You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Requirement - what kind of business use case are you trying to solve?
Reduce confusion in per-second request/error rates in graphs.
Problem - what in Jaeger blocks you from solving the requirement?
The rate duration defaults to 1 hr which can result in quite low rates (e.g. 0.013 requests/sec), which can be confusing.
Proposal - what do you suggest to solve the problem or improve the existing situation?
Online examples of prometheus queries using rate commonly quote a window of 5 mins. As such, changing the ratePer to a smaller window, say, 10m for starters might be a reasonable compromise. It still results in quite a low rate (e.g. 0.08), but it should reach a more expected rate sooner.
The other alternative is to use irate in jaeger-query, however, this only considers the last 2 points in the rate window, and all other information is lost. irate is ideal for a short demo, but in a production environment, I expect rate to be the preferred function.
We can later iterate on whether if this would be useful as a configurable parameter (either through the UI or json config), if not already possible.
The text was updated successfully, but these errors were encountered:
Requirement - what kind of business use case are you trying to solve?
Reduce confusion in per-second request/error rates in graphs.
Problem - what in Jaeger blocks you from solving the requirement?
The rate duration defaults to
1 hr
which can result in quite low rates (e.g. 0.013 requests/sec), which can be confusing.Proposal - what do you suggest to solve the problem or improve the existing situation?
Online examples of prometheus queries using
rate
commonly quote a window of 5 mins. As such, changing theratePer
to a smaller window, say,10m
for starters might be a reasonable compromise. It still results in quite a low rate (e.g. 0.08), but it should reach a more expected rate sooner.The other alternative is to use
irate
in jaeger-query, however, this only considers the last 2 points in the rate window, and all other information is lost.irate
is ideal for a short demo, but in a production environment, I expectrate
to be the preferred function.We can later iterate on whether if this would be useful as a configurable parameter (either through the UI or json config), if not already possible.
The text was updated successfully, but these errors were encountered: