Skip to main content
Lantern Home
 
 
 
Splunk Lantern

Utilizing policies other than the default policy

  1. Last updated
  2. Save as PDF

 

The default aggregation policy is designed to be a catch-all when notables don’t qualify for other policies. It was not designed to be your primary aggregation policy and has special behavior that likely does not fit your primary need.

This article is part of the Definitive Guide to Best Practices for IT Service Intelligence. ITSI administrators and end users will benefit from adopting this practice as they work on Event Analytics.

Solution 

To understand why you should create custom policies, you first need to understand the behavior of the default policy. 

  • Scenario 1: You haven't built any custom policies.
    • When a notable event comes in, an episode is built under the default policy. 
  • Scenario 2: You have built one custom policy.
    • A notable event comes in that qualifies for that policy. Although all notable events will always qualify for the default policy, in this case, an episode is built only under the custom policy because it is a match.
    • A notable event comes in that does not qualify for the custom policy. The episode is built under the default policy, which is in place to ensure that no notable events are lost. This is the correct function of the default policy.
  • Scenario 3: You have built two custom policies.
    • A notable event comes in that qualifies for one of the two custom policies. An episode is built only under that one custom policy because it is a match.
    • A notable event comes in that qualifies for both custom policies. An episode is built under both of those policies.
    • A notable event comes in that does not qualify for either custom policy. The episode is built under the default policy.

So what should you do instead of relying on the default aggregation policy?

  1. Use the out-of-the-box policies in the Content Pack for Monitoring and Alerting. These allow you to build episodes by alarm, source, ITSI service, and alert group.
  2. Create your own. You can use the ones in the Content Pack for Monitoring and Alerting as configuration references.

After you have them created, be sure to monitor regularly which policies notables qualify into. 

  1. Treat the default policy like index=main and ensure you don’t have episodes inadvertently qualifying for the default policy.
  2. Verify that notable events are not qualifying into multiple policies, unless you want that to happen.
  3. Use the ITSI episode monitoring service tree in the Content Pack for Monitoring and Alerting to monitor what’s happening.

Next steps

This content comes from Splunk .Conf presentation, The Definitive List of Best Practices for Splunk® IT Service Intelligence: How to Configure, Administer, and Use ITSI for Optimal Results, part one presented in .Conf23 and part two presented in .Conf24 session. In the session replays, you can watch Jason Riley and Jeff Wiedemann share the many awesome best practices they've amassed for designing key performance indicators (KPIs), services, episodes, and machine learning to maximize end-user experience and insights. Whether you're new or experienced, you'll come away with tactical guidance you can use right away.

​You might also be interested in the following Splunk resources: