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 0000

Maravilha!

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ÁVEL

Sã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
TRACES

Podemos 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
   ↓
Db2

Uma métrica pode dizer:

latência p95 = 2,4 segundos

O log pode mostrar:

SQLCODE -911

E 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
Saturation

Para 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 time

Traffic

Quanto trabalho estamos recebendo?

transactions/sec
requests/sec
messages/sec
jobs/hour

Errors

Quanto está falhando?

HTTP 500
ABENDs
SQL errors
MQ failures
rejected transactions

Saturation

Quanto estamos nos aproximando do limite?

CPU
memory
connections
threads
queue depth
storage

Aqui existe uma lição importante.

CPU alta não significa automaticamente problema.

Imagine:

CPU      = 91%
Latency  = normal
Errors   = normal
Traffic  = altíssimo

Talvez a máquina simplesmente esteja trabalhando bastante.

Agora imagine:

CPU      = 42%
Latency  = 8 segundos
Errors   = crescendo
Traffic  = normal

Temos 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
   ↓
ALERTAR

A 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 = 1400

Ruim?

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.917

Agora 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_total

Interessante.

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 ambiente

Isso é 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
   ↑
Prometheus

Temos 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
       ↑
   Prometheus

Pense 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:9100

podem ser targets.

E normalmente Prometheus encontrará ali:

/metrics

Portanto:

TARGET
   ↓
endpoint monitorado

EXPORTER
   ↓
componente que expõe métricas

Uma aplicação também pode implementar /metrics diretamente.

Nesse caso:

Application
     ↓
  /metrics
     ↑
Prometheus

Nã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/metrics

Ele 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
      ↓
scrape

O 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 organizar

Grande parte disso aparece no:

prometheus.yml

Exemplo 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ção

Cuidado apenas para não levar a analogia longe demais.

---

🧭 CAPÍTULO 10 — SERVICE DISCOVERY

Targets fixos funcionam bem quando temos:

server01
server02
server03

Mas imagine Kubernetes.

Agora:

10 pods

Cinco minutos depois:

27 pods

Mais tarde:

8 pods

Seria 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
     ↓
scraping

Esse 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_total

Ele cresce:

100
101
105
120
180

Normalmente só volta para baixo quando o processo reinicia.

Excelente para:

requests
transactions
errors
jobs completed
messages processed

Mas existe uma armadilha.

Perguntar:

http_requests_total = 938.281.293

nã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 = 150

podemos interpretar, dentro daquele contexto, algo como:

150 requests/s

Para 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íodo

Uma 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 tasks

Imagine MQ:

mq_queue_depth

Valores:

08:00   14
08:01   17
08:02   25
08:03   81
08:04   320
08:05   982

Isso 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 ms

Calcular 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
p99

Se dissermos:

p95 = 800 ms

estamos 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âncias

Queremos calcular:

p95 global

Histograms 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]) > 80

nã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 0000

e 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 SERIES

Isso lembra bastante uma:

MATERIALIZED VIEW

de 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 alerta

Exemplo conceitual:

alert: HighLatency

expr: alguma_expressao > limite

for: 5m

labels:
  severity: warning

O 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
encaminhar

Imagine cinquenta servidores falhando porque um único switch morreu.

Você provavelmente não quer:

50 × email
50 × Slack
50 × pager

Você quer contexto e agrupamento.

Esse é o trabalho do Alertmanager.

---

📺 CAPÍTULO 22 — GRAFANA NÃO É PROMETHEUS

Outra confusão comum:

Grafana ≠ Prometheus

Prometheus fornece os dados e responde às consultas.

Grafana os transforma em visualizações.

Prometheus
     ↑
   PromQL
     │
  Grafana

Grafana pode produzir:

gráficos
tabelas
gauges
heatmaps
dashboards

Mas 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
      ↓
SETTLEMENT

Instrumentamos:

card_authorizations_total

card_authorization_errors_total

card_authorization_duration_seconds

clearing_transactions_total

settlement_failures_total

Agora podemos observar:

TPS
error rate
latency
rejection rate
backlog

Perceba o salto.

Começamos monitorando:

CPU
memory
disk

Agora 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.307

Consulta 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 nada

Porque 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 growth

em 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 pagamentos

Podemos 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 trail

Prometheus é 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 transacional

Cada 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/metrics

Sem Grafana.

Isso é importante.

Veja primeiro a matéria-prima.

Procure métricas.

Entenda nomes e labels.

Depois vá à interface do Prometheus e experimente:

up

Depois:

node_cpu_seconds_total

Depois:

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
OpenTelemetry

A 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
conhecimento

Grafana, 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 PROMETHEUS

Nem:

CRIAR GRAFANA

Nem:

TER 500 MÉTRICAS

Muito menos:

CRIAR 200 ALERTAS

O 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
   │      │
   └──────┴──────────────► Grafana

E 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éries

E 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
agir

Mudaram 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. 🔥🧝‍♀️☕