> For the complete documentation index, see [llms.txt](https://docs.infraon.io/infraon-help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.infraon.io/infraon-help/infinity-user-guide/event-management/aiops-events.md). # AIOps Events ## **What Do You See on the Screen** You’ll find a range of search and filter options in the Events tab at the top of the screen. These filters help you narrow down events based on their origin. To focus specifically on events triggered by **AIOps configurations**, use the following filters:
LabelDescription / Example
Anomaly EventDisplays events generated from prediction-based anomaly detection using adaptive thresholds.
Event SuppressionDisplays events that are tagged for suppression based on time-based or seasonal logic. These events are still raised, but can be excluded from ticketing if suppression is configured in triggers.
Event AssociationShows events grouped by correlation rules learned through event association mining.
## Anomaly Events It identifies and raises alerts when anomalies are detected in monitored resources. It is tightly integrated with the **prediction model** and relies on **adaptive thresholds** generated using machine learning. * Detects deviation from expected behavior using AI-generated thresholds. * Converts anomalies into **event alerts**, which can generate tickets **if a trigger is configured**. * Enables real-time issue identification without relying on static threshold configurations. ### **How Anomalies Are Detected** Anomalies are detected by comparing **live polled values** with **model-generated thresholds** derived from the past 30 days of data. The process follows this logic:
1. **Model Learning**\ \ The prediction model uses 30 days of historical data to understand the typical behavior of a metric (e.g., CPU, bandwidth usage). It computes: * Upper threshold (e.g., expected high usage) * Lower threshold (e.g., expected low usage) * Mid value (expected average) 2. **Threshold Comparison**\ \ The model outputs these threshold bands for every hour in the prediction window (typically the next three weeks). The system continuously compares incoming poll data with these thresholds. 3. **Anomaly Trigger** * If the **actual value** exceeds the **upper threshold** or drops below the **lower threshold**, it is flagged as an anomaly. * An **event is raised**, and based on the configuration, a **ticket is auto-generated**. **Example:**\ \ A bank branch typically consumes 3–6 Mbps on weekdays. Suddenly, 2 Gbps of data is transferred on a Sunday. The system recognizes this spike as an anomaly and flags it. ## Seasonal Event It is a mechanism designed to reduce alert fatigue by suppressing known, expected, or repetitive events within specific time windows. These events are often harmless and predictable and do not require user action. It is used to: * To **prevent unnecessary noise** in the event system. * Avoid triggering **notifications** such as **tickets, emails, SMS, or JSON alerts** for known recurring behavior (e.g., nightly shutdowns in retail or banking environments). * Improves **event signal-to-noise ratio**, making real issues more visible. ### **How Suppression is Detected** * Suppression is **time-based** and can be **manually configured**. * Suppressed events are **not discarded** — they are **logged** but do **not generate notifications or tickets**. * Common use case: devices shut down every evening at 8 PM. The system learns or is told not to raise events during this window. ### **Configuration** Navigate to the **Advanced Resource Configuration (ARC)** module and enable the **Seasonal Event Suppression** toggle under prediction settings. You may need to adjust business hour profiles and ensure the correct metrics are selected. {% hint style="info" %} A valid license is required to activate this feature. {% endhint %} * In the **Events module**, suppressed events are still visible but marked (e.g., “Suppressed” tag). * They will **not trigger tickets** or **alert notifications** unless manually configured otherwise. * Suppressed event counts can be viewed in the **dashboard widgets** and **reports**. ## Event Association Event Association is correlating multiple related events across components or systems and identifying them as part of a **common cause or impact zone**. It is used to: * To **detect root causes** when multiple alerts are triggered together. * To **group events** meaningfully rather than treating them as isolated issues. * Helps in large, distributed environments where **dependent systems** impact each other (e.g., a UPS failure causing router, switch, and IP camera outages). * The learned associations can also be **used to dynamically build a logical topology**, allowing users to visualize event flows and dependencies, even when no static topology is configured. ### **How Associations Are Detected** Infraon AIOps analyzes the last 90 days of event history to identify patterns and recurring relationships between events. It learns which events frequently occur together and detects potential correlations across components. The system generates association rules based on two key parameters: * Confidence (%) – Indicates the likelihood that one event is related to another. * Support Value – Represents how often a pattern has occurred in the observed data. ### **Configuration** To configure Event Association, navigate to the Advanced Resource Configuration (ARC) module and follow the steps below: * Enable the Event Association Mining toggle under the selected asset. * Provide the following configuration inputs: * **Statistic**: Select the specific metric (e.g., CPU utilization, bandwidth) on which event association should be applied. * **Confidence (%):** Defines the strength of the relationship between two events. For example, a value of 90% means there's a high likelihood that one event is related to another. * **Support Value:** Specifies how often the same event pattern must occur before it is considered significant. For example, a value of 5 means the system must observe the pattern at least five times. * Once configured, Infraon uses this data to detect recurring relationships and generate association rules that link related events across your environment. {% hint style="info" %} These associations will be reflected in the Events module with the label “Associated”, showing grouped events and potential root causes. {% endhint %} * In the UI, a **parent-child event relationship** is displayed. * The association details (what triggered what, how confident the system is, etc.) can be traced in the event’s detail view. * You can also view these associations in relevant dashboards, where grouped event patterns are visually represented. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.infraon.io/infraon-help/infinity-user-guide/event-management/aiops-events.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.