Como três pilares viraram um?
Se você trabalha com software, com toda certeza já ouviu falar sobre microsserviços, SaaS, DevOps e todas essas palavras da moda, e provavelmente já ouviu a palavra observabilidade (observability).
Além da minha experiência anedótica me levar a desconfiar daqueles que querem muito usar essas palavras (sem saber exatamente o que significa), um comportamento que chamou minha atenção recentemente foi como as pessoas tem tratado tudo isso como um único e grande framework.
Hoje eu vou focar em uma tendência comum, embora bastante prejudicial, de tratar logs, métricas e traces como uma coisa só.
No princípio, era o verbo…
Muito antes de se ouvir falar sobre pilares e observabilidade no contexto que assumimos hoje, todos esses métodos já existiam como forma de monitorar e/ou entender como o seu software se comporta em um determinado ambiente. Para métricas, temos as Kprobes do Linux, para traces podemos citar o WMI, que podia ser instalado desde o Windows 98 (foi o que a Wikipédia me contou), e log é uma palavra que tem origem muito anterior a qualquer sistema eletrônico, se quisermos continuar indo mais longe.
Juntos, eles formam os chamados “três pilares da observabilidade”, ou seja, técnicas que, pasmem, te permitem monitorar como seu software se comporta em um determinado ambiente, embora agora esse ambiente seja distribuído ao redor do mundo.
Com essas três técnicas milenares, os desenvolvedores de sistemas distribuídos perceberam que podiam reunir informações sobre todo o seu complexo sistema que fica muito bonito em visualizações de grafo, com o plus de garantir que todos os pontos estão saudáveis o bastante para não prejudicar o resto do sistema.
…E então as coisas se confundem
Depois de perceber que essas técnicas eram boas o bastante para sistemas distribuídos, os desenvolvedores começaram a entender que nem sempre técnicas que funcionam dentro de um sistema auto contido escalam bem quando temos que replicar e sincronizar essas mesmas técnicas em lugares diferentes.
A primeira e mais óbvia é o tracing. Quando estamos falando em um sistema que pretende ter o tracing de milhões de objetos ao longo de um dia, e monitorar isso ao longo de uma rede complexa de comunicação, escala se torna um problema bem sério. Foi ai que entraram em cena amostras estatísticas para nos ajudarem (de novo uma técnica milenar, ou pelo menos de outro milênio).
Então quando falamos de tracing em um sistema distribuído que pretende operar em grandes escalas, ou só tracing distribuído, estamos falando em um conjunto de amostras que consideramos como significativamente relevante para demonstrar o comportamento do nosso sistema. E é aqui que o primeiro erro costuma acontecer:
Tracing distribuído é bom para debug
Essa uma promessa que ouvimos bastante, usar tracing como forma de entender todas as transições de um certo objeto dentro do nosso sistema e quando um erro existir, esse mesmo tracing vai nos dar uma visualização especial de como o erro aconteceu.
Bom, isso quase nunca acontece. O primeiro motivo é que você não esperava um erro inesperado (isso mesmo), quando decidiu o modo como iria coletar amostras no seu sistema, o que pode significar que você não tem a amostra necessária. Além disso, mesmo quando você consegue a sua amostra, a não ser que você tenha adotado um estilo de inserir todo tipo de informação dentro do seu sistema de tracing (se sim, boa sorte com a conta de armazenamento e duração de chamadas entre serviços), você provavelmente não vai ter muitas informações para debug.
Traces quase sempre não são bons para debug a nível de serviço, mas podem ser um ótimo complemento para dividir a carga com nosso outro pilar, os logs.
É possível e recomendado colocar toda informação necessária em um registro de log, e elas não precisam ser repassadas ao longo do sistema inteiro, além de podermos usar ferramentas de análise de logs para auxiliar durante o debug.
Tudo isso é verdade, logs ainda são, na minha opinião, a melhor ferramenta para debug de um sistema. Existem várias estratégias que eu não vou discutir aqui sobre coletar logs, principalmente aqueles relacionados a debug, que em geral são os mais custosos em termos computacionais.
E agora já temos dois pilares de três, basta inserir métricas e começar as palestras. Isso nos leva ao próximo grande erro:
Logs são ótimos para recolher métricas
Antes de mais nada, logs até podem ser fontes de métricas, mas o objetivo primário de um log não é esse. Existem alguns problemas em ter logs como fontes primárias para métricas do seu sistema.
Um log em geral esta ligado diretamente ao contexto do seu serviço, o que significa que vários problemas podem ocorrer antes que um log seja registrado, prejudicando sua ingestão de métricas. Muitos dos seus logs podem estar ligados a funções mais externas que falham antes, ou a saída de funções anteriores.
Além disso, uma métrica é um número que pode ser recolhido e tratado como indicador para algum ponto importante a ser observado, e é importante focar na afirmação de “um número”. Logs costumam ser grandes e conter muitas informações, das quais poucas podem se tornar efetivamente métricas, o que implica em uma larga carga de processamento para extrair pontos relevantes.
Vários problemas, o mesmo problema
Existe um motivo primordial para que existam três pilares quando falamos em observabilidade de sistemas distribuídos. Quando queremos ter um teto, tentar trazer mais carga para um pilar ou decidir abrir mão de outro é um erro estrutural que pode acabar ruindo acima das nossas cabeças.
O mesmo erro leva os três pilares a serem tratados como uma coisa só: Não entender qual o objetivo primordial de cada ponto e aplica-lo antes de ter um objetivo claro.
Tracers só viram ferramentas de debug quando não se tem plena consciência do custo e do funcionamento que essa ferramenta tem, assim como de seu objetivo de registrar fluxos.
Logs só passam a ser grandes fontes de métricas quando não se tem plena consciência de como essas métricas podem ser recolhidas. É bem mais barato aumentar um certo contador antes de registrar um log do que processá-lo para obter a mesma contagem depois.
É claro que toda solução depende de contexto, mas ainda mais importante é o conhecimento dos requisitos e dos outputs quando decidimos aplica-las. Usar termos bonitos para soluções feias parece estar se tornando cada vez mais comum, então mantenha os olhos abertos.
