MANUAL DE MONITOREO

Control IT
GBM 2019
Contenido
INTRODUCCIÓN ............................................................................................................................. 3
HERRAMIENTAS ............................................................................................................................. 4
CLIENTES........................................................................................................................................ 4
TIPOS DE MONITOREO ................................................................................................................... 4
Nagios........................................................................................................................................ 4
Tivoli (TEP) ................................................................................................................................. 5
BAC ............................................................................................................................................ 5
Emergencias 911 ........................................................................................................................ 5
Banesco ..................................................................................................................................... 5
ICE Core ..................................................................................................................................... 5
GESTIÓN DE ALERTAS ..................................................................................................................... 6
GESTIÓN DE ALERTAS#1 NAGIOS & TIVOLI ................................................................................. 6
Paso #1: Identificar................................................................................................................. 6
Paso #2: Validar...................................................................................................................... 6
Paso #3: Cerrar Ticket............................................................................................................. 7
Excepciones ........................................................................................................................... 9
GESTIÓN DE ALERTAS #2 EMERGENCIAS 911 ............................................................................ 10
Paso #1: Identificar Alerta .................................................................................................... 10
Paso #2: Validar.................................................................................................................... 10
Paso #3: Cerrar Ticket........................................................................................................... 10
Datos Importantes ............................................................................................................... 11
GESTIÓN DE ALERTAS #3 BAC CREDOMATIC ............................................................................. 11
Paso #1: Identificar Alerta .................................................................................................... 11
Paso #2: Validar.................................................................................................................... 11
Paso #3: Cerrar Ticket........................................................................................................... 11
Datos importantes ............................................................................................................... 12
GESTIÓN DE ALERTAS #4 BANESCO .......................................................................................... 13
GESTIÓN DE ALERTAS #5 ICE Core ............................................................................................ 13
Paso #1: Validar.................................................................................................................... 13
Paso #2: Cerrar Ticket........................................................................................................... 13
GESTIÓN DE ALERTAS #6 Caja de Ande ..................................................................................... 14
Paso #1: Validar.................................................................................................................... 14

1
 Paso #2: Cerrar Ticket........................................................................................................... 15
Datos importantes ............................................................................................................... 15
CONCLUSIÓN ............................................................................................................................... 16

2
INTRODUCCIÓN

El siguiente manual se ha creado con el objetivo de facilitar el trabajo de aquellos colaboradores

que estén iniciando su etapa como operadores de NOC, así como también para aquellos quienes
quieran refrescar los conocimientos hasta ahora obtenidos.

En el podrán encontrar todos los temas relacionados a las operaciones diarias de monitoreo tales
como: herramientas, tipos de clientes, procesos, tareas, etc.

Cada uno de los aspectos anteriormente citados, serán explicados a detalle, tomando en cuenta
cada uno de los aspectos necesarios para cumplir de la mejor manera con las tareas a realizar.

Dicha información estará sujeta a cambios constantes, esto debido a que la naturaleza del trabajo
obliga a un constante proceso de actualización y modificación.

3
HERRAMIENTAS

Debido a la cantidad y especificación de las herramientas utilizadas en el monitoreo, se ha creado

el manual anexo “Manual para las herramientas de monitoreo”. El mismo detalla cada una de las
herramientas utilizadas por un operador de monitoreo. Algunas de las herramientas utilizadas son:

• OTRS
• Nagios
• Tivoli (TEP´s)
• Solar Winds (Ufinet)
• APM (Caja de Ande)
• Data Center Network Manager (ICE Core)
• Cisco Prime (Emegencias 911)

CLIENTES

Data Center Regional NOC cuenta con una amplia cantidad de clientes a nivel regional, sin embargo,
por temas de confidencialidad y cantidad de estos, no se detallarán en este documento.

TIPOS DE MONITOREO

El monitoreo se divide en 2 secciones, Express (Nagios) Enhanced (cuando no es Nagios)

Actualmente se cuenta con varios tipos de monitoreo, por ejemplo:

Nagios
• Nagios es actualmente el sistema de monitorización que mayor se utiliza en el NOC.
• Existe un Nagios Central, encargado de centralizar las funciones de todos los otros
monitoreos. Además, existen Nagios secundarios (Gateway) en cada DC de GBM y en los
clientes que cuenten con esta funcionalidad.
• Capaz de monitorear servers con la mayoría de los sistemas operativos, equipos de redes,
enlaces de internet, etc.
• En Nagios existen 2 tipos de monitoreo:
o Activo: cuando el Nagios consulta la información a monitorear al equipo.
o Pasivo: cuando el Nagios espera que el equipo envíe la información a monitorear

4
Tivoli (TEP)

• Después de Nagios, Tivoli es la tecnología mas utilizada para el monitoreo del NOC
• Tivoli utiliza TEP´s para el monitoreo, que es la herramienta mediante la cual se valida la
operatividad de cada equipo en monitoreo
• Existe un TEP para los clientes ICE, CIBAO y un TEP de capacidad de procesamiento, donde
se encuentran otros clientes como Bancolombia, COPA, BNP, BHD, etc.

BAC

• BAC Credomatic es un cliente del NOC.

• Se le considera un tipo de monitoreo porque se basa en la validación únicamente con el
cliente.
• Los monitoreos son: Replicas/ iSeries
• Este cliente cuenta con localizaciones en todo Centroamérica, por lo que las validaciones
se harán con el respectivo país o con DICA (Punto central).

Emergencias 911

• Emergencias 911 es un cliente del NOC.

• Utiliza la herramienta Cisco Prime para la validación de alertas.
• Además, se valida con el cliente si la alerta así lo amerita
• Links Down y Routers Unrecheable son las alertas que se gestionan

Banesco

• Banesco es un cliente del NOC.

• El proceso de gestión de alertas con este cliente se basa en la validación con personal de
GBM y con SR o INC, esto dependiendo del horario en que se gestione la alerta

ICE Core

• Es un monitoreo exclusivo de SW Nexus del cliente ICE

• Para la validación de las alertas se utiliza una herramienta de Cisco.
• Si es requerido, se debe reportar la alerta con los contactos de verificación

5
GESTIÓN DE ALERTAS

La gestión de alertas que debe realizar el operador de NOC se basa en la gestión de tickets que
ingresan al OTRS.

Cada ticket debe ser gestionado de la manera correcta, tomando en cuenta que la alerta deberá ser
atendida por el personal correcto.

Dichos tickets deben ser cerrados, sea por su notificación correspondiente, o por otro motivo
claramente expresado por el contacto de verificación.

Es importante señalar que el objetivo principal de la gestión de eventos es informar de manera

efectiva a los responsables de que algo esta ocurriendo con el (los) equipos, sea de manera escrita
(correo, chat) o por medio de llamada telefónica. Siempre asegurándose que la información llegue
al responsable.

Puntos para recalcar en la gestión de eventos:

• Cada ticket o evento se debe gestionar en su totalidad en máximo 20 minutos

• Alertas de reinicios y pérdidas de comunicación se deben atender inmediatamente.
• Colocar una nota en cada ticket o notificación siempre es de gran importancia.

GESTIÓN DE ALERTAS#1 NAGIOS & TIVOLI

Paso #1: Identificar

• Se abre el ticket.
• Se verifica a cuál tipo de monitoreo pertenece.

Paso #2: Validar

• Tomando en cuenta el tipo de monitoreo del que proviene el ticket, se procede a revisar la
CMDB.
• De acuerdo con lo que indique la CMDB, se debe realizar la validación con los contactos
correspondientes o con la herramienta de monitoreo.

6
Otro método de validación se realiza con las herramientas de monitoreo, la alerta se debe buscar
en el dashboard correspondiente y si la misma no se encuentra activa, se procede a cerrar la misma
con una captura de la evidencia:

Paso #3: Cerrar Ticket

3.1: Notificación
• Una vez realizada la validación, si la alerta persiste de acuerdo con la herramienta de
monitoreo, o el contacto de verificación indica que se envíe la alerta, se procede a realizar
la misma.
• Un aspecto muy importante para tomar en cuenta es colocar una nota de todo aquello que
se considera relevante durante el proceso de validación. Tómese esto como conversaciones,
capturas, comentarios, etc.

7
3.2: Cerrar ticket por inexistencia de la alerta
• Si de acuerdo con la herramienta de monitoreo, la alerta ya no se encuentra activa, se
procede a cerrar la misma con la evidencia de lo que se está validando.
• Si la validación se realiza con un contacto de verificación, y el mismo indica que no es
necesario notificar, se realiza lo anterior con nota de lo que se nos indicó.

8
Excepciones
Existen casos en los cuales los tickets que se reciben no deben ser gestionados por varias razones:

• No son alertas reales

• Alertas que se pueden omitir por su criticidad.

Alertas no reales
Existen tickets que, debido a diversas circunstancias, no representan una alerta real, por ejemplo,
cuando la comunicación entre los equipos y el Gateway de monitoreo sufren inconvenientes
(lentitud. Latencia, pequeñas perdidas de comunicación) que afectan el intercambio de información.

Algunos ejemplos de estos problemas pueden ser:

• Punto para recalcar, aunque un ticket como los anteriores no representa mayor afectación,
Todo un equipo alertado con estos tipos de descripción, significa Perdida de Comunicación.
• Por lo que se recomienda siempre validar el estado de un equipo cuando observamos tickets
de este tipo:

Alertas Omitidas
Otro tipo de tickets que se pueden omitir son aquellos que por su criticidad no se gestionan:

• Warning
• Yellow
• Minor

Estas vienen ubicadas en la descripción de cada ticket:

9
GESTIÓN DE ALERTAS #2 EMERGENCIAS 911

Paso #1: Identificar Alerta

• Se abre el ticket.
• Se verifica si la alerta pertenece a Link Down o Router Unrecheable.

Paso #2: Validar

• La alerta debe chequearse si aún persiste en la herramienta.
• Sila alerta corresponde a Router Unrecheable, se debe realizar una segunda validación con
los contactos de verificación en la CMDB.

Paso #3: Cerrar Ticket

3.1: Notificación
• Si la alerta corresponde a Link Down, y persiste en la herramienta de monitoreo, se debe
realizar la respectiva notificación
• Si la alerta corresponde a Router Unrecheable, persiste en la herramienta y el contacto de
verificación indica que enviamos la notificación, se procede con la misma.

3.2: Cerrar ticket por inexistencia de la alerta

• Si la alerta no persiste en la herramienta de monitoreo, se procede a cerrar el ticket con
captura que lo evidencie
• Si el contacto de verificación indica que la alerta es controlada, se cierra el ticket con lo
indicado por el mismo.

10
Datos Importantes
• El monitoreo express de emergencias 911 no es válido para gestionar, únicamente se toma
como referencia.

GESTIÓN DE ALERTAS #3 BAC CREDOMATIC

Paso #1: Identificar Alerta

• Se abre el ticket.
• Se verifica si la alerta pertenece a iSeries, Replicas Mobile First.

Paso #2: Validar

• El primer paso para validar es si cada ticket Critical, tiene su respectivo Clear
• Clear = La alerta volvió a estado OK
• Si la alerta no cuenta con su respectivo clear, se procede a hacer la validación vía telefónica
con los contactos correspondientes, encontrados en la CMDB.

Paso #3: Cerrar Ticket

3.1: Notificación
• Si la alerta corresponde a iSeries, y no cuenta con su respectivo Clear, se debe realizar la
respectiva notificación
• Si la alerta corresponde a Replicas o Mobile First, y no cuenta con su respectivo Clear y el
contacto de verificación indica que enviamos la notificación, se procede con la misma.

3.2: Cerrar ticket por inexistencia de la alerta

• Si la alerta cuenta con su respectivo Clear, se procede a cerrar el ticket con captura que lo
evidencie.
• Si el contacto de verificación indica que la alerta es controlada, se cierra el ticket con lo
indicado por el mismo.

11
Datos importantes
• El cliente BAC Credomatic, es todos sus países, realiza durante las noches un proceso
conocido como “Cierres”. En el cual, las réplicas de la mayoría de los equipos se detienen
por un periodo de varias horas. De igual forma, cada noche se deberá validar esto con los
operadores correspondientes.
• Las alertas por latencia en réplicas, en los equipos de DICA, tienen un comportamiento
normal en un rango de 0-20000.
• Los fines de semana, el cliente usualmente realiza mantenimiento en sus equipos. De igual
forma se debe validar dicha información con los operadores.

12
GESTIÓN DE ALERTAS #4 BANESCO

El cliente BANESCO tiene la particularidad de que todo su procedimiento de gestión es especial, no

se gestiona de la misma manera que el resto de tickets que ingresan al OTRS. Debido a esto, todo
el procedimiento de gestión de alertas para este cliente se encuentra detallado en el FAQ:

Dado esto, se recomienda chequear el mismo para su información.

GESTIÓN DE ALERTAS #5 ICE Core

Paso #1: Validar

• Dado que las alertas de este tipo siempre corresponden a SW Nexus, el paso a seguir es
comprobar si la alerta persiste en la herramienta “Data Center Network Manager” (Para
conocer cómo utilizar la herramienta, léase el “Manual de Herramientas de Monitoreo”)
• Una vez dentro de la herramienta, se corrobora si la alerta persiste o no.
• Si la validación da como resultado afirmativo, se prosigue a reportar la alerta con los
contactos de verificación del cliente descritos en la CMDB

Paso #2: Cerrar Ticket

2.1: Notificación
• Si la alerta persiste en la herramienta de monitoreo, se procede a validar con los contactos
de validación.
• Si al momento de validar la alerta con los contactos de verificación, los mismo indican enviar
la alerta, se procede con la misma y se cierra el ticket.

13
2.2: Cerrar ticket por inexistencia de la alerta
• Si la validación con el Data Center Network Manager muestra que la alerta ya no existe, se
cierra el ticket con la evidencia de lo anterior.
• Finalmente, si el contacto de verificación indica que se puede omitir la alerta porque es
controlada, se procede con lo indicado.

GESTIÓN DE ALERTAS #6 Caja de Ande

Paso #1: Validar

• Caja de Ande es un cliente del Data Center Regional NOC que cuenta con alrededor de 50
equipos.
• La validación de alertas de Caja de Ande se basa en el uso del Dashboard que se nos ha
facilitado, y en caso de que haya que realizar una validación extra, la misma se efectúa con
los contactos ubicados en la CMDB.
• Si la alerta persiste en la herramienta de monitoreo, se procede a validar con los contactos
de validación.
• Para conocer como validar una alerta en la herramienta, léase el “Manual de Herramientas
de Monitoreo”

14
Paso #2: Cerrar Ticket
2.1: Notificación
• Si al momento de validar la alerta con los contactos de verificación, los mismo indican enviar
la alerta, se procede con la misma y se cierra el ticket. (Sígase el procedimiento de la CMDB)

2.2: Cerrar ticket por inexistencia de la alerta

• Si la validación con el Dashboard muestra que la alerta ya no existe, se cierra el ticket con la
evidencia de lo anterior.
• De otra manera, si el contacto de verificación indica que se puede omitir la alerta porque es
controlada, se procede con lo indicado.

Datos importantes
• El cliente Caja de Ande, realiza durante las noches un proceso conocido como “Flashcopy”.
Este proceso curre entre la media noche hasta las 6am, en los servidores db2. Durante este
periodo de tiempo y en estos servidores se recibirán alertas de CPU y agentes
desconectados. Los mismos se pueden omitir.

15
CONCLUSIÓN

El anterior manual se ha creado con la intención de facilitar el entrenamiento de aquellos nuevos

operadores que ingresen al Data Center Regional NOC, así también como para aquellos que
deseen refrescar un poco los conocimientos.

El mismo queda abierto ante cualquier cambio que ocurra en el proceso o los clientes, por lo que
se invita a colaborar a todos los miembros del departamento a la mejora continua del proceso.

16