Está en la página 1de 3

INFORME DE EVIENCIAS No.

1 DE LA REVISIÓN DE EVENTOS TIME OUT SISTEMA


MONITOREO SOBRE LA APP283 – CUIDARNOS AMBIENTE PRODUCCION
Diagnóstico:
Se evidencia de parte del sistema Spectrum eventos concurrentes tipo Time Out de acuerdo al
reporte indicando generando alarmas.

De acuerdo a la revisión del log error.log de ngnix se evidencia que existe conexiones rechazadas
tanto de IPv4 e IPv6 como se muestra a continuación:

Se evidencia que existen archivos que tiene un peso al momento de desplegar los diferentes
elementos y generan un tiempo que afecta el despliegue de la aplicación. Como el ejemplo de esta
imagen pesa 9,9 MB con un promedio de tiempo en consulta de 2000 ms a 10000 ms
Posibles causas del evento:

- Por la naturaleza de la aplicación para lo que fue desarrollada al momento de realizar


consultas a contenidos con imágenes de bastante peso de forma simultánea por muchos
usuarios se genera un consumo alto de memoria lo cual activa el script de reinicio de la
capa media el cual ésta programado para ejecute cuando sea >75% el uso generando una
desconexión del servicio.

- Verificar la configuración en el ngnix.config acepte correctamente las comunicaciones por


IPv6 y este apuntando al servidor y puerto correctos.

- El sistema Spectrum genera unos picos como eventos tipo Time Out que realmente no
miden si el servicio de capa media este caído o no a través de la url, pero con la primera
causa influye en el comportamiento de este reporte en el sistema de monitoreo.
Recomendación técnica:
Acciones a Corto Plazo

- Depurar el peso de las imágenes que tengan mayor peso en MB que esta publicadas por
parte de los funcionales del MEN.
- Ejecutar como tarea programada, un script que depure la memoria de cacheo ya que el
actual está activo es el script reinicia el servicio de capa media.
- Realizar seguimiento a la aplicación de 7 a 15 días a través del sistema de monitoreo para
conocer si el sistema bajo

Acciones a Mediano Plazo


- De parte de Fabrica, Instalar un módulo de depuración de cache para borrar el exceso del
peso acumulada de memoria total.
- Realizar seguimiento a la aplicación durante los 30 días siguientes a través del sistema de
monitoreo para conocer si el sistema bajo
Acciones a Largo Plazo

- Mediante código desarrollar una funcionalidad que indique al usuario a través de la capa de
aplicación que peso máximo en KB se debe cargar y publicar los archivos en el aplicativo
para que no impacte demasiado el rendimiento y sus tiempos de respuestas cumplan con lo
pactado.

También podría gustarte