[ECO] Inventory Telemetry

[roshan-elastic]

📖 Description

Add minimal telemetry to help us understand adoption of the Inventory.

✔️ Acceptance criteria

Draft

1. Must Have

Must be delivered in this issue in order for the release to be valuable

Name	Description	Final Specs
❌ We must track whether EEM is enabled for a user or not	Could we populate something in context object consistently around Kibana? e.g. context.eem_enabled : true. Please shout if this is tricky so we can see if we want to do this.	Add eem_enabled to context. It will be populated only if Inventory plugin is accessible to the users, and once they access the Observability solution. ⚠️ We’ve decided not to proceed with the implementation. You can find the details here.
We must track whether views to the Inventory page are in an 'empty state' or not	Maybe we just trigger an event when someone views the inventory which has properties which defines if it is in an empty state or not?	Event name: Entity Inventory Viewed Properties.view_state: empty / populated / eem_disabled
We must track searches	Can we re-implement the same telemetry as per APM unified search for now? We just want to track when someone searches as a minimum	Event name: Entity Inventory Search Query Submitted Properties.kuery_fields Properties.entity_types Properties.action: submit / refresh
🆕 We must track entity type filtered	The entity type filter is treated as a separate action from the search submit	Event name: Entity Inventory Entity Type Filtered Properties.entity_types Properties.kuery_fields
We must track click throughs on entity views	Can we track a very simple event (event_type : "entity view click") when someone clicks on an entity which passes in info to a properties object, e.g. properties.entity_type : "service" and properties.view_type as detail view (in the future, we'll probably have add 'fly out' buttons so we can differentiate. Note that we can't pass in the entity name for privacy reasons.	Event name: Entity View Clicked Properties.entity_type: service / container / host Properties.view_type: detail / flyout

4. Will Not Have (for now)

Explicitly will not be looked at within this issue

Name	Description
-	-

[elasticmachine]

Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services)

[roshan-elastic]

Note : Not required for 8.16 (we can get some basic metrics from the properties.target fields)

[iblancof]

Hi @roshan-elastic ,

as part of the refinement here are some questions/proposals (following the conventions) for the required events:

Whether EEM is enabled for a user or not (⚠️)

The description suggests adding information about whether EEM is enabled in the context property of the event. While it’s technically possible, I’m unsure if it’s a good practice to include such specific details in a general context. It seems that all the information in context is quite generic and not tied to any specific solution. Adding this information would also propagate to the ES and Security solutions, introducing unnecessary noise to the event.

If I recall correctly, something similar was done in the past for serviceInventoryViewType (PR for tech reference), but I’m not sure if the matter was questioned in the same way I’m addressing it now.

To recap, we can proceed as we did in the past, but I want to ensure we’re "allowed" to do this, as I don’t believe it’s a good practice and I can’t find any documentation on the rules regarding it.

If we didn’t consult with the team who owns analytics for serviceInventoryViewType, we have two options now:

• Ask the analytics owner (though I’m not sure who they are at the moment) how they recommend gathering this type of information in a way that can be shared across multiple events.
• Move forward without any comments as a temporary workaround and later ask for their recommendations to ensure a consistent telemetry experience in the future.

Whether views to the Inventory page are in an 'empty state' or not (❓)

For this one I have two proposals depending on the answer to this question:
When should we trigger this? Only when the list is visible (which would mean EEM is enabled)?

If yes:
Event name: Entity Inventory List Viewed
Properties.view_state: empty | populated

If no and we want to trigger this every time the user accesses the Inventory, regardless of whether EEM is enabled:
Event name: Entity Inventory Viewed
Properties.view_state: empty | populated | eem_disabled

Searches (✅)

Event name: Entity Inventory Search Query Submitted
Properties.kuery_fields
Properties.timerange Edit: Removed the timerange filter, as it’s not available at the moment.
Properties.action: submit | refresh

Click throughs on entity views (✅)

Event name: Entity View Clicked
Properties.entity_type: service | container | host
Properties.view_type: detail | flyout

cc: @kpatticha

[kpatticha]

Regarding the context,

The framework allows the plugins to extend the context by analytics.registerContextProvider we just need to be cautious about not overusing it. https://docs.elastic.dev/telemetry/collection/event-based-telemetry#adding-context-to-the-event

[roshan-elastic]

Hey @iblancof,

Thanks for this!

Whether EEM is enabled for a user or not (⚠️)

Yeah, I was figuring this might be contentious. We're basically trying to capture the number of users who are eligible to use the new experience - regardless of whether they visit Inventory or not. However, I answering that is too tricky for this issue so it makes sense to trim this requirement back a bit.

Could we populate it in the context object if you're in some of our pages? e.g. Inventory, APM app, metrics app?

Trying to think what might be easiest here.

Thought : Maybe it would be in the properties object but I assume you'll need to pass that in each specific event vs just setting it in context

Event name: Entity Inventory Viewed
Properties.view_state: empty | populated | eem_disabled

This sounds good to me!

[iblancof]

Hi @roshan-elastic,

regarding the context is feasible for us to add it by using what @kpatticha shared, is the same we did for serviceInventoryViewType in the past and is not super tricky. It's more a matter of it being not the best considering that the events context is shared across all the project because is meant to be like that.

We're basically trying to capture the number of users who are eligible to use the new experience

If adding this to the context is the only way to check it, let's go ahead. However, I’d like to follow up with the analytics core team once this is merged to see what they recommend for similar cases, as this likely isn't an issue unique to our team.

[roshan-elastic]

Hey @iblancof - I slacked you but quick Q:

If we populate the context object will it persist outside of the Kibana apps we manage?

Or, will it just it just populate on the pages we own?

I'm happy either way - feel free to go ahead with whichever seems more sensible from an engineering POV.

[iblancof]

Hey @iblancof - I slacked you but quick Q:

If we populate the context object will it persist outside of the Kibana apps we manage?

Or, will it just it just populate on the pages we own?

It will be persisted across ALL Kibana apps, including Search, Security, Analytics, etc. (as mentioned in this previous comment).

Let’s go ahead and implement it, and I’ll explore other alternatives we might consider for future developments, including a potential refactor for eem_enabled.

[roshan-elastic]

Sounds good @iblancof !

One question to help me understand the telemetry - if a user opens a completely different page in Kibana (and never visits inventory) - will the context.X be populated with whether EEM is enabled or not? Or, will it only start populating once a user visits Inventory (and then it will persist from that point onwards around Kibana in the context.X)?

[iblancof]

One question to help me understand the telemetry - if a user opens a completely different page in Kibana (and never visits inventory) - will the context.X be populated with whether EEM is enabled or not? Or, will it only start populating once a user visits Inventory (and then it will persist from that point onwards around Kibana in the context.X)?

Adding attributes to the telemetry context occurs during plugin setup and is not related to whether the user visits the page, it's part of Kibana's initialization. In fact, I've checked in serverless with only Search, and the new attribute also appears.

The visibility of Inventory is controlled by the entityCentricExperience advanced setting, which is always set to true by default, along with the configuration of spaces and user permissions.

We can try to include eem_enabled only when the Inventory plugin is available to users, meaning when the advanced setting is enabled and it's accessible in the navigation (because of space config, user permissions or serverless with Observability).

With this workaround, we can ensure that we only add content to the context when the user has access to Inventory.

How does the proposal sound to you @roshan-elastic ?

[iblancof]

Hey @roshan-elastic,

just adding something to my previous response.

I’ve been looking into whether we could add eem_enabled to the context once the user visits the Inventory page for the first time, and I believe we could do that.

However, I don’t think this would fully cover what we want to analyze, which, as I understand it, is how the user interacts with the platform depending on whether EEM is enabled or not.

I think the decision on when to add the attribute depends on what exactly we want to analyze.

Please let me know what would work better for us, thanks!

[roshan-elastic]

Hey @iblancof ,

Quick clarification - are you checking if the entityCentricExperience feature flag is enabled or whether someone has clicked to enable EEM itself (i.e. the transforms)?

My guess is that checking the feature flag is easy to put in the context object (and perhaps this is what you are doing)?

What I was hoping to find out is whether EEM itself is enabled (which I assume is an API call which is only checked in Inventory)?

If you're checking the feature flag entityCentricExperience, could you rename the context.NAME to context.entityCentricExperience (if not too late? we can always change it in an upcoming PR - it's not critical).

If you're checking if EEM itself is enabled, could you let me know the behaviour and when the context.eem_enabled is set?

Either way, I want to minimise any further work on this as I know you've probably spent a bit of time on this - we can always fix this in a follow up issue if we need to change what you've implemented if that's easier.

[iblancof]

Quick clarification - are you checking if the entityCentricExperience feature flag is enabled or whether someone has clicked to enable EEM itself (i.e. the transforms)?

My guess is that checking the feature flag is easy to put in the context object (and perhaps this is what you are doing)?

Hey @roshan-elastic, you’re right that I mistakenly assumed from the start we were talking about the entityCentricExperience Advanced Setting.

What I was hoping to find out is whether EEM itself is enabled (which I assume is an API call which is only checked in Inventory)?
If you're checking if EEM itself is enabled, could you let me know the behaviour and when the context.eem_enabled is set?

Regarding how to determine if EEM is enabled or not, it indeed requires an API call. As for setting eem_enabled in the context, it needs to be done during the plugin setup, which is what I mentioned in a previous comment:

"Adding attributes to the telemetry context occurs during plugin setup and is not related to whether the user visits the page, it's part of Kibana's initialization."

Either way, I want to minimise any further work on this as I know you've probably spent a bit of time on this - we can always fix this in a follow up issue if we need to change what you've implemented if that's easier.

I’ve been busy with other tasks, so I haven’t gotten to the context implementation yet. We can go ahead this way without any problems.

Summary

• The eem_enabled attribute will reflect the EEM enablement status, rather than the entityCentricExperience Advanced Setting.
• This new attribute must be configured during the plugin setup (when Kibana is loaded).
• An API call will be made during plugin setup to retrieve the EEM enablement value.
• If EEM is initially disabled and the user activates it by accessing Inventory and enabling it, the eem_disabled status will be updated accordingly.

[roshan-elastic]

Brilliant @iblancof! That's exactly how I was hoping we could get it to work.

If you think the scope of this is pretty significant and should be split out into a separate task - let me know.

[iblancof]

During development, it has been noted that the entity type filter is not included in the same search submit action, so there will be a couple of new changes:

• A new event, "Entity Inventory Entity Type Filtered," will be introduced with entity_types and kuery_fields.
• Regarding the "Entity Inventory Search Query Submitted" event:
  • We will add a new property to include entity_types, as it is not part of the kuery.
  • The timerange property will be removed since the search currently does not have a time filter.

This changes are now reflected on the issue description.