Bellacosa Mainframe e laboratorio pratico de performance

☕💣🔥 LABORATÓRIO PRÁTICO — TESTES DE PERFORMANCE PARA O PADAWAN COBOL MAINFRAME

Este laboratório foi criado para transformar conceitos em prática.

A ideia é que o aluno pense como um Analista de Performance, um Desenvolvedor COBOL e um Sysprog ao mesmo tempo.

Cada exercício possui:

• Cenário

• Desafio

• Solução Comentada

• Conceitos Envolvidos

---

EXERCÍCIO 1

Identificando o Tipo de Teste

Cenário

O banco deseja validar se o Internet Banking suporta 5.000 usuários simultâneos.

Pergunta

Qual tipo de teste deve ser realizado?

A) Estresse

B) Resistência

C) Carga

D) Pico

---

Solução

Resposta:

C) Carga

O objetivo é validar a capacidade prevista do ambiente.

Não estamos ultrapassando limites.

Não estamos testando durante horas.

Não estamos simulando explosões repentinas.

Estamos simulando o uso normal esperado.

---

EXERCÍCIO 2

Descobrindo o Gargalo

Cenário

Uma consulta de saldo apresenta:

Componente	Tempo
Front-End	50 ms
API	80 ms
CICS	1200 ms
DB2	950 ms

Pergunta

Onde está o principal gargalo?

---

Solução

CICS e DB2.

O tempo de resposta total está concentrado nessas camadas.

O Front-End e API representam parcela muito pequena do processamento.

O próximo passo seria analisar:

• SQL

• Índices

• Plano de acesso

• Locks

---

EXERCÍCIO 3

Avaliando Throughput

Cenário

Durante um teste foram processadas:

120.000 transações

em

60 segundos

Pergunta

Qual o Throughput?

---

Solução

Fórmula:

TPS = Transações ÷ Tempo

120.000 ÷ 60

TPS = 2.000

Resposta:

2.000 TPS

---

EXERCÍCIO 4

Encontrando Problema de Código COBOL

Programa

PERFORM UNTIL WS-FIM = 'S'

   READ ARQ-CLIENTES
      AT END
         MOVE 'S' TO WS-FIM
   END-READ

   PERFORM PROCESSA-CLIENTE

END-PERFORM

Pergunta

Qual risco de performance existe?

---

Solução

Se o arquivo possuir milhões de registros:

• CPU elevada

• I/O elevado

• Tempo excessivo

O código não está errado.

Mas pode não escalar.

Performance depende do volume.

---

EXERCÍCIO 5

Escolhendo a Ferramenta

Cenário

Você precisa gerar:

10.000 usuários simultâneos

realizando chamadas HTTP.

Pergunta

Qual ferramenta apresentada seria mais indicada?

---

Solução

Apache JMeter.

Porque:

• Open Source

• Escalável

• HTTP

• HTTPS

• REST

• SOAP

Foi justamente a ferramenta mostrada na apresentação.

---

EXERCÍCIO 6

Teste de Resistência

Cenário

Uma aplicação funciona perfeitamente por:

30 minutos

Após:

8 horas

o consumo de memória cresce continuamente.

Pergunta

Qual tipo de teste identificou o problema?

---

Solução

Teste de Resistência.

Também chamado:

Soak Test

ou

Endurance Test.

Esse tipo de problema dificilmente aparece em testes rápidos.

---

EXERCÍCIO 7

Simulando Black Friday

Cenário

Usuários simultâneos:

09:00 → 1.000

09:01 → 10.000

09:02 → 15.000

09:03 → 1.000

Pergunta

Qual tipo de teste está sendo realizado?

---

Solução

Teste de Pico.

Objetivo:

Validar explosões repentinas de acesso.

Muito comum em:

• Black Friday

• PIX

• Campanhas

• Venda de ingressos

---

EXERCÍCIO 8

Análise de Mainframe

Cenário

Durante o teste:

CPU = 35%

Tempo de Resposta = 8 segundos

Pergunta

A CPU é o problema?

---

Solução

Não necessariamente.

Esse é um erro clássico.

Mesmo com CPU baixa podem existir:

• Locks DB2

• Espera de I/O

• MQ congestionado

• SQL ruim

• Contenção CICS

CPU baixa não significa ambiente saudável.

---

EXERCÍCIO 9

Virtualização de Serviços

Cenário

O microsserviço precisa chamar:

• Serviço A

• Serviço B

• Mainframe

Mas o Mainframe está indisponível.

Pergunta

Como continuar os testes?

---

Solução

Utilizando Virtualização.

Criamos respostas simuladas.

Exemplo:

{
  "conta":"12345",
  "saldo":"1500.00"
}

Assim os testes continuam sem depender do ambiente real.

---

EXERCÍCIO 10

Diagnóstico Completo

Cenário

O Grafana mostra:

CPU = 40%

Memória = 45%

Tempo Médio = 5 segundos

Dynatrace mostra:

API = 100 ms

CICS = 250 ms

DB2 = 4200 ms

Pergunta

Onde você investigaria primeiro?

---

Solução

DB2.

O banco responde por mais de 80% do tempo total.

Possíveis causas:

• Full Scan

• Índice ausente

• Estatísticas desatualizadas

• Lock

• SQL mal otimizado

---

DESAFIO FINAL DO PADAWAN ☕💣

Imagine a seguinte arquitetura:

Mobile
   ↓
Apache
   ↓
WebSphere
   ↓
API
   ↓
MQ
   ↓
CICS
   ↓
COBOL
   ↓
DB2

Você recebe a reclamação:

"Consultar saldo está demorando 12 segundos."

Descreva:

1. Quais ferramentas utilizaria?

2. Quais métricas analisaria?

3. Quais componentes investigaria primeiro?

4. Como executaria um teste de carga?

5. Como validaria a correção?

---

GABARITO ESPERADO

Ferramentas:

• JMeter

• Dynatrace

• Grafana

• OMEGAMON

• RMF

• SMF

Métricas:

• CPU

• TPS

• Tempo Médio

• P95

• P99

• I/O

• MQ Depth

• Tempo DB2

Investigação:

1. Dynatrace

2. DB2

3. CICS

4. MQ

5. API

Teste:

• 5.000 usuários

• Ramp-up gradual

• Monitoramento simultâneo

Validação:

Comparar:

Antes = 12 segundos

Depois = meta inferior a 2 segundos

---

Missão Extra Bellacosa Mainframe

Pegue um programa COBOL real do seu ambiente e responda:

• Quantos READs ele executa?

• Quantos WRITEs?

• Quantos SELECTs DB2?

• Qual o maior loop?

• Qual o volume esperado?

• Como ele se comportaria com 10 milhões de registros?

Se você conseguir responder essas perguntas, já começou a pensar como um profissional de Performance Mainframe e não apenas como um programador COBOL. ☕💣🚀

Bellacosa Mainframe e a performance em mainframe

☕💣🔥 O DIA EM QUE 10.000 USUÁRIOS DERRUBARAM UM COBOL QUE FUNCIONAVA PERFEITAMENTE — O GUIA DEFINITIVO DE TESTES DE PERFORMANCE PARA O PADAWAN DO MAINFRAME

Existem algumas frases que assustam qualquer profissional experiente de Mainframe.

Uma delas é:

"Pode colocar em produção. Já testamos tudo."

A segunda é:

"Funcionou na minha máquina."

E a terceira, talvez a mais perigosa de todas:

"Performance a gente vê depois."

Se você é um jovem Padawan do COBOL, provavelmente acredita que o trabalho do programador termina quando o programa compila sem erros, passa nos testes funcionais e devolve o resultado correto.

Mas existe um mundo oculto além da lógica.

Um universo onde programas corretos derrubam bancos.

Onde APIs perfeitamente desenvolvidas travam durante a Black Friday.

Onde um SELECT aparentemente inocente consegue transformar uma aplicação inteira em um incêndio corporativo.

Esse universo chama-se Performance.

E hoje vamos conversar sobre um assunto que separa programadores comuns dos profissionais que sobrevivem décadas trabalhando em ambientes críticos.

Vamos falar sobre Testes de Performance.

---

A PRIMEIRA GRANDE LIÇÃO

Imagine que você criou um programa COBOL chamado CONSULTA-SALDO.

O programa recebe:

• Agência

• Conta

Consulta o DB2.

Retorna o saldo.

Você testa.

Funciona.

Seu colega testa.

Funciona.

O analista testa.

Funciona.

O gerente testa.

Funciona.

Todo mundo comemora.

O programa sobe para produção.

Cinco minutos depois:

O Internet Banking trava.

O aplicativo móvel trava.

O atendimento telefônico trava.

O gerente da agência liga desesperado.

E você pensa:

"Mas aqui funcionava..."

Sim.

Funcionava.

Para um usuário.

Produção não possui um usuário.

Produção possui milhares.

Essa é a primeira lição da performance.

Um sistema que funciona para uma pessoa não necessariamente funciona para dez mil.

---

O QUE É UM TESTE DE PERFORMANCE?

Muitos iniciantes acreditam que teste de performance significa medir velocidade.

Não é apenas isso.

Teste de performance é a arte de descobrir como um sistema se comporta quando submetido ao mundo real.

Queremos responder perguntas como:

• Quantos usuários suporta?

• Qual o tempo de resposta?

• Onde está o gargalo?

• Quanto de CPU consome?

• Quanto de memória utiliza?

• Quantas transações por segundo processa?

Na prática estamos tentando descobrir o limite antes que o cliente descubra primeiro.

Porque quando o cliente descobre primeiro, normalmente já existe uma crise instalada.

---

TESTES FUNCIONAIS X TESTES NÃO FUNCIONAIS

O material apresentado faz uma separação extremamente importante.

Testes funcionais verificam:

"O sistema faz o que deveria fazer?"

Exemplo:

Você informa uma conta.

O sistema retorna o saldo correto.

Teste aprovado.

Mas existe outra pergunta.

"O sistema continua fazendo isso quando dez mil usuários acessam simultaneamente?"

Essa pergunta pertence ao mundo dos testes não funcionais.

E é exatamente aqui que entra a performance.

---

O EXEMPLO DO AUTOMÓVEL

Imagine um carro.

Você gira a chave.

O motor liga.

Teste funcional aprovado.

Mas ainda faltam várias perguntas:

• Qual a velocidade máxima?

• Quanto consome?

• Quanto suporta de carga?

• Como se comporta em uma subida?

• Como reage após cinco horas de viagem?

Essas perguntas representam os testes não funcionais.

O mesmo vale para sistemas.

---

O QUE REALMENTE DERRUBA SISTEMAS?

O Padawan normalmente pensa:

"Se estiver lento é porque falta CPU."

Nem sempre.

Na verdade, CPU costuma ser apenas um dos suspeitos.

Os verdadeiros vilões geralmente são:

• SQL mal escrito

• Índices ausentes

• Locks excessivos

• Filas MQ congestionadas

• Chamada excessiva a serviços

• Pool JDBC esgotado

• Recursos compartilhados

Em outras palavras:

O problema normalmente não está onde você imagina.

---

TESTE DE CARGA

Este é o mais conhecido.

O objetivo é reproduzir o uso normal esperado.

Imagine:

O banco estima 5.000 usuários simultâneos.

Criamos então um cenário simulando exatamente esse volume.

A pergunta é simples:

"O sistema suporta?"

Se suporta, ótimo.

Se não suporta, ainda temos tempo para corrigir.

Muito melhor descobrir isso no laboratório do que no Jornal Nacional.

---

TESTE DE ESTRESSE

Aqui a conversa fica interessante.

Em vez de testar o limite esperado, ultrapassamos o limite.

Muito.

Se o ambiente foi projetado para 5.000 usuários:

Testamos 10.000.

15.000.

20.000.

Queremos descobrir:

Como ele falha?

Uma falha controlada é muito melhor que um colapso inesperado.

---

TESTE DE RESISTÊNCIA

Agora imagine uma maratona.

O sistema suporta 5.000 usuários.

Ótimo.

Mas por quanto tempo?

Uma hora?

Duas?

Dez?

Vinte e quatro?

O teste de resistência mantém carga constante durante longos períodos.

Muitas aplicações parecem saudáveis por trinta minutos.

Depois começam a consumir memória.

Depois mais memória.

Depois ainda mais memória.

Até morrerem lentamente.

É o famoso Memory Leak.

---

TESTE DE PICO

Imagine a abertura das vendas de um show.

Ou a Black Friday.

Ou o lançamento de um PIX promocional.

O tráfego explode.

O sistema precisa absorver esse impacto.

O teste de pico verifica exatamente isso.

O comportamento durante explosões repentinas.

---

O MUNDO HÍBRIDO

Antigamente era simples.

Usuário.

Tela.

Mainframe.

Fim.

Hoje não.

Hoje temos:

Aplicativo Mobile

↓

Apache

↓

WebSphere

↓

API Gateway

↓

Microsserviços

↓

MQ

↓

CICS

↓

COBOL

↓

DB2

Percebe o problema?

Se a tela demora cinco segundos, onde está o gargalo?

Pode estar em qualquer ponto da cadeia.

E é por isso que observabilidade se tornou tão importante.

---

APACHE JMETER

Se existe uma ferramenta que virou símbolo dos testes de carga modernos, essa ferramenta é o Apache JMeter.

Pense nele como um exército virtual.

Você configura usuários fictícios.

Esses usuários começam a executar operações.

Consultar saldo.

Fazer transferência.

Emitir extrato.

Pagar boleto.

E o sistema acredita que são usuários reais.

O JMeter consegue gerar milhares de acessos simultâneos.

É exatamente assim que simulamos produção sem colocar clientes reais em risco.

---

EXEMPLO PRÁTICO

Suponha uma API:

GET /saldo

Queremos simular:

5.000 usuários.

Criamos:

Thread Group

Usuários: 5000

Ramp-Up: 300 segundos

Loop: infinito

Agora adicionamos:

HTTP Request

Executamos.

Pronto.

Começamos a produzir carga.

Mas isso é apenas metade da história.

---

POR QUE APENAS GERAR CARGA NÃO BASTA?

Imagine um médico.

Ele mede sua pressão.

Mas ignora:

• Frequência cardíaca

• Oxigenação

• Temperatura

Seria um diagnóstico completo?

Claro que não.

Com performance ocorre a mesma coisa.

Gerar carga é apenas o começo.

Precisamos observar o ambiente inteiro.

---

DYNATRACE

É aqui que entra o Dynatrace.

Pense nele como uma tomografia computadorizada da aplicação.

Ele acompanha cada requisição.

Cada chamada.

Cada serviço.

Cada banco de dados.

Cada microsserviço.

Cada transação.

Em vez de simplesmente dizer:

"Está lento."

Ele mostra:

"Está lento porque o Serviço X chamou o Serviço Y que executou uma consulta SQL custosa."

Agora existe informação para agir.

---

O SONHO DE TODO ANALISTA DE PERFORMANCE

Imagine um clique no aplicativo.

Consultar saldo.

Dynatrace exibe:

Frontend = 80 ms

API = 100 ms

Microsserviço = 120 ms

CICS = 800 ms

DB2 = 700 ms

Pronto.

Achamos o culpado.

Não existe mais adivinhação.

---

GRAFANA

Se Dynatrace é o médico.

Grafana é o painel da UTI.

Ele transforma números em gráficos.

Mostra:

• CPU

• Memória

• Throughput

• Erros

• Tempo médio

• Percentil 95

• Percentil 99

E permite acompanhar tudo em tempo real.

Uma imagem muitas vezes vale mais que mil relatórios.

---

O QUE O MAINFRAME ENSINA SOBRE PERFORMANCE?

Muito antes da palavra observabilidade virar moda, o Mainframe já monitorava tudo.

E quando digo tudo, é tudo mesmo.

O z/OS nasceu para ambientes críticos.

Por isso existem ferramentas extremamente sofisticadas.

---

SMF

System Management Facility.

Registra praticamente tudo.

CPU.

I/O.

Transações.

Consumo.

Execução.

É o grande livro de registros do sistema.

---

RMF

Resource Measurement Facility.

Analisa comportamento dos recursos.

Ajuda a identificar gargalos.

Mostra utilização de processadores.

Filas.

Memória.

Dispositivos.

---

OMEGAMON

Uma das ferramentas mais famosas do universo IBM.

Monitora:

• z/OS

• CICS

• DB2

• MQ

Em tempo real.

Quando algo fica lento, geralmente ele é um dos primeiros lugares onde o especialista procura respostas.

---

O MAIOR ERRO DOS PROGRAMADORES INICIANTES

O Padawan costuma pensar:

"Meu programa executa rápido."

Mas rápido para quem?

Com qual volume?

Em qual horário?

Contra qual banco?

Com quantos registros?

Essas perguntas mudam tudo.

Um SELECT que retorna dez linhas parece maravilhoso.

O mesmo SELECT retornando dez milhões de linhas pode virar um desastre.

---

O CASO DO LOOP INOCENTE

Imagine:

PERFORM UNTIL EOF

READ ARQUIVO

PROCESSA

END-PERFORM

Parece simples.

Mas e se o arquivo possuir:

50 milhões de registros?

Agora o cenário muda.

Performance não depende apenas do código.

Depende dos dados.

---

PERFORMANCE É ARQUITETURA

Muitos acreditam que performance é responsabilidade exclusiva da infraestrutura.

Não é.

Também não é responsabilidade exclusiva do desenvolvedor.

Performance é responsabilidade de todos.

Arquitetura.

Banco.

Infraestrutura.

Rede.

Aplicação.

Integração.

Monitoramento.

Tudo influencia.

---

A MENTALIDADE DO PROFISSIONAL MADURO

O iniciante pergunta:

"Funciona?"

O profissional experiente pergunta:

"Funciona sob carga?"

O iniciante pergunta:

"Retornou o resultado?"

O profissional experiente pergunta:

"Quanto tempo demorou?"

O iniciante pergunta:

"Passou no teste?"

O profissional experiente pergunta:

"Qual foi o consumo?"

Essa mudança de mentalidade transforma carreiras.

---

A LIÇÃO FINAL

Ao longo dos anos vi programas COBOL sobreviverem décadas.

Vi sistemas processarem bilhões de transações.

Vi ambientes suportarem eventos gigantescos sem falhar.

E todos tinham algo em comum.

Performance não era tratada como um detalhe.

Era tratada como requisito.

Porque funcionalidades atraem usuários.

Mas é a performance que permite que eles permaneçam utilizando o sistema.

No fim das contas, um programa COBOL não é avaliado apenas pelo que faz.

Ele é avaliado pela velocidade, estabilidade e capacidade com que faz aquilo.

E essa é a diferença entre escrever código e construir sistemas capazes de sobreviver ao mundo real.

Bem-vindo ao próximo nível da sua jornada no Mainframe, jovem Padawan.

Agora você já sabe que compilar é apenas o começo.

 

Bellacosa Mainframe o mundo da observabilidade mainframe

☕🔥 PROMETHEUS, MIMIR E O “SMF DO MUNDO CLOUD” — O UNIVERSO DA OBSERVABILIDADE EXPLICADO PARA UM SYSPROG JÚNIOR 🔥☕

Se o Grafana é o “painel do operador moderno”…

Então:

• Prometheus é o coletor de métricas
• Mimir é o mega repositório escalável
• Loki é o “SYSLOG gigante”
• Tempo é o rastreador de transações
• OpenTelemetry virou o “SMF universal”

E tudo isso junto forma o que o mercado chama hoje de:

☕ OBSERVABILIDADE

Mas um sysprog veterano olha isso e pensa:

“Isso parece RMF + SMF + OMEGAMON + SYSLOG + CICS MONITORING misturados…”

E honestamente?

Está certíssimo. ☕💾

---

☕ O QUE É OBSERVABILIDADE?

Observabilidade é a capacidade de:

• enxergar o sistema
• entender comportamento
• prever falhas
• diagnosticar problemas rapidamente

Ela normalmente trabalha em 3 pilares:

Pilar	Equivalente Mainframe
Métricas	RMF / SMF
Logs	SYSLOG / JESMSGLG
Traces	CICS trace / Db2 accounting

---

☕ O QUE É PROMETHEUS?

O Prometheus é:

• banco de métricas
• coletor temporal
• motor de queries
• sistema de alertas

Criado em:

• 2012
• pela SoundCloud
• open source
• depois adotado pela CNCF

Site oficial:

• Prometheus

---

☕ O PROBLEMA QUE ELE RESOLVEU

Antes do Prometheus:

• monitoramento era caro
• proprietário
• complicado
• cheio de agentes pesados

O Prometheus trouxe:

• simplicidade
• coleta HTTP
• métricas em texto
• integração cloud-native

Foi um divisor de águas.

---

☕ COMO O PROMETHEUS FUNCIONA?

☕ Modelo “Pull”

O Prometheus vai até o servidor e pergunta:

“Me mostre suas métricas.”

Isso é chamado:

• scrape

---

☕ Exemplo de endpoint

Servidor exportando:

http://server:9100/metrics

Saída:

node_cpu_seconds_total 12345
node_memory_MemFree_bytes 987654321

Parece simples…

E é exatamente essa simplicidade que tornou o Prometheus gigante.

---

☕ EXPORTERS — O “COLETOR SMF” DO MUNDO MODERNO

Prometheus usa exporters.

Eles convertem dados do sistema para métricas.

---

☕ EXPORTERS MAIS FAMOSOS

Exporter	Função
node_exporter	Linux
windows_exporter	Windows
blackbox_exporter	Rede
mysqld_exporter	MySQL
postgres_exporter	PostgreSQL
jmx_exporter	Java
snmp_exporter	Equipamentos

---

☕ ANALOGIA MAINFRAME

Mainframe	Prometheus
SMF Type Records	Metrics
RMF Monitor	node_exporter
OMEGAMON	Grafana + Prometheus
Performance Monitor	Time Series DB

---

☕ PROMQL — O “JCL DAS MÉTRICAS”

O Prometheus possui uma linguagem chamada:

☕ PromQL

Isso é o coração do sistema.

---

☕ Exemplo simples

CPU:

rate(node_cpu_seconds_total[5m])

---

☕ Média de memória

avg(node_memory_MemAvailable_bytes)

---

☕ Detectar servidor offline

up == 0

---

☕ O QUE TORNA O PROMETHEUS ESPECIAL?

☕ 1 — Time Series Database

Ele guarda:

• métricas no tempo
• compressão eficiente
• consultas rápidas

Perfeito para:

• tendências
• capacity planning
• troubleshooting

---

☕ 2 — Labels

Toda métrica pode ter rótulos:

http_requests_total{job="api",status="500"}

Isso lembra:

• classificação SMF
• accounting records
• classes de workload

---

☕ 3 — Alertas

Exemplo:

CPU > 90%

Aciona:

• email
• Slack
• Teams
• PagerDuty

Equivalente moderno de:

“OPERADOR! O SISTEMA ESTÁ PEGANDO FOGO!” ☕💥

---

☕ LIMITAÇÕES DO PROMETHEUS

Aqui começa o lado “sysprog raiz”.

Prometheus é excelente…

Mas:

• retenção longa é complicada
• clustering nativo é limitado
• escala massiva dói
• multi-tenant é complexo

E foi exatamente daí que nasceu:

☕ MIMIR

---

☕ O QUE É MIMIR?

O Grafana Mimir é:

• backend distribuído
• armazenamento massivo de métricas
• compatível com Prometheus

Site:

• Grafana Mimir

---

☕ A IDEIA DO MIMIR

Imagine:

Prometheus sozinho:

• ótimo para ambientes pequenos/médios

Mas empresas gigantes precisam:

• bilhões de métricas
• retenção longa
• HA
• multi datacenter
• multi tenant

Mimir resolve isso.

---

☕ ANALOGIA MAINFRAME

Mundo Moderno	Mundo Mainframe
Prometheus	RMF local
Mimir	SMF central corporativo
Object Storage	Tape library
Long retention	Arquivamento histórico

---

☕ COMO O MIMIR FUNCIONA?

Ele separa componentes:

Componente	Função
Distributor	recebe métricas
Ingester	grava dados
Querier	faz consultas
Compactor	compacta blocos
Store Gateway	acessa storage

Parece familiar?

Sim…

É praticamente arquitetura de subsistema enterprise:

• filas
• cache
• storage
• distribuído
• paralelismo

Muito parecido com mentalidade mainframe.

---

☕ STORAGE

Mimir normalmente usa:

• S3
• MinIO
• GCS
• Azure Blob

Isso permite:

• retenção gigantesca
• baixo custo
• alta escalabilidade

---

☕ LOKI — O “SYSLOG GIGANTE”

☕ O QUE É?

O Loki é:

• sistema de logs
• feito pela Grafana Labs

Site:

• Grafana Loki

---

☕ DIFERENÇA IMPORTANTE

Elasticsearch indexa tudo.

Loki indexa:

• apenas labels

Resultado:

• menos custo
• menos storage
• mais eficiência

---

☕ EXEMPLO

{job="nginx"} |= "ERROR"

---

☕ ANALOGIA MAINFRAME

Loki	Mainframe
Logs distribuídos	SYSLOG
Labels	Classes JES
Queries	SDSF filtros

---

☕ TEMPO — O “CICS TRACE MODERNO”

Tempo trabalha com:

• distributed tracing

Site:

• Grafana Tempo

---

☕ O QUE É TRACE?

Imagine:

• usuário clica no app
• passa API
• banco
• microserviço
• MQ
• cache

Tempo rastreia:

• toda jornada

---

☕ ANALOGIA MAINFRAME

Quase igual:

• CICS trace
• Db2 accounting trace
• MQ activity trace

---

☕ OPEN TELEMETRY — O “SMF UNIVERSAL”

☕ O QUE É?

Framework padronizado de:

• métricas
• logs
• traces

Site:

• OpenTelemetry

---

☕ POR QUE ISSO MUDOU O MERCADO?

Antes:

• cada ferramenta tinha padrão próprio

Agora:

• tudo fala OpenTelemetry

Virou:

“o TCP/IP da observabilidade”

---

☕ DATA SOURCES MAIS IMPORTANTES NO GRAFANA

Data Source	Uso
Prometheus	Métricas
Loki	Logs
Tempo	Traces
Elasticsearch	Logs/search
InfluxDB	IoT/time series
PostgreSQL	Dados SQL
MySQL	Analytics
CloudWatch	AWS
Azure Monitor	Azure
Splunk	Enterprise logs
OpenSearch	Observabilidade

---

☕ O QUE UM SYSPROG JÚNIOR PRECISA APRENDER?

☕ PRIORIDADE 1

Aprender:

• Grafana
• Prometheus
• PromQL

Isso já abre MUITAS portas.

---

☕ PRIORIDADE 2

Depois:

• Loki
• Alertmanager
• OpenTelemetry

---

☕ PRIORIDADE 3

Avançado:

• Mimir
• Tempo
• Thanos
• Kubernetes observability

---

☕ THA NOS — O “PRIMO DO MIMIR”

Outro projeto famoso:

• Thanos

Também resolve:

• escala
• retenção longa
• HA

Muito usado em Kubernetes.

---

☕ CURIOSIDADES INSANAS

☕ Netflix, Uber, bancos e bolsas usam isso

Hoje observabilidade é:

• missão crítica
• core business

---

☕ Um dashboard ruim pode derrubar operação

Porque:

• operador não vê problema
• alerta errado gera caos
• excesso de métricas vira ruído

Exatamente como:

• console floodado no JES2 ☕💥

---

☕ MÉTRICA DEMAIS VIRA O NOVO “SPAGHETTI”

Empresas geram:

• bilhões de métricas por dia

Sem governança:

• storage explode
• custo explode
• queries ficam lentas

---

☕ O FUTURO

A nova onda:

• AIOps
• IA analisando métricas
• detecção automática
• previsão de falhas
• correlação inteligente

Mas o princípio continua o mesmo desde os tempos do MVS:

“Monitorar, entender e agir antes do desastre.” ☕💾🔥

 

Bellacosa Mainframe Grafana o dashbord de monitoramento mainframe

☕🔥 GRAFANA — O “PAINEL DE CONTROLE DO MAINFRAME MODERNO” QUE TODO SYSPROG JÚNIOR PRECISA CONHECER 🔥☕

Se você veio do mundo do MVS, JES2, RMF, OMEGAMON, SDSF e consoles verdes, prepare o choque cultural:

O Grafana é praticamente o equivalente moderno de um:

• “painel operacional do datacenter”
• console visual de monitoração
• cockpit de performance
• RMF turbinado com esteroides gráficos

E o mais curioso?

Muita gente de distributed acha que inventou observabilidade em 2018…

Enquanto sysprog de mainframe já monitorava CPU, DASD, canais, paging e throughput quando a internet ainda fazia barulho de modem. ☕💾

---

☕ O QUE É GRAFANA?

O Grafana é uma plataforma open source de:

• visualização de métricas
• dashboards
• monitoramento
• observabilidade
• alertas
• analytics

Ele pega dados de várias fontes e transforma tudo em:

• gráficos
• gauges
• tabelas
• alertas
• mapas
• painéis em tempo real

---

☕ A ORIGEM DO GRAFANA

O Grafana nasceu em:

• 2014
• criado por Torkel Ödegaard
• inicialmente na empresa brasileira-norueguesa Orbitz/Neteye
• depois evoluiu para a empresa:
  • Grafana Labs

A ideia original era simples:

“Por que monitoramento corporativo precisa ser feio e complicado?”

E aí nasceu uma interface moderna, web, rápida e absurdamente flexível.

---

☕ HISTÓRIA E EVOLUÇÃO

☕ 2014 — Primeiros Releases

O Grafana surgiu focado em:

• métricas do Graphite
• dashboards simples
• visualização web

Na época já era revolucionário.

Enquanto muita ferramenta corporativa parecia software de 1997…

Grafana parecia tecnologia “do futuro”.

---

☕ 2015–2018 — Explosão DevOps

Com a ascensão de:

• Docker
• Kubernetes
• Cloud
• DevOps
• Prometheus

…o Grafana virou praticamente padrão de mercado.

---

☕ 2019+ — Observabilidade Total

Hoje o Grafana monitora:

• Linux
• Windows
• Kubernetes
• APIs
• Banco de dados
• Mainframe
• Cloud
• aplicações
• logs
• traces
• IoT
• IA

Sim…

Tem empresa usando Grafana para monitorar:

• CICS
• MQ
• z/OS
• Db2
• OpenTelemetry em mainframe

O mundo deu uma volta gigantesca. ☕

---

☕ RELEASES IMPORTANTES

Versão	Destaque
1.x	Primeira geração
2.x	Dashboards melhores
4.x	Alertas modernos
6.x	Transformações de dados
7.x	Painéis novos
8.x	Unified Alerting
9.x	Observabilidade forte
10.x	IA + performance + cloud

---

☕ COMO O GRAFANA FUNCIONA?

Pense assim:

O Grafana NÃO coleta dados sozinho.

Ele funciona como:

• “o painel”
• “a camada visual”
• “o cockpit”

Os dados vêm de:

• Prometheus
• InfluxDB
• Elasticsearch
• Loki
• PostgreSQL
• MySQL
• APIs
• CloudWatch
• Splunk
• OpenTelemetry

---

☕ ANALOGIA MAINFRAME

Mainframe	Grafana World
RMF	Prometheus
OMEGAMON	Observabilidade
SDSF	Dashboards operacionais
JES2 console	Alerting
SMF records	Métricas
Sysview	Grafana

---

☕ CONCEITOS IMPORTANTES

☕ Dashboard

Tela com gráficos e indicadores.

Como um:

• painel do OMEGAMON
• cockpit do operador
• monitor da sala de controle

---

☕ Panel

Cada gráfico individual.

Ex:

• CPU
• memória
• rede
• jobs
• response time

---

☕ Data Source

Origem dos dados.

Ex:

• Prometheus
• Loki
• PostgreSQL

---

☕ Alerting

Alarmes automáticos.

Ex:

• CPU > 90%
• disco cheio
• aplicação caída

Quase um:

“$HASP250 JOB ABENDED” moderno ☕💥

---

☕ CURIOSIDADES QUE QUASE NINGUÉM SABE

☕ O nome “Grafana”

Veio da ideia de:

• “graphs”
• visualização gráfica

---

☕ Empresas gigantes usam

• IBM
• SAP
• PayPal
• eBay
• bancos
• telecoms
• governos

---

☕ Existe integração com mainframe

Hoje existem exporters para:

• z/OS
• CICS
• Db2
• MQ
• SMF

Sim…

Você pode colocar:

• CPU do z/OS
• fila do MQ
• transação CICS

num dashboard moderno web.

Isso explodiria a cabeça de um operador de 1989. ☕💾

---

☕ EASTER EGGS E DETALHES DIVERTIDOS

☕ Dark Theme

Sysprog ama terminal escuro.

O Grafana praticamente virou:

“o ISPF cyberpunk”

---

☕ Playlists Automáticas

Você pode colocar dashboards rotativos em TVs.

Igual:

• NOC
• sala de operações
• centro de monitoração

---

☕ Drill Down

Clicar num gráfico e navegar.

Quase como:

• entrar do SDSF no job
• depois no spool
• depois no SYSOUT

---

☕ INSTALAÇÃO PASSO A PASSO (LAB)

🔥 LAB 01 — PRIMEIRO DASHBOARD NO GRAFANA

---

☕ OBJETIVO

Você vai:

✅ instalar Grafana
✅ acessar via browser
✅ criar datasource
✅ criar dashboard
✅ criar gráficos
✅ salvar painel
✅ fazer manutenção básica

---

☕ CENÁRIO

Imagine:

Você é um sysprog júnior moderno monitorando:

• servidor Linux
• CPU
• memória
• disco

---

☕ PASSO 1 — INSTALAR DOCKER

Linux:

sudo apt update
sudo apt install docker.io -y

Validar:

docker --version

---

☕ PASSO 2 — SUBIR GRAFANA

docker run -d \
--name grafana \
-p 3000:3000 \
grafana/grafana

---

☕ PASSO 3 — ACESSAR

Browser:

http://localhost:3000

Login padrão:

admin
admin

Depois:

• altere senha

---

☕ PASSO 4 — INSTALAR PROMETHEUS

Prometheus coleta métricas.

Criar container:

docker run -d \
--name prometheus \
-p 9090:9090 \
prom/prometheus

---

☕ PASSO 5 — ADICIONAR DATASOURCE

No Grafana:

⚙️ Connections

→ Add new connection

Escolha:

• Prometheus

URL:

http://prometheus:9090

Salvar:

• Save & Test

---

☕ PASSO 6 — CRIAR DASHBOARD

➕ Create

→ Dashboard
→ Add Visualization

Selecionar:

• Prometheus

---

☕ PASSO 7 — PRIMEIRA QUERY

Exemplo:

up

Isso mostra:

• targets online

---

☕ PASSO 8 — CRIAR GRÁFICO DE CPU

Query:

rate(node_cpu_seconds_total[1m])

Tipo:

• Time Series

---

☕ PASSO 9 — ADICIONAR MEMÓRIA

Query:

node_memory_MemAvailable_bytes

---

☕ PASSO 10 — SALVAR DASHBOARD

Nome:

LAB-SYSPROG-JR

---

☕ MANUTENÇÃO BÁSICA

☕ Editar painel

Clique:

• painel
• Edit

---

☕ Duplicar painel

Menu:

• Duplicate

Muito usado em operações.

---

☕ Exportar dashboard

Menu:

• Export JSON

Equivalente moderno de:

“guardar PROC/JCL padrão” ☕

---

☕ BACKUP

Dashboards ficam em:

• banco SQLite interno
• PostgreSQL
• MySQL

Sysprog raiz:

SEMPRE faz backup ☕💾

---

☕ DICAS DE OURO PARA SYSPROG JÚNIOR

☕ 1 — Não crie dashboard “carnaval”

Erro clássico:

• 500 gráficos
• 90 cores
• poluição visual

Operação precisa:

• clareza
• leitura rápida

---

☕ 2 — CPU sem contexto engana

90% CPU pode ser:

• normal
• batch pesado
• pico legítimo

Mesma filosofia do RMF.

---

☕ 3 — Aprenda PromQL

PromQL é o “JCL do observability”.

Quem domina:

• vira referência rapidamente.

---

☕ 4 — Menos é mais

Bons dashboards:

• simples
• objetivos
• operacionais

---

☕ 5 — Nomeie tudo direito

Nunca faça:

Dashboard1
PainelNovo2
TESTEFINALFINAL

Isso vira o:

PROCLIB bagunçado do DevOps ☕💥

---

☕ EXEMPLO DE ESTRUTURA PROFISSIONAL

OPS-LINUX
OPS-K8S
OPS-DB
OPS-MQ
OPS-ZOS
OPS-CICS

---

☕ O FUTURO

Grafana hoje está entrando forte em:

• IA operacional
• observabilidade inteligente
• correlação automática
• AIOps

Mas no fundo…

A lógica continua a mesma do velho operador de mainframe:

“Descobrir problema antes do usuário ligar reclamando.” ☕🔥

---

☕ FRASE FINAL ESTILO BELLACOSA MAINFRAME

“O sysprog antigo olhava SDSF.
O sysprog moderno olha Grafana.
Mas os dois têm a mesma missão:
manter o datacenter vivo enquanto o mundo dorme.” ☕💾🔥