> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/es/pam/deploy-operate/monitoring.md). # 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 | {% hint style="info" %} **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. {% endhint %} 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**. {% hint style="warning" %} **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. {% endhint %} 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. {% hint style="danger" %} **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. {% endhint %} 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. {% hint style="warning" %} **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. {% endhint %} ## 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](/es/pam/administration/audit/audit-trail.md) * [Grabaciones de sesión](/es/pam/administration/audit/recordings.md) * [Informes](/es/pam/administration/audit/reports.md) * [Puertos](/es/pam/reference/ports.md) * [Copia de seguridad y restauración](/es/pam/deploy-operate/backup-and-restore.md)