Manage pseudo entities in ITSI
A pseudo entity in IT Service Intelligence (ITSI) is an entity that's automatically generated by a KPI split. It's not a real entity because it has no ID and isn't stored anywhere except in the summary index.
You create a pseudo entity if you split a KPI by entity but the entity split field isn't matched in the entity lookup. For more information about splitting a KPI, see Split by entity in the KPI configuration workflow. You won't create a pseudo entity if you split a KPI by entity and filter to entities in the service, unless you do an entity pivot. For instructions, see Entity pivot below.
Pseudo entities appear in the UI as the field value of the entity split field. For example, if you split by
host and the host values are A, B, and C, it's possible that A and B match to entities with titles of
appserver-02, but C doesn't match to anything. ITSI displays their names as
C. Pseudo entities aren't clickable in the Service Analyzer.
The entity key of a pseudo entity is
N/A because ITSI can't find a match in the lookup to put a real ID in that field. The entity title field is the only thing that identifies a pseudo entity because alias normalization isn't possible without an entity record.
The following table describes the advantages and disadvantages of using pseudo entities:
|Advantages of pseudo entities||Disadvantages of pseudo entities|
|Increase the speed of setup because you don't have to configure entities||Don't have an entity details page|
|Perform better than entities because they don't require a lookup||Can't be displayed in a deep dive swim lane|
|Better management of dynamic entities using entity pivot||Don't allow for entity normalization, and you can't use them to filter to anything|
An entity pivot lets you associate pseudo entities to a particular service, even through a shared base search without entity broadcast. To configure an entity pivot, provide a different value for the entity filter field than you do for the entity split field during KPI configuration. Entity pivots are useful because you can filter to entities in the service while still using only pseudo entities.
For example, instead of creating entities that are hosts, you want to create large groups of entities that you can filter on in your data. You have a service called
American Southeast and you filter the data with
datacenter=Georgia. You make a Florida entity and a Georgia entity and add them to your service. Then you filter a KPI by
Florida but split it by
host. By using entity pivot, you can have relatively static entities that act as pure filters, and lots of highly dynamic small entities that you want to monitor, but you don't have to keep track of them in a CMDB sense.
When to use entity pivot
Consider using entity pivot if you dynamically spin up and down virtual machines or you use a system like Kubernetes and you want to split by pod. Virtual machines and pods are difficult to define as entities because they're too dynamic. As pseudo entities, they're defined at the time the KPI search runs. You can filter based on relatively static entities, but split on the dynamic entities.
ITSI allocates service membership in shared base searches based on the filter field, not based on the split by field. Therefore, you don't need to worry about pseudo entities being assigned to the wrong service.
Entity pivot example
You configure the following metrics KPI to monitor CPU usage by process:
| mstats avg(_value) as alert_value WHERE index=em_metrics metric_name="processmon.cpu.percent" by process_name, host
To perform an entity pivot and associate those dynamic processes to a service, you split by
process_name but filter by
host. Each host acts as the filter and associates processes to that particular service. Each process is defined at the time the KPI search runs.
The following image shows the entity split and filter configuration:
If you have pseudo entities but you don't filter to entities in the service, and you try to use that pseudo entity in a shared base search, the entity is assigned to all services. This functionality is called "entity broadcast".
Entity broadcast occurs because service membership is based on the filter field, not on the split by field. If you use entity pivot and the filter and split fields are the same, all entities and pseudo entities within that filter belongs to that service. However, as soon as an entity belongs to no services, it belongs to all services. This functionality is not ideal except in rare scenarios.
A pseudo entity, even though it has
entity_key=N/A, will never be broadcasted if it belongs to a service due to the filter field (entity pivot). Defined entities can never be broadcasted.
Pseudo entities in correlation searches
If you have a pseudo entity in your correlation search, you need to either statically assign it to a service, or do an entity lookup based on what is traditionally the entity filter field in a pivot scenario. An entity lookup in a correlation search needs to look up on the large group of static entities, if you have that type of entity, instead of looking up on host. For more information, see Entity pivot above. In other words, you must either statically assign the entity to a service, or match against something other than that entity.
No entity relationship option exists in ITSI, and there are no additional metadata fields available for pseudo entities. As a workaround, you can associate two fields to each other using the
eval command to create the entity title field.
Bulk delete entities in ITSI
Overview of services in ITSI
This documentation applies to the following versions of Splunk® IT Service Intelligence: 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.1.0, 4.1.1, 4.1.2, 4.1.5, 4.2.0, 4.2.1, 4.2.2, 4.2.3, 4.3.0, 4.3.1, 4.4.0, 4.4.1