[APM] Service groups - dynamic query refresh#140406
Conversation
c55a431 to
e3cbff6
Compare
eef2aa5 to
c95ec06
Compare
|
Pinging @elastic/apm-ui (Team:APM) |
cauemarcondes
left a comment
There was a problem hiding this comment.
Some comments on the server side
x-pack/plugins/apm/public/components/app/service_groups/service_groups_list/index.tsx
Outdated
Show resolved
Hide resolved
💚 Build Succeeded
Metrics [docs]Async chunks
Saved Objects .kibana field count
History
To update your PR or re-run it, just comment with: cc @ogupte |
| const { | ||
| field: { | ||
| spec: { name: fieldName }, | ||
| }, | ||
| } = querySuggestion; |
There was a problem hiding this comment.
nit: this is 100% personal preference but my brain always struggle a bit with nested destructurings. Feel free to leave as-is if you prefer that.
| const { | |
| field: { | |
| spec: { name: fieldName }, | |
| }, | |
| } = querySuggestion; | |
| const fieldName = querySuggestion.field.spec.name; |
| const { start, end } = useMemo( | ||
| () => | ||
| getDateRange({ | ||
| rangeFrom: 'now-24h', | ||
| rangeTo: 'now', | ||
| }), | ||
| [] | ||
| ); |
There was a problem hiding this comment.
This is on the service group overview page (aka the page listing all the service groups), right?
@gbamparop and I talked about that we didn't currently have a timepicker, and we didn't see any need to add any. It also means that the lookback time-period for calculating the service counts is hardcoded to 24 hours.
I think this is a fine compromise between simplicity and functionality. But we should remember to flag this to product (and possible docs to document it).
There was a problem hiding this comment.
Correct, this is on the service group overview page.
| async ({ | ||
| id, | ||
| kuery, | ||
| }): Promise<{ id: string; servicesCount: number }> => { |
There was a problem hiding this comment.
Is this type annotation necessary ?
There was a problem hiding this comment.
It seems that it isn't, we can remove it
| }: { | ||
| setup: Setup; | ||
| kuery: string; | ||
| maxNumberOfServices: number; |
There was a problem hiding this comment.
Is maxNumberOfServices unused here?
There was a problem hiding this comment.
It is unused, we can add a size (service inventory and service map already have max size specified).
| const MODAL_HEADER_HEIGHT = 122; | ||
| const MODAL_FOOTER_HEIGHT = 80; | ||
|
|
||
| const suggestedFieldsWhitelist = [ |
There was a problem hiding this comment.
Can you use allowlist here?
| t.partial({ | ||
| serviceGroupId: t.string, | ||
| }), | ||
| t.undefined, |
There was a problem hiding this comment.
Do you actually want t.union([ t.type(), t.partial() ]) here?
| ...(serviceGroup?.serviceNames ?? []), | ||
| ]; | ||
| const serviceNames = compact([serviceName]); | ||
|
|
There was a problem hiding this comment.
What happens if this is an empty array? Does it return a service map for all services or no service map at all?
There was a problem hiding this comment.
It returns a service map for all services. I think that was there before to handle service-specific service maps
| end, | ||
| maxNumberOfServices, | ||
| serviceGroup, | ||
| }); |
There was a problem hiding this comment.
Why do we pass both serviceNames and serviceGroup?
There was a problem hiding this comment.
Service name is used when we are in the context of a service. We could rename it to serviceName. Service group is passed to apply a kuery filter for the group
| color: string; | ||
| } | ||
|
|
||
| const migrateApmServiceGroups850: SavedObjectMigrationFn< |
There was a problem hiding this comment.
Is that a convention to put the version in the end like that? Perhaps we can make it a little clearer:
| const migrateApmServiceGroups850: SavedObjectMigrationFn< | |
| const migrateApmServiceGroups_v8_5_0: SavedObjectMigrationFn< |
There was a problem hiding this comment.
Not sure if this is a convention but It's aligned with https://docs.elastic.dev/kibana-dev-docs/tutorials/saved-objects#writing-migrations
| } | ||
|
|
||
| const migrateApmServiceGroups850: SavedObjectMigrationFn< | ||
| ApmServiceGroupsPre850, |
There was a problem hiding this comment.
| ApmServiceGroupsPre850, | |
| ApmServiceGroupsPre_v8_5_0, |
There was a problem hiding this comment.
I don't think we'll hit v85.0 anytime soon but by using separators we at least don't run the risk of confusion in the future :D
| }), | ||
| serviceGroup | ||
| ? getServiceNamesFromServiceGroup(serviceGroup) | ||
| ? getServiceNamesFromServiceGroup({ |
There was a problem hiding this comment.
This isn't useful anymore. The intent of this function is to quickly get a list of sorted and filtered services, but as this now aggregates over all the data, including raw transactions and spans, it is likely to be slower than the request that gets the actual statistics. We should remove it, I think.
There was a problem hiding this comment.
That's true, we wouldn't get the benefit of terms enum. Removing it though could result in preloaded service names being removed once we get the "final" response right?
There was a problem hiding this comment.
We probably shouldn't preload at all if a service group is selected. So, simply returning an empty array here might suffice. But I don't know how it specifically works. terms_enum doesn't make sense if a service group is selected, we shouldn't use it at all in that case (I think that's already happening today).
| id, | ||
| kuery, | ||
| }): Promise<{ id: string; servicesCount: number }> => { | ||
| const servicesCount = await getServicesCounts({ |
There was a problem hiding this comment.
have you compared performance of a single request w/ filter aggregations vs multiple requests?
There was a problem hiding this comment.
Good point, I haven't checked filter aggregations, @ogupte have you? If not, we could have a look
There was a problem hiding this comment.
yeah we should probably fix this since it can get out of hand with many service groups.
There was a problem hiding this comment.
Some findings on this comparison in a related issue (#141242): #141242 (comment)
x-pack/plugins/apm/server/routes/services/get_services/get_sorted_and_filtered_services.tsto work with dynamic refreshThis is a draft PR and all the changes should be revisited.
observability:apmServiceGroupMaxNumberOfServicesis sometimes used outside of the context of service groups while in other queries max service count is hardcoded. We could rename the setting and use it in all service queries.Closes #133112