[ECO][Inventory v2] APM changes

[cauemarcondes]

We're moving away from materialized entities, meaning we won't have the entity-*-latest index anymore. Due to this, these changes need to be made:

Warning

We should NOT call the EEM rest APIs directly, we should use the services exposed on the EEM client plugin.

• APM fetches the datastream_type from a given service name on the entities latest index. We'll need to update it to call the new API instead:
  API: GET /internal/apm/entities/services/{serviceName}/summary

POST kbn:/internal/entities/v2/_search
{
    "type": "service",
    "limit": 1,
    "metadata_fields": ["data_stream.type"],
    "filters": ["service.name == \"service-9\"", "service.environment == \"Synthtrace: other_bucket_group development\""]
}

• Delete GET /internal/apm/entities/services.
• /link-to/entity/{serviceName} route:
  This link is used to link service names shown on logs explorer and discover, It also uses the summary API GET /internal/apm/entities/services/{serviceName}/summary, and needs to be tested.

[elasticmachine]

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

[cauemarcondes]

blocked by https://github.com/elastic/elastic-entity-model/issues/213

[cauemarcondes]

I created a draft PR in case the person making these changes wants to continue what I've done.

[jennypavlova]

I was comparing the results of entityManagerClient.v2.searchEntities and getServiceEntitySummary I see some differences:

Before we were using the latestEntityServices query and now I am trying to replace it with entityManagerClient.v2.searchEntities
The agentName and environments are not present in the response:

getServiceEntitySummary	entityManagerClient.v2.searchEntities
{ "serviceName": "synth-dotnet", "agentName": "rum-js", "lastSeenTimestamp": "2024-12-12T18:23:14.753Z", "dataStreamTypes": [ "traces", "logs" ], "environments": [ [ "Synthtrace: logs_traces_hosts" ] }	[ { "data_stream.type": [ "logs", "traces" ], "entity.last_seen_timestamp": "2024-12-12T18:24:20.753Z", "service.name": "synth-dotnet", "entity.type": "built_in_services_from_ecs_data", "entity.id": "synth-dotnet", "entity.display_name": "synth-dotnet"" } ]

So regarding the serviceEntitySummary missing fields usage: the agent name is used here and I couldn't find environments usage so far.

cc: @miltonhultgren @klacabane Do you know how to get the agent name there and if we plan to add it in the response?

I did some updates in #202497 so both responses are now logged and present

[klacabane]

@jennypavlova how does the searchEntities call looks like ? generally you need to explicitly ask for metadata fields in v2 APIs, so in that case it should be searchEntities({ ..., metadata_fields: ['data_stream.type', 'agent.name', 'service.environment'], ... }).

If you want some metadata fields to always be included when you search for entities, you'd need to set them on the source definition (here for services) but you'd have to consider the tradeoff (ie always aggregating a given field even if not used vs only aggregating when needed). If a field is required in all the places a given entity type is manipulated then it may be a good call to set it on the definition source

[klacabane]

One additional note on metadata fields is that you may see different results between v1 and v2 as v1 used a terms aggregation to get n unique values but v2 uses a top aggregation that does not dedupe. For a given time range there's a good chance you won't get all the unique values for a field but only the top result sorted alphabetically. I'm looking into ways to improve this (see #204137)

[jennypavlova]

generally you need to explicitly ask for metadata fields in v2 APIs, so in that case it should be searchEntities({ ..., metadata_fields: ['data_stream.type', 'agent.name', 'service.environment'], ... }).

@klacabane Good point, this works for the use case here!

If you want some metadata fields to always be included when you search for entities, you'd need to set them on the source definition (here for services) but you'd have to consider the tradeoff (ie always aggregating a given field even if not used vs only aggregating when needed).

I don't think we should add it for now - I am not sure if it will be used everywhere so I think we can add it once we confirm that.

One additional note on metadata fields is that you may see different results between v1 and v2 as v1 used a terms aggregation to get n unique values but v2 uses a top aggregation that does not dedupe. For a given time range there's a good chance you won't get all the unique values for a field but only the top result sorted alphabetically. I'm looking into ways to improve this

Thanks! Agent name is a string so I guess it should be fine there (it could be also an array from what I saw) and for the data stream type that would be useful :)

[jennypavlova]

@rmyz found an issue with duplicate values in the metadata and enviroment and I checked and it's related to the EEM response - I used synthtrace to generate data and I got this response:

I handled that on our side to allow only unique values but it might be something you should also take a look, @miltonhultgren , @klacabane

[klacabane]

@jennypavlova this is caused by the TOP behavior we use on metadata aggregation which does not dedup values and eem only dedup values when merging entities from different sources. we've discussed this and TOP does not satisfy our requirements so we'll revert to VALUES which does the dedup

[jennypavlova]

Thank you for checking that! I already added a logic to pick only unique values so it's not a blocker for the PR

[klacabane]

@jennypavlova fyi #204460 has been merged so the dedup logic is not needed anymore