Modernizando a Monitoração UNIX: Como Coletar Métricas de HP-UX, Solaris e AIX com Grafana e Prometheus

20 de agosto de 20266 min de leitura
UNIXObservabilidadeGrafanaPrometheusSNMP

Introdução

Muitas empresas de grande porte sustentam suas operações mais críticas em servidores UNIX tradicionais (como Oracle Solaris, HP-UX ou IBM AIX). Sejam bancos de dados relacionais gigantes, sistemas legados de faturamento ou modelos de ERP (como SAP Business One), essas plataformas UNIX entregam alta estabilidade, mas frequentemente operam como "caixas pretas" para times de monitoração modernos.

Manter consoles de monitoração legadas e desconectadas gera silos operacionais. Neste artigo instrutivo, ensinamos como integrar servidores Solaris, HP-UX e AIX ao ecossistema moderno de observabilidade baseado em Prometheus e Grafana, criando painéis centralizados que facilitam a tomada de decisões preventivas.


🏗️ Desafios Técnicos e a Arquitetura da Solução

Diferente de sistemas Linux modernos, instalar e rodar diretamente o node_exporter padrão em sistemas UNIX comerciais pode ser complexo devido à falta de compilações nativas compatíveis com as bibliotecas do sistema (libc específicas) ou arquiteturas de processadores antigas (como SPARC da Oracle ou PA-RISC da HP).

A solução arquitetural mais robusta utiliza uma ponte de coleta:

[Servidor Solaris / HP-UX / AIX]
              │ (Métricas nativas coletadas via SNMP local)
              ▼
    [Prometheus SNMP Exporter] (Rodando em container Linux)
              │
              ▼
        [Prometheus] <───> [Grafana Dashboard]

Por que SNMP?

O protocolo SNMP (Simple Network Management Protocol) é nativo e extremamente maduro nesses sistemas operacionais. Ativar o daemon SNMP nativo (como o snmpd) em sistemas UNIX consome pouquíssimos recursos de CPU do servidor principal, mantendo a estabilidade exigida para infraestruturas críticas.

⚙️ Passo a Passo da Implementação

Passo 1: Configurar o Daemon SNMP no UNIX

No Oracle Solaris 11, por exemplo, a ativação do serviço SNMP é gerenciada pelo Service Management Facility (SMF):

Habilitar o serviço SNMP

svcadm enable svc:/application/management/net-snmp:default

No AIX, configure o arquivo /etc/snmpdv3.conf para liberar a leitura das MIBs clássicas do sistema (como uso de memória, status de discos e carga de CPU) e reinicie o subsistema:

stopsrc -s snmpd
startsrc -s snmpd

Passo 2: Configurar o SNMP Exporter do Prometheus

Em um servidor Linux intermediário na mesma rede, instale o snmp_exporter oficial do Prometheus. Configure o arquivo snmp.yml para traduzir as MIBs do fabricante do hardware (ex: MIBs de hardware Sun/Oracle ou HP-UX).

Mapeie o target em seu prometheus.yml:

scrape_configs:
  • job_name: 'unix-legacy'
  • static_configs:
  • targets:
  • 192.168.1.100 # IP do servidor Solaris/AIX
  • metrics_path: /snmp params: module: [if_mib] # Módulo SNMP desejado relabel_configs:
  • source_labels: [__address__]
  • target_label: __param_target
  • source_labels: [__param_target]
  • target_label: instance
  • target_label: __address__
  • replacement: 127.0.0.1:9116 # Endereço do snmp_exporter

    O que o sar ainda responde

    O exporter não substitui o diagnóstico no host. Quando o painel fica vermelho, eu entro no Solaris, HP-UX ou AIX e confirmo com o mesmo intervalo de 1 segundo.

    sar -u 1 5
    vmstat 1 5
    iostat -x 1 3
    snmpwalk -v2c -c public 192.0.2.10 1.3.6.1.2.1.25.2.3

    192.0.2.10 aqui é endereço de documentação. No ambiente real o walk usa a community da zona de gerência, nunca a default public deixada no exemplo. Se sar e o Grafana divergem, o scrape do Prometheus está atrasado, não o UNIX.


    📊 Benefícios do Painel no Grafana

    Uma vez que o Prometheus inicia a raspagem (scraping) das métricas de SNMP, o Grafana permite criar painéis ricos visualmente que unem: Capacidade de Disco (Disk Space): Essencial para prever estouros de tablespaces em bancos de dados. Utilização de CPU e Load Average: Identificação de picos de processamento em rotinas batch noturnas. * Métricas de Rede (I/O): Detecção de gargalos de comunicação com o Storage Area Network (SAN).

    Essa centralização elimina a necessidade de manter administradores de sistemas consultando comandos de terminal (sar, vmstat, iostat) isoladamente, trazendo agilidade ao centro de operações de rede (NOC) e aproximando o ambiente legado das melhores práticas de SRE (Site Reliability Engineering).

    Artigos Relacionados