SPLK-3002 Thresholds and Time Policies

Thresholds and Time Policies Detailed Explanation

1. Purpose of Thresholds and Time Policies

What Are Thresholds?

A threshold is a rule that tells ITSI when a KPI should change its status.

For example:

• If a KPI value is normal, ITSI shows it as green.

• If it gets worse, the color might turn yellow (warning) or red (critical).

• These color changes are based on threshold rules.

Thresholds help:

• Detect problems early

• Trigger Notable Events

• Update service health scores

Without thresholds, KPIs are just numbers—thresholds give them meaning.

What Are Time Policies?

A Time Policy allows you to apply different thresholds at different times.

Why would you need that? Because systems behave differently depending on:

• Business hours vs. overnight

• Weekdays vs. weekends

• Maintenance windows

Time policies let you:

• Be stricter during peak usage

• Be more relaxed during low activity

• Prevent false alerts during maintenance

2. Types of Thresholds

There are several ways you can set thresholds in ITSI. Choose the type that fits your KPI’s behavior.

a. Static Thresholds (Fixed Numbers)

These are simple and direct.

Example:
If response time > 500ms → mark as “Critical”

Best for:

• Predictable metrics like disk usage

• KPIs where exact limits are known

Pro: Easy to understand
Con: Not flexible for changing workloads

b. Percentage-Based Thresholds

These apply when the KPI is a percentage value (like CPU or memory usage).

Example:
If CPU > 90% → Warning
If CPU > 95% → Critical

Best for:

• Utilization-based KPIs

• Anything measured in percentages

Pro: Good for capacity planning
Con: May need tuning for spikes

c. Trend-Based Thresholds

These don’t just look at the value—but how fast it changes over time.

Example:
If response time jumps 50% in 5 minutes, alert me—even if it’s still “within range”.

Best for:

• KPIs that change suddenly

• Use cases where rate of change matters

Pro: Great for catching early signs of trouble
Con: Can be sensitive to normal fluctuations

d. Machine Learning Thresholds (Anomaly Detection)

These use historical data to learn what “normal” looks like.
Then, if the KPI deviates from the learned baseline, ITSI marks it as abnormal.

Example:
Normally, login failures stay below 10/hour.
If suddenly it spikes to 60, ML will flag it—even if no static threshold was set.

Best for:

• Complex environments

• KPIs with irregular patterns

Pro: Very smart, adaptive
Con: Requires training period and good historical data

3. Understanding Time Policies

Why Use Time Policies?

Because context matters. A KPI might look bad at 2 AM, but that’s expected during backups or updates.

With Time Policies, you can say:

“Use strict thresholds from 8 AM to 6 PM,
and looser rules from 6 PM to 8 AM.”

This helps:

• Avoid false positives

• Improve alert accuracy

• Tailor monitoring to business needs

Use Cases for Time Policies

• Maintenance windows: Don’t alert on downtime during scheduled upgrades.

• Business-critical hours: Be more sensitive when users are active.

• Nighttime monitoring: Reduce alert noise when fewer users are online.

4. Configuration Elements

a. Severity Levels

When a threshold is crossed, the KPI status changes to:

• Normal

• Info

• Warning

• High

• Critical

These severity levels affect:

• The color of KPIs and services

• The priority of Notable Events

• The urgency of alert actions

b. Time Zones

If your organization operates in multiple locations (e.g., U.S., Europe, Asia), time policies can:

• Adjust automatically based on local time

• Ensure thresholds are relevant to each region

This makes global monitoring more accurate and useful.

c. Overrides

Time Policies can override default threshold settings.

Example:

• Default KPI threshold = 500ms

• But during nightly batch processing, allow up to 800ms

This lets you fine-tune alert behavior for different time windows.

Summary: What to Remember About Thresholds and Time Policies

• Thresholds tell ITSI when something is “Normal,” “Warning,” or “Critical”.

• You can use static, percentage, trend-based, or ML-based thresholds depending on your KPI.

• Time Policies change how thresholds behave at different times of day.

• These features reduce false alerts, improve accuracy, and make ITSI smarter and more context-aware.

Thresholds and Time Policies (Additional Content)

1. Where to Configure Thresholds and Time Policies

Understanding where and how thresholds and time policies are configured in ITSI is essential for proper KPI tuning and real-time alerting.

Threshold Configuration Location:

• Thresholds are configured inside each KPI’s settings, either:

  • At creation time when building a new KPI.

  • Or later, via the Service Editor → select a KPI → click Edit Thresholds.

• Within this interface, you can:

  • Choose the type of threshold (static, percentage-based, trend-based, machine learning).

  • Set status levels: Normal, Info, Warning, High, Critical.

  • Define value ranges for each level.

Thresholds are specific to each KPI and must reflect the metric’s business impact and performance expectations.

Time Policy Configuration:

• Time policies are created and managed in the Time Policy Manager:

  • Navigate to Settings > ITSI > Time Policies.

  • There you can define:

    • Time windows (e.g., business hours, weekends).

    • Associated threshold overrides for those windows.

• Once created, these policies can be applied to multiple KPIs to ensure dynamic behavior.

This separation ensures flexibility: one policy can manage threshold behavior across many KPIs simultaneously.

2. How Thresholds Trigger Notable Events

The KPI → Notable Event Mechanism:

• Each KPI in ITSI can be configured with action rules that define what happens when the KPI status changes due to threshold breaches.

• If the KPI changes to Warning, High, or Critical, and it has event generation enabled, it will create a Notable Event.

This creates a direct link between metric behavior and alert generation, enabling operations teams to respond quickly to real issues.

Key Conditions:

• The KPI must be:

  • Enabled for Notable Event creation.

  • Properly connected to a service and team, for routing.

• Generated events will appear in the Episode Review dashboard if aggregation is enabled, or in the Notable Events Review panel as individual alerts.

Example Scenario:

• You configure a KPI for CPU Usage with a Critical threshold at 90%.

• CPU spikes to 95% during business hours.

• The threshold breach triggers a status change to Critical.

• Because the KPI has event generation enabled, it creates a Notable Event tagged as "CPU Alert", with severity Critical.

This seamless flow from KPI → Threshold → Event → Response is the backbone of ITSI’s monitoring architecture.

Summary

• Thresholds are configured in the KPI editor or Service Editor and control how KPI values are interpreted into health statuses.

• Time Policies are created via the Time Policy Manager and allow thresholds to vary by time of day or week.

• When a threshold is breached, a KPI state change may trigger a Notable Event, provided the KPI is configured to do so.

• These elements are essential for driving alerts and service health scores, and a clear understanding is vital for both real-world and exam success.