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:
Label
Description / Example
Anomaly Event
Displays events generated from prediction-based anomaly detection using adaptive thresholds.
Event Suppression
Displays 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 Association
Shows 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:
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)
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.
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.
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.
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.
Last updated
Was this helpful?