Notable events¶
The notable-events path generates TrackMe notable events from an entity’s state — normalised JSON events written to a dedicated index whenever an alert fires. A notable here is TrackMe’s own concept: a consistent, machine-readable record of what fired and why, ready for correlation searches, third-party integration, or any custom incident workflow. (Being ordinary Splunk events, they can be consumed by anything that reads the index — but they are not tied to any particular app.)
Notables are also the backbone of the legacy third-party integration design. Two architectures are possible: scenario 1 — TrackMe alerts emit notable events into a notable index, and a single centralised alert watches that index and dispatches to Jira, ServiceNow, Slack, email, and so on; or scenario 2 — each TrackMe alert runs the third-party action directly. Scenario 1 is preferred — one place to decide what becomes an incident, normalised events, and acknowledgment handled consistently.
How it works¶
A notable is generated only when an alert fires for an entity — one event per fire.
There is no open/update/close lifecycle: each notable is an instant snapshot of the entity
at the moment it fired, written as a JSON event to the tenant’s notable index (default
trackme_notable).
Each notable carries at least: a rule name, a severity / urgency
(low / medium / high / critical), the entity identity
(object_id, tenant_id, component), its object_state, total_score, and
anomaly_reason, its priority / tags / SLA, timestamps, and a drilldown URL back to
the entity. You can review them in the entity’s Notables tab, or query them with the
tenant notable macro, for example:
`trackme_notable_idx(mytenant)` tenant_id="mytenant" object="myobject"
Notables are generated by the trackme_notable alert action, which writes the JSON
event to the tenant’s notable index (default trackme_notable).
Tip
You can also generate notables directly from an ad-hoc search with the
trackmegennotable command — useful for one-off correlation work outside the standard
alert actions.
Notables vs stateful alerting¶
Notable events |
||
|---|---|---|
Lifecycle |
One event per fire (no state machine) |
Open / update / close, deduplicated |
Channels |
Index ingest only |
Email, ingest, commands |
Consumer |
Correlation searches, third-party integration, custom workflows |
Email-first teams, automation |
Acknowledgment |
Ignored |
Honoured |
Threading |
No |
Yes |
Both can run on the same alert, so you can emit notables for correlation or integration and email a small team at once.
Note
Notables are written to the tenant’s notable index (default
trackme_notable); the target index is set on the alert action.There is no de-duplication at the TrackMe layer: a flapping entity firing every cycle floods the index. Use a less frequent schedule or stateful alerting.
Notables ignore acknowledgment — acking an entity does not suppress its notables.
If you have no notable consumer, prefer stateful alerting; unread notables just pile up.
See also
Stateful alerting — the modern, ack-aware path.
Acknowledgments — why ack does not affect notables.
Operations & Administration — index configuration and the REST API.