Generate pseudo entities in ITSI
A pseudo entity in IT Service Intelligence (ITSI) is an entity automatically generated when you split a KPI by entities. It's not a real entity because it has no ID and isn't stored anywhere except in the itsi_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 and filter a KPI by entities in ITSI. You don't create a pseudo entity if you split a KPI by entity and filter to entities in the service, unless you perform an entity pivot. For instructions, see Entity pivot in this topic.
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 are visible in the Service Analyzer but they aren't clickable.
The entity key of a pseudo entity is
N/A because ITSI can't find a match in the lookup to populate that field with an ID. The entity name 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. For more information about entity broadcast, see Entity broadcast in this topic.
To configure an entity pivot during KPI configuration, provide a different value for the entity filter field than you do for the entity split field. Entity pivots are useful because you can associate entities with a 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 and small entities that you want to monitor. However, you don't have to keep track of them in a change management database (CMDB) sense.
When to use entity pivot
Consider using entity pivot if you dynamically start and stop virtual machines, or if 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 Entity Filter Field, not on the Entity Split Field. Because the services is filtered based on entities, you don't need to worry about pseudo entities being assigned to the wrong service.
Entity pivot example
You configure the following metric KPI to monitor CPU usage by process:
| mstats avg(_value) as alert_value WHERE index=itsi_im_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 Entity Filter Field, not on the Entity Split Field. If you use entity pivot and the filter and split by fields are the same, all entities and pseudo entities within that filter belong 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, isn't broadcasted if it belongs to a service due to the filter field. 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 perform 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 perform a lookup 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. You need to either statically assign the entity to a service, or match it 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. For more information, see eval in the Search Reference manual.
Set up a recurring import of entities in ITSI
Resolve conflicts during ITSI entity imports
This documentation applies to the following versions of Splunk® IT Service Intelligence: 4.5.0 Cloud only, 4.5.1 Cloud only, 4.6.0 Cloud only, 4.6.1 Cloud only, 4.6.2 Cloud only, 4.7.0, 4.7.1, 4.7.2, 4.7.3, 4.7.4, 4.8.0 Cloud only, 4.8.1 Cloud only, 4.9.0, 4.9.1, 4.9.2, 4.9.3, 4.9.4, 4.9.5, 4.9.6, 4.10.0 Cloud only, 4.10.1 Cloud only, 4.10.2 Cloud only, 4.10.3 Cloud only, 4.10.4 Cloud only, 4.11.0, 4.11.1, 4.11.2, 4.11.3, 4.11.4, 4.11.5, 4.12.0 Cloud only, 4.12.1 Cloud only, 4.13.0