 |
| Bellacosa Mainframe apresenta o Prometheus |
☕ Um Café no Bellacosa Mainframe
🧝♀️ GALADRIEL E O ESPELHO DE PROMETHEUS
Métricas, exporters, targets, PromQL, Grafana, Alertmanager, observabilidade e a antiga arte de descobrir que a produção estava morrendo antes que o telefone tocasse.
Há sistemas que anunciam sua queda com trombetas.
Há outros que simplesmente morrem.
E existem os mais perigosos: aqueles que continuam aparentemente vivos enquanto, lentamente, alguma coisa começa a apodrecer por dentro.
Uma fila cresce. A latência aumenta. Uma aplicação começa a devolver mais erros. Um processo batch demora alguns minutos a mais todos os dias. A CPU parece normal. O CICS continua respondendo. O Db2 está UP. Nenhum job terminou com CC 0012.
Ainda assim, alguma coisa está errada.
Se estivéssemos em Lothlórien, talvez Galadriel nos conduzisse até seu espelho e dissesse:
“O espelho mostra muitas coisas. Coisas que foram, coisas que são e algumas coisas que ainda podem acontecer.”
No nosso reino, entretanto, não temos o Espelho de Galadriel.
Temos Prometheus.
E talvez isso seja até melhor, porque Prometheus não trabalha com profecias.
Ele trabalha com métricas.
🎬 PRÓLOGO — GALADRIEL OLHA PARA PRODUÇÃO
Imagine que você seja um programador COBOL iniciante.
Você escreveu seu programa, compilou, link-editou, submeteu o JCL e recebeu:
IEF142I JOB001 STEP01 - STEP WAS EXECUTED - COND CODE 0000Maravilha!
Funcionou.
Só existe um pequeno problema.
Isso não significa que o sistema esteja saudável.
Um programa pode terminar com CC 0000 e consumir recursos demais.
Uma transação pode funcionar e levar quatro segundos.
Um serviço pode estar disponível enquanto 8% das requisições estão falhando.
Uma fila MQ pode estar funcionando perfeitamente enquanto cresce mais rapidamente do que os consumidores conseguem processá-la.
Uma aplicação pode estar tecnicamente UP e praticamente inutilizável.
É nesse momento que precisamos distinguir duas ideias:
FUNCIONAR
e
ESTAR SAUDÁVELSão coisas diferentes.
Prometheus existe justamente para nos ajudar a observar essa segunda dimensão.
🧝 CAPÍTULO 1 — “VOCÊ NÃO PODE CORRIGIR AQUILO QUE NÃO CONSEGUE VER”
Antes de estudar Prometheus, precisamos falar de observabilidade.
Monitoramento tradicional normalmente pergunta:
CPU está alta?
Memória acabou?
Servidor está UP?
Banco está disponível?
Fila está cheia?São perguntas importantes.
Observabilidade tenta responder perguntas maiores:
O que aconteceu?
Quando começou?
Onde aconteceu?
Quem foi afetado?
Por que aconteceu?
Está piorando?
Qual componente provavelmente participa do problema?Uma forma didática muito usada para apresentar observabilidade fala em três grandes sinais:
METRICS
LOGS
TRACESPodemos pensar assim:
Metrics mostram numericamente o comportamento do sistema.
Logs registram acontecimentos e detalhes.
Traces acompanham o caminho de uma operação através de vários componentes.
Imagine uma transação:
Cliente
↓
API
↓
MQ
↓
CICS
↓
COBOL
↓
Db2Uma métrica pode dizer:
latência p95 = 2,4 segundosO log pode mostrar:
SQLCODE -911E um trace pode revelar que a maior parte daqueles 2,4 segundos aconteceu no acesso ao banco.
Agora começamos a enxergar o sistema.
💍 CAPÍTULO 2 — OS QUATRO SINAIS DOURADOS
Na literatura de SRE aparece frequentemente a ideia dos Four Golden Signals:
Latency
Traffic
Errors
SaturationPara quem vem de mainframe, os nomes podem ser modernos, mas o raciocínio é muito familiar.
Latency
Quanto tempo algo demora?
CICS transaction response time
API response time
SQL elapsed time
batch elapsed timeTraffic
Quanto trabalho estamos recebendo?
transactions/sec
requests/sec
messages/sec
jobs/hourErrors
Quanto está falhando?
HTTP 500
ABENDs
SQL errors
MQ failures
rejected transactionsSaturation
Quanto estamos nos aproximando do limite?
CPU
memory
connections
threads
queue depth
storageAqui existe uma lição importante.
CPU alta não significa automaticamente problema.
Imagine:
CPU = 91%
Latency = normal
Errors = normal
Traffic = altíssimoTalvez a máquina simplesmente esteja trabalhando bastante.
Agora imagine:
CPU = 42%
Latency = 8 segundos
Errors = crescendo
Traffic = normalTemos provavelmente algo muito mais preocupante.
O número isolado raramente conta a história inteira.
🔥 CAPÍTULO 3 — AFINAL, O QUE É PROMETHEUS?
Prometheus é um sistema open source para monitoramento e alertas baseado principalmente em métricas de séries temporais.
Podemos resumir sua missão assim:
COLETAR
↓
ARMAZENAR
↓
CONSULTAR
↓
AVALIAR
↓
ALERTARA palavra importante aqui é:
tempo.
Imagine simplesmente:
CPU = 84%Esse número tem pouca informação.
Agora:
10:00 CPU 31%
10:01 CPU 38%
10:02 CPU 47%
10:03 CPU 63%
10:04 CPU 84%
10:05 CPU 96%A situação mudou completamente.
Não temos apenas um valor.
Temos uma história.
E Prometheus é, em grande parte, uma máquina especializada em guardar e consultar essas histórias numéricas.
🕰️ CAPÍTULO 4 — TIME SERIES: O TEMPO CONTA A HISTÓRIA
Considere:
mq_queue_depth = 1400Ruim?
Depende.
Talvez aquela fila normalmente tenha 5.000 mensagens.
Agora veja:
03:13 17
03:14 22
03:15 51
03:16 194
03:17 830
03:18 1.402
03:19 2.917Agora temos uma história bastante diferente.
Às 03:17, alguma coisa aconteceu.
Sim, jovem padawan do COBOL: você encontrou o pequeno easter egg escondido no SYSOUT. ☕
Talvez o produtor tenha aumentado o ritmo.
Talvez um consumidor tenha parado.
Talvez alguma dependência esteja lenta.
Prometheus não sabe necessariamente a causa.
Mas agora temos uma pista extremamente importante:
QUANDO?Esse é um dos maiores valores das séries temporais.
🏷️ CAPÍTULO 5 — LABELS: OS NOMES SECRETOS DAS COISAS
Suponha que tenhamos:
cics_transactions_totalInteressante.
Mas podemos enriquecer:
cics_transactions_total{
region="CICSPROD",
transaction="PAY1",
status="success"
}Os valores entre {} são labels.
Agora podemos perguntar:
transações por região
transações por status
transações por aplicação
transações por ambienteIsso é poderosíssimo.
Porém Galadriel provavelmente levantaria uma sobrancelha e diria:
“Nem todas as labels deveriam ter sido criadas.”
Porque existe um monstro chamado:
💣 CARDINALIDADE
Imagine:
payment_total{
channel="mobile",
status="approved"
}Perfeito.
Existem poucos canais e poucos status.
Agora alguém tem a brilhante ideia:
payment_total{
customer_id="123456789",
transaction_id="982737283928382"
}Catástrofe em potencial.
Cada combinação diferente de labels pode criar outra série temporal.
Milhões de clientes multiplicados por milhões de transações podem gerar uma quantidade gigantesca de séries.
Portanto:
Label não é campo de banco de dados.
Não coloque tudo nela.
Esse é um dos conhecimentos que separa quem simplesmente instalou Prometheus de quem começou realmente a entendê-lo.
🧙 CAPÍTULO 6 — EXPORTERS: OS INTÉRPRETES ENTRE OS REINOS
Nem todo sistema nasceu sabendo falar Prometheus.
É aí que entram os exporters.
Um exporter obtém informações de determinado sistema e as apresenta de uma maneira que Prometheus consegue coletar.
Exemplo:
Linux
↓
Node Exporter
↓
/metrics
↑
PrometheusTemos exporters para diferentes tecnologias e também podemos desenvolver exporters específicos.
Essa arquitetura é particularmente interessante para legado.
Imagine:
IBM Z
├── CICS
├── Db2
├── MQ
├── JES2
└── z/OS
↓
coleta/adaptação
↓
Custom Exporter
↓
/metrics
↑
PrometheusPense no exporter como um tradutor.
O sistema pode continuar falando sua língua ancestral.
O exporter traduz os dados relevantes para o idioma esperado pelo ecossistema Prometheus.
🎯 CAPÍTULO 7 — EXPORTER NÃO É TARGET
Aqui aparece uma confusão comum.
Exporter é o software/adaptador que expõe métricas.
Target é o endpoint que Prometheus vai coletar.
Por exemplo:
server01:9100
server02:9100
server03:9100podem ser targets.
E normalmente Prometheus encontrará ali:
/metricsPortanto:
TARGET
↓
endpoint monitorado
EXPORTER
↓
componente que expõe métricasUma aplicação também pode implementar /metrics diretamente.
Nesse caso:
Application
↓
/metrics
↑
PrometheusNão precisamos necessariamente colocar outro exporter entre eles.
🧲 CAPÍTULO 8 — PROMETHEUS PUXA AS MÉTRICAS
Uma característica famosa do Prometheus é seu modelo predominantemente pull.
Em termos simplificados:
Prometheus
|
| HTTP GET
↓
http://server:9100/metricsEle pergunta:
“Quais são seus números agora?”
O target responde.
Depois Prometheus volta novamente.
E novamente.
Isso é chamado de scraping.
Imagine:
15 segundos
↓
scrape
15 segundos
↓
scrape
15 segundos
↓
scrapeO intervalo depende da configuração.
Existe suporte para cenários de push, particularmente através do Pushgateway para determinados workloads de curta duração, mas compreender o modelo pull primeiro ajuda muito.
📜 CAPÍTULO 9 — prometheus.yml: O JCL DO REINO
Agora chegamos a uma parte que fará qualquer mainframer sorrir.
Prometheus precisa saber:
o que coletar
onde coletar
com qual frequência
como organizarGrande parte disso aparece no:
prometheus.ymlExemplo simplificado:
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
- job_name: "linux"
static_configs:
- targets:
- "server01:9100"
- "server02:9100"Um mainframer olha para isso e imediatamente pensa:
“Então esse YAML está dizendo ao Prometheus qual trabalho executar.”
Exatamente.
Não é literalmente JCL, mas conceitualmente a analogia ajuda:
JCL
↓
descreve execução
prometheus.yml
↓
descreve comportamento de coleta/configuraçãoCuidado apenas para não levar a analogia longe demais.
🧭 CAPÍTULO 10 — SERVICE DISCOVERY
Targets fixos funcionam bem quando temos:
server01
server02
server03Mas imagine Kubernetes.
Agora:
10 podsCinco minutos depois:
27 podsMais tarde:
8 podsSeria absurdo alguém editar manualmente prometheus.yml a cada mudança.
Entra então Service Discovery.
Prometheus pode descobrir dinamicamente os targets através de mecanismos de descoberta.
Conceitualmente:
Kubernetes
↓
Service Discovery
↓
Prometheus descobre targets
↓
scrapingEsse conceito é fundamental em cloud-native porque a infraestrutura deixou de ser necessariamente estática.
O servidor deixou de ser um castelo.
Passou a ser quase uma barraca de campanha: aparece, trabalha e desaparece.
📦 CAPÍTULO 11 — COUNTER: O CONTADOR QUE SÓ SABE AVANÇAR
Primeiro tipo fundamental de métrica:
Counter.
Exemplo:
http_requests_totalEle cresce:
100
101
105
120
180Normalmente só volta para baixo quando o processo reinicia.
Excelente para:
requests
transactions
errors
jobs completed
messages processedMas existe uma armadilha.
Perguntar:
http_requests_total = 938.281.293não é muito útil.
Você quer saber:
“Quão rapidamente isso está crescendo?”
E então aparece PromQL.
🌊 CAPÍTULO 12 — rate(): A VELOCIDADE DO RIO
Imagine:
rate(http_requests_total[5m])Estamos aproximadamente perguntando pela taxa média de crescimento por segundo naquele intervalo.
Se:
resultado = 150podemos interpretar, dentro daquele contexto, algo como:
150 requests/sPara CICS poderíamos imaginar:
rate(cics_transactions_total[5m])Agora temos algo semelhante a TPS.
Essa é uma transformação importantíssima:
COUNTER
↓
rate()
↓
VELOCIDADE📈 CAPÍTULO 13 — increase(): QUANTO CRESCEU?
Outra função extremamente útil:
increase(http_requests_total[1h])Pergunta conceitualmente:
Quanto esse counter aumentou durante uma hora?
Compare:
rate()
→ ritmo
increase()
→ aumento no períodoUma analogia simples:
velocímetro → rate()
odômetro percorrido na viagem → increase()🌡️ CAPÍTULO 14 — GAUGE: O TERMÔMETRO
Gauge pode aumentar e diminuir.
Exemplos:
CPU
memory
temperature
active connections
queue depth
active tasksImagine MQ:
mq_queue_depthValores:
08:00 14
08:01 17
08:02 25
08:03 81
08:04 320
08:05 982Isso não prova sozinho qual é o problema.
Mas é um indício espetacular.
O produtor pode estar produzindo mais rapidamente.
O consumidor pode ter ficado lento.
O consumidor pode ter parado.
Alguma dependência pode estar congestionada.
A métrica é a pista.
A investigação continua.
📊 CAPÍTULO 15 — HISTOGRAM: A MÉDIA PODE MENTIR
Imagine tempos de resposta:
20 ms
22 ms
23 ms
25 ms
26 ms
29 ms
32 ms
4.000 msCalcular somente a média pode esconder uma experiência terrível para uma parcela dos usuários.
Por isso observabilidade fala tanto em:
p50
p90
p95
p99Se dissermos:
p95 = 800 msestamos falando aproximadamente do valor abaixo do qual ficaram 95% das observações.
Histograms organizam observações em buckets e permitem estudar a distribuição.
Isso é extremamente útil para:
latência
tamanho de payload
tempo de processamento🧮 CAPÍTULO 16 — SUMMARY: PARECIDO, MAS NÃO IGUAL
Summary também trabalha com distribuições e quantis.
A diferença arquitetural importante é que summaries tradicionalmente calculam quantis no cliente, enquanto histograms expõem dados que permitem ao Prometheus trabalhar posteriormente com a distribuição.
Isso tem consequência em ambientes distribuídos.
Imagine:
100 instânciasQueremos calcular:
p95 globalHistograms normalmente são muito mais apropriados para agregação entre várias instâncias.
Não escolha Summary simplesmente porque o nome parece mais simpático.
🔮 CAPÍTULO 17 — PROMQL: A LÍNGUA DO ESPELHO
Agora chegamos ao coração intelectual da coisa.
PromQL é a linguagem de consulta do Prometheus.
Ela permite selecionar, filtrar, combinar e agregar séries temporais.
Por exemplo:
rate(http_requests_total[5m])Ou:
sum by(service)(
rate(http_requests_total[5m])
)Agora perguntamos:
Quantas requisições por segundo cada serviço está processando?
Podemos filtrar labels:
http_requests_total{environment="prod"}Ou:
http_requests_total{
environment="prod",
status="500"
}Aqui Prometheus deixa de ser simplesmente coletor.
Ele vira ferramenta investigativa.
⚠️ CAPÍTULO 18 — PROMQL CORRETA PODE RESPONDER A PERGUNTA ERRADA
Essa é uma das melhores lições escondidas nas imagens.
Imagine alguém escrevendo:
avg(http_request_duration_seconds)e dizendo:
“Essa é a latência média.”
Calma.
Primeiro precisamos entender que métrica é essa.
Gauge?
Histogram?
Summary?
Qual dimensão?
Qual intervalo?
O mesmo problema aparece em exemplos de CPU.
Algo como:
rate(node_cpu_seconds_total[5m]) > 80não significa automaticamente:
CPU > 80%node_cpu_seconds_total representa segundos acumulados de CPU separados por modos.
Uma consulta mais típica para utilização pode partir da proporção de idle:
100 *
(
1 -
avg by(instance)(
rate(node_cpu_seconds_total{mode="idle"}[5m])
)
)A lição vale ouro:
Query que executa sem erro não é necessariamente query correta.
COBOLers conhecem muito bem esse fenômeno.
Um programa pode terminar:
CC 0000e ainda assim produzir o resultado errado.
PromQL não é diferente.
🧠 CAPÍTULO 19 — RECORDING RULES: AS MATERIALIZED VIEWS DO PROMETHEUS
Imagine uma consulta PromQL pesada utilizada por vinte dashboards.
Executá-la constantemente pode ser caro.
Podemos criar uma Recording Rule.
Conceitualmente:
RAW METRICS
↓
PROMQL COMPLEXA
↓
RECORDING RULE
↓
NOVA TIME SERIESIsso lembra bastante uma:
MATERIALIZED VIEWde banco de dados.
Você calcula antecipadamente algo que será consultado frequentemente.
Resultado:
dashboards mais rápidos
queries mais simples
menor trabalho repetitivo🚨 CAPÍTULO 20 — ALERTING RULES: QUANDO O ESPELHO GRITA
Agora queremos transformar observação em ação.
Uma Alerting Rule pode expressar:
SE condição acontecer
E persistir
ENTÃO gere alertaExemplo conceitual:
alert: HighLatency
expr: alguma_expressao > limite
for: 5m
labels:
severity: warningO for: é importantíssimo.
Imagine CPU:
14:00:01 92%
14:00:10 48%Queremos chamar alguém?
Provavelmente não.
Foi apenas um pico.
Agora:
14:00 92%
14:01 94%
14:02 96%
14:03 95%
14:04 97%
14:05 96%A história mudou.
Por isso os estados de um alerta podem passar conceitualmente por:
Inactive
↓
Pending
↓
Firing🔔 CAPÍTULO 21 — PROMETHEUS DETECTA; ALERTMANAGER ORGANIZA A GUERRA
Prometheus e Alertmanager têm responsabilidades diferentes.
Prometheus determina:
"A condição do alerta aconteceu."Alertmanager pergunta:
"Quem precisa saber?"Ele pode:
agrupar
rotear
silenciar
inibir
encaminharImagine cinquenta servidores falhando porque um único switch morreu.
Você provavelmente não quer:
50 × email
50 × Slack
50 × pagerVocê quer contexto e agrupamento.
Esse é o trabalho do Alertmanager.
📺 CAPÍTULO 22 — GRAFANA NÃO É PROMETHEUS
Outra confusão comum:
Grafana ≠ PrometheusPrometheus fornece os dados e responde às consultas.
Grafana os transforma em visualizações.
Prometheus
↑
PromQL
│
GrafanaGrafana pode produzir:
gráficos
tabelas
gauges
heatmaps
dashboardsMas existe uma armadilha sedutora.
Criar um dashboard com 93 gráficos e pensar:
“Nossa observabilidade está fantástica!”
Talvez não esteja.
Dashboard bom responde perguntas:
Estamos saudáveis?
Usuários estão sendo afetados?
Quando começou?
Onde está acontecendo?
Está piorando?
O que devo investigar?Se o painel não ajuda nisso, temos apenas uma televisão extremamente sofisticada mostrando números coloridos.
🏦 CAPÍTULO 23 — PROMETHEUS ENTRA NO PROCESSAMENTO DE CARTÕES
Imagine:
AUTHORIZATION
↓
CAPTURE
↓
CLEARING
↓
SETTLEMENTInstrumentamos:
card_authorizations_total
card_authorization_errors_total
card_authorization_duration_seconds
clearing_transactions_total
settlement_failures_totalAgora podemos observar:
TPS
error rate
latency
rejection rate
backlogPerceba o salto.
Começamos monitorando:
CPU
memory
diskAgora estamos monitorando:
O NEGÓCIO.Isso é muito mais interessante.
🦖 CAPÍTULO 24 — PROMETHEUS ENCONTRA O MAINFRAME
Imagine um dashboard:
╔════════════════════════════════════╗
║ CICS PRODUCTION ║
╠════════════════════════════════════╣
║ TPS 2.841 ║
║ p95 184 ms ║
║ ABEND Rate 0,02% ║
║ Active Tasks 117 ║
║ MQ Queue Depth 14 ║
║ CPU 63% ║
╚════════════════════════════════════╝De repente o operador percebe:
03:15 MQ depth 17
03:16 MQ depth 34
03:17 MQ depth 581
03:18 MQ depth 1.307Consulta outra métrica.
TPS continua normal.
Outra.
CICS response time começou a aumentar às 03:16:48.
Outra.
Db2 latency aumentou às 03:16:31.
Agora temos uma linha investigativa:
Db2 latency
↓
CICS latency
↓
MQ backlog
↓
experiência do usuárioÉ quase arqueologia de incidente em tempo real.
🕵️ CAPÍTULO 25 — NÃO ALERTE SOBRE RUÍDO
Existe uma regra de ouro operacional:
Alertar sobre tudo
=
não alertar sobre nadaPorque seres humanos aprendem rapidamente a ignorar alarmes inúteis.
Imagine receber diariamente:
CPU 81%
CPU 82%
CPU 84%
CPU 81%
CPU 83%Depois de algumas semanas:
"Ah, é aquele alerta."Até chegar o dia em que:
CPU 99%
latency 12s
errors 31%E alguém automaticamente pensa:
“É aquele alerta.”
Isso é alert fatigue.
Por isso, quando possível, é melhor aproximar alertas de sintomas relevantes:
error rate
latency
availability
SLO violation
queue growthem vez de transformar todo pico técnico em emergência.
📚 CAPÍTULO 26 — PROMETHEUS NÃO É SEU LEDGER
Outra distinção fundamental.
Imagine que Prometheus indique:
1.984.322 pagamentosPodemos usar isso para observar comportamento.
Mas se a pergunta for:
“Quantos pagamentos exatamente precisam ser liquidados?”
Procure a fonte transacional oficial.
database
transaction log
ledger
audit trailPrometheus é sistema de observabilidade.
Não deveria ser tratado como livro contábil de transações.
Para um mainframer isso é especialmente fácil de compreender:
SMF ≠ arquivo mestre do cliente
RMF ≠ ledger financeiro
Prometheus ≠ sistema de registro transacionalCada coisa tem sua finalidade.
🛠️ CAPÍTULO 27 — LABORATÓRIO DO APRENDIZ
Se eu estivesse ensinando Prometheus para um COBOLer iniciante, faria o aprendizado nesta ordem:
Primeiro, subiria Prometheus localmente.
Depois, instalaria Node Exporter.
Então observaria:
http://localhost:9100/metricsSem Grafana.
Isso é importante.
Veja primeiro a matéria-prima.
Procure métricas.
Entenda nomes e labels.
Depois vá à interface do Prometheus e experimente:
upDepois:
node_cpu_seconds_totalDepois:
rate(node_cpu_seconds_total[5m])Só depois começaria:
sum()
avg()
max()
topk()
histogram_quantile()Então Grafana.
Depois alertas.
Depois Alertmanager.
Finalmente:
service discovery
recording rules
remote storage
HA
federation
OpenTelemetryA ordem importa.
Quem começa instalando um dashboard pronto pode acabar sabendo operar o painel sem compreender o sistema.
É como aprender ISPF decorando PF keys sem compreender datasets, jobs e address spaces.
💡 CAPÍTULO 28 — CURIOSIDADES QUE VALEM UM CAFÉ
Prometheus nasceu no SoundCloud e posteriormente tornou-se projeto da CNCF.
O nome vem do Prometeu da mitologia grega, associado ao roubo do fogo dos deuses para entregá-lo aos humanos.
É uma escolha curiosamente apropriada.
O Prometheus moderno também nos entrega “fogo”:
dados
visibilidade
conhecimentoGrafana, por sua vez, não faz parte do Prometheus propriamente dito. Eles trabalham maravilhosamente juntos, mas são projetos separados.
Outra curiosidade importante: Prometheus consegue monitorar a si próprio.
Sim.
O vigia também pode ser vigiado.
E isso é essencial.
Porque existe algo pior do que um sistema cair:
o sistema cair enquanto seu monitoramento também está quebrado e ninguém perceber.
🧝♀️ EPÍLOGO — O ESPELHO NÃO PREVÊ O FUTURO
Galadriel observa novamente a superfície do espelho.
Mas dessa vez não aparecem exércitos de Mordor.
Aparecem gráficos.
Latency ↗
Errors ↗
Traffic →
Saturation ↗Um aprendiz pergunta:
— Senhora, isso significa que o sistema cairá?
Galadriel responde:
— Não.
Porque métricas não são profecias.
Elas são evidências.
Prometheus não nos diz necessariamente o futuro.
Ele nos permite perceber que o presente está mudando.
E essa talvez seja a ideia mais importante de toda esta história.
O objetivo final não é:
INSTALAR PROMETHEUSNem:
CRIAR GRAFANANem:
TER 500 MÉTRICASMuito menos:
CRIAR 200 ALERTASO objetivo é construir um sistema no qual, quando alguém disser:
“Produção está estranha.”
possamos responder:
Quando começou?
O que mudou?
Quem foi afetado?
Qual serviço degradou?
Qual é a tendência?
Qual foi a sequência dos acontecimentos?E começar a encontrar respostas.
☕ O HOLOCRON DO PROGRAMADOR COBOL
Se você guardar apenas uma página deste enorme pergaminho de Lothlórien, guarde esta:
OBSERVABILIDADE
│
┌───────────┼───────────┐
│ │ │
METRICS LOGS TRACES
│
▼
TARGETS
│
/metrics
│
▼
PROMETHEUS
│
┌──────┼───────────────┐
│ │ │
TSDB PromQL RULES
│ │ │
│ │ ┌──────┴──────┐
│ │ │ │
│ │ Recording Alerting
│ │ │
│ │ ▼
│ │ Alertmanager
│ │
└──────┴──────────────► GrafanaE abaixo dele escreva:
Counter
→ algo acumulativo
Gauge
→ estado que sobe e desce
Histogram
→ distribuição em buckets
Summary
→ distribuição/quantis calculados no cliente
rate()
→ velocidade de crescimento
increase()
→ crescimento durante um intervalo
Labels
→ dimensões das séries
High Cardinality
→ perigo
Recording Rules
→ pré-calcular
Alerting Rules
→ detectar condições
Alertmanager
→ administrar notificações
Grafana
→ visualizar
PromQL
→ interrogar as sériesE finalmente uma última inscrição, talvez gravada na porta da sala de operações:
“CC 0000 apenas diz que o programa terminou. Observabilidade tenta descobrir se o reino continua saudável.”
Porque, no fim, Prometheus não é sobre CPU, dashboards ou gráficos.
É sobre transformar comportamento em métricas, métricas em séries temporais, séries em perguntas, perguntas em evidências e evidências em ação.
O velho programador COBOL pode olhar para exporters, YAML, PromQL, Grafana, Kubernetes e inicialmente pensar que chegou à Terra-média.
Mas, depois de remover os nomes modernos, encontrará conceitos bastante familiares:
medir
registrar
comparar
correlacionar
detectar
investigar
agirMudaram as ferramentas.
Mudaram os nomes.
Mudaram os castelos.
A missão permanece praticamente a mesma.
Descobrir o que está acontecendo dentro da máquina antes que aquilo que acontece dentro da máquina comece a acontecer com os usuários.
E se às 03:17 uma pequena fila começar silenciosamente a crescer...
...talvez o Espelho de Prometheus já esteja mostrando alguma coisa. 🔥🧝♀️☕
