tutorial monitoreo monitorear instalar configurar con cliente agregar logfiles nagios

logfiles - monitorear - nagios monitoreo de red



¿Cómo uso Nagios para monitorear un archivo de registro? (6)

Estamos utilizando Nagios para monitorear nuestra red con gran éxito. Sin embargo, tenemos un syslog para errores de aplicación críticos y mientras configuro check_log, no parece funcionar tan bien como monitorizar un dispositivo.

Los temas son:

  • Solo muestra la última entrada.
  • No parece haber una forma de reconocer el error crítico y devolver el monitor a un buen estado

¿Es nagios la herramienta equivocada, o simplemente no estamos configurando el servicio de monitoreo correcto?

Aquí están mis entradas

# log file define command{ command_name check_log command_line $USER1$/check_log -F /var/log/applications/appcrit.log -O /tmp/appcrit.log -q ? } # Define the log monitering service define service{ name logfile-check ; use generic-service ; check_period 24x7 ; max_check_attempts 1 ; normal_check_interval 5 ; retry_check_interval 1 ; contact_groups admins ; notification_options w,u,c,r ; notification_period 24x7 ; register 0 ; } define service{ use logfile-check host_name localhost service_description CritLogFile check_command check_log }

Como hay muchas maneras de lograr un objetivo, también hay un buen complemento de Consol disponible: https://labs.consol.de/lang/en/nagios/check_logfiles/

  • soporta expresiones regulares
  • apoya la rotación de registros

Para usarlo, necesitas un archivo cfg, este es un ejemplo para las bases de datos de Oracle

@searches = ({ tag => ''oraalerts'', options => ''sticky=28800'', logfile => ''/u01/app/oracle/diag/rdbms/davmdkp/DAVMDKP1/trace/alert_DAVMDKP1.log'', criticalpatterns => [ ''ORA/-0*204[^/d]'', # error in reading control file ''ORA/-0*206[^/d]'', # error in writing control file ''ORA/-0*210[^/d]'', # cannot open control file ''ORA/-0*257[^/d]'', # archiver is stuck ''ORA/-0*333[^/d]'', # redo log read error ''ORA/-0*345[^/d]'', # redo log write error ''ORA/-0*4[4-7][0-9][^/d]'',# ORA-0440 - ORA-0485 background process failure ''ORA/-0*48[0-5][^/d]'', ''ORA/-0*6[0-3][0-9][^/d]'',# ORA-6000 - ORA-0639 internal errors ''ORA/-0*1114[^/d]'', # datafile I/O write error ''ORA/-0*1115[^/d]'', # datafile I/O read error ''ORA/-0*1116[^/d]'', # cannot open datafile ''ORA/-0*1118[^/d]'', # cannot add a data file ''ORA/-0*1122[^/d]'', # database file 16 failed verification check ''ORA/-0*1171[^/d]'', # datafile 16 going offline due to error advancing checkpoint ''ORA/-0*1201[^/d]'', # file 16 header failed to write correctly ''ORA/-0*1208[^/d]'', # data file is an old version - not accessing current version ''ORA/-0*1578[^/d]'', # data block corruption ''ORA/-0*1135[^/d]'', # file accessed for query is offline ''ORA/-0*1547[^/d]'', # tablespace is full ''ORA/-0*1555[^/d]'', # snapshot too old ''ORA/-0*1562[^/d]'', # failed to extend rollback segment ''ORA/-0*162[89][^/d]'', # ORA-1628 - ORA-1632 maximum extents exceeded ''ORA/-0*163[0-2][^/d]'', ''ORA/-0*165[0-6][^/d]'', # ORA-1650 - ORA-1656 tablespace is full ''ORA/-16014[^/d]'', # log cannot be archived, no available destinations ''ORA/-16038[^/d]'', # log cannot be archived ''ORA/-19502[^/d]'', # write error on datafile ''ORA/-27063[^/d]'', # number of bytes read/written is incorrect ''ORA/-0*4031[^/d]'', # out of shared memory. ''No space left on device'', ''Archival Error'', ], warningpatterns => [ ''ORA/-0*3113[^/d]'', # end of file on communication channel ''ORA/-0*6501[^/d]'', # PL/SQL internal error ''ORA/-0*1140[^/d]'', # follows WARNING: datafile #20 was not in online backup mode ''Archival stopped, error occurred. Will continue retrying'', ] });

Creo que ahora hay un verdadero complemento de Nagios que controla los registros de manera efectiva.

http://support.nagios.com/forum/viewtopic.php?f=6&t=8851&p=42088&hilit=unixautomation#p42088

La página de inicio del complemento Nagios en esa página es Nagios Log Monitor

Your [ commands.cfg file ] will contain: define command { command_name NagiosLogMonitor command_line $USER1$/NagiosLogMonitor $HOSTNAME$ $ARG1$ $ARG2$ $ARG3$ $ARG4$ ''$ARG5$'' ''$ARG6$'' $ARG7$ $ARG8$ $ARG9$ $ARG10$ } OR define command { command_name NagiosLogMonitor command_line $USER1$/NagiosLogMonitor $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$ $ARG4$ ''$ARG5$'' ''$ARG6$'' $ARG7$ $ARG8$ $ARG9$ $ARG10$ } Your [ services.cfg file ] will look similar to: define service { check_command NagiosLogMonitor!logrobot!autofig!/var/log/proteus.log!15!500.html!500 Internal Server Error!1!2!-foundn max_check_attempts 1 service_description 500_ERRORS_LOGCHECK host_name sky.blat-01.net,sky.blat-02.net,sky.blat-03.net use fifteen-minute-interval }

Nada en tu configuración me salta como si estuviera mal configurado.

Por diseño, check_log solo mostrará un mensaje OK o la última entrada de registro que activó una alerta. Si necesita ver varias entradas, deberá modificar el complemento.

Sin embargo, me parece que el hecho de que no obtengas recuperaciones es algo extraño. La forma en que funciona el check_log (comparando el registro actual con la versión anterior), debe obtener una recuperación en la próxima verificación de servicio. Excepto, por supuesto, cuando se han agregado entradas coincidentes adicionales al registro desde la última comprobación.

¿Forzar otra verificación de servicio (o varias) hace que se recupere?

Además, no tengo la intención de hacerlo de manera mezquina, pero me aseguro de que realmente funcione mal. ¿Su registro obtiene entradas adicionales coincidentes entre las comprobaciones, lo que hace que no se recupere? Su cheque está emparejando "?" que coincidirá con cualquier cosa nueva en el registro. ¿Se está agregando algo más (un error) en el registro y causando una coincidencia inadvertidamente?

Si ninguno de los anteriores es el problema, sugeriría reducirlo eliminando a Nagios de la ecuación. Intente ejecutar check_log manualmente (desde la línea de comandos, pero como el mismo usuario que nagios), y con un registro antiguo diferente. Debería ir algo como esto ...

  1. ejecutar comprobación con un nuevo "registro antiguo" - obtener mensaje de inicialización
  2. Ejecutar cheque - marque OK
  3. hacer cambios en el registro
  4. Ejecutar cheque - cheque falla
  5. Ejecutar cheque - marque OK

Si esto no funciona, entonces debes concentrarte en el registro, el registro antiguo y cómo el check_log está haciendo la verificación.

Si funciona, entonces apunta más hacia un problema con su configuración de nagios.

Nagios ahora tiene una solución que se integra estrechamente con Nagios Core, XI, etc.

Nagios Log Server, que puede alertar sobre cualquier consulta en cualquier archivo de registro en cualquier sistema en su infraestructura.

Para supervisar los registros con Nagios, normalmente el verificador de registros devolverá una advertencia solo para los mensajes de error recién descubiertos cada vez que se invoque (por lo tanto, debe conservar algún estado para saber si hay que ignorarlos en las ejecuciones posteriores). Por lo tanto usualmente establezco:

max_check_attempts 1 is_volatile 1

Esto hace que Nagios envíe la alerta inmediatamente, pero solo una vez, y luego vuelva a la normalidad.

Mi verificador de registros favorito es logwarn , pero estoy parcializado porque lo escribí yo mismo después de no encontrar ninguno que me haya gustado. El paquete logwarn incluye un complemento de Nagios.