Managing tenants¶

Once a tenant exists, everything you do to it is on its three-dot menu in the Virtual Tenants grid. This page covers that menu — configuration, access, enabling and disabling, deletion — and the two things you watch to keep a tenant healthy: its operational status and its scheduling.

Tenant administration screen — management menu

Tenant administration screen — operational status

The tenant menu¶

Everything you can do to a tenant is on its three-dot menu on the tenant card. The menu is grouped into Access, Search, and Administration actions, plus a personal hide/show preference; the administration actions are available to tenant admins.

Menu action	What it does
Open the Virtual Tenant	Opens the tenant’s home page (you can also double-click the card).
Open SLA overview	Opens the SLA dashboard — the percentage of time each entity spent green.
Search summary / audit / notable events, Search metrics	Deep links into Splunk search, pre-scoped to the tenant’s indexes.
View knowledge objects	Lists every knowledge object the tenant owns, with its type — useful for auditing.
Manage components	Add or remove monitoring components on the tenant.
Configure tenant	The per-tenant settings editor (see Configuring a tenant).
RBAC & ownership	Change the admin / power / user roles and the owner; existing knowledge objects are re-permissioned and, if the owner changes, re-assigned. See Roles & access control.
Restrict access by user	Limit the tenant to a named list of users, on top of role-based access; the card then shows a Restricted badge.
Clear operational status	Reset a stuck operational status once you have fixed the cause (see Operational status).
Disable / Enable the tenant	Pause or resume the tenant without deleting anything (see below).
Delete the tenant	Permanently destroy the tenant (see below).
Hide / Unhide this tenant	A personal preference that shows or hides the tenant in your grid — it ties into the `showHiddenTenants` preference (see Personal preferences).

Warning

Removing a component (via Manage components) permanently deletes that component’s knowledge objects and purges its data. The only way back is a restore from backup. Prefer disabling the tenant if you are unsure.

Configuring a tenant¶

Configure tenant opens a tabbed editor for everything about a tenant that is not its identity or its components. From here you set, per tenant: priority and pagination defaults, UI preferences, the disruption queue, the delayed-entities inspector, auto-disablement and search constraints, CMDB integration, documentation, group-by settings, access control, impact scoring, and AI settings. Most of these features are explained in their own parts of this guide — this modal is where you tune them for one tenant.

Enabling and disabling¶

Disabling a tenant is the safe, reversible alternative to deleting it:

Disable the tenant sets the status to disabled: all the tenant’s knowledge objects are disabled in Splunk, no trackers run, no entities are maintained — but no data is destroyed. Disabled tenants are hidden in the UI unless you turn on the showHiddenTenants preference (see Personal preferences).
Enable the tenant brings it straight back.

Deleting a tenant¶

Warning

Deletion is permanent and irreversible. It drops the tenant’s data collections, removes its configuration and its role triplet, deletes its scheduled trackers, and purges its Configuration Guardian alerts. Previously generated events and metrics are left untouched in your indexes. Hybrid trackers must be re-created if you ever rebuild the tenant. The only recovery path is a restore from backup — when in doubt, disable instead of delete.

Operational status¶

TrackMe continuously monitors itself. Every tracker and custom command reports failures to a central register, and a per-tenant health tracker (running every five minutes) turns that into health events you can see directly on the tenant card.

Common causes of a failing operational status:

An overloaded environment with no available search slots.
A search head in detention.
Network or credential issues (especially toward a remote deployment — see Integrations & Remote Deployments).
Corrupted configuration: missing knowledge objects or incorrect permissions.

To investigate:

Click the operational-status chart on a tenant to see the affected tenants, related accounts, and the root cause; Open in search drills into the per-tracker results.
Health events land in the tenant’s audit index, for example index=trackme_audit sourcetype="trackme:health" last_status="failure".
Once you have fixed the cause, use Clear operational status from the tenant menu to reset the recorded status. It defaults to the current tenant but you can widen the scope to others — or all tenants — and optionally re-run the health-check tracker as it clears, with a note for the audit trail.
The Audit → Operational Statuses dashboard gives the cross-tenant view.

The per-tenant execution summary is stored centrally; inspect it with:

| inputlookup trackme_virtual_tenants | fields tenant_id, tenant_objects_exec_summary

Scheduling and tracker health¶

TrackMe depends on its trackers being scheduled and running on time. You monitor that from the Virtual Tenants UI:

Aim for zero skipped searches. Skipped trackers mean the deployment is short on search slots or CPU — review search performance or add capacity.
Trackers log their own run-time KPIs; the TrackMe Performance Deepdive dashboard surfaces them.
Automatic re-attempts: when maximum search concurrency is hit, TrackMe retries (logged as a temporary failure). If the retry limit is reached it logs a permanent failure and cancels that run.

Tip

DEBUG logging is very verbose — enable it only while troubleshooting, from Configuration → System settings → Logging, and turn it back down afterwards.

Under the hood and via the API¶

The tenant lifecycle is fully scriptable through the vtenants/admin endpoints (all mode=post unless noted): update_tenant_rbac, enable_tenant, disable_tenant and del_tenant (mode=delete). Operational status is produced by a per-tenant health tracker, trackme_health_tracker_tenant_<tenant_id> (every ~5 min, running | trackmetrackerhealth tenant_id="<tenant_id>"); read it with the configuration/get_tenant_ops_status endpoint and clear it with vtenants/admin/clear_exec_summary. The trackers themselves are orchestrated by the trackmetrackerexecutor command — inspect scheduling at index=_internal sourcetype=trackme:custom_commands:trackmetrackerexecutor.