Manual de instalación y configuración del Agente SNMP de FirstWave para bases de datos

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 y las expone a través de SNMP (Simple Network Management Protocol / Protocolo Simple de Administración de Red).

Permite supervisar el estado operativo de la instancia, su disponibilidad y distintos indicadores de desempeño.

Este monitoreo proporciona visibilidad sobre el consumo de recursos, como CPU, memoria, disco y actividad general de la base de datos, así como sobre condiciones que puedan impactar su operación, por ejemplo saturación, errores o degradación del servicio.

Adicionalmente, la solución permite generar alertas proactivas ante eventos o comportamientos anómalos, así como integrar la información recolectada en paneles, gráficas e históricos para facilitar el análisis operativo y de capacidad.

El nivel de detalle del monitoreo dependerá de la configuración del agente, los permisos disponibles y la información expuesta por la instancia de base de datos monitoreada.

Este documento lo guiará en la instalación y configuración del agente en su sistema anfitrión con base de datos.

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 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: Nombre del host, puerto, nombre del servicio y credenciales.

Requisitos del usuario de la base de datos

El Agente de FirstWave requiere un usuario dedicado 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. Integrar los archivos correspondientes al modelo

Descargar los archivos del modelo Oracle.
Colocar los archivos 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.
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 logins: genera un reporte sobre sesiones activas de Oracle (usuarios conectados/logins). Se ejecuta con la etiqueta "HOURLY", es decir, cada hora.
/usr/local/bin/firstwave-agent report 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). Se ejecuta con la etiqueta "HOURLY", es decir, cada hora.
/usr/local/bin/firstwave-agent version: devuelve la versión del agente firstwave-agent, útil para inventario o debugging. Se ejecuta con la etiqueta "HOURLY", es decir, cada hora.
/usr/local/bin/firstwave-agent report 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 tablespaces: reporta los contenedores lógicos de almacenamiento. Se ejecuta con la etiqueta "FIVEMIN", es decir, cada 5 minutos.
/usr/local/bin/firstwave-agent report locks: reporta los bloqueos de Oracle (locks en tablas, filas, objetos), importante para detectar cuellos de botella o deadlocks. Se ejecuta con la etiqueta "HOURLY", es decir, cada hora.

4. Ejecutar las tareas programadas vía cron

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. Las instrucciones deben de ir en una sola línea de texto.

# Oracle domingos 7am
0 7 * * 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

# Oracle cada 5 minutos
*/5 * * * *     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=FIVEMIN

El tag "SUNDAY" se ejecutará los domingos a las 7:00am.
el tag "FIVEMIN" se ejecutará cada 5 minutos (en los minutos: 00, 05, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55).
La instrucción para el tag "HOURLY" ya debe de estar agregada por defecto al cron.
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 el agente.
Colocar el archivo en el directorio de binarios del sistema:

/usr/local/bin/

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.

Nota: el usuario declarado en este archivo, debe de poder acceder al agente y poder ejecutarlo (/usr/local/bin/firstwave-agent) y debe de poder acceder al archivo de instancias (/etc/firstwave-agent/conf.d/oracle-db.yaml).

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 [OBSOLETO PARA VERSIÓN 1.2.1 DEL AGENTE]

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, CLIENTEBD, la cadena sería:

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

Donde:

Monitoreo = usuario

123456789 = contraseña

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

1523 = puerto que indicaron

CLIENTEBD = 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.

4. Crear ruta y archivo de instancias

Se debe crear una ruta y un archivo de instancias dentro de la carpeta /etc/firstwave-agent/ y darle permisos de usuario y grupo.
mkdir conf.d chown nmis:nmis conf.d

Nota: el usuario nmis y el grupo nmis son un ejemplo. Esto se refiere al usuario que ejecutará y será propietario del proceso.

Dentro de la carpeta /etc/firstwave-agent/conf.d/, deberá de crearse el archivo oracle-db.yaml, el cual contendrá cada una de las instancias de la base de datos.

cd /etc/firstwave-agent/conf.d
sudo nano oracle-db.yaml

El contenido del archivo tendrá la siguiente estructura:

instances:
  - name: "nombre de la instancia 1"
    server: "ip del servidor de la bd"
    service_name: "service name de la bd 1"
    username: "usuario de conexión a la bd"
    password: "password de conexión a la bd"
    port: #puerto
  - name: "nombre de la instancia 2"
    server: "ip del servidor de la bd"
    service_name: "service name de la bd 2"
    username: "usuario de conexión a la bd"
    password: "password de conexión a la bd"
    port: #puerto

Por ejemplo, si se tienen dos instancias con los siguientes datos:

Nombre de la instancia: instancia1
Servidor: 10.10.10.10
Nombre del servicio: instancia1
Usuario de conexión: usuario1
Contraseña: password1
Puerto: 1523

Nombre de la instancia: instancia2
Servidor: 10.10.10.10
Nombre del servicio: instancia2
Usuario de conexión: admin
Contraseña: password
Puerto: 1523

El archivo oracle-db.yaml quedaría así:

instances:
  - name: "instancia1"
    server: "10.10.10.10"
    service_name: "instancia1"
    username: "admin"
    password: "password"
    port: 1523
  - name: "instancia2"
    server: "10.10.10.10"
    service_name: "instancia2"
    username: "admin"
    password: "password"
    port: 1523

Guardar el archivo y darle permisos de usuario y grupo.

chown nmis:nmis oracle-db.yaml

Nota: el usuario nmis y el grupo nmis son un ejemplo. Esto se refiere al usuario que ejecutará y será propietario del proceso.

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

8. Generar e instalar una política SELinux personalizada para el agente

Cuando SELinux está en modo Enforcing, puede bloquear acciones necesarias del servicio firstwave-agent. Para permitir dichas acciones de forma segura, se debe generar e instalar una política personalizada basada en los eventos registrados por SELinux.

a) Generar la política SELinux a partir de los logs, ejecutando lo siguiente:

sudo ausearch -c 'firstwave-agent' --raw | audit2allow -M firstwave-agent-policy

Detalles

ausearch -c 'firstwave-agent': busca en los logs de auditoría de SELinux todos los eventos relacionados con el proceso firstwave-agent.
--raw: muestra los eventos en formato crudo, necesario para procesarlos correctamente.
audit2allow: analiza los eventos bloqueados por SELinux y genera reglas que permiten esas acciones.
-M firstwave-agent-policy: crea un módulo de política SELinux llamado firstwave-agent-policy, generando dos archivos:
- firstwave-agent-policy.te (archivo fuente de la política)
- firstwave-agent-policy.pp (módulo compilado)

b) Instalar el módulo de política SELinux, ejecutando lo siguiente:

sudo semodule -i firstwave-agent-policy.pp

Explicación:

semodule -i: Instala el módulo de política SELinux en el sistema.
A partir de este momento, SELinux permitirá las acciones necesarias para que firstwave-agent funcione correctamente, sin desactivar SELinux.

c) Reiniciar el servicio firstwave-agent

sudo systemctl restart firstwave-agent

d) Verificar el estado del servicio

sudo systemctl status firstwave-agent

Con este proceso se asegura que el agente se ejecute correctamente y que SELinux permanezca en modo Enforcing.

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 logins: cada hora
/usr/local/bin/firstwave-agent report cursors: cada hora
/usr/local/bin/firstwave-agent version: cada hora
/usr/local/bin/firstwave-agent report jobs: domingos a las 7:00hrs
/usr/local/bin/firstwave-agent report tablespaces: cada cinco minutos
/usr/local/bin/firstwave-agent report 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.