Monitorizando dispositivos de red con ZABBIX

Para monitorizar dispositivos de red vamos a utilizar el protocolo SNMP (Protocolo Simple de Administración de Red).

Adjunto el link donde se describe el protocolo SNMP. http://es.wikipedia.org/wiki/Simple_Network_Management_Protocol

Las MIB’s (Base de Información de Administración) es una colección de información que está organizada jerárquicamente y son accedidas usando el protocolo de administración de red SNMP.
Las MIB’s más importantes para monitorizar los dispositivos de red son:

RFC1213

.1.3.6.1.2.1.1.1.0 sysDescr.0 (Descripción completa del sistema, versión, HW, OS)
.1.3.6.1.2.1.1.3.0 sysUpTime.0 (Tiempo desde la última reinicialización)

IF-MIB

.1.3.6.1.2.1.2.1.0 ifNumber.0 (El número de interfaces de red)
.1.3.6.1.2.1.2.2.1.2.1 ifDescr.1 (Descripción del interface de red)
.1.3.6.1.2.1.2.2.1.5.1 ifSpeed.1 (Velocidad del interface en bits/s)
.1.3.6.1.2.1.2.2.1.8.1 ifOperStatus.1 (El estado del interface)
.1.3.6.1.2.1.2.2.1.10.1 ifInOctets.1 (Número de octetos/s entrada del interface)
.1.3.6.1.2.1.2.2.1.16.1 ifOutOctets.1 (Número de octetos/s salida del interface)

Apunte para los de sistemas como yo: un octeto son 8 bits.

Una vez hecho un resumen del protocolo SNMP y las MIB’s que vamos a usar toca ponernos a configurar un dispositivo en ZABBIX.

Para ello os dejo una maravillosa plantilla que os podéis descargar en este link.
http://www.bimind.es/files/zabbix/BIMIND_Template_Network.xml

En ella encontrareis los intems de las MIB’s comentados anteriormente para 6 interfaces, los triggers que os avisarán si hay alguna de las 6 interfaces caídas o si se ha reiniciado el dispositivo y por último los gráficos de subida y bajada de las 6 interfaces.

La plantilla está configurada con la comunidad de lectura SNMP “public”. Acordaros que tiene que coincidir con la comunidad SNMP del dispositivo de red a monitorizar.

Cómo Actualizar Zabbix (1.6.5)

Ya tenemos aquí la nueva versión de zabbix 1.6.5 y aprovechando esta buena noticia voy a explicar como hacer la actualización.

Recuerdo que siempre es recomendable hacer una copia de seguridad de las base de datos y del directorio zabbix antes de actualizar a las nuevas versiones.

Paramos los servicios de zabbix

sudo /etc/init.d/zabbix-server stop

sudo /etc/init.d/zabbix-agent stop

Descargamos la última versión 1.6.5

wget http://puzzle.dl.sourceforge.net/sourceforge/zabbix/zabbix-1.6.5.tar.gz

La descomprimimos

tar zxvpf zabbix-1.6.5.tar.gz

Vamos a la carpeta que hemos descomprimido

cd zabbix-1.6.5

./configure --prefix=/usr --with-mysql --with-net-snmp --with-libcurl --with-jabber=/usr/ --enable-server --enable-agent && make
sudo make install

Copiamos los nuevos binarios.

sudo cp misc/init.d/debian/zabbix-server /etc/init.d
sudo cp misc/init.d/debian/zabbix-agent /etc/init.d

Y los reconfiguramos.

sudo nano /etc/init.d/zabbix-server

Buscamos la cadena:
DAEMON=/home/zabbix/bin/${NAME}
y la remplazamos por:
DAEMON=/usr/sbin/${NAME}

sudo nano /etc/init.d/zabbix-agent

Buscamos la cadena:
DAEMON=/home/zabbix/bin/${NAME}
y la remplazamos por:
DAEMON=/usr/sbin/${NAME}

Copiamos los nuevos archivos del frontend web

cp -R frontends/php/* /home/zabbix/public_html/

Creamos los índices recomendados por la actualizacion

sudo mysql -p -D zabbix –e “CREATE UNIQUE INDEX history_log_2 on history_log (itemid,id);”

sudo mysql -p -D zabbix -e “CREATE UNIQUE INDEX history_text_2 on history_text (itemid,id);”

sudo mysql -p -D zabbix -e “CREATE INDEX graphs_items_1 on graphs_items (itemid);”

sudo mysql -p -D zabbix -e “CREATE INDEX graphs_items_2 on graphs_items (graphid);”

sudo mysql -p -D zabbix -e "CREATE INDEX services_1 on services (triggerid);"

Iniciamos los servicios de zabbix

sudo /etc/init.d/zabbix-server start
sudo /etc/init.d/zabbix-agent start

Ya tenemos nuestro zabbix con la última versión

Zabbix 1.6.5 SO: Ubuntu 9.04

Explicación Tablas de la BBDD de Zabbix

Gracias a la aportación de OWEN os dejo la explicación de casi todas las tablas que forman parte de la BBDD de Zabbix.

Si alguien tiene más información que deje sus comentarios y lo iré completando.

- acknowledges: donde se alojan los comentarios cuando un problema es conocido/confirmado.
- actions: donde se alojan las acciones con su asunto, texto.
- alerts: el historial de alertas, enviado correo a tal, sms a tal, con el asunto del mensaje
- applications: poco que decir, donde se alojan las aplicaciones (repetidas para cada host)
- auditlog: lo que se muestra en administración -> auditoria -> audit logs
- conditions: relaciona una acción con una condición
- config: solo una fila con distintas configuraciones (tiempo de refresco, periodo de trabajo.. etc, configuraciones de la web)
- dchecks: comprobación de "discovery" (descubrir)
- drules: reglas para "discovery"
- dservices: ? algo de servicios de discovery pero nunca lo he utilizado
- escalations: registra las "escalaciones" a otro usuario cuando no puedes solucionar un problema
- events: donde se guarda el estado de los eventos, su fecha y el valor (on, off, unknown) y si esta ack (confirmado/conocido)
- functions: donde se guarda una relación de host (maquina) / item (elemento) / lanzador (trigger) y funcion (last, nodata, diff..)
- graphs: donde se guardan los datos de la grafica (alto, ancho, nombre.. )
- graphs_items: relación entre grafica y elemento (item) y otros valores de la relación (líneas, color..)
- groups: grupos de usuarios/maquinas
- help_items: la descripción de los items (elementos)
- history y history_*: se guarda la historia de los valores que se reciben de los hosts (maquinas)
- hosts: las maquinas, su nombre, ip y distintos valores
- hosts_groups: relación entre maquinas y grupos
- hosts_profiles: donde se alojan los perfiles de las maquinas
- hosts_profiles_ext: idem que el anterior pero cuando se crea un perfil mas avanzado
- hosts_templates: relación entre maquinas y plantillas
- housekeeper: esta tabla la tengo vacía, pero en teoría debería contener cada cuanto es el máximo de días que se contiene por cada tabla
- httpstep: los pasos que se siguen en configuración->web
- httpstepitem: relaciona la tabla anterior con la tabla de items (elementos)
- httptest: se guardan los test (ultima comprobación, próxima comprobación, periodo entre comprobaciones, aplicación relacionada..)
- httptestitem: relaciona la tabla anterior con la tabla de items (elementos)
- ids: es una tabla para saber el id de cada tabla, me imagino que es por compatibilidad con pgsql (que no tiene auto_increment, sino secuencias)

- images: las imágenes en un campo blob
- items: los elementos (system.uptime, proc.num[], etc) con configuraciones generales (tiempo del historial, tiempo de tendencia, template..)
- items_applications: relación de elementos (items) con las aplicaciones
- mappings: donde se guardan los "mapeos" (0 = off, 1 = on, etc)
- media: relación de usuarios/acciones y severidad (enviar sms a tal usuario cuando el problema es de alerta urgente, por ej.)
- media_type: los medios para enviar alertas (email pues su smtp, dirección de remitente; modem pues su puerto ttyS; script el nombre del script alojado en /etc/zabbix/alert.d/
- node_cksum: ? algo del checksum pero la tengo vacía
- nodes: ? algo de nodos, no lo utilizo
- opconditions: vacía
- operations: esta tengo que investigarla
- profiles: parece una tabla interna para distintas configuraciones (periodos de graficas, graficas favoritas.. )
- proxy_dhistory/proxy_history: historial del proxy (1.6)
- rights: permisos para los grupos
- screens: nombre de la pantalla y su tamaño
- screens_items: los mapas/elementos que se muestra dentro de las pantallas (screens)
- scripts: aplicaciones que se pueden ejecutar en las maquinas
- service_alarms, services, services_links, services_items: ?
- sessions: donse aloja el sessionid (identificador de la sesión) para cada usuario
- slides: donde se guardan configuración -> screens -> slides
- sysmaps: los mapas en si con el tamaño y configuraciones del titulo
- sysmaps_elements: los elementos dentro de cada mapa
- sysmaps_link_triggers, sysmaps_links: ?
- trends, trends_uint: donde se aloja la tendencia de los elementos (items) en los últimos X dias
- trigger_depends: dependencia de los triggers (yo nunca lo he usado)
- triggers: los triggers con la condición para que se lance y la plantilla/host a la que se relaciona
- users: los usuarios
- users_groups: relación usuarios/grupos
- usrgrp: ?
- valuemaps: ? parecen etiquetas para los mapas

Backup BBDD Zabbix sin histórico

En la BBDD de Zabbix tenemos almacenado tanto la configuración de este como el histórico de los valores que vamos recogiendo.

El histórico de Zabbix es el que va aumentando durante la vida de nuestro servidor y lo que hace que la copia de la base de datos a veces sea muy lenta.

Nos podemos encontrar con la necesidad de crear un Zabbix de test con la misma configuración que el de producción pero sin datos o simplemente vaciar el histórico para aumentar la velocidad o el espacio de disco.

Lo primero que vamos hacer es extraer el listado de tablas de nuestro zabbix a un archivo:

mysql -p zabbix -e 'show tables' > tables.txt

Ahora exportaremos los datos de la BBDD exceptuando las tablas history:

grep -v Tables ./tables.txt | grep -v history | xargs mysqldump -p zabbix > backup.sql

Y con esto ya tenemos una copia de nuestro Zabbix sin el histórico lista para importar donde queramos.

Zabbix 1.6.5 SO: Ubuntu 9.04

Ejecutar comandos remotos en Zabbix

Voy a intentar explicar las opciones para usar comandos remotos para administrar nuestros dispositivos monitorizados. Como requisito previo en la configuración del agente de nuestros dispositivos “zabbix_agentd.conf” tenemos que habilitar la opción de ejecutar comandos remotos “EnableRemoteCommands=1”.

Tenemos varias opciones para diferentes escenarios.

OPCIÓN 1. Comando remoto mediante Configuration-Intems.

Esta opción sirve para recoger la información que produce un comando de manera periódica.

system.run[comando_remoto]

OPCIÓN 2. Comando remoto mediante Configuration-Actions.

Esta opción la utilizaríamos para ejecutar un comando de manera automática si se produce alguna condición previamente configurada.

{HOSTNAME}:comando_remoto

OPCIÓN 3. Comando remoto mediante Administration-Scrips.

Esta opción sirve para ejecutar de manera manual un comando y ver el resultado.

zabbix_get -s {HOST.CONN} -k system.run[comando_remoto]

Zabbix 1.6.2 SO: Ubuntu 8.10

Ejemplo mensaje Alerta/Acción para zabbix

Aquí os dejo un pequeño ejemplo para configurar un mensaje de alerta/acción para zabbix "Configuration-Actions".

Default subject:

{HOSTNAME} {TRIGGER.NAME}: {STATUS}

Default message:

Date: {DATE}

Time: {TIME}

Hostname: {HOSTNAME}

IP: {IPADDRESS}

Severity: {TRIGGER.SEVERITY}

Last Key:
{{HOSTNAME}:{TRIGGER.KEY}.last(0)}

Preview Key:
{{HOSTNAME}:{TRIGGER.KEY}.prev(0)}

Por último os dejo un link con varias variables para utilizar en los mensajes.

http://www.zabbix.com/wiki/howto/config/alerts/customizing_your_alerts

Zabbix 1.6.2 SO: Ubuntu 8.10

Visor de Sucesos de Windows con Zabbix

Para empezar a monitorizar el visor de sucesos de Windows guardaremos esta plantilla en formato xml y posteriormente la importaremos desde "Configuration-Import/Export".

http://www.zabbix.com/wiki/lib/exe/fetch.php?id=contrib%3Atemplates&cache=cache&media=contrib:zabbix_export.xml

Una vez importada la plantilla podremos observar que los tipos de items son activos con lo cual es el host quien envía la información y no Zabbix Server quien la pide. Esto significa que el nombre del host que publiquéis en zabbix "Configuration-Hosts-Name" y el hostname que escribas en el archivo de configuración del cliente "zabbix_agentd.conf" tienen que coincidir para que Zabbix sepa de qué host proviene la información.

Tener en cuenta que el hostname tiene que ser único y distingue mayúsculas de minúsculas.

Una vez empiece a funcionar los agentes de Windows empezaran a enviar todo el visor de sucesos al zabbix de manera secuencial. Esto lo comento porque empezareis a recibir alertas antiguas hasta que no se cargue todo el visor de sucesos. Es recomendable deshabilitar los triggers hasta que finalice el proceso.

Y ahora un poco de sintaxis para parametrizar los triggers y así se adapten a nuestras necesidades.

Esto deshabilitará la alerta del trigger si el visor de sucesos no nos envía mas alertas en los últimos 30 segundos.

({HOST:eventlog[Application].logseverity(4)}=4)&({HOST:eventlog[Application].nodata(30)}#1)

En este trigger le indicamos el origen del visor de sucesos

({HOST:eventlog[Application].logseverity(4) }=4)&({HOST:eventlog[Application].logsource(Origen)}=1)

En este trigger le indicamos un texto a buscar en el visor de sucesos.

({HOST:eventlog[Application].logseverity(4)}=4)&({HOST:eventlog[Application]. str(Texto a buscar)}=1)

Zabbix 1.6.2 SO: Ubuntu 8.10