QUICK START - Design and automate through lookup knowledge

Automate priority, tags and SLA management through a single lookup

• This quickstart guides you through the design and implementation of lookup-based policies in TrackMe, a powerful approach to automate the management of priority, tags, and SLA classes across your monitored entities.

• The key idea: a single lookup file (CSV or KVstore) containing your knowledge about your Splunk environment can drive all three policy types at once — priority assignment, tag automation, and SLA classification.

• This quickstart provides two end-to-end examples:

  • Data source monitoring (DSM): Using an index-based lookup to assign priorities, tags, and SLA classes to data source entities

  • Data host monitoring (DHM): Using a host-based lookup to assign priorities, tags, and SLA classes to data host entities

• Prerequisites: An existing Virtual Tenant with discovered entities, and a lookup file uploaded to Splunk (via the Splunk App for Lookup File Editing or any other method).

Hint

For detailed documentation on each individual policy type, refer to:

• Managing priority via policy — Priority policies

• Accessing, defining and managing tags policies — Tags policies

• Defining SLA policies to assign SLA classes automatically — SLA policies

The concept: one lookup, three policies

The idea behind lookup-based policies is simple: you maintain a single lookup file that contains your knowledge about your Splunk environment, and TrackMe uses it to automate the management of priority, tags, and SLA classes across your monitored entities.

Consider the following lookup file example_cmdb_indexes.csv with three columns:

Example:

index	priority	tags
os	low	os
prd*_*_linux	critical	production
webserver	critical	web

From this single lookup, TrackMe can create three policies:

• Priority policy: Map the index column to entity fields, and use the priority column to assign priority levels (low, medium, high, critical) to matching entities.

• Tags policy: Using the same lookup and field mapping, use the tags column with a comma separator to assign one or more tags to matching entities.

• SLA policy: Using the same lookup and field mapping, use the priority column with value mappings to translate priority levels into SLA classes (e.g., critical → gold, high → silver, low → platinum).

Hint

This approach is particularly powerful because:

• All three policies share the same lookup file — a single source of truth for your Splunk knowledge.

• Updates to the lookup are automatically reflected when the policy trackers run.

• Field mappings support wildcard matching (using * and ? patterns), so you can match complex index or host naming conventions with simple patterns.

• Each policy includes a simulation mode that lets you preview the results before applying changes.

Data source monitoring (DSM) example

In this example, we will demonstrate the complete workflow for data source monitoring, using the example_cmdb_indexes.csv lookup shown above. We will map the index field in the lookup to the data_index entity field, which allows matching data source entities by the index they belong to.

The lookup file

The lookup file example_cmdb_indexes.csv is uploaded to Splunk and contains 15 rows mapping indexes to priorities and tags:

Initial state

Before creating any policies, all 34 data source entities are at the default priority level (medium) and have no tags or SLA classes assigned:

Step 1: Create a priority policy

Access the priority policies screen:

From the Tenant Home page, click the Actions button in the top-right corner, then select Manage priority policies.

Create a lookup-based priority policy:

• Click Create new policy and select the Lookup based mode

• In Step 1, select the lookup transform example_cmdb_indexes (csv) — TrackMe lists all available lookup transforms and shows a preview of sample rows

• In Step 2, configure the field mapping: map the lookup field index to the entity field data_index, and select the match mode (Wildcard or Exact)

• In Step 3, select priority as the priority field — the lookup already uses TrackMe priority values (low, medium, high, critical), so no value mappings are needed

• In Step 4, priority value mappings are optional and not required in this example since the lookup already uses TrackMe-compatible priority values

Run the simulation to preview which entities would be matched and what priorities would be assigned. The simulation results show the number of matched entities and the priority distribution:

Add the policy and execute the tracker:

Once the policy is created, click Execute tracker to apply the priority assignments to all matching entities:

Result: Entities are now assigned the correct priority levels based on the lookup — the Tenant Home reflects the new priority distribution (critical, high, medium, low):

Step 2: Create a tags policy

Access the tags policies screen:

From the Tenant Home page, click the Actions button, then select Manage tags policies.

Create a lookup-based tags policy:

Using the same lookup transform, configure the tags policy:

• In Step 1, select the same lookup transform example_cmdb_indexes (csv)

• In Step 2, configure the same field mapping: index → data_index, with Wildcard match mode

• In Step 3, select tags as the tags field

• In Step 4, set the tags separator to , (comma) — this tells TrackMe to split the tags column value into individual tags (e.g., eventgen,os becomes two separate tags: eventgen and os)

Run the simulation to preview tag assignments. The simulation shows 34 matched entities and 6 distinct tags discovered:

Execute the tracker to apply the tag assignments:

Result: Entities are now tagged, and you can group the Tenant Home by tags to see the tag distribution. Clicking on an entity’s tags dialog shows the tags assigned by the policy:

Step 3: Create an SLA policy

Access the SLA policies screen:

From the Tenant Home page, click the Actions button, then select Manage SLA policies.

Create a lookup-based SLA policy:

Using the same lookup transform, configure the SLA policy — but this time, we leverage value mappings to translate the priority column into SLA classes:

• In Step 1, select the same lookup transform example_cmdb_indexes (csv)

• In Step 2, configure the same field mapping: index → data_index, with Wildcard match mode

• In Step 3, select priority as the SLA field — since the lookup does not have a dedicated SLA column, we reuse the priority column and translate values via mappings

• In Step 4, enable SLA value mappings and define the translation:

Lookup value (priority)	→	SLA class
low	→	platinum
medium	→	platinum
high	→	silver
critical	→	gold

Run the simulation to preview SLA class assignments. The simulation shows the SLA distribution across all 34 entities:

Execute the tracker to apply the SLA class assignments:

Result: Opening an entity’s SLA tab confirms the SLA class has been assigned by the policy. In this example, prd3_eu:linux:linux_secure is assigned the gold SLA class, as its index matches the prd*_*_linux wildcard pattern with a critical priority mapped to gold:

Data host monitoring (DHM) example

In this example, we demonstrate the same workflow for data host monitoring, using a host-based lookup example_cmdb_hosts.csv. The key differences from the DSM example are:

• The lookup maps hosts (by FQDN) instead of indexes

• The field mapping uses host → alias (the entity alias field in DHM)

• The match mode is Exact (hosts have specific FQDNs, no wildcards needed)

• The tags field uses the ci_desc column (leveraging an existing CMDB description field as tags)

DHM - The lookup file

The lookup file example_cmdb_hosts.csv is uploaded to Splunk and contains 8 rows with columns ci_contact, ci_desc, host, and priority:

DHM - Initial state

Before creating any policies, all 7 data host entities are at the default priority level (medium):

DHM - Step 1: Create a priority policy

Access the priority policies screen and create a lookup-based policy:

• Select the lookup transform example_cmdb_hosts (csv)

• Configure the field mapping: host → alias, with Exact (case-insensitive) match mode

• Select priority as the priority field

Run the simulation — all 7 entities are matched with the correct priority distribution (critical: 2, high: 2, medium: 1, low: 2):

Execute the tracker to apply the priority assignments:

Result: Entities are now assigned the correct priority levels. The entity-level priority dialog shows the priority is managed by the policy and can be overridden at entity level:

DHM - Step 2: Create a tags policy

Create a lookup-based tags policy using the same lookup transform:

• Field mapping: host → alias, with Exact match mode

• Tags field: ci_desc — in this example, we leverage the CMDB description column as the source of tags (e.g., “Public facing”, “Internal infrastructure”, “Event generator”)

• Tags separator: , (comma)

Run the simulation — 7 entities matched, 3 distinct tags discovered (Public facing, Internal infrastructure, Event generator):

Execute the tracker to apply the tag assignments:

Result: Entities are now tagged and can be grouped by tags in the Tenant Home. The entity tags dialog confirms the tag assignment by the policy:

DHM - Step 3: Create an SLA policy

Create a lookup-based SLA policy using the same lookup transform:

• Field mapping: host → alias, with Exact match mode

• SLA field: priority — as in the DSM example, we reuse the priority column and translate values via mappings

• Enable SLA value mappings: low → platinum, medium → platinum, high → silver, critical → gold

Run the simulation — 7 entities matched with SLA distribution (gold: 2, platinum: 3, silver: 2):

Result: Opening an entity’s SLA tab confirms the SLA class assignment. In this example, downloads.trackme-limited.com is assigned the gold SLA class (critical priority mapped to gold):

Summary and best practices

Key takeaways

• Single source of truth: Maintain one lookup file per scope (e.g., one for indexes, one for hosts) and let TrackMe derive priority, tags, and SLA from it.

• Wildcard matching: Use wildcard match mode with patterns like prd*_*_linux to match complex naming conventions without enumerating every possible entity.

• Value mappings: When your lookup doesn’t use TrackMe’s native values (e.g., custom priority levels or no dedicated SLA column), use value mappings to translate on the fly.

• Simulate before applying: Always run a simulation before adding a policy to verify the match count and value distribution.

• Execute trackers: After creating or modifying policies, execute the relevant tracker to apply changes immediately. Trackers also run on schedule, so any future lookup updates will be picked up automatically.

• Tags separator: When a single lookup cell contains multiple tags (e.g., eventgen,os), configure the tags separator so TrackMe splits them into individual tags.

• Conflict resolution: If multiple policies match the same entity, TrackMe applies the following resolution rules:

  • Priority: Highest priority level wins across all policies

  • Tags: Tags are merged (union) across all matching policies

  • SLA: Highest-rank SLA class wins across all policies