Monitoria y Analisis de Red Con Nagios PDF
Monitoria y Analisis de Red Con Nagios PDF
Monitoria y Analisis de Red Con Nagios PDF
Las redes de cómputo de las organizaciones, se vuelven cada vez más complejas y la exigencia de la operación es cada vez mas demandante. Las redes, cada
vez mas, soportan aplicaciones y servicios estratégicos de las organizaciones. Por lo cual el análisis y monitoreo de redes se ha convertido en una labor cada vez
mas importante y de carácter pro-activo para evitar problemas. Con el termino Monitoreo nos referimos a un sistema que constantemente monitorea una red de
computadoras para detectar sistemas lentos o en mal funcionamiento y que notifica al administrador de la red en caso de falla vía correo electrónico, sms u otros
medios.
Para prevenir errores en un sistema podemos utilizar una aplicación que se ocupe de estar “controlado y observando” el funcionamiento de la red, esto podemos
realizarlo por medio de un software llamado Nagios. Nagios es un sistema de monitoreo de servidores, aplicaciones y redes. Comprueba clientes y servicios,
especifícados alertando en caso de problemas como caídas de servicio ó restauración de los mismos.
Nagios es un sistema de monitorización de equipos y de servicios de red, escrito en C y publicado bajo la GNU General Public License, el lenguage con el cual esta
desarrollado nos asegura una rápida ejecución y su licencia que lo determina como Software Libre nos asegura que siempre tendremos actualizaciones
disponibles y que hay una gran comunidad de desarrolladores soportándolo.
Creado para ayudar a los administradores a tener siempre el control de qué está pasando en la red que administran y conocer los problemas que ocurren en la
infraestructura que administran antes de que los usuarios de la misma los perciban, para así no sólo poder tomar la iniciativa, sino asumir la responsabilidad de
hacer que las cosas sucedan; decidir en cada momento lo que queremos hacer y cómo lo vamos a hacer, debido a que este software nos permite obtener datos,
interpretarlos y tomar decisiones en base a ello como:
Para facilitar tareas de explotación de datos, hay diferentes aditivos como un visor de reportes integrados, en el cual se puede ver el histórico de actividad y
performance de servicios, y además un visor de diagramas de red con el estado actual de cada equipo.
El mismo, esta constituido por un Núcleo que construye la interfaz de usuario y por plugins los cuales representan los ojos y oídos de Nagios y por lo cual se
encargan de recopilar información (bajo demanda). Los mismos pueden estar programados en diversos lenguajes como C, C++, Python, Perl, PHP, Java, Bash
etc, ya que Nagios es independiente del lenguaje en el cual que se desarrolle el plugin y solo procesa los datos recibidos de este, para la posterior elaboración y
envío de notificaciones a los encargados de la administración del sistema en cuestión.
Objetivos y necesidades
Conocer el estado de diferentes servicios brindados por un conjunto heterogéneo de dispositivos y equipos como servidores corriendo diferentes sistemas
operativos, routers de los cuales dependen varios equipos, sistemas SCADA y sistemas de analizadores de humedad/temperatura/gases etc. Obtener información
de los mismos como estado en red, tiempo arriba, puertos abiertos, servicios y procesos corriendo, carga de CPU, carga de memoria física, carga de memoria
virtual, espacio en disco, interfaces de red activas.
Para poder tener esta información se debe establecer un control que asegure el mantenimiento de los dispositivos y se puedan efectuar acciones en forma
preventiva o correctiva según corresponda en tiempo y forma ante eventuales anomalías de los servicios.
Es posible conocer los estados y datos de estos diferentes equipos para una posterior elaboración de reportes etc, elaborando una configuración personalizada de
Nagios para cada caso en particular, por medio de testeo de paquetes de red, o haciendo uso de diferentes funciones que provee el protocolo SNMP (Simple
Network Management Protocol) que nos permite gestionar y/o supervisar datos de diferentes elementos y componentes de la red como routers, switches,
servidores etc y al ser un protocolo standard es posible monitorizar una amplia variedad de casos en escenarios con sistemas ó equipos diferentes.
Ya que podemos :
Detectar de forma sistemática el uso de los recursos y los flujos de información dentro de una organización.
Determinar qué información es crítica para el cumplimiento de su misión y objetivos, identificando necesidades, duplicidades, costos, valor y barreras, que
obstaculizan flujos de información eficientes.
Análizar de eficiencia del sistema.
Verificar el cumplimiento de Normativas.
Revisión de la gestión de recursos.
Con esto podemos elaborar informes, responder ante evaluaciones externas y documentar la evaluación para reflejar el desarrollo y los resultados de la misma.
Fortalecer bases de información para grupos y personas de apoyo que trabajan con los sistemas.
Cuando uno contrata un servicio de Data Center hay varios factores a tener en cuenta que deben ser provistos y desarrollados por el prestador del servicio y a la
hora de ofrecer el mismo, esos factores suelen afectar directamente en su costo :
Todos estos factores deben estar esclarecidos ya que no solo puede existir la necesidad de asegurarle y garantizarle efectivamente esto a los utilizadores
externos, sino también a los internos, ya que la Disponibilidad es el factor determinante de la contratación del servicio. Por lo general se establecen acuerdos de
Disponibilidad de Servicio - SLA, con diferentes niveles y con un accionar y escalamiento determinado para cada caso.
Lo comentado anteriormente en la mayoría de los casos y por lógica y sentido común suele encuadrarse dentro de un marco legal por medio de un contrato y
dentro del mismo suele haber cláusulas por multas monetarias debido a tiempos de indisponibilidad o mal funcionamiento del servicio. El proceso de costeo para
realizar la calificación de incidentes y su posterior valorización monetaria debe estar detallado en una norma que regle dicho procedimiento definido en la
contratación del servicio.
Por y para eso para nosotros es necesario como proovedores de servicio que somos y al estar abasteciendo a otras empresas con exigencias necesarias para el
desarrollo de su actividad, en este caso la base material para correr su infraestructura informática :
Tengamos un registro minucioso y reportado de eventos ya que estos pueden afectarnos directamente de forma legal y monetaria en el desarrollo de nuestras
actividades sino llevamos control de los mismos.
Estrategias
Monitoreo Activo
Este tipo de monitoreo se realiza enviando paquetes desde sl sistema de monitoreo a los clientes que necesitamos monitorear. Ya sea un PING o pedidos a
determinadas aplicaciones en los mismos.
Ventajas
No hay que instalar un agente especializado en el cliente. En algunos casos solo SNMP. Es una opción para casos en los que no es posible instalar
aplicaciones en los clientes
Desventajas
Tiene métricas menos especificas por consiguiente se pueden realizar análisis menos detallados. Pueden ser afectadas por hechos que sucedan en la red..
Monitoreo Pasivo
Esta estrategia se basa en la obtención de datos a partir desde los clientes a monitorear hacia el sistema de monitoreo. Este enfoque bien planificado puede ser
mas perfomante a lo que trafico de red se refiere comparándolo con la técnica de Monitoreo Pasivo.
Ventajas
Información más específica y más detallada. Mayor flexibilidad para realizar monitoreos personalizable. Posibilidad de crear soluciones de monitoreo que
controlen estados de servicios o métricas no estándares sobre aplicaciones o hardware. El control de las aplicaciones y servicios se realiza directamente en
el nodo monitoreado. Mayor seguridad en la red ya que se manejan protocolos encriptación. Menor riesgo de detección de inactividades.
Desventajas
Puede provocar mayor carga de actividad en el cliente. Se debe instalar el agente en todos los equipos que se van a monitorear.
Capas
Aspectos generales
Monitoreo de objetos o cajas negras con agentes o sin agentes
Reportes estadísticos
En ITIL, los consultores acompañan a las empresas a diseñar y/o implementar sus procesos. También realizan GAPs para evaluar cuan cerca se encuentra la
organización de las actividades que se recomiendan en las mejores prácticas y se recomiendan posibles mejoras para acercarse.
Service Desk
Incident Management
Service Level Management
Capacity Management
IT Service Continuity Management
Availability Management
ICT infrastructure Management
Gestión de la disponibilidad
La disponibilidad “Availability Management” es un proceso del “Service Delivery”, definido en las especificaciones de ITIL.
Su meta es asegurar que el nivel de disponibilidad requerido esté proporcionado.
La supervisión y análisis de informes de la disponibilidad es una actividad clave para asegurar que los niveles del servicio se estén cumpliendo.
En la base de la gestión se debe supervisar contínuamente la disponibilidad de la Infraestructura, servicios y alertar a los administradores para iniciar los
procedimientos oportunos.
Ciclo de un incidente
Administracion de la capacidad
Alinear los servicios de TI con las necesidades de la empresa (el negocio), actuales y futuras.
Mejorar la calidad de los servicios de TI.
Reducir los costos por la proveeduría de servicios de TI en el mediano y largo plazos.
Mejora de rendimiento de la inversión de TI.
Se mide el sistema de TI de la organización evaluando los procesos de Soporte Técnico y Entrega de Servicios comparándolos con las Mejores Prácticas.
Objetivos
Nuestras necesidades
Estan en orden de prioridad, pero todas van atadas de la mano una con otra
Para la gestion de inventario y de incidencias presentadas con los equipos y servicios inventariados se puede implementar GLPI
Ademas se busca una herramienta que se integre y complemente al el sistema de ivnentario, como FusionInventory, que es una variante de OCS-
Inventory, que se integra completamente con el Software GLPI
Descripción
Equipos de desarrollo
Coordinadores de Mesas de Ayuda
Areas relacionadas
Que se va a monitorear
Sistema Operativo
Utilización de red
Trafico
Servicios (SAP, Web, Bases de datos, DHCP)
Como impacta
Mejora de productividad
Antelacion de problemas
Reporte y aviso de incidentes
Agilidad en su tratamiento
Mejor y mayor relacion e integracion de sectores adjuntos
Requerimientos Operativos
impacto_urgencia.dia.gz
Recursos tecnológicos
Ejemplo un vez tuve que monitorear una red con 700 hosts y 2000 servicios que a su vez guardaba estadisticas completas en un MySQL dentro del mismo equipo
para luego generar informes SLA y mostrar datos en pantalla en una interfaz personalizada y disponia de un Intel Quad Core 2.8 GHz a 32 bits con un disco SATA
de 320 GB y se quedo algo corto el hardware para los requerimientos
Tareas
Dependencias
Para una correcta instalación de Nagios, con todas sus características es necesario tener instalados ciertos paquetes de software en el sistema, la instalación
puede variar según la distribución de Linux que elijamos, si los tenemos empaquetados, o si los tenemos que compilar en instalar manualmente.
Cliente Oracle
http://www.oracle.com/technetwork/database/features/instant-client/
Basic Cliente de Oracle para realizar los chequeos
[http://www.oracle.com/technetwork/database/features/instant-client/]
SQL*Plus
Eventdb Integración de chequeos de Syslog https://www.netways.org/projects/eventdb [https://www.netways.org/projects/eventdb]
Highchart for
Gráficos de PNP4Nagios en AJAX http://sourceforge.net/projects/highchartfornag/ [http://sourceforge.net/projects/highchartfornag/]
Nagios
Nota:
Hay algunos plugins que no estan mas disponibles en su sitio, aca los incluyo
nagios_lotus-blackberry.tgz
Descarga y compilación
En este apartado nos concentraremos en la descarga y compilación de los diferentes paquetes bajados en formato de codigo fuente.
Nagios
Para empezar deberemos descargar el código fuente del software Nagios desde su sitio web, en formato tar.gz, a la fecha la última versión es la 3.0.
General Options:
-------------------------
Nagios executable: nagios
Nagios user/group: nagios,nagios
Command user/group: nagios,nagios
Embedded Perl: no
Event Broker: yes
Install ${prefix}: /usr/local/nagios
Lock file: ${prefix}/var/nagios.lock
Check result directory: ${prefix}/var/spool/checkresults
Init directory: /etc/rc.d/init.d
Apache conf.d directory: /etc/httpd/conf.d
Mail program: /bin/mail
Host OS: linux-gnu
If the main program and CGIs compiled without any errors, you
can continue with installing Nagios as follows (type 'make'
without any arguments for a list of all possible options):
make install
- This installs the main program, CGIs, and HTML files
make install-init
- This installs the init script in /etc/rc.d/init.d
make install-commandmode
- This installs and configures permissions on the
directory for holding the external command file
make install-config
- This installs *SAMPLE* config files in /usr/local/nagios/etc
You'll have to modify these sample files before you can
use Nagios. Read the HTML documentation for more info
on doing this. Pay particular attention to the docs on
object configuration files, as they determine what/how
things get monitored!
make install-webconf
- This installs the Apache config file for the Nagios
web interface
*** Support Notes *******************************************
http://www.nagios.org/support/
*************************************************************
Enjoy.
Para correr el daemon del servicio nagios y realizar tareas de administración y configuración sobre el, se debió crear el usuario nagios y el grupo nagios con
privilegios de usuario normal del sistema, con su home ubicado en el directorio de instalación de nagios /usr/local/nagios, luego se le atribuyeron permisos de
acceso y escritura para dicho usuario.
/etc/init.d/nagios start
Luego deberemos bajarnos el paquete de plugins básico de Nagios y descomprimirlo para luego compilarlo
PNP4Nagios
PNP4Nagios es un addon para Nagios que básicamente, nos genera gráficas con los resultados de los análisis de Nagios, para poder llevar un control más general
de la monitorización de un determinado servidor o servicio en las últimas horas, días, semanas, meses o incluso años.
Una vez que tenemos instalado y configurado Nagios procederemos a descargar y descomprimir el paquete pnp4nagios,
General Options:
------------------------- -------------------
Nagios user/group: nagios nagios
Install directory: /usr/local/nagios
HTML Dir: /usr/local/nagios/share/pnp
Config Dir: /usr/local/nagios/etc/pnp
Path to rrdtool: /usr/bin/rrdtool (Version 1.2.29)
RRDs Perl Modules: FOUND (Version 1.2029)
RRD Files stored in: /usr/local/nagios/share/perfdata
process_perfdata.pl Logfile: /usr/local/nagios/var/perfdata.log
Perfdata files (NPCD) stored in: /usr/local/nagios/var/spool/perfdata/
NDOUtils
El generador de graficas Nagvis necesita acceder a los datos que Nagios genera, una de las formas de acceder a los mismos es que Nagios almacene sus datos
dentro de una base de datos MySQL ya que por defecto lo hace en archivos de texto, para que Nagios pueda hacer eso, deberemos instalar el modulo NDO que
viene dentro del paquete NDOUtils descargable via el sitio web de Nagios. Este módulo es el que se encarga de generar las consultas en formato MySQL, que
son cargadas sobre un socket El proceso NDO2DB corriendo como daemon lee de ese socket y carga los datos en una base de datos MySQL.
General Options:
-------------------------
NDO2DB user: nagios
NDO2DB group: nagios
Las utilidades NDO incluyen un Nagios Even Broker Module (NDOMOD.O) que exporta datos desde el demonio de nagios.
Asumiendo que nagios fue compilado con el Modulo Event Broker activado (esto es por default), usted puede configurar que nagios cargue el modulo NDOMOD
en tiempo de ejecucion. Una vez que el modulo fue cargado por el daemon de nagios, este puede acceder a todos los datos y logicamente presente el el proceso
de nagios que esta corriendo.
El modulo NDOMOD tiene designado exportar la configuracion, como informacion variada de eventos en tiempo de ejecucion que ocurre en el proceso de
monitoreo, por el daemon de nagios. El modulo puede enviar esta informacion a un archivo estandar, a un Socket Unix de Dominio o un a socket TCP.
Si el NDOMOD esta escrito para un archivo de salida, usted puede configurarlo para rotarlo periodicamente y/o procesarlo en otra maquina fisicamente (usando
SSH, etc.) y envia este contenido al daemon NDO2DB usando la utilidad FILE2SOCK (que describiremos mas adelante).
La utilidad LOG2NDO
Esta es designada para permitir importar un historial de logs de nagios a una BD via el NDO2DB daemon (describiremos luego). La utilidad trabaja enviando
archivos de logs históricos a un archivo estandar, un unix sock o un tcp sock en un formato que NDO2DB daemon entienda. El NDO2DB daemon puede luego
usarlo para procesar la salida y almacenar en un archivo de log historico informandolo en una BD.
La utilidad FILE2SOCK
Esta utilidad es muy simple, solo lee de un archivo estandar (o STDIN) y escribe todo sobre un socket de dominio unix o un tcp socket. Estos datos son leidos y
no son procesados por nada, antes de ser enviados al socket.
El demonio NDO2DB
La utilidad es diseñada para tomar los datos de salida de los componentes NDOMOD y LOG2NDO y almacenarlos en una BD MySQL o BD PostgreSQL.
Cuando este inicia, el daemon NDO2DB crea un socket y espera que los clientes se conecten. NDO2DB puede correr independientemente, bajo un demonio
multiproceso o bajo inetd (si esta usando un socket TCP).
Instalación
cp src/ndomod-3x.o /usr/local/nagios/bin/ndomod.o
Con esto copiaremos el modulo al directorio de ejecución de Nagios
cp config/ndomod.cfg /usr/local/nagios/etc
De esta manera instalaremos la configuración inicial del modulo
cp src/ndo2db-3x /usr/local/nagios/bin/ndo2db
Con esto copiaremos el daemon al directorio de ejecución de Nagios
cp config/ndo2db.cfg /usr/local/nagios/etc
De esta manera instalaremos la configuración inicial del daemon
Configuración
MK Livestatus
La forma clásica de acceder a la informacion actual de sus hosts y servicios es mediante la lectura y análisis del archivo status.dat, que es creado por Nagios en
una base regular. El intervalo de actualización se configura a través status_update_interval en nagios.cfg. Un valor típico es de 10 segundos. Si la instalación es
cada vez más grande, usted podría tener que aumentar este valor con el fin de reducir al mínimo el uso de CPU y de E / S de disco. La interfaz web de Nagios
utiliza status.dat para mostrar sus datos.
Analizar status.dat no es muy popular entre los desarrolladores de addons. Así que muchos utilizan otro enfoque: NDO. Este es un módulo de ORC que se carga
directamente en el proceso de Nagios y envía todas las actualizaciones de estado a través de un socket UNIX a un proceso de ayuda. Eso crea sentencias SQL y
actualizaciones de varias tablas en una base de datos MySQL o PostgreSQL. Este enfoque tiene varias ventajas sobre status.dat:
El futuro
Desde la versión 1.1.0, Check_MK ofrece un enfoque totalmente nuevo para acceder a datos de estado y también histórico: Livestatus. Así como NDO, Livestatus
hacer uso de la API de Nagios evento Broker y carga un módulo binario en su proceso de Nagios. Pero luego otros NDO, Livestatus no realiza escribir datos. En su
lugar, se abre un socket en la que pueden consultar los datos a demanda.
La toma permite enviar una solicitud de los servicios u otros datos y obtener una respuesta inmediata. Los datos son directamente leídos de estructuras de datos
internas de Nagios. Livestatus no crea su propia copia de esos datos. A partir de la versión 1.1.2 que también se pueden recuperar los datos históricos de los
archivos de registro a través de Nagios Livestatus.
Esto es no sólo un enfoque increíblemente simple, si no también muy rápido. Algunas ventajas son:
Otro entonces NDO, utilizando Livestatus no impone una carga mensurable de su CPU para nada. Sólo en el tratamiento de las consultas de una cantidad muy
pequeña de la CPU es necesario. Pero eso ni siquiera se bloqueará Nagios.
En el mismo tiempo, ofrece a sus Livestatus propio lenguaje de consulta que es simple de entender, ofrece la mayoría de la flexibilidad de SQL e incluso más en
algunos casos. Es un protocolo rápido, ligero y no necesita un cliente binario. Incluso, pueden obtener acceso a los datos sin ningún tipo de software especial de
ayuda.
Proceso de compilación
Despues tenemos que especificar que Nagios cargue el archivo objeto compilado livestatus.o, para eso debemos agregar a nagios.cfg:
broker_module=/usr/local/lib/mk-livestatus/livestatus.o /var/lib/nagios/rw/live
event_broker_options=-1
Valor por
Opción Que significa
default
debug 0 Set this to 1 in order to make Livestatus log each query it executes in nagios.log
Livestatus' access to Nagios logfiles caches messages in-memory. Here you can set the maximum number of cached messages. Each message takes about 250
max_cached_messages 500000
bytes (in the current implementation)
Livestatus constructs each response in-memory before sending it to the clients. In order to avoid a crash in case of extensive queries, the maximum response size
max_response_size 104857600
is limited. The default limit is 100 MB
num_client_threads 10 Livestatus needs one thread for each concurrent client connection. A fixed number of threads is created when Nagios starts
This parameter sets the size of the stack of each client thread. In versions before 1.1.4, the stack size was set to 8 MB (pthread default). The new default value is
thread_stack_size 65536 64 KB. A small stack reduces virtual memory usage and also save CPU ressources. A too small value will probably crash your Nagios process, though. You have
been warned
This value is in ms. In order to avoid being hung by broken clients, Livestatus imposes a limit on the time for reading the query from the client. A value of 0
query_timeout 10000
disables the timeout
idle_timeout 300000 This value is in ms. Livestatus is waiting at most that much time for the next query. A value of 0 disables the timeout
Ejemplo de como dejar MK Livestatus escuchando en un socket tcp para consultarlo por red, por ejemplo por un sistema de reportes al estilo Jasper Reports o
alguna interfaz alternativa como Thruk.
service livestatus
{
type = UNLISTED
port = 6557
socket_type = stream
protocol = tcp
wait = no
# limit to 100 connections per second. Disable 3 secs if above.
cps = 100 3
# set the number of maximum allowed parallel instances of unixcat.
# Please make sure that this values is at least as high as
# the number of threads defined with num_client_threads in
# etc/mk-livestatus/nagios.cfg
instances = 500
# limit the maximum number of simultaneous connections from
# one source IP address
per_source = 250
# Disable TCP delay, makes connection more responsive
flags = NODELAY
user = nagios
server = /usr/local/nagios/bin/unixcat
server_args = /usr/local/nagios/var/rw/live
# configure the IP address(es) of your Nagios server here:
# only_from = 127.0.0.1 10.0.20.1 10.0.20.2
disable = no
}
Nagvis
Nagvis es un addon para Nagios, con el cual podemos tener gráficos a modo de diagrama estructural de red, dinámicos, con lo cual podemos conocer el estado
actual de la red mirando un gráfico amigable al usuario final para que pueda tomar acciones y/o informar sobre el estado de los mismos a personal responsable.
Se pueden utilizar imágenes propias de fondo (denominadas mapas) y luego integrarle iconos representativos de las máquinas y servicios de la red que muestren
el estado actual de los mismos.
Deberemos bajar el paquete Nagvis desde su sitio web, y descomprimirlo y copiarlo a un directorio visible desde la interfaz web de Nagios.
Para instalar la configuración por defecto deberemos dentro de /usr/local/nagios/share/nagvis renombrar o mover el archivo etc/nagvis.ini.php-sample a
etc/nagvis.ini.php.
Para una correcta generación de la característica Automap de Nagvis, primero es necesario configurar todos los parents hosts para poder diagramar en tiempo
real la topología de red. Ademas deberemos tomar los iconos de la directiva statusmap_image que especificamos en el anexo hostextinfo, dicho icono se
almacena en nagios/share/images/logos, en formato gd2 entendible por el binario statusmap.cgi para mostrarlo via web, pero no es entendible por nagvis siendo
que este lo busca en base al parametro statusmap_image entonces aprovechando que dicho icono esta en formato gd2 y en formato png copiaremos en archivo
en formato png al directorio nagvis/images/shapes pero cambiandole la extensión de png a gd2, y entonces Nagvis lo vera como un gd2 siendo que realmente es
un PNG y debido a eso sera capas de mostrarlo.
Modificar el archivo nagvis/share/userfiles/templates/default.hover.html de la siguiente manera, agregando solo las dos lineas donde especificamos el tag img.
<table class="hover_table">
<tr><th colspan="2">[lang_obj_type] ([lang_last_status_refresh]: [last_status_refresh])</th></tr>
<tr><td class="label"><label>[lang_name]</label></td><td>[obj_name]</td></tr>
<!-- BEGIN service -->
<tr><td class="label"><label>[lang_service_description]</label></td><td>[service_description]</td></tr>
<!-- END service -->
<tr><td class="label"><label>[lang_alias]</label></td><td>[obj_alias]</td></tr>
<!-- BEGIN host -->
<tr><td colspan="2" style="text-align:center;"><img src="/nagios/pnp/index.php?host=[obj_name]&srv=_HOST_&source=1&view=0&display=image" with="300px" height="94px"></td></tr>
<tr><td class="spacer" colspan="2"></td></tr>
<tr><td class="label[obj_state]"><label>[lang_state] ([lang_state_type])</label></td><td class="state[obj_state]">[obj_state] ([obj_state_type])[obj_in_downtime][obj_acknowledged]
<tr><td class="label"><label>[lang_output]</label></td><td>[obj_output]</td></tr>
<tr><td class="label"><label>[lang_perfdata]</label></td><td>[obj_perfdata]</td></tr>
<tr><td class="label"><label>[lang_current_attempt]</label></td><td>[obj_current_check_attempt]/[obj_max_check_attempts]</td></tr>
<tr><td class="label"><label>[lang_last_check]</label></td><td>[obj_last_check]</td></tr>
<tr><td class="label"><label>[lang_next_check]</label></td><td>[obj_next_check]</td></tr>
<tr><td class="label"><label>[lang_last_state_change]</label></td><td>[obj_last_state_change]</td></tr>
<!-- END host -->
<tr><td class="spacer" colspan="2"></td></tr>
<tr><td class="label[obj_summary_state]"><label>[lang_summary_state]</label></td><td class="state[obj_summary_state]">[obj_summary_state] [obj_summary_in_downtime][obj_summary_acknowledged]
<tr><td class="label"><label>[lang_summary_output]</label></td><td>[obj_summary_output]</td></tr>
<!-- BEGIN service -->
<tr><td colspan="2" style="text-align:center;"><img src="/nagios/pnp/index.php?host=[obj_name]&srv=[service_description]&source=1&view=0&display=image" with="300px" height="94px"><
<tr><td class="label"><label>[lang_perfdata]</label></td><td>[obj_perfdata]</td></tr>
<tr><td class="label"><label>[lang_current_attempt]</label></td><td>[obj_current_check_attempt]/[obj_max_check_attempts]</td></tr>
<tr><td class="label"><label>[lang_state_type]</label></td><td>[obj_state_type]</td></tr>
<tr><td class="label"><label>[lang_last_check]</label></td><td>[obj_last_check]</td></tr>
<tr><td class="label"><label>[lang_next_check]</label></td><td>[obj_next_check]</td></tr>
<tr><td class="label"><label>[lang_last_state_change]</label></td><td>[obj_last_state_change]</td></tr>
<!-- END service -->
<!-- BEGIN childs -->
<tr><td class="spacer" colspan="2"></td></tr>
<tr><td colspan="2">
<table width="100%">
<tr>
<!-- BEGIN servicegroup --><td class="label"><label>[lang_child_name1]</label></td><!-- END servicegroup --><td class="label"><label>[lang_child_name]</label></td><
</tr>
<!-- BEGIN loop_child -->
<tr><!-- BEGIN servicegroup_child --><td>[obj_name1]</td><!-- END servicegroup_child --><td>[obj_name]</td><td class="state[obj_summary_state]">[obj_summary_state][obj_summa
<!-- END loop_child -->
</table>
</td></tr>
<!-- END childs -->
</table>
MySQL
MySQL es uno de los Sistemas Gestores de Bases de Datos Relacional multihilo y multiusuario, más populares,
Compilacion
Por defecto, el usuario root no tiene asignada una contraseña y esto no es nada recomendable, así que vamos a establecer una. Utilizamos el comando:
Cambiar ‘loquesea’ por la contraseña que desemos establecer, pero es importante no olvidarse de teclear las comillas simples.
mysql -u root -p
Nos pedirá la contraseña, la tecleamos, y si todo es correcto entraremos en la interfaz del cliente de MySQL, podemos teclear algún comando de mysql para
interactuar con el servidor, por ejemplo:
Nos mostrará las bases de datos que existan en el servidor, normalmente y si acabamos de instalar, aparecerán las bases de datos mysql y test.
+----------+
| Database |
+----------+
| mysql |
| nagios |
| test |
+----------+
3 rows in set (0.01 sec)
Ahora deberemos crear un usuario con privilegios de SELECT, INSERT, UPDATE, DELETE
mysql> quit
Paquetes
La instalacion de MySQL, en el caso de tenerlo empaquetado en nuestra distribucion Linux, es bastante simple
CentOS y RedHat
Para instalar el paquete mysql haremos uso de la utilidad de sistema up2date o yum
up2date mysql-server
Lo habitual será que cuando arranque o se pare nuestro servidor tambien se inicie o detenga el MySQL, para ello deberemos ejecutar:
Esto activa el demonio mysqld en los runlevel 3 y 5, y lo detiene en el resto. Si queremos comprobar el estado del servicio podemos utilizar lo siguiente:
Debian
/etc/init.d/mysql start
Nota SuSE
Para setear el arranque de un servicio en SuSE Linux deberemos ejecutar el comando insserv -d nombre_servicio con el parametro -d estariamos indicando una
opcion similar a defaults como en Debian.
Apache y PHP
Nagios muestra los estados de todos los servicios configurados a través de páginas web, esto implica que debe instalarse un servidor web con la información
correspondiente para hacerlo.
En esta etapa se hace dicha instalación siguiendo las mejores prácticas de instalación de Apache poniendo énfasis en su seguridad.
Apache es un software libre servidor HTTP de código abierto para plataformas Unix (BSD, GNU/Linux, etc.), Windows, Macintosh y otras, es el mas usado en
internet.
PHP es un lenguaje de programación interpretado, diseñado originalmente para la creación de páginas web dinámicas, en nuestro caso nos servira realizar una
interpretación extra de los datos de Nagios via web.
CentOS
/etc/init.d/httpd start
Debian
/etc/init.d/apache2 start
Configuración
Ahora nos referiremos a la configuración de los elementos instalados para su posterior articulación y funcionamiento en conjunto.
Implementación
Para el correcto funcionamiento de Nagios, y asegurar escalabilidad con orden, se debe seguir una estructura de configuración y tener previamente planteados
temas como:
Definición una estructura de archivos y directorios acorde a la situación, haciéndolo a su vez mas entendible para su posterior administración
Configurar Apache para su permitir su acceso via web por HTTP o HTTPS
En la mayoría de los equipos a monitorear mientras fuera posible instalar y dejar corriendo los servicios de SNMP
Configurar servicio de envío de emails
Definir grupos de contactos a los cuales se les enviarían los avisos de notificaciones, dependiendo de que hosts o servicio se trate.
Definir grupos de hosts y servicios, al tenerlos agrupados y verlos mas facilmente
A continuación se detalla como llevar a cabo dichos pasos necesarios para su implementación.
En el servidor
Configuraciones necesarias en el servidor de monitoreo.
Nagios
Algunos puntos basicos previos a la instalacion :
Estructura de archivos
Una vez que compilamos e instalamos el paquete Nagios nos termina quedando una nomenclatura de directorios como la siguiente :
bin
Aqui se almacenan los binarios ejecutables
etc
Guarda la configuracion de Nagios
libexec
Se almacenan los plugins que efectuaran los chequeos a monitorear
sbin
Dentro de este directorio se mantienen los ejecutables CGI de la interfaz web
share
Organiza el contenido web a mostrar, iconos, html, php etc
var
Guarda los datos de ejecucion del monitoreo, estado de servicios, hosts, y logs
bin
Dentro de este directorio encontramos los ejecutable principales, como el binario nagios que es el que se ejecuta como proceso en segundo plano, el objeto
ndomod.o que es el modulo que se encarga de traducir las estadisticas de nagios en formato de consultas MySQL, y ndo2db que el proceso en segundo plano
que se encarga conectarse con la base de datos para posteriormente ejecutar esas consultas.
etc
Este directorio guarda la configuración de Nagios, sus componentes, hosts/servicios a chequear, comandos de ejecucion, contactos de notificación, intervalos de
chequeos. Dentro de el hay diferentes subdirectorios y archivos.
libexec
Alli se contienen lo ejecutables de los plugins que efectuan los chequeos, SNMP, SAP, Oracle, SSH, que pueden ser binarios, scripts en Perl, PHP, Shell, Java, etc.
sbin
Aqui se almacenan los ejecutables cgi que se ejecutaran para la visualizacion por web de la consola Nagios.
share
Aqui encontramos el contenido web, imagenes, logos, los aditivos como PNP, Nagvis y los datos que necesitan para funcionar estos.
var
Aqui se guardan los datos internos de Nagios, estadisticas de los chequeos, informacion de ejecucion actual, archivos de sockets, registros de logs, colas de
ejecución de chequeos.
cgi.cfg
Usuarios con acceso permitido para ver la informacion de configuracion (separados por comas)
authorized_for_configuration_information=nagiosadmin
Usuarios con acceso permitido ejecucion de comandos nagios (separados por comas)
authorized_for_system_commands=nagiosadmin
Usuarios permitidos a ver informacion de hosts y servicios (separados por comas)
authorized_for_all_services=nagiosadmin
authorized_for_all_hosts=nagiosadmin
Usuarios permitidos para ejecutar comandos sobre hosts y servicios (separados por comas)
authorized_for_all_service_commands=nagiosadmin
authorized_for_all_host_commands=nagiosadmin
htpasswd.users
Archivo con passwords encriptadas de los usuarios que se autentificaran por HTTP
nagios.cfg
Archivo de configuracion principal de Nagios, aqui se especifican los directorios de trabajo y se incluyen los archivos de configuracion extra a utilizar por
Nagios
Con diversos parametros :
log_file se especifica el archivo de log a utilizar por Nagios
cfg_file se especifica un archivo de configuracion extra a incluir en la ejecucion de Nagios
cfg_dir se especifica un directorio con archivos de configuracion extra a incluir recursivamente en la ejecucion de Nagios
log_archive_path path donde se alojaran los archivos de log
use_syslog integracion con syslog
ndo2db.cfg
Archivo de configuracion del daemon que se encarga de introducir las consultar generadas por el modulo ndomod
ndomod.cfg
Modulo de Nagios que se encarga de traducir la informacion de ejecucion de Nagios en consultas MySQL, disponiendolas por medio de un socket
resource.cfg
objects/
objects/commands.cfg
Definicion de comandos de ejecucion por default, con los alias que queremos usar
objects/contacts.cfg
objects/localhost.cfg
objects/printer.cfg
objects/switch.cfg
objects/templates.cfg
Plantilla inicial para definir periodos de chequeos, aquí se definen los rangos de tiempo donde son válidos el envío de alertas y las verificaciones de los
servicios que están funcionando
objects/windows.cfg
services/
Aqui vamos a definir los servicios que usaremos en los chequeos. Se define la métrica o el servicio a monitorizar y el host/grupo de hosts sobre el que se
ejecuta
var/rw/
Alli se encuentra un archivo special de socket que realiza la comunicacion de los comando y ordenes de la interfaz web hacia nagios, como cambiar horarios de
chequeo, deshabilitar notificaciones etc.
El archivo que alli se encuentra nagios.cmd debe tener permisos de escritura y lectura por el propietario y el grupo de pertenencia nagios:nagcmd (660),
nagcmd es un grupo especial en el cual vamos a incluir al usuario que ejecuta el servidor web (ej. en apache sobre Debian www-data), y asi poder enviar
ordenes desde la interfaz web CGI. Esta es una característica avanzada de Nagios es que permite vía web la ejecución de ciertas tareas más allá del propio
conjunto de CGI’s que vienen de serie, como por ejemplo la
caída o el reinicio del propio Nagios, etcétera. Para poder ejecutar este tipo de comandos es necesario también configurar el sistema de una forma un tanto
especial. No hay que olvidar que al configurar Nagios de este modo se está permitiendo desde la web activar o desactivar opciones que en principio sólo estaban
disponibles desde la consola del sistema. Para configurar Nagios de esta forma, hay que editar el fichero principal nagios.cfg y añadir (o modificar si ya existen)
las siguientes líneas:
check_external_commands=1
command_check_interval=-1
command_file=/usr/local/nagios/var/rw/nagios.cmd
Lo que hará que Nagios active el chequeo para buscar comandos externos, con tanta frecuencia como sea posible por el sistema y buscará los comandos en el
archivo nagios.cmd.
diagrama_nagios.dia.gz
Buenos Aires
Lanús
Florencio Varela
CABA
Olavarria
Bahia Blanca
Santa Fe
Rosario
Neuquén
Zapala
San Martin
En este caso, simplemente deberemos tener templates para hosts y servicios, que se dividan por tipo. Si es un servidor, equipo de red, scada etc.
Argentina
Buenos Aires
Neuquen
Tucuman
Brasil
Rio
Cajati
Paraguay
Ciudad del este
Villa hayes
Portugal
Lisboa
En este caso algo mas complejo, deberemos tener templates para hosts divididos para cada país, templates para servicios divididos para cada país, templates
para contactos divididos para cada país.
Siempre debemos utilizar templates para todo, porque cuando debemos hacer un cambio en masa es mucho mas simple y con menos posibilidad a errores.
SNMP Traps
Una trap es generado por el agente snmp en el dispositivo a monitorear para reportar ciertas condiciones y cambios de estado en un procesp
Se “cae” un servicio
Hay un problema de memoria o de hardware
La carga de procesos excede un límite
Se llena una partición de disco
En debian para instalar el manejador de traps SNMP deberemos ejecutar los siguiente :
/etc/snmp/snmptt.ini
mode = daemon
log_system_enable = 1
unknown_trap_log_enable = 1
mysql_dbi_enable = 1
mysql_dbi_host = localhost
mysql_dbi_port = 3306
mysql_dbi_database = snmptt
mysql_dbi_table = snmptt
mysql_dbi_table_unknown = snmptt_unknown
mysql_dbi_table_statistics = snmptt_statistics
mysql_dbi_username = snmptt
mysql_dbi_password = mytrap
/etc/snmp/snmptt.conf
/etc/snmp/snmptrapd.conf
disableAuthorization yes
traphandle default /usr/sbin/snmptthandler
Configuración de permisos :
/etc/default/snmpd
TRAPDRUN=yes
Schema MySQL
USE snmptt;
USE snmptt;
/etc/init.d/snmptt
/etc/init.d/snmpd
Ref.: http://exchange.nagios.org/directory/Addons/SNMP/Nagios-SNMP-Trap-Interface-%28NSTI%29/details
[http://exchange.nagios.org/directory/Addons/SNMP/Nagios-SNMP-Trap-Interface-%28NSTI%29/details]
Apache
Para permitir y tener una correcta visualizacion de la consola web de Nagios, procederemos a realizar una configuración personalizada dentro del servidor web
Apache.
Deberemos crear un archivo de configuracion preferentemente con el nombre nagios.conf para tenerlo de una manera mejor organizada, y deberá ir dentro del
directorio de donde el Apache obtiene su configuración, el mismo dependerá del método de instalación elegido o con que distribución de Linux estemos
trabajando.
CentOS /etc/httpd/conf.d
Debian /etc/apache2/site-available y luego crear un link simbolico a ese archivo dentro de /etc/apache2/site-enabled
SuSE /etc/apache2/vhosts.d
Configuración SSL
La configuración HTTPS con SSL se realiza por defecto en la instalación del paquete Debian y CentOS, no asi en SuSE para ellos deberemos realizar
configuraciones extra.
Dentro del archivo /etc/sysconfig/apache2 deberemos agregarle el siguiente FLAG de arranque para especificar la utilización del protocolo SSL dentro del
servidor web Apache.
APACHE_SERVER_FLAGS="-D SSL"
A continuación mostramos un archivo de configuración de Apache mas elaborado con autenticación por ActiveDirectory
<VirtualHost *:443>
SSLEngine on
SSLCertificateFile /etc/apache2/ssl.crt/server.crt
SSLCertificateKeyFile /etc/apache2/ssl.key/server.key
ScriptAlias /nagios/cgi-bin "/usr/local/nagios/sbin"
<Directory "/usr/local/nagios/sbin">
AuthType Basic
AuthName "Nagios Access"
AuthLDAPEnabled On
AuthLDAPURL ldap://192.168.1.9:389/OU=Usuarios,DC=test,DC=com,DC=ar?SamAccountName?sub?(&(objectClass=user)(memberOf=CN=Monitoreo,OU=Tech,OU=Grupos,DC=test,DC=com,DC=ar))
AuthLDAPBindDN [email protected]
AuthLDAPBindPassword *****
Options All
Order allow,deny
Allow from all
SSLRequireSSL
AllowOverride None
Require valid-user
</Directory>
El usuario Bind debe ser un usuario solo con privilegios necesarios para saber que usuarios existen (ver documentación LDAP), y su contraseña debe estar
almacenada en texto plano en la configuración, y el archivo de configuración debe tener los debidos permisos para que no sean leídos por otros usuarios.
Que sean miembros del grupo Monitoreo a su vez dentro del grupo Tech
memberOf=CN=Monitoreo,OU=Tech,OU=Grupos,DC=test,DC=com,DC=ar
En caso de tener requerimientos mas exhaustivos con respecto a la autenticación, como restringir el acceso por ip se puede agregar a cada campo <Directory>
los siguientes parámetros.
Order deny,allow
Deny from all
Allow from 127.0.0.1
En el caso por ejemplo de que usemos otro sistema de autenticacion como CAS, deberemos compilar el modulo de apache Auth_CAS, si estammos usando
Debian podemos bajarnos los archivos libapache2-mod-auth-cas_1.0.8.orig.tar.gz libapache2-mod-auth-cas_1.0.8-3.diff.gz, ya que a la fecha no estan en la
rama estable, si no en la inestable, pero tenemos los fuentes originales y el diff para parchear esos fuentes y ejecutar los scripts que lo convierten en paquete
debian. Antes deberemos tener instalados los paquetes debhelper y dh-make en el sistema.
Con eso tenemos el paquete libapache2-mod-auth-cas listo para funcionar, para instalarlo deberemos ejecutar el comando dpkg -i libapache2-mod-auth-
cas_1.0.8-3_i386.deb, luego ejecutar el comando a2enmod auth_cas, con lo cual habilitamos ese modulo en la ejecucion del servicio Apache.
En el archivo de configuración del site de Nagios, deberemos incluir las siguientes lineas.
CASAllowWildcardCert On
#CASCookiePath /tmp/mod_auth_cas/
CASDebug On
CASValidateServer Off
CASValidateDepth 9
CASLoginURL https://servidorcas/cas/login
CASValidateURL https://servidorcas/cas/proxyValidate
CASTimeout 7200
CASIdleTimeout 7200
En la directiva CASCookiePath, especificamos un directorio temporal donde alojar las cookies, por default en debian es /var/cache/apache2/mod_auth_cas
Luego en cada entrada Directory eliminamos todas las entradas de autenticacion y las cambiamos a solo esta AuthType CAS.
Deberemos reiniciar el servicio Apache para que los cambios tengan efecto.
Configuración de Email
Para el envío de notificaciones por parte de Nagios es necesario configurar un MTA (Agente de Transporte de Correos), por lo general suele estar previamente
configurado el Sendmail en el caso de que nos basemos en un CentOS, o un Postifx tratándose de un SuSE o Debian.
En caso de que utilizemos el paquete de Postfix disponible en la distribución, y debamos utilizar otro servidor saliente SMTP dentro de la red, deberemos
configurar el relayhost apuntando al servidor SMTP de la red local ej 192.168.1.110, quedando el archivo /etc/postfix/main.cf con las siguientes entradas de
configuración.
queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix
mail_owner = postfix
myhostname = nagios
mydomain = midominio.net
inet_interfaces = $myhostname
unknown_local_recipient_reject_code = 550
debug_peer_level = 2
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq
setgid_group = maildrop
html_directory = /usr/share/doc/packages/postfix/html
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/packages/postfix/samples
readme_directory = /usr/share/doc/packages/postfix/README_FILES
mail_spool_directory = /var/mail
canonical_maps = hash:/etc/postfix/canonical
virtual_maps = hash:/etc/postfix/virtual
relocated_maps = hash:/etc/postfix/relocated
transport_maps = hash:/etc/postfix/transport
sender_canonical_maps = hash:/etc/postfix/sender_canonical
masquerade_exceptions = root
masquerade_classes = envelope_sender, header_sender, header_recipient
program_directory = /usr/lib/postfix
inet_interfaces = 192.168.1.4
masquerade_domains =
mydestination = $myhostname, localhost.$mydomain
defer_transports =
disable_dns_lookups = no
relayhost = 192.168.1.110
content_filter =
mailbox_command =
mailbox_transport =
smtpd_sender_restrictions = hash:/etc/postfix/access
smtpd_client_restrictions =
smtpd_helo_required = no
smtpd_helo_restrictions =
strict_rfc821_envelopes = no
smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination
smtp_sasl_auth_enable = no
smtpd_sasl_auth_enable = no
smtpd_use_tls = no
smtp_use_tls = no
alias_maps = hash:/etc/aliases
mailbox_size_limit = 0
message_size_limit = 10240000
Siendo los parámetros : inet_interfaces la ip propia por cual salir, si tenemos una sola placa de red, pondremos esa ip, relayhost es el host que nos realizará
el envío SMTP.
PNP4Nagios
Para la ejecución de almacenamiento de gráficas deberemos configurar ciertos comandos que obtengan los resultados de la ejecución de comandos y servicios,
para ellos deberemos agregar y/o modificar en la configuración de Nagios ciertos parámetros :
Modo Síncrono
El modo síncrono es la forma más fácil de integrar en nagios el recolector de datos process_perfdata.pl. Cada evento dispara la ejecución de process-service-
perfdata.
enable_environment_macros=1
service_perfdata_command=process-service-perfdata
host_perfdata_command=process-host-perfdata
define command {
command_name process-service-perfdata
command_line /usr/bin/perl /usr/local/nagios/pnp4nagios/libexec/process_perfdata.pl
}
define command {
command_name process-host-perfdata
command_line /usr/bin/perl /usr/local/nagios/pnp4nagios/libexec/process_perfdata.pl -d HOSTPERFDATA
}
Modo Masivo
En el modo masivo, Nagios escribe los datos a un fichero temporal en un formato predefinido. Este fichero se procesa mediante process_perfdata.pl a intervalos
regulares. Nagios controla el arranque y ejecución periódica del recolector de datos. .
commands.cfg
define command{
command_name process-service-perfdata-file
command_line /usr/local/nagios/pnp4nagios/libexec/process_perfdata.pl --bulk=/usr/local/nagios/pnp4nagios/var/service-perfdata
}
define command{
command_name process-host-perfdata-file
command_line /usr/local/nagios/pnp4nagios/libexec/process_perfdata.pl --bulk=/usr/local/nagios/pnp4nagios/var/host-perfdata
}
Se vuelca la informacion de perfdata en una cola para luego ser procesada por un proceso en segundo plano, lo cual libera gran carga del CPU.
nagios.cfg
process_performance_data=1
#
# service performance data
#
service_perfdata_file=/usr/local/nagios/var/service-perfdata
service_perfdata_file_template=DATATYPE::SERVICEPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tSERVICEDESC::$SERVICEDESC$\tSERVICEPERFDATA::$SERVICEPERFDATA$\tSERVICECHECKCOMMAND::$SERVICECHECKCOM
service_perfdata_file_mode=a
service_perfdata_file_processing_interval=15
service_perfdata_file_processing_command=process-service-perfdata-file
#
# host performance data starting with Nagios 3.0
#
host_perfdata_file=/usr/local/nagios/var/host-perfdata
host_perfdata_file_template=DATATYPE::HOSTPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tHOSTPERFDATA::$HOSTPERFDATA$\tHOSTCHECKCOMMAND::$HOSTCHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::
host_perfdata_file_mode=a
host_perfdata_file_processing_interval=15
host_perfdata_file_processing_command=process-host-perfdata-file
commands.cfg
define command{
command_name process-service-perfdata-file
command_line /bin/mv /usr/local/nagios/var/service-perfdata /usr/local/nagios/var/spool/perfdata/service-perfdata.$TIMET$
}
define command{
command_name process-host-perfdata-file
command_line /bin/mv /usr/local/nagios/var/host-perfdata /usr/local/nagios/var/spool/perfdata/host-perfdata.$TIMET$
}
Y luego ejecutar :
/etc/init.d/npcd start
Datos de configuración
service_perfdata_file
Ruta al archivo temporal que debe contener los datos de rendimiento.
service_perfdata_file_template
Formato del archivo temporal. Los datos se definen utilizando Nagios macros.
service_perfdata_file_mode
Opción “a” especifica que los datos se insertan como anexo.
service_perfdata_file_processing_interval
El intervalo de procesamiento es de 15 segundos
service_perfdata_file_processing_command
El comando que habrá de ejecutarse durante dicho intervalo.
Luego se deja ejecutando en segundo plano el demonio npcd para procesar la cola de mensajes.
En modo masivo con NPCD se puede deshabilitar la opcion enable_environment_macros para ahorrar carga de CPU, ya que en este modo esta ya no es
requerida.
Si en algún momento se llega a colgar el demonio NPCD o si por algo falla el procesamiento de los archivos de perfdata, reiniciamos NPCD y va a reprocesar los
archivos en el spool de perfdata para volver a incluir la información faltante en RRD.
Interfaz web
action_url /pnp4nagios/index.php/graph?host=$HOSTNAME$
action_url /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=$SERVICEDESC$
En los clientes
Podemos elegir monitorear los clientes por medio del protocolo ICMP, SNMP o de mecanismos como ver si tenemos x puerto abierto, o ciertos mensajes de
respuesta, aqui se comentan los protocolos mas comunes para monitorear estados de equipos (ICMP/SNMP) o servicios (SNMP).
ICMP
El protocolo ICMP (Internet Control Message Protocol) puede ser considerado como parte de la capa IP. La especificación completa de este protocolo se encuentra
en RFC 792 [http://www.ietf.org/rfc/rfc792.txt]. Aunque sus mensajes son encapsulados en datagramas IP como cualquier otro protocolo de capa superior, su uso
corresponde a mensajes especiales de la propia capa de red, aunque también pueden acceder a él las propias aplicaciones (por ejemplo el programa ping).
Algunos ejemplos de uso de ICMP son: obtención de máscaras de red (solicitud y respuesta), obtención de marcas de tiempo (solicitud y respuesta), condiciones
de error del tipo “port unreachable” o “se necesita fragmentar el datagrama habiéndose solicitado la no-fragmentación”, petición y respuesta de eco para
comprobar la actividad de otro host, información sobre el estado de las comunicaciones en una red, etc.
Los mensajes de query incluyen tras la cabecera 2 bytes de identificación, para que el cliente distinga las respuestas dirigidas a él de las dirigidas a otros
procesos, y 2 btes de número de secuencia, para que el cliente pueda identificar 'requests' con 'replays'. La generación de replys suele correr a cargo del kernel
(no es un proceso de usuario). Los mensajes ICMP de 'query' más importantes son:
Petición/respuesta de máscara: Aunque normalmente se usa DHCP, también es posible para el host hacer una petición durante el proceso de arranque
para obtener la máscara y una petición RARP para obtener su IP. La petición de máscara suele enviarse en difusión. Un servidor de máscaras se encarga de
contestar.
Petición/respuesta de marca de tiempo: Se utiliza para conocer el tiempo que un host tarda en procesar un mensaje y contestarlo o para sincronizar
relojes entre hosts. Los tiempos se ponen en milisegundos desde las 0h UTC (Tiempo Coordinado Universal). Se proveen tres campos, a parte de los
anteriormente citados para este tipo de mensajes. 'Marca de tiempo de generación', a rellenar por el emisor, y 'Marca de tiempo de recepción', y 'Marca de
tiempo de transmisión', a rellenar por el receptor. Los significados de los campos resultan evidentes.
Solicitud/anuncio de router: Se trata de una forma de inicializar la tabla de enrutamiento. Tras el arranque, un host envía en broadcast o multicast un
mensaje de solicitud de router. Uno o más routers responderán con mensajes de anuncio de router. Esto lo podrán hacer periódicamente permitiendo a los
hosts actualizar sus tablas de enrutamiento.
Petición/respuesta de eco: Se utiliza para conocer si un host está en red. El mensaje ICMP contiene unos datos OPCIONALES cuyo contenido es irrelevante.
Muchos SO implementan este mensaje mediante el programa ping. En las implementaciones UNIX de ping el campo identificador suele asociarse con el ID del
proceso que envía el request. Esto permite identificar las respuestas si hubiera varias instancias de ping corriendo en el mismo host. En el campo de
secuencia, se suele llevar un contador que permite ver si se han perdido, duplicado o desordenado paquetes, cosa típica en la capa IP sobre la que se
encapsulan los mensajes ICMP.
Ya se ha dicho que el formato de los mensajes de error tan sólo incluye, además de la cabecera, una copia de la cabecera IP del datagrama que generó el error y
los 8 primeros bytes del datagrama. En algunos de los ejemplos que siguen veremos la razón de ser de este formato:
Destination unreachable: Este tipo de mensajes de error se generan cuando por alguna razón, el datagrama no pudo alcanzar su destino (puerto, host, red
inalcanzable, necesidad de fragmentar con bit DF activado…). La forma de comunicar este error a la capa superior es copiando la cabecera IP en el propio
mensaje de error. Gracias al campo 'protocolo' el módulo ICMP que lo reciba sabrá asociarlo con el protocolo adecuado. Supongamos que se produce un 'port
unreachable' en el envío de un datagrama UDP. La cabecera IP permite identificar que el error se produjo en el protocolo UDP, y además esto sirve para
interpretar los 8 bytes adicionales, que pertenecerán a la cabecera UDP. Estos contendrán los puertos origen y destino (ver tema UDP). El puerto de origen
puede servir para asociar el error con un determinado proceso de usuario (ej. puerto 2924 asociado a un cliente tftp), mientras que el destino nos indica qué
puerto originó el error 'port unreachable'.
Otro ejemplo, al intentar hacer ping al otro equipo de la red, que está apagado, se obtiene lo siguiente:
Se han producido mensajes ICMP de error en respuesta a mensajes ICMP de query, lo cual SI está permitido, como ya se ha dicho.
Source quench: Este tipo de mensaje es generado por un router con problemas de congestión para avisar al host fuente de que reduzca el flujo de
transmisión. Es muy poco usado, normalmente los routers se limitan a tirar paquetes y a intentar solucionar la congestión mediante algoritmos de
enrutamiento.
Parameter problem: Si un router intermedio o el host destino encuentran un problema en la cabecera IP que le obliga a desecharlo, puede enviar un
mensaje ICMP de este tipo al host fuente. Si el código es cero, un puntero marca el lugar de la cabecera en el que se produjo el error.
Redirección: Son enviados por un router al remitente de un datagrama IP cuando éste debería haber sido enviado a través de otro router.
Time Exceeded: Son enviados al remitente de un datagrama IP cuando se cumple el tiempo de vida máximo del paquete. Esto puede ocurrir porque el
campo TTL del datagrama se haya puesto a 0 en un router, o bien el tiempo de reensamblado de fragmentos se haya cumplido en el destino. Basándose en
este mensaje, y variando el campo TTL de un mensaje de petición de eco es posible obtener la ruta a un destino. Si el TTL es insuficiente, se recibirá un
mensaje de tiempo excedido por cada router donde al recalcular el TTL valga 0, y un mensaje de respuesta de eco cuando el TTL sea suficiente para llegar al
destino. El comando tracert de windows se basa en este algoritmo.
Protocolo Simple de Administración de Red o SNMP es un protocolo de la capa de aplicación que facilita el intercambio de información de administración entre
dispositivos de red. Es parte de la familia de protocolos TCP/IP. SNMP permite a los administradores supervisar el desempeño de la red, buscar y resolver sus
problemas, y planear su crecimiento. Podemos conocer datos internos de dispositivos a monitorear, ej uso de CPU, Memoria, Disco, Uptime etc.
Los agentes se centran en recopilar cierta información y mantenerla organizada para que el gestor pueda acceder a ella cuando lo necesite. El agente también
puede mandar notificaciones al gestor sobre problemas o información relevante sin que el gestor se lo solicite.
El gestor controla y actúa sobre los elementos de la red, controlando la información que recopilan los agentes se pueden tomar decisiones y actuar sobre la red
para mejorar los aspectos que se necesiten. Para ello se basa en tres elementos:
SMI es el conjunto de estructuras y esquemas para definir elementos de las MIB. Dichas estructuras están formateadas en ASN.1 (Abstract Synstax Notation
One), indicando cómo debe ser el nombre, la sintaxis y el método de codificación de los datos para su transmisión por la red.
Acceso: Puede ser: read-only, read-write, write-only, not-acessible. SMIv2 incluye además read-create, y deja de usar write-only
Status: Puede ser: mandatory (en SMIv2 se indica como current), que tienen que ser implementadas por cualquier versión de la MIB que incluya ese modulo,
optional, que pueden faltar sin que eso cause ningún problema ( en vez de optional, SMIv2 incluye deprecated, para objetos que ya no se usan, y que por
tanto, no tienen por qué estar implementados), u obsolete, que han dejado de mantenerse y revisarse.
Descripción: Definición textual de la semántica del tipo de objeto. No es codificable mediante una computadora, es una descripción para programadores y
administradores que pueden leerla para entender el funcionamiento de la MIB.
La definición termina indicando bajo qué nodo del árbol de OIDs (ver la siguiente sección) debe situarse y con qué número a efectos de identificación
La información requerida de un sistema se almacena en las MIBs usando una estructura jerárquica que contiene los identificadores de objeto descritos mediante
ASN.1.
Esta jerarquía de árbol contiene los elementos que pueden ser de tipo escalar o tablas de datos. Estos objetos cuelgan en el árbol de la MIB de la rama
correspondiente a la organización que mantiene dicha estructura. Se nombra a los ejemplares de la MIB mediante su identificador de objeto que es una cadena
de enteros que representa como cuelga el objeto del nodo raíz. Por ejemplo IP es el (1.3.6.1.2.1.4.)
Esta es la estructura de la MIB-II (RFC 1213) y sus diferentes subgrupos. Estas son algunas de las variables que se mantienen en cada grupo:
Grupo system: Descripción de la entidad, identificador, tiempo desde arranque, nombre del administrador, localización física, servicios ofrecidos
Grupo interfaces: Número de interfaces del sistema
Grupo at: Número de interfaz, Dirección física, Dirección IP
Grupo ip: Si el sistema hace forward, valor del TTL, número de datagramas recibidos y enviados, errores, datagramas con protocolo no válido, etc.
Grupo icmp: cuatro contadores generales: número total de mensajes ICMP de entrada y salida con o sin errores y 22 contadores para los diferentes mensajes
ICMP
Grupo tcp: Algoritmo de retransmisión, timeout en milisegundos, número de conexiones TCP, número de transiciones entre los diferentes estados de TCP,
número de segmentos recibidos y enviados, número de segmentos retransmitidos, con error y con el flag RST activado.
Grupo udp: Número de datagramas enviados y recibidos, datagramas sin proceso receptor
Grupo egp: Número de mensajes de encaminamiento recibidos con y sin error, número de mensajes generados en el sistema, estado del sistema.
Como sigue el paradigma gestor-agente la los comandos son para solicitar, modificar o devolver información de la MIB, así como envíar notificaciones (traps).
Las operaciones disponibles en SNMPv1 son:
Posteriormente, a partir de la versión 2 se introdujo la operación de get-bulk-request, que permite realizar varios get-next seguidos sin tener que hacer varias
peticiones. También se introdujo la operación de inform, para que distintos gestores puedan intercambiarse notificaciones.
SNMPv1
SNMPv3
Configuramos un usuario que se llama nagios con autenticacion, en la siguiente linea lo creamos con una clave almacenada en texto plano en este archivo y
luego encriptada en MD5 y DES
Debemos reiniciar el servicio SNMP y luego podemos hacer algo como esto
TIPS
De:
A:
A veces por causa de tener montados filesystems remotos NFS o CIFS, cuando tenemos retrasos en la conexion con ellos se puede colgar el servicio SNMP, para
prevenir esto deberemos agregar la siguiente opción en el archivo de configuración snmpd.conf.
skipNFSInHostResources yes
/usr/local/bin/var.sh
echo "hola"
echo "chau"
UCD-SNMP-MIB::ucdavis.555.1.1 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.555.2.1 = STRING: "/bin/sh"
UCD-SNMP-MIB::ucdavis.555.3.1 = STRING: "/tmp/bar.sh"
UCD-SNMP-MIB::ucdavis.555.100.1 = INTEGER: 0
UCD-SNMP-MIB::ucdavis.555.101.1 = STRING: "hola"
UCD-SNMP-MIB::ucdavis.555.101.2 = STRING: "chau"
UCD-SNMP-MIB::ucdavis.555.102.1 = INTEGER: 0
UCD-SNMP-MIB::ucdavis.555.103.1 = ""
SNMPv1 en Windows
En los equipos Windows se configurara una community RO (read only) denominada public, acceso para la ip que corresponda al servidor que tiene acceso al
SNMP, en este caso nuestro nagios.
Para ello nos situamos en el panel de control dentro de agregar programas en la sección de componentes.
Una vez dentro nos situamos dentro de Herramientas de administración y supervisión o Management and Monitoring tools
Luego en la Administración de Servicios, nos dirigiremos a las propiedades del servicio SNMP
Dentro de ella nos encontraremos con un cuadro de dialogo
A veces en Windows es necesario configurar el servicio de Firewall para permitir las consultas por medio SNMP.
NRPE
NSClient++
nsclient.ini
[/settings/external scripts/scripts]
check_pagefile="C:\Program Files\Nagios Plugin Collection\check_pagefile.exe"
En el Monitoreo
Creando directivas
Debemos crear algunas entradas de configuración para especificar donde encontramos los servicios, grupos, contactos etc, las mismas debemos incluirlas en
nuestro archivo de configuración nagios.cfg
Con la directiva cfg_dir el indicamos Nagios que tome como configuración los archivos con extencion “cfg” encontrados en tal directorio.
Configuración de alertas
Para que el Nagios envíe notificaciones sobre el estado de los servicios es necesario definir grupos a los cuales enviárselas, y dentro de ellos estarán los
miembros a cuales enviarlos
define contactgroup{
contactgroup_name admin
alias Administrators
members admin-sap,admin-windows
}
define contactgroup{
contactgroup_name {nombre del grupo contacto}
alias {descripcion}
members {miembros del grupo}
}
contactgroup_name
alias
members
Se deberá crear el archivo {nagios-dir}/etc/contactgroups/{nombregrupodecontacto.cfg} con las entradas correspondientes anteriormente explicadas.
Agregando Contactos
Para recibir las notificaciones de Nagios es necesario generar contactos que estén incluidos en diferentes grupos de contactos, una configuración simple para un
contacto se ve como la siguiente entrada
define contact{
contact_name admin
alias Administrador Nagios
contactgroups admin
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify-by-email
host_notification_commands host-notify-by-email
email root@localhost
}
define contact{
contact_name {nombre del contacto}
alias {descripcion del contacto}
contactgroups {grupo de contactos al cual pertenece}
service_notification_period {priodo de tiempo de notificaciones de servicios}
host_notification_period {priodo de tiempo de notificaciones de hosts}
service_notification_options {opciones de notificacion por servicio}
host_notification_options {opciones de notificacion por host}
service_notification_commands {comando de notificacion a utilizar por servicio}
host_notification_commands {comando de notificacion a utilizar por host}
email {direccion de email del contacto}
}
contact_name
alias
contactgroups
service_notification_period
host_notification_period
service_notification_options
host_notification_options
service_notification_commands
Comando para realizar la notificación del estado del servicio, podemos definir múltiples comandos
host_notification_commands
Comando para realizar la notificacion del estado del host, podemos definir múltiples comandos
Email perteneciente al contacto en el cual recibira las notificaciones por email. Para que esto funcione se debe tener correctamente configurado el mail delivery
local.
Se deberá crear el archivo {nagios-dir}/etc/contacts/{nombredecontacto.cfg} con las entradas correspondientes anteriormente explicadas.
Podemos estilizar nuestras alertas por email de nagios con colores, símbolos eh imágenes.
Aquí adjunto dos scripts descargados de nagiosexchange que están modificados por mi :
nagios_send_host_mail.pl.gz nagios_send_service_mail.pl.gz
Podemos configurar alertas SMS de forma muy simple con el software Gnokii.
[global]
port = /dev/ttyUSB2
model = AT
initlength = default
connection = serial
use_locking = yes
serial_baudrate = 19200
smsc_timeout = 10
[connect_script]
TELEPHONE = 12345678
[disconnect_script]
[fake_driver]
[flags]
[gnokii]
[gnokiid]
[logging]
debug = on
rlpdebug = off
xdebug = off
Modo de uso :
Definición como comando de notificación, (podemos agregarlo como comando extra al contacto, para que ademas del comando común de notificación por email
tambien se ejecute este para el envío de la alerta por sms).
Notemos que lo ejecutamos por ssh, es para una situación hipotética de que el modem USB 3G de nuestro proovedor de telefonía celular este enchufado en otra
maquina de nuestra red.
define command {
command_name host-notify-by-sms
command_line ssh [email protected] "echo "Host '$HOSTNAME$' esta $HOSTSTATE$ $HOSTOUTPUT$" | sudo gnokii --sendsms $CONTACTPAGER$"
}
define command {
command_name service-notify-by-sms
command_line ssh [email protected] "echo 'Servicio $SERVICEDESC$ en Host $HOSTNAME$ IP $HOSTADDRESS$ State $SERVICESTATE$ Info $SERVICEOUTPUT$' | sudo gnokii --sendsms $CONTACTPAGER$"
}
nagios_sms.svg.gz
Agregando Comandos
En Nagios los encargados de recabar los datos del monitoreo, de mostrar alertas, de todas las tareas, son los comandos.
Los mismos se dividen en comandos de performance y en comandos de chequeo, los primeros son utilizados para algunos casos en particular.
Los comandos de chequeo no traen datos de los equipos a monitorear, como consumo de CPU, Memoria, Disco, procesos corriendo, puertos abiertos etc, es decir
todos los datos necesarios de la monitoria.
Los comandos de performance se utilizan cuando hay que guardar ciertos datos o enviarlos a algún host externo etc, con información de algún servicio.
define command{
command_name check_snmp_mem
command_line $USER1$/check_snmp_mem.pl -H $HOSTADDRESS$ $ARG1$ -w $ARG2$ -c $ARG3$ $ARG4$
}
define command{
command_name {nombre del comando}
command_line {datos de ejecucion}
}
command_name
command_line
Modo del cual Nagios ejecutara el comando en cuestión, con su ruta física y argumentos Lo que vemos en entre signos $ son variables internas de nagios,
llamadas macros, las mas comunes son:
$ARG1$ $ARG2$ $ARG3$ $ARG4$ : Son los números en orden de argumentos que recibe el comando a ejecutar
define servicegroup{
servicegroup_name lotus_response
alias Lotus Reponse Services
}
define servicegroup{
servicegroup_name {nombre corto del grupo de servicio}
alias {alias descriptivo completo del grupo}
}
Se deberá crear el archivo {nagios-dir}/etc/servicegroup/{nombregrupodeservicios.cfg} con las entradas correspondientes anteriormente explicadas.
Agregando Servicios
A continuacion se muestra una tipica entrada de configuración de un servicio
define service {
use windows
host_name srv1,srv2
hostgroup_name servidores-windows
service_description Verification disco F:
servicegroups storage
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 5
retry_check_interval 1
contact_groups windows
notification_interval 240
notification_period 24x7
notification_options c,r
check_command check_snmp_storage!^F!60!90!-C public!-r
}
define service {
use {template de servicio a utilizar}
host_name {hosts que ejecutan dicho servicio}
hostgroup_name {grupos de host que ejecutan ese servicio}
service_description {descripcion del servicio}
servicegroups {grupo al cual pertenece}
is_volatile {si el servicio es volatil}
check_period {periodo de tiempo para el chequeo}
max_check_attempts {maximo de intentos de chequeo}
normal_check_interval {intervalo de tiempo a programar los chequeos}
retry_check_interval {intervalo de tiempo para un re-chequeo}
contact_groups {grupo de contacto};
max_check_attempts {maxima cantidad de chequeos}
notification_interval {intervalo de tiempo entre notificaciones}
notification_period {priodo de tiempo de notificaciones}
notification_options {cuando enviar notificaciones}
check_command {comando de chequeo con sus argumentos}
}
use
host_name
Nombre del o los host a los cuales esta asignado dicho servicio
hostgroup_name
Nombre del grupo de host en los cuales esta asignado dicho servicio, es útil para cuando se vuelve tedioso poner uno por uno los nombres de los hosts a los
cuales se asigna el servicio
service_description
contact_groups
max_check_attempts
Maxima cantidad de chequeos a efectuar por Nagios, antes de enviar un OK como resultado
normal_check_interval
Intervalo de tiempo antes de programar un nuevo chequeo del servicio
retry_check_interval
notification_interval
Esta directiva se utiliza para definir el número de las “unidades del tiempo” para esperar antes de re-notificar a un contacto que este servidor todavía está abajo
o inalcanzable. A menos que se haya cambiado la directiva interval_length del valor prefijado de 60, este número significará minutos. Si este valor se establece a
0, Nagios re-no notificará contactos sobre los problemas para este host - solamente una notificación del problema será enviada.
notification_period
notification_options
Esta directiva indica a Nagios en que momentos debe enviar notificaciones de estado
check_command
Se deberá crear el archivo {nagios-dir}/etc/services/{nombreservicio.cfg} con las entradas correspondientes anteriormente explicadas.
En caso en los cuales el estado de un servicio dependa de la disponibilidad o el estado de otro, se pueden definir dependencias. Una entrada a modo ejemplo
puede ser:
define servicedependency{
host_name Host A
service_description Service A
dependent_host_name Host B
dependent_service_description Service D
execution_failure_criteria u
notification_failure_criteria n
}
define servicedependency{
host_name {host donde se ejecuta el servicio dependiente}
service_description {servicio dependiente}
dependent_host_name {host donde se ejecuta el servicio del cual se depende}
dependent_service_description {servicio del cual se depende}
execution_failure_criteria {criterio para establecer el estado}
notification_failure_criteria {notificar segun x estado}
}
host_name
Nombre del o los host dentro de los cuales se ejecuta el servicio dependiente
service_description
Descripcion del servicio dependiente, debe ser igual a la entrada que aparece en la configuracion del servicio.
dependent_host_name
dependent_service_description
Nombre descriptivo que corresponde al servicio del cual se depende, debe ser igual al de su configuracion de servicio
execution_failure_criteria
notification_failure_criteria
En base a que estado realizar las notificaciones, si esta caido, si esta ok o no realizar notificaciones
En algunos casos podemos agregar un link informativo u externo haciendo referencia al servicio en ejecution
define serviceextinfo{
host_name linux2
service_description Carga del sistema Linux
notes Carga sistema
notes_url http://localhost/cargalinux.pl?host=linux2&service=Carga+Sistema
icon_image carga.png
icon_image_alt Alertas de carga
}
define serviceextinfo{
host_name {nombre del host}
service_description {nombre descriptivo del servicio}
notes {nota descriptiva sobre la informacion extra}
notes_url {url donde se encuentra la informacion extra}
icon_image {imagen de icono}
icon_image_alt {texto alternativo de la imagen}
}
host_name
service_description
notes
notes_url
icon_image
icon_image_alt
define hostgroup {
hostgroup_name ramallo
alias Equipos de Ramallo
members ramallo,slnra01,srvrmlofs
}
define hostgroup {
hostgroup_name {nombre del grupo}
alias {alias descriptivo}
members {host miembros}
}
hostgroup_name
alias
members
Host que son miembros del grupo, debemos ingresar el host_name de cada uno separado por comas ”,”
Se deberá crear el archivo {nagios-dir}/etc/hostgroups/{nombregrupodehosts.cfg} con las entradas correspondientes anteriormente explicadas.
Agregando Hosts
Para configurar un host con o sin SNMP previamente instalado y configurado como lo indicado anteriormente, para su posterior monitoreo. Se debe crear una
entrada en la configuracion de Nagios.
define host{
use servidores
host_name servidorsap2
hostgroup_name servidores-linux
alias SAP SERVER
address 192.168.10.84
parents buenos_aires
contact_groups linux;
max_check_attempts 10
notification_interval 120
notification_period 24x7
notification_options d,u,r
}
define host{
use {template-host}
host_name {nombre-host}
hostgroup_name {grupos al que pertenece este host}
alias {alias-descriptivo}
address {ip}
parents {host del que depende}
contact_groups {grupo de contacto};
max_check_attempts {maxima cantidad de chequeos}
notification_interval {intervalo de tiempo entre notificaciones}
notification_period {priodo de tiempo de notificaciones}
notification_options {cuando enviar notificaciones}
}
use
host_name
hostgroup_name
address
parents
Host del que depende y que esta delante suyo, por ejemplo puede ser un router o un equipo que le brinde la conectividad etc, y en el mapa se dibujara como
dependiente de ese nodo
contact_groups
max_check_attempts
Maxima cantidad de chequeos a efectuar por Nagios, antes de enviar un OK como resultado
notification_interval
Esta directiva se utiliza para definir el número de las “unidades del tiempo” para esperar antes de re-notificar a un contacto que este servidor todavía está abajo
o inalcanzable. A menos que se haya cambiado la directiva interval_length del valor prefijado de 60, este número significará minutos. Si este valor se establece a
0, Nagios re-no notificará contactos sobre los problemas para este host - solamente una notificación del problema será enviada.
notification_period
notification_options
Esta directiva indica a Nagios en que momentos debe enviar notificaciones de estado
Se deberá crear el un subdirectorio correspondiente al nombre del host y segun corresponda ubicarlo en el directorio servers/{linux-windows-lotus} o routers y
deentro crear un archivo hosts.cfg con la configuración anteriormente explicada,
La informacion extendida de host se utiliza para el look and feel de los host dentro de los mapas de estado, ya sea tanto el 2D como el 3D
define hostextinfo{
host_name linuxoracle
notes Servidor Oracle de uniface
icon_image oracle.png
icon_image_alt Oracle
vrml_image oracle.png
statusmap_image oracle.gd2
}
define hostextinfo{
host_name {nombre de host}
notes {descripcion para el host}
icon_image {logo para ver en la interfaz web}
icon_image_alt {texto para el logo}
vrml_image {logo para ver en el mapa 3D}
statusmap_image {logo para ver en el mapa 2D}
}
host_name
notes
Pequeña nota descriptiva de la informacion del host a presentar en los mapas de estado
icon_image
icon_image_alt
vrml_image
statusmap_image
Icono a visualizar en el mapa 2D
Se deberá crear en el archivo hostextinfo.cfg dentro subdirectorio correspondiente al host con las entradas de configuración anteriormente explicadas. Lo iconos
se encuentran dentro del directorio {nagiosdir}share/images/logos/ tanto en su version png como gd
Para convertir una imagen png comun a un icono gd2 (necesario para la generacion del grafico de statusmap 2D) debemos ejecutar el siguiente comando:
El primer parametro es mi ya existente imagen png, el segundo parametro es el nombre de archivo de salida en formato gd2, el parametro 1 se refiere a que la
cree en formato raw (crudo), y el segudo parametro es para que lo cree sin compresion, todo esto se realiza dentro del directorio logos anteriormente explciado.
En casos donde hay host donde su estado depende del estado de otro host, es posible especificar dependencias. Aqui vemos una entrada tipica
define hostdependency{
host_name linuxsap2
dependent_host_name linuxoracle
notification_failure_criteria d
}
define hostdependency{
host_name {nombre del host a referise}
dependent_host_name {nombre del host del cual depende}
notification_failure_criteria {opciones de notificacion}
}
host_name
dependent_host_name
notification_failure_criteria
Se deberá crear en el archivo hostdependency.cfg dentro subdirectorio correspondiente al host con las entradas de configuración anteriormente explicadas.
A su ves las definiciones Timeperod pueden contener varios tipos de directivas, entre los días de semana, días del mes, y las fechas. El orden de precedencia de
los distintos tipos de directivas (en orden descendente) es el siguiente:
define timeperiod{
timeperiod_name 24x7
alias 24 Hours A Day, 7 Days A Week
sunday 00:00-24:00
monday 00:00-24:00
tuesday 00:00-24:00
wednesday 00:00-24:00
thursday 00:00-24:00
friday 00:00-24:00
saturday 00:00-24:00
}
define timeperiod{
timeperiod_name workhours
alias Normal Work Hours
monday 09:00-17:00
tuesday 09:00-17:00
wednesday 09:00-17:00
thursday 09:00-17:00
friday 09:00-17:00
}
define timeperiod{
name us-holidays
timeperiod_name us-holidays
alias U.S. Holidays
january 1 00:00-00:00 ; New Years
monday -1 may 00:00-00:00 ; Memorial Day (last Monday in May)
july 4 00:00-00:00 ; Independence Day
monday 1 september 00:00-00:00 ; Labor Day (first Monday in September)
thursday -1 november 00:00-00:00 ; Thanksgiving (last Thursday in November)
december 25 00:00-00:00 ; Christmas
}
Definimos un periodo de tiempo que chequee las 24 horas del dia los 7 dias de la semana, pero que incluya las excepciones anteriormente mostradas
define timeperiod{
timeperiod_name 24x7_sans_holidays
alias 24x7 Sans Holidays
use us-holidays ; Agregar excepciones
sunday 00:00-24:00
monday 00:00-24:00
tuesday 00:00-24:00
wednesday 00:00-24:00
thursday 00:00-24:00
friday 00:00-24:00
saturday 00:00-24:00
}
define timeperiod{
name weekdays
timeperiod_name weekdays
monday 00:00-24:00
tuesday 00:00-24:00
wednesday 00:00-24:00
thursday 00:00-24:00
friday 00:00-24:00
}
define timeperiod{
name weekends
timeperiod_name weekends
saturday 00:00-24:00
sunday 00:00-24:00
}
define timeperiod{
name holidays
timeperiod_name holidays
january 1 00:00-24:00 ; New Year's Day
2008-03-23 00:00-24:00 ; Easter (2008)
2009-04-12 00:00-24:00 ; Easter (2009)
monday -1 may 00:00-24:00 ; Memorial Day (Last Monday in May)
july 4 00:00-24:00 ; Independence Day
monday 1 september 00:00-24:00 ; Labor Day (1st Monday in September)
thursday 4 november 00:00-24:00 ; Thanksgiving (4th Thursday in November)
december 25 00:00-24:00 ; Christmas
december 31 17:00-24:00 ; New Year's Eve (5pm onwards)
}
Ahora definimos un timeperiod llamadas por ejemplo, incluya los dias de la semana, pero excluya los dias festivos
define timeperiod{
timeperiod_name llamadas
use weekdays ; Include weekdays
exclude holidays ; Exclude holiday dates/times defined elsewhere
}
Alternando dias, o sea desde el primero de agosto de 2007 cada dos dias notificar, si en vez de / 2 ponemos / 14 lo realizara cada 14 dias
define timeperiod{
timeperiod_name john-oncall
2007-08-01 / 2 00:00-24:00 ; Every two days, starting August 1st, 2007
}
En la entrada del contacto deberemos especificarle los timeperiods para hosts y servicios
define contact{
contact_name john
...
host_notification_period john-oncall
service_notification_period john-oncall
}
Programando plugins
Desarrollar plugins de chequeos para Nagios es extremadamente flexible, ya que no dependemos del lenguaje de programación debido a que Nagios toma la
salida resultante de su ejecución.
Deberemos conocer bien lo que queremos chequear y conocer los indicadores que nos mostraran si deberemos expresarlos como un OK, un WARNING o un
CRITICAL.
Luego deberemos reflejar esos estados en su código de retorno o Exit status, dependiendo del código del mismo Nagios entenderá que debe mostrar.
Exit Estado de
Estado de Host Descripcion
status Servicio
0 OK UP El plugin es capaz de verificar el servicio y que parece estar funcionando correctamente
El plugin es capaz de verificar el servicio, pero que parecía estar por encima de un umbral de “advertencia” o parece no estar funcionando
1 WARNING UP/DOWN/UNREACHABLE
correctamente
2 CRITICAL DOWN/UNREACHABLE El plugin detecta que o bien el servicio no funciona o que está por encima de un umbral “crítico”
Argumentos de línea de comandos no válida o fallas internas del plugin (por ejemplo error en un socket o dns) que le impiden realizar las
3 UNKNOWN DOWN/UNREACHABLE
operaciones especificadas
Deberemos copiar nuestro ejecutable (ya sea script o binario) al directorio /usr/local/nagios/libexec con permisos de ejecución.
Crearle una entrada dentro del archivo de configuración de Comandos.
Crear un Servicio y asignarle ese comando para que se encargue de dicho chequeo.
http://nagios.sourceforge.net/docs/3_0/pluginapi.html [http://nagios.sourceforge.net/docs/3_0/pluginapi.html]
http://nagiosplug.sourceforge.net/developer-guidelines.html [http://nagiosplug.sourceforge.net/developer-guidelines.html]
Dado el caso que queramos obtener información interna de determinado Host y necesitemos que este disponible para consultarla por SNMP, podemos incluir
dicha informacion. Para ellos deberemos incluir diferentes directivas de configuracion en el archivo snmpd.conf, y haremos uso de la tabla externa del objeto
UCD. La Tabla externa UCD es una tabla extensible de comandos de la cual obtendremos su código de resultado de ejecución y su salida.
/etc/snmp/snmpd.conf
Luego podemos ver los resultados obtenidos realizando una consulta SNMP a UCD-SNMP-MIB::extTable o .1.3.6.1.4.1.2021.8, obteniendo resultados similares a
:
UCD-SNMP-MIB::extIndex.1 = INTEGER: 1
UCD-SNMP-MIB::extIndex.2 = INTEGER: 2
UCD-SNMP-MIB::extIndex.3 = INTEGER: 3
UCD-SNMP-MIB::extIndex.4 = INTEGER: 4
UCD-SNMP-MIB::extNames.1 = STRING: comando1
UCD-SNMP-MIB::extNames.2 = STRING: comando2
UCD-SNMP-MIB::extNames.3 = STRING: comando3
UCD-SNMP-MIB::extNames.4 = STRING: comando4
UCD-SNMP-MIB::extCommand.1 = STRING: /bin/comando1
UCD-SNMP-MIB::extCommand.2 = STRING: /bin/comando2
UCD-SNMP-MIB::extCommand.3 = STRING: /bin/comando3
UCD-SNMP-MIB::extCommand.4 = STRING: /bin/comando4
UCD-SNMP-MIB::extResult.1 = INTEGER: 0
UCD-SNMP-MIB::extResult.2 = INTEGER: 0
UCD-SNMP-MIB::extResult.3 = INTEGER: 0
UCD-SNMP-MIB::extResult.4 = INTEGER: 0
UCD-SNMP-MIB::extOutput.1 = STRING: salida-comando
UCD-SNMP-MIB::extOutput.2 = STRING: salida-comando
UCD-SNMP-MIB::extOutput.3 = STRING: salida-comando
UCD-SNMP-MIB::extOutput.4 = STRING: salida-comando
UCD-SNMP-MIB::extErrFix.1 = INTEGER: 0
UCD-SNMP-MIB::extErrFix.2 = INTEGER: 0
UCD-SNMP-MIB::extErrFix.3 = INTEGER: 0
UCD-SNMP-MIB::extErrFix.4 = INTEGER: 0
UCD-SNMP-MIB::extErrFixCmd.1 = STRING:
UCD-SNMP-MIB::extErrFixCmd.2 = STRING:
UCD-SNMP-MIB::extErrFixCmd.3 = STRING:
UCD-SNMP-MIB::extErrFixCmd.4 = STRING:
Ramas SNMP :
UCD-SNMP-MIB::extNames
En esta rama obtendremos el nombre que le hemos asignado a dicho comando
UCD-SNMP-MIB::extCommand
Esta rama nos devolvera la ruta completa al ejecutable del comando
UCD-SNMP-MIB::extResult
Nos devolvera el resultado de la ejecucion del comando fue exitosa o no, devolviendonos su exit status
UCD-SNMP-MIB::extOutput
Aqui obtendremos la salida del comando con el string o expresion que necesitemos conocer
http://net-snmp.sourceforge.net/docs/mibs/ucdavis.html [http://net-snmp.sourceforge.net/docs/mibs/ucdavis.html]
#!/usr/local/bin/perl
use strict;
use warnings;
use Net::SNMP;
my $OID_sysUpTime = '1.3.6.1.2.1.1.3.0';
if (!defined $session) {
printf "ERROR: %s.\n", $error;
exit 1;
}
if (!defined $result) {
printf "ERROR: %s.\n", $session->error();
$session->close();
exit 1;
}
$session->close();
exit 0;
Ejemplo simple de como consultar una variable SNMPv3, igualmente se pueden consultar mas de una variable por sesion. En este caso estamos consultado la
variable extOutput.1 para ver la salida del primer comando.
#!/usr/bin/perl
use Net::SNMP;
$oid = ".1.3.6.1.4.1.2021.8.1.101.1";
Podemos realizar plugins que dependan de la salida de otros plugins sin necesidad de consultar o ejecutar nuevamente estos, uilizando los datos contenidos en la
base de datos MySQL
SELECT nagios_hosts.display_name
FROM
nagios_hostgroups,nagios_instances,
nagios_hosts,nagios_hostgroup_members,
nagios_objects
WHERE
nagios_hostgroups.hostgroup_id=nagios_hostgroup_members.hostgroup_id
AND
nagios_hostgroup_members.host_object_id=nagios_hosts.host_object_id
AND
nagios_hostgroups.hostgroup_object_id=nagios_objects.object_id
AND
nagios_objects.name1 = '{grupo_de_host_a_consultar}'
ORDER BY nagios_hosts.display_name ASC
SELECT
nagios_servicestatus.perfdata,nagios_servicestatus.output
FROM
nagios_services,nagios_servicestatus,
nagios_objects,nagios_instances
WHERE
nagios_services.instance_id=nagios_instances.instance_id
AND
nagios_servicestatus.service_object_id=nagios_services.service_object_id
AND
nagios_servicestatus.service_object_id=nagios_objects.object_id
AND
nagios_objects.name2 = '{servicio_a_consultar}'
AND
nagios_services.config_type='1'
AND
nagios_objects.name1 = '{host_que_lo_contiene}'
SELECT
nagios_hosts.display_name,
nagios_hosts.alias,
nagios_hoststatus.current_state,
nagios_hoststatus.output
FROM
nagios_hoststatus,
nagios_instances,
nagios_hosts,
nagios_objects
WHERE
nagios_hoststatus.host_object_id=nagios_objects.object_id
AND
nagios_hoststatus.host_object_id=nagios_hosts.host_object_id
AND
nagios_hosts.instance_id=nagios_instances.instance_id
AND
nagios_hosts.config_type='1'
AND
nagios_hosts.display_name = '{host_a_consultar}'
SELECT
obj2.name1 AS host_name,
obj2.name2 AS service_description
FROM nagios_servicegroups
INNER JOIN nagios_servicegroup_members ON
nagios_servicegroups.servicegroup_id=nagios_servicegroup_members.servicegroup_id
INNER JOIN nagios_services ON
nagios_servicegroup_members.service_object_id=nagios_services.service_object_id
INNER JOIN nagios_objects AS obj1 ON
nagios_servicegroups.servicegroup_object_id=obj1.object_id
INNER JOIN nagios_objects AS obj2 ON
nagios_servicegroup_members.service_object_id=obj2.object_id
INNER JOIN nagios_instances ON
nagios_servicegroups.instance_id=nagios_instances.instance_id
WHERE nagios_servicegroups.alias ='{alias_service_group}'
AND nagios_services.display_name ='{alias_de_servicio}'
SELECT nagios_hosts.display_name,nagios_hoststatus.current_state
FROM nagios_hoststatus,nagios_hosts
WHERE nagios_hoststatus.host_object_id = nagios_hosts.host_object_id;
display_name current_state
firewall 0
apache 1
servidor-sql 0
sap-db 0
Para conocer el estado de un servicio, independientemente de los hosts en los que se encuentre disponible
Consulta simple para obtener un pantallazo general del estado de servicios de un hostgroup
SELECT
CASE st.current_state
WHEN 0 THEN 'OK'
WHEN 1 THEN 'WARNING'
WHEN 2 THEN 'CRITICAL'
WHEN 3 THEN 'UNKNOWN'
END AS states,
COUNT(st.current_state) AS number
FROM nagios_hostgroup_members m, nagios_services s,
nagios_servicestatus st
WHERE m.host_object_id = s.host_object_id
AND s.service_object_id = st.service_object_id
AND hostgroup_id IN
(
SELECT hostgroup_id
FROM nagios_hostgroups hg, nagios_objects o
WHERE hg.hostgroup_object_id = o.object_id
AND o.name1 = '{nombre_hostgroup}'
)
GROUP BY st.current_state;
states number
OK 1754
WARNING 13
CRITICAL 84
UNKNOWN 20
Consulta simple para obtener un conteo general de los estados generales ordenados por meses de un año determinado.
SELECT
CONCAT('',DATE_FORMAT(nagios_statehistory.state_time,'%M')) AS TEMPS,
ELT(nagios_statehistory.state+1,'OK','WARNING','CRITICAL','UNKNOWN') AS ETAT,
CONCAT('',COUNT(nagios_statehistory.state)) AS QUANTITE
FROM
`nagios_statehistory`
LEFT JOIN nagios_objects AS obj1 ON nagios_statehistory.object_id=obj1.object_id
LEFT JOIN nagios_instances ON nagios_statehistory.instance_id=nagios_instances.instance_id
WHERE
obj1.objecttype_id='2'
AND nagios_statehistory.state_type = 1
AND DATE_FORMAT(nagios_statehistory.state_time,'%Y') = 2010
GROUP BY
TEMPS, ETAT
ORDER BY
DATE_FORMAT(nagios_statehistory.state_time,'%m'),nagios_statehistory.state
Nagios no guarda en ninguna tabla de MySQL el último estado de los objetos, pero guarda los cambios de estado en la tabla nagios_statehistory. Para mantener
el último estado se puede usar un trigger:
Ese trigger hace un update así que hay que cronear esto para mantener al día con los objetos la tabla.
Luego estas consultas podemos integrarlas en PHP o Perl, y obtener resultados que necesitemos para reflejarlos en un visor web, o en los resultados de un
plugin.
NOTA: Importante el modulo mysql de PHP no soporta la consulta a los PROCEDURE de MySQL, para ello deberemos utilizar el modulo mysqli de PHP, otra cosa
tambien importante es que mysqli soporta conecciones persistentes, asi que para evitarse tiempo de implementacion a veces es necesario o implementar un
script en Perl, o hacer que el resultado del PROCEDURE se almacene en una tabla temporal y realizar una consulta simple desde ahi.
Correlación de eventos
Si bien Nagios provee de monitoreo en vivo para saber el estado de nuestros servicios, a veces necesitamos un proceso para analizar los datos de eventos e
identificar patrones, que nos ayudaran a entender causas comunes y causas iniciales, por medios de reglas para estados predefinidos.
Para poder determinar estos casos deberemos implementar una Bitácora centralizada de eventos del sistema (SYSLOG).
Syslog es un estándar de facto para el envío de mensajes de registro en una red informática IP. Por syslog se conoce tanto al protocolo de red como a la
aplicación o biblioteca que envía los mensajes de registro.
Un mensaje de registro suele tener información sobre la seguridad del sistema, aunque puede contener cualquier información. Junto con cada mensaje se incluye
la fecha y hora del envío.
También es posible registrar el funcionamiento normal de los programas; por ejemplo, guardar cada acceso que se hace a un servidor web, aunque esto suele
estar separado del resto de alertas.
El protocolo syslog es muy sencillo: existe un ordenador servidor ejecutando el servidor de syslog, conocido como syslogd (demonio de syslog). El cliente envía
un pequeño mensaje de texto (de menos de 1024 bytes).
Los mensajes de syslog se suelen enviar vía UDP, por el puerto 514, en formato de texto plano. Algunas implementaciones del servidor, como syslog-ng,
permiten usar TCP en vez de UDP, y también ofrecen Stunnel para que los datos viajen cifrados mediante SSL/TLS.
Los logs de un sistema son una parte primaria de la seguridad y pueden ser usados en la detección de ataques e intrusiones, así como en el análisis de fallas de
hardware y software.
El programa syslog, es una interface que provee un framework standard para que tanto programas como el mismo sistema operativo puedan generar mensajes
que peuden ser almacenados localmente o ser enviados a un host remoto. Originalmente escrito para Unix, se convirtió en un standard que se usa en muchos
sistemas operativos y dispositivos de red.
En un sistema de syslog centralizado, un server común recibe todos los mensajes de syslog de todos los sistemas de la red. Esto incluye logs de los servers
Unix/linux/Windows etc, firewalls, y dispositivos de red (routers, switches, etc)
El syslog puede ser conectado en un segmento de red diferente protegido por un firewall
Teniendo los mensajes de todos los equipos, puede hacerse una correlación de ataques o
fallas en distintos puntos de una manera mucho más sencilla. Por ejemplo si en el syslog aparece un mensaje de desconexión de la interface de red de varios
servers en el mismo momento, es lógico suponer una falla en el switch donde estos servers estan conectados.
Un usuario no deseado que haya ingresado en un server, no podrá alterar los mensajes que
El análisis de logs es una herramienta muy importante para mantener el control de servers y dispositivos de red.
Sin embargo esta es una de las tareas que más tiempo consume y por consiguiente que menos se hace.
Con la cantidad de mensajes informativos que se generan en un sistema de log, detectar en forma manual los mensajes de problemas es muy dificultoso y con
mucha probabilidad de error. Esto se vé aumentado cuando se usa un sistema de syslog centralizado, donde la información proviene de varias fuentes distintas.
Muchas soluciones de monitoreo se basan en sumarizar la información de archivos de log de dias previos.
Esto es muy útil para la generación de estadísticas y análisis posterior a una falla o intrusión, pero no tanto para la resolución de problemas.
Muchas fallas o accesos no autorizados se ven precedidos por mensajes que de haber sido detectados, podrían haber permitido tomar acciones preventivas.
Por ejemplo, un acceso no autorizado via ssh, puede haber estado precedido por una gran cantidad de intentos fallidos de acceso.
Disponer una solución online de monitoreo, permite disponer de herramientas que pueden ayudar a prevenir problemas graves antes que ocurran.
Detectar eventos en el momento que ocurren permite generar acciones en ese mismo instante y no luego de las consecuencias.
Siguiendo con el ejemplo del acceso ssh, podría bloquearse el acceso ssh desde determinada dirección IP despues de un número de intentos fallidos de acceso.
Un concepto que aparece aquí es el de correlación de eventos.
Un sistema automatizado de análisis de logs que pueda hacer una correlación de varios eventos simplifica y acelera el monitoreo de eventos consolidando alertas
y mensajes de error en un mensaje más corto y fácil de entender.
Compresión toma varias apariciones del mismo evento y se examina la duplicación de información, se remueve las redundacias y se reporta como un único
evento. De esta manera 1000 mensajes “route failed” se convierte en un único alerta que dice “route failed 1000 times” Recuento reporta un número específico
de eventos similares como uno solo. Esto se diferencia de la compresión en que no solo cuenta en que sea el mismo evento, sino que se supere un determinado
umbral para generar un reporte.
Supresión asocia prioridades con alarmas y permite que el sistema suprima un alarma de prioridad más baja si ha ocurrido un evento de prioridad mayor.
Generalización asocia alarmas con eventos de más alto nivel que son los que son reportados.
Esto puede ser útil para por ejemplo para correlacionar eventos de múltiples discos de un array.
No se necesita ver cada mensaje específico si se puede determinar que el array completo tiene problemas.
Correlación basada en tiempo puede ser útil estableciendo causalidad. A menudo una información puede ser obtenida relacionando eventos que tienen una
relación temporal específica.
Ejemplos genéricos:
Objetivos
Simplificar y optimizar la administración de diferentes servicios para conocer su estado minuto a minuto, y elaborar planes de acción. A su vez el sistema debe
ser simple de utilizar por el administrador, y ser posible de ver via web los registros del sistema, realizar busquedas etc.
También es posible registrar el funcionamiento normal de los programas; por ejemplo, guardar cada acceso que se hace a un servidor web, aunque esto suele
estar separado del resto de alertas.
Puede logguear tanto por UDP como por TCP, teniendo compatibilidad con el viejo syslog, soportando a su vez muchas mas opciones y tareas que el syslog
comun.
Sobre Syslog-NG
Syslog-NG es un sistema para el envío de mensajes de registro en una red.
También es posible registrar el funcionamiento normal de los programas; por ejemplo, guardar cada acceso que se hace a un servidor web, aunque esto suele
estar separado del resto de alertas.
Puede logguear tanto por UDP como por TCP, teniendo compatibilidad con el viejo syslog, soportando a su vez muchas mas opciones y tareas que el syslog
comun.
Tareas
Se instalo el software syslog-ng dentro de un servidor Debian.
/etc/syslog-ng/syslog-ng.conf
Clientes
En los clientes se procedió a configurar el syslog convencional para que loggueara por UDP hacia el servidor syslog.
syslog-ng.conf
syslog-ng.conf
destination syslog_server {
tcp( "10.1.1.2" port(514) );
};
filter f_auth {
facility(auth, authpriv);
};
log {
source(src);
filter(f_auth);
destination(syslog_server);
};
log {
source(src);
filter(f_local6);
destination(syslog_server);
};
syslog.conf
syslog.conf
auth.*;authpriv.*;auth.notice;auth.error;auth.info;authpriv.none; @10.1.1.2
local6.* @10.1.1.2
/etc/profile.local
Esto es para logguear todos los comandos que ejecutan los usuarios, funciona aunque ejecuten un sudo o un su sin perder el rastro del usuario original, siempre
y cuando no modifiquen la variable de entorno.
export PROMPT_COMMAND='RETRN_VAL=$?;logger -p local6.debug "$(whoami) [$$]: $(history 1 | sed "s/^[ ]*[0-9]\+[ ]*//" ) [$RETRN_VAL]"'
Archivo /etc/syslog-ng/syslog-ng.conf
Opciones generales, fuentes de donde obtener información, filtros y destinos paracada filtro
options {
long_hostnames(off);
# doesn't actually help on Solaris, log(3) truncates at 1024 chars
log_msg_size(8192);
# buffer just a little for performance
# sync(1); <- Deprecated - use flush_lines() instead
flush_lines(1);
# memory is cheap, buffer messages unable to write (like to loghost)
log_fifo_size(16384);
# Hosts we don't want syslog from
#bad_hostname("^(ctld.|cmd|tmd|last)$");
# The time to wait before a dead connection is reestablished (seconds)
time_reopen(10);
#Use DNS so that our good names are used, not hostnames
use_dns(no);
dns_cache(yes);
#Use the whole DNS name
use_fqdn(no);
keep_hostname(no);
chain_hostnames(no);
#Read permission for everyone
perm(0644);
# The default action of syslog-ng 1.6.0 is to log a STATS line
# to the file every 10 minutes. That's pretty ugly after a while.
# Change it to every 12 hours so you get a nice daily update of
# # how many messages syslog-ng missed (0).
stats(43200000);
};
# Log Interno
source interno {
# message generated by Syslog-NG
internal();
# standard Linux log source (this is the default place for the syslog()
# function to send logs to)
unix-stream("/dev/log");
# messages from the kernel
file("/proc/kmsg" log_prefix("kernel: "));
};
destination d_eventdb {
pipe(
"/usr/local/nagios/var/rw/syslog-ng.pipe",
template("$HOST\t$SOURCEIP\t$PRI\t$YEAR-$MONTH-$DAY\t$HOUR:$MIN:$SEC\t$PROGRAM\t$MSG\n")
template_escape(no)
);
};
log {
source(externo);
destination(d_eventdb);
};
PHP-Syslog-ng
Para la visualizacion de los logs via web, busqueda y demas operaciones para su administracion se instalo, configuro y modifico a necesidad parte de codigo del
sofware php-syslog-ng que provee de una interfaz web con soporte de busquedas y que servia para cubrir la necesidad planteada.
Una vez instalado se configuro el apache para su puesta en marcha de la siguiente manera (se omitieron las directivas de autenticacion).
¿Que es Eventdb?
¿Cómo funciona?
El EventDB toma los eventos recibidos y los almacena en una base de datos MySQL. Se tomando los datos de syslog-ng desde un pequeño demonio perl (syslog-
ng2mysql.pl). syslog-ng2mysql.pl abre una unix-pipe por un lado desde donde recibe los mensajes de syslog-ng, y utiliza DBI en el otro para escribir datos en
MySQL.
Referencias
TIP´s varios
Sobre performance
http://en.gentoo-wiki.com/wiki/Safe_Cflags [http://en.gentoo-wiki.com/wiki/Safe_Cflags]
Nagios utiliza cada vez que necesita ejecutar un check dos forks en vez de uno, esto le trae entre otros beneficios el aislamiento del proceso hijo. Sin embargo la
utilización de CPU se incrementa necesariamente. Deshabilitando esta opción puede incrementarce la performance en instalaciones grandes.
child_processes_fork_twice=1
Configuración recomendada:
child_processes_fork_twice=0
Flap Detection
Flap detection es un mecanismo mediante el cual Nagios induce que un servicio esta cambiando de estado continuamente sin entrar en un régimen permanente.
El procedimiento del que se vale flap detection para detectar que un servicio o host esta en ese estado (“flapping”), es tomar los últimos 21 resultados de los
checks y verificar cuantos cambios de estado hay en los mismos. Analizando más en detalle, dentro de 21 resultados hay 20 posibles cambios de estado.
Suponiendo que dentro de estos 20 cambios de estado posibles, hubo 10 cambios de estado reales, la relación daría como resultado 10/20=0,50, es decir, 50%.
Mediante dos parámetros se configuran los umbrales para que el mecanismo considere que el servicio o host se encuentra en ese estado.
Es interesante entender que el concepto de “flapping” se puede asignar por servicio ya sea en el template utilizado o en la definición de un servicio en particular.
Igualmente es conveniente dejar la configuración general en su estado original y solo alterar la configuración particular del servicio que presenta problemas de
esta índole.
Otra consideración importante es que se pueden quitar estados a interpretarse como cambio de estado, por ejemplo el estado “UNKNOWN” podría considerarse
como que no hubo cambio respecto del estado anterior. Para ello hay que utilizar la directiva flap_detection_options dentro de la configuración del servicio o
host.
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
NDO
Cuando la base de datos esta cargada con una gran cantidad de registros, el NDO comienza a tener un comportamiento erratico, y los datos reflejados no son los
correctos, por lo tanto cada cierto tiempo hay que purgar algunas tablas, ese tiempo sera dependiendo de la cantidad de objetos a monitorear.
#!/bin/bash
echo "TRUNCATE TABLE nagios_servicechecks" | /usr/bin/mysql -u root --batch --database=nagios
echo "TRUNCATE TABLE nagios_logentries" | /usr/bin/mysql -u root --batch --database=nagios
echo "TRUNCATE TABLE nagios_service_contactgroups" | /usr/bin/mysql -u root --batch --database=nagios
echo "TRUNCATE TABLE nagios_hostchecks" | /usr/bin/mysql -u root --batch --database=nagios
Para luego incluirlo en el crontab, por ejemplo si tenemos alrededor de mas de 600 hosts y alrededor de 2000 servicios o mas, chequeando ambos en intervalos
de ente 1 y 5 minutos, podemos establecer su ejecucion en 15 minutos.
Igualmente en las opciones de configuracion del daemon ndo2db tenemos opciones referidas a esto, aunque igualmente dependeremos del script a realizar ya
que el NDO en si mismo puede fallar. La configuracion se refiere a valores en minutos.
Reparar tabla de NDO : En caso de que una tabla se corrompa, deberemos bajar el servicio NDO para que nagios no siga escribiendo registros y ejecutar la
siguiente orden desde el shell.
Para que cuando elegimos exportar los informes de disponibiliad en formato CSV, no nos aparesca en la ventana del navegador y en cambio nos abra un cuadro
de dialogo para elegir guardar o abrir con un programa externo, deberemos modificar los encabezados HTTP que imprime Nagios en dicho momento.
cgi/avail.c
if(output_format==HTML_OUTPUT)
printf("Content-type: text/html\r\n\r\n");
else{
printf("Content-type: plain/text\r\n\r\n");
return;
}
Lo cambiaremos como :
if(output_format==HTML_OUTPUT)
printf("Content-type: text/html\r\n\r\n");
else{
printf("Content-Disposition: attachment;filename=informe_mensual-nagios.csv
Content-type:application/csv\r\n\r\n");
return;
}
Scripts útiles
A continuacion se detallan scripts que pueden ser de utilidad para el dia a dia con Nagios
Volcado de estado actual : Haciendo uso de la clase StatusLog disponible en CPAN podemo parsear el contenido del archivo status.dat de Nagios, para luego
exportar su contenido
#!/usr/bin/perl
use Nagios::StatusLog;
my $log = Nagios::StatusLog->new(
Filename => "/dev/shm/status.dat",
Version => 3.0
);
print("Content-type: text/xml\n\n");
print("<?xml version='1.0'?>");
print("<status>\n");
foreach my $host ($log->list_hosts()) {
print("<host>\n<name>$host</name>\n<services>");
foreach my $serv ($log->list_services_on_host($host)) {
print ("<service>\n");
print (ref $serv);
my $st = $log->service($host, $serv);
foreach $tag ($st->list_tags()) {
print("<$tag>$$st{$tag}</$tag>\n");
}
print ("</service>\n");
}
print("</services>\n</host>\n")
}
print("</status>");
use Nagios::Report ;
my $x = Nagios::Report->new(q<local_cgi nagios_web_server nagios_user>, [ '24x7' ], 'thismonth')
or die "Can't construct Nagios::Report object." ;
my @these_fields = qw(
HOST_NAME
PERCENT_TOTAL_TIME_UP
) ;
$x->mkreport(
\@these_fields,
# All records
# sub { 1 },
# All records whose HOST_NAME starts with 'Alb'
# sub { my %F = @_; my $h = $F{HOST_NAME}; $h =~ /^Alb/ },
# Regrettably, this is _NOT_ the same since
# @_ can't be used as a hash.
# sub { $_{HOST_NAME} =~ /^Alb/ }
# All records with an up time percent < 98%
sub {
my %F = @_;
my $u = $F{PERCENT_TOTAL_TIME_UP};
$u =~ s/%//;
$u > 0
},
# Sort order
&comp( alpha => 0, ascend => 0, fields => [ qw(TOTAL_TIME_DOWN TOTAL_TIME_UNREACHABLE) ]),
# Sorts descending by max of TOTAL_TIME_DOWN and TOTAL_TIME_UNREACHABLE
# DIY sorters remember that $a and $b _must_ be in Nagios::Report package.
# eg by TOTAL_DOWN_TIME descending.
# sub { my %f = @_ ;
# package Nagios::Report;
# $b->[$f{TOTAL_TIME_DOWN}] <=> $a->[$f{TOTAL_TIME_DOWN}]
# },
# Same as
# &comp(alpha => 0, ascend => 0, fields => ['TOTAL_TIME_DOWN'])
# Same but harder,
# sub { package Nagios::Report; $b->[16] <=> $a->[16] },
# Optional callback to add or mangle fields.
# Add 2 fields for downtime vals in hours minutes and secs.
sub {
$F = shift @_;
$F->{PERCENT_TOTAL_TIME_UP} =~ s/%//;
$F->{TIME_UP_HHMMSS} = t2hms( $F->{TOTAL_TIME_UP} ),
$F->{TIME_DOWN_HHMMSS} = t2hms( $F->{TOTAL_TIME_DOWN} ),
$F->{TIME_UNREACH_HHMMSS} = t2hms( $F->{TOTAL_TIME_UNREACHABLE} ) ;
qw(TIME_UP_HHMMSS TIME_DOWN_HHMMSS TIME_UNREACH_HHMMSS)
}
) ;
$x->csv_dump ;
Volcado de variables de entorno de Nagios (esto es útil cuando programamos plugins que requiren variables de entorno y no sabemos como las tenemos que ver
o capturar) :
#!/usr/bin/perl -w
my $o_hoststate = $ENV{NAGIOS_HOSTSTATE};
# Nagios monitored host check output data
my $o_hostoutput = $ENV{NAGIOS_HOSTOUTPUT};
# Nagios date when the event was recorded
my $o_datetime = $ENV{NAGIOS_LONGDATETIME};
# The recipients defined in $CONTACTEMAIL$
my $o_to_recipients = $ENV{NAGIOS_CONTACTEMAIL};
use Data::Dumper::Concise;
print "<pre>";
print Dumper(%ENV);
print "</pre>";
Ejemplo de mk_livestatus
#!/usr/bin/python
#
# Sample program for accessing the Livestatus Module
# from a python program
socket_path = "/var/lib/nagios/rw/live"
import socket
s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
s.connect(socket_path)
print table
$data_address="unix:///usr/local/nagios/var/rw/live";
$query="GET services\nFilter: host_groups >= ServiciosGenerales\nColumns: host_name host_address display_name service_state plugin_output notes_url\nOutputFormat: json\n\n";
$fp = fsockopen($data_address,0);
if (!$fp) {
echo "$errstr ($errno)<br />\n";
} else {
$returnval = "";
fwrite($fp,$query);
while (!feof($fp)) {
$returnval = $returnval.fgets($fp, 128);
# print $returnval;
}
fclose($fp);
if ($returnval == "[] ")
$returnval = "";
}
print_r(json_decode($returnval,true));
Ejemplo de como obtener la lista de equipos y su estado desde php y exportarlo a formato CSV
$lista_servidores = shell_exec("/bin/echo -e \"GET hosts\nColumns: name address alias state\n\" | /usr/local/bin/unixcat /usr/local/nagios/var/rw/live");
$lista_hosts = str_getcsv($lista_servidores, "\n");
El lenguaje de consultas de Livestatus, basicamente consiste en consultas del tipo GET (case sensitive) con estos parámetros a los cuales consideraremos como
equivalente a tablas SQL :
NetMySLA
netMySLA es una variedad de procedimientos almacenados de MySQL. Se creó un procedimiento para calcular un único valor de disponibilidad de servicio. El otro
itera a través de todos los hosts y servicios para crear valores de disponibilidad de servicio y lo divide en plazos. Por lo tanto, usted puede calcular los valores
una vez al día y consulta la tabla de resultados para obtener sus datos.
https://www.nagiosforge.org/gf/project/netmysla/ [https://www.nagiosforge.org/gf/project/netmysla/]
Lista de argumentos
call np_checkAvailability('srv-web1', 'HTTP', true, true, true, true, NULL, '2008-01-11 00:00:00', '2009-07-01 00:00:00', false, false);
Ejemplo de como llamar al procedimiento desde PHP5, para por ejemplo conocer el SLA de x servicio en n cantidad de hosts.
foreach($hosts as $host) {
$query = $pdo->prepare("call np_checkAvailability('".$host['display_name']."', '".$service."', false, false, false, false, true, '".$start_time."', '".$end_time."', false, false)"
$query->execute();
print_r($query->fetch());
}
Array
(
[sla_id] => 1
[host_object_id] => 463
[host_name] => 001
[service_object_id] =>
[service_name] => Servicio
[outage_percent] => 0
[availability_percent] => 100
)
Tambien podemos utilizar el script np_aggregate.sh para ejecutarlo por medio de cron y tener autogenerados los informes, por cada hosts y cada servicios,
organizados diaria, semanal, mensual y anualmente.
Documentacion al vuelo
Para tener una documentacion actualizada de los equipos y sus servicios, lo ideal es implementar un wiki.
DokuWiki es un software para gestión de webs colaborativas de tipo wiki, escrito en lenguaje PHP y distribuido en códigon abierto bajo la licencia GPL.
Está enfocado para ser usado por grupos de desarrolladores, grupos de trabajo en general y pequeñas compañías.
Su sintaxis es similar a la de MediaWiki, aunque a diferencia de este software, la información se almacena en archivos de texto planos, por lo que no requiere el
uso de una base de datos.
Características:
Para integrarlo con Nagios podemos implementar un script en PHP como este :
<?php
/**
* Forwarder to doku.php
*
* @license GPL 2 (http://www.gnu.org/licenses/gpl.html)
* @author Joerg Linge <[email protected]>
*/
header("Location: doku.php?id=nagios:".$host.":".$srv);
exit;
} elseif($host!="") {
header("Location: doku.php?id=nagios:".$host.":host");
exit;
} else {
header("Location: doku.php?id=nagios:index");
exit;
}
?>
Ejemplo de un serviceextinfo, aunque tambien lo podemos aplicar dentro de la plantilla inicial del servicio.
define serviceextinfo {
host_name router
service_description ping
notes_url /wiki/nagios.php?host=$HOSTNAME$&srv=$SERVICEDESC$
icon_image help.png
}
Desde Dokuwiki haciendo uso de la extension PHP, podemos embeber los datos actuales de los objetos de Nagios, gracias a MK Live Status
<php>
$lista_servidores = shell_exec("/bin/echo -e \"GET hosts\nColumns: name address alias state\n\" | /usr/local/bin/unixcat /usr/local/nagios/var/rw/live");
$lista_hosts = str_getcsv($lista_servidores, "\n");
echo "<div class='level2'>
<div class='table sectionedit3'>
<table class='inline'>
<th>Host</th><th>IP</th><th>Descripcion</th><th>Estado Actual</th><th>Metricas / Informes</th>
";
echo "</table></div></div>";
</php>
Tambien desde dokuwiki por ejemplo si necesitamos podemos consultar comandos por SSH para mostrar su salida en la documentación de nuestro equipo, como
un plus de un dato en tiempo real.
<php>
if (!function_exists("ssh2_connect")) die("function ssh2_connect doesn't exist");
if(!($con = ssh2_connect("oracle", 22))){
echo "No puedo establecer una conexion SSH\n";
} else {
if (ssh2_auth_pubkey_file($con, 'root',
'/home/usuario/.ssh/id_rsa.pub',
'/home/usuario/.ssh/id_rsa', 'secret')) {
// echo "Public Key Authentication Successful\n";
} else {
die('Public Key Authentication Failed');
}
if (!($stream = ssh2_exec($con, "/home/usuario/dokuwiki_archlogs.pl" ))) {
echo "fail: unable to execute command\n";
} else {
// collect returning data from command
stream_set_blocking($stream, true);
$data = "";
while ($buf = fread($stream,4096)) {
$data .= $buf;
}
fclose($stream);
print $data;
}
}
</php>
dokuwiki_archlogs.pl
!/usr/bin/perl
use strict;
use warnings;
sub get_sorted_files {
my $path = shift;
opendir my($dir), $path or die "no puedo abrir $path: $!";
my %hash = map {$_ => (stat($_))[9] || undef} # saltar listas vacias
map { "$path$_" }
grep { m/.dbf/i }
readdir $dir;
closedir $dir;
return %hash;
}
my %files = get_sorted_files("/oracle/arclog/DBID/");
print "
<table class='inline'>
<th>Archivo</th><th>Timestamp</th>";
foreach my $key (sort{$files{$a} <=> $files{$b}} keys %files) {
my $filename = $key;
$filename =~ s/\.\///g;
$filename =~ s/\.\.//g;
print "<tr><td>$filename</td><td>", scalar localtime($files{$key}), "</td></tr>\n";
}
print "</table>";
Plugins interesantes
check_multiaddr
A menudo sucede que tenemos hosts a monitorear con multiples ip disponibles, y dado el caso por ejemplo que necesitemos chequear por cualquiera de las dos
IP para consultar disponibilidad, y que nuestro plugin intente por una o por otra con un timeout definido, para eso ya existe la solucion check_multiaddr, con la
cual no necesitamos realizar ninguna modificacion a el código existente de nuestros plugins, por ejemplo en la direccion ip del host a monitorear puede ir
192.168.0.1,192.168.0.11,192.168.0.21. Luego en la entrada de nuestro comando de chequeo realizamos modificaciones para que quede algo como esto :
define command{
command_name check_multiple_dns
command_line $USER1$/check_multiaddr.pl $USER1$/check_dns -H $ARG1$ -s $HOSTADDRESS$
}
Con lo cual el utilitario check_multiaddr actuara simplemente de envoltorio de nuestros plugins, encargandose del timeout entre cada consulta a cada direccion y
de devolver su salida con su exit status correspondiente.
check_multiaddr.pl.txt.gz
check_all_ips.pl.txt.gz
apache
/etc/apache2/conf.d/security
Ciertos parametros son útiles para evitar cierta exposición de nuestro Apache.
ServerTokens Prod
ServerSignature Off
TraceEnable Off
check_sap
Para que funcionen correctamente algunas cosas de los plugins de Nagios CCMS, hay que realizar algunas minimas modificaciones por ejemplo en : En el plugin
“Nagios SAP CCMS” hay que modificar algunas lineas de los archivos agnt_mon.h y sap_moni_ccm.h ya que en estos se establece el path de acceso a los
archivos de configuración que por defecto los busca en /etc/sapmon, pero nuestro objetivo es que los busque en /usr/local/nagios/etc/sapmon, de una cierta
manera quede mas centralizao u ordenado. Para mas información sobre SAP pueden ver el apartado aprendiendo SAP.
agnt_mon.h
[LOGIN_PRD]
LOGIN=-d PRD -u nagios -p password -c 300 -h 10.1.1.90 -s 00
[TEMPLATE_00]
DESCRIPTION="Load Average"
MONI_SET_NAME=SAP CCMS Admin Workplace
MONI_NAME="Operating System"
MAX_TREE_DEPTH=0
PATTERN_0="BCE\bcemain_BCE_26\CPU\5minLoadAverage"
PATTERN_0="*\*\CPU\5minLoadAverage"
[TEMPLATE_01]
MONI_SET_NAME=SAP CCMS Admin Workplace
MONI_NAME="Operating System"
MAX_TREE_DEPTH=0
PATTERN_2="BCE\bcemain_BCE_26\CPU\CPU_U*"
[TEMPLATE_02]
VALUE=DIALOG_RESPONSE_TIME
[TEMPLATE_03]
SYSTEM=BCE
APPL-SERVER=bcemain*
VALUE=DIALOG_RESPONSE_TIME
[TEMPLATE_04]
MONI_SET_NAME="SAP CCMS Monitor Templates"
MONI_NAME="Dialog Overview"
PATTERN_0="BCE\*\Dialog\FrontEndNetTime"
[TEMPLATE_05]
MONI_SET_NAME="SAP CCMS Monitor Templates"
MONI_NAME="Dialog Overview"
PATTERN_0="BCE\PWD*\Dialog\FrontEndNetTime"
[TEMPLATE_005]
MONI_SET_NAME="SAP CCMS Monitor Templates"
MONI_NAME="Dialog Overview"
PATTERN_0="P10\*\Dialog\FrontEndNetTime"
[TEMPLATE_06]
MONI_SET_NAME="SAP CCMS Monitor Templates"
MONI_NAME="Dialog Overview"
PATTERN_0="*"
[TEMPLATE_07]
MONI_SET_NAME="SAP CCMS Monitor Templates"
MONI_NAME="Availability and Performance Overview"
PATTERN_0="*\Availability\*_BCE*\"
[TEMPLATE_105]
MONI_SET_NAME="SAP CCMS Monitor Templates"
MONI_NAME="Dialog Overview"
PATTERN_0="*UsersLoggedIn"
[TEMPLATE_110]
MONI_SET_NAME="SAP CCMS Monitor Templates"
MONI_NAME="Entire System"
PATTERN_0="*EsAct"
[TEMPLATE_200]
MONI_SET_NAME="SAP CCMS Monitor Templates"
MONI_NAME="Database"
PATTERN_0="*Fullest tablespace"
[TEMPLATE_210]
MONI_SET_NAME="SAP CCMS Monitor Templates"
MONI_NAME="Entire System"
PATTERN_0="*DBRequestTime"
[TEMPLATE_300]
MONI_SET_NAME="SAP CCMS Monitor Templates"
MONI_NAME="Operating System"
PATTERN_0="*5minLoadAverage"
[TEMPLATE_999]
MONI_SET_NAME="SAP CCMS Monitor Templates"
MONI_NAME="Entire System"
PATTERN_0="*"
[TEMPLATE_060]
#DESCRIPTION="Free Swap"
MONI_SET_NAME=SAP CCMS Admin Workplace
MONI_NAME="Operating System"
#MAX_TREE_DEPTH=0
PATTERN_0="*\*\Swap_Space\Freespace"
[TEMPLATE_070]
DESCRIPTION=Dialog Response Time
MONI_SET_NAME=SAP CCMS Monitor Templates
MONI_NAME=Dialog Overview
PATTERN_0=P10\*\Dialog\ResponseTime
[TEMPLATE_071]
DESCRIPTION=Dialog Response Time
MONI_SET_NAME=SAP CCMS Monitor Templates
MONI_NAME=Dialog Overview
PATTERN_0=*
[TEMPLATE_09]
DESCRIPTION="DialogResponseTime"
MONI_SET_NAME=SAP CCMS Monitors for Optional Components
MONI_NAME="Logon Load Balancing"
MAX_TREE_DEPTH=0
PATTERN_0="*\*\Dialog\ResponseTime"
[TEMPLATE_007]
DESCRIPTION="TEST"
MONI_SET_NAME=SAP CCMS Monitors for Optional Components
MONI_NAME="Logon Load Balancing"
MAX_TREE_DEPTH=0
PATTERN_0="SAP\Server3_SAP_00\R3Services\Dialog\ResponseTime"
[TEMPLATE_900]
DESCRIPTION=Java
MONI_SET_NAME=SAP J2EE Monitor Templates
MONI_NAME=Heartbeat
PATTERN_0=*
[TEMPLATE_901]
DESCRIPTION=Java
MONI_SET_NAME=SAP J2EE Monitor Templates
MONI_NAME=Applications
PATTERN_0=*
[TEMPLATE_06]
DESCRIPTION=Users-Logged-On
MONI_SET_NAME="SAP CCMS Monitor Templates"
MONI_NAME="Dialog Overview"
MAX_TREE_DEPTH=0
PATTERN_0=SID\hostname*\Di*\Us*
[TEMPLATE_870]
DESCRIPTION=Java
MONI_SET_NAME=Test J2EE Monitor Set
MONI_NAME=J2EE Engine Kernel
PATTERN_0="XQ1\XQ1 64 Serv 649148450 mchp7tpa\System Threads Pool\MaximumThreadPoolSize"
[TEMPLATE_875]
DESCRIPTION=Java
MONI_SET_NAME=Test J2EE Monitor Set
MONI_NAME=J2EE Engine Kernel
PATTERN_0="XQ1\XQ1 64 Disp 649148400 mchp7tpa\General (MessageContext)\AverageMSProcessTime"
[TEMPLATE_666]
DESCRIPTION=SAP Avg. DB Request Time dehq0srm
MONI_SET_NAME=CENTRAL MONITORING SYSTEM (SAP Basis Kerpen)
MONI_NAME=Test Systems SAP
PATTERN_0=SID\hostname\Dialog\DBRequestTime
[TEMPLATE_667]
MONI_SET_NAME = "SAP CCMS Technical Expert Monitors"
MONI_NAME = "All Contexts on Local Application Server"
PATTERN_0 = "*"
[TEMPLATE_668]
MONI_SET_NAME = "SAP CCMS Technical Expert Monitors"
MONI_NAME = "All Contexts on Local Application Server"
PATTERN_0 = "*\SYSTEM\Free space"
[TEMPLATE_471]
MONI_SET_NAME = "SAP CCMS Technical Expert Monitors"
MONI_NAME = "All Contexts on Local Application Server"
PATTERN_0 = "*\PSAPSR3USR\Free space"
[TEMPLATE_785]
MONI_SET_NAME="SAP CCMS Monitor Templates"
MONI_NAME="Performance Overview"
PATTERN_0="SID\SID2_00\*EsAct"
[TEMPLATE_786]
MONI_SET_NAME="SAP CCMS Monitor Templates"
MONI_NAME="Performance Overview"
PATTERN_0="SID\SID1_00\*EsAct"
[TEMPLATE_666]
MONI_SET_NAME = "SID - Monitor"
MONI_NAME = "All Monitoring Contexts"
PATTERN_0 = "*"
[TEMPLATE_670]
MONI_SET_NAME="SID - Monitor"
MONI_NAME="All Monitoring Contexts"
PATTERN_0="SID\*\*Oracle messages*\ORA*"
Si queremos agregar en CCMS el monitoreo de X jobs debemos seguir esta guia
http://help.sap.com/saphelp_nw04/helpdata/en/1c/48803d48de0610e10000000a114084/content.htm
[http://help.sap.com/saphelp_nw04/helpdata/en/1c/48803d48de0610e10000000a114084/content.htm]
define command {
command_name check_sap
command_line $USER1$/ccms/check_sap $ARG1$ $_HOSTSAPID$
register 1
}
define command {
command_name check_sap_np
command_line $USER1$/ccms/check_sap_np.sh $ARG1$ $_HOSTSAPID$
register 1
}
Por ejemplo si la salida del chequeo en SAP nos arroja pipes |, para que no tengamos problemas con un falso perfdata, podemos apelar a este script :
check_sap_np.sh
#!/bin/bash
CMD=`/usr/local/nagios/libexec/ccms/check_sap $1 $2`
EXIT=$?
echo $CMD | /bin/sed -e 's/|/-/g'
exit $EXIT
Para poder hacer correctamente el chequeo deberemos defini la variable $_HOSTSAPID$ dentro de la configuración del host :
_SAPID PRD
jVectorMap
Con jVectorMap podemos dibujar mapas dinámicos vectoriales en AJAX, podemos hacer que por ejemplo al pasar el mouse por cada país por medio de datos
obtenidos de MKLiveStatus muestre el estado de hosts y servicios de cada región.
Ejemplo muy simple :
jQuery.noConflict();
jQuery(function(){
var $ = jQuery;
$('#map').vectorMap({
map: 'ar_mill_en',
hoverOpacity: 0.7,
hoverColor: false,
backgroundColor: 'transparent',
zoomButtons: false,
zoomOnScroll: false,
regionStyle: {
initial: {
fill: '#E1AF6C'
}
},
onRegionClick: function(event, code){
cargar_ajax('hostgroup_info.php?code='+code+'');
}
});
})
Interfaz administrativa
Anteriormente se vio de manera detallada las directivas de configuracion necesarias para el funcionamiento de un servicio Nagios, igualmente esta configuracion
se puede establecer por medio de una interfaz web, la misma es NagiosQL, es una aplicacion desarrollada en PHP.
Ademas si queremos soporte de idiomas deberemos asegurarmos que los locales de nuestro sistema tengan generado su enconding, ej. es_ES.utf8. Para ver los
enconding disponibles deberemos ejecutar “locale -a”.
Si realizamos la instalacion en un hosts con HTTPS, deberemos modificar el campo nagiosql.tbl_settings, de http a https.
Deberemos instalar NagiosQL donde residen los archivos HTML de Nagios, usualmente en /usr/local/nagios/share. Nuestra configuracion actual de Nagios debera
ser importada dentro de NagiosQL, para asi poder administrarla. Al realizar la importacion nos quedara una nomenclatura de directorios como esta
Por cada cambio que se realiza NagiosSQL hace una copia de seguridad de dicha configuracion.
Para comenzar con la instalacion deberemos crear un archivo dentro del directorio de nagiosQL touch nagiosql3/install/ENABLE_INSTALLER. Ahora podremos
comnezar la instalacion via web, una vez finalizada la instalacion deberemos eliminar el archivo creado rm -f nagiosql3/install/ENABLE_INSTALLER
Al ingresar a la ubicacion de NagiosQL nos aparecera una pantalla de login, en la cual deberemos indentificarnos con el usuario que creamos al momento de la
instalacion.
Una vez ingresados al sistema, nos aparecera un menu con enlaces de uso a la izquierda, con diferentes secciones
SubSección Hosts: Dentro de este apartado, tendremos un listado de los hosts presentes en la configuracion, indicando su estado si es activo o no, y a su vez
dandonos la posibilidad de modificarlos y personalizar su modo de chequeo, alarmas etc.
SubSección Servicios: Dentro de este apartado, tendremos un listado de los servicios asignados a sus correspondientes hosts, indicando su estado si es activo
o no, y a su vez dandonos la posibilidad de modificarlos.
SubSección Grupos de Hosts: Dentro de este apartado, tendremos un listado de los grupos de hosts, en donde queramos definir un conjunto de hosts que
tengan que ver entre sí por algún servicio o alguna función que cumplan.
SubSección Grupo de Servicios: Dentro de este apartado, tendremos un listado de los grupos de servicios, en donde queramos definir un conjunto de servicios
que tengan que ver entre sí por alguna dependencia o que cumplan funciones parecidas.
SubSección Plantillas de Hosts: Dentro de este apartado, tendremos las plantillas que utilizaremos para afectar a los hosts de manera común en lo que
respecta a intervalos de alarmas/notificaciones, modo de chequeo, contactos a quienes enviar datos, agrupación, servicios asignados, auto definido como una
forma centralizada de cambiar la configuración de determinado conjunto de hosts.
SubSección Plantillas de Servicios: Dentro de este apartado, similar al anterior tendremos las plantillas que utilizaremos para afectar a los servicios de
manera común en lo que respecta a intervalos de alarmas/notificaciones, modo de chequeo, contactos a quienes enviar datos, agrupación, hosts en cuales
ejecutarse, auto definido como una forma centralizada de cambiar la configuración de determinado conjunto de servicios.
SubSección Hosts
Al ingresar a este apartado de administración nos encontraremos con una pantalla similar a esta con la lista de hosts presentes en el sistema de monitoreo,
indicándonos cuales se encuentran activos y si su configuración se encuentra actualizada con respecto a la presente en el archivo de configuración.
El primer botón es para acceder a la información de configuración del host, con la correspondiente posibilidad de su posterior modificación.
El segundo botón es para copiar y así duplicar la configuración de dicho host, en caso de que tengamos un equipo con similares características al realizar esto
se nos hará mucho más fácil su implementación.
El tercer botón es para generar la escritura en la configuración de Nagios para dicho host en caso de que hayamos cambiado algo.
El cuarto botón es para descargados el archivo con la configuración individual de dicho equipo.
El quinto y último botón es para mostrarnos información de las relaciones de configuración de dicho equipo, si es posible borralo y no afectar otras
configuraciones mostrándonos un resumen como el siguiente:
Refiriéndonos al primer botón para proceder a editar un hosts existente o dar de alta uno nuevo, nos aparecera una pantalla como esta, donde podremos ir
agregando los datos pertinentes del hosts en cuestion que necesitamos monitorear.
Al editar un host existente o dar de alta uno nuevo, nos aparecera una pantalla como esta, donde podremos ir agregando los datos pertinentes del host en
cuestion que necesitamos monitorear.
A su vez deberemos utilizar una plantilla, en este caso la de generic-host o podemos utilizar otra con opciones y ajustes predefinidos para el tipo de monitoreo a
utilizar para esta clase de host (intervalos de chequeo, notificaciones, alarmas, dependencias, grupo de hosts).
Nombre del Host: Aquí definiremos el nombre real o de configuración para nosotros, sin espacios, comas, guiones ú otros caracteres que no correspondan.
Descripción: Mínimo dato descriptivo de que función cumple el hosts, ejemplo ‘smon0002lx – Servidor de monitoreo‘
Padres: Podremos definir una lista de hosts de los que depende la ruta de llegada hacia ese determinado host dentro de la topología de red.
Grupo de Hosts: Conjuntos a los cuales pertenece dicho hosts, igualmente si son muchos hosts de similares servicios que utilizan una misma plantilla, es mas
practico definir este dato en ella.
Comando de comprobación: Comando para ejecutar el chequeo de comprobación del hosts, igualmente si son muchos hosts de similares servicios que utilizan
una misma plantilla, es mas practico definir este dato en ella.
$ARG1$ - $ARG8$: Lista de argumentos ordenados uno a uno para pasarle al comando de comprobación de dicho host.
Plantillas: Plantillas de las cuales depende el host para obtener determinados datos de configuración, dichos datos contenidos en estas se pueden omitir en la
configuración del host ya que se desprenden de esta.
Opciones de comprobación del Host
Aqui podemos ver las opciones generales del hosts, intervalos de chequeo, reintentos, periodo de chequeos etc. Donde dice ‘saltar’ es por que se deja esa opción
a la determinada globalmente por la plantilla.
Estado inicial: Por defecto Nagios al iniciar asume que el host esta activo, pero esto no necesariamente puede ser así, entonces podemos definirlo como:
O = UP
D = DOWN
U = UNREACHABLE
Máximos intentos de comprobación: Máxima cantidad de intentos de comprobación antes de definir el estado final del host.
Comprobación pasiva: Es un chequeo ejecutado por aplicaciones externas y su resultado devuelto a Nagios para su procesamiento.
Periodo de comprobaciones: Son los lapsos de tiempo en los cuales se ejecutaran los chequeos de dicho host, por ejemplo las 24 horas del día los 7 días de la
semana o solo horas laborales de Lunes a Viernes.
Umbral de refresco: Se utiliza en la implementación de chequeos pasivos y en entornos distribuidos para poner énfasis sobre el refresco de los datos de
chequeo de un equipo.
Gestor de eventos: Comando a ejecutarse luego de obtenidos los resultados del chequeo del host.
Gesto de eventos activado: Aquí definiremos si utilizaremos o no un gestor de eventos luego de los chequeos.
Umbral bajo de oscilación: Aquí definimos el umbral mínimo para considerar una detección correcta del flapping de estado (cambios de estados muy
repentinos)
Umbral alto de oscilación: Aquí definimos el umbral máximo para considerar una detección correcta del flapping de estado (cambios de estados muy
repentinos)
Opciones de detección de estabilidad: Aquí definimos que estado consideramos para establecer el flapping de un host.
Mantener información de estado: En caso de que reinicie Nagios, mantener la última información de estadística obtenida del chequeo del host
Mantener el resto de la información: Mantener otra información útil sobre el host entre los reinicios de Nagios.
Datos sobre el rendimiento de los procesos: Procesar la información de performance de los chequeos, esto es útil ya que varios plugins de chequeo y otras
utilidades utilizan esta información para colección de datos.
Desde este apartado podremos estableces las opciones de cómo llegaran las notificaciones del estado del host a personal encargado de recibirlas.
Interfaz administrativa
NOTA PERSONAL: Desde hace un par de años no recomiendo usar NagiosQL, en su lugar recomiendo tener los archivos cfg, con la menor cantidad de líneas
posibles y siempre utilizar templates para todo.
Plugins
Plugins SNMP, caracteristicas generales
El sistema Nagios incorpora un gran número de comandos por default que se pueden utilizar. Algunos de ellos hacen uso de librerías y paquetes que deben estar
instalados en el sistema. En las siguientes líneas se comentan cuales son los comandos que vienen por default y que hacen.
check_by_ssh
Este comando es muy interesante interesante. Permite ejecutar comandos en ordenadores remotos vía SSH (de forma segura, por tanto). El resultado de ese
comando será tomado por Nagios.
-V, –version
-p, –port=INTEGER
Puerto a chequear
-4, –use-ipv4
Usar IPv4
-6, –use-ipv6
Usar IPv6
-1, –proto1
-2, –proto2
-S, –skip-stdout[=n]
-E, –skip-stderr[=n]
-f
Decirle al SSH que realize un fork en vez de una tty [optional]. Siempre devolver OK si ssh es ejecutado
-l, –logname=USERNAME
-i, –identity=KEYFILE
-O, –output=FILE
-s, –services=LIST
-n, –name=NAME
-o, –ssh-option=OPTION
llamar ssh con la opcion '-o' (puede ser usada multiples veces) [optional]
-q, –quiet
-w, –warning=DOUBLE
-c, –critical=DOUBLE
-t, –timeout=INTEGER
-v, –verbose
La forma mas comun de uso, es por medio de una llave ssh con el argumento '-i'. De este modo el par de llaves deben tener una contraseña nula y la llave
publica debe estar listada en el archivo authorized_keys del host remoto. Usualmente la llave debe estar restringida para correr solo un comando en el servidor
remoto. Si el script remoto permite la adicion de argumentos, puede actuar como una agente al estilo proxy para ejecutar otros comandos remotos.
define command {
command_name check_ssh_load
command_line $USER1$/check_by_ssh -H $HOSTADDRESS$ -C "/user/bin/check_load -w $ARG1$ -c $ARG2$"
}
define service {
use local-service
hostgroup_name ssh-nagios-services
service_description Current Load
check_command check_ssh_load!5.0,4.0,3.0!10.0,6.0,4.0
}
define hostgroup {
hostgroup_name ssh-nagios-services
alias Nagios over SSH
members remote1,remote2
}
check_dig
Este comando sirve para comprobar el funcionamiento del servicio de DNS en un equipo remoto. Utiliza dig para esto.
Usage:check_dig -l <query_address> [-H <host>] [-p <server port>] [-T <query type>] [-w <warning interval>] [-c <critical interval>] [-t <timeout>] [-a
<expected answer address>] [-v]
Ejemplos: Esto enviara una consulta TCP al servidor DNS consultando por el nombre www.example.com [http://www.example.com]
define command{
command_name check_dig
command_line $USER1$/check_dig -H '$HOSTADDRESS$' -l '$ARG1$'
}
define service{
use generic-service
host_name nombre_host
service_description dig
check_command check_dig!www.google.com
}
check_disk
Este comando sirve para comprobar el espacio libre de un volumen montado en el sistema de ficheros donde se esté ejecutando Nagios. Permite especificar dos
umbrales y generar disparadores advertencias cuando se supera el menor, y errores críticos cuando se supera el segundo.
Usage: check_disk -w limit -c limit [-W limit] [-K limit] {-p path | -x device} [-C] [-E] [-e] [-g group ] [-k] [-l] [-M] [-m] [-R path ] [-r path ] [-t timeout] [-u
unit] [-v] [-X type]
Checks /tmp and /var at 10% and 5%, and / at 100MB and 50MB
Checks all filesystems not matching -r at 100M and 50M. The fs matching the -r regex
are grouped which means the freespace thresholds are applied to all disks together
Checks /foo for 1000M/500M and /bar for 5/3%. All remaining volumes use 100M/50M
define command{
command_name check_all_disks
command_line $USER1$/check_disk -w '$ARG1$' -c '$ARG2$'
}
define service{
use generic-service
host_name nombre_host
service_description Disk Space
check_command check_all_disks!20%!10%
}
check_disk_smb
Planificación, especificación, diseño y evaluación de redes Este comando funciona exactamente igual que check_disk pero realiza la comprobación utilizando
samba para realizar la comprobación de volúmenes compartidos en quipos remotos, en redes Windows.
Perl Check SMB Disk plugin for Nagios
-H, –hostname=HOST
-s, –share=STRING
-W, –workgroup=STRING
-u, –user=STRING
-p, –password=STRING
-P, –port=INTEGER
Port to be used to connect to. Some Windows boxes use 139, others 445 (Defaults to smbclient default)
check_dns
Este comando permite hacer una consulta DNS para averiguar la dirección IP de un equipo dado el nombre o viceversa. Utiliza nslookup para ello; permite
especificar el servidor DNS a usar o si no usa el o los especificados en /etc/resolv.conf.
Usage:check_dns -H host [-s server] [-a expected-address] [-A] [-t timeout] [-w warn] [-c crit]
check_dummy
Este comando permite realizar una consulta a un dispositivo ficticio (devuelve el mismo parámetro que se le pasa). Puede ser utilizado para comprobaciones y
depuraciones.
check_flexlm
Este comando comprueba el funcionamiento de un sistema FlexLM. Este sistema es un servidor de licencias en red usado para obtener permisos de uso de
software en red. Devuelve distintos errores dependiendo del estado de estos servidores de licencias.
check_ftp
Este comando realiza comprobaciones de conexión a un servidor FTP remoto. Permite conocer el estado de este servicio.
This plugin tests FTP connections with the specified host (or unix socket).
Usage:check_ftp -H host -p port [-w <warning time>] [-c <critical time>] [-s <send string>] [-e <expect string>] [-q <quit string>][-m <maximum bytes>] [-
d <delay>] [-t <timeout seconds>] [-r <refuse state>] [-M <mismatch state>] [-v] [-4|-6] [-j] [-D <days to cert expiry>] [-S <use SSL>] [-E]
check_http
Este comando comprueba servicios HTTP y HTTPS en equipos remotos. Permite además realizar el seguimiento de redirecciones, tiempos de conexión, la
expiración de los certificados para SSL, etcétera. Es especialmente útil para servidores web que sirvan de base para aplicaciones de comercio electrónico.
When the 'www.verisign.com [http://www.verisign.com]' server returns its content within 5 seconds, a STATE_OK will be returned. When the server returns its
content but exceeds the 5-second threshold, a STATE_WARNING will be returned. When an error occurs, a STATE_CRITICAL will be returned.
CHECK CERTIFICATE: check_http -H www.verisign.com [http://www.verisign.com] -C 14
When the certificate of 'www.verisign.com [http://www.verisign.com]' is valid for more than 14 days, a STATE_OK is returned. When the certificate is still valid, but
for less than 14 days, a STATE_WARNING is returned. A STATE_CRITICAL will be returned when the certificate is expired.
#!/bin/sh
/usr/local/nagios/libexec/check_http -H $1 -p 50000 -u /irj/portal -A "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" -k "Accept-Language: es-ES" -s "Bienvenido"
check_ifoperstatus
Este comando comprueba el estado de operación de interfaces de red remotas por medio de SNMP v1 o SNMP v3.
check_ifstatus
Este comando comprueba el estado general de interfaces de red remotas por medio de SNMP v1 o SNMP v3.
check_imap
Este comando realiza conexiones contra un servidor IMAP para comprobar su estado de funcionamiento. Permite generar advertencias y errores críticos.
define command{
command_name check_imap
command_line $USER1$/check_imap -H '$HOSTADDRESS$'
}
define command {
command_name check_simap
command_line $USER!$/plugins/check_imap -p 993 -H '$HOSTADDRESS$' -S
}
define service{
use generic-service
host_name nombre_host
service_description imaps
check_command check_simap
}
check_ircd
Este comando comprueba el funcionamiento de un servidor de IRC remoto. Realiza conexiones para ello, esta escrito en Perl.
check_ldap
Este comando realiza conexiones y búsquedas LDAP contra un servidor remoto y comprueba así su estado de funcionamiento y si responde dentro del tiempo
esperado o no.
Usage: check_ldap -H <host> -b <base_dn> [-p <port>] [-a <attr>] [-D <binddn>]
Notes: If this plugin is called via 'check_ldaps', method 'STARTTLS' will be implied (using default port 389) unless –port=636 is specified. In that case 'SSL on
connect' will be used no matter how the plugin was called. This detection is deprecated, please use 'check_ldap' with the '–starttls' or '–ssl' flags to define the
behaviour explicitly instead.
check_load
Este comando trabaja en local en la máquina que está ejecutando el sistema Nagios. Comprueba la carga del sistema en función de unos umbrales que tiene
preestablecidos y permite generar advertencias o errores severos según sea esta carga.
-r, –percpu
define command{
command_name check_load
command_line $USER1$/check_load --warning=$ARG1$,$ARG2$,$ARG3$ --critical=$ARG4$,$ARG5$,$ARG6$
}
define service{
use generic-service
host_name nombre_host
service_description Current Load
check_command check_load!5.0!4.0!3.0!10.0!6.0!4.0
}
check_log
Este comando es muy interesante para administradores del sistema. Funciona en local y permite buscar coincidencia de patrones en ficheros de suceso. Cuando
el patrón que se busca es encontrado, Nagios recoge esta incidencia.
Usage: check_log -F logfile -O oldlog -q query Usage: check_log –help Usage: check_log –version
check_mailq
Este comando funciona en local en la máquina que corre Nagios. Permite comprobar el número de mensajes que hay en espera en las colas de Sendmail. Se
puede establecer un límite para que se genere una notificación en ese caso.
Usage: check_mailq -w <warn> -c <crit> [-W <warn>] [-C <crit>] [-M <MTA>] [-t <timeout>] [-v verbose]
Checks the number of messages in the mail queue (supports multiple sendmail queues, qmail)
Feedback/patches to support non-sendmail mailqueue welcome
check_mrtg
Este comando también trabaja en local en la máquina que está ejecutando Nagios y permite monitorizar los ficheros de sucesos de MRTG; en concreto permite
monitorizar cualquiera de los parámetros que se vuelcan sobre dichos ficheros como por ejemplo conexiones, carga del procesador, entrada, salida, etcétera.
Permite establecer umbrales que si se superan generan notificaciones.
This plugin will check either the average or maximum value of one of the two variables recorded in an MRTG log file.
Usage:check_mrtg -F log_file -a <AVG | MAX> -v variable -w warning -c critical [-l label] [-u units] [-e expire_minutes] [-t timeout] [-v]
check_mrtgtraf
Este comando permite comprobar el servicio UPS en un equipo remoto y establecer umbrales para, según el valor devuelto, disparar una advertencia, un error
severo o nada.
This plugin will check the incoming/outgoing transfer rates of a router, switch, etc recorded in an MRTG log. If the newest log entry is older than
<expire_minutes>, a WARNING status is returned. If either the incoming or outgoing rates exceed the <icl> or <ocl> thresholds (in Bytes/sec), a CRITICAL
status results. If either of the rates exceed the <iwl> or <owl> thresholds (in Bytes/sec), a WARNING status results.
Usage check_mrtgtraf -F <log_file> -a <AVG | MAX> -v <variable> -w <warning_pair>-c <critical_pair> [-e expire_minutes] [-t timeout] [-v]
-V, –version
-F, –filename=STRING
-e, –expires=INTEGER
-a, –aggregation=(AVG|MAX)
-w, –warning
-c, –critical
Notes: - MRTG stands for Multi Router Traffic Grapher. It can be downloaded from
http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html
- While MRTG can monitor things other than traffic rates, this
- The calculated i/o rates are a little off from what MRTG actually
reports. I'm not sure why this is right now, but will look into it
for future enhancements of this plugin.
check_nagios
Este comando se ejecuta en la máquina que está ejecutando Nagios y permite comprobar que el archivo de sucesos del sistema de monitorización no sea más
antiguo de lo que se especifique.
-V, –version
-F, –filename=FILE
-e, –expires=INTEGER
-C, –command=STRING
-v, –verbose
negate
Este comando sirve para, en combinación con cualquiera de los otros plugins, negar su valor. Por ejemplo, el uso normal del comando check_ftp es que devuelve
OK cuando el servicio esté funcionando y CRITICAL cuando no. Con este comando se invierten los valores. Es útil para cuando se desea tener notificación
explícita de que algo está funcionando bien en lugar de cuando falla.
check_nntp
Este comando establece conexiones NNTP contra un servidor remoto especificado para comprobar que el servicio de NEWS esté activo.
This plugin tests NNTP connections with the specified host (or unix socket).
Usage:check_nntp -H host -p port [-w <warning time>] [-c <critical time>] [-s <send string>] [-e <expect string>] [-q <quit string>][-m <maximum bytes>]
[-d <delay>] [-t <timeout seconds>] [-r <refuse state>] [-M <mismatch state>] [-v] [-4|-6] [-j] [-D <days to cert expiry>] [-S <use SSL>] [-E]
check_nt
Este comando realiza peticiones a un equipo Windows NT/2000/XP remoto que esté ejecutando el servicio NSClient para comprobar parámetros locales a dicho
equipo como por ejemplo uso de la CPU, de la memoria, del disco, etcétera.
check_ntp
Este comando ejecuta ntpdate para comprobar que el timestamp de la máquina local que ejecuta Nagios no difiere en más de lo especificado del timestamp de
una máquina remota dado.
check_nwstat
Planificación, especificación, diseño y evaluación de redes Este comando realiza peticiones a un equipo Novell remoto que esté ejecutando el servicio MRTGEXT
NLM para comprobar paráme tros locales a dicho equipo como por ejemplo uso de la CPU, de la memoria, del disco, etcétera.
check_oracle
Este comando permite comprobar el estado de un SGBD Oracle en un ordenador remoto así como el estado de los tablespaces, de bases de datos, de las caché,
etcétera, de dicho servidor.
check_overcr
Este comando permite comprobar el estado de un servicio Over-CR ejecutándose en un sistema UNIX remoto. Realiza peticiones a este servicio para comprobar
su estado.
check_pop
Este comando comprueba si el servicio POP de un equipo remoto está funcionando correctamente. Realiza peticiones para ello.
check_procs
Este comando funciona en la máquina donde se está ejecutando Nagios. Comprueba el número de procesos que se están ejecutando en la máquina y genera
advertencias cuando este número sobrepasa el umbral especificado.
check_real
Este comando comprueba si el servicio REAL de un equipo remoto está funcionando correctamente. Realiza peticiones para ello.
check_rpc
Este comando comprueba si un servicio RPC remoto está registrado y funcionando correctamente. Utiliza para ello llamadas a rpcinfo.
check_sensors
Este comando funciona en la máquina local donde se ejecuta Nagios; necesita de paquetes adicionales instalados en el sistema de monitorización y su función es
comprobar el estado del hardware de la máquina.
check_smtp
Este comando permite conocer el estado de un servicio SNMP de una máquina remota. Realiza conexiones a este servicio para averiguar la información
necesaria.
check_snmp
Este comando permite conocer el estado de una máquina remota mediante la consulta a su agente SNMP. Utiliza para ello el protocolo SNMP en cualquiera de sus
versiones 1, 2 ó 3.
check_ssh
Este comando permite controlar si el servicio SSH de una máquina remota está activo o no. Realiza peticiones a este servicio para obtener la información
necesaria.
check_swap
Este comando funciona en local, en la máquina donde está instalado Nagios. Permite monitorizar el tamaño de la memoria de intercambio utilizada y generar
advertencias o errores cuando este valor sobrepaso los umbrales establecidos.
check_tcp
Este comando permite realizar peticiones arbitrarias a conexiones (sockets) TCP contra sistemas remotos. Por tanto permite monitorizar cualquier servicio que
utilice sockets TCP para recibir peticiones.
define command{
command_name check_tcp
command_line $USER1$/check_tcp -H '$HOSTADDRESS$' -p $ARG1$
}
define service{
use generic-service
host_name nombre_host
service_description telnet
check_command check_tcp!23
}
check_time
Este comando permite comprobar si el servicio de hora (TIME) está funcionando en una máquina remota. Realiza conexiones a este servicio para obtener la
información.
check_udp
Este comando permite realizar peticiones arbitrarias a conexiones (sockets) UDP contra sistemas remotos. Por tanto permite monitorizar cualquier servicio que
utilice sockets UDP para recibir peticiones.
check_ups
Este comando permite monitorizar el estado del servicio UPS en máquinas remotas; para ello hace peticiones a este servicio. Necesita paquetes adicionales
instalados en el sistema de monitorización.
check_users
Este comando permite conocer el número de usuarios conectados actualmente en el sistema local, en el que se está ejecutando Nagios. Genera advertencias y
errores cuando el número supera el umbral fijado.
check_vsz
Este comando permite comprobar que el tamaño en memoria de un programa determinado no sea mayor de un límite fijado. Cuando se produzca el caso
contrario se generarán advertencias y/o errores.
urlize
Este comando permite, usando con otro comando, que la salida de este último se pueda mostrar en la pantalla de un navegador en formato HTML como un
enlace hipertexto navegable.
-V, –version
Examples: Pay close attention to quoting to ensure that the shell passes the expected data to the plugin. For example, in:
Importante Para que este comando funcione bien, deberemos tener configurado en el archivo cgi.cfg la siguiente directiva :
escape_html_tags=0
check_xml_url.sh
Esto lo necesite cuando tuve que XML de diferentes Webservices tengan la sintaxis correcta, para asi saber si habia una falla en los mismos.
check_xml_url.sh
#!/bin/bash
wget -q -O - --user-agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Firefox/21.0" $1 | xmlstarlet val - 1>/dev/null 2>/dev/null
EXIT_STATUS=$?
Ejemplo de configuración :
check_command check_xml_url!https://wsaa.afip.gov.ar/ws/services/LoginCms?wsdl
check_command check_xml_url!https://serviciosjava.afip.gob.ar/wsmtxca/services/MTXCAService?wsdl
check_xml_afip.php
En Argentina tenemos un servicio de Factura Electronica, si queremos verificar su status, deberemos consumir este WebService
https://serviciosjava.afip.gob.ar/wsmtxca/services/MTXCAService/dummy [https://serviciosjava.afip.gob.ar/wsmtxca/services/MTXCAService/dummy] , del cual
obtendremos esta respuesta que debemos parsear :
check_xml_afip.php
#!/usr/bin/php
<?php
/*
SimpleXMLElement Object
(
[appserver] => OK
[authserver] => OK
[dbserver] => OK
)
*/
$xml_cae_dummy = simplexml_load_file('https://serviciosjava.afip.gob.ar/wsmtxca/services/MTXCAService/dummy');
$appserver_status = $xml_cae_dummy->appserver;
$authserver_status = $xml_cae_dummy->authserver;
$dbserver_status = $xml_cae_dummy->dbserver;
check_nfe_status
En Brasil se utiliza la Nota Fiscal eletrônica, este plug esta en desarrollo. Por eso no lo publico, hay un desarrollo en java para realizar estos chequeo :
http://www.vivaolinux.com.br/dica/Plugin-NFe-2.00-Nagios [http://www.vivaolinux.com.br/dica/Plugin-NFe-2.00-Nagios]
check_heartbeat
Script simple para chequear el estado de HeartBeat y sus nodos, muy útil por cierto
check_heartbeat
#!/bin/bash
# Author: Emmanuel Bretelle
# Date: 12/03/2010
# Description: Retrieve Linux HA cluster status using cl_status
# Based on http://www.randombugs.com/linux/howto-monitor-linux-heartbeat-snmp.html
#
# Autor: Stanila Constantin Adrian
# Date: 20/03/2009
# Description: Check the number of active heartbeats
# http://www.randombugs.com
NODE_NAME=`uname -n`
CL_ST='/usr/bin/cl_status'
usage () {
echo "\
Nagios plugin to heartbeat.
Usage:
$PROGNAME
$PROGNAME [--help | -h]
$PROGNAME [--version | -v]
Options:
--help -l Print this help information
--version -v Print version of plugin
"
}
help () {
print_revision $PROGNAME $REVISION
echo; usage; echo; support
}
declare -i I=0
declare -i A=0
NODES=`$CL_ST listnodes`
if [ $A -eq 0 ]
then
echo "Heartbeat CRITICAL: $A/$I"
exit $CRITICAL
elif [ $A -ne $I ]
then
echo "Heartbeat WARNING: $A/$I"
exit $WARNING
else
echo "Heartbeat OK: $A/$I"
exit $OK
fi
</code>
<code>
define command {
command_name check_ha_by_ssh
command_line $USER1$/check_by_ssh -l root -H $HOSTADDRESS$ -C "/usr/local/sbin/check_heartbeat.sh"
}
check_systemimager
check_systemimager
#!/usr/bin/php -q
# Sergio Cayuqueo <[email protected]>
# http://cayu.com.ar
<?php
$lista_imagenes = shell_exec("si_lsimage --verbose|grep Image");
$lista_imagenes = preg_split("/[\n]+/",$lista_imagenes);
$fecha_actual = date('Y.m.d');
foreach($lista_imagenes as $imagen) {
if(strlen($imagen)>0) {
if(@!$i) {
$i=1;
}
$imagen = preg_split("/[\s]+/",$imagen);
$imagenes[$i]['nombre'] = $imagen[2];
$imagenes[$i]['actualizada'] = $imagen[4];
$imagenes[$i]['ip'] = $imagen[8];
if($imagen[4] == $fecha_actual) {
$imagenes[$i]['estado'] = "ok" ;
} else {
$imagenes[$i]['estado'] = "critical" ;
$critical=1;
}
$i++;
}
}
if(@$critical) {
$head = "CRITICAL - Hubo un desfasaje en una o mas imagenes\n";
$exit = 2;
} else {
$head = "OK - Todas las imagenes actualizadas a la fecha\n";
$exit = 0;
}
print $head;
foreach($imagenes as $imagen) {
if(strlen($imagen['nombre'])<9) {
$tab = "\t\t";
} else {
$tab = "\t";
}
if($imagen['estado'] == "ok") {
print "OK - ".$imagen['nombre']." ".$tab.$imagen['ip']."\n";
} else {
print "CRITICAL - ".$imagen['nombre']." ".$tab.$imagen['ip']." \t actualizado a : ".$imagen['actualizada']."\n";
}
}
exit($exit);
?>
define command {
command_name check_si_by_ssh
command_line $USER1$/check_by_ssh -l root -H $HOSTADDRESS$ -C "/usr/local/sbin/check_systemimager.php"
}
check_dba_2pc_pending
check_dba_2pc_pending
#!/usr/bin/perl
open(SQLPLUS_SELECT, "sqlplus -S \"/ as sysdba\" @/usr/local/bin/dba_2pc_pending_select.sql |") or die "No puedo ejecutar: $!";
while (<SQLPLUS_SELECT>) {
chomp($_);
if(length($_)>1) {
$select = $_;
}
}
close SQLPLUS_SELECT;
El script sql
SET pagesize 0
SET trimspool ON
SET headsep off
SELECT LOCAL_TRAN_ID FROM dba_2pc_pending;
exit;
check_microstrategy
define command {
command_name check_microstrategy
command_line $USER1$/check_microstrategy.sh $HOSTADDRESS$
register 1
}
define service {
service_description Servicio MicroStrategy
use generic-service
check_command check_microstrategy
max_check_attempts 1
check_interval 1
retry_interval 1
active_checks_enabled 1
check_period 24x7
notification_period 24x7
notification_options r,c
notifications_enabled 1
register 1
}
check_microstrategy.sh
check_microstrategy.sh
#!/bin/sh
SALIDA_SSH=`ssh $1 -l monitoreo "sudo /msis/var/opt/MicroStrategy/bin/mstrctl -s IntelligenceServer gs | grep state| sed 's/<[^>]*[>]//g' | sed 's/\t//g' | sed 's/\n//g'"`
if [ $SALIDA_SSH="running" ]
then
echo "OK - Proceso MicroStrategy corriendo"
exit 0;
else
echo "CRITICAL - Hay un problema con el proceso MicroStrategy"
fi
count_archlogs.pl
count_archlogs.pl
#!/usr/bin/perl
use strict;
use warnings;
my $ORACLE_SID=$ARGV[0];
sub get_sorted_files {
my $path = shift;
opendir my($dir), $path or die "no puedo abrir $path: $!";
my %hash = map {$_ => (stat($_))[9] || undef} # saltar listas vacias
map { "$path$_" }
grep { m/.dbf/i }
readdir $dir;
closedir $dir;
return %hash;
}
my %files = get_sorted_files("/oracle/arclog/".$ORACLE_SID."/");
my $count = keys %files;
select_count.sh
Si necesito alertar cuando crecen X registros en una tabla Oracle, en el dia de hoy se puede ejecutar esto :
echo -e "set head off\nset pagesize 0\nSELECT COUNT(DATA) FROM APPREG.DATA WHERE DATA = TO_DATE(SYSDATE,'DD/MM/YY');" | sqlplus -S "/ as sysdba" | awk '/^[ 0-9\.\t ]+$/ {print int($1)}'
bash select_count.sh
#!/bin/bash
# Chequear registros en Tabla y alertar al llegar al limite
CONTEO=`echo -e "set head off\nset pagesize 0\nSELECT COUNT(DATA) FROM APPREG.DATA WHERE DATA = TO_DATE(SYSDATE,'DD/MM/YY');" | sqlplus -S "/ as sysdba" | awk '/^[ 0-9\.\t ]+$/ {print int($
LIMITE=5
bash check_DATABASE_STATUS.sh
DATABASE_STATUS=`echo -e "set head off\nset pagesize 0\nSELECT status, database_status FROM v\\$instance;" | sqlplus -S "/ as sysdba"| cut -f1`
case "$DATABASE_STATUS" in
MOUNTED)
start
echo "CRITICAL - Los tablespaces de la base de datos estan $DATABASE_STATUS -" `date '+DATE: %m/%d/%y TIME:%H:%M:%S'`
exit 2;
;;
OPEN)
echo "OK - Los tablespaces de la base de datos estan $DATABASE_STATUS -" `date '+DATE: %m/%d/%y TIME:%H:%M:%S'`
exit 1;
;;
*)
echo "CRITICAL - Hay algun error con la base de datos $DATABASE_STATUS -" `date '+DATE: %m/%d/%y TIME:%H:%M:%S'`
exit 2;
esac
check_snmp_ifstatus_v3.pl
Version modificada por mi del script check_snmp_ifstatus.pl para que pueda consultar por medio de snmp v3
check_snmp_ifstatus_v3.tgz
check_oracle_tablespace.sh
Version modificada por mi del script check_oracle_tablespace.sh para no tener que usar oratab y conectarse con el sqlplus sin necesidad de tnsnames.ora,
ademas soporta perfdata para graficarla en pnp4nagios
Tengo que agregar una opción para agregarle a la linea de comandos que sea ignorar table space
check_oracle_tablespace.sh.gz
ssl-cert-check.sh
ssl-cert-check.sh -c Certificado.crt -n -x 60
ssl-cert-check.sh.gz
Notas importantes
Estos son los comandos que acompañan a Nagios y que deberan ser invocados cada uno con sus respectivos parámetros y su forma de ejecución. Para saber
más acerca de estos datos, necesarios para el uso de los comandos, se pueden invocar en línea de comandos con el parámetro –h lo que mostrará en la pantalla
una ventana de descripción del comando, los parámetros que usa y cómo se invoca. Recordar que los ejecutables de los comandos se encuentran dentro del
directorio libexec de la instalación de Nagios.
/etc/init.d/nagios
Directorio de Nagios
/usr/local/nagios
Sitios de consultas
Sitios de donde descargar plugins y agregados para Nagios
http://nagiosplug.sourceforge.net/ [http://nagiosplug.sourceforge.net/]
http://nagios.manubulon.com/ [http://nagios.manubulon.com/]
http://sourceforge.net/projects/nagios-sap-ccms/ [http://sourceforge.net/projects/nagios-sap-ccms/]
http://nagiosmobile.sourceforge.net/ [http://nagiosmobile.sourceforge.net/]
http://www.1ight.fr/plugins/BlackBerry/ [http://www.1ight.fr/plugins/BlackBerry/]
http://barbich.net/ [http://barbich.net/]
http://www.nagiosforge.org/ [http://www.nagiosforge.org/]
http://www.nagiosexchange.org [http://www.nagiosexchange.org]
https://addons.mozilla.org/en-US/firefox/addon/3607 [https://addons.mozilla.org/en-US/firefox/addon/3607]
http://code.google.com/p/nagioschecker/ [http://code.google.com/p/nagioschecker/]
http://sourceforge.net/projects/nagstamon [http://sourceforge.net/projects/nagstamon]
Sitios generales sobre funcionamiento de redes y protocolos
http://ariadna.ii.uam.es/wiki/wiki_rc2/doku.php [http://ariadna.ii.uam.es/wiki/wiki_rc2/doku.php]
http://www.monografias.com/trabajos95/recursos-red-y-su-monitoreo/recursos-red-y-su-monitoreo.shtml [http://www.monografias.com/trabajos95/recursos-red-y-
su-monitoreo/recursos-red-y-su-monitoreo.shtml]
TESIS Sistema de monitoreo y control de redes inalámbricas para optimización del servicio de Internet en la empresa Intercompu Ailaca Ramírez, Carlos Vinicio
http://repo.uta.edu.ec/handle/123456789/442 [http://repo.uta.edu.ec/handle/123456789/442]
http://repo.uta.edu.ec/bitstream/handle/123456789/442/Tesis_t655ec.pdf?sequence=1 [http://repo.uta.edu.ec/bitstream/handle/123456789/442/Tesis_t655ec.pdf?
sequence=1]
TESIS Implementación de NOC para el monitoreo de Servicios e Infraestructura de Redes para el Banco de Loja, basado en Software Libre, Solís Álvarez , Camilo
Javier
http://dspace.utpl.edu.ec/bitstream/123456789/9187/1/SOLIS%20ALVAREZ%20CAMILO%20JAVIER%2028-03-2014.pdf
[http://dspace.utpl.edu.ec/bitstream/123456789/9187/1/SOLIS%20ALVAREZ%20CAMILO%20JAVIER%2028-03-2014.pdf]
TESIS GESTIÓN Y MONITOREO DE UN LABORATORIO CON HERRAMIENTAS OPEN SOURCE, Ramos Galicia, Juan Christian
http://132.248.52.100:8080/xmlui/bitstream/handle/132.248.52.100/2815/Tesis.pdf?sequence=1
[http://132.248.52.100:8080/xmlui/bitstream/handle/132.248.52.100/2815/Tesis.pdf?sequence=1]
http://www.ptolomeo.unam.mx:8080/xmlui/handle/132.248.52.100/2815 [http://www.ptolomeo.unam.mx:8080/xmlui/handle/132.248.52.100/2815]
http://signa.googlecode.com/svn/trunk/entrega2/anexos/Anexo%20F%20-%20Descripci%C3%B3n%20de%20los%20Sistemas%20Finalistas.doc
[http://signa.googlecode.com/svn/trunk/entrega2/anexos/Anexo%20F%20-%20Descripci%C3%B3n%20de%20los%20Sistemas%20Finalistas.doc]
https://code.google.com/p/signa/ [https://code.google.com/p/signa/]
Notas
Inicio del documento Junio de 2007 y a lo largo del tiempo le fui agregando cosas que descubri a lo largo de mi trabajo
Este documento se puede utilizar libremente, lo único que pido es que citen la fuente si van a utilizarlo en obras derivadas
Si están leyendo este documento desde un pdf u odt, puede encontrar los archivos adjuntos en su fuente original
http://wiki.cayu.com.ar/doku.php?id=manuales:nagios [http://wiki.cayu.com.ar/doku.php?id=manuales:nagios]
Actualmente estoy trabajando por escribir una versión en Portugues (va algo lenta la traducción) y posiblemente comienze otra en Italiano :
http://wiki.cayu.com.ar/doku.php?id=manuales:nagios:portugues [http://wiki.cayu.com.ar/doku.php?id=manuales:nagios:portugues]
Este documento constituye una referencia para los administradores del sistema de monitoreo Nagios, y no tiene por objeto reemplazar a los manuales provistos
con el producto. Es sumamente recomendable efectuar lectura previa de dichos manuales para poder comprender los conceptos utilizados en este documento, así
como para realizar cualquier tarea de administración sobre el sistema.