Monitorización y salud

Cómo saber si la instalación está sana: el endpoint de salud que debe consultar un monitor externo, las pantallas de la consola que muestran el estado de los componentes y de las tareas, y las alertas

Qué es esto y cuándo usarlo

Esta página trata de la salud de la instalación: si la base de datos es alcanzable, si los componentes están en marcha, si las tareas de fondo se ejecutan. No trata de observar lo que hace un usuario dentro de una sesión; eso es la monitorización de sesión en vivo, en Auditoría › Sesiones › En línea, y responde a otra pregunta.

La monitorización de salud tiene tres capas, y la mayoría de las instalaciones solo monta la segunda:

1. Un monitor externo que consulta el endpoint de salud. Es la capa que despierta a alguien a las 03:00.

2. Pantallas de la consola: Configuración del sistema › Componentes y el panel de tareas al que se llega desde Configuración del sistema › Operaciones. Son exactas, pero hay que estar mirándolas.

3. Alertas dentro del producto: suscripciones de notificación para la conectividad del almacenamiento y el rendimiento de los componentes.

El endpoint de salud

La solución expone un endpoint de salud no autenticado en /api/health/. Devuelve JSON:

{"status":true,"db_status":true,"db_time":0.0083,"redis_status":true,"redis_time":0.0022,"time":1788772352}

Campo	Significado
status	Resultado global
db_status	Si la base de datos es alcanzable
db_time	Latencia de respuesta de la base de datos, en segundos
redis_status	Si Redis es alcanzable
redis_time	Latencia de respuesta de Redis, en segundos
time	Marca de tiempo del servidor

Apunte su monitor externo a este endpoint, no a la página de inicio. Un monitor que descarga la página de inicio de sesión demuestra únicamente que el servidor web respondió. Este endpoint demuestra que la base de datos y Redis son alcanzables: las dos dependencias cuya pérdida deja la consola inútil aunque siga devolviendo una página.

Los dos campos de tiempo son latencia en segundos. Alertar solo sobre db_status: false atrapa la caída; seguir la tendencia de db_time y de redis_time la atrapa cuando viene de camino.

En un clúster, la instalación se sitúa tras una única dirección virtual, y cada nodo responde además a /api/health/ directamente. Consulte ambos: la dirección virtual le dice si el servicio está en marcha, y las respuestas por nodo le dicen si un nodo ha desaparecido en silencio mientras la dirección sigue respondiendo desde los demás. Un monitor que vigila solo la dirección virtual no puede distinguir "el clúster está caído" de "un nodo está caído", y la segunda condición es la que pasa semanas inadvertida.

Salud de los componentes en la consola

Configuración del sistema › Componentes › Componentes lista cada microservicio registrado con su estado en vivo.

Columna	Qué le indica
Nombre	Componente registrado, con el formato [Tipo]-NombreDelServidor
Sesiones en línea	Sesiones que el componente atiende en este momento. Cero significa inactivo; un número persistentemente alto sugiere que necesita otra instancia
Stat	Uso de CPU y memoria del proceso del componente. Cerca del 100% significa que el recurso está saturado
Load status	Normal, Sin conexión o High load
Dirección remota	Dirección del servidor donde se ejecuta el componente

Sin conexión es el estado que importa. Si el componente de la API core está sin conexión, toda la plataforma queda inaccesible. Si un conector de protocolo está sin conexión, las sesiones de ese protocolo se detienen mientras todo lo demás parece correcto: la consola sigue cargando, de modo que el fallo se lee como "el RDP está roto" y no como "un componente está caído".

La fuente recomienda configurar alertas externas para los componentes sin conexión mediante un sistema de monitorización, dando Zabbix, Prometheus y Datadog como ejemplos, en lugar de confiar en que alguien abra esta pantalla.

El motor de tareas: workers y colas

Todo el trabajo automático se ejecuta en tareas de fondo: limpieza de registros, comprobaciones periódicas de activos, sincronización de cuentas y las automatizaciones basadas en Ansible. El botón Supervisión, en la parte superior de Configuración del sistema › Operaciones, abre el panel de tareas en una pestaña nueva del navegador.

Pestaña de workers. Cada fila es un proceso worker llamado queue@hostname. Se esperan dos workers: el worker de mantenimiento por defecto y el worker de automatización (Ansible). Las columnas son Worker, Estado (En línea / Sin conexión), Activo, Processed, Fallido, Succeeded, Retried y Load Average (carga del sistema a 1, 5 y 15 minutos).

Pestaña de tareas. Ejecuciones individuales: Nombre (la ruta interna de la tarea, con el formato module.submodule.task_name), UUID (haga clic para ver el detalle completo), Estado (SUCCESS, FAILURE, PENDING, RETRY), args y kwargs, Resultado, Received e Iniciado.

Pestaña del broker. Estado de las colas. Redis es el broker de tareas, con dos colas configuradas: default para el mantenimiento y las comprobaciones de sistema, y ansible para las automatizaciones que hablan con los activos gestionados. Las columnas son Cola, Messages (pendientes), Unacked (entregadas a un worker pero aún sin confirmar), Listos, Consumers e Idle since.

Un worker sin conexión detiene todas las tareas automáticas, en silencio. Limpieza, rotación de credenciales, comprobaciones de conectividad, sincronización de cuentas: todo. Nada se rompe en la consola, de modo que el síntoma aparece más tarde como datos obsoletos o como una rotación que nunca ocurrió. Si un worker está sin conexión, el servicio de tareas de ese servidor no está en marcha y la infraestructura tiene que reiniciarlo.

Dos cifras merecen seguimiento a lo largo del tiempo:

• Fallido, en la pestaña de workers, junto con los estados FAILURE de la pestaña de tareas. Los fallos repetidos apuntan a la conectividad con los activos, a un error de configuración o a una inconsistencia en la base de datos.

• Messages, en la pestaña del broker. Una cola que no deja de crecer significa que los workers no consumen al ritmo al que llega el trabajo: sobrecarga del servidor, o un worker atascado. La cola ansible es la que se acumula en entornos con muchos activos gestionados, en los picos de automatización.

En la propia lista de operaciones, dos columnas hacen el mismo trabajo para las tareas programadas: un recuento de Éxito/Total mostrado en rojo señala las ejecuciones que fallan, y la hora de la última publicación debería caer dentro del ciclo de la propia tarea. La fuente da la prueba concreta: una tarea con un ciclo de 3600 segundos que no se ha ejecutado en las dos últimas horas significa que debería ir a mirar los workers.

Alertas que conviene suscribir

Configuración del sistema › Notificaciones › Suscripción vincula tipos de evento con destinatarios. Dos de las categorías tratan de la infraestructura, y no del comportamiento de los usuarios:

Tipo de mensaje	Se dispara cuando
Almacenamiento: Conectividad	El backend de almacenamiento configurado no se puede alcanzar. Es un aviso temprano: llega antes de que las grabaciones empiecen a fallar al guardarse
Componente: rendimiento del servidor	Un componente presenta un uso alto de CPU o memoria, o un rendimiento degradado
Sesiones: comando rechazado	Un comando de una sesión en vivo fue bloqueado por la política de comandos
Job: comando rechazado	Un trabajo programado intentó ejecutar un comando bloqueado

Cada tipo tiene su propia lista de destinatarios, fijada mediante Editar destinatario. Una suscripción sin destinatario es silenciosa, lo que resulta indistinguible de que no haya ocurrido nada.

Almacenamiento y retención: el crecimiento que hay que vigilar

Los ajustes de retención, en Configuración del sistema › Retenciones, fijan cuántos días se conserva cada clase de registro. Las tareas nocturnas de limpieza borran después todo lo más antiguo.

La retención borra evidencia, y nada le avisa de que ha ocurrido. Una investigación sobre un evento más antiguo que la ventana de retención devuelve un resultado vacío, no un error, lo que es indistinguible de "nunca ocurrió". Decida los valores de retención frente a sus obligaciones de auditoría antes de necesitar la evidencia, no durante la investigación.

La segunda trampa es la separación entre metadatos y archivos:

• Los valores de retención de la consola controlan los registros de la base de datos.

• El ciclo de vida de los archivos de grabación propiamente dichos es el que diga la política de ciclo de vida del bucket o del contenedor de almacenamiento de objetos.

Se configuran en dos sitios distintos y no se coordinan. Un ciclo de vida de bucket más corto que su retención de registros de sesión deja registros de sesión que listan una reproducción que ya no existe; uno más largo conserva archivos después de que hayan desaparecido los registros que apuntaban a ellos. Los backends de almacenamiento de grabaciones se gestionan en Configuración del sistema › Almacenamiento › Almacenamiento de objetos, donde exactamente un backend está marcado como predeterminado; compruebe cuál es antes de razonar sobre dónde se guarda algo. Las sesiones gráficas (RDP) consumen mucho más espacio que las de terminal, así que el crecimiento del almacenamiento sigue la mezcla de protocolos que usa, no el número de sesiones.

Diagnóstico de red desde el servidor

Configuración del sistema › Utilidades ejecuta Ping, Telnet, Nmap, Tcpdump y Traceroute desde el servidor, con el resultado volcado en el área de Salida. Ese es justamente el objetivo: el resultado refleja la conectividad entre la solución y el activo, no entre su estación de trabajo y el activo, que es la pregunta que realmente tiene cuando una sesión no se abre.

• Telnet es el útil para un activo con problemas: prueba un puerto TCP, mientras que Ping solo prueba ICMP. Úselo antes de registrar un activo nuevo, para confirmar que el puerto del protocolo es alcanzable desde el servidor.

• Ping muestra la dirección resuelta, la latencia y la pérdida de paquetes, de modo que sirve además como comprobación de resolución DNS desde el servidor.

• Tcpdump y Nmap son las herramientas pesadas. Aplique siempre filtros de origen y de destino a un Tcpdump en producción, y trate la salida capturada como sensible: puede contener el tráfico de activos gestionados.

Las utilidades son herramientas de reconocimiento que se ejecutan desde dentro de su red. El interruptor Herramientas en la cabina, en la pestaña Básico, las deshabilita por completo, para todo el mundo, con independencia de los permisos de rol. Allí donde estén habilitadas, restrínjalas por rol a los perfiles de red e infraestructura.

Cómo verificar que su monitorización funciona de verdad

La monitorización es lo único que falla sin síntoma, porque un monitor que nunca se dispara tiene exactamente el mismo aspecto que un sistema que nunca se rompe. Compruebe el monitor, no el sistema:

1. Confirme que su comprobación externa prueba el contenido del endpoint y no solo su código de estado. Verifique que el monitor alerta cuando db_status o redis_status es false: un endpoint que devuelve HTTP 200 con db_status: false es una caída real, y un monitor que solo mira el código de respuesta la informa como sana.

2. En un clúster, compare la respuesta de la dirección virtual con la de cada nodo. Si su monitor solo tiene un objetivo, no puede ver que un nodo se caiga.

3. Confirme que una alerta llega a una persona. Abra cada suscripción de la que dependa y compruebe que el Receptor no está vacío.

4. Confirme que el motor de tareas está vivo, y no simplemente presente. En la pestaña de workers, ambos workers deben estar en línea y, en la lista de operaciones, la hora de la última publicación de una tarea de ciclo corto debe ser reciente. Un worker puede estar listado y ocioso.

5. Confirme la vía de almacenamiento de extremo a extremo abriendo una grabación reciente y reproduciéndola. Las alertas de conectividad del almacenamiento le dicen que el backend es inalcanzable; solo una reproducción le dice que las escrituras aterrizan donde las lecturas buscan.

Errores frecuentes

Síntoma	Causa	Solución
El monitor informa de un sistema sano durante una caída de la base de datos	La comprobación prueba la página de inicio de sesión o solo el código de estado HTTP	Consulte /api/health/ y alerte sobre db_status y redis_status
La consola carga pero un protocolo no puede abrir sesiones	El conector de ese protocolo está sin conexión	Revise Configuración del sistema › Componentes; reinicie el servicio del componente en el servidor donde se ejecuta
Toda la plataforma inaccesible	El componente de la API core está sin conexión	La misma pantalla; la API core es el único componente cuya pérdida se lleva todo por delante
Rotaciones, limpiezas y comprobaciones de conectividad se detuvieron todas en silencio	Un worker de tareas está sin conexión, así que no se ejecuta ninguna tarea programada	Revise la pestaña de workers desde Operaciones › Supervisión; reinicie el servicio de tareas
El número de Messages de la cola no deja de subir	Los workers no consumen al ritmo al que llega el trabajo, o uno está atascado	Revise el estado y la carga de los workers; la cola ansible se acumula primero en entornos grandes
Existen registros de sesión pero las reproducciones no se abren	Los archivos de grabación los eliminó la política de ciclo de vida del propio bucket, que es independiente de la retención de la consola	Alinee el ciclo de vida del bucket con su requisito de retención
Un evento antiguo no aparece en absoluto en el registro de auditoría	Su ventana de retención venció y la limpieza nocturna borró el registro; no se genera ningún error	Fije los valores de retención frente a sus obligaciones de auditoría con antelación
Alertas configuradas pero nunca recibidas	El tipo de mensaje no tiene destinatario	Fije el Receptor por tipo de mensaje en Notificaciones › Suscripción
A un administrador le falta en la consola una herramienta de diagnóstico	Herramientas en la cabina está deshabilitado, lo que prevalece sobre los permisos de rol	Vuelva a habilitarlo en la pestaña Utilidades › Básico y después restrinja por rol

Páginas relacionadas

• Registro de auditoría

• Grabaciones de sesión

• Informes

• Puertos

• Copia de seguridad y restauración