CMDB integration¶

The CMDB integration enriches any entity with external context — owner, contacts, asset metadata — pulled from a search you define. It surfaces on demand behind a CMDB icon on the entity, and is embedded automatically in stateful and notable alert notifications when a match is found. It is read-only: it never changes an entity’s state or score.

How it works¶

The integration is configured per component. TrackMe ships a system-wide default template (under Configure → splk-general → CMDB integration searches), and each tenant can review or override it from the Manage: CMDB integration screen. From there you enable or disable the integration for the tenant, choose the Splunk deployment the lookup runs on (local, or a configured remote account for a remote CMDB), and edit the CMDB search template:

The Manage CMDB integration modal for the Data Host Monitoring component — Enable CMDB integration (Yes), Splunk deployment (local), the tenant-level configuration source with the system default, and the CMDB search SPL editor with its available tokens

The guided lookup builder in the same modal — Step 1 select a lookup transform (example_cmdb csv), Step 2 map lookup fields to entity tokens (ci_name to the alias token), then Generate SPL

The search template is any SPL, with entity tokens that are auto-filled at run time — $alias$ , $object$ , $data_index$ , $data_sourcetype$ and $tenant_id$ . For example, the Data Host Monitoring default looks up a CMDB lookup keyed on the host alias:

| inputlookup my_cmdb where (host="$alias$")

You do not have to write the SPL by hand: the guided lookup builder lets you pick a lookup transform, preview its content, and map one or more lookup fields to entity tokens — TrackMe generates the SPL for you (shown above). Because the template is arbitrary SPL, it can query a CSV or KV Store lookup, call a custom command, or reach an external ITSM such as ServiceNow or Jira.

Note

The lookup or transform the template uses must be visible in the TrackMe app context (or on the selected remote account). Enrichment is read-only — it does not affect monitoring.

Under the hood, enrichment is performed by the trackmesplkcmdb command, which takes tenant_id, component (matching ^(?:dsm|dhm|mhm|cim|flx|wlk)$) and either object or object_id — the latter being the KV Store key; pass one, not both. To troubleshoot a template, run it manually and inspect index=_internal sourcetype=trackme:custom_commands:trackmesplkcmdb.

On demand, from the entity¶

Clicking an entity’s CMDB icon runs the template and renders the result inline — the full CMDB record, together with the exact trackmesplkcmdb command and the translated Splunk query it resolved to, which makes troubleshooting straightforward. An empty result shows a clear “no results” message:

The on-demand CMDB lookup result for an entity — the CMDB record (asset_tag, business_service, ci_class, ci_type, city, data_center, environment, fqdn, ...) with the trackmesplkcmdb search query and its translated inputlookup query

Enrichment at alert time¶

The same per-component templates also enrich alerts automatically when they fire: the stateful and notable alert actions run the entity’s CMDB search at firing time and embed the result under the event’s cmdb field, so downstream consumers (email, ES, a SOAR playbook, a ticket) receive the owner and asset context inline — no separate enrichment step:

A stateful-alert incident event in the entity's Incidents view, with the embedded cmdb field expanded — ci_contact, ci_desc, host and importance pulled from the CMDB at firing time

It is controlled per tenant, from the same Manage: CMDB integration screen: the Enable CMDB integration toggle (on by default) turns it on, and the Splunk deployment setting selects whether the template runs locally or against a remote account. Enrichment is best-effort — if the lookup fails the alert still fires, just without the cmdb field.