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 (itsi_summary).

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

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 below.

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 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=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 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:

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 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.