 |
| Bellacosa Mainframe em revisao observabilidade muito alem do grafana |
☕ Um Café no Bellacosa Mainframe
Observabilidade Muito Além do Grafana
O Que Todo Programador COBOL Padawan Precisa Saber Sobre Prometheus, Grafana, Loki, ELK, Zabbix, OpenTelemetry e Como os Grandes Bancos Descobrem Problemas Antes que os Clientes Percebam
"Durante décadas, quem trabalhava com Mainframe aprendia uma regra simples: se o sistema caiu, alguém vai ligar em menos de cinco minutos. Na era do Kubernetes, dos microsserviços e da nuvem, essa regra mudou. O objetivo agora é descobrir o problema antes mesmo que o telefone toque."
Introdução
Se você é um Programador COBOL Padawan e passou boa parte da carreira trabalhando com IBM Z, CICS, DB2, IMS, MQ, JCL, JES2, SDSF e RACF, provavelmente já ouviu alguém dizer:
"Agora usamos Grafana."
Ou então:
"Precisamos colocar Prometheus."
Ou ainda:
"Os logs estão no Loki."
E a primeira reação costuma ser:
"Mais um monte de ferramentas..."
Na verdade, não.
O que mudou não foi o problema.
Mudaram apenas as ferramentas utilizadas para resolvê-lo.
Desde a década de 1960, administradores de sistemas possuem exatamente as mesmas preocupações:
O servidor está funcionando?
Existe gargalo?
A CPU está sobrecarregada?
A memória acabou?
O banco está lento?
O programa entrou em loop?
Quem provocou o incidente?
Como evitar que aconteça novamente?
No Mainframe existiam RMF, SMF, SYSLOG, OMEGAMON, SDSF, Tivoli, NetView e System Automation.
Na computação em nuvem surgiram Prometheus, Grafana, Loki, OpenTelemetry, Tempo, Jaeger, Elastic Stack e dezenas de outras soluções.
O conceito continua exatamente o mesmo.
A diferença é que agora estamos monitorando milhares de microsserviços distribuídos em centenas de servidores que podem nascer e desaparecer em segundos.
Vamos tomar um café e entender essa evolução.
O maior erro de quem começa em DevOps
Muita gente acredita que Grafana é uma ferramenta de monitoramento.
Não é.
Outros imaginam que Prometheus cria dashboards.
Também não.
Há quem pense que Loki substitui um banco de dados.
Novamente, não.
Essas ferramentas fazem parte de uma disciplina muito maior chamada Observabilidade.
E esse é um conceito extremamente importante.
Monitoramento x Observabilidade
Imagine que você trabalha em um banco.
Às 10h15 da manhã começam centenas de reclamações.
Clientes não conseguem fazer PIX.
O monitoramento informa apenas:
API PIX
Status:
DOWN
Ótimo.
Sabemos que existe um problema.
Mas...
Por quê?
Agora entra a observabilidade.
Ela responde algo como:
CPU
↓
95%
↓
Garbage Collector executando
↓
Banco de Dados respondeu lentamente
↓
Fila Kafka acumulou mensagens
↓
Timeout
↓
Clientes começaram a receber erro
Percebe a diferença?
Monitoramento responde:
Existe um problema.
Observabilidade responde:
Por que ele aconteceu.
A analogia perfeita para quem vem do Mainframe
Vamos traduzir tudo isso para o universo IBM Z.
| Mundo Mainframe | Mundo Cloud Native |
|---|---|
| RMF | Prometheus |
| SMF | Metrics |
| SYSLOG | Logs |
| OMEGAMON | Grafana |
| SDSF | Grafana + Loki |
| NetView | Alertmanager |
| Tivoli Monitoring | Prometheus + Grafana |
| System Automation | Alertmanager + Kubernetes |
Ou seja...
Você já conhece praticamente todos os conceitos.
Apenas os nomes mudaram.
Os três pilares da Observabilidade
Existe uma regra que todo profissional de SRE conhece.
Uma infraestrutura moderna precisa de três tipos de informação.
Pilar 1 — Métricas
São números.
Apenas números.
Exemplos:
CPU
67%
Memória
12 GB
Disco
81%
Latência
95 ms
Requests
3500/s
Essas informações ocupam pouco espaço.
São rápidas.
Podem ser armazenadas durante anos.
É exatamente esse tipo de dado que o Prometheus coleta.
Pilar 2 — Logs
Agora imagine um extrato bancário.
Cliente iniciou login
↓
Senha válida
↓
Consultou saldo
↓
Transferência
↓
PIX
↓
Logout
Isso é um log.
Ele conta uma história.
Enquanto métricas dizem:
CPU = 89%
O log diz:
NullPointerException
Arquivo não encontrado
Timeout DB2
Usuário autenticado
Transação cancelada
Os logs ocupam muito mais espaço.
Mas possuem riqueza de detalhes.
Pilar 3 — Traces
Este é o mais moderno dos três pilares.
Imagine um PIX.
Ele passa por vários componentes.
Aplicativo
↓
API Gateway
↓
Autenticação
↓
Pagamento
↓
Banco
↓
Kafka
↓
Resposta
Cada etapa possui tempo.
O Trace mostra exatamente onde ocorreu a lentidão.
É como colocar um GPS dentro da requisição.
Ferramentas:
Jaeger
Tempo
OpenTelemetry
Afinal, o que é o Prometheus?
O Prometheus nasceu na SoundCloud.
Hoje é um projeto da CNCF.
Praticamente todo cluster Kubernetes utiliza Prometheus.
Mas afinal...
O que ele faz?
Resposta curta:
Coleta métricas.
Só isso.
Não cria dashboards.
Não armazena logs.
Não faz visualizações bonitas.
Ele apenas pergunta continuamente aos servidores:
Como você está?
O modelo Pull
Esse detalhe é extremamente importante.
Prometheus trabalha com Pull.
Ou seja...
Ele vai até o servidor.
Prometheus
↓
Servidor Linux
↓
Qual sua CPU?
Servidor responde:
cpu_usage 63.4
Depois de alguns segundos...
Pergunta novamente.
cpu_usage 65.8
Depois novamente.
cpu_usage 67.9
Assim nasce uma série temporal.
Time Series Database
O banco interno do Prometheus é especializado em séries temporais.
Cada informação possui:
Valor
+
Data
+
Hora
Por exemplo:
10:00
CPU 20%
10:05
CPU 32%
10:10
CPU 48%
10:15
CPU 80%
O interessante não é apenas o valor.
É enxergar sua evolução.
Exporters
Prometheus não entende tudo sozinho.
Ele utiliza Exporters.
Imagine-os como tradutores.
Linux?
Node Exporter.
Windows?
Windows Exporter.
MySQL?
MySQL Exporter.
PostgreSQL?
Postgres Exporter.
Redis?
Redis Exporter.
Kafka?
Kafka Exporter.
Nginx?
Nginx Exporter.
Apache?
Apache Exporter.
Até equipamentos de rede podem ser monitorados utilizando SNMP Exporter.
No mundo IBM Z também existem integrações específicas para expor métricas de z/OS, CICS, Db2 e MQ para plataformas modernas de observabilidade.
PromQL — A linguagem do Prometheus
Um dos maiores diferenciais do Prometheus é sua linguagem de consultas.
PromQL.
Imagine perguntar:
"Qual foi a média de CPU dos últimos cinco minutos?"
Ou:
"Quantas requisições HTTP ocorreram por segundo?"
Ou:
"Qual o percentil 95 da latência?"
Tudo isso pode ser respondido utilizando PromQL.
É uma linguagem extremamente poderosa e indispensável para quem trabalha com SRE.
Grafana — Muito além dos gráficos bonitos
Existe uma frase famosa:
Prometheus coleta.
Grafana apresenta.
Essa frase resume bem o papel do Grafana.
Ele não coleta nada.
Ele apenas conecta diversas fontes de dados.
Pode consultar:
Prometheus
Loki
Elasticsearch
Oracle
SQL Server
PostgreSQL
MySQL
InfluxDB
OpenSearch
Tempo
Jaeger
CloudWatch
Azure Monitor
Google Cloud Monitoring
E transformar tudo isso em painéis extremamente intuitivos.
O painel do NOC
Imagine entrar em um Centro de Operações.
Existe um enorme telão.
Você vê:
CPU
Memória
Disco
Rede
APIs
Kubernetes
Bancos
Filas MQ
Kafka
Tempo de resposta
Quantidade de usuários
Tudo atualizado em tempo real.
Esse telão normalmente é Grafana.
Dashboards inteligentes
Um bom dashboard não serve apenas para mostrar gráficos.
Ele ajuda a responder perguntas.
Exemplo:
Por que a CPU aumentou?
Clique.
Agora veja somente aquele servidor.
Clique novamente.
Veja apenas aquele Pod.
Clique outra vez.
Agora visualize os logs.
Depois os traces.
Esse processo chama-se Drill Down.
É uma investigação guiada.
Loki — O banco de logs da Grafana Labs
Se Prometheus trabalha com métricas...
Loki trabalha com logs.
Mas existe uma diferença enorme entre Loki e Elasticsearch.
ELK tradicional
No Elastic Stack, praticamente todo o conteúdo do log é indexado.
Isso torna a pesquisa extremamente rápida.
Mas também exige muito armazenamento.
Grandes ambientes podem consumir dezenas de terabytes.
Loki
O Loki segue uma filosofia diferente.
Ele indexa apenas Labels.
Por exemplo:
Namespace
backend
Pod
payment-api
Container
java
O texto completo permanece compactado.
Resultado?
Muito menos espaço.
Muito menos custo.
Por isso Loki tornou-se extremamente popular em Kubernetes.
LogQL
Assim como Prometheus possui PromQL...
Loki possui LogQL.
Você pode perguntar:
Mostre todos os logs do namespace financeiro.
Ou:
Procure apenas mensagens ERROR.
Ou:
Mostre todos os Timeout DB2.
A sintaxe é bastante intuitiva.
Elastic Stack — O gigante da busca textual
Nem sempre Loki é a melhor escolha.
Imagine uma instituição financeira.
Milhões de logs por dia.
Auditoria.
LGPD.
Compliance.
Fraudes.
Pesquisas complexas.
Nesse cenário o Elastic Stack continua sendo excelente.
Ele é composto por:
Elasticsearch
Logstash
Kibana
Em muitas empresas modernas o Logstash foi substituído por Beats ou Elastic Agent.
Também existe o OpenSearch, derivado do Elasticsearch, bastante utilizado como alternativa open source.
Zabbix — O veterano que continua forte
Antes do Kubernetes dominar o mercado, muitas empresas já utilizavam Zabbix.
Ele continua extremamente relevante.
Especialmente para:
Switches
Roteadores
Firewalls
Impressoras
Servidores físicos
Máquinas virtuais
UPS
Storage
Bancos de dados
Ambientes híbridos
Enquanto Prometheus nasceu para ambientes dinâmicos e cloud native, Zabbix continua brilhando em infraestruturas tradicionais.
OpenTelemetry — A linguagem universal da observabilidade
Nos últimos anos surgiu um novo protagonista.
OpenTelemetry.
Ele não substitui Prometheus.
Nem Grafana.
Nem Loki.
Ele cria um padrão.
Imagine uma aplicação Java.
Outra em Go.
Outra em Python.
Outra em COBOL acessando uma API via z/OS Connect.
Como todas enviarão métricas, logs e traces?
OpenTelemetry resolve esse problema.
Ele padroniza a instrumentação.
É como um tradutor universal.
Alertmanager — Quando o problema precisa encontrar você
Monitorar é importante.
Mas ninguém fica olhando dashboards vinte e quatro horas por dia.
Quando algo acontece...
O Alertmanager entra em ação.
Ele pode enviar notificações para:
Slack
Microsoft Teams
Telegram
Discord
PagerDuty
Opsgenie
E-mail
SMS
Muito parecido com o papel desempenhado pelo IBM System Automation e pelo NetView em ambientes Mainframe.
O fluxo completo da observabilidade
Imagine um microsserviço Java executando em Kubernetes.
O fluxo típico será:
Aplicação
↓
Exporta métricas
↓
Prometheus
↓
Grafana
Ao mesmo tempo:
Aplicação
↓
Logs
↓
Fluent Bit
↓
Loki
↓
Grafana
E também:
Aplicação
↓
OpenTelemetry
↓
Collector
↓
Tempo
↓
Grafana
Observe algo interessante.
Tudo converge para o Grafana.
Ele torna-se a porta de entrada para toda a operação.
Um exemplo real em um grande banco
Imagine um Internet Banking durante o pagamento de salários.
Milhões de transações.
Subitamente o tempo de resposta aumenta.
O que acontece?
Primeiro...
Prometheus detecta aumento de CPU.
Depois...
Grafana mostra crescimento da latência.
Logo em seguida...
Alertmanager envia alerta para a equipe.
Os operadores acessam Loki.
Descobrem centenas de mensagens:
Timeout DB2
Os traces mostram que todas as requisições lentas passam pelo mesmo microsserviço.
A equipe reinicia apenas aquele componente.
O problema desaparece.
Tudo isso pode acontecer em poucos minutos.
Antes mesmo de milhares de clientes perceberem.
E no Mainframe?
Muita gente imagina que observabilidade pertence apenas à nuvem.
Não é verdade.
IBM Z possui uma enorme quantidade de dados operacionais.
SMF Records.
RMF.
OMEGAMON.
CICS Performance Analyzer.
Db2 Statistics.
IMS Monitor.
MQ Statistics.
Essas informações podem ser integradas com Prometheus, Grafana e OpenTelemetry.
Hoje é perfeitamente possível construir dashboards que apresentam lado a lado:
CPU do z/OS
Consumo do CICS
Threads do Java
Pods Kubernetes
APIs REST
Banco PostgreSQL
Db2 for z/OS
Tudo na mesma tela.
Essa convergência é uma das maiores tendências da observabilidade corporativa.
O caminho recomendado para um COBOL Padawan
Se você está começando nessa área, minha recomendação é seguir uma trilha progressiva:
Entenda o conceito de observabilidade.
Aprenda a diferença entre métricas, logs e traces.
Estude Prometheus e PromQL.
Domine Grafana e criação de dashboards.
Aprenda Loki e LogQL.
Conheça Alertmanager.
Estude OpenTelemetry.
Explore Tempo e Jaeger.
Conheça Elastic Stack e OpenSearch.
Aprenda como tudo isso se integra ao Kubernetes.
Essa sequência faz muito mais sentido do que tentar aprender todas as ferramentas ao mesmo tempo.
Muito além das ferramentas
Talvez a maior lição deste café seja perceber que observabilidade não é um produto, mas uma forma de pensar.
O profissional moderno não espera o usuário reclamar. Ele cria sistemas capazes de revelar tendências, antecipar falhas e explicar, com precisão, por que uma aplicação está degradando.
Quem trabalhou anos com IBM Z já conhece essa mentalidade. Sempre houve preocupação com disponibilidade, desempenho, capacidade e diagnóstico. O que mudou foi a escala. Em vez de monitorar um único computador central altamente estável, hoje monitoramos milhares de contêineres efêmeros, APIs, filas de mensagens e bancos distribuídos que surgem e desaparecem em segundos.
Ferramentas como Prometheus, Grafana, Loki, OpenTelemetry, Tempo, Jaeger, Elastic Stack e Zabbix representam a evolução natural desse processo. Elas não substituem os conceitos que fizeram do Mainframe uma referência mundial em confiabilidade; elas os expandem para um ambiente distribuído, dinâmico e orientado a microsserviços.
Para o Programador COBOL Padawan, aprender observabilidade é muito mais do que decorar comandos ou instalar dashboards. É compreender como uma transação percorre toda a arquitetura, como interpretar sinais de degradação antes que se transformem em incidentes e como utilizar dados para tomar decisões técnicas com rapidez e segurança.
No fim das contas, a missão continua a mesma de cinquenta anos atrás: manter sistemas críticos funcionando com excelência. A diferença é que agora contamos com uma caixa de ferramentas muito mais rica, integrada e inteligente. Quem domina observabilidade deixa de apenas reagir a problemas e passa a antecipá-los, tornando-se um profissional indispensável em qualquer equipe de Engenharia de Software, DevOps, SRE ou Modernização de Mainframe.
Porque, seja em um IBM Z processando milhões de transações CICS por segundo ou em um cluster Kubernetes espalhado por dezenas de nós, a pergunta continua sendo a mesma:
"O sistema está saudável?"
E a observabilidade moderna finalmente nos permite responder não apenas "sim" ou "não", mas também "por quê", "desde quando", "qual componente foi afetado" e, o mais importante, "como evitar que isso aconteça novamente".
Esse é o verdadeiro poder da observabilidade. Esse é o próximo passo na jornada de todo Programador COBOL Padawan rumo à engenharia de software moderna.
