UNIVERSIDAD DE SANTIAGO DE CHILE

FACULTAD DE TECNOLOGÍA

UNIDAD ACADÉMICA DE TECNOLOGÍAS INDUSTRIALES

TÍTULO

SISTEMA DE MONITOREO DE RED ZABBIX

AUTOR:

JOSIAS JONATHAN POZO AROCA

PROFESOR GUÍA:

DR. ARTURO RODRÍGUEZ GARCÍA

PROPÓSITO:

Optar a Título de Tecnólogo en Telecomunicaciones

Santiago-Chile

2014
ii
© Josias Jonathan Pozo Aroca

Se autoriza la reproducción parcial o total de esta obra con fines académicos,

por cualquier forma, medio o procedimiento, siempre y cuando se incluya la
cita bibliográfica del documento.

iii
 Dedicatoria

oYe teEEEerkiooooooo

iv
 Agradecimientos

Gracias a Sergio Milan Berd Santander y su PYME impresiones Berd por

auspiciarme con la impresión y servirme desayuno el día lunes que fui a
buscar la impresión, había quequito, tostadas y mokachino ñam ñam.

v
 Tabla de Contenido
Dedicatoria ...................................................................................................... iv

Agradecimientos ............................................................................................. v

Tabla de Contenido......................................................................................... vi

Índice de Figuras ............................................................................................ ix

Resumen ........................................................................................................ x

Abstract ........................................................................................................... xi

Capítulo I ........................................................................................................ 1

Introducción .................................................................................................... 1

1.1 Objetivos ............................................................................................ 3

1.1.1 Objetivo General ........................................................................ 3

1.1.2 Objetivos Específicos .................................................................. 3

1.2 Estado del arte ................................................................................... 4

1.2.1 Herramientas de monitorización .................................................. 4

1.2.2 Elección de la herramienta ........................................................ 12

Capítulo II ..................................................................................................... 14

Estudio de los procesos que deben ser monitorizados ................................. 14

2.1 Análisis de redes de área local ............................................................ 14

Capítulo III .................................................................................................... 19

Descripción de la solución de monitoreo Zabbix ........................................... 19

3.1 Arquitectura de Zabbix......................................................................... 20

3.2 Infraestructura de monitoreo ................................................................ 21

3.3 Monitoreo centralizado y distribuido .................................................... 23

3.4 Flujo de datos ...................................................................................... 24

3.5 Integraciones ....................................................................................... 26

vi
 3.5.1 SNMP ............................................................................................ 26

3.5.2 ICMP ............................................................................................. 28

3.5.3 JMX ............................................................................................... 28

3.5.4 IPMI ............................................................................................... 28

3.5.5 WEB .............................................................................................. 29

3.5.6 KPI................................................................................................. 29

3.5.7 SSH ............................................................................................... 30

3.5.8 Telnet ............................................................................................ 30

3.5.9 Agentes ......................................................................................... 30

3.5.10 ODBC .......................................................................................... 31

3.5.11 Máquinas virtuales....................................................................... 31

Capitulo IV .................................................................................................... 32

Factibilidad de monitoreo de los elementos definidos ................................... 32

Capítulo V ..................................................................................................... 35

Garantías de los sistemas de monitoreo ....................................................... 35

5.1 Evaluación del impacto de la implementación de nuevas tecnologías. 36

5.2 Monitoreo del servicio de Internet ........................................................ 37

5.3 Soluciones SNMP ................................................................................ 37

5.4 Monitoreo de control de acceso mediante integración de logs. ........... 38

5.5 Monitoreo de desarrollo de aplicaciones ............................................. 39

5.6 Monitoreo analítico de negocios .......................................................... 39

5.7 Monitoreo de capacidad ...................................................................... 40

5.8 Monitoreo de configuración ................................................................. 41

5.9 Monitoreo de inventario ....................................................................... 41

5.10 Monitoreo de seguridad ..................................................................... 42

vii
Capítulo VI .................................................................................................... 43

Implementación de plataforma Zabbix .......................................................... 43

6.1 Contexto .............................................................................................. 43

6.2 Configuración Servidor Zabbix ............................................................ 45

6.3 Configuración de parámetros generales .............................................. 47

6.4 Configuración de host .......................................................................... 49

6.4.1 Switch WS-C2950-24 .................................................................... 49

6.4.2 Access point Cisco Aironet 1200 ................................................... 51

6.4.3 Firewall ASA 5505 ......................................................................... 51

6.4.4 Servidores Windows 2008 ............................................................. 51

6.4.5 Servidor CentOS 5.1 con CPanel .................................................. 52

6.5 Monitoreo a través del proxy ............................................................... 52

6.6 Creación de mapa ............................................................................... 53

6.7 Creación de alertas.............................................................................. 53

6.8 Resultados de la monitorización .......................................................... 54

Capítulo VII ................................................................................................... 56

Conclusiones ................................................................................................ 56

Bibliografía .................................................................................................... 58

Anexo A ........................................................................................................ 60

viii
 Índice de Figuras

Figura 1.1 - Esquema de monitoreo................................................................ 4

Figura 1.2 - Nagios ......................................................................................... 5
Figura 1.3 - Pandora. ...................................................................................... 8
Figura 1.4 - ZabbIx........................................................................................ 11
Figura 3.1 - Estructura Zabbix....................................................................... 26
Figura 3.2 - Pooling....................................................................................... 28
Figura 3.3 - Trapping .................................................................................... 28
Figura 3.4 - Monitoreo Distribuido. ................................................................ 30
Figura 3.5 - Flujo de datos ............................................................................ 31
Figura 3.6 - MIB. ........................................................................................... 33
Figura 4.1 - Clientes Access Point. ............................................................... 39
Figura 4.2 - Tráfico Router ............................................................................ 39
Figura 4.3 - Paquetes Router. ....................................................................... 40
Figura 5.1 - Impacto en la cantidad de tráfico. .............................................. 42
Figura 5.2 - Tiempo de respuesta router ISP. ............................................... 43
Figura 6.1 - Esquema de monitoreo.............................................................. 44
Figura 6.2 - Virtual Machine Settings. ........................................................... 45
Figura 6.3 - CentOS 6.2 ................................................................................ 46
Figura 6.4 - Comando Ping. .......................................................................... 49
Figura 6.5 - MIB Walk. .................................................................................. 50
Figura 6.6 - Mapa Zabbix .............................................................................. 53
Figura 6.7 - Tráfico en switch. ....................................................................... 54
Figura 6.8 - Uso de CPU. .............................................................................. 55
Figura 6.9 -Uso de RAM. .............................................................................. 55

ix
 Resumen

En la actualidad existen diversas formas de monitorear una red, una

de ellas es a través de Zabbix, una aplicación de código abierto, que por
ende permite realizar modificaciones en su código fuente, instalación,
implementación, etc.

En la presente tesis se exponen tres de las aplicaciones de

monitorización más populares, y posteriormente se realiza la comparación
entre dichas herramientas de monitoreo, luego se analiza en profundidad la
que resulta mejor evaluada. Este análisis se basa en la capacidad de dar
cumplimiento a los requerimientos de monitoreo de una red, y las limitaciones
de la herramienta. Para determinar los requerimientos de monitoreo de la red
de una empresa, se realiza un análisis de los procesos que deben ser
monitorizados, estudio que luego se contrasta con las posibilidades que
entrega Zabbix frente a dichas necesidades y las tecnologías que integra.
Luego se exponen las garantías de un sistema de monitoreo, y las diferentes
soluciones por área de aplicación que brinda o puede llegar a brindar Zabbix.
Finalmente se implementó el sistema de monitoreo.

x
 Abstract

Currently, there are several ways of network monitoring, one of them is

through Zabbix, an open code application, which allows, therefore, to modify
the source code, installations, implementations, etc.

In the present dissertation, three of the most popular monitoring

applications are explained. Later, these three monitoring applications are
compared, giving rise to the analysis of the network monitoring tool best
evaluated. This analysis is based on the capacity to fulfil the requirements of
monitoring a network, and the limitations of this tool. To determine the
requirements of a company's network monitoring, the processes that should
be monitored are analysed; then, this study is contrasted with the solutions
that Zabbix provides against those needs and the technologies that it
integrates. Later, the guarantees of a monitoring system and the different
solutions by area of application are described, which are provided or may be
provided by Zabbix. Finally, the monitoring system was implemented.

xi
 Capítulo I

Introducción

Una red que no es monitoreada es una red impredecible y más

compleja de administrar. La monitorización es una forma de obtener la
información necesaria para administrar de manera eficiente los recursos de
una red y comprender el estado de la misma. Es necesaria la implementación
de sistemas de monitoreo de red, para prevenir fallas generales del sistema,
realizar diagnósticos ante problemas y situaciones de contingencia,
almacenar datos y crear un registro histórico.

Este proyecto pretende analizar un sistema de monitoreo basado en

Zabbix, una aplicación open source, que permite la supervisión de
servidores, equipos de comunicaciones, entre otros dispositivos, mediante
agentes propios de la aplicación, y una gama de protocolos de red.

1
La memoria esta subdividida en los siguientes capítulos:

 Capítulo 1 “Introducción”: se plantean los objetivos generales,

objetivos específicos y se desarrolla el estado del arte.
 Capítulo 2 "Estudio de los procesos en un sistema de red que deben
ser monitorizados”: para analizar una solución, es necesario conocer
la “necesidad” o problema en cuestión. En este capítulo se estudian
los equipos que forman parte de una red y que deben ser
monitoreados.
 Capítulo 3 "Descripción de la solución de monitoreo Zabbix”: se
analizan las funcionalidades de Zabbix y la capacidad de integrar
diversas tecnologías.
 Capítulo 4 "Factibilidad de monitoreo de los elementos definidos”: Se
contrastan los resultados de los dos capítulos anteriores, verificando si
la aplicación es capaz de monitorear los procesos o equipos
necesarios.
 Capítulo 5 "Garantías de los sistemas de monitoreo”: Se exponen las
garantías propias de la instalación de Zabbix y casos de uso donde se
aprecian de forma concreta
 Capítulo 6 “Implementación de la plataforma de monitoreo”:
Finalmente el sistema es implementado y observado.
 Capítulo 6 “Conclusiones”

2
1.1 Objetivos

1.1.1 Objetivo General

 Analizar un sistema de monitoreo de red basado en Zabbix

1.1.2 Objetivos Específicos

 Estudio de los procesos en un sistema de red que deben ser

monitorizados.
 Descripción del Sistema Zabbix.
 Factibilidad de monitoreo de los elementos definidos.
 Garantías de los sistemas de monitoreo.
 Implementación del sistema de monitoreo.

3
1.2 Estado del arte

1.2.1 Herramientas de monitorización

Existen múltiples herramientas que prestan el servicio de

monitorización de redes, algunas del tipo Open Source y otras con licencias
comerciales, con las ventajas y desventajas que ello implica. La utilización
de herramientas Open Source además de reducir el costo de los proyectos
por términos de licenciamiento permite una mayor flexibilidad a la hora de
adaptar la aplicación a las necesidades del usuario y en la personalización
de la herramienta. Además permiten usar el programa con cualquier
propósito, inclusive comercial; permiten estudiar, adaptar y mejorar el
programa y no incluyen restricciones técnicas.

Si bien existen diferentes herramientas, el esquema de

funcionamiento es similar y se basa en que el monitor tenga conectividad con
el equipo a monitorear y realice en forma periódica diversas consultas, las
que luego son evaluadas por el servidor, que determina según su
programación si se debe activar una alerta.

Figura 1.1 Esquema de monitoreo

4
 A continuación se presentarán tres de las herramientas de
monitorización open source más populares: Nagios, Pandora y Zabbix.

1.2.1.1 Nagios

Lanzado inicialmente en 1999, Nagios es una herramienta de

monitorización desarrollada por Ethan Galstad y es ampliamente utilizada en
entornos productivos. Su versión gratuita Nagios Core cuenta con licencia
GPL Versión 2 y puede instalarse en cualquier equipo que esté ejecutando
Linux o una variante de Unix. [1]

La herramienta se compone de un servidor el cuál procesa la

información obtenida y agentes que recolectan la información. Nagios puede
monitorear equipos sin la necesidad de un agente, sin embargo la utilización
de los mismos permite obtener métricas más específicas de cada equipo.
Existen scripts y plugins que permiten monitorear distintas versiones de Linux
y Windows.

Figura 1.2 Nagios

5
 Según la página oficial de Nagios los requisitos mínimos de instalación
son los siguientes [2]:

 Hardware
o 1Ghz de CPU
o 512 MB de RAM
o 2 GB de disco duro

 Software
o Web Server ( de preferencia Apache)
o Thomas Boutell's gd library version 1.6.3

Las principales cualidades de Nagios son la monitorización de

servicios de red (SMTP, POP3, HTTP, NNTP, ICMP, SNMP); monitorización
de los recursos de equipos hardware (carga del procesador, uso de los
discos, logs del sistema) en varios sistemas operativos, incluso Microsoft
Windows con los plugins NRPE_NT o NSClient++. ; diseño simple de plugins,
que permiten a los usuarios desarrollar sus propios chequeos de servicios
dependiendo de sus necesidades, usando sus herramientas preferidas
(Bash, C++, Perl, Ruby, Python, PHP, C#...); posibilidad de definir la
jerarquía de la red, permitiendo distinguir entre host caídos y host
inaccesibles; visualización del estado de la red en tiempo real a través de
interfaz web, con la posibilidad de generar informes y gráficas de
comportamiento de los sistemas monitorizados, y visualización del listado de
notificaciones enviadas, historial de problemas, archivos de registros[2].

Existen además de Nagios Core, otras 6 versiones de Nagios que

difieren del mismo en sus funcionalidades, por ejemplo algunos son para
usos específicos como el tratamiento de logs de servidores o análisis de
tráficos y además difieren en que poseen licencias comerciales.

6
1.2.1.2 Pandora

Es una herramienta de monitorización Open source, con licencia GPL

versión 2. El proyecto fue comenzado en 2004 por Ártica Soluciones
tecnológicas, empresa española especializada en el desarrollo de software
principalmente de seguridad. La plataforma oficial de Pandora FMS es
Linux, sin embargo desde la versión 5.1 también se soporta Windows server.
Oficialmente se soportan, para el servidor y la consola las siguientes
versiones [3]:

 Windows Server (2003 o superior)

 RedHat Enterprise (RHEL) 6.x

 CentOS 6.x

 SLES 11 SP1 o superior

 OpenSUSE 11.x o superior

 Debian 5.x o superior

 Ubuntu 11 o superior

El sistema se compone de 3 elementos: Servidor, agente y consola. El

servidor trabaja con una base de datos, que puede estar instalada en forma
local o remota, actualmente MySQL es el único formato soportado para
entornos de producción, aunque se está experimentando para trabajar
también con Oracle y PostgreSQL, y es donde almacenan todos los datos
recibidos por los módulos de los agentes. La consola contiene el servidor
WEB donde se encuentra la plataforma que permite administrar el servidor.

Pandora puede monitorear equipos sin la necesidad de un agente, sin

embargo la utilización de los mismos permite obtener métricas más
específicas de cada equipo. Ártica ha desarrollado una gran cantidad de
agentes para las distintas versiones de Linux, Windows, MacOS por

7
mencionar las más populares y además ha desarrollado agentes para
versiones de android 2.2 o superior.

Figura 1.3 Pandora

Según la página oficial de Pandora, los requisitos mínimos de instalación son

los siguientes:

 Hardware:
o 2 GHz de CPU
o 3 Gb de RAM
o 15 GB de Disco Duro

 Software
o Servidor MySQL
o Perl 5.8
o Web Server para la consola

8
 Una de las principales cualidades de Pandora FMS es la integración
de diversas tecnologías, lo que permite abarcar gran cantidad de hosts
presentes en redes empresariales. Dentro de estas tecnologías se
encuentran Netflow, ICMP y SNMP, esta última tecnología está presente en
la gran mayoría de los equipos de comunicaciones, tales como switch, router
y Access Point. También integra soporte para múltiples sistemas operativos
como Windows, Linux, Solaris, AIX, Macos; bases de datos como Oracle,
MySQL, PotgreSQL; aplicaciones empresariales, como SAP, Active directory,
Lotus y ficheros de Logs; servidores de aplicaciones como Tomcat, JMX,
WebSphere; Servidores web y caches como Apache, Nginx, ISS; tecnologías
de virtualización como Vmware, Hyper-v, Xen; también es compatible con
todo tipo de sensores con interfaz IP [4].

Sin embargo la versión gratuita de Pandora Fms no incluye algunas de

estas integraciones y excluye algunas de las funciones que realiza. La
versión Enterprise, la cual se cobra según la cantidad de equipos a
monitorear, integra todas las tecnologías ya mencionadas y no limita el uso
de las funciones del servicio.

9
1.2.1.3 Zabbix

Es un sistema de monitoreo de redes, Open source con licencia GPL

versión 2. Fue creada por Alexei Vladishev y actualmente es desarrollada y
soportada por Zabbix SIA. Fue iniciado como un proyecto interno de software
en 1998 y después de 3 años, en 2001, fue lanzado al público sobre GPL.
Tomo 3 años más hasta su primera versión estable, 1.0, que fue lanzada en
2004. Debido a los requisitos de seguridad y la naturaleza del servicio, UNIX
es el único sistema operativo que puede entregar de forma consistente el
rendimiento necesario, la tolerancia a fallos y la capacidad de recuperación.
Zabbix ha sido testeado en los siguientes sistemas operativos [5]:

 Linux

 IBM AIX

 FreeBSD

 NetBSD

 OpenBSD

 HP-UX

 Mac OS X

 Solaris

 Windows: 2000, Server 2003, XP, Vista, Server 2008, 7, 8, Server

2012 (solo agente de Zabbix)

El sistema base se compone de 2 elementos: servidor y agente. El

servidor es quien colecta la data enviada por los agentes de monitoreo,
posee una base de datos que contiene los datos recopilados. Zabbix puede
monitorear sin la necesidad de un agente, pero la utilización del mismo
permite obtener datos más detallados del equipo monitoreado.

10
 Figura 1.4 Zabbix

Según la página oficial de Zabbix los requerimientos mínimos de

instalación del servidor Zabbix son los siguientes [5]:

 Hardware:
o 1 GHz de CPU
o 128 MB de RAM

 Software
o Apache
o PHP
o MySQL, Oracle, PostgreSQL, SQLite o IBM DB2.

11
 La cantidad de disco duro se debe calcular por la cantidad de ítems a
monitorear y el tiempo que se monitorizará la red. La cantidad de espacio en
disco, es el principal límite para determinar la cantidad de host a monitorear,
ya que Zabbix no posee un límite.

Dentro de sus principales cualidades de Zabbix está el soporte nativo

para SNMP (poolling y trapping), IPMI, JMX, ICMP y chequeos de VmWare;
recopilación de datos en intervalos personalizados; monitoreo distribuido
mediante nodos (hasta la versión 2.x) y proxy; definición personalizada de
umbrales; Alertas altamente configurables; representaciones gráficas
personalizables; monitoreo Web; mapas de red; detección de redes; uso de
plantillas y su fácil configuración.

No existen versiones comerciales de Zabbix, pero se puede contratar

soporte profesional para apoyo en las fases de instalación, configuración y
mantención. De esta forma la versión gratuita incluye todas las
funcionalidades desarrolladas en la herramienta.

1.2.2 Elección de la herramienta

A nivel de sistemas operativos se puede resumir la información en la

siguiente tabla:

Sistema Servidor Agente

Operativo
Nagios Pandora Zabbix Nagios Pandora Zabbix
Linux ✓ ✓ ✓ ✓ ✓ ✓

Windows ✓ ✓ ✓ ✓

MacOS ✓ ✓ ✓ ✓

Unix ✓ ✓ ✓ ✓ ✓
Tabla 1.1 Comparación de sistemas

12
 A partir de los datos obtenidos se genera la siguiente tabla
comparativa:

Nagios Pandora Zabbix

Core FMS
Full Open source No No Sí
Multiplataforma en servidor Sí Sí Sí
Multiplataforma en cliente Sí Sí Sí
Monitorización servicios de red Sí Sí Sí
Monitorización sin agente Sí Sí Sí
Facilidad de uso No Sí Sí
Múltiples App bases de datos No No Sí
Soporte/comunidad Sí Sí Sí
Interfaz web Sí Sí Sí
Alertas Sí Sí Sí
Generación de gráficos No Sí Sí
Tabla 1.2 Comparación de herramientas

Las tres herramientas cumplen con los requisitos fundamentales de

una solución de monitoreo, todas son capaces de monitorizar servicios de
red mediante ICMP y/o SNMP, monitorean múltiples sistemas operativos
mediante agentes o sin la necesidad de ellos, son personalizables, cuentan
con una interfaz web y son capaces de alertar ante una incidencia.

Sin embargo Pandora FMS Y Nagios Core no incluyen todas las

funcionalidades desarrolladas para el uso de la herramienta, ya que además
existen versiones comerciales que incluyen dichas mejoras y para acceder a
ellas se deben pagar licencias. Zabbix no posee licencias comerciales por lo
que todo el desarrollo está incluido en su versión gratuita. Además de esto
Zabbix ofrece la posibilidad de trabajar con distintas bases de datos, caso
contrario a Pandora que solo trabaja con MYSQL, que además posee una
licencia dual y Nagios que no trabaja con una base de datos. Es por eso que
se elige Zabbix para el desarrollo del presente trabajo.

13
 Capítulo II

Estudio de los procesos que deben ser monitorizados

El principal objetivo del monitoreo es supervisar el estado de una red y

los elementos que la componen, asegurando de esta forma que los
componentes se encuentren operativos y que en caso de fallar, el sistema
alerte permitiendo tomar acciones ante la incidencia que den solución a la
misma. A la vez cumple labores preventivas que permiten evitar futuras fallas
en la red. Es por esto que los procesos a monitorear deben tener directa
relación con la trascendencia de los mismos en función del correcto cometido
de la red.

2.1 Análisis de redes de área local

Con el fin de determinar cuáles son estos procesos, se analizaron los

componentes de tres redes Ethernet (técnicamente IEEE 802.3) de
diferentes envergaduras, tomando como referencia el modelo TCP/IP [6] y su
distribución por capas, además de la topología.

TCP/IP es un modelo de referencia de cuatro niveles: Interfaz de red,

internet, transporte y aplicación. No es el objetivo de este trabajo profundizar
en la estructura del modelo, solo se relacionarán los equipos a una capa (aun
cuando hay equipos que pueden ser vinculados con múltiples capas) con el
fin de establecer un orden lógico y facilitar el análisis.

En el estudio se tomarán en cuenta todos los componentes de la red,

asociándolos a una capa de referencia.

14
2.1.1.1 Topología

Cable UTP de Categoría 5e: es un tipo de cable de par trenzado cuya

categoría es uno de los grados de cableado UTP descritos en el estándar
EIA/TIA 568B el cual se utiliza para ejecutar CDDI y puede transmitir datos a
velocidades de hasta 100 Mbps a frecuencias de hasta 100 MHz.

Conectores RJ45: es una interfaz física comúnmente usada para

conectar redes de cableado estructurado, (categorías 4, 5, 5e, 6 y 6a). Es
parte del Código Federal de Regulaciones de Estados Unidos. Posee ocho
pines o conexiones eléctricas, que normalmente se usan como extremos de
cables de par trenzado.

Fibra óptica: es un medio de transmisión, consistente en un hilo muy

fino de material transparente, vidrio o materiales plásticos, por el que se
envían pulsos de luz que representan los datos a transmitir.

Conectores de fibra óptica: es un mecanismo que conecta el extremo

de un cable de fibra óptica para permitir una conexión y desconexión fácil. Su
meta es acoplar mecánicamente los núcleos de las fibras para que la luz
pueda pasar.

2.1.1.2 Capa de acceso al medio

Modem: es un dispositivo que convierte las señales digitales en

analógicas (modulación) y viceversa (demodulación), permitiendo la
comunicación entre redes a través de la línea telefónica o del cable módem.

15
 Hub: es un dispositivo que permite centralizar el cableado de una red y
poder ampliarla. Esto significa que dicho dispositivo recibe una señal y repite
esta señal emitiéndola por sus diferentes puertos.

Access Point: es un dispositivo que interconecta dispositivos de

comunicación alámbrica para formar una red inalámbrica. Normalmente un
WAP (Wireless Access Point) también puede conectarse a una red cableada,
y puede transmitir datos entre los dispositivos conectados a la red cable y los
dispositivos inalámbricos. La mayoría sigue el estándar de comunicación
IEEE 802.1.

Switch: es un dispositivo de interconexión utilizado para conectar

equipos en red formando lo que se conoce como una red de área local (LAN)
y cuyas especificaciones técnicas siguen el estándar IEEE 802.3.

Conversor de Ethernet a fibra: dispositivo permiten establecer

conexiones de equipos UTP Ethernet de cobre a través de un enlace de fibra
óptica para aprovechar las ventajas de la fibra

Radiotransmisor-receptor: dispositivo electrónico que, mediante una

antena, irradia o recibe ondas electromagnéticas que contienen información.

Wireless LAN Controller: controlador de nivel de entrada diseñado

para proporcionar funciones de control en todo el sistema de LAN
inalámbrica

2.1.2.3 Capa de internet

Router: es un de dispositivo de interconexión de redes, interconecta

segmentos de red o redes enteras. Si bien cuando se trata de routers MPLS
pertenecen a la capa 2 y 3 del modelo TCP, se clasificará como un
dispositivo de la capa de internet.

16
2.1.2.4 Capa de Transporte

Firewall: es un dispositivo o conjunto de dispositivos configurados para

permitir, limitar, cifrar, descifrar, el tráfico entre los diferentes ámbitos sobre la
base de un conjunto de normas y otros criterios. Si bien este se trata de un
dispositivo multicapa se clasificará como un dispositivo de la capa de
transporte

2.1.1.3 Capa de aplicación

Servidores: es un nodo que, formando parte de una red, provee

servicios a otros nodos denominados clientes, los que pueden ser locales o
remotos.

Estaciones de trabajo: en ocasiones llamadas nodos, pueden ser

computadoras personales o cualquier terminal conectada a la red. Se trabaja
con sus propios programas o aprovecha las aplicaciones existentes en
servidores.

Teléfono IP: Dispositivo utilizado en la transmisión de voz y datos a través de

la red empleando el protocolo IP

IP-PBX: Una central IP o IP-PBX es un equipo de comunicaciones

diseñado para ofrecer servicios de comunicación a través de las redes de
datos. A esta aplicación se le conoce como voz sobre IP (VoIP), donde IP es
la identificación de los dispositivos dentro de la red.

Impresoras: Dispositivo conectado directamente a la red a través de

un puerto Ethernet con el fin de ser compartida entre los usuarios de la red
local.

17
 PLC: Es una computadora utilizada en la ingeniería automática o
automatización industrial, para automatizar procesos electromecánicos, tales
como el control de la maquinaria de la fábrica en líneas de montaje o
atracciones mecánicas.

Sistemas de video vigilancia: es una tecnología de vigilancia visual

que combina los beneficios analógicos de los tradicionales CCTV (Circuito
Cerrado de Televisión) con las ventajas digitales de las redes de
comunicación IP, permitiendo la supervisión local y/o remota de imágenes y
audio así como el tratamiento digital de las imágenes, para aplicaciones
como el reconocimiento de matrículas o reconocimiento facial entre otras.

Sensor: es un dispositivo capaz de detectar magnitudes físicas o

químicas, llamadas variables de instrumentación, y transformarlas en
variables eléctricas. Las variables de instrumentación pueden ser por
ejemplo: temperatura, intensidad lumínica, distancia, aceleración, inclinación,
desplazamiento, presión, fuerza, torsión, humedad, movimiento, pH, etc.

18
 Capítulo III

Descripción de la solución de monitoreo Zabbix

Tal como se mencionó en el capítulo anterior, Zabbix fue creada por

Alexei Vladishev, actualmente es desarrollada y soportada por Zabbix S.A. y
se describe a sí misma como una solución empresarial de supervisión
distribuida.

Zabbix es un software que monitoriza numerosos parámetros de una

red, la integridad de los servidores y de los hosts en general, utiliza un
mecanismo de notificación flexible que permite a los usuarios configurar
alertas basadas en el correo electrónico, para prácticamente cualquier
evento. Esto permite una reacción rápida a los problemas detectados por el
servidor.

Zabbix ofrece interesantes características de informes y visualización

de información en base a los datos almacenados. Todos los informes y
estadísticas de Zabbix, así como los parámetros de configuración, son
accesibles a través de una interfaz basada en web, la cual asegura que el
estado de la red y el estado de los servidores pueden ser evaluados desde
cualquier ubicación [7].

19
3.1 Arquitectura de Zabbix

La arquitectura de Zabbix se basa en tres componentes de software

los cuales tienen distintas funciones y se detallan a continuación [8].

Figura 3.1 Estructura Zabbix

20
 Zabbix Server: es el componente principal de la arquitectura de
Zabbix, sus funciones son la consulta y captura de datos, la evaluación de
los mismos y la posterior notificación a los usuarios.

Base de datos: es el componente que almacena tanto la información

de configuración como los datos recogidos por el servidor de monitoreo. Hay
múltiples opciones de software compatibles con Zabbix.

Interfaz Web: también llamado front-end es el componente que

permite el acceso a Zabbix desde cualquier plataforma, lo cual posibilita
controlar la configuración y acceder a la información almacenada en el
servidor. Cuenta con múltiples recursos gráficos que serán expuestos más
adelante. Está hecha en PHP.

3.2 Infraestructura de monitoreo

Zabbix soporta la obtención de datos de dos formas, el sondeo

(pooling) y la captura (trapping). El sondeo consiste en la consulta periódica
de parte del servidor Zabbix a un host registrado en su base de datos. En la
captura es el host quien remite la información ante un evento determinado,
sin la necesidad de ser consultado por el servidor de monitoreo; este método
es utilizado para eventos de alta prioridad en que no se puede esperar la
próxima consulta del servidor para alertar sobre alguna incidencia [9].

A modo de ejemplo, la siguiente figura representa la consulta que

realiza Zabbix a un switch cada 30 segundos, periodo definido previamente
por el usuario. El servidor de monitoreo en el segundo 0 realiza una consulta
(GetRequest1), la cual es respondida por el switch (GetResponse1) un
segundo más tarde. GetRequest y GetResponse son tipos de mensajes
SNMP que son enviados por defecto a través del puerto 161/udp. El proceso
se repite periódicamente cada 30 segundos. Cabe señalar que los tiempos
son referenciales, ya que los tiempos de respuesta en una LAN son mucho
menores.

21
 Figura 3.2 Pooling

En el caso de la captura de datos, es el switch quien genera el flujo de

datos. En la figura se aprecia que al segundo 40 se genera un problema en
el switch, el cual está configurado para alertar inmediatamente mediante un
trap, que es un tipo de mensaje SNMP que se envía por el puerto 162/udp.
En este caso no es necesario esperar que pasen 30 segundos para que el
servidor de monitoreo disponga de la información del estado del switch.

Figura 3.3 Trapping

22
3.3 Monitoreo centralizado y distribuido

Para hacer posible el monitoreo es necesario que se establezca una

comunicación directa entre el servidor y el host a monitorear. Sin embargo
existe una alternativa para monitorear hosts que no tengan conectividad con
el servidor de monitoreo; se trata de Zabbix Proxy, un software que se debe
instalar en una máquina con un sistema operativo de los ya mencionados
compatible con el servidor Zabbix y cuya función es actuar de “puente” entre
el servidor principal de Zabbix y el host a monitorear. La comunicación entre
el servidor y el proxy se realiza por defecto mediante el puerto 10051. Cuenta
también con una base de datos que almacena temporalmente los datos
recogidos y que permite retener una determinada cantidad de información al
perder la comunicación con el Servidor de Zabbix.

En la figura 3.1 el servidor de monitoreo se encuentra dentro de la red

de área local 1, y tiene conectividad con todos los equipos de la misma,
además de la interfaz pública de la LAN 2. Sin embargo no tiene conectividad
con los equipos dentro de la Red de área local 2. En este caso se instaló un
proxy de Zabbix que tiene conectividad con los equipos en la LAN 2 y que
puede comunicarse con el servidor central de monitoreo a través de una
regla que realice una traslación de puertos (PAT) entre el firewall y el servidor
Zabbix [5].

23
 Figura 3.4 Monitoreo Distribuido

3.4 Flujo de datos

Una vez obtenidos los datos, ya sea mediante pooling o trapping, de

forma local o remota, el servidor comienza el procesamiento de los datos
obtenidos. Con el fin de obtener una métrica determinada de un equipo
especifico, lo primero que se debe crear es un “host” en Zabbix, el cual se
asociará a una IP y/o DNS, además de un puerto, mediante el cual se
establecerá la comunicación con dicho equipo. Por cada host se definen los
parámetros a monitorear, los cuáles son nombrados “ítems”, por ejemplo el
nivel de carga de la CPU. Por cada ítem es posible definir expresiones
lógicas que determinan si el ítem se encuentra en condiciones de normalidad
o anormalidad, a estas expresiones se les denomina “triggers”. Cuando
mediante un trigger se define que el valor de un ítem es anormal se puede
configurar una respuesta de parte del servidor ante dicho evento, a esta

24
respuesta se denomina “action”. Un action puede notificar a uno o varios
usuarios acerca del evento, por uno o varios medios de comunicación o
tomar medidas directas mediante comandos remotos; dependerá de la
configuración determinada por el usuario. Finalmente todos los datos, desde
el ingreso a la posible generación de acciones son almacenados en la base
de datos, creando un registro que luego puede ser consultado por el usuario
[5].

En el siguiente diagrama de flujo se expone el recorrido de la

información desde que ingresa hasta el punto en que es almacenado en la
base de datos. Luego un ejemplo en el que ingresa un dato correspondiente
al porcentaje de carga en la CPU del host “Servidor de correo”.

Figura 3.5 Flujo de datos

25
 Si bien la configuración parece engorrosa, esto permite mayor
flexibilidad de monitorización, definición de expresiones lógicas y acciones.
Para facilitar la administración es posible crear plantillas o “templates” que
asocian un conjunto de ítems, triggers, entre otros recursos para un tipo de
host, por ejemplo es conveniente disponer de un template para servidores
con sistema operativo Windows.

3.5 Integraciones

3.5.1 SNMP

SNMP (Simple Network Management Protocol) es un protocolo que se

compone de un conjunto de aplicaciones de gestión de red que trabaja
generalmente sobre UDP y que con el tiempo se ha convertido en un
estándar. Diversos equipos (la gran mayoría) cuentan con soporte SNMP,
entre ellos switchs, routers, Access Points, servidores, unidades de red, entre
otras [10].

Para SNMP la red se compone de 2 elementos: gestores y agentes.

Un gestor es quien solicita y recibe información a través de una consulta a
los distintos dispositivos de la red. Un agente reside en los equipos que son
consultados y es el encargado de remitir la información, apoyándose en los
parámetros contenidos en su MIB (Management Informacion Base) ya sea
respondiendo una consulta (pooling) o al presentarse situaciones específicas
en las que es el agente quien envía la información sin ser consultado
(trapping).

La MIB es un tipo de base de datos que contiene información

jerárquica, estructurada en forma de árbol, de todos los dispositivos
gestionados en una red de comunicaciones. Existen diversos software que
pueden consultar la MIB completa de un equipo, para a partir de ello
integrarlo a Zabbix.

26
 Figura 3.6 MIB

Existen varios tipos de consultas SNMP:

- Get Request: Una petición del Administrador al Agente para que envíe los
valores contenidos en el MIB (base de datos).

- Get Next Request: Una petición del Administrador al Agente para que envíe
los valores contenidos en el MIB referente al objeto siguiente al especificado
anteriormente.

- Get Response: La respuesta del Agente a la petición de información

lanzada por el Administrador.

- Set Request: Una petición del Administrador al Agente para que cambie el
valor contenido en el MIB referente a un determinado objeto.

- Trap: Un mensaje espontáneo enviado por el Agente al Administrador, al

detectar una condición predeterminada, como es la conexión/desconexión de
una estación o una alarma.

Dada su amplia popularidad dentro de los fabricantes, este protocolo

está integrado de forma nativa a Zabbix, el cual Dentro de la estructura
SNMP Zabbix asume el rol de gestor, realizando de forma periódica

27
consultas Get Request y recibiendo consultas Set Request y Traps de los
host, previa configuración del usuario.

3.5.2 ICMP

ICMP (Internet Control Message Protocol) es un protocolo que tiene

por función el control y notificación de errores, se encarga de informar al
origen si se ha producido algún error durante la entrega de su mensaje. A
partir de esta información el emisor de la consulta ICMP puede determinar
ciertos parámetros relativos a la comunicación entre los equipos [11].

A través de dicho protocolo, Zabbix puede realizar cinco tipos de consulta:

 Accesibilidad desde el servidor a través de ping

 Porcentaje de paquetes perdidos en la transmisión
 Tiempo de respuesta
 Servicios corriendo y aceptando peticiones TCP a través de un puerto
 Tiempo de respuesta de servicios a través de un puerto

3.5.3 JMX

JMX (Java Management eXtensions) es una tecnología de java

destinada a la gestión integrada de JVM (Java Virtual Machine)
proporcionando las herramientas necesarias para monitorizar y gestionar
aplicaciones, objetos del sistema y dispositivos. [5]

Zabbix incorpora de forma nativa esta tecnología que le permite consultar

ítems a través de JMX.

3.5.4 IPMI

IPMI (Intelligent Platform Management Interface) es un estándar que

permite gestionar servidores independientemente de su sistema operativo,

28
permite por ejemplo encender o apagar un equipo que esté conectado a la
red y con alimentación eléctrica. [5]

Zabbix incorpora de forma nativa esta tecnología lo que le permite

realizar consultas acerca del estado del hardware y eventualmente ordenar el
apagado u otras funciones del equipo mediante comandos remotos.

3.5.5 WEB

Con Zabbix se pueden chequear varios aspectos sobre la

disponibilidad de los sitios WEB. Un escenario WEB se compone de una o
varias solicitudes HTTP o request. Los pasos se ejecutan periódicamente por
el servidor de Zabbix en un orden predefinido. [5]

A través de Zabbix es posible obtener los siguientes datos:

 Promedio de velocidad de descarga por todos los request

 Número de request fallidos
 Último mensaje de error
 Velocidad de descarga por cada request
 Tiempo de respuesta por cada request
 Código de respuesta por cada request

Además es posible simular el login o una ruta de clicks en la página.

3.5.6 KPI

KPI (Key Performance Indicator) es una medida del nivel de

desempeño de un proceso. Existen KPI para diversas áreas de una empresa:
compras, logística, ventas, servicio al cliente, etc. Las grandes compañías
disponen de KPI que muestran si las acciones desarrolladas están dando sus
frutos o si, por el contrario, no se progresa como se esperaba. A través de
Zabbix es posible recopilar esta información. [5]

29
3.5.7 SSH

SSH (Secure Shell) es el nombre de un protocolo y el programa que lo

implementa. Permite el acceso de forma remota a la consola de un equipo a
través de la red. En Zabbix se ocupa como una forma de monitoreo sin
agente y que permite tanto obtener información como la ejecución de
comandos. [5]

3.5.8 Telnet

Telnet (Teletype Network) es un protocolo de red que permite el

acceso remoto a la consola de un equipo a través de la red. En Zabbix se
ocupa como una forma de monitoreo sin agente y que permite tanto obtener
información como la ejecución de comandos. [5]

3.5.9 Agentes

Son programas diseñados con el único fin de establecer la

comunicación entre el servidor de monitoreo y el host. Se han desarrollado
agentes para los sistemas operativos más populares (ver estado del arte), lo
que permite la integración de prácticamente cualquier servidor. Permite
obtener diversas métricas de los servidores, acerca del estado del software y
del hardware, hace posible la ejecución de comandos de forma remota y la
recolección de logs.

30
3.5.10 ODBC

ODBC (Open DataBase Connectivity) es un estándar de acceso a las

bases de datos que tiene por objetivo hacer posible el acceso a cualquier
dato, desde cualquier aplicación sin importar que sistema de gestión de base
de datos almacene los datos.

3.5.11 Máquinas virtuales

Zabbix soporta el monitoreo de entornos virtuales, puede utilizar reglas

de descubrimiento para encontrar las máquinas virtuales y posteriormente
asociarlas a una plantilla predefinida.

31
 Capitulo IV

Factibilidad de monitoreo de los elementos definidos

Como resultado del estudio inicial acerca de los componentes de una

red, se obtuvo un listado de equipos, el cual se debe contrastar con las
capacidades de Zabbix de monitorizar e integrar diversas tecnologías. Al
igual que el estudio inicial, el análisis es realizado por capas del modelo de
referencia TCP/IP.

A nivel de topología se encuentran elementos tales como conectores y

diversos tipos de cableado y fibra, elementos que componen el medio físico
por el cual se propagan las señales. Mediante Zabbix no es posible
monitorear directamente el estado de los componentes de la topología ya
que una de las condiciones mínimas para que el componente sea
monitoreado es que este o un objeto que lo supervise directamente cuente
con una dirección IP o un DNS mediante el cual se pueda establecer la
comunicación.

Ya en la primera capa del modelo de referencia TCP/IP se encuentra

una diversa gama de elementos, los cuales se analizarán subdivididos en
dos grupos, los elementos que cuentan con una dirección IP y los que no.
Como ya ha sido mencionado, no es posible monitorear elementos que no
cuenten con una dirección IP o un elemento que los supervise y que
disponga de una. Dentro de esta capa dichos elementos son módems, hubs,
switchs no administrables y algunos tipos de conversores. En el otro grupo se
encuentran los elementos que cuentan con una dirección IP, utilizada para la
administración de dicho dispositivo. Tales dispositivos son los
radiotransmisores, Access Point y WLAN controller. En el caso particular de
los Access Point, la gran mayoría cuenta con soporte SNMP lo que permite
obtener métricas acerca del tráfico en sus interfaces, cantidad de clientes

32
conectados, entre otros datos, dependiendo de la MIB del equipo, la cual
varía entre las distintos fabricantes y modelos. La figura muestra la cantidad
de equipos conectados a un Access Point.

Figura 4.1 Clientes Access Point

A nivel de capa dos del modelo de referencia TCP/IP todos los

componentes pueden ser monitoreados mediante su dirección IP. Además la
gran mayoría soporta el protocolo SNMP lo que permite obtener métricas de
tráfico por interfaz, cantidad de paquetes por segundo diferenciando por tipo
de destino (unicast, multicast o broadcast), entre otros parámetros
soportados por la MIB del equipo. También es posible obtener el resultado de
la ejecución de comandos vía SSH o Telnet.

El gráfico muestra el tráfico entrante y saliente en una determinada

interfaz de un router, el tráfico entrante está graficado de color verde y el
saliente de color azul, sin embargo los colores son personalizables.

Figura 4.2 Tráfico en interfaz de Router

33
 El siguiente gráfico muestra la cantidad de paquetes diferenciando
entre entrantes, salientes y unicast, multicast, y broadcast.

Figura 4.3 Paquetes en interfaz de router

En la capa tres de transporte, se encontró solamente el firewall, que si

bien es un equipo multicapa fue clasificado como un dispositivo de la tercera
capa del modelo de referencia TCP/IP. Los firewall pueden ser monitoreados
por sus distintas interfaces a través de sus direcciones IP, además también
en su gran mayoría cuentan con soporte SNMP.

El mayor desarrollo se encuentra en la cuarta capa, de aplicación.

Todos los elementos son alcanzables por medio de su dirección IP o un
elemento que los supervise y cuente con una, como es el caso de sensores y
PLC.

El desarrollo de agentes permite obtener métricas detalladas acerca

del rendimiento de los servidores, haciendo posible obtener información del
uso de recursos como memoria, cpu, discos, o también del estado de los
servicios en los equipos.

34
 Capítulo V

Garantías de los sistemas de monitoreo

El monitoreo de redes es esencial para empresas de cualquier

tamaño, ya que no solo asegura que el usuario sea alertado ante una
incidencia, sino que además permite aumentar la eficiencia de los recursos
disponibles al poder registrar el consumo de recursos y ancho de banda de
equipos como servidores, lo que puede llevar a una reducción de costos al
adquirir equipamiento, teniendo en cuenta información confiable acerca de
las propias necesidades.

También trae beneficios como la reducción del tiempo de inactividad

por fallas que no se han descubierto, lo que a su vez ocasiona una mayor
satisfacción de parte los usuarios ante un sistema estable y controlado, y una
mayor tranquilidad para el administrador de la red.

Un malentendido común acerca de Zabbix como solución de

monitoreo, es que puede ser aplicada solamente para monitorear la
integridad de la infraestructura TI de las organizaciones, como la
disponibilidad y el desempeño de servidores, dispositivos de red, y
aplicaciones. Sin embargo, años de experiencia en el desarrollo de Zabbix y
la integración, así como el conocimiento obtenido por los usuarios a través
de diferentes industrias, permite afirmar que esta herramienta puede
aplicarse a muchas tareas dentro de la función de gestión de TI y la gestión
de procesos de negocios.[5]

Cada negocio es único en términos de estrategia, estructura, metas y

tácticas, de modo que para mantener un negocio “bajo control” algunos
necesitan tomarle más atención a los parámetros de disponibilidad de la
compañía, otros en seguridad o producción, mientras algunos otros en
desempeño y resultados. Pero una de las grandes cualidades de Zabbix, es

35
que no limita al usuario en cuanto a qué puede ser monitorizado. La solución
de monitoreo es capaz de leer, reaccionar, y mostrar información de distintas
fuentes y puede ser adaptada en el 99,9% de los casos dentro de cualquier
área de tu infraestructura TI.

A modo de ejemplo se exponen diferentes áreas y casos donde se ha

aplicado la herramienta de software Zabbix, como principal solución de
monitoreo.

5.1 Evaluación del impacto de la implementación de nuevas

tecnologías.

La implementación de nuevas tecnologías implica un aumento en la

demanda del uso de recursos, que siempre son limitados, por lo que el
impacto sobre la red dependerá de la cantidad de recursos disponibles. Sin
la presencia de una herramienta como Zabbix, el impacto no es cuantificable
y pasa por un asunto de percepción. Sin embargo el uso de una herramienta
de monitoreo permite obtener gráficos como el que se expone a
continuación.

Figura 5.1 Impacto en la cantidad de tráfico

El gráfico muestra el aumento progresivo del volumen de tráfico en

una interfaz de un switch de distribución de una red en la que se comenzó a
implementar un sistema de videovigilancia IP.

36
5.2 Monitoreo del servicio de Internet

A través de Zabbix es posible monitorear y posteriormente analizar el

comportamiento de los equipos que son propiedad del ISP. Esto permite
obtener pruebas concretas del desempeño de dichos equipos, lo que puede
transformarse en un respaldo al realizar una queja ante un servicio
deficiente. Zabbix también contiene herramientas que permiten determinar
el cumplimiento del SLA. Este monitoreo se aplica a través de ICMP y SNMP,
dependiendo de la disponibilidad del equipo.

Se pueden apreciar anomalías en el comportamiento de los equipos,

excesivos tiempos de respuestas, gran cantidad de pérdida de paquetes,
como también el uso que se le da al equipo al observar la cantidad de datos
que trafica

En la figura 5.2 se aprecia el tiempo de respuesta de un router

propiedad de un ISP que presenta un tiempo de respuesta promedio de 250
ms durante más de seis horas.

Figura 5.2 Tiempo de respuesta Router ISP

5.3 Soluciones SNMP

A partir de las integraciones SNMP es posible desarrollar diversas

soluciones. A modo de ejemplo un sistema de alimentación ininterrumpida

37
(SIA) que soporta el protocolo SNMP puede alertar al ser desconectado de la
corriente eléctrica, esto puede hacer que Zabbix ordene el apagado de los
servidores antes que la energía que almacena el SIA ante este tipo de
eventos se agote.[7]

5.4 Monitoreo de control de acceso mediante integración de logs.

Como usual primer paso, las compañías comienzan a monitorear los

archivos log de control de sistema para correlacionar las ocurrencias de fallas
del sistema TI con la entrada a la sala de servidores, donde los servidores y
el equipamiento de redes están localizados, o determinar una relación entre
las puertas abiertas y los cambios de temperatura en la sala de servidores.

Algunos van más allá e integran el monitoreo del log de control de

acceso con el sistema, para verificar si una persona está autorizada para
entrar a una sala de servidores a una hora determinada o para usar un ruteo
dinámico de mensajes de correo electrónico conteniendo alarmas acerca del
monitoreo de fallas del ambiente, o a gente que recientemente se haya
reportado en sus escritorios.

Dependiendo de la información que el sistema de acceso escribe en

sus archivos logs, Zabbix puede detectar e informar acerca de puertas
abiertas, uso inapropiado de tarjetas de acceso (Como una tarjeta usada
para salir de una sala sin haberla utilizado para entrar en esa sala), o
intentos de uso de tarjetas que se han reportado como perdidas o robadas.

La integración de los logs de control de acceso como otra información

de monitoreo recopilada por Zabbix, permite a las compañías hacer este tipo
de monitoreo inteligente.

38
5.5 Monitoreo de desarrollo de aplicaciones

En un ambiente de desarrollo altamente dinámico de software, donde

las mejoras de software se suman a la producción de sistemas semanal o
incluso diariamente, es una tarea desafiante el monitorear la calidad de los
procesos de desarrollo o código. Los problemas pueden ser asociados con la
mantención del código limpio, controlando el uso de memoria y previniendo
las pérdidas de memoria, asegurando que no queden atrás ramas
comprometidas o inutilizadas por un largo tiempo.

Un típico ejemplo de tal monitoreo, puede ser un caso de incremento

dramático en la memoria o el uso de CPU de un servidor web, después de
publicar una nueva aplicación en la página web. Zabbix permite comparar el
uso de recursos con el número de usuarios en línea. Y si tal exigencia de
recursos no puede ser relacionado con más navegantes que usan
activamente las nuevas características, un e-mail puede ser enviado para
informar acerca de problemas con la aplicación.

5.6 Monitoreo analítico de negocios

Cualquier negocio tiene indicadores claves de rendimiento (KPI), los

cuales permiten entender el estado de tal negocio. Pueden ser los ingresos,
ganancias, número de visitantes web o el número de compras, o la cantidad
de dispositivos que se manufacturan por hora. Para cada compañía e
industria asociada puede ser algo diferente y único. Recopilar tal información
manualmente y chequear que se compare con los números previstos, es una
tarea que consume tiempo, que hace que algunas empresas “olviden”
recopilar y evaluar tal importante información de forma contante. Esto puede
resultar en una perdida directa de ingresos o decisiones de negocios
erróneas.

39
 Agregar esas métricas al monitoreo Zabbix toma unos pocos minutos,
pero puede tener una influencia dramática en el desempeño financiero de la
empresa y el futuro desarrollo. No hay necesidad de agregar y configurar
cientos de parámetros de inmediato. Esto puede hacerse gradualmente,
añadiendo constantemente KPI’s que sean necesarios para el negocio.

Con todo el desarrollo de Zabbix un gerente puede recibir un SMS a

una hora determinada declarando las ventas de ese día o que el plan de
producción está terminado viendo una tabla en un Smartphone mostrando
que todos los indicadores clave están “en verde” para hoy. La funcionalidad
incorporada de Zabbix, permite lograr esto fácilmente, accediendo a tablas
de datos, pantallazos, gráficos y notificaciones.

5.7 Monitoreo de capacidad

Esta es una de las principales funciones de Zabbix, pero que a

menudo es olvidada o infravalorada por los usuarios. Zabbix tiene toda la
información del desempeño de la infraestructura TI y por lo tanto es capaz de
informar la cantidad de recursos que quedan sin utilizar.

Esta información utilizada inteligentemente permite “exprimir” más

recursos de la infraestructura TI sin gastar dinero adicional o comprar nuevo
equipamiento. También en base a la información es posible sugerir dar de
baja equipos temporal o permanentemente, o reacomodar sistemas a
equipos con más recursos disponibles.

Controlar esta información es una garantía para aprobar presupuestos

para los próximos años, sabiendo las condiciones reales de los servidores,
dispositivos de red, licencias de aplicación y otros recursos. Tener todos los
números en mano permite justificar los gastos requeridos y no poner en
peligro esas predicciones más adelante.

40
5.8 Monitoreo de configuración

La solución de monitoreo de redes Zabbix, no proporciona la

funcionalidad de gestión de configuración, pero puede ser fácilmente
configurado para monitorear la configuración de un ambiente TI,
asegurándose que los sistemas operen de acuerdo a las reglas establecidas.

A modo de ejemplo, Zabbix puede recopilar información acerca de las

versiones de un software y reportar si algún equipo corre con una versión
software más antiguo que el que se utiliza. Otro uso para Zabbix sería la
detección de aplicaciones instaladas en cualquier servidor, compararla con la
lista de aplicaciones permitidas o requeridas y notificar acerca de cualquier
anormalidad.

Algunos usuarios de Zabbix van aún más allá y usan scripts en Zabbix
para instalar aplicaciones en dispositivos seleccionados.

5.9 Monitoreo de inventario

Zabbix, permite monitorear el inventario de equipamiento TI. Mientras

la mayoría de los sistemas de gestión de inventarios llevan un seguimiento
de los dispositivos y aplicaciones compradas por la organización, solo unas
pocas de ellas proporcionan el estado actual del inventario.

A modo de ejemplo, una compañía tiene 100 licencias de Microsoft

SQL o de Servidores Oracle. En un ambiente dinámico puede ser difícil llevar
un seguimiento de cuantas están en uso realmente. Puede haber licencias
que no estén utilizadas, lo que significa que no hay necesidad de comprar
nuevas para los equipos que llegan. O el número de instancias instaladas
está sobre el número de licencias compradas y por lo tanto nuevas licencias
tienen que ser compradas.

41
 Es también posible llevar un seguimiento del número de módulos
RAM, discos, dispositivos de red y escritorios, impresoras y otros periféricos
en actual uso y compararlo con el inventario oficial.

5.10 Monitoreo de seguridad

Hay muchas soluciones diferentes de seguridad en el mercado que

hacen trabajos complejos o muy al límite, como controles de puertos de red,
análisis de contenidos de paquetes, chequeos de archivos e integridad de los
datos, análisis de logs y otras acciones de seguridad.

Pero luego hay un factor humano o malfuncionamiento que causa la

mayoría de las violaciones de seguridad. Tal vez alguien abrió un puerto de
red por un minuto y nunca recordó cerrarlo; Un virus o un software malicioso
alteró los sistemas y el control es dado a un intruso; Un archivo de
contraseña fue alterado cuando debería permanecer sin cambios; La
contraseña de root fue utilizada muchas veces; Un case de servidor fue
abierto.

Zabbix entrega garantías de seguridad, ya que todos los chequeos

requeridos pueden ser fácilmente realizados por Zabbix y posteriormente
envía notificaciones a tiempo para excluir violaciones de seguridad o
minimizar las pérdidas de dichas acciones ilegales.

42
 Capítulo VI

Implementación de plataforma Zabbix

6.1 Contexto

Con el fin de analizar el comportamiento y las reales prestaciones de Zabbix

se procede a la implementación de la herramienta en el siguiente contexto:

Servidor Zabbix: La aplicación es instalada sobre el sistema operativo

CentOS 6.2 en su versión minimal de 64 bits. El sistema operativo se
encuentra virtualizado sobre la aplicación VMware Workstation 10.0.0. A su
vez la aplicación está instalada sobre Windows 7 Professional de 64 bits en
un notebook Hp Probook 6460b.

Proxy Zabbix: la aplicación está instalada sobre Raspbian OS, en una

Raspberry Pi B+.

Red a monitorear: La red a monitorear se compone de algunos de los

elementos señalados en el capítulo II. Estos son dos servidores Windows
2008, un servidor Cpanel con CentOS 5.1, dos access point Cisco Aironet
1200, dos firewall ASA 5505, dos switch Cisco WS-C2950-24 y una
impresora HP LJ300-400.

La infraestructura a monitorear se compone de dos redes privadas y un

servidor con una dirección IP pública. El servidor Zabbix se encuentra en la
LAN 1, mientras que en la LAN 2 se instaló un proxy Zabbix.

No se profundizará en los detalles de la instalación dado que no es el

objetivo de este trabajo, pero se indicará la bibliografía que contiene de
forma detallada las distintas fases de instalación.

43
A continuación el diagrama que muestra la forma en que están dispuestos
los elementos a monitorear.

Figura 6.1 Esquema de monitoreo

44
El proceso de implementación comienza con la definición del número de
elementos a monitorear ya que esto determina el requerimiento de hardware
para el servidor Zabbix. La estructura se compondrá de doce elementos,
incluyendo el servidor y el proxy de Zabbix que también deben ser
monitoreados, por lo tanto se clasifica como una estructura pequeña y puede
ser configurado sobre los requerimientos mínimos de hardware.

6.2 Configuración Servidor Zabbix

Se cuenta con un equipo HP ProBook 6460b con Windows 7 sobre el cual

se instalará VMware Workstation, aplicación que permite la creación de
máquinas virtuales. Se crea la máquina virtual y se le asignan los siguientes
recursos:

 1 GB de memoria RAM
 20 GB de disco duro
 1 Procesador

Además la tarjeta de red fue configurada en modo Bridged. En la bibliografía

se encuentra un enlace con más información acerca de VMware Workstation
[12] y un manual de configuración [13].

Figura 6.2 Virtual Machine Settings

45
Dentro de la máquina virtual se instala CentOS 6.2, un sistema operativo de
código abierto, basado en la distribución Red Hat Enterprise Linux,
operándose de manera similar, y cuyo objetivo es ofrecer al usuario un
software de "clase empresarial" gratuito. Se define como robusto, estable y
fácil de instalar y utilizar. En la bibliografía se encuentra un enlace con más
información acerca de CentOS [14] y un manual de configuración [15].

Figura 6.3 CentOS 6.2

Se procede a la instalación de la aplicación, lo que conlleva la instalación de

los siguientes pre-requisitos de software que permiten el funcionamiento de
Zabbix:

 Apache 1.3.12 o posterior

 PHP 5.3.0 o posterior
 Extensiones PHP: gd, bcmath, ctype, libXML, xmlreader, xmlwriter,
session, sockets, mbstring, gettext, mysqli.
 MySQL
 Libssh2
 Fping
 Net-snmp

46
Posteriormente se agrega el usuario “zabbix” al sistema y se procede a la
instalación de los paquetes de la aplicación propiamente tal, los archivos son
almacenados en la carpeta del usuario creado. Se optó por usar MySQL en
la instalación, se creó una base de datos y se le dio los permisos necesarios
al usuario para conectare a ella. En la bibliografía se encuentran dos
referencias, una con las instrucciones de configuración oficiales del servidor
de Zabbix [5]y otra configurada por un usuario[7].

Una vez configurado el servidor se procede a ingresar los host, para esto
basta su dirección IP y un nombre descriptivo. Se debe tener claridad acerca
del tipo de tecnología con la que se puede monitorear el host, ya que esto
determina el tipo de interfaz a utilizar. Las interfaces disponibles de forma
nativa son cuatro: SNMP, IPMI, JMX y agente Zabbix. En la bibliografía se
encuentra un enlace acerca del ingreso de host al servidor de monitoreo[5].

6.3 Configuración de parámetros generales

La implementación continúa con la determinación de los parámetros a

monitorear. Algunos de estos parámetros son comunes, por ejemplo el
tiempo de respuesta dentro de la red LAN, y otros son específicos de cada
host. Cada parámetro contiene una llave que determina la función del ítem.

Tal como se mencionó en el capítulo iii, Zabbix integra diversas tecnologías

que permiten obtener datos, una de ellas es a través del protocolo ICMP, a
través del cual se puede obtener datos de disponibilidad, tiempo de
respuesta y paquetes perdidos. Por defecto Zabbix incluye una plantilla que
agrupa los ítems ICMP, pero estos ítems pueden ser modificados de acuerdo
a ciertos parámetros.

 El ítem disponibilidad es el más simple, ya que solo verifica si el host

responde o no a un ping. Su llave es la siguiente:

47
 Target: IP o DNS
Packets: número de paquetes
Interval: tiempo entre paquetes sucesivos (ms)
Size: tamaño de los paquetes en bytes
Timeout: tiempo de espera (ms)

 El ítem de tiempo de respuesta contiene la siguiente llave:

Target: IP o DNS
Packets: número de paquetes
Interval: tiempo entre paquetes sucesivos (ms)
Size: tamaño de los paquetes en bytes
Timeout: tiempo de espera (ms)
Mode: mínimo, máximo, promedio (por defecto)

 El ítem de paquetes perdidos contiene la siguiente llave

Target: IP o DNS
Packets: número de paquetes
Interval: tiempo entre paquetes sucesivos (ms)
Size: tamaño de los paquetes en bytes
Timeout: tiempo de espera (ms)

Cuando los paréntesis no son alterados, se toma la configuración por defecto

para la obtención de la información. En este caso se dejará por defecto.

48
A partir de estos tres ítems se debe crear al menos una alerta respecto al
protocolo ICMP. Respecto a la disponibilidad, se determinó que si el host no
responde a 10 consultas se debe activar el trigger. Respecto a la cantidad de
paquetes perdidos se determinó que al obtener un 100% de paquetes
perdidos en promedio de las últimas 10 consultas debe activarse el trigger.
En el caso del tiempo de respuesta para determinarlo se realizó un ping
continuo entre dos host de la red por 30 segundos para determinar el tiempo
de respuesta promedio dentro de la red y a partir de aquello activar el
trigger.

Figura 6.4 Comando PING

Se obtuvo un mínimo de 1 ms, un máximo de 29 ms y un promedio de 5 ms,

por lo que el trigger se activará cuando el tiempo promedio de las últimas 10
muestras supere el doble del promedio, 10 ms.

Con el fin de agrupar la información de forma lógica se explicará por cada

tipo de host de la red las acciones realizadas.

6.4 Configuración de host

6.4.1 Switch WS-C2950-24

Este switch cuenta con soporte SNMP, por lo que se usará este protocolo
para obtener datos. El primer paso es la habilitación del protocolo, al
respecto se adjunta la respectiva bibliografía [16]. Luego se debe consultar la
MIB para saber qué datos son relevantes a la hora del monitoreo, para esto

49
existen varios métodos, uno de estos es a través de “MIB Walk” un programa
dentro del conjunto de herramientas de SolarWinds[17].

Dentro de la herramienta se debe indicar la IP y la comunidad SNMP que fue

previamente configurada en el switch y se mostrará la MIB completa del
equipo.

Figura 6.5 MIB Walk

A partir de la MIB se pueden seleccionar los ítems que se consideran

relevantes, en este caso se tomaron los datos de tráfico por interfaz, errores
entrantes y salientes, uso de CPU.

Para ello se debe tomar el OID o el nombre, y luego crear un ítem del tipo
SNMP, agregar la comunidad, especificar el puerto, el intervalo de consulta,
entre otros datos. Se creará un trigger solo para el uso de CPU, cuando el
uso supere el 90%.

50
6.4.2 Access point Cisco Aironet 1200

Este Access Point cuenta con soporte SNMP, por lo que se usará este
protocolo para obtener datos. El primer paso es la habilitación del protocolo,
al respecto se adjunta la respectiva bibliografía [17]. Luego se debe consultar
la MIB para saber qué datos son relevantes a la hora del monitoreo, esto se
realizará de la misma forma que el switch. Se va a monitorear la cantidad de
tráfico en la interfaz del Access Point y la cantidad de usuarios conectados.
No se crearán triggers al respecto.

6.4.3 Firewall ASA 5505

Este Firewall cuenta con soporte SNMP, por lo que se usará este protocolo
para obtener datos. El primer paso es la habilitación del protocolo, al
respecto se adjunta la respectiva bibliografía [18]. Luego se debe consultar la
MIB para saber qué datos son relevantes a la hora del monitoreo, esto se
realizará de la misma forma que el switch y el Access Point. Se va a
monitorear la cantidad de tráfico en la interfaz, pero no se creará un trigger al
respecto.

6.4.4 Servidores Windows 2008

Es posible monitorear los servidores Windows a través de agentes propios de

Zabbix. Se procede a la instalación del agente en el servidor, al respecto la
bibliografía señala un manual de configuración de agentes en dicha
plataforma[5]. Se va a monitorear la cantidad de espacio en disco duro, el
uso de RAM y CPU. Se crearán triggers respecto a los tres parámetros
monitoreados, en el caso del disco duro, cuando el espacio ocupado supere
el 90%, en el caso del uso de CPU del 50% 70% y el 90% de utilización, y en
el caso de la memoria RAM, cuando el uso supere el 70% y 90% de uso.

51
También se va a monitorear el estado del servicio DHCP, y se creará el
respectivo trigger.

6.4.5 Servidor CentOS 5.1 con CPanel

Es posible monitorear los servidores Linux a través de agentes propios de la

Zabbix. Se procede a la instalación del agente en el servidor, al respecto la
bibliografía señala un manual de configuración de agentes en dicha
plataforma [5]. Se va a monitorear, al igual que en Windows la cantidad de
espacio en disco duro, el uso de RAM y CPU. Se crearán triggers respecto a
los tres parámetros monitoreados, en el caso del disco duro, cuando el
espacio ocupado supere el 90%, en el caso del uso de CPU del 50% 70% y
el 90% de utilización, y en el caso de la memoria RAM, cuando el uso supere
el 70% y 90% de uso. También se va a monitorear la disponibilidad de los
puertos 25 (SMTP), 143 (IMAP) y 110 (POP3). Al respecto se creará un
trigger para cada puerto.

6.5 Monitoreo a través del proxy

El uso del proxy permite el monitoreo de otra red o segmento que no tenga
conectividad directa con el servidor Zabbix. Se instaló en una Raspberry Pi
B+, el sistema operativo Raspbian, basado en Debian y sobre dicho sistema
operativo la aplicación proxy de Zabbix. Respecto a dichas configuraciones
en la bibliografía se encuentra un manual de instalación de Raspbian [19] y
del proxy Zabbix [20]. En el proxy también se habilitó el agente que permite
su monitoreo.

Para configurar el proxy se le debe indicar la dirección IP del servidor, como

el servidor tiene una IP privada se debe crear un PAT en el firewall de la red
del servidor, que permita la conexión entre este y el proxy a través del puerto

52
10050 y 10051. En el servidor solo se debe registrar el nombre del proxy y
los host que serán monitoreados a través de él.

6.6 Creación de mapa

Una forma de facilitar la monitorización es la creación de mapas, ya que los

mapas muestran en tiempo real si el host presenta alguna alerta. Se creó el
mapa según el diagrama presentado al inicio de la implementación. Se
adjunta en la bibliografía un manual de configuración de mapas [5].

Figura 6.6 Mapa Zabbix

6.7 Creación de alertas

A partir de los triggers creados, se creó una alerta que envía por correo
información acerca del evento ocurrido. Se adjunta el detalle de la
configuración de alertas y medios de envío en la bibliografía [5].

53
6.8 Resultados de la monitorización

Una vez implementado el sistema de monitoreo se observa el

comportamiento del mismo por una semana.

Respecto a los triggers relativos a ICMP, durante los primeros días se

observó una gran cantidad de alertas de tiempo de respuesta y paquetes
perdidos, sin embargo el equipo permanecía disponible y los triggers
generaron muchas alertas innecesarias, por lo que fueron desactivados,
quedando solo el trigger de disponibilidad. El hecho de desactivar el trigger,
no significa que los ítems de tiempo de respuesta y paquetes perdidos no
sigan siendo observados y pueden ser analizados desde la web.

Durante el periodo de observación se produjo la caída de un Access Point, la

cual fue correctamente alertada y posteriormente solucionada. También se
debe señalar que no hubo caídas que no fueron registradas por el servidor
de monitoreo.

Se pudo registrar el volumen de tráfico, que va hacia internet desde la LAN a

través de la interfaz que conecta a switch y firewall

Figura 6.7 Tráfico en switch

54
Se pudo observar el comportamiento de los servidores.

Figura 6.8 Uso de CPU

Figura 6.9 Uso de RAM

55
 Capítulo VII

Conclusiones

Se comenzó con un análisis de la red con el objetivo de contrastar las

necesidades de monitoreo con las posibilidades que entrega Zabbix. Luego
se analizó Zabbix llegando a las siguientes conclusiones:

Zabbix es un sistema altamente flexible, integrando diversas

tecnologías que permiten integrar no solo una gran cantidad de equipos, si
no que una gran cantidad de parámetros a monitorear, lo que brinda amplias
posibilidades de generar soluciones en diversas áreas de aplicación que van
desde soluciones básicas para supervisar la disponibilidad de la red, hasta
complejas soluciones que controlen el sistema de logs de servidores, y
accesos a las salas donde están ubicados, tomando acciones a través de
comandos remotos ante determinados eventos.
La complejidad del resultado de la implementación de la solución de
monitoreo dependerá en definitiva de la habilidad de quien la configure, ya
que como aplicación las limitantes de Zabbix son mínimas y en cuanto a
cantidad de host y parámetros a monitorear, estos se limitan por las
características físicas del servidor donde se encuentre alojado Zabbix. Como
se ha analizado es posible integrar prácticamente cualquier tecnología al
sistema ya sea directa o indirectamente. Cabe señalar que existe la
posibilidad de contratar soporte profesional, para facilitar los procesos de
instalación, configuración y mantenimiento, pero el servicio tiene un costo
asociado. Existe también una gran comunidad donde se puede encontrar
valiosa información proporcionada por los usuarios de Zabbix alrededor del
mundo.

56
 Zabbix es un sistema de monitoreo que da cubrimiento a las cuatro
capas del modelo de referencia TCP/IP, aunque hay equipos de la capa de
acceso que no pueden ser monitoreados directamente al carecer de una
dirección IP. Sin embargo los equipos clasificados en las capas superiores,
en su totalidad, pueden ser monitoreados, siendo la capa de aplicación la
que presenta un mayor nivel de integración en sus equipos.

La implementación de un sistema de monitoreo es una decisión

estratégica para cualquier empresa, ya que permite tener control sobre la
infraestructura TI al alertar las incidencias en tiempo real y almacenar datos
que al ser correctamente analizados permiten prevenir futuros incidentes.
También permite medir y analizar la disponibilidad y comportamiento de
equipos propios o de algún proveedor de servicios y aumentar la
productividad del sistema, al disminuir los tiempos de detección y posterior
reparación de fallas. A la vez es una fuente de información confiable que
permite mantener un control centralizado del equipamiento, lo que es útil a la
hora de presentar presupuestos e invertir en la mejora de la estructura TI.

El uso de herramientas de monitoreo Open Source, no solo permite la

disminución de costos por términos de licenciamiento, si no que incorpora
beneficios tales como la posibilidad de estudiar, mejorar y personalizar el
software a las necesidades específicas de cada empresa, permitiendo usar el
programa para prácticamente cualquier propósito.

Mediante la implementación se comprobó el correcto funcionamiento

de Zabbix, ya que detectó las fallas que se presentaron en la red y se
comprobó que no hubo eventualidades que Zabbix no haya podido detectar,
esto de acuerdo a los parámetros que se le indicó al servidor que debía
monitorear. Se pudieron registrar correctamente datos de tráfico, tiempo de
respuesta, paquetes perdidos, uso de recursos en servidores, estado de
servicios, disponibilidad y disponibilidad de puertos, lo que representa
información relevante a la hora de realizar un análisis de la red

57
 Bibliografía

[1] Ryder, Tom (2013) Nagios Core Administration Cookbook ,

Birmingham, U.K.
[2] Nagios Enterprises. Nagios Core. Disponible en: nagios.com,
directory: products/nagioscore.
[3] Osorio, Axel. Monitorización con Pandora FMS. TECSUP
[4] Ártica Soluciones Tecnológicas. Pandora:Documentación. Disponible
en wiki.pandorafms.com.
Directory: index.php?title=Pandora:Documentation_es:Instalacion
[5] Zabbix SIA. Documentation. Disponible en zabbix.com, Directory:
documentation.php
[6] Braden, R (1989) RFC 1122, Requeriments for internet host-
Comunication layers.
[7] Sánchez,I. (2005). Sistema de monitorización con la herramienta
Zabbix
[8] González .E.(2010) Sistema de monitorización de la infraestructura
CCTV en la UC3M con Zabbix
[9] García B. (2013) Estudio de un sistema de Gestión de redes usando el
protocolo SNMP
[10] J. Case (1990) RFC 1157, A Simple Network Management Protocol.
[11] J. Postel (1981) RFC 792, Internet Control Message Protocol
[12] VMware Workstation. Disponible en: vmware.com, directory:
cl/products/workstation.
[13] VMware Manual. Disponible en: vmware.com, directory:
pdf/ws7_manual.
[14] CentOS Proyect. Disponible en: centos.org
[15] CentOS manual install. Disponible en: wiki.centos.org, directory:
howtos/manualinstall.

58
[16] Cisco WS-C2950-24. Disponible en: cisco.com, directory:
en/US/products/hw/switches/ps628/products_data_sheet09186a00801
cfb71.html
[17] Cisco Aironet 1200. Disponible en: cisco.com, directory:
/c/en/us/products/collateral/wireless/aironet-1200-access-
point/product_data_sheet09186a00800937a6.html
[18] Cisco ASA 5505. Disponible en: cisco.com, directory:
c/en/us/support/security/asa-5505-adaptive-security-
appliance/model.html
[19] Raspbian. Disponible en: raspberrrypi.org, directory:
documentation/installation/installing-images/
[20] Zabbix Proxy. Disponible en: Zabbix.org, directory:
wiki/Zabbix_on_the_Raspberry_Pi_%28OS_Raspbian%29

59
 Anexo A

Plataforma WEB

Una de las principales cualidades de Zabbix es la forma en que muestra la

información que almacena. En este anexo se detallan los recursos
disponibles en la plataforma WEB de Zabbix.

Dashboard

El dashboard es la pantalla principal de la pestaña de monitoreo, contiene un

resumen de alertas y acceso a diversos recursos del servidor como lo son
gráficos, screns y mapas.

1. Sistem Status: Muestra un estado general del servidor.

2. Favourite Graphs: Acceso directo a los gráficos más relevantes que
crea el servidor de monitoreo.
3. Favourite Screens: Acceso directo a los screen más relevantes que
crea el servidor de monitoreo.

60
 4. Favourite Maps: Acceso directo a los principales mapas disponibles en
el servidor de monitoreo.
5. System Status: Resumen de alertas activas organizadas por nivel de
severidad en cada grupo de host.
6. Last 20 issues: últimas 20 alertas que permanecen activas.

Alertas activas

Esta pestaña contiene información acerca de las alertas que se encuentran

activas o triggers que se han activado. Las opciones disponibles permiten
filtrar por estado, nombre, severidad, estado de reconocimiento y duración de
la alerta, además de la opción de mostrar detalles de la expresión lógica que
desató la alerta.

Últimas muestras

Esta pestaña contiene el último valor recogido por cada ítem monitoreado.
Las opciones disponibles permiten filtrar por nombre de ítem, mostrar
detalles e ítems sin datos.

61
En la última columna se muestran hipervínculos, los que llevan a un gráfico
de las últimas muestras.

62
Una vez dentro del gráfico, es posible ver la tabla de valores que lo generó
en “Valores” o “Los últimos 500 valores”

Gráficos

Esta pestaña contiene todos los gráficos generados a partir de los datos
recolectados. Es posible filtrar por host y fecha.

Screens

A partir de los gráficos, mapas, historiales, estado de host, entre otros es

posible crear agrupaciones lógicas que faciliten la visualización de la
información. Estas se encuentran en la pestaña Screens

63
Mapas

Esta pestaña contiene los mapas, los cuáles muestran el estado de los host
contenidos en ellos. Cuando un host tiene una alerta activa cambia de color
dependiendo de la severidad de la alarma.

64
Historial de alertas

Esta pestaña contiene un registro histórico de alertas generadas por el

servidor. Es posible filtrar por el host o grupo de host y por fecha.

Top 100 alertas más recurrentes

Contiene un informe de las 100 alertas más recurrentes en un rango de

fechas determinado, por día, semana, mes y año

65