E o que é essa tal de Observabilidade?
E bora para mais um artigo com assuntos essenciais para um SRE, dessa vez vamos entender o que é Observabilidade.
Muito provavelmente você que está lendo isso tem ou já teve muitas dúvidas do que é Observabilidade (eu tive). Sempre fiquei pensando se Observabilidade só não era mais um termo da moda para a palavra Monitoração, então comecei a estudar isso e vim aqui compartilhar com vocês o resultado desse estudo na tentativa, bem sincera, de esclarecer o que realmente é Observabilidade.
Aperte os cintos que esse artigo é um pouco extenso. Não desista e leia até o final.
O conceito de Observabilidade não é novo, ele é derivado das publicações de Rudolf E. Kálmán para a "Teoria do Controle" na decáda de 1960.
"Observabilidade é uma medida de quão bem os estados internos de um sistema podem ser inferidos a partir do conhecimento de suas saídas externas." (Rudolf E. Kálmán)
O conceito de Observabilidade foi trazido para a TI como a capacidade do seu ambiente de tecnologia externalizar os estados internos dos seus sistemas. Em outras palavras, é a capacidade que os sistemas (e aqui de uma maneira bastante ampla que contempla hardware dos servidores, equipamentos de rede, sistemas distribuídos, ambiente em nuvem, etc) sejam capazes de criar a quantidade suficiente de dados para que seja possível observar, de modo holístico, o seu estado.
E é aqui que entra o triunfo da Observabilidade, pois além dela ser capaz de encontrar problemas em tempo real, ela entrega dados de todo o fluxo das aplicações e processos, a ponto de providenciar uma observância completa que produz aprendizado de modo a impedir que um falso alarme ocorra no ambiente (quando, por exemplo, é normal ter uma taxa momentânea de utilização de CPU por conta de um aumento momentâneo da utilização de algum processo) ou a ponto de prever falhas no futuro (seguindo o mesmo exemplo, no aumento, mesmo momentâneo de utilização de CPU quando não há nenhum outro indicativo de aumento de utilização de algum processo).
Essa capacidade de entender o comportamento e o estado normal dos serviços de TI só é possível através da observação das saídas dos dados do ambiente (infra, rede, sistemas, nuvem, etc).
A Observabilidade deve ser capaz de apoiar os times de TI na tomada de decisão, na antecipação de problemas e na investigação de incidentes.
Telemetria e os Pilares da Observabilidade
Antes de entrarmos nos Pilares da Observabilidade, vamos entender um pouco sobre Telemetria.
"Telemetria é o feedback que você recebe dos seus sistemas de produção que informa o que está acontecendo lá, esse feedback melhora sua capacidade de tomar decisão sobre os sistemas de produção." (Riedesel, Jamie. Software Telemetry: Reliable logging and monitoring )
Abaixo está a arquitetura que comumente encontramos nos ambientes de telemetria, essa figura foi retirada do livro da Jamie Riedesel, chamado "Software Telemetry: Reliable logging and monitoring". Esse livro é o mais incrível que encontrei sobre esse tema.
O entendimento dessa figura é bem importante para seguirmos com os demais conceitos, temos:
1- Os sistemas de produção, que podem ser equipamentos de rede, servidores, infraestrutura da nuvem, banco de dados ou sistemas. Todos esses elementos geram informações de telemetria;
2- Os sistemas de telemetria recebem essas informações, processam, transformam, armazenam e apresentam;
3- E os usuários, de diversos times, utilizam os sistemas de telemetria para suas atividades do dia a dia.
Os sistemas de telemetria possuem um pipeline de três estágios, conforme demonstra na figura abaixo (também do livro da Jamie Riedesel):
Portanto os sistemas de telemetria recebe os dados no "Estágio Emissor"(Emitting Stage). Em seguida processam, transformam e armazenam essas informações no "Estágio de Expedição" (Shipping Stage). Por fim, apresentam essas informações como suporte para a tomada de decisão, no "Estágio de Apresentação" (Presentatio stage).
E por que é importante entender telemetria? Porque é a telemetria que lida com os três pilares da Observabilidade: Logs centralizado, métricas e rastreabilidade.
Logs Centralizados
É a capacidade de ter, em um lugar centralizado, os logs gerados pelos sistemas de produção. Nesse lugar centralizado as pessoas podem realizar queries para encontrar as informações dos logs.
Abaixo está um exemplo de uma arquitetura de logs centralizados (Jamie Riedesel):
No Estágio de Emissão tanto as aplicações quanto o hardware produzem os logs, no Estágio de Expedição componentes como o log da aplicação (arquivo de log chamado "app.log") e o log do hardware (syslog server) recebem os logs e centraliza no Fluentd, que transforma essas informações e armazenam no Elasticsearch. O Estágio de Apresentação utiliza o Kibana, como interface com o usuário, que está conectado ao Elasticseach, que é onde os usuários fazem as queries pelos seus logs.
Métricas
Diferente dos logs, que normalmente é baseado em textos, as métricas é baseada em números (contadores, timers, médias, etc). Através das métricas é possível entender o que está ocorrendo com o ambiente de produção.
Para ficar mais palpável, uma métrica pode ser o tempo de execução de um determinado processo de produção (algo do tipo metrics.time = "batch_pagamento_stage1_process", timer.seconds).
Abaixo um exemplo de arquitetura de um pipeline de métricas (Jamie Riedesel):
No Estágio de Emissão temos as aplicações (que normalmente emitem métricas usando alguma biblioteca da linguagem daquela aplicação) e a monitoração do sistema operacional (representado pelo collectd) gerando as métricas. No Estágio de Expedição as métricas são transformadas e sumarizadas pelo StatsD e Graphite exporter e armazenadas no Prometheus (que é uma base de dados muito poderosa para armazenar "time series data"). Já no Estágio de Apresentação o Grafana constrói e apresenta os gráficos baseado nas métricas armazenadas no Prometheus.
Rastreabilidade
O objetivo aqui é exibir o trajeto end-to-end de uma requisição ou processo ao longo da arquitetura distribuída de uma aplicação. Ou seja, o trace deve ser capaz de ligar, em uma visão única, todas as execuções de uma requisição ou processo.
Um único rastreamento pode fornecer visibilidade tanto do caminho percorrido por uma requisição quanto da estrutura de uma requisição, conforme ilustra a figura abaixo (Jamiel Riedesel):
Abaixo um exemplo de arquitetura de um sistema de trace:
No Estágio de Emissão o código de produção está usando a biblioteca do OpenTelemetry, que envia os eventos para o Jaeger (sistema open source de rastreamento) que armazena os evendos em uma database no Estágio de Expedição. Por fim, no Estágio de Apresentação, o frontend do Jaeger providencia o mecanismo de busca e demonstração do trace.
Obrigado por ler o artigo até aqui, se chegou até aqui realmente está interessado nesse tema. Está acabando, não desista! :)
Concluíndo… para realmente ser possível ter Observabilidade é preciso ter esses 3 pilares: logs, métricas e rastreabilidade. Entendendo isso você entendeu o que é Observabilidade.
A Observabilidade entrega uma possibilidade impar da TI ser proativa, detectar os problemas antes deles realmente atingir um nível que intefira na experiência dos usuários ou interrompa algum processo de negócio.
Um ponto importante é que para ter Observabilidade é preciso de um bom investimento, investimento em aplicações (que não são baratas) e em treinamento das equipes de SRE. Também é importante ter um ótimo roadmap de integração com os times de desenvolvimento, as aplicações precisam utilizar as bibliotecas definidas pela arquitetura de TI da empresa para a criação dos logs, métricas e rastreamento (e fugir da armadilha de comprar uma super ferramenta de APM que não consegue tirar nenhuma métrica das aplicações por falta de instrumentação no código).
É isso pessoal, espero que tenha ajudado a entender um pouco melhor o que é Observabilidade.
Siga a série de conceitos básicos de SRE:
- Guia dos Conceitos Básicos (https://medium.com/@mclortizz/guia-dos-conceitos-b%C3%A1sicos-do-sre-ab91f0b7531d).
- Vídeo sobre os Conceitos Básicos: https://www.youtube.com/watch?v=9uvS6WeCuVg&t=172s
- SLOs e Error Budget (https://medium.com/@mclortizz/o-que-%C3%A9-sli-slo-error-budget-e-como-isso-evita-a-fal%C3%AAncia-do-sla-3ebfee7c140c).
- Observabilidade (esse aqui).
- Redução de Toil (https://medium.com/@mclortizz/o-que-%C3%A9-toil-quais-suas-caracter%C3%ADsticas-quais-s%C3%A3o-os-passos-para-a-redu%C3%A7%C3%A3o-d8e640fcb265).
- Aprendizagem com a falha (e sem culpa) (https://medium.com/@mclortizz/post-mortem-sem-culpa-5a36f27b885b).
Para quem quer buscar mais informações, deixo alguns livros e sites interessantes sobre SRE e Observabilidade:
- Livro: Engenharia de Confiabilidade do Google (https://sre.google/sre-book/table-of-contents/)
- Livro: The Site Reliability Workbook (https://sre.google/workbook/table-of-contents/)
- Livro: Software Telemetry Reliable Logging and Monitoring (Jamie Riedesel)
- Livro: Distributed Systems Observability (Cindy Sridharan)
- Vídeos de apresentações e seminários do evento "Monitorama": https://vimeo.com/monitorama
- Site da OpenTelemetry: https://opentelemetry.io/docs/concepts/what-is-opentelemetry/
- Site Google SRE: https://sre.google/
Obrigado e até a próxima.
Marcelo Ortiz
Engenheiro da Computação, mestrando em Ciências da Computação.
