Universidad Austral de Chile

Facultad de Ciencias de la Ingeniera

Escuela de Ingeniera Civil Electrnica

IMPLEMENTACIN DE PLATAFORMA DE
MONITOREO ZABBIX PARA SISTEMAS DE
TELECOMUNICACIONES TELSUR
Trabajo para optar al ttulo de:
Ingeniero Civil Electrnico
Profesor Patrocinante
Sr. Jos Mardones Fernndez
Ingeniero Electrnico
Licenciado en Ciencias de la Ingeniera

MARCELO ANDRES ULLOA SOLIS

VALDIVIA CHILE
2014

DEDICATORIA

Con todo mi amor y carios ya que hicieron todo en la vida para que yo pudiera lograr mis
sueos, por motivarme, por confiar en mi, por aconsejarme y darme la mano cuando senta que
el camino se terminaba, a ustedes por siempre en mi corazn y agradecimiento Pap y Mam.
Hermana, cuado y hermosa sobrina. Mucha gracias por todos estos aos, 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 aos apoyndome tanto presencial como a
la distancia, pero muy especial a esas personas que son parte de mi corazn.
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 preocupacin en la preparacin 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 compaa.

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 ESTNDARES DE MONITOREO. .............................12
3. MONITOREO DE RED ..................................................................................................14
4. SOFTWARE ZABBIX ...................................................................................................15
4.1 CMO ES EL FUNCIONAMIENTO DEL SOFTWARE ZABBIX? ...............................16
4.2 JUSTIFICACIN DE ELECCIN DISPOSITIVO DE MONITOREO ZABBIX ...............18
5. DESARROLLO PRACTICO DE IMPLEMENTACIN DEL SOFTWARE ZABBIX ........24
5.1 Definicin de la Red de Telefnica del Sur................................................................24
5.2 CRITERIOS DE ELECCIN DE LA DISTRIBUCION DE LINUX A INSTALAR COMO
SERVIDOR ....................................................................................................................27
5.3 INSTALACIN DEL SOFTWARE ZABBIX. ................................................................28
6. DESARROLLO PRACTICO DEL MONITOREO ...........................................................35
6.1 GESTIN DE MONITOREO DE ENERGA. ..................................................................35
6.2 GESTIN DE MONITOREO DEL EQUIPAMIENTO DE TV IP. ....................................48
7. RESULTADOS ..............................................................................................................49
7.1 RESULTADOS DEL MONITOREO DE LOS EQUIPOS DE ENERGA..........................49
7.2 RESULTADOS DEL MONITOREO DEL EQUIPAMIENTO TV IP. .................................50
8. CONCLUSIONES ..........................................................................................................53
9. REFERENCIAS .............................................................................................................55

Indice de figuras

Figura 1 Ubicacin protocolo SNMP en modelo TCP /IP ............................................3

Figura 2 Subrbol MIB-II rama mgmt ...........................................................................6
Figura 3 Modelo de comunicacin TCP/IP y SNMP ...................................................10
Figura 4 Operaciones SNMP .......................................................................................12
Figura 5 Funcionamiento Zabbix ................................................................................16
Figura 6 Red ejemplo telefnica del sur. ....................................................................25
Figura 7 Obtencin de la direccin de descarga .......................................................28
Figura 8 Descarga de archivos de instalacin ...........................................................29
Figura 9 Archivos de configuracin zabbix 2.2 .........................................................29
Figura 10 Interfaz de configuracin final ....................................................................30
Figura 11 Checkeo de prerrequisitos de archivos instalados...................................31
Figura 12 Configuracin de coneccin a la base de datos .......................................32
Figura 13 Configuracin Zabbix Server ......................................................................32
Figura 14 Detalles de configuracin en la instalacin Web Zabbix .........................33
Figura 15 Instalacion final ...........................................................................................33
Figura 16 Test de comprobacin correcta de Zabbix ................................................34
Figura 17 Pantalla de bienvenida al programa ...........................................................34
Figura 18 Apoyo visual para la creacin del Host Group ..........................................36
Figura 19 Configuracin del Grupo de host para rectificadores...............................36
Figura 20 Configuracin de un host rectificador en forma detallada .......................37
Figura 21 Configuracin tem Ping Check ..................................................................38
Figura 22 Grfica de la variable ping check en el rectificador LN03 Concepcin ...39
Figura 23 Configuracin del Trigger para tem ping check .......................................40
Figura 24 Diagrama funcionamiento SNMP Trap .......................................................41
Figura 25 Configuracin equipos mediante Telnet ....................................................42
Figura 26 Configuracin snmptrapd.conf...................................................................43
Figura 27 Configuracin archivo snmptt.ini ...............................................................44
Figura 28 Trap recibido desde un rectificador sin modificaciones ..........................45
Figura 29 Traps traducido por SNMPTT .....................................................................45
Figura 30 Configuracin 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 Grfica temperatura del procesador ..........................................................51
Figura 37 Grficos de entrada en la Puerta 1 del Switch mikrotik ............................51
Figura 38 Grfica de salida en la puerta 1 del switch mikrotik .................................52

III

RESUMEN

La deteccin 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 estndar 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 aplicacin 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.

OBJETIVOS

OBJETIVOS GENERALES

Disear la aplicacin de un software de monitoreo para la red de Telefnica del Sur.

Instalar y configurar un software de monitoreo para la red sistema de
telecomunicaciones de Telefnica del Sur..
Habilitar una plataforma de software estable de monitoreo Zabbix actualizada.
Identificar las variables crticas, menos crticas y no importantes en la capa de
distribucin del sistema de telecomunicaciones para la mantencin 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 monitorizacin va Traps.
Crear triggers eficientes para un correcto monitoreo.
Verificar la correcta aplicacin del software Zabbbix para el monitoreo de la red de
Telefnica 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 Telefnica del Sur. Debido a la amplitud de la red, los costos de
mantencin 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 rpida. Adems tienen
una importancia prioritaria para ofrecer altos estndares de confiabilidad y disponibilidad a los
clientes.

Una accin de monitoreo exitosa requiere de un diseo de ingeniera previo que seale donde y
como se efectuaran las acciones de recopilaccion de datos, clasificacin de ellos y toma de
decisiones para efectuar labores correctivas asi mismo, la ingeniera del diseo permitir definir
criterios de mantencin preventiva basados en el almacenamiento y post procesamiento de los
datos recogidos por el sistema de monitoreo.

Poder montar una solucin de monitero que sea efectiva y eficaz a la vez, requiere mucha
dedicacin por parte del personal encargado, ya que se deben analizar y configurar muchos
parmetros.

El software Zabbix [1] es una plataforma Open Source de gran calidad y factible
econmicamente 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 mximo el uso del software. Una de las caractersticas importantes es que es un
software libre y no se necesitan costos de licenciamiento para su manejo.

Cada equipamiento posee su propio sistema de monitoreo establecido, el cual rara vez se
puede configurar segn las necesidades del usuario.
El desarrollo del presente trabajo se organiza de la siguiente forma: En el captulo 2 se describe
las caractersticas del protocolo SNMP. En el captulo 3 se define que es un monitoreo de red.
En el captulo 4 se da a conocer las caractersticas del software Zabbix. En el captulo 5 se
describe la implementacin del software zabbix. En el captulo 6 se da a conocer los resultados
de la ejecucin del monitoreo. En el captulo 7 se muestran los resultados obtenidos en el
proceso de monitoreo. Finalmente, en el captulo 8 se entregan las conclusiones.

2 SNMP

Simple Network Management Protocol (SNMP) es un protocolo perteneciente a la capa de

aplicacin correspondiente al sptimo nivel del modelo OSI es definido por la IAB (Internet
Architecture Board) en la RFC 1157 para el intercambio de informacin de administracin entre
dispositivos de red. Este protocolo posee un conjunto de aplicaciones de gestin 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. Ubicacin protocolo SNMP en modelo TCP /IP.

SNMP en la actualidad es uno de los protocolos ampliamente usado para la gestin 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 gestin de red (NMS)

2.1 COMPONENTES BSICOS SNMP

Una red administrada con SNMP contiene 4 componentes bsicos fundamentales

Administrador SNMP

Dispositivos Administrados

Agente SNMP

Base de datos informacin de gestin (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 ms importantes de un Administrador SNMP son las siguientes:

Consultas al agente

Obtener las respuestas de los agentes

Establece las variables de agentes

Reconoce eventos asncronos de los agentes.

Dispositivos gestionados: Un dispositivo gestionado, es una parte de la red que requiere

algn tipo de monitoreo y gestin 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 gestin del dispositivo a nivel local y hace posible que el
administrador SNMP pueda realizar consultas. Estos agentes pueden ser estndar o
especficos de un proveedor.

Las funciones ms importantes de un agente SNMP son:

Recopilar informacin de gestin.

Almacenar y recuperar informacin que se definen en la MIB.

Informar un evento al Administrador SNMP.

Actuar como Proxy para algn nodo de la red que no manejable con SNMP

Base de datos informacin de gestion (MIB): Cada uno de los agentes SNMP contiene una
base de datos de informacin que describen los parmetros de los dispositivos monitoreados. El
administrador SNMP utiliza esta base de datos para solicitar al agente obtener informacin
especfica y enva la informacin necesaria para el sistema de gestin de red. Esta base de
datos comn 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, segn se
definen en la MIB. Esto permite que el administrador SNMP este al tanto de las preguntas
estndar y privadas que tiene cada agente.

Las MIB son colecciones de informacin para la gestin de los elementos de la red. Estas
estn compuestas por identificadores de nombre de objetos (OID).

Cada uno de estos identificadores es nico y denota las caractersticas especficas de un

dispositivo. Estos valores de los identificadores pueden ser del tipo Texto, Numrico,
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
definicin de la estructura del rbol de MIB se encuentra en el mdulo RFC1155-SMI [7]
(Structure Management Information), junto con las declaraciones de tipos utilizados en las MIB.

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 gestin como:
informacin del sistema, interfaces, protocolos, etc. La importancia que tiene la MIB-II, es que
cada dispositivo que soporta SNMP tambin debe contener la MIB-II lo cual la convierte en un
estndar 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 numrico). En la figura 2. Se muestra la estructura del subrbol MIB-II de la rama
mgmt.

Figura 2. Subrbol MIB-II rama mgmt.

2.2 MIB-II

La MIB-II es la base de datos comn para gestin de equipos. Est definida originalmente en la
RFC 1213. Con la aparicin 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 Transmisin
Grupo SNMP

Un breve resumen del contenido de los grupos contenidos en la MIB-II se da a continuacin:

Grupo System (1.3.6.1.2.1.1): Este grupo proporciona informacin 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 informacin sobre la configuracin y
estadsticas de eventos sobre las interfaces de red en una entidad gestionada. Este
grupo monitoriza que interfaces estn cadas o levantadas y registra cada dato como
octetos enviados y recibidos, errores, etc.

Grupo at (1.3.6.1.2.1.3): Este grupo es el encargado de la traduccin 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 informacin 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 informacin 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 informacin sobre las
conexiones UDP tanto en la operacin e implementacin. Registrando las
estadsticas asociadas como: datagramas de entrada, datagramas de salida, etc.
Grupo EGP (1.3.6.1.2.1.8): Este grupo contiene informacin sobre la operacin e
implementacin de EGP (exterior gateway procotolo) en el nodo gestionado.
Grupo transmisin (1.3.6.1.2.1.9): Este grupo mantiene informacin relevante
sobre el sistema fsico 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 implementacin SNMP registrando datos como por ejemplo el
nmero de paquetes SNMP que sean enviado y recibido.

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 estndar en las comunicaciones
para intercambiar informacin entre gestores y agentes. Se elige UDP sobre TCP (Transmission
Control Protocol) porque este tipo de protocolo no es orientado a la conexin, esto quiere decir,
que no se establece una conexin extremo a extremo entre el agente y el gestor cuando los
paquetes (datagramas) se envan 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 aplicacin ya que se determinan si estos datagramas se perdieron ( timeout) y
poder realizar una retransmisin si as se desea. El funcionamiento se basa en que el gestor
enva una peticin UDP a un agente y espera una respuesta a dicha peticin. Si no existe
respuesta a dicha peticin (timeout) y el gestor no recibe datos se asume que el paquete se
perdi y se vuelve a retransmitir la peticin, se pueden hacer una configuracin con un nmero
mximo 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 transmisin,
lo que logra un impacto mnimo al rendimiento de la red.

Cuando usamos SNMP-Trap necesitamos tener una comprobacin de que el agente enva 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 configuracin del
agente. En caso que se realice algn cambio de puertos, se debe configurar el sistema gestor
con los cambios realizados para poder realizar las consultas pertinentes.

10

Figura 3. Modelo de comunicacin 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 operacin SNMP (Una peticin o Trap como
ejemplo), se producen una serie de eventos en la pila de protocolos.

Aplicacin: La aplicacin SNMP (Agente o gestor) toma una decisin de que accin 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 podra ser un operario que
est encargado del monitoreo de cierto servicio va mensajes traps.

UDP: Esta etapa est encargada de la comunicacin entre 2 hosts. Dentro de la

cabecera UDP se encuentra el puerto de destino del dispositivo al que se envan 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 direccin IP.

11

Control de Acceso al Medio (MAC): La ltima etapa que sucede con el envo del
paquete SNMP es llegar a su destino, para ello es necesario llegar a la red fsica, donde
se enruta con el direccionamiento del destino final. La capa MAC es responsable de
recibir los paquetes de la red fsica y devolverlos a la pila de protocolos de forma que
puedan ser procesador por la capa de aplicacin.

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 peticin especfica de la MIB del agente.

Get-Next-Request: El gestor realiza una peticin 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 enva un mensaje informando sobre algn suceso no habitual

predefinido.

12

Figura 4. Operaciones SNMP.

2.5 VERSIONES SNMP Y OTROS ESTNDARES DE MONITOREO.

SNMP versin 1 (SNMPv1) versin estndar del protocolo SNMP definida en su totalidad en la
RFC 1157. La seguridad utilizada en esta versin est basada en comunidades. Esta versin
fue diseada a mediados de los aos 80, y cumpla con el rol de ser una solucin temporal para
la gestin de redes a la espera de protocolos con mejor diseo y ms completos; el intercambio
de informacin es basada en mensajes PDU.

SNMP V2, en esta versin se adicionan mejoras importantes referentes a la cantidad de cargo
adicional en el uso del monitoreo, solucionando problemas relacionados con monitorizacin
remota o distribuida. Creada en el ao 1993 y revisada en 1995, aadindole protocolos de
seguridad , donde las variables son definidas con ms detalles, adems se le aaden
estructuras en la tabla de datos para facilitar el manejo de los datos obtenidos.

SNMP V3, esta versin fue desarrollada en el ao 1998, donde se le agregan parmetros de
seguridad, las cuales son:

Integridad de mensajes: Asegura que el paquete de datos no haya sido modificado

durante la transmisin.

13

Autentificacin: Determina que el mensaje enviado proviene de una fuente vlida.

Encriptacin: El paquete de datos es encriptado en su contenido para aadir una capa

de seguridad como forma de prevencin.

Tambin existen otros protocolos de gestin de red, como CMIS/CMIP. Las diferencias
principales radican en que SNMP es utilizado para la gestin de red internet (TCP/IP) y
CMIS/CMIP es utilizado en la gestin de redes OSI. El protocolo CMIP es un sistema de
gestin 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 monitorizacin 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, trficos de entrada y salida,
entre otros. Todos estos datos permiten identificar y resolver cualquier error crtico antes que
afecte los procesos de negocios. La finalidad es crear alarmas automticas que informen de
estados crticos al grupo tcnico para poder tomar decisiones basadas en anlisis y
experiencias previas. El objetivo final es que los problemas se resuelvan rpidamente sin que el
usuario final se vea afectado.

Este proceso de monitoreo debe ser permanente, ordenado y exacto. Para poder identificar que
variables crticas constituyen la estabilidad de la red y servicios asociados, para tomar acciones
de carcter preventivo y correctivo.

Tener un buen sistema de monitoreo constituyen una buena inversin, ya que evita grandes
costos de mantencin correctiva de los equipos y sobre dimensionar la cantidad de personal
para la operacin de la red. La respuesta anticipada a problemas y la prevencin 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 diseado 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 caractersticas de Zabbix son las siguientes:

Alto rendimiento y alta capacidad de monitoreo de distintos dispositivos.

Monitoreo centralizado a travs de un administrador web.

Alta capacidad de anlisis de servicios prestados.

La instalacin de agentes se puede realizar en cualquier sistema operativo.

Capacidad para monitorear directamente con protocolo SNMP (v1, 2 y 3) y dispositivos

IPMI.

Construccin de grficos y opciones de visualizacin.

Notificaciones que permiten una fcil integracin de sistemas.

Configuracin flexible, incluyendo la creacin de plantillas.

Permite el uso de script externos.

Entre otras caractersticas que permiten un sistema de monitorizacin sofisticado.

15

16

4.1 CMO ES EL FUNCIONAMIENTO DEL SOFTWARE ZABBIX?

La aplicacin Zabbix [3] se instala en un servidor Linux [13] el cual tiene como

funcin

recolectar informacin. Adems Zabbix proporciona una interfaz Web en la cual se presentan de
forma grfica toda la informacin que se recolect.

Zabbix almacena la informacin entregada por los agentes SNMP de los dispositivos
monitoreados. Esta informacin puede ser accesada a travs de la interfaz grfica que queda
instalada en el servidor Zabbix.

Los agentes una vez que son instalados en los dispositivos, estn a la espera de las rdenes
del servidor Zabbix. Los agentes solo envan la informacin 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 Instalacin del Agente Zabbix en el equipo a monitorear (servidores o estacin 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 travs de la herramienta de administracin web

(FrontEnd), se deben registrar los equipos y dispositivos destinados a la monitorizacin.

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 mdulos encargados de recoger datos del Host y en caso del hardware son los
datos recogidos del dispositivo.

4.1.5 Los Items utilizan parmetros de zabbix llamados Keys, estos nos permiten indicar
que tipo de informacin 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 informacin 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 mdulos 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

administracin web, permitiendo mostrar grficamente las alarmas generadas.

4.1.8 Zabbix, tiene la capacidad de poder genera eventos como enviar correos
electrnicos, SMS o ejecutar algn script cuando algn tem sobrepasa un parmetro
definido. Esto son eventos son definidos en los triggers.

4.2 JUSTIFICACIN DE ELECCIN DISPOSITIVO DE MONITOREO ZABBIX

Existen muchas razones para elegir zabbix como solucin de monitoreo sobre otras
plataformas. Las caractersticas ms importantes de la plataforma son las siguientes:

4.2.1. Capacidad de monitoreo: Utilizando Zabbix podemos fcilmente controlar los

servidores, dispositivos de red y aplicaciones, con una recoleccin de estadsticas
precisas de los datos.

4.2.2. Rendimiento: Monitoreo de las variables de rendimiento como CPU, memoria,

red, espacio de disco, se pueden lograr fcilmente con el agente Zabbix, el cual
est disponible para Linux, Unix y Windows. Este es un proceso nativo y no
requiere un entorno especfico, como Java o .NET.

4.2.3. Supervisin 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 estndar, tales como correo
electrnico o servidores sin necesidad de instalar ningn 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 planificacin de la capacidad de la red proporcionando datos
claves, tales como la utilizacin del trfico de red, estado de CPU, memorias y
estados de puertos. Adems, Zabbix puede controlar cualquier otro dispositivo con
un agente SNMP como dispositivos de red, sistemas de climatizacin y dispositivos
de energa.

4.2.5. Personalizacion: Zabbix cuenta con extensas capacidades de personalizacin lo

que permite integrarlo en cualquier entorno y reunir datos de cualquier sistema.
Adems no existen limitaciones en los lenguajes de programacion usados, cuenta
con sus propios checkeos en Shell, Perl, Python o cualquier otro.

4.2.6. Supervisin de base de datos: Las bases de datos son unos de los pilares
informticos 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 tambin su forma de funcionamiento. Utilizando zabbix se
puede usar cualquier base de datos incluyendo MySql, PostgreSQL, Oracle y
Microsoft SQL Server.

4.2.7. Monitorizacin de hardware: Si el hardware permite el acceso de IPMI, zabbix

puede recopilar datos estadsticos tales como la temperatura, estado de disco y el
estado de los ventiladores, evitando tiempos de inactividad. Adems puede
ejecutar comandos de IPMI para encender o apagar los dispositivos en la red
cuando ocurre algn problema.

4.2.8. Empresas: Zabbix est diseado para apoyar desde pequeas empresas a
grandes entornos empresariales.

20

4.2.9. Ampliacin a grandes entornos: Zabbix est diseado para ampliarse desde
pequeos entornos con unos pocos dispositivos hasta grandes entornos con miles
de dispositivos monitorizados. Existen instalaciones Zabbix con ms de 100.000
dispositivos monitoreados, demostrando que Zabbix es capaz de procesar ms de
3.000.000 de chequeos por minuto y recopilando Gigabytes de datos histricos
diarios.

4.2.10. Monitoreo distribuido: Zabbix adems del modelo de servidor nico

centralizado, ofrece monitorizacin distribuda, la cual es fcil de configurar y casi
sin necesidad de mantenimiento utilizando proxy Zabbix. El proxy Zabbix es una
solucin muy robusta y est disponible hace mucho aos el cual ayuda en el
monitoreo de grandes centro de datos de manera eficiente.

4.2.11. Optimizado para alto rendimiento: Adems de una gran supervisin sin
agentes, el agente Zabbix ofrece un alto rendimiento para supervisar el sistema
operativo y los parmetros especficos de la aplicacin.

El agente Zabbix utiliza recursos de la mnimos de la CPU y memoria, adems 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, dndoles un gran rendimiento y reduciendo la carga en la base
de datos del Backend.
Los protocolos de comunicacin de redes en uso de Zabbix son eficientes con el
uso de recursos informticos 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 comunicacin, 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 fcilmente. Forzar al
agente de supervisin que contiene a actualizarse debido a que el sistema de
supervisin lo requiere, no es justificable; Zabbix es compatible con todas las
versiones existentes de agente.
Las actualizaciones de Zabbix a la ltima versin estable son fciles y no requiere
ningn cambio en la base de datos, evitando la reconfiguracin de multiples archivos.
La creacin de API est disponible. La creacin de copias de seguridad de todos los
datos de configuracin 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 travs de una

conexin protegida SSL, garantizando la seguridad entre los usuarios y el servidor.
Adems la interfaz tiene una autoproteccin 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 automticamente.

4.2.15. Preparado para IPv6: Con los segmentos IPv4 acabndose con gran rapidez,
los ISP estn 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 operacin, evitando los tiempos de
inactividad y mejorando la calidad de servicios

22

4.2.17. Estado de alerta: Adems de la interfaz web de Zabbix

que proporciona toda

la informacin sobre el sistema, Zabbix puede enviar mensajes de notificacin a

travs de correo electrnico, SMS o Jabber (protocolo XMPP) para cada estado
alarmado.

4.2.18. Gestor de eventos: Pueden existir situaciones en las cuales una accin
automatizada puede solucionar problemas, como reiniciar un router o apagar un
servidor a travs de IPMI, Zabbix puede gestionar este trabajo de forma autnoma.

4.2.19. Solucion rpida: Si la primera notificacin o trabajo automatizado no fueron

suficientes para resolver un problema, se pueden usar escalamientos que
notificarn a los expertos tcnicos para la gestin de la solucin o ejecutar otra
accin que resuelva el problema.

4.2.20. Gestin del problema: Cuando se est trabajando en un problema, el analista

puede reconocer este problema y dejar un comentario sobre la solucin. Esta
caracterstica ayuda a mejorar el trabajo en equipo y permite una gestin de alto
nivel. El resultado de un entorno operacional controlado permite menor tiempo de
inactividad y mejora la satisfaccin del cliente.

4.2.21. Informacin de inters: Algunos detalles sobre dispositivos, como aplicaciones,

especificaciones de hardware, ubicacin, nmero 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 informacin puede ser almacenada. En las ltimas
versiones esta informacin puede ser recopilada automticamente.

23

4.2.22. Planificacin de crecimiento: La adquisicin de nuevos equipamientos pueden

demorar semanas, lo que requiere una planificacin anticipada por el administrador
acerca de la utilizacin de recursos para los prximos meses. Con los datos obtenidos
de Zabbix, se podr analizar con facilidad, por ejemplo, el crecimiento en la utilizacin
de un disco duro y saber con precisin cuando se agotar el espacio disponible.De este
modo se puede evitar la ocurrencia de eventos de carcter crtico, 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 informticos disponibles

dentro de una empresa estn 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 fcilmente 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
utilizacin 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
nmero de dispositivos monitorizados, se puede utilizar Zabbix para monitorear
miles de dispositivos totalmente gratis.
Adems se puede modificar su cdigo fuente para adaptarse al sistema, as como
tambin desarrollar herramientas de forma personalizadas agregando nuevas
caractersticas para Zabbix.

4.2.25. No bloqueos por provedores: El cdigo fuente esta totalmente disponible, por
lo que el entorno informtico no es dependiente de una entidad comercial. Todas
las configuraciones y datos obtenidos se almacenan de forma simple y estn
totalmente disponibles, fciles de exportar o de integrar en otros sistemas.

5 DESARROLLO PRACTICO DE IMPLEMENTACIN DEL SOFTWARE ZABBIX

5.1 Definicin de la Red de Telefnica del Sur

Telefnica del Sur es una empresa de telecomunicaciones chilena creada en la ciudad de

Valdivia el ao 1893. Los servicios que vende Telefnica del Sur actualmente son:

Telefona.

Internet y Datos.

Televisin.

Larga Distancia.

Telefona Mvil.

Telefnica del Sur basa el core de su red a travs del protocolo MPLS, que es una tecnologa
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 mltiples redes y utilizacin de recursos.

El trabajo realizado en Telefnica del Sur, se basa en la red simplificada de la figura 6

24

25

Figura 6. Red ejemplo telefnica 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 Televisin. Cabe destacar que este nodo se usa
exclusivamente para proveer de este tipo de trfico 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 dems
nodos de la red otorgando el servicio a cada uno de ellos.

Los nodos son conectados a travs de enlaces troncales de 10 Gbps.

26

El nodo de Osorno desglosa ms detalladamente la red, donde va conectado un grupo de

switches y estos a la vez de un grupo de DSLAM. En los sitios donde estn ubicados los
DSLAM existe un rectificador el cual cumple la funcin de convertir una alimentacin 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 travs de su tarjeta de comunicacin 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 Telefnica 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, otorgndole permisos en los puertos 161, 162 y ping, que bsicamente
son los puertos ocupados para la monitorizacin.

Con este modelo de ejemplo nos ayudar para explicar detalladamente el funcionamiento del
trabajo realizado; este es un modelo clsico de telecomunicaciones, donde tenemos las capas
de CORE, agregacin, distribucin, borde y de accesos.

27

5.2 CRITERIOS DE ELECCIN 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 distribucin Linux de clase empresarial basada en las fuentes libremente
disponibles de Red Hat Enterprise Linux. Cada versin de Centos se mantiene durante 7 aos
(con sus respectivas actualizaciones de seguridad). Las versiones nuevas salen cada 2 aos y
actualizadas constantemente con un ritmo aproximado de 6 meses para soporte de hardware
nuevo. Se elige Centos porque es la versin gratuita de Red Hat y es la ms estable en
conceptos de servidores.

La eleccin de esta distribucin 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. Adems cuenta con un nivel muy superior de seguridad comparada con
otros sistemas operativos; adems opera de forma transparente, sin la necesidad de
enviar avisos o notificaciones al usuario. Pero lo ms importante es que no existen virus
o cdigos maliciosos que operen en Linux; el sistema de archivos es de tal robustez que
la prdida de datos es algo que raramente ocurre.

Estabilidad y rendimiento: Linux a comparacin de otros sistemas operativos es muy

difcil que llegue a un estado de congelamiento, paralizando total o parcialmente el
sistema y los procesos que conllevan. Adems cabe destacar que Linux ocupa muy
pocos recursos de hardware para un funcionamiento de buena calidad.

28

5.3 INSTALACIN DEL SOFTWARE ZABBIX.

La instalacin de la plataforma Zabbix la realizamos mediante la compilacin de archivos
fuentes. A continuacin se detallar paso a paso este procedimiento.

5.3.1 Vamos a la pgina de descarga zabbix http://www.zabbix.com/download.php, y

copiamos el link correspondiente a la versin de CentOS y la arquitectura de nuestro
servidor como se aprecia en la figura 7. Estas corresponden a la versin 6 y a una
arquitectura del tipo x86_64.

Figura 7. Obtencin de la direccin 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 instalacin.

5.3.3 El archivo descargado tiene el nombre zabbix-2.2.0.tar.gz, este archivo contiene

todas las configuraciones necesarias para la instalacin. 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 configuracin 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 instalacin 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 contraseas.

5.3.7 El siguiente paso corresponde a la instalacin 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 instalacin.

5.3.8 Una vez realizado los pasos anteriores, se abre un explorador web y se abre la
siguiente direccin http://<server_ip_or_name>/zabbix. Donde se debe especificar la
direccin IP o nombre de nuestro servidor. Al abrir la direccin web se encuentra con un
asistente de configuracin final como se ve en la figura 10, donde se comprueba que la
instalacin ha sido realizada de forma correcta

Figura 10. Interfaz de configuracin final.

31

5.3.9 Lo siguiente es asegurarse que se cumpli con todos los prerrequisitos de instalacin
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. Configuracin de coneccin 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. Configuracin Zabbix Server.

33

5.3.12 Luego se revisa el resumen de la configuracin hecha hasta el momento. En la figura

14 se ven los detalles de la configuraciones hasta el momento.

Figura 14. Detalles de configuracin en la instalacin Web Zabbix.

5.3.13 Se procede a validar la configuracin hecha previamente descargando el archivo de

configuracin. En la figura 15, se destaca con rojo el botn 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
instalacin completa de forma correcta. En la figura 16 se hace un test de comprobacin de
la instalacin.

Figura 16. Test de comprobacin 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 contrasea 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 PRCTICO DEL MONITOREO

6.1 GESTIN DE MONITOREO DE ENERGA (SNMP TRAP).

En esta seccin se detalla el monitoreo del sistema de energa; este sistema se basa en los
equipos rectificadores de marca Cherokee, los cuales constituyen la solucin de alimentacin
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 caractersticas al
equipo:

Recupera informacin de identificacin estndar haciendo uso referencial de RFC1213.

Envo de traps cada vez que una alarma aparece.

Cada trap contiene detalles sobre el elemento que activ la alarma en especfico, y
tambin describiendo el estado actual de dicha alarma, la cual puede estar activa o
desactiva.

El agente SNMP se ejecuta conjuntamente con la aplicacin TCP/IP de Cherokee, el cual

entrega un acceso completo a los parmetros de sistema con forma detallada.

El procedimiento de agregacin 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 estarn

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 creacin del Host Group.

Figura 19. Configuracin del Grupo de host para rectificadores.

37

Una vez creado el host group, viene la etapa de creacin 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 parmetros:

Host Name: Este parmetro sirve para poder identificar cada uno de los
rectificadores con un nombre referencial.

ii) Groups: Este parmetro ayuda a agrupar los rectificadores en un grupo especfico;
esto se hace para usar Templates, tener configuraciones ms ordenadas y
especficas.
iii) Agent Interfaces: Este parmetro se configura con la direccin IP del rectificador y
el puerto asociado; el cual sirve para conectarnos al rectificador por el puerto
configurado.
iv) SNMP Interfaces: Este parmetro se configura con la direccin 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 parmetros configurados para un rectificador en
especfico.

Figura 20. Configuracin 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
configuracin 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 tramitacin de las
comprobaciones simples (haciendo conexiones externas, etc). El tipo de informacin que
se obtendr de la key es numrico, 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
coneccin mediante ICMP Ping falla y un valor 1 cuando la coneccin mediante ICMP
ping es exitosa. La configuracin detallada del tem se puede ver en la figura 21.

Figura 21. Configuracin 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 das, gracias a esto se pueden
hacer grficas del comportamiento de esta variable, que ayudan al anlisis del equipo.
En la figura 22 se puede ver la grfica del rectificador LN03 ubicado en la ciudad de
Concepcin.

Figura 22. Grfica de la variable ping check en el rectificador LN03 Concepcin.

El siguiente paso corresponde a definir un trigger, que es una expresin lgica y que
representa el estado del sistema en este caso el estado del rectificador, en esta ocasin
el trigger devolver un valor numrico. Para la configuracin del trigger se siguen los
siguientes pasos:

(1) Ir a: Configuracin

Host.

(2) Se hace click en Triggers en el men del Host.

(3) Se hace click en crear Trigger.
(4) Se iIntroducen los parmetros del trigger.

40

En la figura 23. se muestra la configuracin del trigger Ping Check. La expresin

{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
carcter Disaster (Desastre), debido a que si no se obtienen valores de ping, el
rectificador no podr reportar si tiene algn problema.

Figura 23. Configuracin 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 envan
informacin y esta es recogida por Zabbix. En general, los traps se envan sobre un
cambio en la condicin de funcionamiento y el agente se conecta mediante el
puerto162 para enviar dicha informacin (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 diseado 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

continuacin:
(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 accin en este caso
usaremos un visualizacin en en panel de control de Zabbix.

Figura 24. Diagrama funcionamiento SNMP Trap [12].

42

A continuacin se detallarn los procedimientos necesarios para poder configurar los equipos
rectificadores para su respectivo monitoreo por Traps.

En esta etapa se produce la coneccin desde el servidor Zabbix hacia el rectificador mediante
Telnet. Como se puede apreciar en la figura 25, se define en el parmetro trapTarget2 con la
direccin de nuestro servidor, con esto se logra que cuando ocurra un evento los traps sean
enviados a la direccin ip del servidor.

Figura 25. Configuracin equipos mediante Telnet.

43

Una vez definido este parmetro 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
configuracin hecha, en la cual se definen los siguientes parmetros:

Traphandble (script para enviar los traps hacia zabbix) define snmptt.

disableAuthorization yes, con este parmetro 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 configuracin se define donde se

guardarn los traps recibidos.

snmpTrapdAddr 0.0.0.0, con esta configuracin se permite que el servidor reciba

cualquier trap desde cualquier servidor.

Figura 26. Configuracin 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
configuracin realizada.

44

Figura 27. Configuracin 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 seala 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 seala 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 seala 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 seala 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 enven 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 ms simple de analizar y entendible por Zabbix.

Figura 28. Trap recibido desde un rectificador sin modificaciones.

Con la configuracin 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 descripcin de la OID .1.3.6.1.4.1.26854.3.2.3.0.1,que significa que aparece
alarma. Este parmetro 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. Configuracin tem trap.

En la configuracin 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 direccin IP del host que
contengan la palabra general, el tipo de informacin que se recibe es del tipo Log. Adems 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 tendrn severidades distintas, cuando falla un mdulo
rectificador, se define una severidad de carcter informativo, cuando falla ms de un
rectificador, se tendr una severidad de carcter alto, cuando el rectificador tenga problemas
de batera en descarga, alarma externa o alarma por temperatura alta, se tendr una severidad
de carcter medio y en los casos que se tenga Bus Low y Falla de alimentacin, se define la
severidad como desastre. Las acciones a realizar en la gestin de los equipos dependern de
las severidades mencionadas anteriormente.

Figura 32 Severidades traps.

48

6.2 GESTIN 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 Concepcin, para tener una
gestin de forma ptima debemos definir los siguientes tems de monitoreo:
Corriente.
CPU.
Nombre de Dispositivo.
Ping Check
Potencia
Voltaje
Trficos de entradas en las puertas
Trficos 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:

Utilizacin de CPU sobre 30% Average (Alarma de carcter promedio)

Utilizacin de CPU sobre 50% High (Alarma de carcter alto)
Prdida de coneccin mediante Ping Check Disaster (Alarma de carcter desastroso)
Trfico de entrada sobre 200 MB Average (Alarma de carcter promedio)
Trfico de entrada sobre 700 MB High (Alarma de carcter alto)
Trfico de salida sobre 200 MB Average (Alarma de carcter promedio)
Trfico

de

salida

sobre

700

MB

High

(Alarma

de

carcter

alto).

7 RESULTADOS
7.1 RESULTADOS DEL MONITOREO DE LOS EQUIPOS DE ENERGA

La incorporacin de la nueva plataforma Zabbix versin 2.2 [5], aporta con detectar los
diferentes fallos que pueden ocurrir en

los equipamientos de energa, en este caso los

rectificadores Cherokee, se tienen una totalidad de 322 equipos monitoreados. Teniendo una
gestin de alta calidad, esto nos ayuda a poder detectar el tipo de problema que puedan ocurrir
de forma rpida para su pronta solucin, ya que estos equipos son una parte clave del sistema
de telecomunicaciones de TELSUR, ya que alimentan con energa 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 grfica.

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 anlisis de variables claves en su

funcionamiento como son la temperatura de funcionamiento del procesador en el switch Mikrotik
mostrada en la figura 36, los trficos de entrada mostrada en la figura 37 y trficos 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. Grfica temperatura del procesador.

Figura 37. Grficos de entrada en la Puerta 1 del Switch mikrotik.

52

Figura 38. Grfica de salida en la puerta 1 del switch mikrotik.

8. CONCLUSIONES
Una vez completadas las etapas de pruebas se concluye que:

Zabbix es verstil debido al uso de protocolos estndar de monitoreo en

telecomunicaciones, como SNMP y SNMP trap, lo que permite que cualquier dispositivo
que cuente con estos protocolos puedan ser monitoreados; adems 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 tecnologas, como por ejemplo: Switches, DSLAM, sondas de televisin,
entre otros.

Para la instalacin del servidor que contenga el software Zabbix a nivel empresarial se
recomienda que tengan como caractersticas 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 carcter preventivo y humbrales
de carcter correctivo segn 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 funcin 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 trfico que

maneja la plataforma, esto a un mediano plazo de tiempo puede ser perjudicial para el
servidor que contiene la aplicacin instalada; para este caso se recomienda exportar los
datos de inters a un servidor que est dedicado a guardar informacin, para lo anterior
existen aplicaciones como CACTI.

Es recomendable usar una plataforma Linux ya que es robusto, estable y rpido.

Ademas cuenta con la gran ventaja de poseer plataformas que son totalmente gratuita lo
que redujo los costos asociados al proyecto realizado en esta ocacin.

54

9. REFERENCIAS

1.

Zabbix 1.8 Network Monitoring, monitor your networks hardware, servers and web
performance effectively and efficiently. Richard Olups, ISBN 978-1-847197-68-9.
Primera versin 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 - Gua Avanzada. Eyler Pat, ISBN: 8420531561, Editorial
Prentice Hall, 2001.

4.

Martinez S. Narvaez G. 2010. IMPLEMENTACIN DE ZABBIX COMO HERRAMIENTA

DE MONITORIZACIN DE INFRAESTRUTURA INFORMTICA DE LA COMPAA
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. Configuracin y administracin de servicios en GNU/Linux paso a paso, ISBN: 978-95844-1616-2, Diego Jos Lus 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