/
Solución de problemas opFlow

Solución de problemas opFlow

Verifique que el demonio de recolección de flujo se esté ejecutando

En OpFlow 3, se le avisará de los problemas del demonio en la página principal del panel, de forma similar a la siguiente captura de pantalla:

Verificar que se está ejecutando "flowd"

opFlow  usa la herramienta "flowd" para recibir (y almacenar temporalmente) datos de flujo:

ps -ef | grep flowd

ps -ef | grep flowd

Debería ver algunas entradas además del grep, la relevante aquí son las dos líneas " ":

[root@thor opmantek]# ps -ef | grep flowd

root 13356 1 0 Jun18 ? 00:00:10 flowd: monitor

_flowd 13357 13356 0 Jun18 ? 00:00:30 flowd: net

root 27114 1 0 12:40 ? 00:00:00 NMIS opflowd debug=0

root 32567 27106 0 12:51 pts/5 00:00:00 grep flowd

[root@thor opmantek]# ps -ef | grep flowd

root 13356 1 0 Jun18 ? 00:00:10 flowd: monitor

_flowd 13357 13356 0 Jun18 ? 00:00:30 flowd: net

root 27114 1 0 12:40 ? 00:00:00 NMIS opflowd debug=0

root 32567 27106 0 12:51 pts/5 00:00:00 grep flowd

Para iniciar un flujo perdido / muerto, simplemente ejecuta

sudo service flowd start

sudo service flowd start

 

Verificar que se está ejecutando "nfcapd"

En opFlow 3, hemos cambiado a un colector de flujo más moderno, "nfcapd" del paquete "nfdump"; OpFlow 3 también incluye un script de inicio más conveniente para este demonio:

sudo service nfdump status

sudo service nfdump status

Debe informar que nfcapd se está ejecutando con un PID particular; puede comprobar siguiendo este parámetro:

ps -ef|fgrep nfcapd

ps -ef|fgrep nfcapd

Si no hay nfcapd activo, ejecuta  

sudo service nfdump start

sudo service nfdump start

 

Verificar que el demonio principal de opFlow se está ejecutando

opFlow requiere que opflowd se ejecute para recuperar periódicamente y procesar nuevos datos de flujo de la herramienta correspondiente del colector de flujo.

sudo service/opflowd status 

sudo service/opflowd status 

Debería de informar que opFlowd está activo, sino ejecutar el siguiente comando

sudo service opflowd start

sudo service opflowd start

Verificar que MongoDB se esté ejecutando

Sin un funcionamiento MongoDB opFlow no puede operar; con toda probabilidad, usará un servidor MongoDB local, en la misma máquina que opFlow. En este caso, debería ser suficiente para verificar un servidor de mongod Activo.

sudo service mongod status y / o  ps -ef | fgrep mongod

sudo service mongod status y / o  ps -ef | fgrep mongod

(Si no está utilizando la configuración predeterminada, sino una instancia de mongod remota, deberá usar el  mongo shell para verificar que esté accesible y funcionando).  Al igual que en el mongod ejemplo anterior, activar una instancia faltante  es fácil:  

sudo service mongod start 

sudo service mongod start 

Tenga en cuenta que mongod puede negarse a iniciar por una serie de razones (por ejemplo, configuración incorrecta, falta de espacio en disco, etc.); si el inicio del servicio indica falla, tendrá que investigar usando los registros de MongoDB (que generalmente están en /var/log/mongodb/).

Verificar la configuración de la carpeta de origen de datos 

opFlow necesita saber dónde buscar nuevos datos de flujo, y es evidente que la herramienta de recolección de flujo necesita saber dónde guardar los datos para que los consumidores los encuentren.

Directorios de flujo (opFlow 2)

 

Verifique que todas las carpetas sean iguales. Ejecute estos comandos y asegúrese de que todo apunte al lugar correcto.

grep logfile /usr/local/etc/flowd.conf

grep opflow_dir /usr/local/opmantek/conf/opFlow.nmis

grep logfile /usr/local/etc/flowd.conf

grep opflow_dir /usr/local/opmantek/conf/opFlow.nmis

Es especialmente importante que opFlow, que es la configuración de "flowd_data", recoja el archivo de registro que fluye, y este se combina con "<dir_o_flujo>" para obtener la ruta

grep logfile /usr/local/etc/flowd.conf

logfile "/data/opflow/flowd"

 grep opflow_dir /usr/local/opmantek/conf/opFlow.nmis

 '<opflow_dir>' => '/data/opflow',

 'flowd_data' => '<opflow_dir>/flowd',

grep logfile /usr/local/etc/flowd.conf

logfile "/data/opflow/flowd"

 grep opflow_dir /usr/local/opmantek/conf/opFlow.nmis

 '<opflow_dir>' => '/data/opflow',

 'flowd_data' => '<opflow_dir>/flowd',

Directorio nfcapd / nfdump (opFlow 3)

La configuración predeterminada para nfcapd se utiliza  /var/lib/nfdump para el almacenamiento de datos de flujo, y opFlowd necesita usar el mismo directorio.

grep opflow_dir  /usr/local/omk/conf/opCommon.nmis

 '<opflow_dir>' => '/var/lib/nfdump',

 cat /etc/default/nfdump /etc/sysconfig/nfdump

#...at most one of these files exists; if not the default in /etc/init.d/nfdump will be used

# in all cases the relevant line looks like this:

DATA_BASE_DIR="/var/lib/nfdump"

grep opflow_dir  /usr/local/omk/conf/opCommon.nmis

 '<opflow_dir>' => '/var/lib/nfdump',

 cat /etc/default/nfdump /etc/sysconfig/nfdump

#...at most one of these files exists; if not the default in /etc/init.d/nfdump will be used

# in all cases the relevant line looks like this:

DATA_BASE_DIR="/var/lib/nfdump"

Espacio de disco duro

Verifica tu espacio de disco (principalmente opFlow 2)

Asegúrese de que donde quiera que esté poniendo los datos de flujo y el Mongo DB, tenga bastante espacio en disco; Los datos de flujo son muy voluminosos. En opFlow 3, las colecciones de la base de datos normalmente tienen un "límite" de tamaño y no aumentan.

 

df -h /data

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/vg_data-lv_data

           247G  86G  148G  37% /data

df -h /data

Filesystem Size Used Avail Use% Mounted on

/dev/mapper/vg_data-lv_data

           247G  86G  148G  37% /data

Ejecute una purga manualmente (solo opFlow 2)

Purgue los datos de flujo binario del flujo sin procesar y los datos de la base de datos anterior, suponga que desea mantener 7 días de datos binarios de flujo y se encuentra en / var / opflow.

/usr/local/opmantek/bin/opflw_purge_raw_files.sh /var/opflow 7

/usr/local/opmantek/bin/opflowd.pl type=purge

/usr/local/opmantek/bin/opflw_purge_raw_files.sh /var/opflow 7

/usr/local/opmantek/bin/opflowd.pl type=purge

Saturación de /var por archivos nfdump

Este apartado explica un escenario común de saturación en /var por archivos nfdump y presenta el proceso de revisión y solución.

Escenario

Al ingresar al módulo opCharts vía UI, no carga y muestra un mensaje de temporalmente fuera de servicio o una página en blanco.

image-20260720-194624.png

Procedimiento

Se recomienda el siguiente proceso:

  1. Ingresar vía consola y revisar estado de servicios y espacio en disco. Ejecutar:

#Validar estado de servicios service omkd status service nmis9d status service opflowd status #Validar espacio en discos df -h

  1. Revisar qué está saturando cache

#Ingresar a la carpeta Cache y listar contenido cd /var/cache/ ls -lrt #Ingresar a la carpeta nfdump y listar contenido cd /var/cache/nfdump/ ls -lrt

  1. Ejecutar el siguiente comando para vaciar instantáneamente el contenido de múltiples archi

cd /var/cache/ ls -lrt #Ingreso a la carpeta nfdump y listar contenido cd /var/cache/nfdump/ ls -lrt

  1. Ejecutar el comando siguiente para vaciar instantáneamente el contenido de múltiples archivos de captura de flujos (NetFlow/IPFIX) sin eliminar los archivos físicamente de su directorio.

find . -type f -name 'nfcapd*' -exec cp /dev/null {} \;

  1. Ejecutar nuevamente el comando para validar el espacio

df -h

  1. Por último, se recomienda generar un script bash que realice la limpieza de estos archivos de manera automática al menos cada 2 días para evitar futuras saturaciones. El script debe ubicarse en la carpeta /root

#Ejemplo de script de depuración nano /root/Limpiar_Temporales.sh

  1. Para la depuración en automático se debe de agregar en el cron, el comando a ejecutar es el siguiente:

#Abrir el cron del sistema crontab -e #Ejemplo de configuración en cron 0 2 */2 * * root /root/limpiar_temporales.sh

A continuación, se explican los valores para configurar el cron, basándonos en el ejemplo anterior.

Valor

0

2

*/2

*

*

root

/root/limpiar_temporales.sh

Descripción

minuto

hora

día

mes

De lunes a viernes

usuario

ruta donde se encuentra el script

 Para ingresar la configuración en cron, se debe de validar que los espacios sean con tabulador.

Correlación de IP en opFlow y NMIS: las IP de list-agents no coinciden con las interfaces de NMIS

En este apartado explicaremos por qué la dirección IP mostrada por opflow-cli.pl act=list-agents puede no coincidir con las direcciones IP de las interfaces registradas en NMIS y describe el procedimiento recomendado para identificar correctamente el ifIndex antes de habilitar interfaces en opFlow. 

Escenario

Es común observar que las direcciones IP listadas para los agentes no coinciden con la IP de gestión o las direcciones de servicio registradas para el nodo en NMIS.

Esta guía explica la causa técnica de este comportamiento y detalla el procedimiento operativo estándar para identificar y activar interfaces en opFlow de manera precisa sin desperdiciar licencias.

Al ejecutar el comando:

/usr/local/omk/bin/opflow-cli.pl act=list-agents

Se observa que la dirección IP del agente no corresponde a ninguna de las interfaces visibles en NMIS.

Esto sucede debido a que opFlow no identifica los agentes por la dirección IP de servicio registrada en NMIS. Identifica cada agente por la dirección IP origen configurada en el flow exporter, es decir, la IP de la interfaz configurada en el parámetro source del exportador NetFlow/IPFIX. Por ejemplo:

flow exporter NETFLOW_TO_FirstWave    destination 10.10.10.28    source GigabitEthernet0/0/0.3    transport   udp 9995

Esta dirección puede ser diferente a las IP de las interfaces monitoreadas en NMIS. Esto es completamente normal y ocurre, entre otros casos, cuando:

  • El dispositivo utiliza una Loopback, una interfaz de administración o una subinterfaz dedicada como origen de la exportación de flujos.

  • NMIS únicamente tiene inventariadas las interfaces configuradas por SNMP, que pueden no incluir la interfaz origen del exportador.

  • El equipo dispone de múltiples interfaces y la interfaz de exportación no forma parte de las que se supervisan habitualmente en NMIS.

Adicional a esto, una vez identificado el agente, opFlow administra sus interfaces mediante ifIndex (identificador numérico asignado por SNMP). Por ello, en opFlow no se muestran directamente el nombre (ifName), la descripción (ifDescr) ni la dirección IP de la interfaz, lo que hace necesaria una correlación previa antes de realizar cualquier activación.

Procedimiento

El proceso que se recomienda es el siguiente:

  1. Obtener el nombre y descripción de las interfaces fisicas mediante:

    show interfaces description     show ip interface brief

  1. Correlacionar la interfaz con NMIS. En NMIS, acceder al nodo correspondiente y consultar la tabla de interfaces (Node → Interfaces). Ahí podrán identificar la relación entre:

  • ifIndex   → identificador numérico requerido por opFlow

  • ifDescr   → nombre descriptivo de la interfaz

  • ifName    → nombre corto del sistema operativo

  1. Una vez confirmado el ifIndex correcto, ejecutar el comando de activación:

/usr/local/omk/bin/opflow-cli.pl act=update-agent \     agent=<IP_AGENTE> \     in_if=<IFINDEX> \     out_if=<IFINDEX> \     admin_status=active

  1. Verificar la configuración aplicada antes de habilitar alguna adicional.

/usr/local/omk/bin/opflow-cli.pl act=list-agents

Este procedimiento deberá repetirse para cada equipo en el que se desee limitar el procesamiento de flujos a interfaces específicas.