Observability

Información relacionada…

Migrating from a standard realm to an observability realm

The Observability module extends the capabilities of WOCU-Monitoring by utilising data stored in a backend based on Elasticsearch. This functionality enables users to query, analyse and contextualise the information associated with a monitored infrastructure, providing a more comprehensive view of asset behaviour, their metrics and the events generated on the platform.

Furthermore, the module incorporates an AI Assistant integrated into WOCU-Monitoring, designed to streamline the diagnosis of incidents relating to Hosts, Services and Problems. Using this feature, users can request assisted analyses, gain context on the status of monitored elements and continue their investigation via a chat-style conversation within the interface itself.

Configuring the Observability Realm

Manual configuration

Important

All configuration of spaces, keys and privileges described in the following stages must be carried out directly via the Elastic website or interface (Elasticsearch), as this procedure is native to that platform.

Requisitos previos

Before starting the configuration of the Observability Realm, the following data and access must be available:

• Access to the Elastic interface with administrator permissions.

• Name of the realm to be configured in WOCU-Monitoring.

• Access to the Realm settings in WOCU-Monitoring or to the environment where its configuration variables are defined

The configuration is based on three main elements:

• Creating a Space in Elastic associated with the Realm.

• Defining a custom role with permissions restricted to the Realm.

• The generation of an API Key linked to those permissions.

The full process is set out below:

1. Access to the Observability project on Elastic

Go to the Elasticsearch interface and select the Serverless Project for observability set up by your administrator or Elastic owner.

Attention

Please check that you are in the correct environment before creating spaces, roles or API keys. This check is important to ensure that credentials are not generated in a project other than the one you will be using with WOCU-Monitoring

2. Creation of the Space associated with the Realm

The first step is to create a Space in Elastic for the Observability Realm.

To do this:

• Open the side menu Admin and settings > Spaces.

• Create a new space using the + Create Space option.

• Next, configure the following fields in the creation form:

  

  Name: enter a descriptive name for the Realm (e.g. central_1). The name of the space must match the functional name of the Realm.

  Initials: enter a short term that will appear in the Space’s avatar box (e.g. C1).

  Cross-project search: select the This project option to limit searches to data from the current project only. This is the recommended option for keeping the focus on a single environment and optimising query performance.

If this space is not your current workspace, click Switch to this space. When you do so, your Kibana session will automatically be redirected to the new space (central_1).

3. Creating a custom role

To avoid using credentials with global permissions, a custom role associated with the Realm must be created. This role acts as a permissions reference and allows access to be restricted solely to the necessary resources, such as metric indices, events or logs from the Realm and its corresponding Space in Kibana.

To do this:

• Open the side menu Admin and settings > Custom Roles.

• Create a new role using the + Create role option.

• The role’s identifying details must be configured at the top of the creation form:

  

  Role name: the unique name of the role. This cannot be changed once it has been created. It is recommended that you use a consistent naming convention that includes the realm identifier (e.g. central_1).

  Role description: a functional description of the role. This field helps to identify the purpose of the role within Elastic (e.g. Kibana base user role for central_1).

  Data Layer: this section defines the access permissions for data stored in Elastic.

  Index privileges: the indexes associated with the Realm must be specified. These indexes define the data that the role will be able to query. For a Realm with the identifier central_1, the indexes to be configured would be:

  metrics-wocu-central_1
  monitoring-events-central_1
  syslogs-central_1
  traps-central_1
  

  Privileges: the read permission must be assigned. This permission allows the user to view metrics, events and logs for the Realm, without granting write or administrative access to the indices.

  Grant access to specific fields and Grant read privileges to specific documents must remain disabled, unless additional filtering by fields or documents is required.

  Application Layer: this section defines which Space and features the role will have access to within Kibana.

  Spaces: select only the Space associated with the Realm (e.g. central_1). It is not recommended to assign the role to all Spaces, as this would compromise the isolation between Realms.

  Privileges: select the Custom option to assign only the necessary permissions. As a general rule, the role should grant read access to the features required to view the Realm’s observability data, whilst avoiding administrative permissions.

• Once you have configured the fields above, click Create role to save the new role.

4. Creating the API key

The API Key enables WOCU-Monitoring and its components to connect securely to Elastic in order to read and write observability data from the Realm, such as metrics, events, syslogs or traps.

Using it avoids the need to rely on global credentials or personal user accounts, and allows access to be restricted solely to the indexes and resources associated with the Realm.

To do this:

• Open the side menu Admin and settings > API KEYS.

• Create a new API using the + Create API key option.

• In the creation form, configure the fields:

  

  Name: a descriptive name for the new API (e.g. central_1). It is recommended that a consistent naming convention be used, including the Realm identifier.

  Control security privileges: this option is used to limit the scope of the key. When enabled, Elastic will display a JSON editor where you can define the specific privileges that the API key will have.

• Copy and edit the following JSON code in the editor to assign write permissions and define the indexes for your Realm.

Attention

You must replace [realm name] with your Kingdom’s actual identifier.

{
"role-read-write-[nombre del reino]": {
    "cluster": [
    "all"
    ],
    "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
    },
    {
        "names": [
        ".kibana-observability-ai-assistant-conversations*"
        ],
        "privileges": [
        "all"
        ],
        "allow_restricted_indices": false
    }
    ],
    "applications": [
    {
        "application": "kibana-.kibana",
        "privileges": [
        "feature_observabilityAIAssistant.all",
        "feature_actions.all"
        ],
        "resources": [
        "*"
        ]
    }
    ],
    "run_as": [],
    "metadata": {},
    "transient_metadata": {
    "enabled": true
    }
}
}

Once you have edited the JSON, click the Create API KEY button.

5. Obtaining the Token

• The platform will generate the key in three output formats: Encoded, Beats and Logstash.

• Select and copy the token in Encoded format and make a note of this value for now, as it will be used in the next section, specifically in the variable ELASTICSEARCH_API_KEY.

  

• Optionally, you can also select the Beats and Logstash formats, required for Fluentd and TD-Agent configuration.

6. Realm Variable Settings

Once you have retrieved the data from Elastic, open the Realm configuration file and enter the following mandatory environment variables:

Important

The variables must be validated using the configuration specified by the engineering team for each deployment.

Server and Ingest Variables (Section: Monitoring)

• LOGGER_SERVER: The public Elasticsearch endpoint associated with the project.

LOGGER SERVER="endpoint"

The value of the variable is retrieved from the Elastic console by accessing the relevant Serverless Observability project.

The path is as follows: Serverless projects > [project_name] > Overview

Next, locate the Application endpoints, cluster and component IDs section and select the Elasticsearch option.

• METRIC_SERVER: Metrics server (same value as in LOGGER_SERVER).

METRIC_SERVER="endpoint"

• ELASTICSEARCH_API_KEY: Authentication key copied in Encoded format (Step 5: Obtaining the token). Connects the system for reading and writing metrics, events and notifications.

ELASTICSEARCH_API_KEY="clave de autenticación"

Other Mandatory Configuration Variables

• ELASTICSEARCH_SERVERLESS_MODE: Mandatory mode for serverless environments (always enabled).

ELASTICSEARCH_SERVERLESS_MODE="True"

• GCONF_ENABLED: Enables the Gconf service (always active).

GCONF_ENABLED="True"

• GCONF_SERVICES_HOST: Access URL for the provided configuration machine. It must be specified including the protocol, IP address, and corresponding port.

GCONF_SERVICES_HOST="https://[IP]:[PORT]"

• MYSQL_SERVER: IP address of the central database provided.

MYSQL_SERVER="IP"

• MYSQL_USER: Add the name of the realm as appropriate.

MYSQL_USER="nombre_reino"

• MYSQL_ROOT_PASSWORD: Database access password (same as the realm name).

MYSQL_ROOT_PASSWORD="nombre_reino"

Note

For distributed infrastructures, authentication is also required from ProxySQL.

7. Creating an Observability Realm in WOCU-Monitoring

Finally, the Observability module is enabled from the realm creation form itself, configured with an Elasticsearch backend.

To create a new standard monitoring realm, access the Settings menu and click the + New Realm button, as shown in the following image:

This action will open the Realm creation form. Next, the fields described in the following sections must be configured:

Display Name: add the Realm name (e.g., central_1).

Import Tool: to add an initial Import Tool, activate the + function next to the field.

The fields that must be modified to set up a new Import Tool are:

Name: add the name of the Realm (e.g., central_1).

Import tool host: IP address or hostname where the Import Tool is hosted (e.g., 10.57.20.73).

Import tool port: connection port for the Import Tool API (e.g. 50280).

Import Tool API Protocol: protocol used by WOCU-Monitoringto connect to the Import Tool API. Select the http option from the drop-down menu.

API Optimization: check the box to enable optimization of queries made against the Import Tool API.

Next:

• Confirm the changes made using the Create button

• Select the new Import Tool from the drop-down menu to continue.

Monitoring Host: IP address or hostname of the machine hosting the database (e.g., 10.57.20.73).

Monitoring port: server network port. Default: 50000.

Backend technology: select the Elasticsearch option.

Elasticsearch backend: in this new selector, you can add a new backend by triggering the + function.

The fields that must be modified are:

Backend name: identifying name for the Elasticsearch backend. It must be a unique value that is easily recognizable by the user (e.g., elasticsearch9-production).

Elasticsearch URL: URL of the Elasticsearch 9 nodes to which WOCU-Monitoring will connect.

For deployments managed from the Elastic console, the value must be obtained by accessing the corresponding Observability Serverless project.

The access route is as follows:

Serverless projects > [project_name] > Overview

Next, locate the Application endpoints, cluster and component IDs block, select the Elasticsearch option, and copy the value shown under Public endpoint.

This endpoint is the value that must be configured in the Elasticsearch URL field.

API Key: This API Key is generated from within the Elastic tool itself. Here, you must enter the key generated in step 3. Obtaining the Token of this same process, which corresponds to the Realm’s own API Key.

Next:

• Confirm the changes made using the Create button

• elect the new backend from the dropdown menu to continue

  

Metric Index: add the name of the Realm (e.g., central_1). The system will internally add the corresponding prefix to the metrics index.

Monitoring Events Index: add the Realm name (e.g., central_1). The system will internally add the prefix corresponding to the monitoring events index.

Observability: check this box to enable the observability module in this new Realm.

Host Name: add the name of the Realm (e.g., central_1).

Once all the required data has been entered, save the form configuration using the Add Realm button.

8. Enable observability in an existing realm

A situation may arise where you want to enable the observability module in an existing Realm.

To do this, click on the Configuration option, which can be accessed via the Settings selector. This will open a new browser window giving you access to the advanced WM Console Admin module, from where you can manage a range of advanced WOCU-Monitoring functions.

Next, select the Realm option from the left-hand side menu and navigate to the Realm you wish to edit. Once you are in the edit profile screen, tick the Observability box.

Finally, save your changes by clicking the Save button and return to the Realm to start using the module’s features.

Congratulations! The initial configuration of the Observability module has been completed successfully.

Configuration via Script

Requisitos previos

• The cloud environment administrator must have an Elastic master API key with sufficient permissions to create and configure the necessary resources for the Observability Realm.

• The environment variable corresponding to the Aggregator must be configured beforehand, as it will be used during the process to apply the Realm configuration.

Script-based configuration enables the automation of the Observability Realm creation in Elastic Cloud, reducing manual intervention and facilitating consistent configuration across different environments.

The full process is set out below:

1. Request for the Master API Key

Before executing the script, request the Elastic master API key from the Cloud environment administrator or superadmin.

This key is generated only once and, by default, must already exist in the environment. The Master API Key has sufficient permissions to create and configure the necessary resources for the Observability Realm in Elastic.

Once this key has been obtained, the necessary credential is availableto proceed with the configuration process via script.

Important

The master API key must be used solely for provisioning or initial configuration tasks. It should not be used as an operational credential for the Realm, as it grants global permissions over the environment.

2. Creating the Realm API Key

Once the master API Key is available, a secondary API Key associated with the Observability Realm must be created. This will be the operational key used by the Realm, with permissions scoped via a JSON privilege structure.

To create it, follow these steps:

• Go to the Elasticsearch interface and select the Serverless Project for observability set up by your administrator or Elastic owner.

  

  Attention

  Please check that you are in the correct environment before creating spaces, roles or API keys. This check is important to ensure that credentials are not generated in a project other than the one you will be using with WOCU-Monitoring

• Access Space by default.

  

• Navigate to the Admin and settings > API KEYS side menu and create a new API key.

  

• In the creation form, configure the fields:

  

  • Name: descriptive name of the new API (e.g., central_1). It is recommended to use the same identifier as that of the Realm.

  • Control security privileges: this option is used to limit the scope of the key. When enabled, Elastic will display a JSON editor where you can define the specific privileges that the API key will have.

  • Copy and edit the following JSON code in the editor to assign write permissions and define the indexes for your Realm.

  Attention

  You must replace [realm name] with your Kingdom’s actual identifier.

  {
  "role-read-write-[nombre del reino]": {
      "cluster": [
      "all"
      ],
      "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
      },
      {
          "names": [
          ".kibana-observability-ai-assistant-conversations*"
          ],
          "privileges": [
          "all"
          ],
          "allow_restricted_indices": false
      }
      ],
      "applications": [
      {
          "application": "kibana-.kibana",
          "privileges": [
          "feature_observabilityAIAssistant.all",
          "feature_actions.all"
          ],
          "resources": [
          "*"
          ]
      }
      ],
      "run_as": [],
      "metadata": {},
      "transient_metadata": {
      "enabled": true
      }
  }
  }
  

• Click Create API Key to generate the key.

3. Obtaining the Token

• The platform will generate the key in three output formats:

  • Encoded

  • Beats

  • Logstash

Important

It is essential to save the key in the three available formats. These values ​​are displayed only at the time the key is created. If they are not saved then, they cannot be recovered later, and it will be necessary to generate a new API Key.

4. Creating a Realm in WOCU-Monitoring and associating the API Key

Finally, the Observability module is enabled from the realm creation form itself, configured with an Elasticsearch backend.

To create a new standard monitoring realm, access the Settings menu and click the + New Realm button, as shown in the following image:

This action will open the Realm creation form. Next, the fields described in the following sections must be configured:

Display Name: add the Realm name (e.g., central_1).

Import Tool: to add an initial Import Tool, activate the + function next to the field.

The fields that must be modified to set up a new Import Tool are:

Name: add the name of the Realm (e.g., central_1).

Import tool host: IP address or hostname where the Import Tool is hosted (e.g., 10.57.20.73).

Import tool port: connection port for the Import Tool API (e.g. 50280).

Import Tool API Protocol: protocol used by WOCU-Monitoringto connect to the Import Tool API. Select the http option from the drop-down menu.

API Optimization: check the box to enable optimization of queries made against the Import Tool API.

Next:

• Confirm the changes made using the Create button

• Select the new Import Tool from the drop-down menu to continue.

Monitoring Host: IP address or hostname of the machine hosting the database (e.g., 10.57.20.73).

Monitoring port: server network port. Default: 50000.

Backend technology: select the Elasticsearch option.

Elasticsearch backend: to add an initial backend, activate the + function next to the field.

The fields that must be modified are:

Backend name: identifying name for the Elasticsearch backend. It must be a unique value that is easily recognizable by the user (e.g., elasticsearch9-production).

Elasticsearch URL: URL of the Elasticsearch 9 nodes to which WOCU-Monitoring will connect.

For deployments managed from the Elastic console, the value must be obtained by accessing the corresponding Observability Serverless project.

The access route is as follows:

Serverless > [project_name] > Overview

Next, locate the Application endpoints, cluster and component IDs block, select the Elasticsearch option, and copy the value shown under Public endpoint.

This endpoint is the value that must be configured in the Elasticsearch URL field.

API Key: This API Key is generated from within the Elastic tool itself. Here, you must enter the key generated in step 3. Obtaining the Token of this same process, which corresponds to the Realm’s own API Key.

Next:

• Confirm the changes made using the Create button

• elect the new backend from the dropdown menu to continue

  

Metric Index: add the name of the Realm (e.g., central_1). The system will internally add the corresponding prefix to the metrics index.

Monitoring Events Index: add the Realm name (e.g., central_1). The system will internally add the prefix corresponding to the monitoring events index.

Observability: check this box to enable the observability module in this new Realm.

Host Name: add the name of the Realm (e.g., central_1).

Once all the required data has been entered, save the form configuration using the Add Realm button.

5. Executing the script from the aggregator console

The next step is to execute the configuration script from the aggregator console.

This script must be available in the environment and will use the previously configured environment variables, including the one for the master API Key. This API has broad permissions within the Elastic environment, so it should not be used as an operational credential for all Realms. Its use in this procedure is exceptional and limited to initial provisioning tasks, as it enables the automation of the creation and configuration of the necessary resources in the Elastic Cloud.

The goal of the script is to prepare the Observability Realm in Elastic, avoiding a full manual configuration and facilitating faster, consistent provisioning. Once the process is complete, each Realm must operate using its own specific API Key, with permissions restricted to its indices, Space, and associated resources.

To execute the script, use the following command from the aggregator’s console:

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

Where <realm_name> appears, it must be replaced with the actual identifier of the realm to be configured.

Example:

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

Important

The master API key must be used solely for this type of initial configuration task. It must not be reused as an operational key for Realms, as it possesses global permissions over the Elastic environment.

Congratulations! The initial configuration of the Observability module has been completed successfully.

Observability view: IA Assistant

WOCU-Monitoring incorporates the AI Assistant, an artificial intelligence feature included within the Observability module and designed to streamline the analysis and diagnosis of incidents affecting monitored elements, such as Hosts, Services and Problems.

Important

This assistant utilises the capabilities of Elastic Observability, enabling users to perform natural language queries on the information available in Elastic, including metrics, events, alerts and logs associated with the Realm’s assets.

The AI Assistant tab therefore provides a chat function that allows users to converse and interact with the AI Assistant, using natural language to quickly and centrally view alerts, metrics, events and logs associated with monitored assets.

Components

Its main components are:

Conversation history: a sidebar displaying the user’s conversations, grouped by date. From this area, you can revisit previous analyses, start a new conversation, and rename or delete conversations.

Connector selector: a drop-down menu that allows you to select the AI connector that the assistant will use to process the query. Each connector represents an AI model or backend that has been previously configured in Elastic.

Conversation area: the main part of the screen where messages exchanged between the user and the assistant are displayed. This area shows both the queries made and the responses generated by the AI.

Query field: a text box into which the user enters a question or instruction in natural language. The query may relate to recent events, performance metrics, active alerts, logs or any other observability information available to the Realm.

Send button: allows you to send your query to the assistant. You can also use the keyboard shortcut shown on the interface itself to send the message quickly.

How it works

The AI Assistant feature is very straightforward to use and is based on a chat-style interaction between the user and the AI Assistant.

• To make a query, the user must type their question or command into the query field at the bottom of the view. This query may relate to metrics, events, alerts, logs or any other observability information available for the Realm.

• Once you have written your query, you must click the Send button to send it to the Assistant.

• Once the request has been sent, the Assistant processes it using the selected connector and returns the response in the conversation area.

• This section displays, in sequence, both the questions asked by the user and the answers generated by the AI.

• This conversation is automatically saved in the conversation history, located in the side panel of the view, allowing the user to return to it later and continue the analysis from where they left off.

Host Anomalies View

Attention

The Anomalies tab will be available when the Realm has the Observability enabled and anomaly analysis configuration exists for Host metrics.

The Anomalies view allows you to view the anomalies detected in the metrics of a host being monitored in WOCU-Monitoring. To do this, it combines query filters, a graph showing the metric’s trend over time, and a table detailing the detected anomalies.

This feature forms part of the Observability module and draws on the analytics capabilities of Elastic Observability. Using the data stored in Elastic, the time series of the monitored metrics are analysed to identify values that deviate from the expected normal behaviour.

Note

Anomaly detection is not based solely on static thresholds, but on a comparison between the observed value and the behaviour pattern learnt from historical data. In this way, the dashboard helps to identify unexpected changes, significant deviations or unusual behaviour that may require operational review.

To access the anomalies view for a host:

1. Go to the relevant Realm.

2. Go to Assets > Hosts.

3. Select the host you wish to analyse.

4. Within the Host details view, click the Anomalies tab.

View components

The Anomalies view consists of several elements designed to filter, display and view the detected anomalies.

Query filters

The filters that define the analysis are displayed at the top of the view:

Date Range

This allows you to specify the time period for which you wish to run the query. The selector offers several predefined ranges:

• 4 hours, to view the anomalies detected over the last four hours.

• 1 day, to analyse the behaviour recorded over the last day.

• 1 week, to extend the search to the last week.

• 1 month, to review a monthly period.

• Custom Range, to manually select a start date and time and an end date and time.

When Custom Range is selected, a calendar opens, allowing the user to define the exact analysis range. As well as selecting the days, it is possible to set the hour, minutes and seconds for the start and end of the period. To apply the selection, click the Apply button.

Services y Metrics

This allows you to select the specific context for analysis within the Host, combining the service and the metric for which you wish to check for anomalies.

The Services field displays the services available for the selected host. When you select a service, the Metrics field is automatically updated to show only the metrics associated with that service.

Once the combination of service and metric has been selected, the view retrieves the relevant data and updates both the anomaly chart and the table below with the results detected for the selected host, service, metric and time range.

Refresh button

The refresh button allows you to refresh the information displayed in the view.

This action is useful for viewing recent data or checking whether any new anomalies have been detected for the selected host, service and metric.

Anomaly Score Chart

The central area of the view displays a graph associated with the selected metric. This graph allows you to compare the actual behaviour of the metric with the expected behaviour calculated by Elastic.

There are three distinct elements in the graph:

• Blue line: represents the actual recorded value of the metric.

• Shaded blue band: expected range or typical behaviour calculated by the model.

• Coloured dots: actual values detected as anomalies, coloured according to their severity or score.

There is a Anomaly Score metric that classifies anomalies by severity. This score does not represent the value of the metric, but rather the degree of deviation from expected behaviour.

The available ranks are:

• 0–3: minimal deviation or no significant abnormality.

• 3-25: low-severity anomaly.

• 25–50: moderate abnormality.

• 50–75: high abnormality.

• 75–100: critical or very significant anomaly.

The higher the Anomaly Score, the greater the significance of the anomaly. For this reason, points with higher scores should be reviewed as a matter of priority.

However, a high score does not necessarily indicate an incident. The anomaly must be analysed alongside the rest of the available information about the host, such as events, active issues, alerts or recent changes.

Note

Queries are carried out via authenticated endpoints, which are responsible for retrieving the anomalies and the data required to generate the graph based on the selected combination of host, service and metric.

When you hover the cursor over a point, the tooltip displays details of that specific data point on the graph.

Take a look at this example:

The exact date and time to which the point refers (16 Jun 2026 11:15).

Current: This is the actual measured value of the metric at that moment (4.533).

Model lower: This is the lower bound of the range predicted by the model for that point in time (1.595).

Model upper: This is the upper limit of the range predicted by the model for that point in time (2.47).

In this case, the actual value of 4.533 is above the expected upper limit of 2.47, which is why the data point is flagged as an anomaly. In other words, the metric was abnormally high compared with what the model considered normal for that date and time.

Table of anomalies

Below the graph is a paginated table showing details of the anomalies detected for the selected host, service and metric.

The table contains the following columns:

Time

Date and time when the anomaly was detected.

Score

Score assigned to the anomaly. A higher value indicates a more significant deviation from expected behaviour.

Current

The actual value recorded for the metric at that time.

Typical

The expected or typical value calculated for that metric within the same time frame.

Note

Comparing Actual and Typical allows us to determine whether the recorded value is above or below the expected standard.

How it works and interpreting the results

The Anomalies view works by selecting an analysis context for the monitored host.

Firstly, the user must define the time range using the Date Range filter. They must then select the Host’s Service and the specific Metric they wish to analyse.

Using this combination of filters, WOCU-Monitoring retrieves the information available in Elastic Observability via authenticated endpoints. These endpoints retrieve both the detected anomalies and the data required to plot the trend of the selected metric.

The results are displayed on two levels:

• A graph of the metric, showing its trend over time alongside the detected anomalies.

• A paginated table detailing each anomaly identified for the selected combination of host, service, metric and time range.

To interpret the results correctly, we recommend checking the following information:

• Time, which indicates the date and time when the anomaly occurred.

• Score, which allows the relevance of the detected deviation to be assessed.

• Actual, which shows the actual value recorded for the metric.

• Typical, which shows the expected or typical value calculated by Elastic.

• The selected service and metric.

• Events, problems or alerts recorded on the host during the same time period.

An anomaly does not necessarily indicate an incident, but it does identify behaviour that deviates from the metric’s usual pattern. For this reason, it should be used as a starting point for operational analysis and cross-checked against the rest of the information available for the host.

Action Ask IA about a problem

Attention

This action will be available when the Realm has the Observability enabled and anomaly analysis is configured for the metrics of the selected host or service.

The Ask AI about a problem action allows you to request an AI-assisted analysis of the status of a monitored item. This option is available in the lists for Hosts, Services and Problems, within the menu of actions applicable to each item.

This feature forms part of the Observability module and draws on the analytics capabilities of Elastic Observability. The AI uses the information stored and processed in Elastic, together with the operational context available in WOCU-Monitoring, to interpret the status of the selected host, service or issue and provide a diagnostic-oriented explanation.

When the action is executed, WOCU-Monitoring opens a contextual view containing a diagnostic report for the selected element. This view summarises the current status and provides an automatic interpretation of the available data.

The analysis may include, amongst other sections:

• A summary of the current situation.

• An explanation of what is happening.

• The most likely cause of the behaviour observed.

• Diagnostic information and recommended commands.

• A recommended next step for the operator.

The diagnosis is generated based on data such as the status of the host or service, the last check run, the plugin’s output, the business impact and the observability information available in Elastic.

At the bottom of the view, there is an Open AI Assistant button. When the user clicks this, they are redirected to the Observability > AI Assistant view, where the assistant opens with the same diagnostic information loaded into the conversation.

From this view, the user can continue the analysis they have started, ask further questions about the problem, request clarification, obtain recommendations for action, or investigate the probable cause of the detected behaviour in greater depth.

This action does not alter the status of the monitored item or make any changes to the monitoring configuration. Its purpose is to provide contextual assistance with diagnosis and to facilitate the interpretation of the observed data using the Elastic Observability capabilities integrated into WOCU-Monitoring.