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