SPLK-3002 Managing Notable Events

Managing Notable Events Detailed Explanation

1. What Is a Notable Event?

Simple Definition

A Notable Event in ITSI is an alert or incident that gets created automatically when:

• A KPI crosses a critical threshold, or

• A pattern is detected through a correlation search.

It’s called "notable" because it signals something that is important, possibly urgent, and should be looked at by a human.

Think of it like:

• A fire alarm in a building.

• A red warning light on a car dashboard.

It doesn’t just show data—it’s a call to action.

2. Lifecycle of a Notable Event

Notable Events follow a 4-step lifecycle in ITSI:

a. Triggering

This is the moment when something goes wrong.
Examples:

• A KPI called “Error Rate” goes above its critical threshold.

• A correlation search detects a combination of high CPU + memory usage.

As soon as the condition is met, ITSI generates a Notable Event.

b. Aggregation

When many events happen around the same time, ITSI can group them together using rules called Aggregation Policies.

This prevents:

• Alert fatigue (too many separate alerts for the same issue)

• Confusion and duplication

• Missed context

Example: If 5 different services report errors due to the same database problem, ITSI may group them into one master event.

c. Prioritization

ITSI uses your rules to assign a severity level to each event:

• Info

• Warning

• High

• Critical

This helps teams:

• Focus on the most important issues first.

• Filter out low-priority alerts.

You can base priority on:

• The affected service

• The impact score

• The source or entity involved

d. Management

Once an event is created, you can manage it in many ways:

• Acknowledge it (mark it as being worked on)

• Assign it to a team or user

• Escalate it if it hasn’t been resolved

• Suppress it if you know it’s a false positive or expected (e.g., maintenance)

This keeps your incident management clean and organized.

3. Event Management Features

ITSI gives you several powerful tools to manage events efficiently:

Aggregation Policies

These are rules that tell ITSI how to:

• Group similar events together

• Define how long to wait before grouping

• What fields to use (e.g., same service, same host)

Think of this like smart folders for events:

"If 3 KPIs go critical in the same service within 5 minutes → treat it as one big event."

Event Suppression

Sometimes you know certain issues will happen—for example:

• During planned maintenance

• While running load tests

• When deploying new code

You can set up suppression rules so that:

• Events during these times are not created

• Your team isn’t bothered by noise

This is very helpful to keep focus on real problems only.

Workflows

Workflows let you automate actions when a Notable Event is triggered.

Examples:

• Send an alert to Slack or Microsoft Teams

• Create a ticket in ServiceNow or Jira

• Run a script to restart a service

This makes your response faster and consistent.

Custom Fields and Tags

Every event can include:

• Custom fields like environment (prod/dev), region, team

• Tags like "database", "frontend", "security"

These make it easier to:

• Filter events

• Route them to the right team

• Search for specific types of problems

Summary: What to Remember About Managing Notable Events

• A Notable Event is an important alert triggered when something crosses a threshold or matches a pattern.

• Events go through a clear process: triggering → aggregation → prioritization → management.

• ITSI provides tools to group, suppress, and automate how events are handled.

• These events are the starting point for action—helping teams stay focused and fast.

Managing Notable Events (Additional Content)

1. Where Are Notable Events Displayed?

Why it matters:
Knowing where Notable Events appear in the UI helps users visually understand the workflow from data to incident review.

Suggested Explanation:

Notable Events are primarily displayed in the Episode Review interface within ITSI.
To access it:

Go to ITSI → Episode Review

This view shows:

• Individual or grouped Notable Events

• Event metadata (severity, time, entity, service)

• Aggregated episodes with timeline view

Operators and analysts can acknowledge, assign, or close events directly from this interface. It's the central workspace for incident triage in ITSI.

2. Example of Event Aggregation (Trigger Logic)

Why it matters:
Seeing a concrete example helps students understand how multiple raw alerts get transformed into a single, meaningful incident.

Suggested Explanation:

Imagine that three different KPIs for a web server (CPU usage, memory usage, and HTTP 500 errors) all go into warning or critical state within 10 minutes. Without aggregation, this would generate three separate Notable Events.

With an Aggregation Policy configured as:

• Filter: Service = web-frontend

• Aggregation Fields: Entity, KPI

• Time Window: 10 minutes

ITSI groups those events into one episode, providing a consolidated view like:

"Web Frontend experiencing performance degradation on server web01"

This reduces alert fatigue and speeds up root cause analysis.

3. How KPIs Trigger Events (via Action Rules)

Why it matters:
Students benefit from understanding how the KPI layer connects to event generation, closing the loop in their mental model.

Suggested Explanation:

KPIs are linked to event generation through Action Rules, which define:

• When a KPI status change should trigger an event

• What severity the resulting event should have

• Which fields (entity, service, category) are added to the event

You can configure action rules under each KPI definition. For instance:

"If status = Critical for more than 2 minutes → trigger Notable Event with severity = High"

This mechanism ties KPI behavior directly to incident management workflows.

4. How Prioritization Works (Impact Score & Entity Importance)

Why it matters:
Understanding how ITSI determines which events are most urgent is critical for meaningful response prioritization.

Suggested Explanation:

Notable Event priority is influenced by multiple factors, including:

• Impact Score: Based on KPI severity and health score weights

• Entity Importance: If an entity (e.g., a production DB) has higher business value, its events may be prioritized higher

• Custom Priority Rules: Defined in Aggregation Policies or Action Rules

For example:

An event involving a “Critical” database with high entity importance will appear before a warning-level alert on a dev server.

This ensures your team responds to what matters most, not just what’s most frequent.

Summary

These enhancements help build a full lifecycle perspective of Notable Events:

• KPI behavior → Event trigger → Aggregation → Review → Response

• Improved clarity around where events live, how they form, and how they're prioritized

• Stronger readiness for both SPLK-3002 exam success and real-world operational use