LinuxParty

NUESTRO SITIO necesita la publicidad para costear hosting y el dominio. Por favor considera deshabilitar tu AdBlock en nuestro sitio. También puedes hacernos una donación entrando en linuxparty.es, en la columna de la derecha.

Ratio: 4 / 5

Inicio activadoInicio activadoInicio activadoInicio activadoInicio desactivado
 

Intentaremos explicar la configuración básica que permita comprobar el estado de hosts y servicios a través de nagios, así como comprobar recursos mediante agentes tanto en Windows como en Linux.

Definición de objetos

Nagios se configura mediante archivos de texto, los cuales deben tener la extensión .cfg. La configuración se basa en objetos, estos son los elementos involucrados en la logística de monitoreo y notificación.

Los objetos básicos son:

  • - comandos: definen qué programas ejecutar.
  • - servicios: son los recursos a testear (CPU, disco, protocolos de red, etc)
  • - hosts: definen los hosts que se van a monitorear.
  • - contactos: son las personas a las que se va a notificar cuando ocurre una alerta.
  • - tiemeperiods: definen en qué horarios se puede chequear un host y en qué horarios se puede notiticar a un contacto.

Estos objetos se pueden agrupar mediante los siguientes objetos:

  • - hostgroups: permiten agrupar hosts.
  • - servicegroups: agrupan servicios.
  • - contactgroups: agrupan contactos.

Como se puede observar en la sección de definición de objetos del manual de Nagios, cada objeto puede tener definidos varios atributos, aunque sólo unos pocos (sobre todo si utilizamos la herencia) son obligatorios. Los objetos se definen mediante la cláusula "define" y sus atributos se encierran entre llaves.

Los atributos que utilizaremos para cada tipo de objeto, y que les servirán para la gran mayoría de los casos, son los siguientes:

comandos:

  • - command_name: nombre del comando (por ej check_http)
  • - command_line: la línea de comando que se ejecutará para el chequeo (ejemplo: /usr/lib/nagios/plugins/check_http -I $HOSTADDRESS$ -p $ARG1$)

 

Como se puede observar en el ejemplo, existen variables predefinidas que se pueden utilizar como argumentos pasados al programa en la línea de comandos (Nagios las denomina macros). La lista completa de macros se encuentra aquí. En el ejemplo $HOSTADDRESS$ es la dirección del host que se está chequeando. También es posible utilizar variables cuyo valor será reemplazado cuando se llame el comando desde la definición de un servicio (o host), las cuales se denominan a partir de $ARG1$ hasta $ARGN$.

servicios:

- use: directiva que permite heredar atributos de servicios definidos previamente. Es posible definir un servicio base y luego extenderlo mediante esta directiva. En las definiciones de servicios, se suele heredar de "generic-service".

- service_description: una breve descripción del servicio.

- hostgroup_name/host_name: asigna el servicio a un grupo de hosts o a hosts específicos. No es mandatorio utilizar este parámetro, dado que se pueden asignar servicios a hosts desde la misma definición de los hosts. Es posible asignar más de un hostgroup o host separándolos con comas.

- check_command: el nombre del comando, previamente definido, que se utilizará para chequear el servicio. Algo a tener en cuenta es que cuando se llama al comando, los parámetros se pasan separados con signos de admiración. Estos luego se reemplazarán en $ARG1$... $ARGN$, según se definió en el comando.

Por ejemplo, en la definición de check_tcp encontramos que el comando ejecutado es el siguiente: /usr/lib/nagios/plugins/check_tcp -H $HOSTADDRESS$ -p '$ARG1$' -4

donde $ARG1$ se reemplazará por el puerto TCP que se desea chequear cuando se llame el comando. La forma de llamar el comando es la siguiente:

check_command check_tcp!50000 donde 50000 es el parámetro utilizado para el puerto.

NOTA: si no se hereda la definición de generic-service, deberán definirse otros atributos adicionales que son mandatorios (max_check_attempts, check_interval, retry_interval, check_period, notification_interval, notification_period, contacts, contact_groups).

hosts:

  • - use: al igual que en los servicios, esta directiva permite heredar los atributos de un host previamente definido. El caso más común es heredar la definición de "generic-host"
  • - host_name: es lo que el nombre indica, el hostname del host.
  • - address: dirección IP del host.
  • - alias: una breve descripción de la funcionalidad del host.
  • - hostgroups: listado de hostgroups a los que el host pertenece. Este atributo no es mandatorio, además es posible asignar los hosts a un hostgroup desde la misma definición del hostgroup.
  • - check_command: tiene la misma utilidad que cuando se define un servicio, con la diferencia que se utiliza para chequear si un host está online. Por defecto se utiliza ping (definido en generic-host) como chequeo, pero se puede reemplazar por otro si es que el host no admite pings.

NOTA: si no se hereda la definición de generic-host, deberán definirse otros atributos adicionales que son mandatorios (max_check_attempts, check_period, notification_interval, notification_period, contacts, contact_groups).

hostgroups:

  • - hostgroup_name: el nombre del hostgroup que estamos definiendo.
  • - alias: una breve descripción de la funcionalidad del hostgroup.
  • - members: listado de hosts, separados por coma, que pertenecen a este hostgroup. Este atributo es opcional.

contactos:

  • - contact_name: nombre del contacto.
  • - alias: un alias para el mismo.
  • - service_notification_period: indica en qué horarios se puede contactar en caso de caída de servicios.
  • - host_notification_period: indica en qué horarios se puede contactar en caso de caída del host.
  • - service_notification_options: listado de estados de servicio que deben reportarse. Los estados se definen con letras y se separan con comas: u (UNKNOWN), c (CRITICAL), r (RECOVERY - OK), f (FLAPPING), y n (NONE).
  • - host_notification_options: listado de estados de host que deben reportarse. También se definen con letras separadas por coma: d (DOWN), u (UNREACHABLE), r (RECOVERY - UP), f (FLAPPING), s (comienza el downtime programado), n (NONE).
  • - service_notification_commands: cómo notificar al contacto en caso de servicio caído (email, sms, etc).
  • host_notification_commands: cómo notificar al contacto en caso de host caído (email, sms, etc).
  • - email: dirección de email del contacto.
  • - contactgroups: grupo al que pertenece el contacto.

Agentes Nagios

Una gran parte del monitoreo se puede hacer remotamente. Todo servicio publicado en la red, se puede monitorear sin necesidad de instalar nada en el host monitoreado. Sin embargo hay recursos que no se pueden monitorear remotamente, como por ejemplo:

  • - espacio libre en disco
  • - memoria en uso
  • - carga de CPU
  • - servicios activos
  • - cantidad de usuarios logueados

Para ello es necesario instalar agentes. Estos agentes, mediante plugins, chequean el estado de los recursos y envían los datos al servidor Nagios. El tipo de conexión es pull, es decir, el servidor Nagios contacta cada cierto intervalo de tiempo a los agentes, les indica qué comandos ejecutar y obtiene los resultados.

Existen varios protocolos utilizados para la comunicación entre agentes y Nagios:

- NRPE - Nagios Remote plugin Executor. Es el protocolo más utilizado y recomendado por Nagios. Se accede mediante el plugin check_nrpe.

- NSCA - Nagios Service Check Acceptor.

- NSCP: protocolo nativo de NSClient++

- NRDP: reemplazo NSCA.

- Syslog: protocolo estándar para transmisión de logs en Unix.

- SNMP: Simple Network Management Protocol. Protocolo estándar para administración y monitoreo de dispositivos de red.

En este artículo se utilizará el protocolo NRPE, para lo cual se instalarán agentes en Linux y Windows que lo soporten.

Instalación del servidor

Instalar el servidor de Nagios es muy simple, está en los repositorios de la mayoría de las distribuciones.

Por ejemplo, en debian, basta con ejecutar:

# apt-get install nagios3 nagios-nrpe-plugin

La instalación en debian solicita que se introduzca una clave de administración web (usuario nagiosadmin). Pueden elegir no ingresar clave, e ingresarla después. Lo más cómodo es asignarla en esta instancia, aunque queda a elección. La autenticación de la interfaz web la realiza Apache, así que agregar o quitar usuarios se puede realizar con la utilidad htpasswd. También instalamos aquí los plugins para comunicarnos con los agentes mediante NRPE (ver más adelante).

El servicio de Nagios se ejecutará, por defecto, a nombre del usuario nagios y grupo nagios. Esto es para limitar los privilegios, dado que el sistema no necesita permisos de root para ejecutarse, y sería muy riesgoso.

Si utilizan debian, otros datos interesantes acerca de la instalación son:

- Los plugins default de Nagios (paquete nagios-plugins) se instalan en /usr/lib/nagios/plugins

- Los comandos (ver más adelante que son) default están definidos en /etc/nagios-plugins/config

- Por defecto, nagios carga toda la configuración incluida en /etc/nagios3/conf.d, así que lo más conveniente es incluir los archivos con las definiciones de hosts, servicios, comandos, etc, allí.

- El archivo de configuración de apache para la interfaz web de Nagios se encuentra en /etc/apache2/conf.d/nagios3.conf

- Por defecto la interfaz web se accede mediante la URL http:///nagios3. Este alias se puede cambiar en el archivo citado en el punto anterior.

- El archivo de autenticación para la interfaz se encuentra en /etc/nagios3/htpasswd.users

 


Sigue aquí: Explicación de los componentes de configuración de Nagios (2)


 

No estás registrado para postear comentarios



Redes:



   

 

Suscribete / Newsletter

Suscribete a nuestras Newsletter y periódicamente recibirás un resumen de las noticias publicadas.

Donar a LinuxParty

Probablemente te niegues, pero.. ¿Podrías ayudarnos con una donación?


Tutorial de Linux

Filtro por Categorías