Universidad Austral de Chile
Facultad de Ciencias de la Ingeniería
Escuela de Ingeniería Civil Electrónica
“IMPLEMENTACIÓN DE PLATAFORMA DE
MONITOREO ZABBIX PARA SISTEMAS DE
TELECOMUNICACIONES TELSUR”
Trabajo para optar al título de:
Ingeniero Civil Electrónico
Profesor Patrocinante
Sr. José Mardones Fernández
Ingeniero Electrónico
Licenciado en Ciencias de la Ingeniería
MARCELO ANDRES ULLOA SOLIS
VALDIVIA – CHILE
2014
DEDICATORIA
Con todo mi amor y cariños ya que hicieron todo en la vida para que yo pudiera lograr mis
sueños, por motivarme, por confiar en mi, por aconsejarme y darme la mano cuando sentía que
el camino se terminaba, a ustedes por siempre en mi corazón y agradecimiento Papá y Mamá.
Hermana, cuñado y hermosa sobrina. Mucha gracias por todos estos años, por guiarme, por
estar conmigo en los momentos buenos y por motivarme a no decaer en momentos malos, por
ser parte de mi linda familia, los quiero.
Amigos simplemente gracias por estar todos estos años apoyándome tanto presencial como a
la distancia, pero muy especial a esas personas que son parte de mi corazón.
A mis profesores que influyeron con sus lecciones y experiencias en formarme como una
persona de bien y por prepararme para los retos que vienen. En especial a mi profesor
Patrocinante por guiarme con mucha preocupación en la preparación de la presente tesis.
Al Sr. Rodrigo Salas, por confiar en mis capacidades y darme la oportunidad de trabajar en un
proyecto de gran importancia para la compañía.
Indice
RESUMEN ………………………………………………………………………………………IV
OBJETIVOS ……………………………………………………………………………………..VI
1. INTRODUCCION .............................................................................................................1
2. SNMP...............................................................................................................................3
2.1 COMPONENTES BASICOS SNMP ................................................................................4
2.2 MIB-II ...............................................................................................................................7
2.3 SNMP Y SUS PROTOCOLOS DE TRANSPORTE ..........................................................9
2.4 Operaciones SNMP ....................................................................................................11
2.5 VERSIONES SNMP Y OTROS ESTÁNDARES DE MONITOREO. .............................12
3. MONITOREO DE RED ..................................................................................................14
4. SOFTWARE ZABBIX ...................................................................................................15
4.1 ¿CÓMO ES EL FUNCIONAMIENTO DEL SOFTWARE ZABBIX? ...............................16
4.2 JUSTIFICACIÓN DE ELECCIÓN DISPOSITIVO DE MONITOREO ZABBIX ...............18
5. DESARROLLO PRACTICO DE IMPLEMENTACIÓN DEL SOFTWARE ZABBIX ........24
5.1 Definición de la Red de Telefónica del Sur................................................................24
5.2 CRITERIOS DE ELECCIÓN DE LA DISTRIBUCION DE LINUX A INSTALAR COMO
SERVIDOR ....................................................................................................................27
5.3 INSTALACIÓN DEL SOFTWARE ZABBIX. ................................................................28
6. DESARROLLO PRACTICO DEL MONITOREO ...........................................................35
6.1 GESTIÓN DE MONITOREO DE ENERGÍA. ..................................................................35
6.2 GESTIÓN DE MONITOREO DEL EQUIPAMIENTO DE TV IP. ....................................48
7. RESULTADOS ..............................................................................................................49
7.1 RESULTADOS DEL MONITOREO DE LOS EQUIPOS DE ENERGÍA..........................49
7.2 RESULTADOS DEL MONITOREO DEL EQUIPAMIENTO TV IP. .................................50
8. CONCLUSIONES ..........................................................................................................53
9. REFERENCIAS .............................................................................................................55
I
Indice de figuras
Figura 1 Ubicación protocolo SNMP en modelo TCP /IP ............................................3
Figura 2 Subárbol MIB-II rama mgmt ...........................................................................6
Figura 3 Modelo de comunicación TCP/IP y SNMP ...................................................10
Figura 4 Operaciones SNMP .......................................................................................12
Figura 5 Funcionamiento Zabbix ................................................................................16
Figura 6 Red ejemplo telefónica del sur. ....................................................................25
Figura 7 Obtención de la dirección de descarga .......................................................28
Figura 8 Descarga de archivos de instalación ...........................................................29
Figura 9 Archivos de configuración zabbix 2.2 .........................................................29
Figura 10 Interfaz de configuración final ....................................................................30
Figura 11 Checkeo de prerrequisitos de archivos instalados...................................31
Figura 12 Configuración de conección a la base de datos .......................................32
Figura 13 Configuración Zabbix Server ......................................................................32
Figura 14 Detalles de configuración en la instalación Web Zabbix .........................33
Figura 15 Instalacion final ...........................................................................................33
Figura 16 Test de comprobación correcta de Zabbix ................................................34
Figura 17 Pantalla de bienvenida al programa ...........................................................34
Figura 18 Apoyo visual para la creación del Host Group ..........................................36
Figura 19 Configuración del Grupo de host para rectificadores...............................36
Figura 20 Configuración de un host rectificador en forma detallada .......................37
Figura 21 Configuración ítem Ping Check ..................................................................38
Figura 22 Gráfica de la variable ping check en el rectificador LN03 Concepción ...39
Figura 23 Configuración del Trigger para ítem ping check .......................................40
Figura 24 Diagrama funcionamiento SNMP Trap .......................................................41
Figura 25 Configuración equipos mediante Telnet ....................................................42
Figura 26 Configuración snmptrapd.conf...................................................................43
Figura 27 Configuración archivo snmptt.ini ...............................................................44
Figura 28 Trap recibido desde un rectificador sin modificaciones ..........................45
Figura 29 Traps traducido por SNMPTT .....................................................................45
Figura 30 Configuración ítem trap ..............................................................................46
II
Figura 31 Traps recibido por Zabbix ..........................................................................46
Figura 32 Severidades traps ........................................................................................47
Figura 33 Cantidad de rectificadores con problemas ................................................49
Figura 34 Diferentes tipos de alarmas enviados por los rectificadores ...................49
Figura 35 Triggers activados con problemas de Ping Check ...................................50
Figura 36 Gráfica temperatura del procesador ..........................................................51
Figura 37 Gráficos de entrada en la Puerta 1 del Switch mikrotik ............................51
Figura 38 Gráfica de salida en la puerta 1 del switch mikrotik .................................52
III
RESUMEN
La detección oportuna de fallas en una red de telecomunicaciones nos permite asegurar un alto
nivel de disponibilidad de ella, donde se prioriza la calidad de los servicios hacia los clientes.
El software Zabbix nos entregan las herramientas necesarias para poder monitorear una red de
telecomunicaciones ya que es compatible con protocolos estándar de monitoreo de redes como
SNMP y SNMP Trap. El software Zabbix opera bajo plataforma Linux lo que da mayor
estabilidad del software.
Una vez ejecutado el software se observan los resultados en 2 áreas de aplicación como son
monitores de rectificadores y monitoreo de switch de TV IP, lo que permite concluir que los
resultados son óptimos.
IV
ABSTRACT
Early detection of faults in the network allows us to have a stable operation of it, where the
quality of service to customers is a priority.
The Zabbix software give us the tools necessary to monitor a telecommunications network that
is compatible with network monitoring protocols such as SNMP and SNMP Trap. The Zabbix
software runs under Linux platform that gives greater stability software.
After running the software results observed in two areas of application such as monitors switch.
V
OBJETIVOS
OBJETIVOS GENERALES
Diseñar la aplicación de un software de monitoreo para la red de Telefónica del Sur.
Instalar y configurar un software de monitoreo para la red sistema de
telecomunicaciones de Telefónica del Sur..
Habilitar una plataforma de software estable de monitoreo Zabbix actualizada.
Identificar las variables críticas, menos críticas y no importantes en la capa de
distribución del sistema de telecomunicaciones para la mantención preventiva.
OBJETIVOS ESPECIFICOS
Describior el protocolo SNMP
Identificar las Object IDentificator (OID) en las diferentes Management Information Base
(MIB) de los equipos monitoreados.
Definir el sistema de monitoreo Zabbix.
Instalar la plataforma de monitoreo Zabbix
Configurar los equipos rectificadores Cherokee para monitorización vía Traps.
Crear triggers eficientes para un correcto monitoreo.
Verificar la correcta aplicación del software Zabbbix para el monitoreo de la red de
Telefónica del Sur.
VI
1. INTRODUCCION.
Poder prevenir y actuar de forma anticipada a los distintos problemas por medio de una
supervigilancia, son herramientas que nos llevan a tener un elevado nivel de disponibilidad de la
red de telecomunicaciones de Telefónica del Sur. Debido a la amplitud de la red, los costos de
mantención son muy altos, y acá es donde las soluciones de monitoreo juegan un papel clave
ya que ofrecen un control y soluciones a problemas de forma óptima y rápida. Además tienen
una importancia prioritaria para ofrecer altos estándares de confiabilidad y disponibilidad a los
clientes.
Una acción de monitoreo exitosa requiere de un diseño de ingeniería previo que señale donde y
como se efectuaran las acciones de recopilaccion de datos, clasificación de ellos y toma de
decisiones para efectuar labores correctivas asi mismo, la ingeniería del diseño permitirá definir
criterios de mantención preventiva basados en el almacenamiento y post procesamiento de los
datos recogidos por el sistema de monitoreo.
Poder montar una solución de monitero que sea efectiva y eficaz a la vez, requiere mucha
dedicación por parte del personal encargado, ya que se deben analizar y configurar muchos
parámetros.
El software Zabbix [1] es una plataforma Open Source de gran calidad y factible
económicamente ya que no requiere de gran hardware en el servidor; sin embargo requiere
personal con alto nivel de conocimientos tanto en Linux [2] como en telecomunicaciones para
potenciar al máximo el uso del software. Una de las características importantes es que es un
software libre y no se necesitan costos de licenciamiento para su manejo.
1
2
Cada equipamiento posee su propio sistema de monitoreo establecido, el cual rara vez se
puede configurar según las necesidades del usuario.
El desarrollo del presente trabajo se organiza de la siguiente forma: En el capítulo 2 se describe
las características del protocolo SNMP. En el capítulo 3 se define que es un monitoreo de red.
En el capítulo 4 se da a conocer las características del software Zabbix. En el capítulo 5 se
describe la implementación del software zabbix. En el capítulo 6 se da a conocer los resultados
de la ejecución del monitoreo. En el capítulo 7 se muestran los resultados obtenidos en el
proceso de monitoreo. Finalmente, en el capítulo 8 se entregan las conclusiones.
2 SNMP
Simple Network Management Protocol (SNMP) es un protocolo perteneciente a la capa de
aplicación correspondiente al séptimo nivel del modelo OSI es definido por la IAB (Internet
Architecture Board) en la RFC 1157 para el intercambio de información de administración entre
dispositivos de red. Este protocolo posee un conjunto de aplicaciones de gestión de red que
emplean los servicios TCP/IP [4], los cuales proporcionan herramientas [16] a los
administradores de red para poder supervisar la red; en la figura 1 podemos ubicar en que nivel
del modelo TCP/IP [6] se encuentra el protocolo.
Figura 1. Ubicación protocolo SNMP en modelo TCP /IP.
SNMP en la actualidad es uno de los protocolos ampliamente usado para la gestión y
seguimiento de elementos dentro de una red. La gran parte de los elementos de red a nivel
profesional vienen con un agente SNMP instalado. Los cuales son activados y configurados de
tal forma que se puedan comunicar con el sistema de gestión de red (NMS)
3
4
2.1 COMPONENTES BÁSICOS SNMP
Una red administrada con SNMP contiene 4 componentes básicos fundamentales
Administrador SNMP
Dispositivos Administrados
Agente SNMP
Base de datos información de gestión (MIB)
Administrador SNMP: Un administrador SNMP es una entidad independiente que se encarga
de comunicarse con el agente SNMP implementados en los distintos dispositivos de red.
Las funciones más importantes de un Administrador SNMP son las siguientes:
Consultas al agente
Obtener las respuestas de los agentes
Establece las variables de agentes
Reconoce eventos asíncronos de los agentes.
Dispositivos gestionados: Un dispositivo gestionado, es una parte de la red que requiere
algún tipo de monitoreo y gestión por ejemplo Switch, servidores, routers, entre otros.
Agente SNMP: Es un programa que se instala dentro de un elemento de red. Este agente tiene
acceso a la base de datos de gestión del dispositivo a nivel local y hace posible que el
administrador SNMP pueda realizar consultas. Estos agentes pueden ser estándar o
específicos de un proveedor.
5
Las funciones más importantes de un agente SNMP son:
Recopilar información de gestión.
Almacenar y recuperar información que se definen en la MIB.
Informar un evento al Administrador SNMP.
Actuar como Proxy para algún nodo de la red que no manejable con SNMP
Base de datos información de gestion (MIB): Cada uno de los agentes SNMP contiene una
base de datos de información que describen los parámetros de los dispositivos monitoreados. El
administrador SNMP utiliza esta base de datos para solicitar al agente obtener información
específica y envía la información necesaria para el sistema de gestión de red. Esta base de
datos común compartida entre el agente SNMP y el gestor se llama Management Information
Base (MIB). Los archivos MIB son el conjunto de preguntas que un administrador SNMP puede
pedir a un agente SNMP. El agente recopila estos datos a nivel local y las almacena, según se
definen en la MIB. Esto permite que el administrador SNMP este al tanto de las preguntas
estándar y privadas que tiene cada agente.
Las MIB son colecciones de información para la gestión de los elementos de la red. Estas
están compuestas por identificadores de nombre de objetos (OID).
Cada uno de estos identificadores es único y denota las características específicas de un
dispositivo. Estos valores de los identificadores pueden ser del tipo Texto, Numérico,
Contadores, etc.
Una OID se compone de una serie de enteros separados por puntos y son basados en los
nodos del árbol MIB. Esta estructura es la base para el esquema de nombres SNMP. La
definición de la estructura del árbol de MIB se encuentra en el módulo RFC1155-SMI [7]
(Structure Management Information), junto con las declaraciones de tipos utilizados en las MIB.
6
Los agentes SNMP implementan una MIB particular llamada MIB-II (RFC 1213). Esta es la MIB
principal para redes del tipo TCP/IP, estos archivan datos comunes de gestión como:
información del sistema, interfaces, protocolos, etc. La importancia que tiene la MIB-II, es que
cada dispositivo que soporta SNMP también debe contener la MIB-II lo cual la convierte en un
estándar para este tipo de base de datos.
El OID MIB-2 se define como iso.org.dod.internet.mgmt.1 (formato texto) o como 1.3.6.1.2.1.
(Formato numérico). En la figura 2. Se muestra la estructura del subárbol MIB-II de la rama
mgmt.
Figura 2. Subárbol MIB-II rama mgmt.
7
2.2 MIB-II
La MIB-II es la base de datos común para gestión de equipos. Está definida originalmente en la
RFC 1213. Con la aparición de las nuevas versiones de SNMPv2 y SNMPv3 esta MIB se amplió
y se dividió en varios RFC: RFC4293, RFC 4022, RFC 4113 y RFC 3418.
La MIB-II está compuesta por 10 grupos
Grupo System
Grupo Interfaces
Grupo AT
Grupo IP
Grupo ICMP
Grupo TCP
Grupo UDP
Grupo EGP
Grupo Transmisión
Grupo SNMP
Un breve resumen del contenido de los grupos contenidos en la MIB-II se da a continuación:
Grupo System (1.3.6.1.2.1.1): Este grupo proporciona información general sobre
nuestro sistema gestionado en el cual se encuentra el agente. Como por ejemplo el
nombre del sistema (sysName), etc.
Grupo Interfaces (1.3.6.1.2.1.2): Contiene información sobre la configuración y
estadísticas de eventos sobre las interfaces de red en una entidad gestionada. Este
grupo monitoriza que interfaces están caídas o levantadas y registra cada dato como
octetos enviados y recibidos, errores, etc.
8
Grupo at (1.3.6.1.2.1.3): Este grupo es el encargado de la traducción de
direcciones de red y direcciones MAC, su estado actual es “deprecated” y se
mantiene únicamente por contabilidad con la MIB . Es probable que termine por
desaparecer en la MIB-III.
Grupo IP (1.3.6.1.2.1.4): Este grupo contiene información relevante sobre las
operaciones y aplicaciones IP en el nodo gestionado, en el cual se incluyen
contadores del flujo de entrada y salida.
Grupo ICMP (1.3.6.1.2.1.5): Este grupo contiene un registro de los distintos
datos tipo ICMP, tanto ICMP enviados y recibidos, incluyendo los errores ICMP.
Gripo TCP (1.3.6.1.2.1.6): Este grupo contiene información sobre las conexiones
TCP y datos generales sobre TCP en el nodo gestionado.
Grupo UDP (1.3.6.1.2.1.7): Este grupo contiene información sobre las
conexiones UDP tanto en la operación e implementación. Registrando las
estadísticas asociadas como: datagramas de entrada, datagramas de salida, etc.
Grupo EGP (1.3.6.1.2.1.8): Este grupo contiene información sobre la operación e
implementación de EGP (exterior gateway procotolo) en el nodo gestionado.
Grupo transmisión (1.3.6.1.2.1.9): Este grupo mantiene información relevante
sobre el sistema físico de cada interfaz del sistema. En general se usa como nodo
bajo el cual existen varios grupos especificados para cada interfaz.
Grupo SNMP (1.3.6.1.2.1.11): Este grupo es el encargado de medir el
rendimiento de la implementación SNMP registrando datos como por ejemplo el
número de paquetes SNMP que sean enviado y recibido.
9
2.3 SNMP Y SU PROTOCOLO DE TRANSPORTE
SNMP se puede implementar usando comunicaciones UDP o TCP, pero se elige como
transporte el protocolo UDP [8] (User Datagram Protocol) como estándar en las comunicaciones
para intercambiar información entre gestores y agentes. Se elige UDP sobre TCP (Transmission
Control Protocol) porque este tipo de protocolo no es orientado a la conexión, esto quiere decir,
que no se establece una conexión extremo a extremo entre el agente y el gestor cuando los
paquetes (datagramas) se envían de un lado hacia otro. Usar UDP es poco fiable ya que no
existen reconocimiento de los datagramas perdidos en el nivel del protocolo. Esto se soluciona
en la parte de aplicación ya que se determinan si estos datagramas se perdieron ( timeout) y
poder realizar una retransmisión si así se desea. El funcionamiento se basa en que el gestor
envía una petición UDP a un agente y espera una respuesta a dicha petición. Si no existe
respuesta a dicha petición (timeout) y el gestor no recibe datos se asume que el paquete se
perdió y se vuelve a retransmitir la petición, se pueden hacer una configuración con un número
máximo de retransmisiones en caso que sea necesario por el equipo gestor. Una de las razones
por lo que se usa UDP es debido a que este protocolo usa pocos recursos para la transmisión,
lo que logra un impacto mínimo al rendimiento de la red.
Cuando usamos SNMP-Trap necesitamos tener una comprobación de que el agente envía una
alarma definida como Trap y que este ha llegado correctamente al gestor, porque no existe
forma alguna de saber si se ha perdido este dato.
Los puertos utilizados para enviar y recibir peticiones son el 161 y el puerto 162 para recibir
traps de los dispositivos monitoreados. Estos puertos vienen por defecto en la configuración del
agente. En caso que se realice algún cambio de puertos, se debe configurar el sistema gestor
con los cambios realizados para poder realizar las consultas pertinentes.
10
Figura 3. Modelo de comunicación TCP/IP y SNMP.
La figura 3 muestra el modelo del protocolo TCP/IP en el cual se basan todas las
comunicaciones utilizando SNMP.
Cuando el gestor o un agente realizan una operación SNMP (Una petición o Trap como
ejemplo), se producen una serie de eventos en la pila de protocolos.
Aplicación: La aplicación SNMP (Agente o gestor) toma una decisión de que acción va
a realizar, por ejemplo enviar traps desde el agente al gestor. Esta capa debe
proporcionar los servicios a un usuario final, en este caso podría ser un operario que
está encargado del monitoreo de cierto servicio vía mensajes traps.
UDP: Esta etapa está encargada de la comunicación entre 2 hosts. Dentro de la
cabecera UDP se encuentra el puerto de destino del dispositivo al que se envían las
consultas o los traps. Los puertos destino por defecto son 161 (consulta) o 162 (traps).
IP: La capa IP es la encargada de enviar el paquete de datos SNMP al destino
especificado por su dirección IP.
11
Control de Acceso al Medio (MAC): La última etapa que sucede con el envío del
paquete SNMP es llegar a su destino, para ello es necesario llegar a la red física, donde
se enruta con el direccionamiento del destino final. La capa MAC es responsable de
recibir los paquetes de la red física y devolverlos a la pila de protocolos de forma que
puedan ser procesador por la capa de aplicación.
2.4 OPERACIONES SNMP
El protocolo SNMP [9] define cinco tipos de mensajes de intercambien entre el agente y el
gestor, los denominados PDU [11].
Get- Request: El gestor realiza una petición específica de la MIB del agente.
Get-Next-Request: El gestor realiza una petición del objeto identificador siguente a uno
dado en la MIB del agente.
GetResponse: El agente devuelve los valores solicitados por las operaciones anteriores
del gestor.
Set-Request: El gestor permite asignar un valor a una variable del sistema del agente.
Trap: El agente envía un mensaje informando sobre algún suceso no habitual
predefinido.
12
Figura 4. Operaciones SNMP.
2.5 VERSIONES SNMP Y OTROS ESTÁNDARES DE MONITOREO.
SNMP versión 1 (SNMPv1) versión estándar del protocolo SNMP definida en su totalidad en la
RFC 1157. La seguridad utilizada en esta versión está basada en comunidades. Esta versión
fue diseñada a mediados de los años 80, y cumplía con el rol de ser una solución temporal para
la gestión de redes a la espera de protocolos con mejor diseño y más completos; el intercambio
de información es basada en mensajes PDU.
SNMP V2, en esta versión se adicionan mejoras importantes referentes a la cantidad de cargo
adicional en el uso del monitoreo, solucionando problemas relacionados con monitorización
remota o distribuida. Creada en el año 1993 y revisada en 1995, añadiéndole protocolos de
seguridad , donde las variables son definidas con más detalles, además se le añaden
estructuras en la tabla de datos para facilitar el manejo de los datos obtenidos.
SNMP V3, esta versión fue desarrollada en el año 1998, donde se le agregan parámetros de
seguridad, las cuales son:
Integridad de mensajes: Asegura que el paquete de datos no haya sido modificado
durante la transmisión.
13
Autentificación: Determina que el mensaje enviado proviene de una fuente válida.
Encriptación: El paquete de datos es encriptado en su contenido para añadir una capa
de seguridad como forma de prevención.
También existen otros protocolos de gestión de red, como CMIS/CMIP. Las diferencias
principales radican en que SNMP es utilizado para la gestión de red internet (TCP/IP) y
CMIS/CMIP es utilizado en la gestión de redes OSI. El protocolo CMIP es un sistema de
gestión de red bien estructurado, el cual mejora muchas deficiencias del protocolo SNMP, pero
a la vez es un sistema que ocupa una gran cantidad de recursos de la red, por lo que se
recomienda siempre implementar SNMP antes que CMIP.
3. MONITOREO DE RED
Uno de los roles fundamentales de un administrador de red es la monitorización de red, esto
consiste en el proceso de comprobar correctamente el funcionamiento de los dispositivos que
contiene la red. Tomar datos, vigilar y analizar los resultados son tareas que se deben cumplir
para anticiparse a problemas que puedan ocurrir dentro de la red.
El funcionamiento de un gestor de monitoreo consiste en tomar datos del consumo de recursos,
asignaciones de memoria, rendimientos, estado de conectividad, tráficos de entrada y salida,
entre otros. Todos estos datos permiten identificar y resolver cualquier error crítico antes que
afecte los procesos de negocios. La finalidad es crear alarmas automáticas que informen de
estados críticos al grupo técnico para poder tomar decisiones basadas en análisis y
experiencias previas. El objetivo final es que los problemas se resuelvan rápidamente sin que el
usuario final se vea afectado.
Este proceso de monitoreo debe ser permanente, ordenado y exacto. Para poder identificar que
variables críticas constituyen la estabilidad de la red y servicios asociados, para tomar acciones
de carácter preventivo y correctivo.
Tener un buen sistema de monitoreo constituyen una buena inversión, ya que evita grandes
costos de mantención correctiva de los equipos y sobre dimensionar la cantidad de personal
para la operación de la red. La respuesta anticipada a problemas y la prevención son las
herramientas que llevan a un control exitoso de la red. El monitoreo a la vez permite mejorar la
confiabilidad y disponibilidad de la red completa.
14
4. SOFTWARE ZABBIX
Zabbix es un sistema de monitoreo de redes, que está diseñado para registrar y monitorear el
estado de varios servicios de red, servidores, hardware de red y aplicaciones.
Las principales base de datos utilizadas por Zabbix son MySql y PostgreSQL.
Las principales características de Zabbix son las siguientes:
Alto rendimiento y alta capacidad de monitoreo de distintos dispositivos.
Monitoreo centralizado a través de un administrador web.
Alta capacidad de análisis de servicios prestados.
La instalación de agentes se puede realizar en cualquier sistema operativo.
Capacidad para monitorear directamente con protocolo SNMP (v1, 2 y 3) y dispositivos
IPMI.
Construcción de gráficos y opciones de visualización.
Notificaciones que permiten una fácil integración de sistemas.
Configuración flexible, incluyendo la creación de plantillas.
Permite el uso de script externos.
Entre otras características que permiten un sistema de monitorización sofisticado.
15
16
4.1 ¿CÓMO ES EL FUNCIONAMIENTO DEL SOFTWARE ZABBIX?
La aplicación Zabbix [3] se instala en un servidor Linux [13] el cual tiene como
función
recolectar información. Además Zabbix proporciona una interfaz Web en la cual se presentan de
forma gráfica toda la información que se recolectó.
Zabbix almacena la información entregada por los agentes SNMP de los dispositivos
monitoreados. Esta información puede ser accesada a través de la interfaz gráfica que queda
instalada en el servidor Zabbix.
Los agentes una vez que son instalados en los dispositivos, están a la espera de las órdenes
del servidor Zabbix. Los agentes solo envían la información que les pida el servidor Zabbix.
Figura 5.- Funcionamiento Zabbix.
17
De acuerdo a la figura 5, se detallan paso a paso el funcionamiento de zabbix:
4.1.1 Instalación del Agente Zabbix en el equipo a monitorear (servidores o estación de
trabajo); éste se debe configurar para reportar al servidor Zabbix de nuestra red. En caso
de Hardware como routers, sensores de temperatura, sensores de humedad,
rectificadores, switches. No se utiliza el agente Zabbix, ya que estos equipos cuentan
con un agente SNMP instalado.
4.1.2 En el servidor Zabbix, a través de la herramienta de administración web
(FrontEnd), se deben registrar los equipos y dispositivos destinados a la monitorización.
4.1.3 El equipo y dispositivos registrados se convierten en elementos a ser monitoreados
y estos reciben un nombre de Host.
4.1.4 Cada uno de los Host está compuesto por una serie de elementos llamados Ítems
que son módulos encargados de recoger datos del Host y en caso del hardware son los
datos recogidos del dispositivo.
4.1.5 Los Items utilizan parámetros de zabbix llamados Keys, estos nos permiten indicar
que tipo de información solicitaremos al agente Zabbix o al agente SNMP. En la figura 5
se pueden apreciar 2 items los cuales tienen keys diferentes. El ítem de la izquierda
utiliza una key espacio en disco, para solicitar la información del espacio disponible en el
disco duro del host monitoreado, el ítem de la derecha utiliza el key memoria para
solicitar el estado de la memoria RAM del host monitoreado.
4.1.6 Los triggers en Zabbix son módulos creados a uno o varios Items, para evaluar y
comparar los valores recolectados por los Items con condiciones que definimos. Por
ejemplo podemos crear un trigger al ítem con la key espacio de disco duro e indicar que
si este llega a un 70% de espacio ocupado nos emita una alarma.
18
4.1.7 Los triggers generan eventos que son reflejados en la herramienta de
administración web, permitiendo mostrar gráficamente las alarmas generadas.
4.1.8 Zabbix, tiene la capacidad de poder genera eventos como enviar correos
electrónicos, SMS o ejecutar algún script cuando algún ítem sobrepasa un parámetro
definido. Esto son eventos son definidos en los triggers.
4.2 JUSTIFICACIÓN DE ELECCIÓN DISPOSITIVO DE MONITOREO ZABBIX
Existen muchas razones para elegir zabbix como solución de monitoreo sobre otras
plataformas. Las características más importantes de la plataforma son las siguientes:
4.2.1. Capacidad de monitoreo: Utilizando Zabbix podemos fácilmente controlar los
servidores, dispositivos de red y aplicaciones, con una recolección de estadísticas
precisas de los datos.
4.2.2. Rendimiento: Monitoreo de las variables de rendimiento como CPU, memoria,
red, espacio de disco, se pueden lograr fácilmente con el agente Zabbix, el cual
está disponible para Linux, Unix y Windows. Este es un proceso nativo y no
requiere un entorno específico, como Java o .NET.
4.2.3. Supervisión sin agente: El agente Zabbix es una gran manera de supervisar,
pero no siempre es posible recurrir a esta herramienta. Para esos casos Zabbix
admite varios enfoques de monitoreo sin agentes. Se pueden hacer consultas de
disponibilidad y la capacidad de respuesta de servicios estándar, tales como correo
electrónico o servidores sin necesidad de instalar ningún software en dispositivos
monitorizados.
19
4.2.4. Dispositivos de red: Zabbix es compatible con agentes SNMP, presentes en
todos los dispositivos de red, como routers y switches. Así Zabbix puede ayudar
con el monitoreo y planificación de la capacidad de la red proporcionando datos
claves, tales como la utilización del tráfico de red, estado de CPU, memorias y
estados de puertos. Además, Zabbix puede controlar cualquier otro dispositivo con
un agente SNMP como dispositivos de red, sistemas de climatización y dispositivos
de energía.
4.2.5. Personalizacion: Zabbix cuenta con extensas capacidades de personalización lo
que permite integrarlo en cualquier entorno y reunir datos de cualquier sistema.
Además no existen limitaciones en los lenguajes de programacion usados, cuenta
con sus propios checkeos en Shell, Perl, Python o cualquier otro.
4.2.6. Supervisión de base de datos: Las bases de datos son unos de los pilares
informáticos fundamentales. Estas bases de datos contienen datos importantes
sobre el sistema que se monitorea. Es una necesidad crucial saber si una base de
datos está disponible, y también su forma de funcionamiento. Utilizando zabbix se
puede usar cualquier base de datos incluyendo MySql, PostgreSQL, Oracle y
Microsoft SQL Server.
4.2.7. Monitorización de hardware: Si el hardware permite el acceso de IPMI, zabbix
puede recopilar datos estadísticos tales como la temperatura, estado de disco y el
estado de los ventiladores, evitando tiempos de inactividad. Además puede
ejecutar comandos de IPMI para encender o apagar los dispositivos en la red
cuando ocurre algún problema.
4.2.8. Empresas: Zabbix está diseñado para apoyar desde pequeñas empresas a
grandes entornos empresariales.
20
4.2.9. Ampliación a grandes entornos: Zabbix está diseñado para ampliarse desde
pequeños entornos con unos pocos dispositivos hasta grandes entornos con miles
de dispositivos monitorizados. Existen instalaciones Zabbix con más de 100.000
dispositivos monitoreados, demostrando que Zabbix es capaz de procesar más de
3.000.000 de chequeos por minuto y recopilando Gigabytes de datos históricos
diarios.
4.2.10. Monitoreo distribuido: Zabbix además del modelo de servidor único
centralizado, ofrece monitorización distribuída, la cual es fácil de configurar y casi
sin necesidad de mantenimiento utilizando proxy Zabbix. El proxy Zabbix es una
solución muy robusta y está disponible hace mucho años el cual ayuda en el
monitoreo de grandes centro de datos de manera eficiente.
4.2.11. Optimizado para alto rendimiento: Además de una gran supervisión sin
agentes, el agente Zabbix ofrece un alto rendimiento para supervisar el sistema
operativo y los parámetros específicos de la aplicación.
El agente Zabbix utiliza recursos de la mínimos de la CPU y memoria, además de
ser compatible con varias plataformas, incluyendo Linux, Unix y Windows.
El servidor Zabbix y el proxy Zabbix utilizan varias soluciones de almacenamiento
en caché de datos, dándoles un gran rendimiento y reduciendo la carga en la base
de datos del Backend.
Los protocolos de comunicación de redes en uso de Zabbix son eficientes con el
uso de recursos informáticos y del uso de ancho de banda de la red, incluso en
despliegues de gran escala.
4.2.12. Alta disponibilidad: Un recurso primordial para los servicios y aplicaciones de
la empresa es la alta disponibilidad de la plataforma Zabbix, por lo que todos los
componentes de Zabbix son inmunes de la red y la comunicación, por el uso
eficiente del buffer de control de datos.
21
4.2.13. Mantenimiento: En el entorno de la empresa existen una gran cantidad de
sistemas antiguos que no se pueden remplazar o actualizar fácilmente. Forzar al
agente de supervisión que contiene a actualizarse debido a que el sistema de
supervisión lo requiere, no es justificable; Zabbix es compatible con todas las
versiones existentes de agente.
Las actualizaciones de Zabbix a la última versión estable son fáciles y no requiere
ningún cambio en la base de datos, evitando la reconfiguración de multiples archivos.
La creación de API está disponible. La creación de copias de seguridad de todos los
datos de configuración y datos es de forma sencilla, todo esto queda guardado en una
base de datos.
4.2.14. Seguridad: El acceso a la interfaz Zabbix se puede hacer a través de una
conexión protegida SSL, garantizando la seguridad entre los usuarios y el servidor.
Además la interfaz tiene una autoprotección contra ataques de fuerza bruta.
Los componentes se comunican entre si y solo aceptan las conexiones de direcciones
IP autorizadas, las otras conexiones son rechazadas automáticamente.
4.2.15. Preparado para IPv6: Con los segmentos IPv4 acabándose con gran rapidez,
los ISP están empezando a prepararse para implementar IPv6. Todos los
componentes Zabbix soportan tanto IPv4 como IPv6, lo que permite su uso en un
entorno mixto entre IPv4 e IPv6.
4.2.16. Monitoreo Proactivo: Los recursos ofrecidos por Zabbix fueron creados para
ayudar a las empresas a reducir los costos de operación, evitando los tiempos de
inactividad y mejorando la calidad de servicios
22
4.2.17. Estado de alerta: Además de la interfaz web de Zabbix
que proporciona toda
la información sobre el sistema, Zabbix puede enviar mensajes de notificación a
través de correo electrónico, SMS o Jabber (protocolo XMPP) para cada estado
alarmado.
4.2.18. Gestor de eventos: Pueden existir situaciones en las cuales una acción
automatizada puede solucionar problemas, como reiniciar un router o apagar un
servidor a través de IPMI, Zabbix puede gestionar este trabajo de forma autónoma.
4.2.19. Solucion rápida: Si la primera notificación o trabajo automatizado no fueron
suficientes para resolver un problema, se pueden usar escalamientos que
notificarán a los expertos técnicos para la gestión de la solución o ejecutar otra
acción que resuelva el problema.
4.2.20. Gestión del problema: Cuando se está trabajando en un problema, el analista
puede reconocer este problema y dejar un comentario sobre la solución. Esta
característica ayuda a mejorar el trabajo en equipo y permite una gestión de alto
nivel. El resultado de un entorno operacional controlado permite menor tiempo de
inactividad y mejora la satisfacción del cliente.
4.2.21. Información de interés: Algunos detalles sobre dispositivos, como aplicaciones,
especificaciones de hardware, ubicación, número de series y contactos pueden ser
valiosos para resolver un problema. Para esto Zabbix ofrecen una fuente dentro del
perfil del Host donde toda esta información puede ser almacenada. En las últimas
versiones esta información puede ser recopilada automáticamente.
23
4.2.22. Planificación de crecimiento: La adquisición de nuevos equipamientos pueden
demorar semanas, lo que requiere una planificación anticipada por el administrador
acerca de la utilización de recursos para los próximos meses. Con los datos obtenidos
de Zabbix, se podrá analizar con facilidad, por ejemplo, el crecimiento en la utilización
de un disco duro y saber con precisión cuando se agotará el espacio disponible.De este
modo se puede evitar la ocurrencia de eventos de carácter crítico, como el uso excesivo
de internet o el agotamiento del espacio de almacenamiento de un disco duro.
4.2.23. Residuos de recursos: Gran parte de los recursos informáticos disponibles
dentro de una empresa están sobredimensionados para la necesidad real. Por
ejemplo el uso de una red Ethernet de un Gigabit (1 Gbps) para un servidor con
una interfaz de 100Mbps. Zabbix puede detectar fácilmente los residuos de la CPU,
memoria, disco o anchos de banda, de todo el sistema monitoreado. De esta
manera se pueden reasignar las aplicaciones y equipos a utilizar mejorando la
utilización de recursos disponibles.
4.2.24. Absolutamente gratis: Zabbix es liberado bajo la licencia GPL, por lo tanto es
gratis tanto para su uso comercial y no comercial. No existen limitaciones en el
número de dispositivos monitorizados, se puede utilizar Zabbix para monitorear
miles de dispositivos totalmente gratis.
Además se puede modificar su código fuente para adaptarse al sistema, así como
también desarrollar herramientas de forma personalizadas agregando nuevas
características para Zabbix.
4.2.25. No bloqueos por provedores: El código fuente esta totalmente disponible, por
lo que el entorno informático no es dependiente de una entidad comercial. Todas
las configuraciones y datos obtenidos se almacenan de forma simple y están
totalmente disponibles, fáciles de exportar o de integrar en otros sistemas.
5 DESARROLLO PRACTICO DE IMPLEMENTACIÓN DEL SOFTWARE ZABBIX
5.1 Definición de la Red de Telefónica del Sur
Telefónica del Sur es una empresa de telecomunicaciones chilena creada en la ciudad de
Valdivia el año 1893. Los servicios que vende Telefónica del Sur actualmente son:
Telefonía.
Internet y Datos.
Televisión.
Larga Distancia.
Telefonía Móvil.
Telefónica del Sur basa el core de su red a través del protocolo MPLS, que es una tecnología
de vanguardia que permite transportar varias aplicaciones IP sobre una misma red con una gran
calidad de servicio y una amplia cobertura nacional e internacional. En una misma VPN, VPRN,
etc. Se pueden utilizar diferentes aplicaciones de voz, video o datos, eliminando de esta forma
el costo de tener múltiples redes y utilización de recursos.
El trabajo realizado en Telefónica del Sur, se basa en la red simplificada de la figura 6
24
25
Figura 6. Red ejemplo telefónica del sur.
En esta red de ejemplo contamos con 5 nodos, de los cuales 1 es llamado nodo Borde (Valdivia
1); este es el punto de entrada en la red MPLS, es decir es el enrutador entre la red MPLS y la
red de nos entrega el servicio de Televisión. Cabe destacar que este nodo se usa
exclusivamente para proveer de este tipo de tráfico a la red y no presta servicios a usuarios
finales.
El servicio de internet es algo distinto, ya que el servicio viene con el enrutamiento desde la
nube de Internet ISP y se conecta al nodo de Temuco, este nodo se conecta con los demás
nodos de la red otorgando el servicio a cada uno de ellos.
Los nodos son conectados a través de enlaces troncales de 10 Gbps.
26
El nodo de Osorno desglosa más detalladamente la red, donde va conectado un grupo de
switches y estos a la vez de un grupo de DSLAM. En los sitios donde están ubicados los
DSLAM existe un rectificador el cual cumple la función de convertir una alimentación alterna a
-48V de corriente continua, el cual alimenta equipamiento destinado a entregar servicios a los
clientes como los DSLAM, Switch, entre otros.
Los rectificadores se conectan a través de su tarjeta de comunicación a una puerta del switch
para el correspondiente monitoreo. Los enlaces entre el switch y el nodo de la red MPLS es de
1 Gbps.
En la nube de red interna Telefónica del Sur se encuentra el Firewall y el servidor de monitoreo
Zabbix. Este firewall debe de configurarse tal que permita la conectividad entre Zabbix y los
equipos a monitorear, otorgándole permisos en los puertos 161, 162 y ping, que básicamente
son los puertos ocupados para la monitorización.
Con este modelo de ejemplo nos ayudará para explicar detalladamente el funcionamiento del
trabajo realizado; este es un modelo clásico de telecomunicaciones, donde tenemos las capas
de CORE, agregación, distribución, borde y de accesos.
27
5.2 CRITERIOS DE ELECCIÓN DE LA DISTRIBUCION DE LINUX A INSTALAR COMO
SERVIDOR.
El software Zabbix necesita de un soporte operativo para ser ejecutado. Como corresponde a
un programa del tipo OpenSource, la mejor plataforma operativa para ejecutarlo es LINUX [15].
LINUX posee una enorme variedad de distribuciones estables.
Centos es una distribución Linux de clase empresarial basada en las fuentes libremente
disponibles de Red Hat Enterprise Linux. Cada versión de Centos se mantiene durante 7 años
(con sus respectivas actualizaciones de seguridad). Las versiones nuevas salen cada 2 años y
actualizadas constantemente con un ritmo aproximado de 6 meses para soporte de hardware
nuevo. Se elige Centos porque es la versión gratuita de Red Hat y es la más estable en
conceptos de servidores.
La elección de esta distribución de Linux fueron por 2 conceptos claves:
Seguridad: Linux una variante del sistema operativo UNIX, cuenta con complejos
protocolos de seguridad que le brindan una robustez no comparable con otros sistemas
operativos. Además cuenta con un nivel muy superior de seguridad comparada con
otros sistemas operativos; además opera de forma transparente, sin la necesidad de
enviar avisos o notificaciones al usuario. Pero lo más importante es que no existen virus
o códigos maliciosos que operen en Linux; el sistema de archivos es de tal robustez que
la pérdida de datos es algo que raramente ocurre.
Estabilidad y rendimiento: Linux a comparación de otros sistemas operativos es muy
difícil que llegue a un estado de congelamiento, paralizando total o parcialmente el
sistema y los procesos que conllevan. Además cabe destacar que Linux ocupa muy
pocos recursos de hardware para un funcionamiento de buena calidad.
28
5.3 INSTALACIÓN DEL SOFTWARE ZABBIX.
La instalación de la plataforma Zabbix la realizamos mediante la compilación de archivos
fuentes. A continuación se detallará paso a paso este procedimiento.
5.3.1 Vamos a la página de descarga zabbix http://www.zabbix.com/download.php, y
copiamos el link correspondiente a la versión de CentOS y la arquitectura de nuestro
servidor como se aprecia en la figura 7. Estas corresponden a la versión 6 y a una
arquitectura del tipo x86_64.
Figura 7. Obtención de la dirección de descarga.
5.3.2 Una vez obtenido el link de descarga,hacemos uso de el comando wget dentro la Shell
de nuestro servidor seguido del link de descarga entre comillas como se puede apreciar en
la figura 8.
29
Figura 8. Descarga de archivos de instalación.
5.3.3 El archivo descargado tiene el nombre “zabbix-2.2.0.tar.gz”, este archivo contiene
todas las configuraciones necesarias para la instalación. Luego se procede a descomprimir
el archivo usando el comando “tar -zxvf zabbix-2.2.0.tar.gz”. Una vez realizado este paso,
nos cambiamos de directorio de la carpeta descomprimida con el comando cd zabbix-2.2.0.
Desplegando todo el contenido con el comando ls, como se aprecia en la figura 9
Figura 9. Archivos de configuración zabbix 2.2.
5.3.4 Para poder configurar los archivos fuentes para el servidor y agente Zabbix, se debe
ejecutar el siguiente comando: ./configure --enable-server --enable-agent --with-mysql -enable-ipv6 --with-net-snmp --with-libcurl --with-libxml2
30
5.3.5 Una vez configurado los archivos Fuentes, se realiza la instalación con el comando
“make install” (el usuario debe tener los privilegios suficientes).
5.3.6 Una vez instalado el programa, se debe configurar el archivo zabbix_server.conf,
donde debemos especificar la base de datos a utilizar, usuarios y contraseñas.
5.3.7 El siguiente paso corresponde a la instalación de la interfaz web Zabbix, para esto se
necesita copiar los archivos PHP en el directorio de documentos HTML del servidor web.
Este se encuentra en el directorio /var/www/html, se crea un subdirectorio de la interfaz que
se llamara <htdocs>/zabbix y luego se procede a copiar los archivos php del archivo fuente
de instalación.
5.3.8 Una vez realizado los pasos anteriores, se abre un explorador web y se abre la
siguiente dirección http://<server_ip_or_name>/zabbix. Donde se debe especificar la
dirección IP o nombre de nuestro servidor. Al abrir la dirección web se encuentra con un
asistente de configuración final como se ve en la figura 10, donde se comprueba que la
instalación ha sido realizada de forma correcta
Figura 10. Interfaz de configuración final.
31
5.3.9 Lo siguiente es asegurarse que se cumplió con todos los prerrequisitos de instalación
para que se ejecute el programa sin problemas, como se aprecia en la figura 11.
Figura 11. Checkeo de prerrequisitos de archivos instalados.
5.3.10 El siguiente paso correspode a comprobar la base de datos creada en el servidor, en
este caso se usa MySQL. Donde se debe especificar el nombre de la base de datos, el
usuario y la password, como se puede ver en la figura 12.
32
Figura 12. Configuración de conección a la base de datos.
5.3.11 Luego de esto se introducen los detalles del servidor, donde se define el nombre del
host y el puerto a usar, los cuales son host: localhost y el puerto:10051. En la figura 13 se
detalla este paso.
Figura 13. Configuración Zabbix Server.
33
5.3.12 Luego se revisa el resumen de la configuración hecha hasta el momento. En la figura
14 se ven los detalles de la configuraciones hasta el momento.
Figura 14. Detalles de configuración en la instalación Web Zabbix.
5.3.13 Se procede a validar la configuración hecha previamente descargando el archivo de
configuración. En la figura 15, se destaca con rojo el botón para la descarga.
Figura 15. Instalacion final.
34
5.3.14 Una vez descargado el archivo, se mueve a la carpeta php de zabbix y se obtendrá la
instalación completa de forma correcta. En la figura 16 se hace un test de comprobación de
la instalación.
Figura 16. Test de comprobación correcta de Zabbix.
5.3.15 La interfaz Web de zabbix está lista para ser usada, en la cual se pedirá un Usuario y
una contraseña para poder interactuar con el programa. En la figura 17 se puede ver la
pantalla de bienvenida al programa.
Figura 17. Pantalla de bienvenida al programa.
6 DESARROLLO PRÁCTICO DEL MONITOREO
6.1 GESTIÓN DE MONITOREO DE ENERGÍA (SNMP TRAP).
En esta sección se detalla el monitoreo del sistema de energía; este sistema se basa en los
equipos rectificadores de marca Cherokee, los cuales constituyen la solución de alimentación
de los equipos zonales. Estos equipos zonales son los encargados de transportar los servicios a
los clientes. El correcto funcionamiento de los rectificadores y el riguroso monitoreo de estos,
son la clave para que los clientes puedan contar con los servicios la mayor cantidad de tiempo
posible.
Para monitorear los rectificadores se hará uso de su tarjeta de comunicaciones; esta tarjeta de
comunicaciones tiene instalado el agente snmp, el cual le da las siguientes características al
equipo:
Recupera información de identificación estándar haciendo uso referencial de RFC1213.
Envío de traps cada vez que una alarma aparece.
Cada trap contiene detalles sobre el elemento que activó la alarma en específico, y
también describiendo el estado actual de dicha alarma, la cual puede estar activa o
desactiva.
El agente SNMP se ejecuta conjuntamente con la aplicación TCP/IP de Cherokee, el cual
entrega un acceso completo a los parámetros de sistema con forma detallada.
El procedimiento de agregación de los rectificadores para el monitoreo es el siguiente:
Dirigirse a Configuration
click
en
el
cuadrado
Host Group, y se crea un nuevo grupo de host haciendo
resaltado
35
con
rojo
en
la
figura
18.
36
El nombre asignado al Host Group es Rectificadores, dentro de este grupo estarán
registrados todos los equipos rectificadores a monitorear. En la figura 19 se puede ver la
forma de configurar este etapa.
Figura 18 Apoyo visual para la creación del Host Group.
Figura 19. Configuración del Grupo de host para rectificadores.
37
Una vez creado el host group, viene la etapa de creación de cada uno de los host
correspondiente a un equipo rectificador a monitorear. Esto se hace en Configuration
H
i)
Host
Create host. Se deben definir los siguientes parámetros:
Host Name: Este parámetro sirve para poder identificar cada uno de los
rectificadores con un nombre referencial.
ii) Groups: Este parámetro ayuda a agrupar los rectificadores en un grupo específico;
esto se hace para usar Templates, tener configuraciones más ordenadas y
específicas.
iii) Agent Interfaces: Este parámetro se configura con la dirección IP del rectificador y
el puerto asociado; el cual sirve para conectarnos al rectificador por el puerto
configurado.
iv) SNMP Interfaces: Este parámetro se configura con la dirección IP del rectificador y
el puerto 161 correspondiente al protocolo SNMP. Esto servirá para poder
monitorear el rectificador bajo este protocolo.
En la figura 20 se puede ver detallamente estos parámetros configurados para un rectificador en
específico.
Figura 20. Configuración de un host rectificador en forma detallada.
38
Una vez configurado el host, es necesario agregar ítems de control para empezar a
recibir datos reales, en un ítem se debe especificar que tipo de datos se desea recibir
desde el host a monitorear. Para lograr esto se debe definir una key dentro de la
configuración del ítem, ya que con esta key se obtendra el valor deseado.
El primer ítem a configurar corresponde a un checkeo simple, esto quiere decir que no
necesita el agente instalado en el host para revisar si el servicio a monitorear está
funcionando. El servidor Zabbix es el encargado de la tramitación de las
comprobaciones simples (haciendo conexiones externas, etc). El tipo de información que
se obtendrá de la key es numérico, con los datos en formato decimal. La key
corresponde a icmp-ping, el cual hace un check si el host es accesible por el protocolo
ICMP ping, se obtienen dos posibles valores: un valor 0 que corresponde cuando la
conección mediante ICMP Ping falla y un valor 1 cuando la conección mediante ICMP
ping es exitosa. La configuración detallada del ítem se puede ver en la figura 21.
Figura 21. Configuración ítem Ping Check.
39
Cada 30 segundos Zabbix hará la consulta de ping check al host monitoreado; estos
datos se guardan en la base de datos MySQL por 16 días, gracias a esto se pueden
hacer gráficas del comportamiento de esta variable, que ayudan al análisis del equipo.
En la figura 22 se puede ver la gráfica del rectificador LN03 ubicado en la ciudad de
Concepción.
Figura 22. Gráfica de la variable ping check en el rectificador LN03 Concepción.
El siguiente paso corresponde a definir un trigger, que es una expresión lógica y que
representa el estado del sistema en este caso el estado del rectificador, en esta ocasión
el trigger devolverá un valor numérico. Para la configuración del trigger se siguen los
siguientes pasos:
(1) Ir a: Configuración
Host.
(2) Se hace click en Triggers en el menú del Host.
(3) Se hace click en crear Trigger.
(4) Se iIntroducen los parámetros del trigger.
40
En la figura 23. se muestra la configuración del trigger Ping Check. La expresión
{Rectificadores_cherokee:icmpping.last(,0)=0, compara el último valor obtenido del ítem
ping check, si este tiene un valor 0 se acciona el trigger, se le asigna una severidad de
carácter Disaster (Desastre), debido a que si no se obtienen valores de ping, el
rectificador no podrá reportar si tiene algún problema.
Figura 23. Configuración del Trigger para ítem ping check.
La etapa siguiente es monitorear los rectificadores mediantes SNMP-Trap que es lo
opuesto a las consultas por SNMP, en este caso los rectificadores envían
información y esta es recogida por Zabbix. En general, los traps se envían sobre un
cambio en la condición de funcionamiento y el agente se conecta mediante el
puerto162 para enviar dicha información (comparado con el puerto 161 usado por el
agente cuando se utilizan las consultas). El uso de traps pueden detectar problemas
que se producen en intervalos de consultas los cuales no son detectados.
Para recibir SNMP Trap en zabbix, que está diseñado para trabajar con snmptrapd y
un script llamado SNMPTT encargado de traspasar los traps a Zabbix. El flujo de
41
trabajo para recibir un traps en zabbix es mostrado en la figura 25 y detallado a
continuación:
(1) El rectificador sufre un problema el cual reporta mediante un mensaje trap.
(2) Snmptrapd recibe el mensaje.
(3) Snmptthandler se encarga de enviar el archivo desde snmptrapd hacia SNMPTT
(4) SNMPTT, analiza el receptor, el formato y escribe el trap en un nuevo archivo
llamado SNMPTrapperFile en el flujo de la figura 24.
(5) Zabbix configura un ítem utilizando la key snmptrap[ ] el cual captura el trap.
(6) Se configura un Trigger para enviar una alerta cuando aparece un trap definido
en la key del paso 5.
(7) Una vez configurado lo anterior se puede generar una acción en este caso
usaremos un visualización en en panel de control de Zabbix.
Figura 24. Diagrama funcionamiento SNMP Trap [12].
42
A continuación se detallarán los procedimientos necesarios para poder configurar los equipos
rectificadores para su respectivo monitoreo por Traps.
En esta etapa se produce la conección desde el servidor Zabbix hacia el rectificador mediante
Telnet. Como se puede apreciar en la figura 25, se define en el parámetro trapTarget2 con la
dirección de nuestro servidor, con esto se logra que cuando ocurra un evento los traps sean
enviados a la dirección ip del servidor.
Figura 25. Configuración equipos mediante Telnet.
43
Una vez definido este parámetro se debe configurar el archivo snmptrapd.conf el cual permitirá
recibir los traps enviados desde el rectificador hacia el servidor. En la figura 26 se puede ver la
configuración hecha, en la cual se definen los siguientes parámetros:
Traphandble (script para enviar los traps hacia zabbix) define snmptt.
disableAuthorization yes, con este parámetro se define que no se necesita tener
permisos de usuario root para el funcionamiento del archivo.
logOPtion f /var/log/snmptt/snmptt.log, en esta configuración se define donde se
guardarán los traps recibidos.
snmpTrapdAddr 0.0.0.0, con esta configuración se permite que el servidor reciba
cualquier trap desde cualquier servidor.
Figura 26. Configuración snmptrapd.conf.
Una vez configurado el paso anterior, se debe editar el archivo snmptt.ini. En el cual se definen
que traps se desea traducir en formato entendible por zabbix. En la figura 27 se puede ver la
configuración realizada.
44
Figura 27. Configuración archivo snmptt.ini.
Podemos recibir 4 tipos de OID en los traps, las cuales son:
.1.3.6.1.4.1.26854.3.2.3.0.1 este OID señala que aparece una alarma.Se configura para que
aparezca el encabezado “Aparece alarma” en el archivo traducido en formato ZABXTRAP.
.1.3.6.1.4.1.26854.3.2.3.0.2 este OID señala que desaparece una alarma.Se configura para que
aparezca el encabezado “Desaparece alarma” en el archivo traducido en formato ZABXTRAP.
.1.3.6.1.4.1.26854.3.2.3.0.3 este OID señala que aparece una alarma.Se configura para que
aparezca el encabezado “Aparece alarma” en el archivo traducido en formato ZABXTRAP.
.1.3.6.1.4.1.26854.3.2.3.0.4 este OID señala que desaparece una alarma.Se configura para que
aparezca el encabezado “Desaparece alarma” en el archivo traducido en formato ZABXTRAP.
45
Cada vez que los rectificadores envíen un trap, será con el formato mostrado en la figura 28.
Este archivo es complicado analizarlo y no es entendible por Zabbix, por lo que se usa el script
SNMPTT el cual traduce este traps, a uno más simple de analizar y entendible por Zabbix.
Figura 28. Trap recibido desde un rectificador sin modificaciones.
Con la configuración realizada anteriormente en el archivo snmptt.ini como se ve en la figura
27, el resultado de esto es el cambio en el formato del traps como el de la figura 28 a un traps
entendible por zabbix como el de la figura 29. En este trap se puede ver que para que aparezca
un texto con la descripción de la OID .1.3.6.1.4.1.26854.3.2.3.0.1,que significa que aparece
alarma. Este parámetro es muy relevante ya que será necesario para capturar los traps en
Zabbix.
Figura 29. Traps traducido por SNMPTT.
El siguiente paso es configurar un nuevo Item en el host del rectificador creado anteriormente.
En la figura 30 se puede ver la configuracion del ítem para poder recibir los traps en el host.
46
Figura 30. Configuración ítem trap.
En la configuración del ítem, se define el tipo de ítem el cual corresponde a SNMP trap, con la
key “general”. Esta key analiza todos los traps recibidos con la dirección IP del host que
contengan la palabra general, el tipo de información que se recibe es del tipo Log. Además se
debe configurar el formato del tiempo. Los resultados de esto lo podemos ver en la figura 31
donde vemos todos los traps recibidos en un host determinado.
Figura 31. Traps recibido por Zabbix.
47
Una vez realizadas las configuraciones del ítem, es necesario configurar un trigger para cada
tipo de trap recibido el cual corresponderá a un tipo de problema diferente. En la figura 32 se
ven los tipos de traps a recibir, los cuales tendrán severidades distintas, cuando falla un módulo
rectificador, se define una severidad de carácter informativo, cuando falla más de un
rectificador, se tendrá una severidad de carácter alto, cuando el rectificador tenga problemas
de batería en descarga, alarma externa o alarma por temperatura alta, se tendrá una severidad
de carácter medio y en los casos que se tenga Bus Low y Falla de alimentación, se define la
severidad como desastre. Las acciones a realizar en la gestión de los equipos dependerán de
las severidades mencionadas anteriormente.
Figura 32 Severidades traps.
48
6.2 GESTIÓN DE MONITOREO DEL EQUIPAMIENTO DE TV IP (SNMP).
El siguiente monitoreo corresponde al switch de marca Mikrotic [14] usado para entregar el
servicio de TV IP en las ciudades de Puerto Montt, Valdivia y Concepción, para tener una
gestión de forma óptima debemos definir los siguientes ítems de monitoreo:
Corriente.
CPU.
Nombre de Dispositivo.
Ping Check
Potencia
Voltaje
Tráficos de entradas en las puertas
Tráficos de salidas en las puertas
Temperatura del dispositivo
Temperatura del procesador
Estado del ventilador.
Cada uno de estos ítems tienen una OID diferente asociada, pero la forma de crear
los ítems
es de forma similar a las explicada anteriormente.
Una vez creados los ítems procedemos a la especificaciones de los triggers
pertinentes:
Utilización de CPU sobre 30% Average (Alarma de carácter promedio)
Utilización de CPU sobre 50% High (Alarma de carácter alto)
Pérdida de conección mediante Ping Check Disaster (Alarma de carácter desastroso)
Tráfico de entrada sobre 200 MB Average (Alarma de carácter promedio)
Tráfico de entrada sobre 700 MB High (Alarma de carácter alto)
Tráfico de salida sobre 200 MB Average (Alarma de carácter promedio)
Tráfico
de
salida
sobre
700
MB
High
(Alarma
de
carácter
alto).
7 RESULTADOS
7.1 RESULTADOS DEL MONITOREO DE LOS EQUIPOS DE ENERGÍA
La incorporación de la nueva plataforma Zabbix versión 2.2 [5], aporta con detectar los
diferentes fallos que pueden ocurrir en
los equipamientos de energía, en este caso los
rectificadores Cherokee, se tienen una totalidad de 322 equipos monitoreados. Teniendo una
gestión de alta calidad, esto nos ayuda a poder detectar el tipo de problema que puedan ocurrir
de forma rápida para su pronta solución, ya que estos equipos son una parte clave del sistema
de telecomunicaciones de TELSUR, ya que alimentan con energía a distintos dispositivos
destinados a entregar los servicios a los clientes TELSUR. En las figura 33, 34 y 35 se puede
ver como se representan las fallas de forma gráfica.
Figura 33. Cantidad de rectificadores con problemas.
Figura 34. Diferentes tipos de alarmas enviados por los rectificadores.
49
50
Figura 35. Triggers activados con problemas de Ping Check.
7.2 RESULTADOS DEL MONITOREO DEL EQUIPAMIENTO TV IP.
Zabbix, en los equipamientos Tv IP aporta con análisis de variables claves en su
funcionamiento como son la temperatura de funcionamiento del procesador en el switch Mikrotik
mostrada en la figura 36, los tráficos de entrada mostrada en la figura 37 y tráficos de salida
mostradas en la figura 38. Teniendo un control efectivo de las variables configuradas se pueden
garantizar una entrega de servicios de forma óptima y en caso de fallas poder determinar cuales
fueron las causas de ellas, ya que se registran la fecha y hora cuando ocurren, por medio de la
experiencia del personal encargado del equipamiento se pueden determinar las causantes de
dichos problemas ocurridos.
51
Figura 36. Gráfica temperatura del procesador.
Figura 37. Gráficos de entrada en la Puerta 1 del Switch mikrotik.
52
Figura 38. Gráfica de salida en la puerta 1 del switch mikrotik.
8. CONCLUSIONES
Una vez completadas las etapas de pruebas se concluye que:
Zabbix es versátil debido al uso de protocolos estándar de monitoreo en
telecomunicaciones, como SNMP y SNMP trap, lo que permite que cualquier dispositivo
que cuente con estos protocolos puedan ser monitoreados; además en aquellos equipos
que no cuenten con tales protocolos se puede instalar un agente Zabbix para
ser
monitoreados. Gracias a esto, Zabbix puede unir monitoreos de distintas plataformas
con distintas tecnologías, como por ejemplo: Switches, DSLAM, sondas de televisión,
entre otros.
Para la instalación del servidor que contenga el software Zabbix a nivel empresarial se
recomienda que tengan como características minimas 512 MB de memoria RAM y un
procesador de arquitectura i386 o x86-64.
Zabbix permite decidir que variables monitorear y cuales son los umbrales con los que
se severizan las alarmas, permitiendo fijas umbrales de carácter preventivo y humbrales
de carácter correctivo según la experiencia ganadas en las practicas de funcionamiento
de la red.
Zabbix permite realizar acciones. Estas se configuran cuando un trigger se activa
permitiendo realizar tareas programadas (SMS, Emails, Jabbers). Estas van de acuerdo
a la severidad y el tiempo en que se presentó la falla.
Zabbix es una plataforma Open Source. Esto permite realizar modificaciones en los
archivos de origen, logrando realizar mantenciones que cumplen la función para que el
software funcione de manera correcta
53
Zabbix no es recomendable almacenar datos por un largo periodo de tiempo debido al
volumen que adquiere la base de datos; lo anterior por
la cantidad de tráfico que
maneja la plataforma, esto a un mediano plazo de tiempo puede ser perjudicial para el
servidor que contiene la aplicación instalada; para este caso se recomienda exportar los
datos de interés a un servidor que esté dedicado a guardar información, para lo anterior
existen aplicaciones como CACTI.
Es recomendable usar una plataforma Linux ya que es robusto, estable y rápido.
Ademas cuenta con la gran ventaja de poseer plataformas que son totalmente gratuita lo
que redujo los costos asociados al proyecto realizado en esta ocación.
54
9. REFERENCIAS
1.
Zabbix 1.8 Network Monitoring, monitor your network’s hardware, servers and web
performance effectively and efficiently. Richard Olups, ISBN 978-1-847197-68-9.
Primera versión publicada en Abril del 2010 por Packt Publishing Ltd.
2.
http://lsi.ugr.es/rosana/docencia/turismo/Linux.pdf
3.
Redes Linux con TCP/IP - Guía Avanzada. Eyler Pat, ISBN: 8420531561, Editorial
Prentice Hall, 2001.
4.
Martinez S. Narvaez G. 2010. IMPLEMENTACIÓN DE ZABBIX COMO HERRAMIENTA
DE MONITORIZACIÓN DE INFRAESTRUTURA INFORMÁTICA DE LA COMPAÑÍA
SANTINI SYSTEM GROUP LTDA. Tesis Ing. Electronico. Bogota, Universidad Santo
Tomas.
5.
http://sandra-evelyn.blogspot.com/
6.
http://www.ietf.org/rfc/rfc1213.txt
7.
http://docstore.mik.ua/orelly/networking_2ndEd/snmp/ch02_01.htm
8.
http://www.coit.es/publicac/publbit/bit102/quees.htm
9.
http://www.ebah.com.br/content/ABAAAfctoAG/snmp
10. https://nsrc.org/workshops/2008/walc/presentaciones/gestion_traps.pdf
11. http://911-ubuntu.weebly.com/51/post/2013/03/conoce-la-estructura-de-zabbix-y-comousarlo.html
12. http://lsi.ugr.es/rosana/docencia/turismo/Linux.pdf
13. Configuración y administración de servicios en GNU/Linux paso a paso, ISBN: 978-95844-1616-2, Diego José Luís Botia Valderrama
14. https://www.zabbix.com/documentation/doku.php?id=2.2/manual
15. http://www.slideshare.net/HaruyoshiChiyoda/zabbixjp-study4-zabbix20rc1-snmp-traps
16. http://wiki.mikrotik.com/wiki/Category:Manual
55
