Skip to main content
Lantern Home
 
 
Splunk Lantern

Using dynamic entity rule configurations

  1. Last updated
  2. Save as PDF

 

You often add or remove entities from your configuration. These changes take time and effort to manually reconfigure your entity filter rules, and the process can introduce errors. You want a rule configuration that updates immediately and without the need for service configuration changes.

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

Solution

Dynamic entity rule configuration ensures that KPI results remain accurate as entities come online and go offline.

When you configure ITSI entities, you use the metadata shown in this table.

Title Alias fields Informational fields Entity type
The most human-friendly name for the entity The other field names and values that uniquely describe this entity Metadata field names and values that further describe this entity. These fields are optional. Useful classification of this entity that allows it to be grouped with others. This field is optional.
Keep it simple and intuitive, and watch out for accidental duplication. For example, you might choose hostname over FQDN.

This value should always match a unique field within the raw data that powers the KPIs. Some examples are thehost, FQDN, ip_address, instance_id, and moid.

Be careful not to use this as an informational field. Also, this is not a compound field.

This information can be useful for entity filtering logic and entity enrichment. Some examples are: operating system, application name, region, client.

 Each entity can be assigned a zero-to-many entity type that drives directed troubleshooting. Some examples are: Windows Host, AWS Instance, and VSphere VM.

Dynamic entity matching uses these metadata fields. To take advantage of dynamic entity matching, use wild cards to bring in new entities. This is especially useful for the title and alias fields, which are unique. The example below shows a wild card for the alias match, but you can use a wild card in any of the fields. On informational fields or entity types, you can already get a one-to-many match without a wild card because many entities can share those values.

clipboard_e00987b735813f76a1db651f52895b992.png

What you don't want to do is hard code a title or alias value. The example below specifically defines webserver-02 and webserver-04. So, if you wanted to retire webserver-04 or add new webserver-05, this rule won't update dynamically. You would have to manually update ITSI to make that change.

clipboard_e037b85fcdf519156a18b1cc63fcc41af.png

Additionally, do not embed your entity filtering logic within your KPI search, as shown in the following screenshot. This is a static configuration, not a dynamic one.

clipboard_e0a33ef27ee088dd488c49466b61a49f7.png

Let's use a hypothetical search from data stored in the main index to see how ITSI KPIs utilize dynamic entity inclusion rules to filter results in KPIs.

  1. First, add index=main.
    clipboard_ef7a11034f5d12a87df322d8eab8618fb.png
  2. Next, let's add the entities for the service using wild card matching. With the plnxweb* value, we get three matches, shown below.
    clipboard_e01b0b361cc3ccb9df729fdc0f1eac424.png
  3. For each matching entity, ITSI automatically obtains the entity's alias value to use when filtering results from the main index. In this example, the specified entity filter field and value arehost=plnxweb01.
    clipboard_e24fa2943631db04181938b73a2d829bc.png

When you've done this, ITSI automatically appends a subsearch to the original KPI search to restrict KPI results to entities in this service. The subsearch drives the filtering logic.

clipboard_e9ec9fd0c02ea88a2f1ec19878a01f1cb.png

While right now, the search would look for search host="plnxweb01" OR host="plnxweb02" OR host="plnxweb03",  in the future, if more plnxweb hosts are added, they would be dynamically added to the search. 

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: