Observabilidade: métricas/logs/traces (OpenTelemetry), Prometheus, Grafana, ELK, SLI × SLO × SLA

A ideia que organiza o assunto

Monitorar é vigiar o que você já sabe que pode dar errado. Observar é poder descobrir o que você não previu. Essa frase resolve boa parte dos itens do tópico.

O monitoramento clássico parte de perguntas escritas de antemão — a CPU passou de 80%? o disco encheu? o serviço respondeu ao ping? — e dispara alerta quando a resposta é sim. Funciona bem enquanto os modos de falha são conhecidos e poucos. Em arquitetura distribuída, com dezenas de serviços conversando entre si, a falha interessante quase nunca é uma das previstas: é “por que estes usuários ficaram lentos às terças”. Nenhum painel montado antes responderia a isso.

Observabilidade é a propriedade de se poder inferir o estado interno de um sistema a partir daquilo que ele emite para fora — sem precisar acoplar um depurador nem antecipar a pergunta. É propriedade do sistema, não ferramenta que se compra, e se sustenta em três sinais, cada um respondendo a uma pergunta diferente:

Métrica responde quanto: valor numérico agregado ao longo do tempo — requisições por segundo, latência no percentil 95, uso de memória. Barata de guardar, ótima para alertar, incapaz de explicar um caso individual.
Log responde o que aconteceu: registro discreto e datado de um evento, com o detalhe — a exceção, o parâmetro, o identificador do pedido. Caro de guardar, insubstituível na investigação.
Trace responde por onde passou: o caminho de uma requisição atravessando os serviços, com o tempo gasto em cada trecho. É o sinal que mostra qual serviço da cadeia é o lento.

Diante de um item, pergunte qual dos três a frase está descrevendo e confira o nome que ela usou. É de longe a distinção mais produtiva do tópico.

O segundo eixo é o da medida de qualidade: SLI é o indicador medido, SLO é a meta que a organização se impõe sobre esse indicador e SLA é o compromisso contratual com o cliente, esse sim com penalidade. Os três formam uma escada — medir, prometer internamente, contratar externamente — e a banca troca os degraus.

Como funciona

Os três sinais na prática. As métricas são coletadas por raspagem periódica (o modelo pull do Prometheus, que consulta um endpoint de cada alvo) ou por envio (push), e ficam em banco de séries temporais. Os logs são emitidos pela aplicação e pelo sistema operacional, recolhidos por um agente, normalizados e indexados em um repositório central. Os traces exigem instrumentação: cada requisição recebe um identificador de trace, que é propagado nos cabeçalhos de uma chamada à seguinte, e cada trecho de trabalho vira um span, com início, fim, atributos e o span pai. É a propagação do contexto que costura os spans de serviços diferentes em um trace único.

OpenTelemetry é o padrão aberto que unifica isso. Ele define a especificação, as APIs, os SDKs por linguagem, a semântica dos atributos e o protocolo OTLP de exportação, além de um collector que recebe, processa (filtra, enriquece, amostra) e reexporta os dados para os destinos escolhidos. O ponto central é a separação entre instrumentação e ferramenta: instrumenta-se uma vez, com OpenTelemetry, e troca-se o backend — Jaeger, Prometheus, Grafana, uma solução comercial — sem mexer na aplicação. O projeto nasceu da fusão do OpenTracing com o OpenCensus e é hospedado pela CNCF.

As ferramentas e seus papéis. O Prometheus coleta e armazena métricas, com linguagem de consulta própria. O Grafana não armazena nada: conecta-se a diversas fontes de dados, consulta cada uma na linguagem dela, transforma os resultados e desenha painéis; suas anotações marcam eventos sobre o eixo do tempo — por consulta integrada, pela API HTTP ou manualmente no painel. A pilha ELK cuida de logs: Logstash (ou os Beats) recolhe e transforma, Elasticsearch indexa e busca, Kibana consulta e visualiza. O Jaeger e o Zipkin guardam e exibem traces. As ferramentas de APM instrumentam a aplicação, capturam traces e medem taxas de erro por código de resposta — o 5xx, e em especial o 500, é o erro do servidor que vira indicador de saúde, ao contrário do 4xx, que é do cliente.

Log de sistema operacional. O Syslog é o padrão de mensagens de log em redes e equipamentos, e sua virtude arquitetural é separar quem gera a mensagem, quem a armazena e quem a analisa — é isso que permite mandar o registro de qualquer dispositivo a um coletor central e analisá-lo com outra ferramenta. Cada mensagem carrega facility (a origem) e severity (a gravidade). No Windows, o equivalente é o log de eventos, lido pelo Visualizador de Eventos, que consulta localmente os canais do próprio sistema — aplicativo, segurança, sistema, configuração — sem depender de serviço externo. Centralizar o log fora da máquina é também controle de segurança: quem invade o servidor não apaga o que já saiu dele.

SLI, SLO e orçamento de erro. O SLI é a razão entre eventos bons e eventos totais — disponibilidade como requisições bem-sucedidas sobre requisições totais, latência como a fração atendida abaixo de um limiar. O SLO fixa a meta sobre esse SLI em uma janela de tempo. O que sobra entre a meta e os 100% é o orçamento de erro: a quantidade de falha que se pode gastar no período. Se o orçamento acabou, a organização suspende mudanças arriscadas; se sobra, ela pode arriscar mais. É o mecanismo que transforma confiabilidade em decisão de engenharia em vez de discurso.

O que decide os itens

Os três sinais — a distinção que decide mais itens:

sinal	pergunta	forma	custo
métrica	quanto?	número agregado no tempo	baixo
log	o que aconteceu?	evento datado, com detalhe	alto
trace	por onde passou?	spans encadeados pela requisição	médio, exige instrumentação

Monitoramento × observabilidade — monitoramento observa o que foi previsto e alerta ao romper o limiar; observabilidade permite investigar o que não foi previsto. Observabilidade é propriedade do sistema, não produto.

SLI × SLO × SLA:

	o que é	quem cobra
SLI	o indicador medido (disponibilidade, latência, taxa de erro)	ninguém: é medida
SLO	a meta interna sobre o SLI	a própria equipe
SLA	o contrato com o cliente, com penalidade	o cliente

O SLO é, por projeto, mais rigoroso que o SLA — é a margem que evita a multa.

Orçamento de erro = 100% − SLO, na janela. Gasto o orçamento, congelam-se as mudanças arriscadas.

Papéis das ferramentas — a troca preferida da banca:

ferramenta	papel
Prometheus	coleta e armazena métricas (modelo pull)
Grafana	consulta, transforma e visualiza; não armazena
Elasticsearch	indexa e busca
Logstash / Beats	recolhe e transforma
Kibana	visualiza o que está no Elasticsearch
Jaeger / Zipkin	armazenam e exibem traces
OpenTelemetry	instrumenta e exporta; não é backend

Span × trace — o span é uma unidade de trabalho com início, fim e pai; o trace é a árvore de spans de uma requisição inteira. Trace não é um log grande.

4xx × 5xx — 4xx é erro do cliente (404, 400, 403); 5xx é erro do servidor (500, 502, 503). O indicador de saúde do serviço é a taxa de 5xx.

Elasticsearch — forma das rotas — o índice é o primeiro segmento e os nomes com sublinhado são a operação: GET /indice/_doc/id recupera um documento; _search, _bulk e _cat são as demais operações. Endpoint com sublinhado antes do índice é sintaxe inventada.

Anotação × alerta (Grafana) — a anotação apenas marca que algo ocorreu naquele instante, para correlacionar com a curva; quem notifica é o alerta.

Syslog × Event Viewer — Syslog é padrão de rede, com facility e severity, e separa geração, armazenamento e análise; o Event Viewer lê localmente os canais de log do próprio Windows.

Números que caem


Syslog	514/UDP (e TCP); sobre TLS, 6514
severidades do Syslog	8 níveis, de 0 (emergency) a 7 (debug)
facilities do Syslog	24, de 0 a 23
OTLP (OpenTelemetry)	4317 (gRPC) e 4318 (HTTP)
Elasticsearch	9200 (API REST) e 9300 (transporte entre nós)
Kibana	5601
Prometheus	9090
Grafana	3000
erro do cliente × do servidor	4xx × 5xx (500, 502, 503)
SLO de 99,9% ao mês	orçamento de erro ≈ 43,2 minutos
SLO de 99,99% ao mês	orçamento de erro ≈ 4,3 minutos

Como a CEBRASPE derruba você aqui

A medição está fechada, e é pequena. São 9 itens explicados: 6 Certos e 3 Errados. Três itens errados não desenham distribuição nenhuma — não há percentual honesto a citar aqui —, e cada um dos três faz um movimento diferente. O que segue é o que esses três fazem e o que os seis Certos têm em comum. As traps que o assunto é conhecido por cobrar e que não apareceram nestes nove itens vêm rotuladas como tais.

O conceito reduzido a uma função que é de outro. A observabilidade aparece como “o processo usado para identificar a rota percorrida por um conjunto de dados pela rede até a chegada em seu banco de dados destino” — isso é rastreamento de caminho, e mesmo o rastreamento distribuído seria apenas um dos três sinais, não a observabilidade inteira. Defesa: a definição é sempre inferir o estado interno a partir do que o sistema emite. Item que a reduza a uma ferramenta, a um sinal ou a uma tarefa de rede encolheu o conceito.

O papel de uma ferramenta dado a outra — conhecida do assunto, não medida aqui. Nenhum dos três itens errados troca o papel entre duas peças da pilha, e os cinco itens que descrevem um produto — Grafana duas vezes, APM, Syslog e ELK — descrevem cada um corretamente e são todos Certo. A troca continua barata de armar, porque a pilha tem muitas peças com nomes próximos: fazer do Grafana um banco de séries temporais, do Kibana o indexador, do Logstash o visualizador. Fica registrada como expectativa, não como medição, e a defesa é a mesma: para cada produto, guarde um verbo só — coleta, armazena, indexa, consulta, visualiza, instrumenta — e confira o verbo do item.

A sintaxe alterada num detalhe. O comando “GET /_index/clientes/_doc/123” descreve corretamente o efeito de recuperar um documento por identificador, mas com um segmento que não existe na rota. Defesa: em item de comando ou de API, leia a sintaxe como se fosse um número — é ali que mora a adulteração, não na descrição do efeito.

O produto ou o plugin inventado. Ferramentas de log da Microsoft que “utilizam a tecnologia Azure com Elasticsearch” e às quais “o plugin AZEL é adicionado ao Event Viewer”. Nome específico que ninguém viu, apresentado com aparência técnica, é sinal forte de item errado — a sigla existe justamente para dar concretude ao que não existe. Defesa: desconfie da especificidade desnecessária, e lembre que o Visualizador de Eventos lê o log local do próprio Windows.

O item que só descreve corretamente o conceito. É a maioria da amostra: 6 dos 9 itens são Certo, e todos eles apenas enunciam o que a ferramenta faz — o Grafana consultando várias fontes e desenhando painéis, o APM capturando traces e taxa de erro, o ELK agregando logs, o Syslog separando geração, armazenamento e análise. Defesa: se não houver absoluto, número, sintaxe nem dono de ação trocado, provavelmente o item é Certo.

Erros clássicos

Tratar observabilidade como sinônimo de monitoramento. Monitoramento responde perguntas prontas; observabilidade permite formular perguntas novas. A segunda contém a primeira, não o contrário.

Confundir os três sinais. Métrica é número agregado, log é evento com detalhe, trace é caminho entre serviços. Descrever um sob o nome do outro é o formato campeão.

Achar que trace é um log detalhado. Trace é estrutura: spans encadeados por um contexto propagado entre serviços. Sem propagação de contexto não há trace, por mais log que se emita.

Trocar SLO por SLA. SLO é meta interna, sem multa; SLA é contrato com penalidade. O SLO é sempre mais rigoroso que o SLA que ele protege.

Achar que OpenTelemetry armazena ou visualiza. Ele instrumenta, padroniza e exporta; quem guarda e mostra é o backend escolhido.

Usar a taxa de 404 como indicador de saúde do serviço. 4xx é erro do cliente. O indicador de falha do servidor é a taxa de 5xx.

Supor que mais logs significam mais observabilidade. Volume sem correlação não responde pergunta nenhuma; o que torna o log útil é o identificador que o liga à requisição e ao trace.

Confundir anotação com alerta no Grafana. Anotação marca o evento no gráfico; alerta é que notifica quando a condição é satisfeita.