Como Monitorar Pods com Prometheus no OpenShift

O monitoramento de infraestrutura e aplicações em ambientes containerizados é uma das competências mais críticas para equipes de DevOps e SREs (Site Reliability Engineering) modernas. No ecossistema Kubernetes, a observabilidade não é um luxo, mas uma necessidade operacional. Quando migramos para o OpenShift, a plataforma Red Hat que adiciona camadas enterprise ao Kubernetes, a gestão de métricas se torna ainda mais robusta, porém exige entendimento profundo dos componentes subjacentes.

Neste tutorial técnico, vamos detalhar como configurar, validar e utilizar o Prometheus para monitorar pods em um cluster OpenShift. Abordaremos desde a arquitetura nativa até consultas práticas com PromQL, focando em sysadmins, desenvolvedores e engenheiros de infraestrutura que buscam visibilidade real sobre seus workloads.

Arquitetura do Monitoramento no OpenShift

O OpenShift não utiliza o Prometheus "na mão" da mesma forma que um cluster vanilla do Kubernetes. Ele emprega uma abordagem declarativa baseada em Operadores. O componente central é o Prometheus Operator, que automatiza a implantação, configuração e gerenciamento de instâncias do Prometheus.

A arquitetura padrão no OpenShift divide o monitoramento em dois níveis principais:

Cluster Monitoring: Gerencia as métricas da infraestrutura do próprio cluster (kubelet, apiserver, etcd) e dos componentes do control plane. Este conjunto de dados é gerenciado automaticamente pela plataforma e não deve ser alterado manualmente pelos usuários.
User-Defined Metrics: Permite que desenvolvedores e administradores de namespaces específicos criem seus próprios objetos Prometheus para monitorar aplicações específicas dentro de seus projetos (namespaces).

Para este guia, focaremos na criação e configuração do monitoramento definido pelo usuário, pois é aqui que a customização para monitoramento de pods específicos ocorre.

Pré-requisitos e Verificação de Acesso

Antes de iniciar, certifique-se de ter as seguintes ferramentas instaladas em sua estação de trabalho local:

Cliente oc (OpenShift CLI) configurado e logado.
Acesso com permissões de administrador ou editor no namespace alvo.
Um projeto (namespace) existente onde os pods serão criados.

Verifique sua conexão executando:

oc whoami
oc project

Se o comando retornar seu usuário e o nome do namespace corretamente, você está pronto para prosseguir.

Etapa 1: Implantando uma Aplicação de Exemplo

Para demonstrar o monitoramento, precisamos de workloads ativos. Vamos criar um deployment simples que gera métricas HTTP. Utilizaremos a imagem pública do prom/node-exporter ou uma aplicação Python básica, mas para fins didáticos rápidos, vamos usar um pod genérico com um servidor web simples.

Crie o arquivo app.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
  labels:
    app: demo-monitoring
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-monitoring
  template:
    metadata:
      labels:
        app: demo-monitoring
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Implante a aplicação:

oc apply -f app.yaml

Aguarde até que os pods estejam em estado Running:

oc get pods -l app=demo-monitoring

Etapa 2: Configurando o ServiceMonitor

O coração do monitoramento personalizado no OpenShift é o recurso ServiceMonitor. Ele diz ao Prometheus Operator onde encontrar as métricas. O operador lê esses CRDs (Custom Resource Definitions) e gera a configuração do Prometheus dinamicamente.

Primeiro, precisamos de um Service Kubernetes que exponha os pods:

apiVersion: v1
kind: Service
metadata:
  name: demo-service
  labels:
    app: demo-monitoring
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: demo-monitoring

Aplique o serviço:

oc apply -f service.yaml

Agora, crie o ServiceMonitor. Este é o passo crucial. Ele instrui o Prometheus a fazer scrape (coleta) no endpoint /metrics do serviço criado:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: demo-monitor
  labels:
    app: demo-monitoring
spec:
  selector:
    matchLabels:
      app: demo-monitoring
  endpoints:
  - port: http
    path: /metrics
    interval: 15s

Expliqueção técnica:

selector.matchLabels: Deve corresponder às labels do Service Kubernetes. Isso garante que o Prometheus saiba quais serviços rastrear.
endpoints.port: Deve corresponder ao nome da porta definida no Service (http).
interval: Frequência de coleta (neste caso, a cada 15 segundos).

Implante o monitor:

oc apply -f servicemonitor.yaml

Etapa 3: Verificando a Configuração do Prometheus

O OpenShift gerencia o Prometheus em um namespace especial chamado openshift-monitoring. No entanto, para monitoramento definido pelo usuário, o operador cria uma configuração dedicada no mesmo namespace onde seus recursos estão.

Para verificar se o ServiceMonitor foi reconhecido, examine os logs do Prometheus Operator:

oc logs -n openshift-monitoring deploy/prometheus-operator

Procure por mensagens de sucesso relacionadas ao seu namespace e nome do monitor. Se houver erros de validação, eles aparecerão aqui.

Você também pode verificar os endpoints ativos no painel web do Prometheus (se exposto via Route) ou usando a API:

oc port-forward -n openshift-monitoring svc/prometheus-k8s 9090:9090

Acesse http://localhost:9090/targets no navegador. Você deve ver o alvo do seu serviço listado como UP. Se estiver DOWN, verifique as regras de firewall, endpoints dos pods e se a porta está correta.

Etapa 4: Consultando Métricas com PromQL

Com o scrape ativo, é hora de analisar os dados. O OpenShift expõe uma interface Grafana integrada para usuários finais, mas entender o PromQL (Prometheus Query Language) é essencial para automação e troubleshooting profundo.

Se você estiver usando a GUI do OpenShift Console:

Navegue até o seu projeto.
Clique na aba "Observe" (Observar).
Selecione "Metrics" (Métricas).

Exemplos de consultas úteis para monitoramento de pods:

1. Uso de CPU por Pod:

sum(rate(container_cpu_usage_seconds_total{namespace="seu-namespace", pod=~"demo-app-*"}[5m])) by (pod)

2. Consumo de Memória Residente (RSS):

container_memory_working_set_bytes{namespace="seu-namespace", pod=~"demo-app-*"}

3. Taxa de Requisições HTTP (se o app expuser stats):

rate(http_requests_total{pod=~"demo-app-*"}[5m])

Dica técnica: Use a função rate() para métricas do tipo Counter. Ela calcula a taxa média por segundo desde o último scrape, corrigindo reinicializações de contadores.

Etapa 5: Alertas e Notificações

Monitorar sem alertar é apenas observação passiva. No OpenShift, podemos definir regras de alerta que disparam notificações via PagerDuty, Slack ou Email quando as métricas excedem limites.

Crie um arquivo alertingrules.yaml:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: demo-alerts
  labels:
    app: demo-monitoring
spec:
  groups:
  - name: demo.rules
    rules:
    - alert: HighCPUUsage
      expr: sum(rate(container_cpu_usage_seconds_total{namespace="seu-namespace", pod=~"demo-app-*"}[5m])) by (pod) > 0.8
      for: 2m
      labels:
        severity: warning
      annotations:
        summary: "Alto uso de CPU no pod {{ $labels.pod }}"
        description: "O pod {{ $labels.pod }} está usando mais de 80% de CPU por 2 minutos."

Este alerta verifica se a taxa de uso de CPU ultrapassa 0.8 (80%) continuamente por 2 minutos. Ao aplicar:

oc apply -f alertingrules.yaml

O OpenShift integra essas regras ao sistema de alertas nativo. Você pode visualizar os alertas disparados na aba "Alerts" do Console do OpenShift ou consultando a API do Prometheus.

Boas Práticas e Troubleshooting Comum

Ao implementar monitoramento em produção, considere as seguintes diretrizes para manter sua infraestrutura estável:

1. Rótulos (Labels) Consistentes:

Garanta que seus pods tenham labels ricas e consistentes. Métricas sem rótulos adequados tornam-se impossíveis de correlacionar posteriormente. Use labels como app.kubernetes.io/version, team ou environment.

2. Limites de Recursos (Resource Quotas):

O Prometheus consome memória e CPU para armazenar dados em TSDB (Time Series Database). Defina limites claros no Prometheus CRD se você estiver gerenciando instâncias personalizadas fora do padrão, para evitar que o processo de monitoramento derrube seu nó.

3. Retenção de Dados:

Verifique a configuração de retenção. No OpenShift, dados de longo prazo são geralmente encaminhados para soluções de armazenamento externo (como S3 ou EBS) via configuração do Operator. Não confie no storage local do pod Prometheus para dados críticos de auditoria.

4. Troubleshooting de Conexões Recusadas:

Se os targets estão DOWN, use o comando oc debug para testar conectividade interna:

oc debug node/<nome-do-node>
chroot /host
curl -v http://<ip-do-pod>:80/metrics

Isso ajuda a distinguir entre problemas de rede do cluster (CNI) e problemas na aplicação (porta errada, firewall interno).

Integração com Grafana

O OpenShift vem com o Grafana pré-instalado. Para visualizar as métricas coletadas:

Acesse a rota do Grafana do cluster (geralmente encontrada no menu de administração ou via oc get route -n openshift-monitoring grafana).
Faça login com suas credenciais de usuário OpenShift.
Navegue até "Dashboards" > "Browse".
Crie um novo dashboard e adicione painéis usando as consultas PromQL discutidas anteriormente.

O Grafana no OpenShift já possui integrações nativas com o Prometheus, facilitando a criação de dashboards unificados que mostram tanto a saúde da infraestrutura quanto a performance da aplicação.

Conclusão

A configuração de monitoramento de pods com Prometheus no OpenShift é um processo robusto que beneficia-se enormemente da automação oferecida pelo Operator Framework. Ao utilizar ServiceMonitor e PrometheusRule, você alinha a infraestrutura DevOps com práticas GitOps, mantendo suas definições de monitoramento versionadas e auditáveis.

Lembre-se: monitoramento não é "configure e esqueça". Requer manutenção contínua das consultas, ajuste de limites de alertas para evitar fadiga de notificações e revisão periódica da relevância das métricas coletadas. Com as ferramentas corretas e a arquitetura adequada, você transforma dados brutos de pods em inteligência acionável para sua operação.

Para mais informações detalhadas sobre a API do Prometheus Operator, consulte a documentação oficial da Red Hat OpenShift e o repositório GitHub do projeto Prometheus Operator.

Tags: #prometheus #openshift #monitoramento #pods #kubernetes #infraestructura #devops #linux