SPLK-3002 Aggregation Policies

Aggregation Policies Detailed Explanation

1. What Are Aggregation Policies?

Simple Definition

An Aggregation Policy in ITSI tells the system:

“When many similar Notable Events happen around the same time, group them together into one consolidated event.”

Why is this helpful?

Because large environments can generate hundreds of alerts at once—sometimes all related to the same root issue.
Aggregation policies help you:

• Reduce alert noise

• Avoid duplication

• Improve clarity

2. What Do Aggregation Policies Do?

Aggregation policies group, prioritize, and format Notable Events.
The result is fewer but more informative alerts that are easier to investigate and resolve.

3. Core Components of an Aggregation Policy

a. Filtering Conditions

• These rules determine which events are considered for aggregation.

• You can filter based on:

  • Severity

  • Service name

  • Entity

  • Custom fields

Example:
Only include events where severity = Critical and service = "Checkout API"

b. Aggregation Fields

• These define what makes events similar.

• You might group events by:

  • Service

  • Entity (host)

  • KPI name

  • Source

Example:
Group all events from the same host or same application

This helps consolidate:

10 alerts from the same server → into 1 grouped event

c. Time Windows

• This defines how close together in time events must be to be grouped.

• If multiple events happen within this time window, they are considered part of the same issue.

Example:
If 5 events occur within 10 minutes, group them.

d. Priority Rules

• These rules assign severity to the grouped event.

• The priority can be based on:

  • The most severe included event

  • A weighted scoring system

  • Custom logic

Example:
If even one Critical event is included, mark the group as Critical.

4. Output of Aggregation Policies

Here’s what you get when aggregation works well:

One Consolidated Event

Instead of 10 separate alerts about a database, you see 1 single incident.

Reduced Alert Fatigue

Your team is not overwhelmed by duplicate messages.

More Actionable Incidents

You can focus on the real problem, not individual symptoms.

5. Advanced Features

a. Drill-Down Searches

You can click into the grouped event to view:

• All the original, raw Notable Events

• Search results and related logs

This helps with fast root cause analysis.

b. Auto-Close Settings

You can configure events to automatically close when:

• Conditions return to normal

• No new events are added after a certain time

This helps reduce manual cleanup and keeps dashboards tidy.

c. Workload Prioritization

ITSI can prioritize critical business services so that:

• High-impact events are shown first

• Less important alerts are delayed or hidden

This helps incident response teams focus on what really matters.

6. Best Practices for Aggregation Policies

Avoid Over-Aggregation

Too much grouping can hide real issues.

For example:

Don’t group all web server alerts together if they belong to different services.

Tailor Aggregation Fields

Every environment is different. You might need to group by:

• Host in one case

• Service in another

• Application ID in others

Adjust aggregation fields based on your monitoring goals

Review Policy Effectiveness Regularly

Over time, you should:

• Analyze which policies are working well

• Adjust time windows or severity rules

• Remove unused or redundant policies

This keeps your alerting accurate and efficient.

Summary: What to Remember About Aggregation Policies

• Aggregation Policies group similar Notable Events to reduce noise and highlight real incidents.

• They use filters, time windows, and severity rules to control how alerts are combined.

• Advanced features like drill-downs, auto-close, and prioritization make event management easier.

• Follow best practices to ensure policies are effective and tuned to your environment.

Aggregation Policies (Additional Content)

1. Where Aggregation Fits in the Notable Event Lifecycle

Aggregation Policies in ITSI play a key role after a Notable Event is generated.

Lifecycle Context:

1. A correlation search or KPI threshold breach triggers a Notable Event.

2. Aggregation policies then review these events in real time and decide:

• Whether to group similar events

• How to assign severity to the group

• How to name and tag the resulting episode

Aggregation is not responsible for detecting issues—that’s the job of correlation or threshold logic.
Instead, it focuses on post-processing and consolidating alerts into meaningful incidents.

Episode Review Visibility:

Once events are grouped by an aggregation policy, the resulting Episode is immediately visible in the Episode Review interface.

You can:

• Click on an episode to see all grouped Notable Events

• View event metadata (e.g., service, entity, severity)

• Drill into root causes or logs from the same screen

Clarification to remember:

Aggregation happens after Notable Events are created. It organizes them into meaningful groups, which are displayed in Episode Review.

2. Differentiating Aggregation Policies from Correlation Searches

One of the most frequently confused topics is the difference between Correlation Searches and Aggregation Policies.
Let’s clarify the distinction:

Feature	Correlation Search	Aggregation Policy
Primary Role	Detect patterns, anomalies, or conditions	Organize, group, and prioritize events
Data Source	Logs, metrics, KPIs, custom SPL logic	Notable Events generated by correlation/KPIs
Timing	Before events are generated	After events are generated
Action	Creates new Notable Events or triggers	Groups Notable Events into Episodes
Tool/Module	Built in Correlation Search Editor	Managed in Aggregation Policy Editor

Summary to reinforce exam learning:

Correlation searches generate Notable Events by identifying patterns. Aggregation policies manage those events by grouping, prioritizing, and formatting them.

Summary

• Aggregation policies are applied after Notable Events are created.

• Their role is to group similar events into one episode, reducing alert fatigue and improving clarity.

• They are fully visible and actionable within the Episode Review interface.

• Aggregation is not a detection mechanism—it’s a management layer that works in tandem with correlation logic.

• Confusing correlation and aggregation can lead to exam mistakes—remember that correlation finds, and aggregation organizes.