Cloud, APPs, Logs + MDC

May 02, 2021

Eu sou de um tempo quando tinha um problema na aplicação o sysadmin logava em uma máquina procurava o erro com vários comandos e greps mirabolantes para debulhar os logs. O tempo passou, e hoje, com infraestruturas na nuvem, container, máquinas efêmeras esse modelo de resolver problemas não faz mais sentido, pelo menos não nos ambientes de produção.

Mas se esse modelo não faz mais sentido, qual modelo faz então?? Aháárráá!! É exatamente sobre isso que vamos falar agora, meu jovem!!

O modelo antigo

No cenário antigo existiam infraestruturas com máquinas físicas ou máquinas virtuais (VMs), e nesses modelos as máquinas eram sempre as mesmas, o código e os pacotes necessários para aquela aplicação que mudava a cada nova versão. Era assumido que o sistema operacional e as VMs eram uma constante. Além disso, padronização, distribuição de carga e aplicações sem “sticky session” não eram amplamente valorizados como são hoje. Esses fatores contribuem para um problema X acontecer em uma máquina, e um problema Y totalmente diferente acontecer em outra máquina.

Esse conjunto de fatores, fazia com que a gente conhecesse o ambiente de cada aplicação por nome de máquinas e alguns colegas conseguiam até guardar o número IP de algumas muitas máquinas!! Que coisa né?! ( Hoje em dia eu não sei nem qual é o IP do meu laptop). Quando ocorria algum problema era simples de resolver, rede tal, máquina tal, da aplicação tal. Logava nela com o SSH, executava um milhão de comandos, achava o problema, resolvia, e zazz!! Vitória!! Vamos tomar café!

CLOUD novo modelo

Utilizando cloud pública muda muita coisa, o data center, as redes, as máquinas, os IPs, a localidade geográfica, nada disso te pertence mais. Você precisa saber que as máquinas vão surgir e desaparecer baseado em outros modelos de gestão de infraestrutura. Só uma coisa que não irá mudar, os problemas vão continuar aparecendo, novos problemas vão surgir e você não poderá dar um SSHzinho para resolver o problema.

Diante desse novo cenário, um novo padrão de projeto de infraestrutura deve ser implementado. Suas VMs, Pods, não são mais um destino para os seus logs, eles são apenas um caminho de passagem, o destino final é algum lugar responsável para receber e armazenar os logs, normalmente chamado de Concentrador de Logs.

APP

Se o mundo mudou para o time de infraestrutura, também mudou para os times de desenvolvimento. As aplicações não rodam mais em servidores físicos (conceitualmente rodam sim), as aplicações rodam em VMs na nuvem, ou em containers, ou em infraestruturas “sem infraestrutura” nas arquiteturas de modelo serverless. Novos modelos de chamar os endpoints, nova relação com os tempos de timeouts, as aplicações devem ser preparadas para rodarem em diversos modelos de infraestruturas, em múltiplas máquinas, em múltiplas instâncias, jamais controlar a sessão do usuário por algum dado gravado no servidor ou no balanceador de cargas.

LOGs

Logs de aplicação, logs de sistema operacional para que serve tudo isso? No universo das aplicações, os logs são os registros das atividades que ocorrem dentro dos componentes de um sistema ou equipamento. Alertas, erros, logs de auditoria tudo gera log. Os logs são uma das formas de acompanhar o que está acontecendo na infraestrutura.

Todos os logs de uma infraestrutura devem ser enviados para um concentrador de logs e lá são armazenados e indexados por alguma ferramenta. Agora tá resolvido o problema certo?? Ainda não meu jovem, um concentrado de logs com muitos logs sem uma formatação e sem algum mecanismo de identificação ficará impossível achar alguma coisa, será praticamente inútil … mas é aí que entra o MDC para ajudar a sua vida.

LOGs com Mapped Diagnostic Context (MDC)

Ao lidar com sistemas distribuídas com dezenas de microsserviços em pouco tempo o concentrador de logs estará recebendo uma enxurrada de dados, e como identificar que o usuário de ID WX323212, no dia 12 de Março, às 15:33 teve um erro ao tentar comprar uma camisa de manga longa no seu site?

A resposta está em deixar o log da aplicação mais detalhado possível, simples não? Um log com ID do usuário e TAGs específicas da aplicação. O MDC pode ajudar melhorar os logs, veja um exemplo:

MDC - Exemplo prático!

Conclusão

O modelo de encontrar problemas nas aplicações mudou. Mudou também a infraestrutura com instâncias ou Pods devem funcionar sempre como caminho de passagem para os logs. Para os desenvolvedores muda também, eles devem ter em mente que os logs devem ser claros, detalhados e marcados com TAGs, ID do usuário, id_da_atividade, classe chamada, etc..

Nesse novo cenário ter logs detalhados e “tagueados” ajuda na indexação nas bases dos logs e facilita ao buscar por chaves e valores específicos. Facilita na criação de alertas e de métricas.

Nesse novo cenário, o antigo grep mirabolante do Sysadmin se torna uma query tão simples quanto essa ;)

1curl -XGET --header 'Content-Type: application/json' http://concentradordelogs.zz.com/_search -d '{
2    "query" : {
3    "match" : { "clientID": "WX323212" }
4}

Referência

Convido você a ver os outros posts do Infra-as-Code

Eu adoraria ouvir suas outras histórias e situações semelhantes ao que acabei de escrever neste post, você pode me encontrar em @infraascode_br ou linkedin.com/in/leonardoml/ .

Te convido a ver os outros posts do blog Infra-as-Code garanto que tem coisas legais lá!!

--- --- IMPORTANTE --- ---
As opiniões aqui expressas são pessoais e de responsabilidade única e exclusiva do autor, elas não refletem necessariamente a posição das empresas que eu trabalho(ei) e/ou presto(ei) serviço.