Conteúdo original nessa thread do Twitter
Ei dev,
Muito provável que já tenha ouvido o termo OBSERVABILIDADE.
Se você nunca ouviu ou o conceito ainda estiver meio nublado, cola aí pra mandar benzaço no seu próximo date e impressionar o crush discutindo sobre tracing.
cc @sseraphini
↓
Disclaimer: essa thread é apenas uma introdução super básica pra vc impressionar quem não sabe sobre o assunto ou pelo menos não se sentir tão perdida/o nas rodas de SRE – confia.
Observabilidade é sustentada por 3 pilares principais e vamos passar por cada um deles: MÉTRICAS, LOGS, E RASTREAMENTO (ou RASTREABILIDADE – sei lá qual é o jeito certo).
MÉTRICAS:
Quando falamos em métricas, a gente precisa pensar numa linha do tempo e coleta de valores. Essas medições podem estar relacionadas com aspectos técnicos ou não. Por exemplo, medição de CPU, memória, etc. Mas nada impede a medição de quantidade de logins, por exemplo.
Sendo bem prático, um exemplo clássico são aqueles painéis com gráficos bonitos, sabe? Claro, os gráficos são apenas uma representação do que foi coletado e você pode fazer outras coisas com os números, como predições, por exemplo.
Um aspecto comumente relacionado a métricas são alarmes. É normal que configuremos alarmes via métricas através de limiares (também falado "thresholds"). Por exemplo, "se a CPU atingir 90% por mais de 5 minutos, manda um sms, toca o telefone, acende a luz vermelha, etc". Top, né?
LOGS:
Esse é o mais conhecido dos 3. Logs são registros discretos de coisas que ocorreram – nada que você já não saiba. Os logs dão uma ideia do que está rolando num componente sistêmico e é excelente pra encontrar e resolver problemas (o famoso troubleshooting).
Deixa eu aproveitar e dar uma dica sobre algo que vejo o pessoal fazendo muito frequentemente: não use logs para métricas se puder, ok? Você vai precisar ficar minerando logs se baseando em padrões no conteúdo. Dessa forma, qq mudança nos logs poderá quebrar suas métricas, blz?
RASTREAMENTO:
Ah, esse é chique e faz sentido em sistemas distribuídos. Rastreamento ("tracing") é correlacionar uma série de eventos ocorridos em lugares diferentes (uma API que chamou outra API, que postou numa fila, etc.). Tracing é como se fossem logs distribuídos.
Como já disse, tracing só faz sentido em sistemas distribuídos. Se você estiver lidando com aplicações que praticamente não fazem saltos de rede (hops) além de para um banco de dados, nem vale a pena o esforço, sinceramente.
Boa! Agora você tá lá com seu crush e o negócio não está indo bem. Vou te dar uma carta pra guardar na manga e lançar nessas horas difíceis!
Olha bem nos olhos do crush e lança "e instrumentação, hein? complicado, né?". O crush vai arrepiar e tá aí sua chance.
Pra gente poder ter esses 3 pilares da observabilidade, a gente precisa INSTRUMENTAR nosso código, servidores, etc. Talvez você ouça esse termo e ele quer dizer usar/adicionar instrumentos para que sejamos capazes de gerar/obter métricas, logs e rastreabilidade!
Uma dica sobre instrumentação: dá um pesquisada e estudada no Open Telemetry. São ferramentas, SDKs, etc. disponíveis pra várias linguagens.
Essa thread foi só pra vc molhar o dedinho do pé nesse rolê de observabilidade, e pra eu poder te dar um abraço e agradecer pelo apoio e moral!
(Ah, dá aquele RT, curte, comenta de boa, pode ser?)
Top comments (1)
Ótimo conteúdo Francisco!
Tenho utilizado bastante o APM do ELK Stack. Testei o jaeger inicialmente mas o ELK se mostrou um pouco mais maduro... pra uso com .net é uma mão na roda e tem dado ótimos insights aqui na observabilidade.
Abs!!