Observability

El módulo Observability amplía las capacidades de WOCU-Monitoring mediante la explotación de datos almacenados en un backend basado en Elasticsearch. Esta funcionalidad permite consultar, analizar y contextualizar la información asociada a una infraestructura monitorizada, facilitando una visión más completa del comportamiento de los activos, sus métricas y los eventos generados en la plataforma.

Además, el módulo incorpora un Asistente de IA integrado en WOCU-Monitoring, orientado a agilizar el diagnóstico de incidencias sobre Dispositivos, Servicios y Problems. A través de esta funcionalidad, el usuario puede solicitar análisis asistidos, obtener contexto sobre el estado de los elementos monitorizados y continuar la investigación desde una conversación tipo chat dentro de la propia interfaz.

Configuración del Reino de Observabilidad

Configuración manual

Importante

Toda la configuración de espacios, claves y privilegios descrita en las siguientes fases debe realizarse directamente desde la página o interfaz de Elastic (Elasticsearch), ya que este procedimiento es nativo de dicha plataforma.

La configuración se basa en tres elementos principales:

La creación de un Space en Elastic asociado al Reino.
La definición de un rol personalizado con permisos limitados al Reino.
La generación de una API Key vinculada a dichos permisos.

A continuación se redacta el proceso completo:

1. Acceso al proyecto de Observabilidad en Elastic

Acceda a la interfaz de Elasticsearch y seleccione el Serveless Project de observabilidad configurado por su administrador o owner de Elastic.

Atención

Verifique que se encuentra en el entorno correcto antes de crear espacios, roles o claves API. Esta comprobación es importante para evitar que las credenciales se generen en un proyecto distinto al que utilizará WOCU-Monitoring

2. Creación del Space asociado al Reino

El primer paso consiste en crear un Space en Elastic para el Reino de Observabilidad.

Para ello:

Despliegue el menú lateral Admin and settings > Spaces.

Cree un nuevo espacio a través de la opción + Create Space.

A continuación, configure los siguientes campos en el formulario de creación:

Name: indique un nombre representativo para el Reino (e. g. central_1). Es obligatorio que el nombre del espacio coincida con el nombre funcional del Reino.

Initials: indique un termino breve que aparecerá dentro del recuadro del avatar del Space (e. g. C1).

Cross-project search: seleccione la opción This project, para que las búsquedas se limiten únicamente a los datos del proyecto actual. Es la opción recomendada para mantener el foco en un solo entorno y optimizar el rendimiento de las consultas.

Si el espacio no es su entorno de trabajo actual, haga clic en Switch to this space. Al hacerlo, la sesión de Kibana se redirigirá automáticamente hacia el nuevo espacio (central_1).

3. Creación del rol personalizado

Para evitar el uso de credenciales con permisos globales, debe crearse un rol personalizado asociado al Reino. Este rol actúa como referencia de permisos y permite delimitar el acceso únicamente a los recursos necesarios, como los índices de métricas, eventos o logs del Reino y su Space correspondiente en Kibana.

Para ello:

Despliegue el menú lateral Admin and settings > Custom Roles.

Cree un nuevo role a través de la opción + Create role.
En la parte superior del formulario de creación deben configurarse los datos identificativos del rol:
Role name: nombre único del rol. No podrá modificarse una vez creado. Se recomienda utilizar una nomenclatura homogénea que incluya el identificador del Reino (e. g. central_1).

Role description: descripción funcional del rol. Este campo ayuda a identificar el propósito del rol dentro de Elastic (e. g. Kibana base user role for central_1).

Data Layer: en esta sección se definen los permisos de acceso a los datos almacenados en Elastic.
Index privileges: se deben indicar los índices asociados al Reino. Estos índices delimitan los datos que el rol podrá consultar. Para un Reino con identificador central_1, los índices a configurar serían:
metrics-wocu-central_1
monitoring-events-central_1
syslogs-central_1
traps-central_1
Privileges: debe asignarse el permiso: read. Este permiso permite consultar la información de métricas, eventos y logs del Reino, sin conceder capacidad de escritura ni administración sobre los índices.
Grant access to specific fields y Grant read privileges to specific documents deben permanecer desactivadas, salvo que se necesite aplicar un filtrado adicional por campos o documentos.

Application Layer: en esta sección se define a qué Space y funcionalidades tendrá acceso el rol dentro de Kibana.

Spaces: seleccione únicamente el Space asociado al Reino (e. g. central_1). No se recomienda asignar el rol a todos los Spaces, ya que rompería el aislamiento entre Reinos.

Privileges: seleccione la opción Custom para asignar únicamente los permisos necesarios. Como criterio general, el rol debe permitir el acceso de lectura a las funcionalidades necesarias para consultar la información de observabilidad del Reino, evitando permisos de administración.
Una vez configurados los campos anteriores, pulse Create role para guardar el nuevo rol.

4. Creación de la API Key

La API Key permite que WOCU-Monitoring y sus componentes se conecten de forma segura a Elastic para leer y escribir datos de observabilidad del Reino, como métricas, eventos, syslogs o traps.

Su uso evita recurrir a credenciales globales o usuarios personales, y permite limitar el acceso únicamente a los índices y recursos asociados al Reino.

Para ello:

Despliegue el menú lateral Admin and settings > API KEYS.
Cree una nueva API a través de la opción + Create API key.

En el formulario de creación, configure los campos:

Name: nombre descriptivo de la nueva API (e. g. central_1). Se recomienda utilizar una nomenclatura homogénea que incluya el identificador del Reino.

Control security privileges: desde esta opción se limita el alcance de la clave. Al habilitarla, Elastic mostrará un editor en formato JSON desde el que es posible definir los privilegios concretos que tendrá la API Key.
Copie el siguiente código JSON en el editor para asignar los permisos de escritura y definir los índices de su Reino.

Atención

Debe sustituir [nombre del reino] por el identificador real de su Reino.

{
"role-read-write-[nombre del reino]": {
    "cluster": [
    "monitor_inference"
    ],
    "indices": [
    {
        "names": [
        "monitoring-events-[nombre del reino]",
        "metrics-wocu-[nombre del reino]",
        "syslog-[nombre del reino]",
        "flexwan-[nombre del reino]",
        "traps-[nombre del reino]",
        "import_tool_cache_conf_hosts",
        "import_tool_cache_conf_hostgroups",
        "import_tool_cache_realms_info",
        ".ml-anomalies-wocu-ml-job-[nombre del reino]",
        "*[nombre del reino]*",
        "task_summaries",
        "livestatus_evolution"
        ],
        "privileges": [
        "read",
        "write",
        "create_index",
        "view_index_metadata"
        ],
        "allow_restricted_indices": false
    }
    ],
    "applications": [
    {
        "application": "kibana-.kibana",
        "privileges": [
        "feature_agentBuilder.all",
        "feature_actions.read"
        ],
        "resources": [
        "space:[nombre del reino]"
        ]
    }
    ],
    "run_as": [],
    "metadata": {},
    "transient_metadata": {
    "enabled": true
    }
}
}

Una vez editado el JSON, haga clic en el botón Create API KEY.

Permisos requeridos por el Asistente de IA (Elastic Agent Builder)

El IA Assistant utiliza la API de Elastic Agent Builder, que requiere licencia Enterprise y, como mínimo, Elastic Stack 9.3.

La API Key del Reino debe incluir el privilegio de aplicación feature_agentBuilder.all sobre kibana-.kibana, tal y como aparece en el JSON anterior.

El nivel read basta para conversar, pero la contabilidad interna de consumo usa una API que Kibana autoriza con el privilegio manageAgents, incluido únicamente en feature_agentBuilder.all (verificado empíricamente: con read devuelve 403 indicando agentBuilder:manageAgents).

Por otro lado, feature_agentBuilder.all concede también crear, editar y borrar agentes y tools. Por eso el ejemplo acota el privilegio de aplicación al Space del Reino mediante "resources": ["space:[nombre del reino]"]; usar ["*"] lo extendería a todos los Spaces de Kibana y no se recomienda. Si su versión de Kibana expone el sub-privilegio manage_agents de forma independiente, puede sustituir feature_agentBuilder.all por ["feature_agentBuilder.read", "feature_agentBuilder.manage_agents"]; valídelo contra su despliegue antes de aplicarlo en producción.

Disponibilidad según la versión de Elastic:

Stack 9.4 o superior: Agent Builder es la experiencia de chat por defecto. No requiere ninguna acción adicional.
Stack 9.3: Agent Builder está disponible como preview y debe activarse manualmente desde el selector de experiencia de chat de Kibana. Si no se activa, las llamadas a /api/agent_builder/* no están disponibles aunque la API Key tenga los privilegios correctos. En 9.3 el chat funciona, pero la contabilidad de consumo (POST /api/agent_builder/agents/{agent_id}/consumption) no está disponible: WOCU-Monitoring omite la sincronización horaria y los informes de uso y coste del Asistente de IA quedan incompletos. La contabilidad de consumo requiere Stack 9.4 o superior (o Serverless).
Serverless: viene activado por defecto.
Stack 9.2 o anterior: no soportado.

Sin este privilegio, todas las llamadas a /api/agent_builder/* devuelven 403 Forbidden y el Asistente de IA no funciona, aunque el resto de funcionalidades de observabilidad del Reino sí operen con normalidad.

Adicionalmente:

El rol de ejemplo no concede privilegios de cluster genéricos ("cluster": ["all"] otorgaría todos los privilegios de cluster y no es necesario para WOCU-Monitoring). Incluye únicamente monitor_inference, que solo hace falta si el agente utiliza un conector de IA que invoca la Inference API de Elasticsearch (por ejemplo, los conectores gestionados por Elastic); si no es el caso, puede dejar la lista de cluster vacía.
Las tools del agente requieren read y view_index_metadata sobre los índices que consulten. Ambos están incluidos en el bloque de índices del Reino.
El privilegio feature_actions.read es necesario para listar los conectores de inferencia disponibles (/api/actions/connectors). Basta con acceso de lectura: WOCU-Monitoring únicamente consulta el listado, no crea ni modifica conectores.
La contabilidad interna de consumo del Asistente de IA (tarea periódica de WOCU-Monitoring) consulta POST /api/agent_builder/agents/{agent_id}/consumption, disponible a partir de Stack 9.4 (y en Serverless). Aunque es una operación de lectura, Kibana la autoriza con el privilegio agentBuilder:manageAgents, por lo que la API Key del Reino necesita feature_agentBuilder.all. En Stack 9.3 y en despliegues sin Agent Builder disponible la recolección se omite automáticamente.
En despliegues creados antes de la migración a Agent Builder, el rol concedía feature_observabilityAIAssistant.all y privilegios sobre el índice interno .kibana-observability-ai-assistant-conversations*. Ambos han dejado de utilizarse: las conversaciones se gestionan ahora mediante la API de Agent Builder y no mediante acceso directo al índice. Al actualizar una API Key existente, sustituya el privilegio antiguo por feature_agentBuilder.all, elimine el bloque de dicho índice y reduzca feature_actions.all a feature_actions.read.

5. Obtención del Token

La plataforma generará la clave en tres formatos de salida: Encoded, Beats y Logstash.
En esta ocasión, seleccione y copie el token en formato Encoded y guarde este valor temporalmente, ya que se utilizará en la siguinte sección, específicamente en la varible ELASTICSEARCH_API_KEY.
Opcionalmente, también puede seleccionar los formatos Beats y Logstash, necesarios para la configuración de Fluentd y TD-Agent.

6. Configuración de Variables del Reino

Una vez obtenidos los datos de Elastic, acceda al fichero de configuración del Reino e introduzca las siguientes variables de entorno obligatorias:

Importante

Las variables deben validarse con la configuración utilizada por ingeniería en cada despliegue.

Variables de Servidor e Ingesta (Sección: Monitoring)

LOGGER_SERVER: Endpoint público de Elasticsearch asociado al proyecto.
LOGGER SERVER="endpoint"
El valor de la variable se obtiene desde la consola de Elastic, accediendo al proyecto Serverless de Observabilidad correspondiente.

La ruta de acceso es la siguiente: Serverless projects > [nombre_del_proyecto] > Overview

A continuación, localice el bloque Application endpoints, cluster and component IDs y seleccione la opción Elasticsearch.

METRIC_SERVER: Servidor de métricas (mismo valor que en LOGGER_SERVER).
METRIC_SERVER="endpoint"
ELASTICSEARCH_API_KEY: Clave de autenticación copiada en formato Encoded (Paso 5. Obtención del Token). Conecta el sistema para lectura/escritura de métricas, eventos y notificaciones.
ELASTICSEARCH_API_KEY="clave de autenticación"
Otras Variables de Configuración Obligatorias

ELASTICSEARCH_SERVERLESS_MODE: Modo obligatorio para entornos Serverless (siempre activo).
ELASTICSEARCH_SERVERLESS_MODE="True"
GCONF_ENABLED: Activa el servicio de Gconf (siempre activo).
GCONF_ENABLED="True"
GCONF_SERVICES_HOST: URL de acceso a la máquina de configuración proporcionada. Debe indicarse incluyendo el protocolo, la dirección IP y el puerto correspondiente.
GCONF_SERVICES_HOST="https://[IP]:[PORT]"
MYSQL_SERVER: IP de la base de datos central provista.
MYSQL_SERVER="IP"
MYSQL_USER: Añade el nombre del reino según corresponda.
MYSQL_USER="nombre_reino"
MYSQL_ROOT_PASSWORD: Contraseña de acceso a la base de datos (mismo nombre del reino).
MYSQL_ROOT_PASSWORD="nombre_reino"

Nota

Para infraestructuras distribuidas también se requiere la autenticación de ProxySQL.

7. Creación de un Reino de observabilidad en WOCU-Monitoring

Finalmente, el módulo de Observability se habilita desde el propio formulario de creación de un Reino, configurado con backend Elasticsearch.

Para crear un nuevo Reino estándar de monitorización, acceda al menú Settings y haga clic en el botón + New Realm, tal y como se muestra en la siguiente imagen:

../../_images/2_093c_aggregator_home-view_add-new-realm_home-empty_0-48.png

Esta acción abrirá el formulario de creación del Reino. A continuación, deberán configurarse los campos descritos en los siguientes apartados:

Display Name: añada el nombre del Reino (e. g. central_1).

Import Tool: para añadir un primer Import Tool, accione la función + anexa al campo.

../../_images/add_realm_import-tool_script.png

Los campos que deben modificarse para dar de alta un nuevo Import Tool son:

Name: añada el nombre del Reino (e. g. central_1).

Import tool host: dirección IP o nombre del host donde se aloja el Import Tool (e. g. 10.57.20.73).

Import tool port: puerto de conexión a la API del Import Tool (e. g. 50280).

Import tool API Protocol: protocolo utilizado por WOCU-Monitoring para conectarse a la API del Import Tool. Seleccione en el desplegable la opción http.

API Optimization: marque la casilla para habilitar la optimización de las consultas realizadas contra la API del Import Tool.

A continuación:

Confirme los cambios efectuados mediante el botón Create.

Seleccione el nuevo Import Tool en el desplegable para continuar.

Monitoring Host: dirección IP o nombre de la máquina donde se aloja la base de datos (e. g. 10.57.20.73).

Monitoring port: puerto de red del servidor. Por defecto, 50000.

Backend technology: seleccione la opción Elasticsearch.

Elasticsearch backend: en este nuevo selector puede dar de alta un nuevo backend accionando la función +.

Los campos que deben modificarse son:

Backend name: nombre identificativo del backend de Elasticsearch. Debe ser un valor único y fácilmente reconocible por el usuario (e. g. elasticsearch9-produccion).

Elasticsearch URL: URL de los nodos de Elasticsearch 9 a los que se conectará WOCU-Monitoring.

En despliegues gestionados desde la consola de Elastic, el valor debe obtenerse accediendo al proyecto Serverless de Observabilidad correspondiente.

La ruta de acceso es la siguiente:

Serverless projects > [nombre_del_proyecto] > Overview

A continuación, localice el bloque Application endpoints, cluster and component IDs, seleccione la opción Elasticsearch y copie el valor mostrado en Public endpoint.

Este endpoint será el valor que deberá configurarse en el campo Elasticsearch URL.

API Key: esta API Key se genera desde la propia herramienta de Elastic. Aquí debe introducir la clave generada en el paso 3. Obtención del Token de este mismo proceso, correspondiente a la API Key propia del Reino.

A continuación:

Confirme los cambios efectuados mediante el botón Create.

Seleccione el nuevo backend en el desplegable para continuar.

Metric Index: añada el nombre del Reino (e. g. central_1). El sistema añadirá internamente el prefijo correspondiente al índice de métricas.

Monitoring Events Index: añada el nombre del Reino (e. g. central_1). El sistema añadirá internamente el prefijo correspondiente al índice de eventos de monitorización.

Observability: marque esta casilla para habilitar el módulo de Observability en este nuevo Reino.

Host Name: añada el nombre del Reino (e. g. central_1).

Una vez introducidos todos los datos requeridos, guarde la configuración del formulario mediante el botón Add Realm.

8. Habilitar observabilidad en un Reino ya existente

Se puede dar el caso, en que se quiera habilitar el módulo de Observability en un Reino existente.

Para ello, haga clic en la opción Configuration, accesible desde el selector Settings. Esta acción abrirá una nueva ventana del navegador con acceso al módulo avanzado WM Console Admin, desde donde se gestionan múltiples funciones avanzadas de WOCU-Monitoring.

A continuación, seleccione la opción Realm en el menú lateral izquierdo y acceda al Reino que desea modificar. Una vez dentro de su perfil de edición, active la casilla Observability.

Por último, guarde los cambios mediante el botón Save y regrese al Reino para comenzar a utilizar las funcionalidades del módulo.

¡Enhorabuena! La configuración inicial del módulo Observability se ha completado correctamente.

Configuración mediante un Script

La configuración mediante script permite automatizar la creación del Reino de Observabilidad en el Cloud de Elastic, reduciendo la intervención manual y facilitando una configuración homogénea entre distintos entornos.

A continuación se redacta el proceso completo:

1. Solicitud de la API Key maestra

Antes de ejecutar el script, solicite al administrador del entorno Cloud o superadmin la API Key maestra de Elastic.

Esta clave se genera una única vez y, por defecto, debe existir previamente en el entorno. La API Key maestra dispone de permisos suficientes para crear y configurar los recursos necesarios del Reino de Observabilidad en Elastic.

Una vez obtenida esta clave, ya se dispone de la credencial necesaria para continuar con el proceso de configuración mediante script.

Importante

La API Key maestra debe utilizarse únicamente para tareas de provisión o configuración inicial. No debe emplearse como credencial operativa del Reino, ya que dispone de permisos globales sobre el entorno.

2. Creación de la API Key del Reino

Una vez disponible la API Key maestra, debe crearse una API Key secundaria asociada al Reino de Observabilidad. Esta será la clave operativa que utilizará el Reino, con permisos acotados mediante una estructura JSON de privilegios.

Para crearla, siga los siguientes pasos:

Acceda a la interfaz de Elasticsearch y seleccione el Serveless Project de observabilidad configurado por su administrador o owner de Elastic.

Atención

Verifique que se encuentra en el entorno correcto antes de crear espacios, roles o claves API. Esta comprobación es importante para evitar que las credenciales se generen en un proyecto distinto al que utilizará WOCU-Monitoring
Acceda al Space by default.
Navegue hasta menú lateral Admin and settings > API KEYS y cree una nueva API Key.

En el formulario de creación, configure los campos:

Name: nombre descriptivo de la nueva API (e. g. central_1). Se recomienda utilizar el mismo identificador que el del Reino.

Control security privileges: desde esta opción se limita el alcance de la clave. Al habilitarla, Elastic mostrará un editor en formato JSON desde el que es posible definir los privilegios concretos que tendrá la API Key.

Copie el siguiente código JSON en el editor para asignar los permisos de escritura y definir los índices de su Reino.

Atención

Debe sustituir [nombre del reino] por el identificador real de su Reino.

{
"role-read-write-[nombre del reino]": {
    "cluster": [
    "monitor_inference"
    ],
    "indices": [
    {
        "names": [
        "monitoring-events-[nombre del reino]",
        "metrics-wocu-[nombre del reino]",
        "syslog-[nombre del reino]",
        "flexwan-[nombre del reino]",
        "traps-[nombre del reino]",
        "import_tool_cache_conf_hosts",
        "import_tool_cache_conf_hostgroups",
        "import_tool_cache_realms_info",
        ".ml-anomalies-wocu-ml-job-[nombre del reino]",
        "*[nombre del reino]*",
        "task_summaries",
        "livestatus_evolution"
        ],
        "privileges": [
        "read",
        "write",
        "create_index",
        "view_index_metadata"
        ],
        "allow_restricted_indices": false
    }
    ],
    "applications": [
    {
        "application": "kibana-.kibana",
        "privileges": [
        "feature_agentBuilder.all",
        "feature_actions.read"
        ],
        "resources": [
        "space:[nombre del reino]"
        ]
    }
    ],
    "run_as": [],
    "metadata": {},
    "transient_metadata": {
    "enabled": true
    }
}
}

Pulse Create API Key para generar la clave.

Importante

El IA Assistant utiliza la API de Elastic Agent Builder, por lo que la API Key debe incluir el privilegio feature_agentBuilder.all. Sin este privilegio, las llamadas a /api/agent_builder/* devuelven 403 Forbidden. Esta funcionalidad requiere licencia Enterprise y, como mínimo, Elastic Stack 9.3.

En Stack 9.3 Agent Builder está en preview y debe activarse manualmente desde Kibana; a partir de 9.4 es la experiencia por defecto. La contabilidad de consumo de tokens (informes de uso y coste) requiere Stack 9.4 o superior; en 9.3 solo está disponible el chat.

Consulte el apartado Creación de la API Key para el detalle completo de permisos, los requisitos de versión y las indicaciones de actualización de claves creadas antes de la migración a Agent Builder.

3. Obtención del Token

La plataforma generará la clave en tres formatos de salida:
- Encoded
- Beats
- Logstash

Importante

Es imprescindible guardar la clave en los tres formatos disponibles. Estos valores solo se muestran en el momento de creación de la clave. Si no se guardan en ese instante, no podrán recuperarse posteriormente y será necesario generar una nueva API Key.

4. Creación de un Reino en WOCU-Monitoring y asociación de la API Key

Finalmente, el módulo de Observability se habilita desde el propio formulario de creación de un Reino, configurado con backend Elasticsearch.

Para crear un nuevo Reino estándar de monitorización, acceda al menú Settings y haga clic en el botón + New Realm, tal y como se muestra en la siguiente imagen:

Esta acción abrirá el formulario de creación del Reino. A continuación, deberán configurarse los campos descritos en los siguientes apartados:

Display Name: añada el nombre del Reino (e. g. central_1).

Import Tool: para añadir un primer Import Tool, accione la función + anexa al campo.

Los campos que deben modificarse para dar de alta un nuevo Import Tool son:

Name: añada el nombre del Reino (e. g. central_1).

Import tool host: dirección IP o nombre del host donde se aloja el Import Tool (e. g. 10.57.20.73).

Import tool port: puerto de conexión a la API del Import Tool (e. g. 50280).

Import tool API Protocol: protocolo utilizado por WOCU-Monitoring para conectarse a la API del Import Tool. Seleccione en el desplegable la opción http.

API Optimization: marque la casilla para habilitar la optimización de las consultas realizadas contra la API del Import Tool.

A continuación:

Confirme los cambios efectuados mediante el botón Create.

Seleccione el nuevo Import Tool en el desplegable para continuar.

Monitoring Host: dirección IP o nombre de la máquina donde se aloja la base de datos (e. g. 10.57.20.73).

Monitoring port: puerto de red del servidor. Por defecto, 50000.

Backend technology: seleccione la opción Elasticsearch.

Elasticsearch backend: para añadir un primer backend, accione la función + anexa al campo.

Los campos que deben modificarse son:

Backend name: nombre identificativo del backend de Elasticsearch. Debe ser un valor único y fácilmente reconocible por el usuario (e. g. elasticsearch9-produccion).

Elasticsearch URL: URL de los nodos de Elasticsearch 9 a los que se conectará WOCU-Monitoring.

En despliegues gestionados desde la consola de Elastic, el valor debe obtenerse accediendo al proyecto Serverless de Observabilidad correspondiente.

La ruta de acceso es la siguiente:

Serverless > [nombre_del_proyecto] > Overview

A continuación, localice el bloque Application endpoints, cluster and component IDs, seleccione la opción Elasticsearch y copie el valor mostrado en Public endpoint.

Este endpoint será el valor que deberá configurarse en el campo Elasticsearch URL.

API Key: esta API Key se genera desde la propia herramienta de Elastic. Aquí debe introducir la clave generada en el paso 3. Obtención del Token de este mismo proceso, correspondiente a la API Key propia del Reino.

A continuación:

Confirme los cambios efectuados mediante el botón Create.

Seleccione el nuevo backend en el desplegable para continuar.

Metric Index: añada el nombre del Reino (e. g. central_1). El sistema añadirá internamente el prefijo correspondiente al índice de métricas.

Monitoring Events Index: añada el nombre del Reino (e. g. central_1). El sistema añadirá internamente el prefijo correspondiente al índice de eventos de monitorización.

Observability: marque esta casilla para habilitar el módulo de Observability en este nuevo Reino.

Host Name: añada el nombre del Reino (e. g. central_1).

Una vez introducidos todos los datos requeridos, guarde la configuración del formulario mediante el botón Add Realm.

5. Ejecución del script desde la consola del agregador

El siguiente paso consiste en ejecutar el script de configuración desde la consola del agregador.

Este script debe estar disponible en el entorno y utilizará las variables de entorno previamente configuradas, entre ellas la correspondiente a la API Key maestra. Esta API dispone de permisos amplios sobre el entorno de Elastic, por lo que no debe utilizarse como credencial operativa para todos los Reinos. Su uso en este procedimiento es excepcional y está limitado a tareas de provisión inicial, ya que permite automatizar la creación y configuración de los recursos necesarios en el Cloud de Elastic.

El objetivo del script es preparar el Reino de Observabilidad en Elastic, evitando una configuración manual completa y facilitando una provisión más rápida y homogénea. Una vez finalizado el proceso, cada Reino deberá operar con su propia API Key específica, con permisos acotados a sus índices, Space y recursos asociados.

Para ejecutar el script, utilice el siguiente comando desde la consola del agregador:

/opt/wocu/embedded/bin/python3 /opt/wocu/embedded/wocu/wocu-aggregator/wocu-aggregator/manage.py configure_kibana_realm_spaces <nombre_del_reino>

Donde se lee <nombre_del_reino> debe sustituirse por el identificador real del Reino que se desea configurar.

Ejemplo:

/opt/wocu/embedded/bin/python3 /opt/wocu/embedded/wocu/wocu-aggregator/wocu-aggregator/manage.py configure_kibana_realm_spaces central_1

Importante

La API Key maestra debe utilizarse únicamente para este tipo de tareas de configuración inicial. No debe reutilizarse como clave operativa de los Reinos, ya que dispone de permisos globales sobre el entorno de Elastic.

¡Enhorabuena! La configuración inicial del módulo Observability se ha completado correctamente.

Vista Observability

IA Assistant

WOCU-Monitoring integra el asistente AI Assistant, una funcionalidad de Inteligencia Artificial incluida dentro del módulo Observability y orientada a agilizar el análisis y diagnóstico de incidencias sobre los elementos monitorizados, como Dispositivos, Servicios y Problems.

Importante

Este asistente se apoya en las capacidades de Elastic Observability, por lo que permite realizar consultas en lenguaje natural sobre la información disponible en Elastic, incluyendo métricas, eventos, alertas y logs asociados a los activos del Reino.

Por lo tanto, la pestaña AI Assistant ofrece un chat para que el usuario converse e interactue con el Asistente de IA, utilizando lenguaje natural para consultar alertas métricas, eventos y logs asociados a activos de monitorización de forma ágil y centralizada.

Componentes

Sus elementos principales son:

Historial de conversaciones: barra lateral con las conversaciones del usuario, agrupadas por fecha. Desde esta área es posible retomar análisis anteriores, iniciar una nueva conversación y renombrar o eliminar conversaciones.

Selector de un conector: desplegable que permite seleccionar el conector de IA que será utilizado por el asistente para procesar la consulta. Cada conector representa un modelo o backend de Inteligencia Artificial previamente configurado en Elastic.

Área de conversación: zona principal de la vista donde se muestran los mensajes intercambiados entre el usuario y el asistente. En esta área se presentan tanto las consultas realizadas como las respuestas generadas por la IA.

Campo de consulta: caja de texto desde la que el usuario introduce la pregunta o instrucción en lenguaje natural. La consulta puede estar relacionada con eventos recientes, métricas de rendimiento, alertas activas, logs o cualquier otra información de observabilidad disponible para el Reino.

Botón Send: permite enviar la consulta al asistente. También puede utilizarse la combinación de teclas indicada en la propia interfaz para enviar el mensaje de forma rápida.

Mientras se genera la respuesta, el proceso puede detenerse mediante el botón Stop, situado junto al botón Send.

Funcionamiento

El funcionamiento de la vista AI Assistant es muy sencilla y se basa en una interacción tipo chat entre el usuario y el Asistente de IA.

Para realizar una consulta, el usuario debe escribir su pregunta o instrucción en el campo de consulta situado en la parte inferior de la vista. Esta consulta puede estar relacionada con métricas, eventos, alertas, logs o cualquier otra información de observabilidad disponible para el Reino.
Una vez redactada la consulta, es obligatorio pulsar el botón Send para enviarla al Asistente.
Tras el envío, el Asistente procesa la solicitud utilizando el conector seleccionado y devuelve la respuesta en el área de conversación.
En esta zona se muestran de forma secuencial tanto las preguntas realizadas por el usuario como las respuestas generadas por la IA.
Esta conversación se registra automáticamente en el historial de conversaciones, ubicado en el panel lateral de la vista, permitiendo al usuario retomarla posteriormente y continuar el análisis desde el punto en el que quedó.

Límites de consumo y coste del Asistente de IA

WOCU-Monitoring permite controlar el gasto del Asistente de IA por Reino y por usuario, y visualizar su coste. Toda la configuración se realiza desde el Django admin (sección Observability).

Cupo por Reino

En AI Assistant Realm Limits se define un límite mensual de tokens por Reino. Cuando el consumo del mes alcanza ese límite, los nuevos turnos del chat se bloquean con un aviso al usuario.

Cada Reino recibe un cupo por defecto al crearse (WOCU_AI_DEFAULT_REALM_TOKEN_LIMIT); con el límite deshabilitado el Reino es ilimitado.

Sub-límite y activación por usuario

En AI Assistant User Policies se puede, por par usuario-Reino, desactivar la IA o fijar un sub-límite mensual propio dentro del cupo del Reino.

Un usuario sin política usa el pool del Reino con la IA activada.

Importante

El tope es preventivo, no un corte de facturación exacto: el consumo se conoce al cerrar cada turno (y, como respaldo, con el sync horario), así que el turno que cruza el límite se completa y varios turnos simultáneos pueden superarlo ligeramente antes de bloquearse.

Los administradores del Reino y los superusuarios no se ven afectados por los límites, para no quedarse sin diagnóstico.

Modelos y coste (€)

En AI Assistant Model Prices se listan los modelos de inferencia. Se descubren automáticamente (tarea horaria y botón Sync models from Elastic), con un precio de referencia por defecto que puede ajustarse. Un modelo desactivado desaparece del selector del chat y se rechaza si se intenta usar. El coste se calcula con el precio (por millón de tokens de entrada y de salida) del modelo usado en cada conversación más el coste de las Agent Executions de Elastic (WOCU_AI_EXECUTION_PRICE). El panel Limits & Cost Dashboard muestra, por Reino y mes, el consumo frente al límite y el coste estimado en la divisa configurada (WOCU_AI_CURRENCY).

Anomalies

La vista Anomalies, incluida en el módulo Observability, permite consultar de forma centralizada las desviaciones detectadas en las métricas de los Hosts y Servicios monitorizados dentro de un Reino.

¿Para qué sirve?

Esta vista está orientada a facilitar la detección temprana y el análisis de comportamientos anómalos en la infraestructura monitorizada.

Permite, entre otros usos:

Identificar métricas cuyo comportamiento se aleja significativamente de su patrón habitual.

Detectar variaciones que podrían pasar inadvertidas utilizando únicamente umbrales fijos.

Priorizar las anomalías según su relevancia mediante el Anomaly Score.

Comparar el valor real observado con el valor esperado para esa métrica.

Localizar rápidamente el Host, Servicio y métrica en los que se ha producido la desviación.

Nota

Una anomalía no implica necesariamente la existencia de una incidencia. Indica que el comportamiento de una métrica se ha alejado de su patrón habitual y, por tanto, puede requerir revisión por parte del usuario.

¿Cómo funciona?

WOCU-Monitoring utiliza las capacidades de análisis de Elastic Observability para analizar las series temporales de las métricas y determinar cuál es su comportamiento esperado. Cuando un valor se aleja de dicho comportamiento, se identifica como una posible anomalía y se le asigna un Score, comprendido entre 5 y 100. Cuanto mayor sea esta puntuación, más significativa es la desviación detectada.

El Score permite clasificar las anomalías de acuerdo con su relevancia:

5 - 25: anomalía baja. El valor presenta una desviación leve respecto a lo esperado.

25 - 50: anomalía moderada. La desviación comienza a ser significativa.

50 - 75: anomalía alta. El comportamiento observado se aleja claramente del patrón esperado.

75 - 100: anomalía muy alta. Representa las desviaciones más relevantes o inusuales.

Importante

El Score no representa el porcentaje de desviación de la métrica. Por ejemplo, un valor de 75 no significa que la métrica se haya desviado un 75 %, sino que representa una puntuación normalizada de la relevancia de la anomalía.

Para facilitar su interpretación, cada anomalía incluye además los valores:

Actual: valor real registrado en el momento de la anomalía.

Typical: valor esperado o habitual para la métrica.

Deviation: diferencia entre ambos valores, expresada de forma que permita valorar fácilmente la magnitud de la desviación.

Por ejemplo, un valor 7.49x higher indica que el valor registrado ha sido aproximadamente 7,49 veces superior al esperado.

¿Cómo se utiliza?

Accesa a la vista Observability > Anomalies. Desde aquí el usuario dispone de una tabla que reúne las anomalías detectadas en el Reino.

Para realizar una consulta:

Seleccione en Date Range el periodo que desea analizar. Están disponibles los intervalos 4 hours, 1 day, 1 week y 1 month, además de Custom Range, que permite definir manualmente la fecha y hora de inicio y fin.
Utilice el filtro Score para limitar los resultados al nivel de relevancia de las anomalías que desea consultar. Como ya se ha explicado en el anterior punto, el filtro agrupa los resultados en cuatro rangos:

5 - 25: anomalía baja.

25 - 50: anomalía moderada.

50 - 75: anomalía alta.

75 - 100: anomalía muy alta.
Pulse Filter para aplicar los criterios seleccionados. La opción Clear permite eliminar los filtros y recuperar la consulta inicial

Tabla principal

La tabla resultante muestra muestra las anomalías detectadas junto con la información necesaria para identificar y valorar cada desviación:

La información que se ofrece es la siguiente:

Time: fecha y hora en la que se ha detectado la anomalía.

Score: puntuación asignada a la anomalía. Cuanto mayor sea el valor, mayor será su relevancia.

Host: dispositivo asociado. Accionando sobre el nombre se accede a la vista detalle del dispositivo en concreto.

Service: servicio en el que se ha identificado la anomalía, cuando corresponda. Accionando sobre el nombre se accede a la vista detalle del servicio en concreto.

Metric: métrica afectada.

Actual: valor observado en el momento de la detección.

Typical: valor esperado para dicha métrica.

Deviation: diferencia entre el valor observado y el valor típico, expresada de forma que facilite la interpretación de la desviación.

De este modo, el usuario puede comparar directamente el comportamiento real de una métrica con su comportamiento habitual e identificar rápidamente situaciones anómalas.

Interpretación de los resultados

Para evaluar una anomalía es recomendable analizar conjuntamente Score y Deviation.

El Score indica la relevancia estadística de la desviación respecto al comportamiento habitual, mientras que Deviation permite comprender de una forma más directa cuánto se ha alejado el valor real del esperado.

Por este motivo, una anomalía con un Score elevado debe considerarse como un elemento prioritario de revisión, pero debe contrastarse con el resto de información disponible en WOCU-Monitoring, como eventos de monitorización, alertas o cambios recientes en el Host o Servicio.

Exportación de resultados

La opción Export permite descargar la información disponible en la tabla de anomalías para su análisis o tratamiento externo. Los formatos disponibles son:

CSV: exporta los datos en formato tabular, compatible con aplicaciones de hoja de cálculo.

JSON: exporta los datos en formato estructurado para su procesamiento o integración con otras herramientas.

Vista de Anomalías de un Dispositivo

Atención

La pestaña Anomalies estará disponible cuando el Reino tenga habilitado el Módulo Observability y exista configuración de análisis de anomalías para las métricas del Host.

La vista Anomalies permite consultar las anomalías detectadas sobre las métricas de un Host monitorizado en WOCU-Monitoring. Para ello, combina filtros de consulta, una gráfica de evolución de la métrica y una tabla con el detalle de las anomalías detectadas.

Esta funcionalidad forma parte del módulo Observability y se apoya en las capacidades de análisis de Elastic Observability. A partir de los datos almacenados en Elastic, se analizan las series temporales de las métricas monitorizadas para identificar valores que se desvían del comportamiento habitual esperado.

Nota

La detección de anomalías no se basa únicamente en umbrales estáticos, sino en la comparación entre el valor observado y el patrón de comportamiento aprendido a partir de los datos históricos. De este modo, la vista ayuda a identificar cambios inesperados, desviaciones relevantes o comportamientos inusuales que pueden requerir revisión operativa.

Para acceder a la vista de anomalías de un Host:

Acceda al Reino correspondiente.

Navegue a Activos (Assets) > Hosts.

Seleccione el Host (columna Host) que desea analizar.

Una vez dentro de la vista de detalle del Host, pulse la pestaña Anomalies.

También puede acceder desde el listado global de Anomalies, hacienco clic sobre el nombre del un dispositivo concreto, visible en la columna Host.

Componentes de la vista

La vista Anomalies se compone de varios elementos orientados a filtrar, visualizar y consultar las anomalías detectadas.

Filtros de consulta

En la parte superior de la vista se muestran los filtros que delimitan el análisis:

Date Range

Permite definir el intervalo temporal sobre el que se desea realizar la consulta. El selector ofrece varios rangos predefinidos:

4 hours, para consultar las anomalías detectadas durante las últimas cuatro horas.

1 day, para analizar el comportamiento registrado durante el último día.

1 week, para ampliar la consulta a la última semana.

1 month, para revisar un periodo mensual.

Custom Range, para seleccionar manualmente una fecha y hora de inicio y una fecha y hora de fin.

Cuando se selecciona Custom Range, se abre un calendario desde el que el usuario puede definir el intervalo exacto de análisis. Además de seleccionar los días, es posible ajustar la hora, los minutos y los segundos de inicio y fin del periodo. Para aplicar la selección, debe pulsarse el botón Apply.

Services y Metrics

Permite seleccionar el contexto concreto de análisis dentro del Host, combinando el servicio y la métrica sobre los que se desea consultar la detección de anomalías.

El campo Services muestra los servicios disponibles para el Host seleccionado. Al elegir un servicio, el campo Metrics se actualiza automáticamente para mostrar únicamente las métricas asociadas a dicho servicio.

Una vez seleccionada la combinación de servicio y métrica, la vista consulta los datos correspondientes y actualiza tanto la gráfica de anomalías como la tabla inferior con los resultados detectados para el Host, servicio, métrica y rango temporal seleccionados.

../../_images/services_metrics_filter_71.png

Score

Permite filtrar las anomalías según su nivel de relevancia. La puntuación, comprendida entre 0 y 100, cuantifica el grado en que el valor observado se desvía del comportamiento esperado. Cuanto mayor es el Score, mayor es la significancia de la anomalía.

El valor Score se expresa en una escala de 0 a 100: cuanto mayor es el valor, más significativa es la desviación detectada y, por tanto, mayor es la relevancia de la anomalía.

En el filtro se agrupan los resultados en cuatro rangos:

5 - 25: anomalía baja. El valor presenta una desviación leve respecto a lo esperado.

25 - 50: anomalía moderada. La desviación comienza a ser significativa.

50 - 75: anomalía alta. El comportamiento observado se aleja claramente del patrón esperado.

75 - 100: anomalía muy alta. Representa las desviaciones más relevantes o inusuales.

Nota

Es importante señalar que el Score no representa directamente un porcentaje de desviación. Por ejemplo, un Score de 75 no significa que el valor se haya desviado un 75 %. Es una puntuación normalizada de severidad de la anomalía, calculada a partir de la diferencia entre el valor real y el comportamiento esperado.

Botón de actualización

El botón de actualización permite refrescar la información mostrada en la vista.

Esta acción resulta útil para consultar datos recientes o comprobar si se han detectado nuevas anomalías para el Host, servicio y métrica seleccionados.

Gráfica Anomaly Score

La zona central de la vista muestra una gráfica asociada a la métrica seleccionada. Esta gráfica permite comparar el comportamiento real de la métrica con e comportamiento esperado calculado por Elastic.

En la gráfica hay tres elementos distintos:

Línea azul: representa el valor real registrado de la métrica.

Banda azul sombreada: rango esperado o comportamiento típico calculado por el modelo.

Puntos de colores: valores reales detectados como anomalías, coloreados según su severidad o score.

Existe una leyenda de Anomaly Score que clasifica las anomalías por rangos de severidad. Esta puntuación no representa el valor de la métrica, sino el grado de desviación respecto al comportamiento esperado.

Los rangos disponibles son:

0-3: desviación mínima o sin anomalía relevante.

3-25: anomalía de baja severidad.

25-50: anomalía moderada.

50-75: anomalía alta.

75-100: anomalía crítica o muy significativa.

Cuanto mayor sea el Anomaly Score, mayor será la relevancia de la anomalía. Por este motivo, los puntos con puntuaciones más elevadas deben revisarse con mayor prioridad.

No obstante, una puntuación alta no implica necesariamente una incidencia. La anomalía debe analizarse junto con el resto de información disponible del Host, como eventos, problemas activos, alertas o cambios recientes.

Nota

Las consultas se realizan mediante endpoints autenticados, encargados de obtener las anomalías y los datos necesarios para representar la gráfica según la combinación de Host, servicio y métrica seleccionada.

Al situar el cursor sobre un punto, el tooltip muestra el detalle de esa muestra concreta de la gráfica.

Véase este ejemplo:

Fecha y hora exacta al que corresponde el punto (16 Jun 2026 11:15).

Actual: Es el valor real medido de la métrica en ese instante (4,533).

Model lower: Es el límite inferior del rango esperado por el modelo para ese momento (1,595).

Model upper: Es el límite superior del rango esperado por el modelo para ese momento (2,47).

En este caso, el valor real 4,533 está por encima del límite superior esperado 2,47, por eso el punto se marca como anomalía. Es decir, la métrica se comportó de forma anormalmente alta respecto a lo que el modelo consideraba normal para esa fecha y hora.

Tabla de anomalías

Debajo de la gráfica se muestra una tabla paginada con el detalle de las anomalías detectadas para el Host, servicio y métrica seleccionados.

La tabla incluye las siguientes columnas:

Time

Fecha y hora en la que se detectó la anomalía.

Score

Puntuación asignada a la anomalía. Un valor más alto indica una desviación más significativa respecto al comportamiento esperado.

5 - 25: anomalía baja. El valor presenta una desviación leve respecto a lo esperado.

25 - 50: anomalía moderada. La desviación comienza a ser significativa.

50 - 75: anomalía alta. El comportamiento observado se aleja claramente del patrón esperado.

75 - 100: anomalía muy alta. Representa las desviaciones más relevantes o inusuales.

Actual

Valor real registrado para la métrica en ese momento.

Typical

Valor esperado o habitual calculado para esa métrica en el mismo contexto temporal.

Deviation

Diferencia entre el valor observado (Actual) y el valor típico (Typical), expresada de forma que facilite la interpretación de la desviación. Por ejemplo, un valor de 3.42x higher indica que el valor registrado es aproximadamente 3,42 veces superior al valor esperado.

Funcionamiento e interpretación de resultados

El funcionamiento de la vista Anomalies se basa en la selección de un contexto de análisis que permita acotar y analizar las anomalías detectadas sobre los dispositivos monitorizados.

En primer lugar, el usuario debe definir el intervalo temporal mediante el filtro Date Range. A continuación, puede seleccionar el Service del dispositivo y la Metric concreta que desea analizar. Una vez definido este contexto, el filtro Score permite limitar los resultados según el grado de relevancia de las anomalías detectadas, facilitando el análisis de aquellas desviaciones con mayor o menor significancia.

A partir de la combinación de estos filtros, WOCU-Monitoring consulta la información disponible en Elastic Observability mediante endpoints autenticados. Estos endpoints recuperan tanto las anomalías detectadas como los datos necesarios para representar la evolución de la métrica seleccionada.

Los resultados se muestran en dos niveles:

Una gráfica de la métrica, donde se visualiza su evolución temporal junto con los puntos anómalos detectados.

Una tabla paginada, donde se detalla cada anomalía identificada de acuerdo con los filtros aplicados.

Los campos Score y Deviation ofrecen información complementaria para evaluar una anomalía. Mientras que Score proporciona una medida normalizada de su relevancia, Deviation permite interpretar de forma más directa cuánto se ha alejado el valor real respecto al comportamiento esperado. Por tanto, un Score elevado no debe interpretarse directamente como un porcentaje o factor de desviación.

Además de estos valores, es recomendable contrastar las anomalías detectadas con los eventos, problemas o alertas registrados en el Host durante el mismo intervalo temporal. Esta correlación permite determinar si el comportamiento anómalo está relacionado con una incidencia real o con algún cambio significativo en el entorno monitorizado.

Una anomalía no implica necesariamente una incidencia, pero sí identifica un comportamiento que se desvía del patrón habitual de la métrica. Por este motivo, debe utilizarse como punto de partida para el análisis operativo y contrastarse con el resto de información disponible del Host.

Vista de Anomalías de un Servicio

Atención

La pestaña Anomalies estará disponible cuando el Reino al que pertenece el Dispositivo y Servicios asociados, tenga habilitado el Módulo Observability.

Al igual que existe una vista Anomalies asociada a un Host concreto, también es posible acceder a una vista de anomalías desde el contexto de un Service específico.

Para acceder a la vista de anomalías de un Servicio:

Acceda al Reino correspondiente.

Navegue a Activos (Assets) > Services.

Seleccione el Servicio que desea analizar (Columna Service).

Una vez dentro de la vista de detalle del Servicio, pulse la pestaña Anomalies.

También puede acceder desde el listado global de Anomalies, haciendo clic sobre el nombre del un servicio concreto, visible en la columna Service.

Esta vista presenta un funcionamiento similar al descrito para los dispositivos, pero centra el análisis exclusivamente en el servicio seleccionado. De este modo, el usuario puede consultar el comportamiento anómalo de las métricas asociadas a dicho servicio dentro de un intervalo temporal determinado.

Por tanto, la principal diferencia respecto a la vista de anomalías de un dispositivo es el contexto de análisis: mientras que en la vista del dispositivo es posible seleccionar entre sus distintos servicios y métricas, en la vista de un Service el análisis queda previamente acotado al servicio desde el que se accede.

Acción Ask IA about a problem

Atención

Esta acción estará disponible cuando el Reino tenga habilitado el Módulo Observability y exista configuración de análisis de anomalías para las métricas del Host o servicio seleccionado.

La acción Ask IA about a problem permite solicitar un diagnóstico asistido por Inteligencia Artificial (IA) sobre un Host, Servicio o Problema monitorizado, utilizando el IA Assistant de WOCU-Monitoring.

Su objetivo es facilitar la comprensión de una incidencia mediante el análisis del estado del elemento seleccionado y de la información operativa disponible en WOCU-Monitoring y Elastic Observability.

¿Para qué sirve?

Ante una incidencia, esta acción proporciona una interpretación automática del estado del elemento monitorizado, ayudando al operador a comprender qué está ocurriendo, identificar posibles causas y determinar los siguientes pasos para su diagnóstico.

El análisis utiliza información contextual como el estado del Host o Servicio, el último check ejecutado, la salida del plugin, el impacto de negocio y los datos de observabilidad disponibles en Elastic.

A diferencia de la Acción Root Cause Analysis (RCA), orientada a correlacionar eventos e información de distintas fuentes para investigar el origen de una incidencia, Ask IA about a problem se centra en ofrecer una explicación y recomendaciones sobre el problema concreto seleccionado.

Por ejemplo, ante un Servicio en estado CRITICAL por un consumo elevado de CPU, la acción puede explicar el estado detectado, interpretar la información devuelta por el check y recomendar comprobaciones para investigar el problema.

¿Cómo se utiliza?

Esta opción está disponible en los listados de Hosts, Services y Problems, dentro del menú de acciones aplicables a cada elemento.

Para ejecutar un análisis:

Localice el Host, Servicio o Problema que desea analizar y seleccione la opción Ask IA about a problem desde el menú de acciones.

WOCU-Monitoring utilizará la información operativa y de observabilidad disponible para generar un diagnóstico contextual del elemento seleccionado.

Una vez generado el análisis, se mostrará una ventana de diagnóstico con los resultados proporcionados por el Asistente de IA.

El diagnóstico puede incluir:

Resumen del estado actual: descripción general de la situación del elemento monitorizado.

¿Qué está pasando?: explicación del comportamiento o problema detectado.

Causa probable: interpretación de los posibles motivos de la incidencia.

Información de diagnóstico: datos relevantes y comandos recomendados para realizar comprobaciones adicionales.

Siguiente paso recomendado: propuesta de actuación para continuar la investigación.

El resultado debe utilizarse como apoyo al diagnóstico, permitiendo al operador interpretar la información disponible y orientar las comprobaciones necesarias para confirmar la causa de la incidencia.

Continuar la investigación con el Asistente de IA

Desde la ventana de resultados es posible seleccionar Open AI Assistant para continuar el análisis mediante una conversación con el IA Assistant de WOCU-Monitoring.

Al seleccionar esta opción, el usuario accede a la vista Observability > AI Assistant, donde se carga el contexto del diagnóstico realizado.

Desde esta conversación, el operador puede formular preguntas adicionales, solicitar aclaraciones sobre el diagnóstico, profundizar en las posibles causas o pedir recomendaciones para continuar con la investigación.

Consideraciones y limitaciones

La funcionalidad Ask IA about a problem requiere que el Reino disponga de un backend Elasticsearch y del módulo Observability correctamente configurados.
Esta acción no modifica el estado de los elementos monitorizados ni ejecuta cambios sobre la infraestructura. Su finalidad es exclusivamente facilitar el diagnóstico y la interpretación de incidencias.

Acción Root Cause Analysis (RCA)

Atención

Esta acción estará disponible cuando el Reino tenga habilitado el Módulo Observability y exista configuración de análisis de anomalías para las métricas del Host o servicio seleccionado.

La acción Root Cause Analysis (RCA) permite realizar un análisis automático de causa raíz sobre un Host o Servicio monitorizado, utilizando el IA Assistant de WOCU-Monitoring.

Su objetivo es facilitar el diagnóstico de incidencias, reuniendo y correlacionando la información disponible en las distintas fuentes de observabilidad del Reino para intentar identificar qué pudo originar el problema y qué eventos pueden estar relacionados entre sí. Para ello, el análisis puede utilizar información procedente de Metrics, Monitoring, Syslogs y Traps.

¿Para qué sirve?

Ante una incidencia, el usuario puede disponer de información repartida entre métricas, eventos de monitorización, logs o traps. La acción RCA centraliza este contexto y lo analiza conjuntamente, ayudando a reducir el tiempo necesario para investigar manualmente cada fuente.

A diferencia de la Acción Ask IA about a problem, centrada en analizar un problema concreto, esta acción busca relaciones entre los diferentes eventos y datos disponibles alrededor del dispositivo, para determinar el origen más probable de la incidencia.

Por ejemplo, ante un Servicio en estado CRITICAL por una carga elevada de CPU, el análisis podría relacionar ese cambio de estado con un incremento previo de determinadas métricas, mensajes registrados en Syslog o eventos detectados en el mismo intervalo temporal.

¿Cómo se utiliza?

Esta opción está disponible en los listados de Hosts, Services y Problems, dentro del menú de acciones aplicables a cada elemento.

Nota

Cuando la acción se ejecuta sobre un Host, este actúa como elemento principal sobre el que se correlaciona toda la información recuperada.

Si el análisis se inicia desde un Servicio, WOCU-Monitoring continúa utilizando el Host asociado como nexo principal de correlación, pero prioriza la información relacionada con el Servicio seleccionado.

Para ejecutar un análisis:

Localice el Host o Servicio que presenta la incidencia y seleccione la opción Root Cause Analysis desde el menú de acciones.

WOCU-Monitoring recopilará la información disponible y ejecutará el análisis.
Una vez finalizado, se mostrará una ventana de diagnóstico con el resultado generado por el Asistente de IA. El resultado puede incluir un resumen del problema, la cronología de los eventos relacionados, una posible cadena causal, las fuentes de información utilizadas y recomendaciones o comprobaciones para continuar con la investigación.

El resultado proporcionado por RCA debe utilizarse como apoyo al diagnóstico, permitiendo al operador disponer de contexto adicional y orientar las siguientes comprobaciones necesarias para confirmar la causa de la incidencia.

Continuar la investigación con el Asistente de IA

Desde la propia ventana de resultados es posible seleccionar Open AI Assistant para continuar el análisis mediante una conversación con el IA Assistant y realizar preguntas adicionales sobre el diagnóstico obtenido.

Esta opción permite realizar preguntas adicionales sobre el diagnóstico obtenido, solicitar aclaraciones o profundizar en determinados eventos o evidencias detectadas durante el análisis RCA.

Consideraciones y limitaciones

La funcionalidad Root Cause Analysis requiere que el Reino disponga de un backend Elasticsearch y del módulo Observability correctamente configurados.

Forecast en Metrics

La vista Metrics incorpora la funcionalidad Forecast, que permite visualizar una estimación de la evolución futura de una métrica a partir de los datos históricos disponibles en WOCU-Monitoring. La previsión puede extenderse hasta 1 día adicional respecto al periodo temporal consultado y se representa directamente sobre la gráfica de la métrica.

../../_images/2_038j_modal-host-metrics-forecast_74.png

Forecast está orientado a facilitar una supervisión más proactiva de los recursos monitorizados. En lugar de analizar únicamente lo que ya ha ocurrido, permite observar la tendencia prevista de una métrica y anticipar posibles comportamientos anómalos o aproximaciones a niveles de Warning o Critical.

Por ejemplo, si una métrica de utilización de CPU presenta una tendencia ascendente, Forecast permite visualizar cómo podría evolucionar durante las próximas horas y valorar si existe riesgo de aproximación a los umbrales configurados. La predicción debe interpretarse como una estimación basada en el comportamiento observado, y no como un valor real ya registrado por el sistema.

Nota

Más información sobre cómo funciona y cómo se utiliza en el siguiente enlace: Forecast de métricas.