TrackMe Ecosystem — Companion Add-ons

What this page is

An inventory of every TrackMe companion technology add-on (TA) and the Splunk SOAR (Phantom) connector that extend TrackMe beyond the main trackme Splunk app. For each one: purpose, data it ingests / produces, Splunk surfaces (commands, REST handlers, alert actions), the TrackMe use cases it unlocks, dependencies, and which FLX templates pair with it (if any).

Audience:

TrackMe administrators, architects, and operators scoping what else they can plug into TrackMe.

Three axes of extension

TrackMe alone monitors data that already lives in Splunk (indexes, scheduled searches, hosts, sourcetypes, fields, lookups via Splunk REST) and orchestrates alerts / AI within the Splunk surface. The companion add-ons extend TrackMe in three orthogonal directions:

1. External data sources made first-class TrackMe entities — Cribl Stream / Edge pipelines and fleet nodes (TA-trackme-cribl), Google SecOps log feeds (TA-trackme-google-secops), and lookup files / KV-stores at filesystem-mtime precision (TA-trackme-lookupmonitor). All can be turned into FLX or hybrid-tracker entities that participate in priority, SLA, ML outliers, stateful alerting and the AI Assistant — exactly like native DSM entities.

2. Bidirectional incident orchestration with external systems — TA-trackme-xsoar (Cortex XSOAR active-command incident lifecycle with a resilient retry store) and trackme-app-on-soar (Splunk SOAR playbook-driven ACKs, maintenance windows, ML retraining, logical-group management and priority / policy bulk-edits).

3. Operational resilience and deployment flexibility — TA-trackme-conf-manager for transactional, retryable TrackMe REST orchestration (CI / IaC pipelines).

Without the companions you keep an in-Splunk monitoring tool. With them, TrackMe becomes a multi-vendor data-quality control plane that closes the loop into the SOC’s ticketing, automation, and configuration-management workflows.

Common architectural patterns

Two patterns appear repeatedly across the companion add-ons:

• API-bridge pattern — A single custom command (cribl / secops) plus a small persistent REST handler for account configuration. Used by TA-trackme-cribl and TA-trackme-google-secops. From TrackMe’s perspective, the command makes external API data look like SPL events so any FLX or hybrid tracker can consume it.

• Resilient transaction store — A KV collection (per-account, replicate-false) records pending / failed REST transactions, plus a 15-minute scheduled saved-search replay loop. Used by TA-trackme-conf-manager (against TrackMe’s own REST) and TA-trackme-xsoar (against the XSOAR REST). Guarantees that a transaction eventually lands even through network blips or destination outages.

External data sources

TA-trackme-cribl

Purpose	Two-way Splunk-to-Cribl-API bridge for both Cribl Stream (Logstream) and Cribl Edge, callable from SPL via | cribl.
Splunk surfaces	Custom command cribl (GET / POST / DELETE with built-in helpers: get_groups_conf, get_global_metrics, get_destinations_metrics, get_pipelines_metrics, get_routes_metrics, get_edge_fleets, get_edge_nodes, get_edge_fleets_conf); persistent REST handler at /services/cribl/v1/... for account access / test connectivity; UCC account config (Cloud or on-prem leader URL, client_id / secret, SSL, RBAC); capability criblapi, role cribl_api.
TrackMe use cases unlocked	FLX live-API tracking of Cribl Edge node health via cribl_edge_fleet_api (the only FLX template that hard-depends on | cribl). Hybrid trackers / ad-hoc SPL where TrackMe entities can be defined directly from Cribl API output (workers count, route traffic, pipeline status, packs) without needing Cribl to forward metrics to Splunk first. Real-time queries of pipeline / route / destination metrics from inside TrackMe scheduled trackers.
Dependencies	Cribl Stream or Cribl Edge deployment with API access; Cribl client_id / secret. Independent of trackme-app at runtime; the FLX template above and the use-case docs are oriented around TrackMe.
FLX templates that pair	Hard requirement: cribl_edge_fleet_api. Independent (relies on Cribl-shipped internal metrics in a Splunk metrics index): cribl_edge_fleet_metrics, cribl_logstream_health_inputs, cribl_logstream_health_outputs, cribl_logstream_hosts_cpu_usage, cribl_logstream_output_destination_pressure, cribl_logstream_pack_traffic, cribl_logstream_pipeline, cribl_logstream_route_traffic, cribl_logstream_total_traffic_inputs, cribl_logstream_total_traffic_outputs. These do not need the TA but operate in the same monitoring family.
See also	Cribl monitoring, Cribl Stream & Edge API.

TA-trackme-google-secops

Purpose	Splunk SPL bridge to Google Security Operations (Chronicle) UDM search API.
Splunk surfaces	Custom command secops (runs UDM queries through udmSearch, auto-applies Splunk’s time range, limit configurable); REST handler at /services/secops/v1 for account / test connectivity; UCC account (GCP project ID, SecOps instance UUID, region, service-account JSON key encrypted, RBAC roles); capability secopsapi, role secops_api.
TrackMe use cases unlocked	Hybrid trackers and FLX entities driven by Google SecOps log feed ingestion — e.g. one entity per metadata.log_type (NGINX / APACHE / …) tracking event count, last-seen, ingest delay, or anomalies. Effectively extends DSM-equivalent monitoring to data living in Chronicle, with the same toolkit (priority, SLA, stateful alerting, AI Assistant) used for Splunk-side feeds.
Dependencies	Hard dependency on trackme-app — the README explicitly states: “TrackMe must be installed and licensed on the search head(s) where this application is deployed. The ``secops`` custom command will fail with a licensing error” — the TA reuses TrackMe’s licensing framework. GCP service account with roles/chronicle.viewer + roles/serviceusage.serviceUsageConsumer. Network reachability to {region}-chronicle.googleapis.com.
FLX templates that pair	None ship — operators build SecOps trackers directly via the | secops command.

TA-trackme-lookupmonitor

Purpose	Generative SPL command that enumerates CSV-file and KV-store lookups visible to the running user with reliable filesystem mtimes and accurate row counts.
Splunk surfaces	Custom generating command trackmelookupsmonitor (local = true — runs on the dispatching SH only); UCC config with logging-level controls. No dashboards / REST API / alert actions.
TrackMe use cases unlocked	This is the data source behind TrackMe’s “Lookups monitoring” search mode in the Hybrid Trackers wizard — see Lookup monitoring. It lets a tenant create TrackMe entities, one per lookup, tracking last-modification freshness and growth / shrinkage of row count — so you can build alerts like “this critical KV-store collection hasn’t been updated in 24 h” or “this CSV lookup just lost 90 % of its rows”. Pair with splunkremotesearch to inventory lookups across remote SHs (the TA must be installed on the remote SH too; trackme-app itself does not need to be there).
Dependencies	None external. Stand-alone usable; integrates with trackme-app only via the Hybrid Trackers wizard.
FLX templates that pair	None — lookups monitoring is implemented as a dedicated hybrid-tracker search mode rather than via FLX templates. Note: splk_large_lookup_files solves an adjacent problem (oversized lookups) using a Splunk REST call (/services/data/transforms/lookups) — independent of this TA.
See also	QUICK START - Design and automate through lookup knowledge, Lookup monitoring.

Bidirectional incident orchestration

TA-trackme-xsoar

Purpose	Cortex XSOAR (Palo Alto) REST-API integration with a built-in resilient retry store for incident-creation calls.
Splunk surfaces	Custom commands xsoar (generic GET / POST / DELETE), xsoarstreamincident (streaming command that creates / updates / closes incidents, keyed by external_incident_id), xsoarresilient (replay loop); persistent REST handler at /services/xsoar/v1/...; scheduled saved search xsoarresilient (every 15 min, enabled by default) replaying failed REST calls; UCC account configuration (key + key ID), capability xsoarapi.
Storage	Two KV collections (replicate-false): kv_xsoar_resilient_store (pending / failed transactions — account, endpoint, body, status, attempts, last_error), kv_xsoar_incidents_store (XSOAR incident IDs ↔ external IDs mapping so updates / closures from TrackMe stateful alerts can reach the right XSOAR incident).
TrackMe use cases unlocked	Bidirectional bridge between TrackMe stateful alerts and Cortex XSOAR incidents — the README documents the exact wiring as active commands in TrackMe stateful alerts: commands_opened creates an XSOAR incident, commands_updated patches it with new state, commands_closed closes it. The resilient store guarantees incident parity even through network blips or XSOAR outages. Use case: TrackMe entity goes red → XSOAR ticket auto-opens; entity recovers → ticket auto-closes.
Dependencies	Cortex XSOAR API key + key ID; network reachability to XSOAR. No external trackme-app dependency at install time (FIPS- compatible, standalone or SHC), but is purpose-built for TrackMe stateful-alert integration.
FLX templates that pair	None. The splk_soar_* family of FLX templates targets Splunk SOAR (Phantom), not XSOAR.
See also	Palo Alto XSOAR Integration.

trackme-app-on-soar (Splunk SOAR connector)

Purpose	A Splunk SOAR (Phantom) app, not a Splunk TA — runs inside SOAR and exposes TrackMe REST endpoints as SOAR actions so playbooks can drive TrackMe entities.
SOAR surfaces (actions)	test connectivity; ack_get, ack_manage (sticky / unsticky, set, extend); maintenance_status, maintenance_enable, maintenance_disable; tenants_ops_status (per-tenant OPERATIONAL / DEGRADED); remote_accounts_check_connectivity; ml_outliers_train_models, ml_outliers_run_monitor, ml_outliers_reset_models, ml_outliers_get_models, ml_outliers_add_period_exclusion; component_get_entity, component_manage_entity (enable / disable / delete + per-action extras manage_dsm_sampling, update_hours_ranges, update_wdays, update_priority, update_lag_policy, update_dcount_host, update_manual_tags); smart_status; logical_group_get_group_for_entity, logical_group_manage.
TrackMe use cases unlocked	SOAR-driven, playbook-orchestrated TrackMe operations: auto-ACK an entity from a SOAR playbook when an upstream maintenance ticket opens; un-ACK when it closes; trigger Smart Status investigation from SOAR after correlating with another SIEM signal; bulk priority / lag policy / hours-ranges adjustments driven by an external CMDB; on-demand ML model retraining / model exclusion windows around known noisy periods (deployments, batch jobs); enable / disable global maintenance from a SOAR incident-response playbook before scheduled changes; logical-group membership management from SOAR (group entities by app / service when the inventory changes upstream).
Dependencies	Splunk SOAR (Phantom) 6.0.2+. Splunk bearer token with TrackMe RBAC. Network reachability to Splunkd HTTPS. Requires trackme-app on the Splunk side.
FLX templates that pair	None — this is a SOAR-side connector, not a Splunk add-on. The splk_soar_* FLX templates monitor a Splunk SOAR deployment’s health; they consume Splunk-side SOAR-forwarded data and TrackMe’s own trackmesplksoar command, independent of this SOAR connector.
See also	TrackMe App on SOAR, Splunk SOAR.

Operational resilience

TA-trackme-conf-manager

Purpose	Resilient transactional layer for replaying failed configuration changes against the TrackMe REST API — accepts a config transaction, persists it, and re-attempts on a schedule until it lands.
Splunk surfaces	Custom search command trackmeconfmanager (modes live / get / simulation); persistent REST handler at /trackme_conf_manager/v1; scheduled saved search trackme_conf_manager_producer (every 15 min, disabled by default — operator opt-in) that calls | trackmeconfmanager mode="live" to replay pending transactions; diagnostic saved searches for transactions, simulation, access logs, KV-store content.
Storage	KV collection kv_trackme_conf_manager (replicate-false).
TrackMe use cases unlocked	Idempotent / retryable orchestration of TrackMe REST calls — useful for SOAR playbooks, infra-as-code (Ansible / Terraform- style) deployments, and CI pipelines that bulk-configure tenants, entities, policies, ACKs, maintenance windows, etc. Submit a transaction once, the TA keeps trying until it succeeds.
Dependencies	Requires trackme-app (it wraps TrackMe REST calls). No external system.
FLX templates that pair	None — pure orchestration, not a data source.

At-a-glance dependency map

Quick reference: who needs whom.

Add-on	Needs trackme-app?	External system needed
TA-trackme-cribl	No (works standalone, but TrackMe use cases require it)	Cribl Stream or Cribl Edge with API access
TA-trackme-google-secops	Yes — hard licensing dependency	GCP Chronicle SecOps with service account
TA-trackme-lookupmonitor	No (integrates via Hybrid Trackers wizard)	None
TA-trackme-xsoar	No (FIPS-compatible, standalone)	Cortex XSOAR with API key
TA-trackme-conf-manager	Yes — wraps TrackMe REST	None
trackme-app-on-soar	Yes — calls TrackMe REST	Splunk SOAR (Phantom) 6.0.2+