Monitorización de líneas de comunicación locales
Esta funcionalidad, es otra más de las componen el módulo de estadísticas y alarmas.
En algunas ocasiones, puede caerse una línea o recurso en la entidad, lo cual puede suponer, que no le lleguen o no puedan salir las transmisiones con normalidad. Esa situación es difícil de detectar, pues a veces esas caídas no dejan rastro o alarma. Cuando la entidad detecta la situación, normalmente ha pasado bastante tiempo, y es como consecuencia de que le indican la anormalidad los remotos que no se conectan o porque los operadores locales detectan que no se completa el envío o recepción de ficheros. Esta situación, suele complicarse y alargarse su solución, en el sentido de que no se actúa directamente sobre el problema, es decir, la caída o inoperatividad de la línea suele ser el último punto a analizar. Además, el producto suele estar “desatendido” con planificadores y otros, lo que hace que se desencadenen muchas más excepciones de lo habitual.
La monitorización de las líneas locales, da solución a la situación anterior. No porque solucione dichas caídas, sino porque las notifica mediante alarma (mail, sms, etc.), en cuanto las detecta, de forma que los operadores pueden investigar y actuar de forma inmediata en la dirección adecuada.
Esta funcionalidad, permite monitorizar todas las líneas locales (a elegir cuales), de la entidad, indicando cada cuanto tiempo deseamos monitorizarlas. Hay varios tipos de líneas locales: Proxy y ip.
Definiciones
Para utilizarla, se deben seguir los siguientes pasos:
Sesión de presentación y transmisión. Definir una sesión “atípica” o “conocida”, para la monitorización local, por ejemplo, local-999999999-MONLIN. Da exactamente igual las características con las que se define, lo importante es que sirve para notificar a los operadores y contiene las fichas jcl con las que se lanzarán los procedimientos (ver Adminsitración y Operación).
Entorno local editran (ver Adminsitración y Operación - Entorno local). Debe definir
La transacción de monitorización (ZTBC)
Los campos relativos a la monitorización de líneas locales, en concreto:
Time-out en minutos. Cada cuanto tiempo queremos “testear” las líneas locales. No se permite indicar un tiempo inferior a 4 minutos. No parece adecuado un testeo continuo, pues la funcionalidad consume recursos y para la verificación, hace llamadas a la red, por lo que “momentáneamente consume cvcs o sockets”, parece más lógico un testeo por ejemplo cada hora, o cada 6 horas o cada 12.
Procedimiento de monitorización (ZTBGP9C), es el procedimiento que se arranca cuando se detecta una línea caída (o cuando estaba caída y se vuelve operativa).
Líneas a monitorizar. Selección de las líneas locales a monitorizar (ip y proxys).
Si marca S en el campo 1-IP, está indicando que desea monitorizar TODOS los listener que atienden transacciones editran y que llegan por IP (SECEXIT editran).
Si marca S en el campo 3-PX está indicando que desea monitorizar las líneas asociadas a los proxys locales, así como la propia pasarela. Debe especificar en la opción 1.3.3 cuales quiere. Además, está indicando que también monitorizará los listener que atienden conexiones de la pasarela PX (SECEXIT EDITR-PR)
La sesión editran de notificación para la monitorización anteriormente definida (local-999999999-MONLIN),
Líneas locales a monitorizar (ver Administración y operación). Debe seleccionar en los Proxy locales aquellas que quiere monitorizar (además debe estar el campo adecuado del tipo de línea a monitorizar en entorno local). Para seleccionarla indique S en el campo MONITORIZAR PX.
Alarmas. (ver Adminsitración y Operación) Si quiere enviar una alarma (mail, sms, etc.) cuando se produzca la caída (o activación) de línea, debe dar de alta una máscara adecuada a la sesión de notificación (o la misma sesión local-999999999-MONIT)
Descripción de los procesos
Cada cierto tiempo (time-out indicado en entorno), se lanza un proceso que realiza lo siguiente:
Si marco en entorno local MONITORIZAR LINEAS IP = S, se verifica que los listener (transid editran que atienden llamadas nativas IP por un puerto, SECEXIT editran) están activos (si no lo están se intentan activar). Además, se hace una llamada saliente a la ip de loopback 127.0.0.1, de forma que se convierte en una llamada entrante a los distintos listener. Si contestan, parece claro que están operativos y en sesión para poder atender llamadas que les llegan desde los extremos remotos. Además, también se están probando las llamadas salientes (procesos cliente).
Si marco en entorno local MONITORIZAR LINEAS PX = S:
Se verifican los listener locales con SECEXIT = EDITR-PR de la misma forma que 1 (marcando MONITORIZAR LINEAS IP = ‘S’ con los listener locales con SECEXIT = editran)
Se verifican las pasarelas PX que tengan el parámetro MONITORIZAR = ‘S’, haciendo una llamada saliente con destino a un remoto cuya ip es la loopbak del Proxy. Este, hace la llamada y en ese momento le llega, de forma que cree que es una llamada remota, con lo que la pasa al listener zos SECEXIT = EDITR-PR. De esta forma se prueba el circuito completo: cliente zos, listener Proxy, cliente Proxy y listener zos. En caso de que llegue una aceptación, se ha probado el circuito completo. En otro caso, se determina en qué punto de todo el circuito está el problema.
Se arranca el procedimiento especificado en entorno local (ZTBGP9C) con las fichas jcl de la sesión de monitorización especificada en entorno local, en caso de:
Detectar una incidencia en una línea (siempre y cuando no estuviera marcada como que ya tenía una incidencia en curso). En ese caso, se arranca el procedimiento con función 98, causa indicando el problema y causa-diagnóstico de red. Nota: Si una línea tiene una incidencia, se marca como tal y en el siguiente testeo que se haga de la misma, no se envía incidencia si continúa en ese estado.
Detectar una línea en estado operativo o activo, siempre y cuando la línea estuviera marcada como que en el testeo anterior estaba en incidencia. En ese caso, se arranca el procedimiento con función 97.
Si se arranca el procedimiento anterior:
Se graba un mensaje en el log de alarmas. (opción 5.1 del menú principal)
Si hay una máscara adecuada (opción 5.3), con la sesión de monitorización definida en el entorno local, se envía una alarma (vía externa, e-mail o sms) con el mensaje del log de alarmas (ya sea de activación como de caída)
Errores
Se pueden dar los siguientes retornos:
Para cada retorno, se muestra causa-diagnostico o motivo más completo del error, por ejemplo, con un retorno 21, se mostraría un mensaje parecido al siguiente:
Indicando error (ZTP999), en la línea PROXY 006 porque la pasarela está caída. La IP de dicha pasarela es 172.144.026.188 y nos debería escuchar por el puerto 7779. La causa del error y el diagnostico se puede mirar en 2.3.4.6 de la interfaz gráfica.
Ejemplo:
Definida la sesión de transmisión y presentación 000099940-333333333-333333
En entorno local:
Definido en las líneas PROXY (número 1)
Se muestra el contenido de la PX-001 (campo monitorizar)
Si, por ejemplo, se detecta un error en esa línea y más tarde se soluciona, aparecerían los siguientes mensajes en el log de alarmas (opción 5.1).
Si, además, estuviera definida en la opción 5.3, se hubiera enviado el correspondiente e-mail o sms o externo. (ver R-02 de anterior pantalla, indicando que envío un sms SMTP)
Última actualización