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-01 and appserver-02, but C doesn't match to anything. ITSI displays their names as appserver-01, appserver-02, and 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

Entity pivot

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=Florida and datacenter=Georgia. You make a Florida entity and a Georgia entity and add them to your service. Then you filter a KPI by Georgia and 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:

Entity broadcast

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.