 |
| Bellacosa Mainframe e o caso dos sinais ocultos do sistema logging tracing e metrics |
☕ Um Café no Bellacosa Mainframe
Logging, Tracing & Metrics — O Caso dos Sinais Ocultos no Sistema
A chuva caía sobre o CPD como se alguém tivesse submetido um JOB com TYPRUN=HOLD para o próprio céu.
Na sala de operações, monitores exibiam gráficos, mensagens, filas, tempos de resposta e alguns alertas vermelhos que ninguém queria encarar por muito tempo. O relógio marcava 02h17 da manhã quando o telefone tocou.
— Bellacosa, temos um problema.
Do outro lado da linha, um programador COBOL iniciante tentava controlar a ansiedade.
— Qual é o erro?
— Ainda não sabemos.
— O sistema caiu?
— Não exatamente.
— O CICS está fora?
— Não.
— O Db2 parou?
— Também não.
— Então qual é o problema?
Houve alguns segundos de silêncio.
— Os clientes estão reclamando que o sistema está lento.
Essa é uma das frases mais perigosas de qualquer ambiente de produção.
“Está lento” não é diagnóstico.
“Está lento” é uma pista.
Pode ser CPU, memória, rede, fila, programa COBOL, consulta SQL, contenção de recurso, timeout, deadlock, chamada externa, API, excesso de logging, problema em disco, indisponibilidade parcial ou até uma combinação de vários elementos.
Foi então que uma figura surgiu na porta do CPD usando um sobretudo escuro, segurando uma lupa em uma mão e uma caneca de café na outra.
— Elementar, meu caro Padawan — disse o investigador. — O sistema já contou o que aconteceu. O problema é que vocês ainda não aprenderam a ouvi-lo.
Assim começa nossa investigação sobre Logging, Tracing, Metrics e Observabilidade.
Para um programador COBOL iniciante, esses conceitos podem parecer assuntos exclusivos de Cloud, DevOps, Kubernetes ou microsserviços. Mas isso é um engano digno de um suspeito tentando desviar a atenção do detetive.
Observabilidade também pertence ao mundo do mainframe.
Ela está no DISPLAY do COBOL, nas mensagens do CICS, nos registros SMF, no SYSLOG, no JES, nas estatísticas do Db2, nas filas MQ, nos tempos de resposta e nos caminhos percorridos por uma transação.
O mainframe sempre produziu evidências.
Agora precisamos aprender a investigá-las.
O mistério central: o sistema está tentando falar
A frase que inspira esta investigação é:
What if the hidden signals in your system are screaming for attention?
Em português:
E se os sinais ocultos do seu sistema estiverem gritando por atenção?
Sistemas raramente falham sem aviso.
Antes de um incidente, normalmente surgem pequenos sintomas:
aumento de tempo de resposta;
crescimento de filas;
elevação da CPU;
redução do throughput;
aumento de erros intermitentes;
mensagens de timeout;
conexões abertas por tempo excessivo;
SQLCODEs incomuns;
maior consumo de memória;
crescimento anormal de logs;
transações aguardando recursos;
chamadas externas cada vez mais lentas.
Separadamente, esses sinais podem parecer irrelevantes.
Juntos, eles formam uma cena do crime.
O grande objetivo da observabilidade é transformar sinais isolados em uma narrativa compreensível.
Em outras palavras, observabilidade é a capacidade de olhar para o comportamento externo de um sistema e deduzir o que está acontecendo dentro dele.
É exatamente o que Sherlock Holmes faria.
Ele não precisava ter visto o crime acontecer. Analisava pegadas, cinzas de cigarro, marcas no chão, horários, testemunhos e objetos fora de lugar.
Na engenharia de software, fazemos algo parecido com:
Cada um desses elementos revela uma parte da história.
Capítulo 1 — Logging: o diário secreto do sistema
Logs são registros de acontecimentos.
Eles respondem perguntas como:
O que aconteceu?
Quando aconteceu?
Onde aconteceu?
Qual módulo estava sendo executado?
Qual usuário iniciou a operação?
Qual foi o código de retorno?
Qual dado estava sendo processado?
Qual transação estava ativa?
Imagine um programa COBOL responsável por consultar o saldo de um cliente.
Um log simples poderia ser:
CONSULTA DE SALDO INICIADA
Isso é melhor do que nada, mas ajuda pouco.
Qual cliente?
Qual horário?
Qual transação?
Qual programa?
Qual resultado?
Um log mais útil seria:
2026-08-03 02:17:54
PROGRAMA=BCSALDO
TRANSACAO=BS01
CLIENTE=000123456
EVENTO=INICIO-CONSULTA
Depois:
2026-08-03 02:17:55
PROGRAMA=BCSALDO
TRANSACAO=BS01
CLIENTE=000123456
SQLCODE=0
TEMPO-DB2=245MS
EVENTO=CONSULTA-CONCLUIDA
Agora existe uma narrativa.
Sabemos quando começou, quando terminou, qual cliente foi consultado e quanto tempo o Db2 levou.
Se ocorrer um erro:
2026-08-03 02:17:56
PROGRAMA=BCSALDO
TRANSACAO=BS01
CLIENTE=000123456
SQLCODE=-911
EVENTO=ROLLBACK
MENSAGEM=DEADLOCK-OU-TIMEOUT
Esse registro se transforma em evidência.
O erro clássico: escrever logs inúteis
Programadores iniciantes frequentemente usam mensagens assim:
DISPLAY 'DEU ERRO'.
O problema é que “deu erro” não diz absolutamente nada.
Seria como Sherlock Holmes encontrar uma testemunha que afirma:
— Aconteceu alguma coisa.
E se recusa a explicar o quê.
Um log de qualidade precisa fornecer contexto.
Exemplo:
DISPLAY 'ERRO NO PROGRAMA BCPAGTO'
DISPLAY 'CLIENTE: ' WS-CLIENTE
DISPLAY 'CONTA: ' WS-CONTA
DISPLAY 'SQLCODE: ' SQLCODE
DISPLAY 'ETAPA: CONSULTA-SALDO'
Melhor ainda seria construir uma mensagem estruturada:
LEVEL=ERROR
PROGRAM=BCPAGTO
STEP=CONSULTA-SALDO
CLIENT=000123456
SQLCODE=-911
TRACE-ID=ABC987654
Esse formato é fácil de pesquisar e processar automaticamente.
Logs estruturados
Sistemas modernos preferem logs estruturados, frequentemente no formato JSON:
{
"timestamp": "2026-08-03T02:17:56",
"level": "ERROR",
"program": "BCPAGTO",
"transaction": "PG01",
"customer": "000123456",
"sqlcode": -911,
"traceId": "ABC987654",
"message": "Rollback após deadlock"
}
Um programa COBOL tradicional pode não gerar JSON diretamente, mas isso não impede o uso do conceito.
O importante é manter um padrão previsível.
Por exemplo:
TIMESTAMP=20260803021756|LEVEL=ERROR|PGM=BCPAGTO|SQLCODE=-911
Depois, ferramentas de integração podem transformar esse conteúdo em formatos modernos.
Logging no mundo mainframe
No ecossistema IBM Z, os logs estão espalhados por vários lugares:
SYSOUT do JES;
spool;
mensagens do programa COBOL;
registros SMF;
CICS transient data queues;
CICS logs;
mensagens de Db2;
logs do MQ;
SYSLOG;
arquivos sequenciais;
datasets de auditoria;
mensagens RACF;
registros de middleware;
logs do z/OS Connect;
relatórios de ferramentas de monitoramento.
Para um iniciante, isso pode parecer fragmentado.
Mas o mainframe trabalha assim porque cada subsistema tem responsabilidades específicas.
O desafio moderno é correlacionar essas fontes.
Capítulo 2 — Metrics: os números que denunciam o comportamento
Se logs contam histórias, métricas contam números.
Uma métrica é uma medida quantitativa coletada ao longo do tempo.
Exemplos:
CPU = 78%
MEMORIA = 64%
TPS = 1.250
LATENCIA-MEDIA = 220MS
ERROS-POR-MINUTO = 35
FILA-MQ = 4.820
Métricas respondem perguntas como:
O sistema está mais lento que ontem?
A quantidade de erros está crescendo?
A CPU está próxima do limite?
A fila está acumulando mensagens?
O número de transações aumentou?
Qual é o tempo médio de resposta?
O comportamento atual é normal?
A grande vantagem das métricas é a capacidade de agregação.
Você não precisa guardar todos os detalhes de cada requisição para saber que a média de latência aumentou de 200 milissegundos para 3 segundos.
Média pode enganar
Vamos investigar dois cenários.
Cenário A
Cinco requisições:
100ms
110ms
120ms
130ms
140ms
Média:
120ms
Tudo parece normal.
Cenário B
Cinco requisições:
50ms
50ms
50ms
50ms
4000ms
Média:
840ms
A média revela um problema, mas não explica que apenas uma requisição foi extremamente lenta.
Agora imagine mil requisições.
A média pode esconder comportamentos importantes.
Por isso usamos percentis.
Percentis: P50, P95 e P99
O percentil indica o valor abaixo do qual determinada porcentagem das observações se encontra.
P50
Metade das requisições foi mais rápida que esse valor.
Também é conhecido como mediana.
P95
95% das requisições foram concluídas abaixo desse tempo.
Os 5% restantes foram mais lentos.
P99
99% das requisições ficaram abaixo desse valor.
O 1% restante representa os casos extremos.
Exemplo:
P50 = 180ms
P95 = 950ms
P99 = 4200ms
A média poderia ser 300 milissegundos, dando a impressão de que tudo está saudável.
Mas o P99 mostra que alguns usuários estão esperando mais de quatro segundos.
Para o negócio, esse detalhe pode ser crítico.
Métricas importantes para COBOL e mainframe
Um programador COBOL deveria começar a conhecer:
quantidade de registros processados;
tempo de execução do JOB;
quantidade de commits;
quantidade de rollbacks;
leituras de arquivos;
gravações;
registros rejeitados;
SQLCODEs diferentes de zero;
tempo gasto em Db2;
tempo gasto em VSAM;
número de transações CICS;
tempo médio de resposta;
uso de CPU;
consumo de zIIP;
filas MQ;
abends;
quantidade de retries;
taxa de sucesso;
taxa de erro.
Em um programa batch, métricas podem ser exibidas no final:
REGISTROS-LIDOS......: 001000000
REGISTROS-VALIDOS....: 000998500
REGISTROS-REJEITADOS.: 000001500
COMMITS..............: 000001000
TEMPO-TOTAL..........: 00:08:32
Isso é observabilidade.
Talvez não esteja em um dashboard sofisticado, mas o princípio é o mesmo.
Capítulo 3 — Tracing: seguindo as pegadas da requisição
Tracing é o acompanhamento completo de uma solicitação através de vários componentes.
Imagine uma compra realizada por aplicativo:
Usuário
↓
Aplicativo Mobile
↓
API Gateway
↓
Serviço de Pedido
↓
Serviço de Pagamento
↓
z/OS Connect
↓
CICS
↓
Programa COBOL
↓
Db2
↓
MQ
↓
Resposta
O usuário reclama:
— Minha compra levou oito segundos.
Onde o tempo foi consumido?
Sem tracing, cada equipe olha apenas para sua parte.
A equipe do aplicativo diz:
— O mobile enviou a requisição corretamente.
A equipe da API diz:
— Recebemos e encaminhamos.
A equipe do CICS diz:
— A transação terminou.
A equipe do Db2 diz:
— A consulta executou.
Todos parecem inocentes.
Mas o usuário esperou oito segundos.
O tracing conecta as etapas.
Trace e Span
Um trace representa toda a jornada de uma requisição.
Um span representa uma etapa dessa jornada.
Exemplo:
TRACE ABC123
├── SPAN 01: Mobile App............. 50ms
├── SPAN 02: API Gateway............ 40ms
├── SPAN 03: Serviço Pagamento...... 90ms
├── SPAN 04: z/OS Connect........... 45ms
├── SPAN 05: CICS................... 80ms
├── SPAN 06: Programa COBOL......... 70ms
├── SPAN 07: Db2.................. 7200ms
└── SPAN 08: Resposta............... 60ms
Pronto.
O culpado apareceu.
O Db2 consumiu 7,2 segundos.
Mas o caso ainda não terminou.
Por que o Db2 demorou?
Pode ter sido:
O trace localiza a região do problema.
Os logs fornecem detalhes.
As métricas mostram se é um caso isolado ou uma tendência.
É por isso que os três pilares precisam trabalhar juntos.
Capítulo 4 — A grande correlação
O segredo mais importante da observabilidade moderna é a correlação.
Sem correlação, você possui milhares de logs, métricas e traces desconectados.
Com correlação, cada evidência aponta para o mesmo caso.
Para isso usamos identificadores como:
Trace ID;
Span ID;
Request ID;
Correlation ID;
Transaction ID;
Session ID.
Exemplo:
TRACE-ID=ABC123
Esse mesmo valor aparece:
No API Gateway
No serviço Java
No z/OS Connect
No CICS
No programa COBOL
No log do Db2
Na resposta ao cliente
Agora o investigador pode pesquisar ABC123 e reconstruir toda a operação.
Como levar um Correlation ID até o COBOL
Um possível fluxo seria:
Aplicativo cria Request ID
↓
API Gateway recebe o ID
↓
Cabeçalho HTTP transporta o valor
↓
z/OS Connect encaminha
↓
CICS recebe
↓
COMMAREA ou Channel/Container armazena
↓
Programa COBOL lê
↓
Programa grava o ID nos logs
Exemplo conceitual de campo COBOL:
01 WS-CORRELATION-ID PIC X(36).
Durante o processamento:
DISPLAY 'TRACE-ID=' WS-CORRELATION-ID
' PROGRAMA=BCPAGTO'
' ETAPA=VALIDACAO'.
Assim, o programa COBOL deixa de ser uma caixa isolada dentro da arquitetura.
Ele passa a participar da observabilidade ponta a ponta.
Capítulo 5 — OpenTelemetry: o tradutor universal
Na imagem aparece o OpenTelemetry, frequentemente abreviado como OTel.
O OpenTelemetry é um conjunto de padrões, bibliotecas, APIs, SDKs e componentes para coletar telemetria.
Telemetria é o conjunto de sinais produzidos pelo sistema:
Uma das grandes vantagens do OpenTelemetry é evitar dependência excessiva de um único fornecedor.
A aplicação gera dados em um padrão conhecido.
Depois, esses dados podem ser enviados para diferentes plataformas.
Auto instrumentation
A imagem mostra:
OTel auto instrumentation
OTel API
OTel SDK
Auto instrumentation
Instrumentação automática.
A ferramenta observa bibliotecas, frameworks e chamadas comuns sem exigir muitas alterações no código.
É útil em Java, .NET, Python, Node.js e outras plataformas.
OTel API
A API define como a aplicação cria spans, métricas e eventos.
OTel SDK
O SDK implementa a coleta, processamento e exportação dos dados.
No mundo COBOL, a instrumentação pode depender mais da arquitetura, do middleware e das ferramentas disponíveis.
Mesmo assim, a aplicação COBOL pode participar fornecendo:
OpenTelemetry Collector
O Collector funciona como uma central de triagem.
Imagine a Scotland Yard da telemetria.
Ele recebe sinais de vários serviços, processa, filtra e encaminha.
Fluxo:
Aplicação
↓
OpenTelemetry Collector
↓
Grafana / Jaeger / Elastic / Backend APM
O Collector pode:
receber dados;
remover informações sensíveis;
adicionar metadados;
agrupar registros;
aplicar filtros;
controlar volume;
encaminhar para vários destinos;
reduzir dependência de agentes proprietários.
Capítulo 6 — Prometheus, Grafana, Elasticsearch, Kibana e Jaeger
A imagem apresenta várias ferramentas.
Vamos colocar cada suspeito na sala de interrogatório.
Prometheus
Prometheus é amplamente utilizado para coletar e armazenar métricas em séries temporais.
Uma série temporal é um conjunto de valores registrados ao longo do tempo.
Exemplo:
10:00 CPU=45%
10:01 CPU=48%
10:02 CPU=60%
10:03 CPU=82%
10:04 CPU=94%
O valor isolado de 94% é importante.
Mas a evolução também é importante.
Se a CPU subiu continuamente durante quatro minutos, existe uma tendência.
Prometheus trabalha muito bem com esse tipo de dado.
Grafana
Grafana é uma plataforma de visualização.
Ele transforma números em dashboards.
Um dashboard pode exibir:
TPS;
erros por minuto;
latência;
uso de CPU;
consumo de memória;
volume de transações;
filas;
disponibilidade;
P95;
P99;
status de serviços.
Uma curiosidade importante:
Grafana não é necessariamente o local onde os dados são coletados.
Ele normalmente consulta outras fontes.
É o painel do detetive, não o local do crime.
Alertmanager
Alertmanager gerencia alertas.
Exemplo:
Se erro > 5% durante 10 minutos:
enviar mensagem para equipe
abrir incidente
registrar severidade
Um bom alerta precisa evitar dois extremos:
Silêncio excessivo
O problema acontece e ninguém é avisado.
Tempestade de alertas
A equipe recebe centenas de mensagens e deixa de prestar atenção.
Esse fenômeno é chamado de alert fatigue, ou fadiga de alertas.
Um alerta útil deve ser:
acionável;
contextualizado;
relevante;
direcionado à equipe correta;
baseado em condição persistente;
vinculado a um procedimento.
Elasticsearch
Elasticsearch é usado para indexação e pesquisa de grandes volumes de dados, especialmente logs.
Com ele, podemos pesquisar:
SQLCODE=-911
ou:
PROGRAM=BCPAGTO AND LEVEL=ERROR
ou:
TRACE-ID=ABC123
Ele permite encontrar rapidamente eventos em enormes conjuntos de registros.
Kibana
Kibana é muito usado para visualizar e explorar dados armazenados no Elasticsearch.
Com ele, podemos criar:
dashboards;
filtros;
gráficos;
pesquisas;
análises;
painéis de erros.
A dupla Elasticsearch e Kibana tornou-se famosa em arquiteturas de logging centralizado.
Jaeger
Jaeger é uma plataforma voltada para tracing distribuído.
Ela mostra visualmente o caminho de uma requisição.
Em vez de apenas saber que o sistema demorou quatro segundos, você enxerga onde cada milissegundo foi consumido.
Para um ambiente híbrido envolvendo Cloud e IBM Z, essa visão é extremamente valiosa.
Capítulo 7 — Observabilidade não é apenas monitoramento
Monitoramento e observabilidade são relacionados, mas não são idênticos.
Monitoramento
Pergunta:
O sistema está funcionando?
Exemplos:
servidor disponível;
CPU abaixo de 80%;
serviço respondendo;
disco com espaço;
CICS ativo.
Observabilidade
Pergunta:
Por que o sistema está se comportando dessa maneira?
A observabilidade permite investigar situações desconhecidas.
O monitoramento costuma trabalhar com problemas previamente imaginados.
Exemplo:
Se CPU > 90%, alertar.
Mas e se a CPU estiver em 40% e o sistema estiver lento?
O alerta não dispara.
A observabilidade permite explorar os dados e descobrir que:
uma API externa está demorando;
uma fila está crescendo;
um lock está bloqueando transações;
um plano SQL mudou;
o logging síncrono está atrasando o processamento.
A observabilidade não elimina o monitoramento.
Ela o amplia.
Capítulo 8 — Caso prático: o PIX fantasma
Vamos investigar um cenário completo.
Um cliente tenta realizar um PIX.
Arquitetura:
Aplicativo
↓
API Gateway
↓
Serviço de Autenticação
↓
Serviço Antifraude
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
Db2
↓
MQ
↓
Resposta
O cliente recebe timeout.
Primeira pista: métrica
O dashboard mostra:
Latência P95:
Antes: 800ms
Agora: 6.500ms
A taxa de erro aumentou para 8%.
A métrica confirma que não é um caso isolado.
Segunda pista: trace
O trace mostra:
API Gateway.............. 30ms
Autenticação............. 70ms
Antifraude............... 90ms
z/OS Connect............. 40ms
CICS..................... 60ms
COBOL.................... 50ms
MQ..................... 5800ms
O gargalo está no MQ.
Terceira pista: logs
Os logs mostram:
MQRC=2053
REASON=QUEUE-FULL
QUEUE=PIX.OUTBOUND
Agora temos a causa provável.
A fila atingiu sua capacidade.
Quarta pista: investigação operacional
Por que a fila encheu?
Outro log mostra que o consumidor externo estava indisponível.
Conclusão:
Consumidor externo indisponível
↓
Mensagens acumuladas
↓
Fila MQ cheia
↓
Programa COBOL aguardando ou falhando
↓
Transações mais lentas
↓
Timeout no aplicativo
Sem observabilidade, cada equipe poderia culpar a outra.
Com métricas, traces e logs correlacionados, a investigação torna-se objetiva.
Capítulo 9 — Passo a passo para começar
Um programador COBOL iniciante não precisa implementar uma plataforma inteira no primeiro dia.
O caminho deve ser gradual.
Passo 1 — Identifique operações importantes
Liste as etapas críticas do programa.
Exemplo:
INICIO
VALIDACAO
LEITURA-ARQUIVO
CONSULTA-DB2
ATUALIZACAO
COMMIT
FIM
Esses pontos serão usados como marcos.
Passo 2 — Padronize os logs
Evite mensagens aleatórias.
Use um formato consistente:
DATA-HORA
PROGRAMA
ETAPA
NIVEL
CORRELATION-ID
CODIGO-RETORNO
MENSAGEM
Exemplo:
20260803-021754|INFO|BCPAGTO|INICIO|TRACE=ABC123|RC=0000
Passo 3 — Registre apenas o necessário
Não transforme o programa em uma metralhadora de DISPLAY.
Logging excessivo pode:
Registre eventos relevantes.
Passo 4 — Crie métricas de negócio
Não monitore apenas infraestrutura.
Inclua indicadores do processo.
Exemplos:
pagamentos processados;
pagamentos recusados;
clientes validados;
registros rejeitados;
transações concluídas;
fraudes detectadas.
Uma CPU saudável não significa que o negócio está funcionando.
O sistema pode estar disponível e, ainda assim, rejeitar todos os pagamentos.
Passo 5 — Meça duração
Registre horário de início e fim.
Exemplo conceitual:
INICIO=02:17:54.100
FIM=02:17:54.850
DURACAO=750MS
Faça isso para etapas críticas.
Assim você poderá descobrir onde o tempo está sendo consumido.
Passo 6 — Adote um identificador de correlação
Cada requisição deve possuir um identificador único.
Exemplo:
TRACE-ID=PX202608030000123456
Propague esse valor entre as camadas.
Passo 7 — Defina alertas úteis
Exemplo ruim:
Alertar quando ocorrer um erro.
Isso pode gerar milhares de alertas.
Exemplo melhor:
Alertar quando a taxa de erro ultrapassar 5%
durante 10 minutos.
Outro exemplo:
Alertar quando o P95 superar 2 segundos
por 5 minutos consecutivos.
Passo 8 — Crie um runbook
Um runbook é um roteiro operacional.
Exemplo:
ALERTA: FILA MQ ACIMA DE 80%
1. Verificar profundidade da fila.
2. Verificar consumidor.
3. Verificar mensagens presas.
4. Confirmar conectividade.
5. Avaliar expansão temporária.
6. Acionar equipe responsável.
Um alerta sem orientação apenas transfere o problema para outra pessoa.
Passo 9 — Revise depois do incidente
Após resolver, pergunte:
O alerta chegou cedo?
Os logs eram suficientes?
O Trace ID estava disponível?
A métrica correta existia?
Houve excesso de ruído?
O runbook ajudou?
Poderíamos detectar antes?
Observabilidade é melhoria contínua.
Capítulo 10 — Boas práticas fundamentais
Nunca registre senhas
Nem em testes.
Nem temporariamente.
Nem “só para depurar”.
Também evite registrar:
Use mascaramento:
CPF=***.***.***-45
CARTAO=****-****-****-1234
Use níveis de log
Um modelo comum:
DEBUG
Detalhes para investigação técnica.
INFO
Eventos normais importantes.
WARN
Situação incomum, mas não fatal.
ERROR
Falha que afetou uma operação.
FATAL
Problema grave que impede continuidade.
Nem todo evento deve ser ERROR.
Caso contrário, ninguém saberá diferenciar uma falha crítica de uma condição comum.
Evite mensagens ambíguas
Ruim:
ERRO NA TABELA
Bom:
ERRO AO ATUALIZAR TABELA CLIENTE
SQLCODE=-803
CHAVE=000123456
TRACE-ID=ABC123
Inclua contexto de negócio
Um log puramente técnico pode ser insuficiente.
Exemplo técnico:
SQLCODE=-803
Exemplo enriquecido:
OPERACAO=CADASTRO-CLIENTE
RESULTADO=DUPLICIDADE
SQLCODE=-803
CLIENTE=000123456
Agora a equipe de negócio também entende o impacto.
Curiosidades do arquivo secreto
Curiosidade 1 — O mainframe já praticava observabilidade antes do termo ficar famoso
Muito antes de OpenTelemetry e microsserviços, ambientes mainframe já utilizavam:
O nome moderno mudou, mas a necessidade sempre existiu.
Curiosidade 2 — Um log pode causar o problema que tenta investigar
Logging excessivo pode aumentar:
I/O;
CPU;
armazenamento;
latência;
contenção.
Em alguns incidentes, ativar logging detalhado em produção piora o desempenho.
É como acender tantas luzes na cena do crime que o gerador elétrico entra em colapso.
Curiosidade 3 — Tracing completo pode ser caro
Registrar cada requisição em sistemas de altíssimo volume produz enormes quantidades de dados.
Por isso usamos sampling.
Sampling significa coletar apenas uma amostra.
Exemplo:
Coletar 1% dos traces normais.
Coletar 100% dos traces com erro.
Coletar 100% dos traces acima de 2 segundos.
Essa estratégia reduz custo sem perder sinais importantes.
Curiosidade 4 — O usuário percebe o P99
A equipe técnica pode comemorar uma média de 200 milissegundos.
Mas o cliente que recebeu uma resposta em oito segundos não se importa com a média.
Para ele, o sistema foi lento.
É por isso que percentis são tão importantes.
Easter eggs para o Padawan
Primeiro easter egg:
Quando um sistema apresenta erros intermitentes, lembre-se do cão que não latiu.
Em uma famosa investigação de Sherlock Holmes, a ausência de uma reação foi a pista principal.
Na observabilidade também precisamos analisar o que não aconteceu.
Exemplo:
o programa iniciou, mas não registrou o fim;
a mensagem entrou na fila, mas não saiu;
houve chamada ao Db2, mas não houve commit;
o serviço recebeu a requisição, mas não retornou resposta.
A ausência de um evento esperado pode ser mais importante do que um erro explícito.
Segundo easter egg:
Se encontrar a identificação 221B em algum exemplo de Trace ID, não é coincidência.
TRACE-ID=221B-BAKER-STREET
Terceiro easter egg:
Todo investigador de sistemas deveria desconfiar da frase:
“Não mudamos nada.”
Quase sempre alguma coisa mudou:
Mesmo quando o código não mudou, o ambiente pode ter mudado.
O método Sherlock Holmes aplicado à produção
Podemos adaptar o método investigativo em sete etapas.
1. Observar
Colete evidências sem tirar conclusões prematuras.
2. Estabelecer a linha do tempo
Descubra quando o comportamento começou.
3. Correlacionar
Relacione logs, métricas, traces e mudanças recentes.
4. Formular hipóteses
Exemplo:
A lentidão pode estar sendo causada pela fila MQ.
5. Testar
Verifique profundidade da fila, consumidor e tempo de espera.
6. Eliminar hipóteses impossíveis
Se o Db2 respondeu em 20 milissegundos, provavelmente não é o gargalo principal.
7. Confirmar causa raiz
Não pare no primeiro sintoma.
Fila cheia é sintoma.
Consumidor indisponível pode ser a causa.
Certificado expirado no consumidor pode ser a causa raiz.
Conclusão — O sistema sempre deixa pegadas
Quando entramos no CPD, tínhamos apenas uma reclamação:
“O sistema está lento.”
Depois da investigação, descobrimos que essa frase escondia uma cadeia de evidências.
As métricas mostraram que a latência aumentava.
Os traces revelaram em qual componente o tempo era consumido.
Os logs explicaram o erro.
O identificador de correlação conectou todas as etapas.
O alerta chamou a equipe.
O runbook orientou a resposta.
E a revisão posterior transformou o incidente em aprendizado.
Esse é o verdadeiro valor da observabilidade.
Logging, tracing e metrics não são três tecnologias isoladas.
São três testemunhas.
Cada uma viu uma parte do caso.
O log afirma:
“Eu sei o que aconteceu.”
A métrica declara:
“Eu sei com que frequência e intensidade aconteceu.”
O trace completa:
“Eu sei por onde a requisição passou.”
Quando as três testemunhas são interrogadas juntas, o sistema deixa de ser uma caixa-preta.
Para o programador COBOL iniciante, a grande lição é simples: não escreva programas que apenas processem dados. Escreva programas capazes de explicar o próprio comportamento.
Registre o início.
Registre o fim.
Registre a etapa.
Registre o código de retorno.
Meça o tempo.
Conte os registros.
Propague um identificador.
Proteja dados sensíveis.
Produza evidências úteis.
Porque, quando o incidente acontecer às 02h17 da manhã — e algum dia ele acontecerá — você não desejará encontrar apenas um DISPLAY 'DEU ERRO' abandonado no spool.
Você desejará encontrar uma trilha completa de pegadas digitais.
Sherlock Holmes fechou o relatório, tomou o último gole de café e olhou para o jovem programador COBOL.
— Agora entende?
— Acho que sim. Observabilidade é descobrir o que o sistema está tentando nos contar.
O investigador sorriu.
— Não exatamente.
— Então o que é?
— É garantir que, quando o sistema falar, ele tenha algo útil a dizer.
No monitor principal, a transação voltou ao tempo normal.
O alerta vermelho desapareceu.
E, em algum lugar entre o CICS, o Db2 e uma fila MQ, um pequeno Trace ID chamado 221B-BAKER-STREET continuou seguindo silenciosamente as pegadas da próxima requisição.
