Es el seguimiento continuo de servidores, redes y aplicaciones para detectar una falla, una lentitud o el agotamiento de un recurso. Reúne la recolección de datos de los equipos, la definición de límites aceptables y la alerta cuando esos límites se superan.

Es el conjunto de datos que el propio sistema emite sobre sí mismo: las métricas, los logs y las trazas. La observabilidad es lo que se logra hacer con esa telemetría una vez recolectada y correlacionada.

Depende de cuántas piezas atraviesa el problema. En un entorno con pocos servidores y aplicaciones independientes, un monitoreo bien configurado resuelve la mayoría de los casos. Cuando la aplicación depende de varios servicios, el monitoreo indica que está lento y no dice qué parte, y ahí es donde la observabilidad pasa a ser necesaria.

Network Operation Center es la estructura que acompaña el entorno de forma continua y trata las alertas generadas. Integrity-UX opera un NOC propio, que monitorea de forma proactiva los mensajes de dispositivos físicos y de aplicaciones.

CPU, memoria, red y disco son el piso, no el objetivo. Dicen si la máquina está sana, no si el negocio está funcionando. Un servidor puede estar al 20% de CPU y la operación detenida, porque la rutina que debía correr a las 2 de la mañana no corrió. El monitoreo que se detiene en el recurso físico avisa tarde, o no avisa.

Es verificar que el proceso que sostiene la operación ocurrió, y no solo que el equipo está en pie. En esa capa entran verificaciones como: la rutina nocturna terminó dentro de la ventana; el archivo que envía el socio llegó hasta el horario acordado; la cola de integración está drenando en lugar de acumular; el volumen de transacciones de la hora está en el rango esperado; el backup copió un volumen compatible, en lugar de reportar éxito con cero bytes; y el certificado vence en treinta días, no mañana. Ninguno de esos aparece en un gráfico de CPU, y son justamente los que la empresa suele descubrir por el cliente.

TI sola no lo logra. Quien sabe que el cierre tiene que estar listo antes de las 6, o que una cola detenida por dos horas se convierte en pérdida, es el área que responde por el proceso. TI traduce eso en una verificación automática y en una alerta para quien necesita saberlo.

En el reactivo el equipo descubre el problema cuando el usuario reclama. En el proactivo la alerta llega cuando el indicador empieza a salirse del rango, antes de la indisponibilidad. La diferencia aparece en el tiempo de respuesta y en cuántas personas fueron afectadas antes de que alguien actuara.

Sí, y es un problema común. Cuando todo genera alerta, nada se trata como alerta. Los límites tienen que salir del comportamiento real de cada entorno, y revisarse periódicamente, en lugar de copiarse de un estándar genérico.

Sí. El seguimiento cubre dispositivos físicos y aplicaciones, en el entorno que el cliente tenga.

Por el relevamiento de lo que existe y de lo que es crítico para la operación. De ahí salen los ítems a monitorear, los límites de cada uno, las reglas de negocio que necesitan verificación y quién recibe cada alerta.