Skip to content
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

improve usability of total statistic in graph legends #242

Open
brharrington opened this issue Oct 24, 2015 · 3 comments
Open

improve usability of total statistic in graph legends #242

brharrington opened this issue Oct 24, 2015 · 3 comments

Comments

@brharrington
Copy link
Contributor

The total statistic doesn't seem to be particularly useful and worse most users seem to interpret it incorrectly. Currently, the total statistic is the sum of all datapoints shown for a given time series on the graph. Most users I have talked with assume it is the total number of events (assuming a counter) that occurred within the time frame of the chart.

Options:

  1. Just remove total. This was done several years ago and it got re-added when someone complained. Though it is quite likely their interpretation of the value was wrong.
  2. Change the value reported with total to try and match the more common user interpretation. This is possible for simple expressions using sum over counters as the aggregate. With something like max or avg it would be an estimate of the total number for a single item. However, if combined with non-counter data it wouldn't be meaningful. Neither make much sense with gauges.
  3. Add support for some sort of legend stat control similar to the current :legend operator. It would be used to specify the stats format. We can then remote total by default and allow users to specify a total variant for counters. This could also help with requests to have some stats, but reduce the amount of vertical space taken up with the statistics. Complications:
    • Different statistics per line can make the legend rendering more complex. However it is likely needed for correctness as things like total don't really make sense for gauges.
    • It would be up to the user to make sure it made sense for the input line. One advantage of Option 2 if it could be done cleanly, is it would be more automatic based on the input data.
@brharrington brharrington added this to the 1.5.0 milestone Oct 24, 2015
@brharrington brharrington modified the milestones: 1.6.0, 1.5.0 Feb 27, 2016
@svachalek
Copy link
Contributor

Option 3 seems good. The default could be based on the statistic tag, or the UI could interpret the statistic tag to set a reasonable value. For consistent formatting, possibly it could use "N/A" for invalid lines instead of dropping the entry.

@brharrington
Copy link
Contributor Author

@svachalek any preferences for what the format specification would look like?

@svachalek
Copy link
Contributor

Sorry, didn't see the question earlier. Probably for readability, a list like

(,max,avg,count,),:stats

would work best.

@brharrington brharrington modified the milestones: 1.6.0, 1.7.0 Jun 21, 2018
@brharrington brharrington modified the milestones: 1.7.0, 1.8.0 Mar 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants