-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[APM] [experimental] Service metrics on inventory page #140868
Conversation
Documentation preview: |
…-ref HEAD~1..HEAD --fix'
d39f738
to
726e43d
Compare
6f2d526
to
da16bc3
Compare
…into 138527-service-metrics
Pinging @elastic/apm-ui (Team:APM) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some small suggestions
x-pack/plugins/apm/server/lib/helpers/get_bucket_size_for_aggregated_transactions/index.ts
Show resolved
Hide resolved
x-pack/plugins/apm/server/routes/services/get_services_detailed_statistics/index.ts
Outdated
Show resolved
Hide resolved
…-ref HEAD~1..HEAD --fix'
…into 138527-service-metrics
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've left some comments, some more important than others, but generally don't wait on my approval as I'm under the weather atm and just wanted to have a quick look. Thanks for doing this!
x-pack/plugins/apm/server/lib/helpers/get_aggregated_metrics.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/apm/server/lib/helpers/get_aggregated_metrics.ts
Outdated
Show resolved
Hide resolved
@@ -12,12 +12,17 @@ export function getBucketSizeForAggregatedTransactions({ | |||
end, | |||
numBuckets = 50, | |||
searchAggregatedTransactions, | |||
searchAggregatedServiceMetrics, | |||
}: { | |||
start: number; | |||
end: number; | |||
numBuckets?: number; | |||
searchAggregatedTransactions?: boolean; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we collapse this into one (maybe required) prop?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Caue left a comment on this helper as well. #140868 (comment)
We could discuss and find what's the best in a follow up PR/ticket
.../plugins/apm/server/routes/services/get_services/get_service_aggregated_transaction_stats.ts
Show resolved
Hide resolved
@@ -34,6 +36,7 @@ export async function getServicesItems({ | |||
kuery: string; | |||
setup: ServicesItemsSetup; | |||
searchAggregatedTransactions: boolean; | |||
searchAggregatedServiceMetrics: boolean; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer one option here too. Not a dealbreaker, but I think it's better to make the decision (about what to search) in one place and then pass it on downwards.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dgieselaar I think I agree. Are you suggesting to combine searchAggregatedTransactions
and searchAggregatedServiceMetrics
into a single option? In that case I suggest we deprecate searchAggregatedTransactions
and remove searchAggregatedServiceMetrics
, and create a new one like:
transactionSource: 'auto' | 'service-metrics' | 'transaction-metrics' | 'transactions'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The auto
in which order should determine the source?
first 'service-metrics'
then transaction-metrics
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that order. But we should only use service-metrics
where it makes sense. Right now only on the inventory page.
...s/get_services_detailed_statistics/get_service_aggregated_transaction_detailed_statistics.ts
Outdated
Show resolved
Hide resolved
...s/get_services_detailed_statistics/get_service_aggregated_transaction_detailed_statistics.ts
Show resolved
Hide resolved
x-pack/plugins/apm/server/routes/services/get_services_detailed_statistics/index.ts
Show resolved
Hide resolved
…-ref HEAD~1..HEAD --fix'
…into 138527-service-metrics
47b8e05
to
e74ae86
Compare
This to ensure proper bucket counts as discovered on elastic/kibana#140868
💚 Build Succeeded
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Just some nits that don't block the merge.
return [ | ||
{ | ||
term: { | ||
[METRICSET_NAME]: 'service', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like we could have an enum for the possible metricsset.name values.
kuery: string; | ||
}): Promise<{ | ||
searchAggregatedTransactions: boolean; | ||
searchAggregatedServiceMetrics: boolean; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have to add Metrics
at the end of the name? We don't do it for transactions.
Maybe to keep it consistent?
searchAggregatedServiceMetrics: boolean; | |
searchAggregatedServices: boolean; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also noticed this inconsistency but I think we should keep "Metrics" and get rid of "Aggregated":
searchAggregatedServiceMetrics: boolean; | |
searchTransactionsMetrics: boolean; | |
searchServiceMetrics: boolean; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let me address the additional feedback in a follow up PR.
Thank you all for the review!
...commonProps, | ||
offset, | ||
}) | ||
: Promise.resolve({}), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think you need Promise.resolve here. isn't that enough?
: Promise.resolve({}), | |
: {}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TypeScript will complain I think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I can't reproduce this, but I've seen issues with TypeScript no longer being able to infer the return type. Maybe it was fixed in a recent version. Runtime a plain value should be fine in any case.
failedTransactions: number | null; | ||
successfulTransactions: number | null; | ||
}) { | ||
if (isNull(failedTransactions) || failedTransactions === 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is up to you, just a preference:
if (isNull(failedTransactions) || failedTransactions === 0) { | |
if (!failedTransactions) { |
|
||
const { apmEventClient, config } = setup; | ||
const { searchAggregatedTransactions, searchAggregatedServiceMetrics } = | ||
await getServiceInventorySearchSource({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't environment be here too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking closer to this!
I think, if we want to be 100% accurate environment should be there, otherwise we ask if there is ANY document that matches the metricset.name: service
and it might no be for the given environment.
but I'm wondering how is that different from getSearchAggregatedTransactions
, why we don't include it as a filter for the aggregated transactions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it should be there too. Not sure why it isn't, it may have been on setup
before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can create a ticket for it unless you want to
@@ -46,12 +46,15 @@ export const PROCESSOR_EVENT = 'processor.event'; | |||
|
|||
export const TRANSACTION_DURATION = 'transaction.duration.us'; | |||
export const TRANSACTION_DURATION_HISTOGRAM = 'transaction.duration.histogram'; | |||
export const TRANSACTION_DURATION_SUMMARY = 'transaction.duration.summary'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
iirc we talked about splitting this file into several files, with one file per data source (eg. APM vs infra vs logs) we might also want to group the fields by doc type (transactions vs transaction metrics vs service metrics)
closes: #138527
By default the settingxpack.apm.searchAggregatedServiceMetrics
is set tofalse
.Add kibana advanced setting to configure - #141147
getSearchAggregatedServiceMetrics()
method which will determine, based on the date range and configuration setting whether aggregated service metrics should be used.getServiceAggregatedTransactionDetailedStatistics()
query for the service metricsgetServiceAggregatedTransactionStats
query for the service metricsCreated separated queries for the fetching service metrics data cause the data model is quite different from aggregated transaction document (transaction.duration.histogram)
service metrics document example
To try this out, you'll need to enable aggregation in APM Server. See elastic/apm-server#8607
In order to test it locally you need to run the following:
apm-server.yml
a.
./apm-server -c apm-server.yml -e -d "*"
node scripts/synthtrace packages/elastic-apm-synthtrace/src/scenarios/high_throughput.ts --local --maxDocs 100 --apm http://localhost:8200/ --username admin --skipPackageInstall --clean
TODO: