Manual de instalación y configuración del Agente SNMP de FirstWave

Introducción

El Agente SNMP de FirstWave es una herramienta de monitoreo que recopila métricas e información de sistemas de bases de datos Oracle y las expone a través de SNMP (Simple Network Management Protocol / Protocolo Simple de Administración de Red). Este documento lo guiará en la instalación y configuración del agente en su sistema anfitrión con base de datos Oracle.

Entendiendo net-snmp y AgentX

¿Qué es net-snmp?

Net-SNMP es una implementación de código abierto del Protocolo Simple de Administración de Red (SNMP). Proporciona:

Herramientas y bibliotecas para utilizar e implementar SNMP.
Un agente extensible para monitorear recursos del sistema.
Soporte para los protocolos SNMP v1, v2c y v3.
Un marco para extender las capacidades de monitoreo.

SNMP se utiliza ampliamente en los sistemas de gestión de red para monitorear dispositivos y servidores conectados a la red, con el fin de detectar condiciones que requieren atención administrativa.

¿Qué es AgentX?

AgentX es un protocolo definido en la RFC 2741 que permite que un agente SNMP maestro sea ampliado mediante subagentes. Sus características clave incluyen:

Arquitectura maestro/subagente: El daemon de net-snmp actúa como agente maestro, mientras que el Agente de FirstWave funciona como subagente.
Extensión dinámica: Los subagentes pueden registrarse y cancelarse dinámicamente sin necesidad de reiniciar el agente maestro.
Gestión de subárboles MIB: Los subagentes pueden gestionar partes específicas de la Base de Información de Gestión (MIB) de SNMP.
Independencia del protocolo: La comunicación entre el agente maestro y los subagentes utiliza un protocolo estandarizado.

En su configuración, el Agente de FirstWave se conecta al daemon de net-snmp utilizando el protocolo AgentX para exponer métricas de la base de datos Oracle a través de SNMP.

¿Por qué es necesario AgentX?

Modularidad: Permite que múltiples subagentes manejen diferentes componentes del sistema (por ejemplo: uno para Oracle, otro para MySQL, otro para métricas del sistema).
Separación de responsabilidades: El agente maestro se enfoca en la coordinación, mientras que cada subagente administra un dominio específico.
Sin reinicios: Los subagentes pueden agregarse o eliminarse sin necesidad de reiniciar snmpd, lo que minimiza el impacto en producción.
Estandarización: Al ser un protocolo definido por RFC, es interoperable y está soportado por muchos fabricantes.

¿Cuál es la esencia de AgentX?

La esencia de AgentX es desacoplar la implementación y el mantenimiento del agente SNMP, permitiendo:

Mayor flexibilidad para extender funcionalidades SNMP sin afectar el sistema base.
La coexistencia de múltiples soluciones de monitoreo que deseen exponer métricas a través del mismo agente SNMP.
El establecimiento de una estructura estandarizada y eficiente de comunicación entre subagentes y el agente maestro.

Consumo de RAM y CPU

En general, AgentX tiene un consumo muy bajo de recursos, pero aquí algunos detalles clave:

Uso de RAM: El subagente puede consumir entre 10 y 50 MB, dependiendo de su configuración y del volumen de métricas consultadas.
Uso de CPU: Bajo, generalmente menos del 1% en condiciones normales. El subagente solo responde cuando se realiza una consulta SNMP hacia su MIB.
Uso de red: Nulo o mínimo (la comunicación maestro–subagente es local).

Es posible aplicar límites de CPU, memoria e I/O de systemd al agente Firstwave en caso de ser necesario. Con esto se pueden establecer, por ejemplo, un uso máximo de memoria o una cuota de CPU. La ventaja de systemd es que incluye por defecto un sistema unificado de control de recursos y su configuración es sencilla. Para limitar recursos de un servicio basta con crear una configuración:

sudo systemctl edit nombredelservicio

Y agregar una sección como la siguiente:

[Service]
CPUWeight=20
CPUQuota=85%
IOWeight=20
MemorySwapMax=0

CPUWeight: valor relativo (por defecto 100) que define la prioridad de CPU frente a otros procesos.
CPUQuota: límite absoluto de CPU expresado en porcentaje (por ejemplo, 85%).
IOWeight: peso relativo para operaciones de disco.
MemorySwapMax: límite para evitar uso excesivo de swap.

Estas opciones permiten evitar que un servicio consuma recursos en exceso y mantener estable el sistema. Para aplicar los cambios, deberá ejecutarse:

sudo systemctl daemon-reload

Requisitos previos

Requisitos del sistema

Antes de instalar el Agente de FirstWave, asegúrese de contar con lo siguiente en el sistema anfitrión:

Versión de net-snmp: Se requiere la versión mínima 5.0.
Base de datos Oracle: Debe estar instalada y en ejecución en el sistema anfitrión, con una versión mínima 10.2.
Acceso a red: El sistema anfitrión debe ser accesible desde NMIS a través de:
- ICMP (ping).
- SNMP (puerto 161).
- SSH (puerto 22): Requerido para que opConfig recupere la salida del trabajo desde el binario.
Acceso al sistema: Acceso con privilegios de root o sudo.
Detalles de conexión a Oracle: Nombre del host, puerto, nombre del servicio y credenciales.

Requisitos del usuario de la base de datos Oracle

El Agente de FirstWave requiere un usuario dedicado en Oracle con privilegios específicos. Se ha probado el agente con la siguiente configuración de usuario:

CREATE USER fw_monitoring_user IDENTIFIED BY your_secure_password;
GRANT CREATE SESSION TO fw_monitoring_user;
GRANT SELECT_CATALOG_ROLE TO fw_monitoring_user;

Nota de seguridad: Recomendamos encarecidamente utilizar un usuario dedicado exclusivamente para monitoreo con privilegios mínimos, en lugar de cuentas del sistema como sys.

Pasos de instalación en el servidor de NMIS

1. Descargar y subir el archivo de modelo

Descargar el archivo Model-oracleDB.nmis desde aquí:
Colocar el archivo en el directorio de modelos personalizados del sistema:

/usr/local/nmis9/models-custom

Ejecutar lo siguiente para ajustar permisos:

/usr/local/nmis9/bin/nmis-cli act=fixperms

2. Agregar el sistema anfitrión a NMIS

Debe agregarse el servidor que contiene la base de datos a NMIS, ya sea usando alguno de los siguientes métodos

a) Vía NMIS:

Acceder a NMIS > System Configuration > NMIS Nodes (devices) > Action > add

Agregar los datos del nodo en la tabla forzando el modelo oracleDB. Si se va a agregar SNMPv3, deberá configurarse en el apartado SNMP Settings que aparece en la parte inferior de la tabla. Dar clic en Add and Update Node.

Si se agrega de esta forma, el nodo deberá activarse para opEvents y opConfig, accediendo al módulo de Administración (ipserver/omk/admin) > Nodes > seleccionar el nodo > Activation > seleccionar Enabled en los tres parámetros.

b) Vía módulo de Administración:

Acceder al módulo de administración (ipserver/omk/admin) > Nodes > botón + (add)

Agregar los datos correspondientes del nodo (Nombre, IP, Grupo).
Activation > NMIS, opEvents y opConfig en Enabled.
Polling > Active, Ping, Collect: True | Model: oracleDB.
SNMP > Agregar credenciales SNMP según corresponda.
Dar clic en Save Changes. El nodo aparecerá en NMIS y los módulos.

3. Agregar conjunto de credenciales y comandos para opConfig

Para obtener los inicios de sesión, bloqueos, cursores y trabajos, será necesario utilizar el conjunto de comandos de opConfig, el cual incluye los comandos necesarios para obtener dicha información.

Agregar credenciales SSH del servidor anfitrión de la base datos a opConfig accediendo a opConfig > System > Edit Credential Sets > Add Credential Set

Colocar las credenciales correspondientes. Dar clic en Save Credential Set.

Acceder a System > Edit Nodes > Seleccionar el nodo anteriormente agregado > Connection > Transport: SSH | Credential Set: seleccionar la credencial que fue creada anteriormente.

Descargar el archivo oracle_db.json desde aquí:
Colocar el archivo en el directorio de sets de comandos del sistema:

/usr/local/omk/conf/command_sets.d

Ejecutar lo siguiente para ajustar permisos:

chmod 664 oracle_db.json
chown root:root oracle_db.json

Los comandos contenidos en el archivo de command sets oracle_db.json, forman parte de la configuración del agente. A continuación, se detalla cada uno de ellos:

/usr/local/bin/firstwave-agent report oracle logins: genera un reporte sobre sesiones activas de Oracle (usuarios conectados/logins).
/usr/local/bin/firstwave-agent report oracle cursors: reporta el estado de los cursores Oracle (recursos que gestionan las sentencias SQL abiertas, muy usados para diagnóstico de consumo de memoria o problemas de límite de cursores).
/usr/local/bin/firstwave-agent version: devuelve la versión del agente firstwave-agent, útil para inventario o debugging.
/usr/local/bin/firstwave-agent report oracle jobs: genera un reporte de jobs programados en Oracle (tareas automatizadas dentro de la base de datos).Se ejecuta solo con la etiqueta "SUNDAY", es decir, los domingos.
/usr/local/bin/firstwave-agent report oracle locks: reporta los bloqueos de Oracle (locks en tablas, filas, objetos), importante para detectar cuellos de botella o deadlocks.

4. Ejecutar la tarea programada cada domingo

Editar el archivo de cron para opConfig (se recomienda generar un backup, copiando el archivo a otra carpeta, nunca duplicar el archivo en cron.d porque puede provocarse un mal funcionamiento de las tareas automatizadas):

/etc/cron.d/opconfig

Agregar lo siguiente. La instrucción debe der ir en una sola línea de texto (esto ejecutará el comando que contiene el tag "SUNDAY" cada domingo a las 00:00hrs):

# Oracle DB
0 0 * * 0       root    export PERL5LIB=/usr/share/perl5:/usr/local/lib64/perl5:/usr/lib64/perl5 PAR_GLOBAL_TMPDIR=/usr/local/omk/var/lib/common/||:;   /usr/local/omk/bin/opconfig-cli.pl quiet=1 act=run_command_sets tags="SUNDAY"

Guardar el archivo y reiniciar el servicio crond:

service crond restart

Pasos de instalación en el sistema anfitrión de la base de datos

1. Descargar e instalar el binario

Descargar usando el link: https://dl-nmis.opmantek.com/firstwave-agent-0.0.1
O bien desde aquí:
Colocar el archivo en el directorio de binarios del sistema:

/usr/local/bin/

Ejecutar lo siguiente para ajustar el nombre del archivo:

cd /usr/local/bin/
mv firstwave-agent-0.0.1 firstwave-agent

Se debe hacer que el binario sea ejecutable:

cd /usr/local/bin/
sudo chmod +x firstwave-agent

Verificar que el binario sea accesible:

/usr/local/bin/firstwave-agent version

2. Crear un servicio del sistema

Crear un archivo de servicio systemd para gestionar el agente FirstWave:

sudo nano /etc/systemd/system/firstwave-agent.service

Agregar el siguiente contenido al archivo de servicio:

[Unit]
Description=FirstWave Oracle Monitoring Agent
Documentation=https://docs.community.firstwave.com
After=network.target oracle.service snmpd.service
Wants=oracle.service snmpd.service

[Service]
Type=simple
User=nmis
Group=nmis

# Start the agent
ExecStart=/usr/local/bin/firstwave-agent

# Restart policy
Restart=always
RestartSec=10

# Logging
StandardOutput=journal
StandardError=journal
SyslogIdentifier=firstwave-agent

[Install]
WantedBy=multi-user.target

Nota: el usuario nmis y el grupo nmis son un ejemplo. Esto se refiere al usuario que ejecutará y será propietario del proceso. Si es posible utilizar root:root, se puede proceder.

3. Configurar la conexión a Oracle

Nota importante de seguridad: El ORACLE_DSN contiene credenciales sensibles. Se deben asegurar las medidas de seguridad adecuadas:

a) Permisos de archivo: Restringir el acceso al archivo de servicio.

sudo chmod 600 /etc/systemd/system/firstwave-agent.service

b) Utilizar un usuario adecuado de Oracle: En lugar de emplear el usuario sys, se debe crear un usuario de monitoreo dedicado con los privilegios mínimos necesarios.

4. Crear archivo de configuración de entorno

Se debe crear un archivo de entorno dedicado para almacenar los detalles de conexión a la base de datos Oracle.
- Crear directorio de configuración y archivo de entorno (llamado environment):

sudo mkdir -p /etc/firstwave-agent
sudo nano /etc/firstwave-agent/environment

Agregar el siguiente contenido al archivo de entorno (llamado environment):

# Oracle Database Connection Configuration
# Format: oracle://username:password@hostname:port/servicename
ORACLE_DSN=oracle://fw_monitoring_user:your_secure_password@example.opmantek.net:1521/FREEPDB1

servicename: es el Service Name de la base de datos Oracle, que identifica a qué instancia o base de datos lógica se conectará el cliente. En el ejemplo del manual se usa FREEPDB1, pero en su entorno debe reemplazarse por el nombre de servicio que corresponda.

password y your_secure_password: ambos se refieren a la contraseña del usuario de la base de datos. En el ejemplo, your_secure_password es un marcador de posición para que lo reemplacen por la contraseña real.

username y fw_monitoring_user: ambos se refieren al nombre de usuario de la base de datos. En el ejemplo, fw_monitoring_user es solo un nombre ficticio.

Si el Service Name fuera, por ejemplo, BANOBRASBD, la cadena sería:

ORACLE_DSN=oracle://Monitoreo:123456789@servidor.ejemplo.com:1523/BANOBRASBD

Donde:

Monitoreo = usuario

123456789 = contraseña

servidor.ejemplo.com = reemplazar por el hostname o IP real

1523 = puerto que indicaron

BANOBRASBD = Service Name de la base de datos

Asegurar el archivo de entorno, estableciendo la propiedad y permisos adecuados:

sudo chown root:nmis /etc/firstwave-agent/environment
sudo chmod 640 /etc/firstwave-agent/environment

Nota: el usuario root y el grupo nmis son un ejemplo. Esto se refiere al usuario que ejecutará y será propietario del proceso. Si es posible utilizar root:root, se puede proceder.

5. Configurar net-snmp para AgentX

Se debe de tener instalado net-snmp: para instalar net-snmp en un servidor de base de datos Oracle, el procedimiento depende del sistema operativo que esté usando el servidor (por ejemplo, RHEL, Oracle Linux, CentOS, Debian, etc.). Esto debe de ser realizado por el operador experto de la Base de Datos.

Verificar el sistema operativo

cat /etc/os-release

Instalación en Oracle Linux / RHEL / CentOS: en estos sistemas, net-snmp se instala con yum o dnf:

sudo yum install net-snmp net-snmp-utils -y

o en versiones más nuevas:

sudo dnf install net-snmp net-snmp-utils -y

Esto instala:

net-snmp: el servicio SNMP (snmpd).

net-snmp-utils: comandos como snmpwalk, snmpget, etc.

Instalación en Debian / Ubuntu: si el servidor Oracle usa una distribución basada en Debian:

sudo apt update
sudo apt install snmp snmpd -y

Habilitar y arrancar el servicio en sistemas con systemd:

sudo systemctl enable snmpd
sudo systemctl start snmpd
sudo systemctl status snmpd

Después, se debe asegurar que net-snmp esté configurado para aceptar conexiones AgentX, en el archivo:

/etc/snmp/snmpd.conf

Agregar o verificar las siguientes líneas:

# Enable AgentX support
master agentx
agentXSocket tcp:localhost:705

# Optional: Set AgentX permissions
agentXPerms 0660 0550

Reiniciar snmpd:

sudo systemctl restart snmpd

6. Iniciar y habilitar el servicio

Recargar systemd para reconocer el nuevo servicio:

sudo systemctl daemon-reload

Iniciar el agente FirstWave:

sudo systemctl start firstwave-agent

Habilitar el inicio automático:

sudo systemctl enable firstwave-agent

Verificar el estado del servicio:

sudo systemctl status firstwave-agent

7. Verificar la instalación

Ver los logs recientes:

sudo journalctl -u firstwave-agent -n 50

Seguir los registros en tiempo real:

sudo journalctl -u firstwave-agent -f

Anexos

Impacto en el rendimiento y configuración

Dependiendo de su configuración y del volumen de métricas consultadas

El agente FirstWave ejecuta consultas a la base de datos Oracle cada 5 minutos para recopilar métricas de rendimiento, las cuales son almacenadas en caché y puestas a disposición para sondeos SNMP por parte de NMIS. Las consultas basadas en SSH ejecutadas por opConfig tienen una frecuencia variable en función de los intervalos de sondeo configurados para el conjunto de comandos.

En escenarios de implementación típicos, se espera un impacto mínimo en el rendimiento del sistema host y de la base de datos Oracle, ya que el agente está diseñado para una recolección de datos ligera y eficiente.

Requerimientos de recursos

Requerimientos de espacio en disco
- Huella de instalación / Installation footprint (espacio o recursos después de su instalación): aproximadamente 10–30 MB para el binario y los archivos de configuración.
- Archivos de registro (logs): estimados 10–20 MB para el registro estándar.
- Requerimiento total estimado: menos de 50 MB.
Consumo de ancho de banda
- Sondeo SNMP: consumo mínimo de ancho de banda (unos pocos MB por día en configuraciones típicas).
- Recolección de datos por SSH: variable según la frecuencia de comandos configurada en opConfig.
- Consumo total estimado: unos pocos MB por día bajo cargas de monitoreo estándar.
Puertos y protocolos de red requeridos
- Entrantes (Inbound)
  - Puerto 161 (UDP): acceso de sondeo SNMP.
  - Puerto 22 (TCP): acceso SSH para recolección de datos con opConfig.
- Salientes (Outbound)
  - Puerto de base de datos Oracle (típicamente 1521): conectividad a la base de datos en localhost (agente instalado en el servidor de base de datos objetivo).
  - Puerto 705 (TCP): comunicación interna de AgentX (solo localhost).
- Internos (Internal)
  - Puerto 705: comunicación del protocolo AgentX entre FirstWave Agent y el demonio net-snmp (socket local, sin tráfico externo).

Impacto del control de recursos con Systemd

Consecuencias de los límites de recursos

Si se aplican límites de recursos de systemd al servicio FirstWave Agent:

Límites de memoria: al acercarse a los límites de memoria configurados, el kernel de Linux primero restringirá la asignación de memoria, lo que podría causar tiempos de respuesta más lentos.
Límites estrictos (hard limits): si el agente excede los límites máximos configurados, systemd terminará el proceso para proteger la estabilidad del sistema.
Límites de CPU: puede aplicarse limitación (throttling) de CPU, lo que podría afectar la frecuencia de recolección de datos.
Recuperación automática: el servicio está configurado con Restart=always y RestartSec=10, lo que garantiza el reinicio automático tras una terminación.

Recomendación: Los límites de recursos proporcionan protección al sistema, mientras que la política de reinicio asegura la continuidad del monitoreo.

Requerimiento de acceso SSH

¿Por qué se requiere SSH a pesar del uso de SNMPv3?

Aunque la recolección principal de métricas utiliza SNMP v3 por motivos de seguridad y estandarización, el acceso SSH es necesario para la recolección de los datos mediante la ejecución de los comandos contenidos en el archivo oracle_db.json.

Las métricas de rendimiento y administración de Oracle (como las tareas automatizadas dentro de la base de datos y los bloqueos), no pueden exponerse de manera eficiente a través del marco de SNMP.
Integración con opConfig: Algunos puntos de monitoreo (como analíticas de inicio de sesión de usuarios e información detallada de sesiones) se recopilan mejor mediante comandos basados en SSH en lugar de consultas SNMP.
Recolección flexible de datos: SSH permite obtener datos complejos y multidimensionales que no se ajustan bien a la estructura jerárquica de las MIB de SNMP.

Nota: la conexión SSH es de solo lectura y se utiliza exclusivamente para la recolección de datos de monitoreo mediante los comandos contenidos en el archivo mencionado.

La frecuencia de ejecución de los comandos vía SSH será la siguiente:

/usr/local/bin/firstwave-agent report oracle logins: cada hora
/usr/local/bin/firstwave-agent report oracle cursors: cada hora
/usr/local/bin/firstwave-agent version: cada hora
/usr/local/bin/firstwave-agent report oracle jobs: domingos a las 00:00hrs
/usr/local/bin/firstwave-agent report oracle locks: cada hora

Requerimientos de acceso al sistema

Privilegios Root/Sudo

El acceso root o sudo solo se requiere durante la instalación para:

Colocar el binario en /usr/local/bin/
Crear el archivo de servicio de systemd.
Configurar los permisos de archivos.
Realizar la configuración inicial y el registro del servicio.

Ejecución en tiempo de operación

El agente se ejecuta bajo una cuenta de usuario dedicada (usuario nmis) y no requiere privilegios elevados durante la operación normal.

Configuración de conexión a Oracle

Definición de ORACLE_DSN

ORACLE_DSN es el Oracle Data Source Name, una cadena de conexión que contiene todos los parámetros necesarios para establecer conexión con el servidor local de base de datos Oracle. Sigue el formato:

oracle://username:password@hostname:port/servicename

Credenciales sensibles

Los siguientes elementos dentro de ORACLE_DSN se consideran sensibles:

Usuario y contraseña de la base de datos para el usuario dedicado de monitoreo (fw_monitoring_user).
Nombre del servicio de Oracle (puede revelar la estructura interna de la base de datos).
Detalles de conexión de la base de datos (combinación de hostname/puerto).
Medidas de seguridad: Estas credenciales se almacenan en /etc/firstwave-agent/environment con permisos de archivo restringidos (640) y propiedad root:nmis.

Seguridad del puerto 705

Cifrado y seguridad de la comunicación

El puerto 705 se utiliza para la comunicación del protocolo AgentX entre el agente FirstWave y el demonio net-snmp. Sus características de seguridad son:

Solo socket local: La comunicación ocurre exclusivamente en localhost (127.0.0.1).
Sin tráfico externo: El tráfico del puerto 705 nunca sale del sistema host.
Protocolo interno: Utiliza el protocolo estándar AgentX para la comunicación maestro/subagente.
No se requiere cifrado: Dado que el tráfico está confinado a la comunicación local entre procesos, no es necesario el cifrado.

Este canal de comunicación interna no representa un riesgo de seguridad externo, ya que no puede ser accedido desde fuera del sistema host.

Matriz de compatibilidad

Soporte de sistema operativo

Distribuciones Linux soportadas:

Cualquier distribución Linux de 64 bits con soporte para systemd.
Probado y verificado: Debian 12 (plataforma principal de pruebas).
Compatibilidad teórica: RHEL/CentOS 7+, Ubuntu 18.04+, SUSE Linux Enterprise 12+.
Requerimientos mínimos: Kernel de Linux 3.10+, systemd 219+, glibc 2.17+.

Compatibilidad con base de datos Oracle

Versiones soportadas formalmente:

Oracle 23c: probado bajo esta versión.

Notas de compatibilidad

Mantenemos la máxima compatibilidad al no requerir las funciones de unified_auditing.
- El agente utiliza vistas estándar del sistema Oracle disponibles en todas las versiones soportadas.
- Las pruebas se realizan principalmente en Oracle 23c con validación de compatibilidad retroactiva.

Arquitectura técnica

Descripción general de la arquitectura del sistema

El agente FirstWave funciona como un puente entre los sistemas de base de datos Oracle y la infraestructura de monitoreo SNMP.

Componentes principales:

Módulo de conectividad Oracle: establece conexiones seguras a Oracle utilizando credenciales dedicadas de monitoreo.
Motor de recolección de datos: ejecuta consultas de solo lectura sobre las vistas del sistema Oracle y tablas de rendimiento.
Interfaz AgentX: se comunica con el demonio net-snmp mediante el protocolo AgentX.
Capa de caché: almacena las métricas recopiladas para un sondeo SNMP eficiente.

Interacción con el sistema operativo

Gestión de procesos: se ejecuta como un servicio gestionado por systemd bajo una cuenta de usuario dedicada.
Acceso al sistema de archivos: lee la configuración desde /etc/firstwave-agent/environment.
Pila de red: se vincula a localhost:705 para la comunicación AgentX.
Registro (logging): envía la salida al journal de systemd para la gestión centralizada de logs.

Interacción con la base de datos Oracle

Método de conexión: utiliza librerías cliente de Oracle para conectividad nativa a la base de datos.
Ejecución de consultas: realiza operaciones SELECT de solo lectura sobre:
- Vistas de rendimiento: V$
- Vistas administrativas: DBA_
- Tablas de estadísticas del sistema.
Modelo de seguridad: opera con los privilegios mínimos requeridos a través de un usuario dedicado de monitoreo.
Gestión de conexiones: Mantiene conexiones persistentes con manejo de timeout configurable.

Recolección y transmisión de datos

Ciclo de recolección: ejecuta consultas a Oracle cada 5 minutos.
Procesamiento de datos: da formato a las métricas recopiladas según las especificaciones de las MIB de SNMP.
Caché: almacena los datos procesados en memoria para respuestas inmediatas de SNMP.
Exposición SNMP: pone los datos en caché a disposición de net-snmp mediante el protocolo AgentX.
Recolección por SSH: recolección paralela de métricas extendidas mediante SSH para integración con opConfig.

Archivos de configuración y componentes

Model-oracleDB.nmis

Propósito: archivo de definición de modelo de NMIS9 que especifica el comportamiento de sondeo SNMP.
Ubicación: directorio models-custom dentro de la instalación de NMIS.
Función: define qué OIDs se deben sondear, las frecuencias de sondeo y las reglas de procesamiento de datos para las métricas de base de datos Oracle recopiladas por el agente FirstWave.

oracle_db.json

Propósito: archivo de configuración de opConfig que define la recolección de datos basada en SSH.
Función: especifica conjuntos de comandos, cronogramas de ejecución y reglas de análisis de datos para métricas recopiladas vía SSH que complementan los datos de SNMP.

firstwave-agent-0.01

Propósito: binario ejecutable central de monitoreo.
Función:
- Establece conexiones con la base de datos Oracle utilizando el DSN configurado.
- Proporciona acceso en tiempo real por CLI para consultas de solo lectura de datos de monitoreo y rendimiento.
- Se comunica con el demonio net-snmp mediante el protocolo AgentX para exponer métricas de Oracle.
- Maneja la recolección, procesamiento y almacenamiento en caché de datos tanto para sistemas de monitoreo basados en SNMP como en SSH.

Características operativas

Diseño liviano y monohilo.
Eficiencia en memoria con connection pooling configurable.
Manejo automático de reconexión para la conectividad a la base de datos.
Registro de errores y reportes de estado completos.

Operaciones de consultas a la base de datos

Consultas SQL ejecutadas por el agente

El agente FirstWave ejecuta las siguientes consultas de solo lectura contra la base de datos Oracle para recopilar métricas de monitoreo.

Monitoreo del estado de los jobs:

SELECT
  jr.JOB_NAME,
  jr.STATUS,
  jr.ERROR#,
  TO_CHAR(jr.ACTUAL_START_DATE, 'YYYY-MM-DD HH24:MI:SS') as run_date,
  TO_CHAR(jr.LOG_DATE, 'YYYY-MM-DD HH24:MI:SS') as log_date
FROM DBA_SCHEDULER_JOB_RUN_DETAILS jr
WHERE jr.ACTUAL_START_DATE >= TRUNC(SYSDATE) - 1
  AND jr.ACTUAL_START_DATE < TRUNC(SYSDATE)
  AND jr.STATUS != 'SUCCEEDED'
  AND jr.OWNER = 'SYS'
ORDER BY jr.ACTUAL_START_DATE DESC

Detección de sesiones bloqueantes:

sql
SELECT
  bl.sid as blocking_sid,
  wl.sid as blocked_sid,
  bl.type as lock_type,
  bl.lmode as lock_mode,
  ROUND((SYSDATE - bs.LOGON_TIME) * 24 * 60, 2) as duration_minutes,
  bs.username as blocking_user,
  ws.username as blocked_user,
  SUBSTR(bsql.sql_text, 1, 100) as blocking_sql
FROM V$LOCK bl, V$LOCK wl, V$SESSION bs, V$SESSION ws, V$SQL bsql
WHERE bl.block = 1
  AND wl.request > 0
  AND bl.id1 = wl.id1
  AND bl.id2 = wl.id2
  AND bl.sid = bs.sid
  AND wl.sid = ws.sid
  AND bs.sql_id = bsql.sql_id(+)
  AND (SYSDATE - bs.LOGON_TIME) * 24 * 60 > 5
ORDER BY duration_minutes DESC

Análisis de inicios de sesión recientes:

sql
SELECT
  OS_USERNAME,
  USERNAME,
  USERHOST,
  TO_CHAR(TIMESTAMP, 'YYYY-MM-DD HH24:MI:SS') as login_time,
  ACTION_NAME,
  RETURNCODE,
  '' as block_time
FROM DBA_AUDIT_TRAIL
WHERE ACTION_NAME = 'LOGON'
  AND RETURNCODE != 0
  AND TIMESTAMP >= TRUNC(SYSDATE)
  AND USERNAME IS NOT NULL
GROUP BY OS_USERNAME, USERNAME, USERHOST, TIMESTAMP, ACTION_NAME, RETURNCODE
HAVING COUNT(*) >= 3
ORDER BY TIMESTAMP DESC

Monitoreo del uso de recursos:

sql
SELECT
  'open_cursors' as parameter,
  p.VALUE as current_value,
  ROUND((s.current_cursors / TO_NUMBER(p.VALUE)) * 100, 2) as pct_use
FROM V$PARAMETER p,
     (SELECT COUNT(*) as current_cursors FROM V$OPEN_CURSOR) s
WHERE p.NAME = 'open_cursors'

Verificación del estado de la base de datos:

sql
SELECT
  d.NAME as db_name,
  i.HOST_NAME as hostname,
  i.STATUS as status,
  TO_CHAR(d.CREATED, 'YYYY-MM-DD HH24:MI:SS') as activation_date,
  d.OPEN_MODE as open_mode
FROM V$DATABASE d, V$INSTANCE i

Análisis del uso de tablespaces:

sql
SELECT
  d.NAME as db_name,
  ts.TABLESPACE_NAME,
  NVL(df.total_size, 0) as defined_space,
  NVL(df.total_size - fs.free_size, 0) as used_space,
  NVL(fs.free_size, 0) as free_space,
  NVL(df.max_size, df.total_size) as max_space,
  CASE
    WHEN NVL(df.max_size, df.total_size) > 0
    THEN ROUND((NVL(df.total_size - fs.free_size, 0) / NVL(df.max_size, df.total_size)) * 100, 2)
    ELSE 0
  END as max_pct_used,
  NVL(df.max_size - df.total_size, 0) as max_growth
FROM V$DATABASE d,
     DBA_TABLESPACES ts
LEFT JOIN (
  SELECT
    TABLESPACE_NAME,
    SUM(BYTES) as total_size,
    SUM(CASE WHEN AUTOEXTENSIBLE = 'YES' THEN MAXBYTES ELSE BYTES END) as max_size
  FROM DBA_DATA_FILES
  GROUP BY TABLESPACE_NAME
) df ON ts.TABLESPACE_NAME = df.TABLESPACE_NAME
LEFT JOIN (
  SELECT
    TABLESPACE_NAME,
    SUM(BYTES) as free_size
  FROM DBA_FREE_SPACE
  GROUP BY TABLESPACE_NAME
) fs ON ts.TABLESPACE_NAME = fs.TABLESPACE_NAME
WHERE ts.CONTENTS != 'TEMPORARY'
ORDER BY ts.TABLESPACE_NAME

Implicaciones de seguridad

Todas las consultas son operaciones SELECT de solo lectura.
No existen capacidades de modificación de datos.
Las consultas acceden a vistas y tablas estándar de monitoreo de Oracle.
El usuario de monitoreo solo requiere privilegios SELECT sobre las vistas del sistema.