En este capítulo se describen las pruebas que se realizaron con el fin de comprobar el correcto funcionamiento del modelo y así poder tener documentación sobre las pruebas de manera ordenada.
A continuación, se relacionan las tablas donde se muestran las pruebas realizadas al modelo.
Tabla 18. Prueba 1
Nombre Prueba: Recepción alarma Código Prueba: P1
Descripción:
Lo que se busca en esta prueba es que el modelo reciba la alarma sin realizar ningún mapeo alguno sobre la misma
Pasos:
Para realizar esta prueba es necesario tener en línea al servicio SNMP de la maquina ómnibus, seguido a esto se debe realizar el envío del paquete SNMP con ayuda del software diseñado en java.
Resultados esperados:
La llegada de la alarma al sistema de manera desordenada y sin ningún tipo de tratamiento.
Resultados Obtenidos:
Los resultados fueron los esperados, se envió un paquete SNMP correspondiente a PRTG y no se evidencio mapeo alguno
Nota. En esta tabla se describe el proceso de la prueba de recepción de alarma
Fuente: El autor
Tabla 19. Prueba 2
Nombre Prueba: Recepción alarma mapeada Código Prueba: P2
Descripción:
Lo que se busca en esta prueba es que el modelo reciba la alarma de crossbeam probe que ya se encuentra mapeado, por ende debería mostrar la alarma con el mapeo propuesto.
Pasos:
Para realizar esta prueba es necesario tener en línea al servicio SNMP de la máquina ómnibus, seguido a esto lo que se debe realizar es el envío del paquete SNMP con ayuda
del software diseñado en java.
Resultados esperados:
La llegada de la alarma al sistema de manera ordena correctamente mapeada por la regla correspondiente
Resultados Obtenidos:
Los resultados fueron los esperados, la alarma se observa ordenada con la severidad esperada y con el nodo previamente establecido.
Nota. En esta tabla se describe el proceso de la prueba de recepción de alarma mapeada
Fuente: El autor
Tabla 20. Prueba 3
Nombre Prueba: Clareo de alarmas Código Prueba: P3
Descripción:
Se envían dos alarmas, una alarma tipo problema con determinadas características y seguido a esto se envía una alarma con igual características, pero de tipo solución, con el fin de que se realice el clareo y posterior salida del sistema
Pasos:
Para realizar esta prueba es necesario tener en línea al servicio SNMP de la maquina ómnibus, seguido a esto lo que se debe realizar es el envío del paquete SNMP que corresponda con el paquete tipo problema y luego se envía el paquete que corresponde al tipo solución con ayuda del software diseñado en java.
Resultados esperados:
Las alarmas involucradas en la prueba deben realizar el clareo, ponerse de color verde y luego de unos minutos deben salir de sistema
Resultados Obtenidos:
Los resultados fueron los esperados, las alarmas salieron del sistema luego de pasar 5 minutos
Nota. En esta tabla se describe el proceso de la prueba de clareo de alarmas.
Fuente: El autor.
Tabla 21. Prueba 4
Nombre Prueba: Correlación de alarmas Código Prueba: P4
Descripción:
Se envía una alarma con determinadas características, seguido a esto se envía una alarma exactamente igual a la que se envió previamente
Pasos:
Para realizar esta prueba es necesario tener en línea al servicio SNMP de la maquina ómnibus, seguido a esto lo que se debe realizar es el envío del paquete SNMP con ayuda
del software diseñado en java.
Resultados esperados:
La alarma no se debe repetir 2 veces o la cantidad que se envíe en el momento, lo único que debe pasar es que el campo count de la alarma tendrá que aumentar
Resultados Obtenidos:
Los resultados fueron los esperados, el campo count se aumentó la cantidad de veces que se envió la alarma
Nota. En esta tabla se describe el proceso de la prueba de correlación de alarmas.
Fuente: El autor.
Tabla 22. Prueba 5
Nombre Prueba: Verificación de sintaxis Código Prueba: P5
Descripción:
Cada vez que se realiza un cambio o integración de un nuevo probe se debe realizar la verificación de sintaxis de los archivos de reglas.
Pasos:
Para realizar esta prueba es necesario tener acceso a la maquina ómnibus, seguido a esto se debe ir a la ruta donde se encuentra el comando correspondiente a verificar los archivos de reglas, cuando se ejecute este comando tendrá que dar una respuesta exitosa
Resultados esperados:
En la traza o resultado del comando se tendrá que ver que la sintaxis de los archivos de reglas es correcta
Resultados Obtenidos:
Los resultados fueron los esperados, sin embargo, se tuvieron que realizar algunos cambios en los archivos de reglas debido a que había errores.
Nota. En esta tabla se describe el proceso de la prueba de verificación de sintaxis.
Fuente: El autor.
Tabla 23. Prueba 6
Nombre Prueba: Conexión ssh a máquina omnibus Código Prueba: P6
Descripción:
Es necesario realizar conexiones ssh a la máquina de ómnibus, con el fin de realizar procesos desde otras máquinas para evitar una sobre carga de procesos, de esta forma se ahorran recursos ya que no se hace uso del entorno grafico
Pasos:
Para realizar esta prueba es necesario tener en línea la maquina correspondiente a ómnibus, se debe lanzar el comando ssh con el usuario y contraseña que permita el
ingreso a la máquina.
Resultados esperados:
Se debe poder acceder a la máquina de ómnibus desde otras maquinas
Resultados Obtenidos:
Los resultados fueron los esperados
Nota. En esta tabla se describe el proceso de la prueba de conexión ssh a máquina omnibus.
Fuente: El autor.
Tabla 24. Prueba 7
Nombre Prueba: Actualización de alarmas desde impact Código Prueba: P7
Descripción:
Se debe tener interacción entre el aplicativo impact y el objectserver el cual aloja los datos de las alarmas que están presentes en el sistema, con el fin de verificar esta conectividad se actualizan campos de la alarma.
Pasos:
Es necesario tener creado el modelo de datos en impact, seguido a esto se debe realizar el test de conexión que provee el aplicativo y poner en ejecución la política de prueba que se encarga de la actualización del campo
Resultados esperados:
Se tendrá que ver el campo que se seleccionó para modificar con los valores que se le enviaron desde el aplicativo impact
Resultados Obtenidos:
Después de realizar algunos cambios en el query que se encargaba de traer la alarma, los resultados fueron los esperados,
Nota. En esta tabla se describe el proceso de la prueba de actualización de alarmas desde
impact
Fuente: El autor.
Tabla 25. Prueba 8
Nombre Prueba: Subida de Dashboard e Impact Código Prueba: P8
Descripción:
Es necesario poner en modo online los dos aplicativos para asegurar un correcto funcionamiento del modelo.
Pasos:
Se debe tener acceso a las maquinas que tengan configurados y montados los dos aplicativos mencionados, seguido a esto se deben lanzar los comandos correspondientes a su puesta online
Resultados esperados:
Se tendrá que tener acceso a los entornos web de cada aplicativo
Resultados Obtenidos:
Los resultados fueron los esperados en un tiempo de espera de 10 minutos subiendo los aplicativos
Nota. En esta tabla se describe el proceso de la prueba de subida de Dashboard e Impact
Fuente: El autor.
Tabla 26. Prueba 9
Nombre Prueba: Creación de tickets Código Prueba: P9
Descripción:
Se debe crear un ticket en el aplicativo máximo desde el aplicativo impact
Pasos:
Para realizar esta prueba es fundamental tener las políticas necesarias para crear los tickets. Previamente a esto se debe tener una alarma que dispare el flujo a la cual se deberá asociar el ticket creado
Resultados esperados:
Creación de un ticket con la alarma que disparo el flujo relacionada
Resultados Obtenidos:
Los resultados fueron los esperados, luego de varios intentos fallidos en la creación del ticket
Nota. En esta tabla se describe el proceso de la prueba de subida de Creación de tickets
CONCLUSIONES
Se diseñó un modelo el cual está en capacidad de recibir alarmas de equipos de red, vía SNMP, con el fin de que estas se pueden visualizar en un aplicativo dando al usuario final comodidad en la lectura y abriendo la posibilidad de realizar automatismos que gestionen las alarmas presentes en el sistema.
Se realizó la implementación e integración de los aplicativos necesarios con el fin de tener un correcto funcionamiento del modelo, dando así solución a la problemática inicialmente planteada.
Con el fin de tener enriquecimiento y correlación de alarmas, se realizaron políticas en el aplicativo impact y customizaciones dentro de los archivos de reglas, brindando así comodidad en la lectura y automatización de los procesos.
En el objectserver se realizó el diseño de la tabla alerts.status, en la cual se guardan los datos que tienen las alarmas activas dentro del aplicativo ómnibus, esto con el fin de poder tener visualización de las mismas en el aplicativo ómnibus/dashboard.
Se realizó el mapeo de las alarmas para hacer más fácil y cómoda la interpretación de estas para el usuario final, sin ser necesaria la conexión a elementos, ahorrando así tiempos y recursos, de la misma manera se gana efectividad en la resolución de problemas.
RECOMENDACIONES
En la realización de este proyecto se pudo evidenciar que el modelo tiene la característica de ser escalable, pero se deben tener en cuenta algunas recomendaciones:
• Para tener un mayor control sobre la finalidad del modelo que es un incidente, es posible realizar automatismos dentro del aplicativo máximo, en los cuales se considere realizar órdenes de trabajo, asignación a grupos de trabajo específicos para cada tipo de falla, y además tareas asociadas al incidente.
• En cuanto al aplicativo Impact, es posible realizar políticas que se encarguen de dar un diagnostico a fondo, realizando conexiones ssh o telnet (según corresponda) a los equipos que están reportando las fallas, con estas acciones será posible que el incidente en máximo tenga más detalles sobre la falla presentada.
• Realizar la inserción de todos los elementos de la red en el aplicativo máximo, con el fin de tenerlos disponibles en el aplicativo para poder realizar el enriquecimiento de todas las alarmas que se reporten en el aplicativo.
• Es importante que se tenga un estándar de modificación de los archivos de reglas, con el fin de tener documentación de los cambios, en este punto es importante tener un respaldo de cada uno de los archivos, teniendo en cuenta en el respaldo datos como fecha de modificación, motivo del cambio y la persona que realizó el cambio.
• Se debe monitorear constantemente las maquinas en las cuales están implementados los aplicativos, debido a que cada acción que se realiza dentro de ellos se logra capturar por medio de archivos de logs, estos pueden
ser un apoyo muy importante en las fallas presentadas.
• Es importante tener un inventario de cada uno de los equipos de red que posee la empresa u organización que haga uso del modelo, esto con el fin de siempre tener un enriquecimiento óptimo y que proporcione datos que puedan ayudar a brindar más información sobre los equipos que se encuentren en falla.
BIBLIOGRAFIA
BOTERO A., Nicolás. Modelo de gestión de seguridad con soporte SNMP. Tesis para optar al título de ingeniero de sistemas. Bogotá: Pontificia Universidad Javeriana, 2005. 149 p.
CALDERÓN C. Lina. Implementación de IBM tivoli netcool ómnibus para la gestión de fallas de una RED LTE en una solución de gestión unificada de servicios de telecomunicaciones. Tesis para optar al título de ingeniera de telecomunicaciones. Bogotá: Universidad Santo Tomás, 2016. 94 p.
ERLANG Diciembre, 2018. “Simple network management protocolo SNMP”. Internet: http://erlang.org/doc/apps/snmp/snmp.pdf
GRUPO MPR. (s.f). “¿Por qué grupo MPR?”. Internet: https://www.grupompr.com GONZALEZ A. Rafael. Diseño e implementación de un sistema de monitoreo basado en SNMP para la red nacional académica de tecnología avanzada. Tesis para optar al título de ingeniero en telecomunicaciones. Bogotá: Universidad Santo Tomas, 2014. 86 p.
HUIDROBO M. José, MILLAN T. Ramón & ROLDAN M. David. Tecnología de telecomunicaciones. Creaciones Copyright, 2017. 114 p.
IBM knowledge center. (s.f). “Introducción a tivolinetcool/ómnibus”. Internet: https://www.ibm.com/support/knowledgecenter/es/ssshtq_8.1.0/com.ibm.netcool_o mnibus.doc_8.1.0/omnibus/wip/user/concept/omn_ovr_introtonetcoolomnibus.html
IBM knowledge center. (s.f). “What's new in netcool/impact”. Internet: (https://www.ibm.com/support/knowledgecenter/ssshyh_7.1.0.11/com.ibm.netcooli mpact.doc/whatsnew.html
IBM knowledge center. (s.f). “Componentes del lenguaje de políticas”. Internet: https://www.ibm.com/support/knowledgecenter/es/ssshyh_7.1.0.6/com.ibm.netcooli mpact.doc/policy/impact_policy_language_c.html
IBM knowledge center. (s.f). “Introduction to tivolinetcool/ómnibus”. Internet: https://www.ibm.com/support/knowledgecenter/en/ssshtq_8.1.0/com.ibm.netcool_o mnibus.doc_8.1.0/omnibus/wip/user/concept/omn_ovr_introtonetcoolomnibus.html
IBM knowledge center. (s.f). “Funciones de netcool/impact”. Internet: https://www.ibm.com/support/knowledgecenter/es/ssshyh_7.1.0.6/com.ibm.netcooli mpact.doc/policy/webtop_overview.html
IBM knowledge center. (s.f). “Introduction to tivolinetcool/ómnibus”. Internet: https://www.ibm.com/support/knowledgecenter/en/ssshtq_8.1.0/com.ibm.netcool_o mnibus.doc_8.1.0/omnibus/wip/user/concept/omn_ovr_introtonetcoolomnibus.html
IBM knowledge center. (s.f). “Funciones de netcool/impact”. Internet: https://www.ibm.com/support/knowledgecenter/es/ssshyh_7.1.0.6/com.ibm.netcooli mpact.doc/policy/webtop_overview.html
IBM knowledge center. (s.f). “SNMP probe”. Internet: https://www.ibm.com/support/knowledgecenter/ssshtq/omnibus/probes/snmp/wip/c oncept/snmp_introduction_c.html
IBM knowledge center. (s.f). “Conceptos y diseño de MIB”. Internet: https://www.ibm.com/support/knowledgecenter/es/ssshtq_7.4.0/com.ibm.netcool_o mnibus.doc_7.4.0/omnibus/wip/ua_mibmgr/reference/omn_ref_mib_mibconcepts.h tml
IBM. “Guía de instalación y despliegue, 2017”. Internet: https://www.ibm.com/support/knowledgecenter/es/ssshtq_8.1.0/com.ibm.netcool_o mnibus.doc_8.1.0/omn_pdf_ins_master.pdf
IBM knowledge center. (s.f). “Utilización de netcoolMIB manager”. Internet:
https://www.ibm.com/support/knowledgecenter/es/ssshtq_7.4.0/com.ibm.netcool_o mnibus.doc_7.4.0/omnibus/wip/ua_mibmgr/concept/using_the_mib_manager.html
ITHIEL DE SOLA, Pool. Tecnología sin fronteras. Tercera edición. México: Fondo de cultura económica, 2017. ISBN 978-16-5116-7
MATA G. Manuel. Implementación de un sistema de monitorización para empresas. Barcelona. Tesis para optar al título de ingeniería técnica en sistemas. Barcelona: Universidad de Barcelona, 2012. 152 p.
MÉTODOS (s.f). “Metodología RUP”. Internet: https://metodoss.com/metodologia- rup/
ORACLE. “SNMP MIB”. Internet:
https://docs.oracle.com/cd/e13203_01/tuxedo/tux81/snmpmref/1tmib.htm
PANDORAFMS. El extraño caso del SNMP: una historia noir sobre protocolos. 2018. Internet: https://blog.pandorafms.org/es/que-es-snmp/
SMITH S. Tracy. (s.f). “Conozca la diferencia entre EAM y CMMS”. Internet: https://reliabilityweb.com/sp/articles/entry/eam-and-cmms-know-the-difference
SIEMENS. “MIB (Management Information Base) en el SNMP”. 2003. Internet: https://support.industry.siemens.com/cs/document/15177711/-mib-(management- information-base)-en-el-snmp-?dti=0&lc=es-co
VALLE V. Patricio. Diseño e implementación de un sistema de monitoreo basado en SNMP para una red de telefonía IP asterisk. Tesis para optar al título de ingeniero civil electrónico. Valparaíso: Universidad Técnica Federico Santa María, 2007. 107 p.