Entities in Splunk Observability Cloud
Learn what entities are, how they relate to telemetry and attributes, and how they appear across Splunk Observability Cloud features.
Entities in Splunk Observability Cloud represent the systems, services, and resources in your environment that you want to measure the health and performance of.
An entity can represent a physical or logical resource. Examples include infrastructure resources such as hosts and cloud instances, Kubernetes resources such as clusters, nodes, pods, and containers, and application resources such as services or service instances.
Entities provide the resource context for telemetry. In some cases, an entity emits telemetry directly. In other cases, telemetry is associated with the entity even if the entity does not emit telemetry itself. For example, a Kubernetes cluster can be represented as an entity because it provides context for the nodes and pods within it.
This entity-based model helps you explore telemetry by resource, not only by metric name. It also helps connect related data across Splunk Observability Cloud experiences, including Metric Explorer, Kubernetes monitoring, and Related Content.
What entities represent
An entity is a physical or logical component of your infrastructure or application.
- Systems such as hosts or virtual machines
- Services and service instances
- Kubernetes resources such as clusters, nodes, pods, and containers
- Cloud compute resources
- Database resources
Entities help represent the resources you monitor in Splunk Observability Cloud. For example, a metric such as CPU utilization is more useful when you can identify which host, pod, container, or service it is associated with.
Entities and telemetry
Entities are closely related to the telemetry data you monitor in Splunk Observability Cloud.
- Metrics describe measurements reported by or associated with entities.
- Logs can be correlated to entities when they share relevant attributes.
- Traces and services can be linked to infrastructure entities through cross-product experiences such as Related Content.
- Attributes help describe entities and refine how you search, group, and filter them.
In practice, entities help you move from a measurement to the resource behind it, or from a resource to the telemetry associated with it.
Why entities matter
Using entities provides a resource-centric way to discover and understand telemetry in complex environments.
- Find telemetry even when naming conventions vary across teams, integrations, or platforms.
- Explore data by service, host, pod, container, or other resource types.
- Understand which resources report a given metric.
- Compare coverage across a population of related resources.
- Navigate between related infrastructure, service, trace, and log data.
This is especially useful in large environments where users might know the resource they want to investigate but not the exact metric names associated with it.
Entities and attributes
Entities are described by attributes that can be used to identify, filter, and group them.
In entity workflows, dimensions, tags, and properties can be understood as attributes of an entity.
Examples of attributes used across Splunk Observability Cloud include host.name, region, environment, service.name, and Kubernetes metadata such as namespaces or pod identifiers.
These attributes help you narrow results, group related resources, and correlate telemetry across product experiences.
For more information about metadata concepts, see the documentation for dimensions, properties, tags, and attributes.
Entity identity
Each entity is defined by the set of attributes needed to uniquely identify an individual instance.
The exact identifying attributes depend on the entity type. In some cases, identity is based on a unique identifier such as a pod UID. In other cases, identity can be based on a combination of attributes, such as service name and environment.
If identifying attributes are inconsistent, Splunk Observability Cloud treats the resulting data as separate entities rather than merging them automatically.
How entities appear in Splunk Observability Cloud
Entities are intended to be a platform-wide concept in Splunk Observability Cloud. Their use across features is being introduced in phases.
- Metric Explorer
- On the Entities tab, you can search for resources by category, type, and attributes, then view the metrics associated with the selected entities. Metric Explorer also shows population coverage for selected entities so you can evaluate how many of them report a specific metric.
- Kubernetes entities
- The Kubernetes entities experience lets you monitor Kubernetes resources such as clusters, nodes, pods, and containers. In those views, entities can also be connected to related Kubernetes resources, APM services, logs, events, and performance analysis workflows.
- Related Content
- Related Content uses shared telemetry context to connect one type of observability data to another. In this workflow, entities help anchor navigation across related observability data.
- Entity-index mappings
-
Entity-index mappings define relationships between observability entities and specific Splunk indexes. These mappings help Related Content retrieve relevant logs more efficiently by associating entity attributes such as
service.name,host.name,deployment.environment, ork8s.namespace.namewith specific indexes and sourcetypes.
Entity examples
- Start with a Kubernetes pod entity and view the metrics associated with that pod.
- Start with an APM service and navigate to related infrastructure or logs.
- Start with a host entity and review the services or log lines associated with that host.
- Filter entities by environment or region to understand which resources report a critical metric.
Entity health
Learn how Splunk Observability Cloud derives entity health state from active alerts mapped to an entity.
Entity health state is based on the highest severity of any active alert mapped to that entity.
Entity health is intended to show whether a resource currently has active alerts that require attention. This model is based on alert severity, not on a separate calculated health score.
What entity health means
Entity health state represents the highest severity of any active alert mapped to an entity. For example, if an entity has at least one critical alert, its health state is critical.
Use the term health state rather than health status to avoid confusion with legacy terminology in other parts of the product.
How health state is determined
Health state is derived from active alerts that are associated with an entity.
- If no higher-severity alert is active, the entity reflects the highest remaining alert severity.
- If a critical alert is active, the entity health state is critical.
- If warning alerts are active and no critical alert is active, the entity health state is warning.
This model focuses on alert severity rather than on detector configuration details, service state, or a broader rollup of performance indicators.
Alert-to-entity mapping
By default, Splunk Observability Cloud maps alerts to entities automatically.
Users can adjust these associations when needed. For example, users can exclude specific alerts from affecting entity health or make bulk updates if an automatically chosen mapping does not match their intended resource relationships.
How entity health relates to the entity model
Entity health builds on the same entity model used elsewhere in Splunk Observability Cloud. An entity can be a physical or logical resource, and health state reflects the alert activity associated with that resource.
Because entities can provide resource context even when they do not emit telemetry directly, an entity can still participate in health workflows when relevant alerts are associated with it.