-
Notifications
You must be signed in to change notification settings - Fork 93
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
a way to graph as a percentage of a total #121
Comments
so
? |
Yeah, that sounds about right. |
oh i forgot that it would be converted to a percentage, is that what you meant with 'about right' |
Do you think you could give a basic idea of what to do to make a pull request for this? It looks to me like interpreting the user's "percent by" query would be in graph_explorer/test/test_query.py and the building of a graphite render/ parameter is in graphs.build_from_targets . ( build_from_targets doesn't seem to have a lot of coverage, though). To be clear, I would eventually like to end up with something like:
Can you think of anything else I'd need to worry about? |
this thing is going to be trickier than straight up sum by / avg by though. with those we just fetch all matching metrics, and then bundle them together in sum() and avg() calls (and as we add them to a sum or avg, we remove the entry from the list of to-be-independently-rendered-metrics, because the list of to-be-independently-rendered-metrics will contain the sum/avg that contains it already) in this case there's 2 options: for a given
A) we add to the list of to-be-independently-rendered-metrics 3 things: B) we add to the list of to-be-independently-rendered-metrics only specifically asked for things B may sound like an overcomplication, but ultimately we should have a way of expressing this, because there will be use cases where you don't want to see the percentage for every possible value of a tag. the other thing is that you can't just do the logic i described for avg/sum by, because every metric will appear multiple times (not just either as an independently rendered metric or as part of an aggregate) but if you're decent at python this shouldn't be an issue, you can just keep track of all the values, so you know how the sum looks like , and then use that in all the aspercent's you want to render. anyway depending on how ambitious you are, i would start with the simplest case, A. |
That's really helpful information. Thanks. I'm not sure I understand the use case for The derivatives are in my example because collectd cpu metrics are counters of total scheduling units so it put it in by habit only. In any case I will let you know how I get on by the end of the week. |
but anyway, i wouldn't worry too much about that now. |
That makes sense. It seems to be very useful to be able to graph things in the context of other metrics which you don't want to show so I'll look at that as well, but I expect I'll just do the original idea until I find some concrete use cases to test against. |
From a user point of view, I think I would expect that: I understand that may technically be wrong though and maybe I don't fully grasp the syntax of the query language. |
your first query, agreed. it just means we have to support the gathering of extra metrics as i described in my previous comment. |
Quite often we want to display a graph in the context of a total. e.g. percentage of 404 responses out of all responses.
A stacked graph achieves this visually but there are situations where this still does not help:
Take collectd's cpu usage. It reports jiffies as a counter (we had to tweak the stock plugin to get this to work at all). The problem here is that jiffies are not necessarily a constant number per second. If we stack all of those counters together, we get spikes above and below the natural maximum line.
So what I propose is a function 'percentage of' or 'percent by' that would work similarly to 'sum by'.
Then we could query for e.g: 'stack collectd_plugin=cpu sum by core group by server percent by type'
For each graph the values would be represented as a sum of the total of all types, for each group.
The text was updated successfully, but these errors were encountered: