Configurando el gestor Nagios

En los posts anteriores (aquí y aquí) abordé cómo configurar los elementos que van a monitorizarse en la red para permitir su gestión desde el servidor Nagios. En este post voy a abordar la configuración de Nagios.

Nagios, de acuerdo a la instalación que tengo, mantiene la información de configuración en el directorio /usr/local/nagios/etc. Bajo este directorio y los subdirectorios correspondientes se encuentran una serie de ficheros de configuración.

El primer paso es traerse toda esta información de configuración al PC para poder editar los ficheros de forma más amigable (aunque vi/vim es un gran editor, prefiero hacerlo con UltraEdit). Después de los líos con la creación de una imagen y su montaje que tuve para transferir archivos desde el PC a una máquina virtual, descubrí que la forma más fácil de mover ficheros es a través de un pincho USB. Lo único que hay que hacer es añadir a las máquinas virtuales un controlador USB y, cuando se monta el controlador reconoce los dispositivos pinchados en el PC que ejecuta el vClient.

Reflexionando sobre el manejo de la cantidad de ficheros de configuración involucrados en el lab, se me ocurre que, probablemente sea una buena idea montar un control de versiones (por ejemplo, svn) para mantener gestionadas todas estas configuraciones (le echaré una pensada a lo largo de la semana).

Volviendo al tajo tras la digresión, lo que voy a hacer es organizar los elementos de configuración en una serie de subdirectorios, en la actualidad, lo que hay es un subdirectorio ‘objects’ con distintos objetos de configuración y uno ‘servers’ con los ficheros de configuración de los distintos hosts de la red. En el directorio raíz se encuentran los ficheros de configuración generales de Nagios. Mi plan es organizar la configuración de la siguiente forma:

  • En el directorio raíz los ficheros de configuración generales: nagios.cfg, resource.cfg, cgi.cfg, nrpe.cfg y htpasswd.users.
  • Subdirectorio commands. Ficheros .cfg de los distintos comandos.
  • Subdirectorio contactgroups. Ficheros .cfg de los contact groups.
  • Subdirectorio contacts. Ficheros .cfg de los contactos.
  • Subdirectorio hostgroups. Ficheros .cfg de los grupos de hosts.
  • Subdirectorio hosts. Ficheros .cfg de los distintos hosts existentes en el lab.
  • Subdirectorio services. Ficheros .cfg de los distintos servicios.
  • Subdirectorio servicegroups. Ficheros de .cfg correspondientes a los grupos de servicios.
  • Subdirectorio timeperiods. Ficheros .cfg con la configuración de períodos de tiempo.

Para que surja efecto es necesario que, en el fichero de configuración general de nagios (nagios.cfg), se establezca que estos directorios deberán ser contemplados en la carga de la configuración:

nag_cfg9

Una vez completada esta labor, lo que queda es pasarla al servidor nagios y probar la configuración. Empleando el pincho usb la transferencia de la configuración es coser y cantar y tras unas mínimas correcciones consigo que la configuración sea correcta:

nag_cfg10

Re-arranco Nagios y me conecto a la interfaz web desde una máquina virtual Lubuntu conectada a la red de gestión.

nag_cfg11

Se ve que los tres hosts de mi red están levantados pero tengo cuatro problemas críticos:

nag_cfg12

Los cuatro problemas críticos tienen que ver con el router vyos, uno de ellos es el servicio SSH que no estará levantado y los otros tres están relacionados con SNMP. Voy a investigar qué pasa.

Al editar la definición del servicio Uptime me doy cuenta enseguida del error. La community del comando check_snmp está puesta a public y en el setup de SNMP del router VyOS la community que establecí es mylab. Un pequeño cambio en la configuración de los servicios basados en SNMP y este problema debería quedar arreglado:

nag_cfg13

nag_cfg14

En el caso del SSH, voy a levantar el servicio SSH en el router vyos:

nag_cfg15

Ya sólo queda comprobar la configuración de Nagios, re-arrancar el servicio y ver qué pasa:

nag_cfg16

A priori, todo pinta bien, veamos cómo está el router VyOS:

nag_cfg17

Todo verde, tarea completada (por ahora) queda por definir qué voy a monitorizar del router, pero eso ya será en otro lugar.

Anuncios

Monitorizando la red virtual (II)

En el post precedente abordé la configuración del servidor NRPE desplegado en mi servidor de syslog (ubsyslog) para poder ser monitorizado desde Nagios. En esta segunda parte, abordaré la configuración del router VyOS para poder ser monitorizado desde Nagios.

A diferencia del caso del servidor, la monitorización del router la voy a realizar empleando SNMP. Para ello, lo primero que tengo que hacer, es configurar el agente SNMP en el router VyOS.

nag_cfg6

Una vez configurado, comprobamos que desde el servidor Nagios podemos acceder a la información del agente SNMP mediante el comando snmpget:

nag_cfg7

En principio esto está funcionando queda decidir qué objetos vamos a monitorizar desde el servidor Nagios.

Monitorizando la red virtual (I)

Una vez instalado Nagios en el servidor designado para ello, el siguiente paso en el camino es monitorizar el resto de los elementos. Ahora mismo, mi red está así:

Dibujo3

Los elementos a monitorizar (por ahora) son, además del propio servidor Nagios, el servidor de Syslog y el router Vyos. Lo que hay que hacer es configurar el servidor Nagios para poder realizar la monitorización. No tengo mucha idea de cómo va esto pero, a priori, el secreto consiste en atacar el router VyOS a través de SNMP y los servidores a través del plugin NRPE.

En este post voy a cubrir la configuración del servidor NRPE en el servidor de syslog.

Para poder monitorizar el servidor de syslog, lo que hay que hacer, en primer lugar, es instalar NRPE y los plugin de Nagios:

add@ubsyslog~$ sudo apt-get update 
add@ubsyslog~$ sudo apt-get install nagios-plugins nagios-nrpe-server

El siguiente paso es editar el fichero de configuración del servidor NRPE. Este fichero es /etc/nagios/nrpe.cfg. En este fichero, establecemos el host desde donde se van a lanzar los comandos de monitorización (servidor ubnagios):

nag_cfg1

y las directivas include para estructurar el contenido de la configuración:

nag_cfg2

Dentro del directorio nrpe.d voy a crear un fichero de configuración (cmds.cfg) que contiene los comandos que van a utilizarse para monitorizar el servidor remoto.

En el caso del servidor ubsyslog, lo que, inicialmente, voy a monitorizar es:

  • Que el servidor esté vivo. Esto se lleva a cabo lanzando un ping desde el servidor de monitorización por lo que, en local, no hay que hacer nada.
  • El número de usuarios conectados al servidor. Para ello empleamos el plugin nrpe check_users estableciendo un nivel de warning a 5 y el nivel crítico a 10.
  • La carga del servidor. Se monitoriza mediante el comando check_load de forma que eleve un aviso si los niveles de carga (de acuerdo a la salida del comando uptime) superan 5,10 y 15 y lanza un nivel crítico cuando estos niveles superan los valores 30, 25 y 20.
  • La ocupación del disco duro del servidor (sistema de ficheros ‘/’), empleando el comando check_disk. El comando emitirá un warning cuando el espacio libre en el disco duro baje del 20% y un aviso crítico cuando el espacio libre esté por debajo del 10%. Es importante saber cuál es el dispositivo en el que se monta el sistema raíz que, en el caso del servidor ubsyslog, es /dev/dm-0 (obtenido mediante el comando ‘df –h /’).
  • El número total de procesos. Para esto, se utiliza el comando check_total_procs, estableciendo un nivel de warning en 150 y el nivel crítico en 200.
  • El espacio de swap libre. Para obtener este valor empleamos el comando check_swap estableciendo el nivel de warning al 20% y el nivel crítico al 10%.
  • El espacio utilizado por los logs (directorio /var/log). Para obtener esto empleamos el comando check_folder_size estableciendo los niveles de warning y crítico respectivamente a 5GB y 6GB (el disco duro total inicial es de 10GB).

El fichero cmds.cfg queda de la siguiente forma:

nag_cfg3

Antes de continuar voy a hacer un breve inciso sobre cómo configurar el comando check_folder_size.sh (yo lo renombré a check_folder_size2.sh) ya que el conseguir que funcione supuso un esfuerzo considerable.

El shell script check_folder_size.sh lo descargué al PC donde ejecuto el vSphere client desde el sitio de internet de Nagios Exchange. Una vez en el PC, surgió el problema de cómo llevarlo a la máquina virtual, la solución que empleé, fue crear una imagen ISO, subirla a vSphere y montarla en la unidad de CD de la máquina virtual. Aquí explican más o menos el mecanismo.

A continuación, tuve un pequeño problema con los permisos. Tuve que cambiar el usuario y los permisos del fichero:

add@ubsyslog:/usr/lib/nagios/plugins$ sudo chown nagios:nagios check_folder_size2.sh
add@ubsyslog:/usr/lib/nagios/plugins$ sudo chmod 755 check_folder_size2.sh

Una vez completado todo esto, conseguí que el comando funcionara en local. Ahora llega la hora de probar que todos los comandos funcionan en remoto desde el servidor de nagios (ubnagios) utilizando el comando check_nrpe:

nag_cfg5

Todo funciona OK y esto me va a servir de plantilla para siguientes configuraciones.

Probando la nueva red

Como he contado aquí y aquí, he reconfigurado la red del entorno lab para que sea más eficiente. Ahora llegó el momento de probar los cambios realizados y que todo funciona de acuerdo a lo esperado.

Para probar la conectividad con la DMZ voy a conectar a la misma una máquina virtual Lubuntu con dirección IP 192.168.2.130:

red20

1. Conectividad desde el PC conectado a la red lab

red18

red19

red21

red22

2. Conectividad desde el PC conectado a la WiFi doméstica

Para esto desactivo la conexión ethernet y activo la conexión WiFi.

red27

red28

red29

3. Conectividad desde la DMZ

red23

red24

red25

red26

Parece que todo funciona correctamente.

Replanteando la red (II)

En esta segunda parte voy a concretar los pasos seguidos para reconfigurar la red en el sentido anticipado en el post anterior. En principio, los elementos que tengo que tocar son:

  • El router de acceso a Internet
  • El router con OpenWRT
  • El PC de sobremesa
  • El servidor ESXi
  • Las redes virtuales del lab.

Vamos a ir paso a paso con cada uno de los elementos:

Cambios en el router de acceso a Internet

Este cambio es, a priori, uno de los más fáciles. No hay más que añadir ruta estática que envíe el tráfico dirigido a la red 192.168.2.0/24 a la interfaz WAN del router OpenWRT que tiene la dirección 192.168.1.2. Para ello, nos conectamos a la interfaz web de administración del router y configuramos la ruta estática:

red3

Cambios en el router con OpenWRT

Aquí es donde está realmente la chicha. Nos conectamos a la interfaz web del router basada en Luci:

red4

A continuación deshabilitamos la interfaz pseudobridge (starbridge) que implementaba el relay entre la red doméstica y la red del lab. Además eliminamos el paquete ralayd que ya no necesitamos (lo siento no tengo captura de pantalla de esto).

Configuramos la interfaz wireless estableciendo la dirección IP estática 192.168.1.2. Esta interfaz está asociada a la zona de firewall WAN.

red5
Creamos una interfaz que haga asociada a la LAN del lab y configuramos la dirección IP 192.168.2.1 (gateway de la LAN del lab). Asociamos esta interfaz a la zona de firewall LAN:

red6

Creamos dos rutas estáticas: una que dirija el tráfico hacia la LAN doméstica e internet hacia la interfaz wireless y otra que dirija el tráfico hacia la subred 192.168.2.128/25 (DMZ) hacia la dirección IP 192.168.2.4 donde va a estar el router VyOS virtual.

red7

Finalmente, configuramos las reglas de firewall que permitan el paso del tráfico desde la LAN doméstica (WAN en este router) y la LAN de lab:

red8

Con esto, el router OpenWRT debería quedar configurado.

Configuración del PC de sobremesa

La configuración del PC de sobremesa no debería ser un arco de iglesia. Abrimos el centro de redes y recursos compartidos, abrimos el enlace de los adaptadores, pinchamos el adaptador ethernet, seleccionamos Propiedades:

red9

Editamos las propiedades del protocolo de Internet versión 4, asignamos la dirección IP a 192.168.2.2, la máscara de subred a 255.255.255.128 y la puerta de enlace a 192.168.2.1. Establecemos los valores de los DNS de Telefónica y ¡listo!:

red10

Configuración del servidor ESXi

La configuración a realizar en el servidor ESXi consiste en establecer la nueva dirección IP para la interfaz de red de administración. Para ello, arrancamos el servidor y, en la consola, establecemos la dirección IP de la interfaz de administración a 192.168.2.3, la máscara de subred a 255.255.255.128 y la puerta de enlace a 192.168.2.1.

Configuración del servidor entorno virtual

Para configurar el entorno virtual, habilito la conexión ethernet del PC de sobremesa y deshabilito la WiFi y me conecto al servidor ESXi a través de vCenter:

red11

red12

Arrancamos el router VyOS y nos conectamos a la consola. Cambiamos, en primer lugar la dirección IP estática de la interfaz WAN.

red13

Cambiamos la interfaz de la DMZ para darle el direccionamiento correspondiente a la subred 192.168.2.128/25.

red14

red15

Configuramos la ruta estática de salida

red16

Finalmente eliminamos la reglas de NAT para la DMZ:

red17

En principio la red debería estar configurada y funcionando. En el próximo post vamos a realizar las pruebas.

Replanteando la red (I)

Comenté en un post anterior cómo había configurado la red para acceder al servidor ESXi. Esencialmente, lo que hice fue configurar un antiguo Router ADSL como un bridge WiFi mediante la instalación de OpenWRT. El esquema de la solución de conectividad que tengo desplegado es el siguiente.

red1

Tengo contratado el paquete Fusión fibra con Movistar. La ONT y el router están instalados en el salón y, directamente conectado al router están: el teléfono, el descodificador de Imagenio, un Android TV y una Play 3. Como la WiFi no llega  muy bien a toda la casa, instalé un repetidor WiFi.

A la WiFi se conectan los teléfonos móviles de la familia (4), los portátiles
de la familia (3), un par de tablets, un par de Kindles y, en la habitación de trabajo un PC de sobremesa que tiene conectados un escáner, una impresora y  varios discos duros compartidos en red. Además, en esta habitación de trabajo, está el router tuneado, al que se conectan por cable de red las dos interfaces del servidor ESXi y una Raspberry PI 2.

La solución de conectividad para el servidor ESXi basada en un pseudobridge sobre OpenWRT. La solución funciona pero, es cierto que, no a mi entera satisfacción.

El problema fundamental es que todo el tráfico del servidor ESXi pasa por la WiFi. Teniendo en cuenta que la WiFi no es uno de los puntos fuertes del router que suministra Telefónica, y el uso que la familia hace de ella, las probabilidades de saturarla son muy altas (prácticamente una certeza). Además la puñetera WiFi tiene cierta tendencia a caerse.

La idea es, dado que el PC de sobremesa (que es donde tengo instalado el
vCenter) tiene una interfaz ethernet (además de la WiFi), conectar esta interfaz al router con OpenWRT y las dos NICs del servidor ESXi. Esto haría que el tráfico del lab, con la excepción del tráfico Internet, se canalizaría por el router y no a través de la WiFi y me permitiría aprovechar el mayor ancho de banda de las conexiones de cobre.

Implementar esta solución supone convertir el pseudobridge en un router y segregar la LAN del lab de la LAN doméstica (192.168.1.0/24). Para el lab configuraré una nueva LAN (192.168.2.0/24). Las tareas a realizar son:

  1. Reconfigurar el router OpenWRT. Es necesario configurar la interfaz Wan (WiFi) con la dirección IP (192.168.1.2), deshabilitar la funcionalidad de pseudobridge y, en la parte LAN configurar dos subredes: la 192.168.2.0/25 para el PC de sobremesa (192.168.2.2) y las NIC del servidor ESXi (192.168.2.3 – Gestión y 192.168.2.4). La otra subred (192.168.2.128/25) la voy a dejar para el direccionamiento de la DMZ en el entorno virtual.
  2. Reconfigurar el router de banda ancha para añadir una ruta estática que dirija el tráfico destinado a la red 192.168.2.0/24 al router OpenWRT (192.168.1.2).

El esquema de red quedaría:

red2

Las ventajas que se me ocurre, proporciona esta solución son:

  1. Reducir el tráfico a través de la WiFi.
  2. Acelerar el acceso desde el vCenter a las máquinas virtuales.
  3. Evitar el doble NAT en la salida a Internet desde las máquinas virtuales (las de la DMZ).

Por otra parte, las desventaja fundamental es que el PC de sobremesa, al estar en una subred distinta al resto de los PCs, no puede compartir la impresora ni los discos duros sin desplegar un servidor de dominio (cosa que no pienso hacer). La solución pedestre es habilitar la interfaz ethernet cuando vaya a jugar con el lab y habilitar la interfaz WiFi el resto del tiempo.

Cómo hacerlo en el siguiente post.

Instalando Nagios (II)

En el post anterior abordé la descarga, configuración inicial, construcción e instalación de Nagios. En este post voy a cubrir la descarga, configuración, construcción e instalación de plugins y NRPE.

Capítulo 4. Descarga e instalación de los plug-ins

En primer lugar, para la descarga de los plugins de Nagios accedemos a este sitio para ver la última versión de éstos. En el momento de escribir esto se trata de la versión 2.1.1.

Al igual que en el caso de Nagios, utilizamos curl para la descarga del tarball:

nagios9

Descomprimimos …

add@ubnagios~$ tar –xvf nagios-p*

Configuramos y construimos …

add@ubnagios~$ cd nagios-p* add@ubnagios~/nagios-plugins-2.1.1$ ./configure --with-mail=/usr/sbin/sendmail --with-nagios-group=nagios --with-command-group=nagcmd
add@ubnagios~/nagios-plugins-2.1.1$ make

y, finalmente, instalamos …

add@ubnagios~/nagios-plugins-2.1.1$ sudo make install

Capítulo 5. Descarga e instalación de NRPE

NRPE es el Nagios Remote Plugin Executor. Al igual que en el caso anterior, averiguamos, en primer lugar, cuál es la última versión de NRPE accediendo a este sitio. En el momento de escribir esto, se trata de la versión 2.15.

Usando curl, descargamos el tarball…

nagios10

Descomprimimos …

add@ubnagios~$ tar –xvf nrpe*

Configuramos, construimos e instalamos …

add@ubnagios~$ cd nrpe* add@ubnagios~/nrpe-2.15$ ./configure --enable-command-args --with-nagios-user=nagios --with-nagios-group=nagios --with-ssl=/usr/bin/openssl --with-ssl-lib=/usr/lib/x86_64-linux-gnu
add@ubnagios~/nrpe-2.15$ make all
add@ubnagios~/nrpe-2.15$ sudo make install
add@ubnagios~/nrpe-2.15$ sudo make install-xinetd
add@ubnagios~/nrpe-2.15$ sudo make install-daemon-config

Por último editamos el script de arranque de xuinetd (/etc/xinet.d/nrpe) para añadir la dirección IP del servidor Nagios en el parámetro only_from:

nagios11

Finalmente rearrancamos el servicio xinetd:

add@ubnagios~$ sudo service xinetd restart

Con esto hemos completado la instalación de Nagios. En el siguiente post trataré de la configuración de Nagios.