 |
| Bellacosa Mainframe analisando a performance mainframe |
☕ Um Café no Bellacosa Mainframe
Hércule Poirot Entra no CPD — O Caso do Sistema que Estava Verde, Mas Já Estava Morto por Dentro
Ou: por que latência, erros, CPU, filas, Db2, MQ e I/O não são uma coleção de números — são as pequenas células cinzentas que impedem o SEV-1 antes do café esfriar
Há uma cena recorrente em tecnologia que faria Hércule Poirot ajustar o bigode, olhar para o dashboard e dizer, com delicada indignação belga: “Mon ami, todos os suspeitos têm álibi. E, ainda assim, a folha de pagamento não foi processada.”
O painel está verde. CPU em 38%. Memória em 61%. Banco “UP”. Rede “normal”. Ninguém abriu chamado de infraestrutura. Mas o usuário está esperando oito segundos para consultar o saldo, o atendente do call center aperta Enter pela terceira vez, a fila do IBM MQ cresce como lista de compras em véspera de feriado e o batch que terminava às 5h ainda está conversando com o DASD às 8h12.
Essa é a verdade incômoda do monitoramento: sistemas raramente deixam de funcionar como uma lâmpada que apaga. Eles se deterioram em sinais pequenos, correlacionados e, muitas vezes, educados demais para disparar um alarme simples. Primeiro uma consulta Db2 demora um pouco mais. Depois o pool de conexões fica ocupado. Em seguida, a aplicação segura as requisições por mais tempo. As filas crescem. Os timeouts começam. Os usuários tentam de novo. O volume aumenta artificialmente. A CPU finalmente sobe. Quando alguém percebe, o incidente já não é técnico: virou negócio, reputação e reunião de diretoria.
Para um programador COBOL iniciante, a mensagem mais importante é esta: monitoramento não é assunto exclusivo do “pessoal de infraestrutura”. Quando seu programa faz um EXEC SQL, grava uma mensagem MQ, chama uma transação CICS, lê um VSAM ou recebe um arquivo de entrada, ele passa a fazer parte da história operacional do sistema. O código pode compilar lindamente e ainda assim criar um gargalo capaz de transformar uma terça-feira comum num episódio de investigação criminal.
Prólogo — Poirot não procura números; ele procura a verdade
Métricas são medições. Observabilidade é a capacidade de explicar o que está acontecendo a partir dos efeitos que o sistema produz. Monitoramento é a prática de acompanhar esses sinais e agir a tempo.
Parece uma diferença de dicionário, mas não é. Um dashboard que exibe 250 gráficos pode ser menos útil do que uma única pergunta bem formulada:
A transação importante para o usuário está concluindo corretamente, dentro do tempo prometido?
Imagine uma aplicação bancária. A CPU pode estar baixa. O CICS pode estar ativo. O Db2 pode responder ao comando de health check. Porém, se a operação de transferência demora 20 segundos e 4% delas terminam em timeout, o serviço não está saudável para quem precisa pagar uma conta. Ele está apenas respirando com aparelhos ligados.
Poirot não ficaria satisfeito com “o servidor está no ar”. Ele perguntaria: “No ar para quem? Fazendo o quê? Em quanto tempo? Com qual taxa de sucesso? E o que mudou antes de Madame Latência começar a gritar?”
1. Latência — a primeira testemunha costuma ser o relógio
Latência é o tempo gasto entre um pedido e uma resposta útil. Em aplicações web é o tempo da requisição. Em CICS, pode ser o tempo percebido pelo usuário na transação. Em batch, pode ser o tempo de execução de uma etapa. Em MQ, pode ser o intervalo entre a mensagem entrar na fila e ser efetivamente consumida.
Ela é uma das melhores primeiras pistas porque o usuário sente demora antes de entender qualquer outra coisa. Usuário não abre RMF, não consulta SMF e não discute buffer pool. Usuário diz: “Está lento.” E frequentemente está certo.
Há uma armadilha: não confie apenas na média. Se 95 consultas respondem em 200 milissegundos e cinco levam 20 segundos, a média pode até parecer elegante num PowerPoint. Mas aquelas cinco pessoas vivem a versão completa do desastre.
Por isso usamos percentis:
p50: o comportamento típico, a mediana;
p95: a experiência dos 5% mais lentos;
p99: a cauda ruim, onde se escondem timeouts e casos críticos.
Em um ambiente COBOL/Db2, uma tela pode permanecer rápida para quase todos, enquanto um tipo específico de cliente dispara uma consulta com critério pouco seletivo. É o equivalente técnico de descobrir que todas as vítimas tomaram chá, mas apenas uma escolheu a xícara errada.
Dica prática: defina um objetivo de serviço, ou SLO. Por exemplo: “99,9% das consultas de saldo devem terminar com sucesso em até 1 segundo.” Agora a conversa deixa de ser “parece lento” e passa a ser verificável.
2. Taxa de erros — quando o sistema deixa evidência no local do crime
Taxa de erros mede falhas explícitas: HTTP 500, timeout, abend, autenticação rejeitada, mensagem devolvida, SQLCODE negativo, transação com rollback ou job encerrado com RC maior que o permitido.
Mas nem todo erro é o mesmo crime. Um 404 causado por URL digitada errada é bem diferente de uma transferência financeira que retorna 500. Um SQLCODE -100 pode ser resultado esperado — nenhum registro encontrado. Já um SQLCODE -911 pode indicar deadlock ou timeout; aí Poirot põe a mão no queixo, porque duas transações disputando recursos contam uma história bem mais interessante.
Um iniciante em COBOL deve aprender desde cedo a tratar retorno e contexto, não apenas “seguir em frente” depois do comando:
EXEC SQL
SELECT NOME
INTO :WS-NOME
FROM CLIENTE
WHERE CPF = :WS-CPF
END-EXEC
EVALUATE SQLCODE
WHEN 0
CONTINUE
WHEN 100
MOVE 'CLIENTE NAO ENCONTRADO' TO WS-MENSAGEM
WHEN OTHER
PERFORM REGISTRA-ERRO-DB2
MOVE 'FALHA TEMPORARIA' TO WS-MENSAGEM
END-EVALUATE.
O detalhe operacional é essencial: registre a falha com identificador da transação, programa, operação e correlação da requisição. Um log dizendo apenas “erro no banco” é tão útil quanto uma testemunha dizendo “vi alguém de chapéu”.
3. Throughput — muito trabalho pode ser sucesso ou pânico
Throughput é volume processado por unidade de tempo: transações por segundo, requisições por minuto, mensagens consumidas, registros lidos, documentos emitidos ou pagamentos autorizados.
Um aumento de throughput pode significar uma campanha bem-sucedida. Mas também pode significar que usuários estão repetindo cliques porque nada responde, que uma integração entrou em loop de retry ou que um lote foi reenviado três vezes.
Esse último caso é uma bela curiosidade de CPD: às vezes o sistema não está recebendo mais trabalho real; está recebendo o mesmo trabalho, repetido por ansiedade humana ou erro de software. É o “efeito elevador”: o botão não respondeu, então alguém apertou cinco vezes. Em sistemas distribuídos, cada tentativa pode abrir conexão, chamar serviço, consultar Db2 e colocar mensagem na fila. A consequência é um aumento de carga que agrava exatamente a lentidão que motivou o novo clique.
Compare sempre throughput com latência, erro e filas. Mais transações com latência estável e erro baixo é capacidade. Mais transações com demora, falhas e acúmulo é saturação disfarçada de sucesso.
4. CPU — o suspeito famoso, mas raramente o único culpado
CPU é a métrica mais vista porque é intuitiva. Uso alto pode apontar carga legítima, loop, compressão, criptografia, serialização, processamento excessivo ou necessidade de capacidade adicional.
Mas CPU baixa não inocenta o sistema. Uma transação bloqueada esperando I/O, lock Db2, resposta de rede ou disponibilidade de conexão pode consumir pouca CPU e, ainda assim, fazer o usuário envelhecer diante da tela.
No z/OS, a investigação é ainda mais refinada. Não basta perguntar “quanto de CPU?”; é preciso considerar CP, zIIP, WLM, prioridade da service class, dispatching delay e a diferença entre usar CPU e esperar para receber CPU. Um workload pode ter sido classificado com importância inadequada, enquanto outro, menos importante, ganha a pista de corrida.
Para o programador COBOL, a lição é humilde e poderosa: antes de concluir que falta máquina, procure trabalho desperdiçado. Um PERFORM mal controlado, uma busca sequencial onde seria possível indexação, conversões repetidas, leitura desnecessária de registros e chamadas redundantes fazem muito barulho quando multiplicadas por milhões.
5. Memória — o vazamento começa como gota e termina como enchente
Memória é a capacidade de manter dados e execução disponíveis sem recorrer excessivamente a paginação, swap ou reinicializações. Vazamentos de memória são particularmente traiçoeiros: a aplicação funciona após o deploy, passa nos testes, opera por algumas horas e, aos poucos, cresce até transformar manutenção de rotina em madrugada de guerra.
Em plataformas distribuídas, procure crescimento contínuo, garbage collection cada vez mais frequente, pausas longas e processos mortos por falta de memória. Em ambiente mainframe, o vocabulário varia — regiões CICS, storage, address spaces, limites e pressão de recursos — mas o princípio é o mesmo: consumo que sobe sem retornar ao patamar normal merece investigação.
Muitos incidentes não são causados por “falta de memória” em sentido absoluto. São causados por fragmentação, limites por processo, vazamento de conexões ou uma aplicação mantendo objetos que deveriam ter sido liberados. O grande crime pode estar numa pequena referência esquecida.
6. Disco e I/O — o porão escuro onde o gargalo se esconde
CPU de 20%, memória tranquila e aplicação lenta: este é o momento de olhar para I/O. A aplicação talvez não esteja calculando; talvez esteja esperando leitura, escrita, flush de log ou páginas do banco.
No mundo Db2, uma consulta aparentemente simples pode fazer centenas de milhares de leituras se o access path for ruim. No VSAM, uma rotina pode transformar acesso direto em leitura sequencial involuntária. No batch, um arquivo enorme pode competir por recursos em um horário já pressionado.
Monitore latência de leitura e escrita, IOPS, fila de I/O, tempo de resposta de volumes, espaço disponível e waits. No z/OS, RMF, SMF, OMEGAMON, SYSVIEW e ferramentas equivalentes ajudam a separar “meu programa está lento” de “meu programa está à espera do storage”.
Eis uma regra de investigação: se alguém sugere comprar mais CPU antes de examinar I/O e SQL, Poirot recomenda cautela. Pode ser como aumentar a potência do carro quando ele está parado numa fila de pedágio.
7. Latência de rede — toda dependência distante aumenta a fragilidade
Uma transação moderna pode atravessar API Gateway, autenticação, microsserviço, cache, serviço externo, MQ, CICS, Db2 e retornar. Cada salto é uma chance adicional de atraso, falha ou timeout.
Não reduza rede a um teste de ping. Há DNS lento, perda de pacotes, handshake TLS, proxy saturado, pool de conexões esgotado, firewall, rota alterada e API de terceiro que decidiu fazer manutenção sem avisar. A parte local pode estar perfeita; a chamada externa pode ser o veneno no chá.
O remédio é rastreamento distribuído: um identificador de correlação que acompanha a requisição. Assim, em vez de saber apenas que a operação demorou oito segundos, você descobre que gastou 200 ms no gateway, 300 ms no CICS, 6,7 s esperando a API externa e 800 ms no Db2.
8. Profundidade de fila — a confissão silenciosa do sistema assíncrono
Fila é uma promessa: “não processei agora, mas processarei daqui a pouco”. IBM MQ é excelente nisso. Ele desacopla produtor e consumidor, absorve picos e protege aplicações. Mas fila crescendo sem parar é a prova de que a entrada é maior que a saída.
Não observe só quantas mensagens existem. Observe também:
taxa de entrada versus taxa de consumo;
idade da mensagem mais antiga;
quantidade de consumidores ativos;
retries e mensagens em dead-letter queue;
tempo total até a conclusão do negócio.
Uma fila com 100 mil mensagens pode ser normal numa madrugada de processamento massivo. Uma fila com 200 mensagens pode ser gravíssima se costumava ficar zerada e cada uma corresponde a uma autorização de cartão. Contexto, como sempre, é a pequena célula cinzenta que separa análise de decoração.
9. Cache hit rate — velocidade emprestada precisa ser devolvida com correção
Cache evita consultas caras. Quando há hit, o dado já está disponível; quando há miss, a aplicação precisa buscar no banco, no disco ou num serviço remoto. Taxa de acerto baixa pode despejar carga sobre o Db2 e iniciar uma cascata: mais leitura, mais I/O, mais latência, mais timeouts e mais retries.
Porém, uma taxa alta não é absolvição. Cache pode entregar dado velho. Em sistemas de saldo, estoque, preço ou autorização, velocidade sem consistência é apenas um erro muito rápido.
Defina claramente o que pode ser armazenado, por quanto tempo, como invalidar e o que fazer em caso de falha. Nem tudo merece cache; alguns dados existem exatamente para serem consultados em sua forma mais atual.
10. Tempo de consulta Db2 — o mordomo quase sempre tem um índice
Há uma piada de veterano: quando uma aplicação está lenta, a culpa é da rede; quando a rede está boa, a culpa é do servidor; quando o servidor está bom, alguém finalmente abre o EXPLAIN.
Consultas ao banco são causas clássicas de degradação escondida. Meça duração, volume de execuções, linhas lidas versus retornadas, uso de índices, locks, deadlocks, tempo de commit e plano de acesso. Uma query de dois segundos rodando uma vez pode ser tolerável. A mesma query executada vinte mil vezes por minuto é um pedido formal de incidente.
Para quem começa em COBOL com Db2, três hábitos evitam boa parte dos crimes:
Não use
SELECT *se precisa de duas colunas.Conheça as colunas de filtro e os índices disponíveis.
Verifique o plano de acesso quando o volume real crescer.
Também cuide das estatísticas. Um otimizador decide com base no que sabe. Se as estatísticas não representam mais a tabela, ele pode escolher um caminho que parece excelente no papel e péssimo no DASD.
O método Poirot: um passo a passo para investigar degradação
Quando o alerta tocar, resista à tentação de acusar o primeiro gráfico vermelho. Siga um roteiro.
Primeiro: confirme o impacto. Qual jornada foi afetada? Login, pagamento, consulta, emissão, batch, integração? Quem sente: todos, uma região, um cliente, uma versão?
Segundo: determine quando começou. Houve deploy, alteração de parâmetro, pico de tráfego, janela de batch, mudança de certificado, atualização de tabela, campanha comercial ou falha externa?
Terceiro: compare sinais. A latência subiu antes dos erros? A fila cresceu antes da CPU? O Db2 ficou lento antes da aplicação esgotar conexões? A sequência importa: ela é a linha do tempo do crime.
Quarto: encontre o gargalo, não o sintoma. Aumentar instâncias pode piorar uma base já sobrecarregada. Reiniciar consumidor pode gerar uma tempestade de reprocessamento. Escalar CPU não cura lock Db2.
Quinto: reduza o impacto. Limite tráfego, faça rollback de mudança, ative modo degradado, aumente consumidores com cuidado, interrompa batch concorrente ou desabilite uma função não essencial.
Sexto: registre o caso. Depois do incidente, documente causa, sinais iniciais, decisão tomada, impacto, correção e alerta preventivo. O objetivo não é achar um culpado humano; é fazer o sistema ensinar a própria equipe.
O dashboard que vale alguma coisa
O painel deve começar pelo negócio, não pelo hardware. Coloque no topo as transações críticas, taxa de sucesso, latência p95/p99 e orçamento de erro. Depois, use CPU, memória, I/O, rede, cache, fila e banco como trilha de investigação.
Uma estrutura simples e poderosa é observar quatro sinais de ouro:
latência: está demorando?
tráfego: quanto trabalho chegou?
erros: está falhando?
saturação: qual recurso chegou ao limite?
Os dez sinais do infográfico aprofundam essa estrutura. Eles não competem entre si; conversam entre si.
Epílogo — o sinal em que se deve confiar
Se Poirot tivesse de escolher apenas um sinal para decisão em produção, ele provavelmente escolheria um SLO ligado à experiência da transação crítica: sucesso dentro de um tempo aceitável. CPU, memória, rede, disco, Db2 e fila são fundamentais para encontrar a causa. Mas o usuário não compra CPU. Ele compra o resultado.
Portanto, a melhor métrica não é “CPU abaixo de 80%”. É algo como: “99,9% das transferências devem concluir corretamente em até dois segundos.” Essa promessa pode ser medida, defendida e investigada.
No fim, monitorar é isso: notar o aumento discreto da latência antes de virar timeout; perceber a fila antes de virar backlog; encontrar a query antes de ela virar indisponibilidade; ouvir os sinais antes que o CPD inteiro grite.
E quando alguém disser que está tudo verde, mas o cliente está esperando, ajuste o bigode imaginário e responda: “Então, mon ami, talvez devêssemos investigar o que esses verdes estão deixando de contar.”
