It seems that SELECT MEAN(value) FROM sipMessages WHERE time > now() -7d GROUP BY time(1h), tag_message_type
would return what you want. That will give the average of the "value" field per hour, per message_type, but across all nodes. If that isn't what you want, can you clarify why not? On Fri, Jun 24, 2016 at 2:57 AM, <[email protected]> wrote: > I've hit an issue that I think, sadly, is going to prevent us from > deploying InfluxDB. The following is an example of this issue, but in > reality it manifests in different ways in many of our use cases. > > I have a set of nodes each reporting the rate at which differnet SIP > messages are being received (in terms of messages per s) > > timestamp | tag_node | tag_message_type | value > --------------------------------------------------- > | node1 | INVITE | 1728 > | node1 | BYE | 1051 > | node2 | INVITE | 1521 > | node2 | BYE | 1241 > > Each node reports writes these stats to InfluxDB roughly every 5s. > > I want to draw charts showing the total rate of different types of SIP > messages being processed across my deployment, split by message_type. > > Ideally I would do this like so: > > SELECT sum("value") FROM "sipMessages" WHERE WHERE time > now() - 7d > GROUP BY time(1h), "tag_message_type" > > The problem here is that this sums across different values of node, but > also sums multiple points within each series. So the number I get returned > is ~720 times higher than it should be. If I knew that there were always > going to be exactly 720 measurements in each time interval I could divide > by 720, but this 720 is only an approximation. [it is also the case that > using Grafana to draw the graphs this "1h" period changes automatically > based on the period that I'm graphing over] > > What I really need to do is to run an average aggregation within each > series over each GROUP BY time period (so that for each node / message_type > combination I have one data point per time period), and then sum the > results of those aggregations across the different series. > > I don't believe this is possibe though, and I can't see any way to work > around it? > > What I don't understand is why this isn't a critical issue for lots of > users as this seems like a very standard use case. Is there a reason that > other users are able to avoid this issue? > > Would adding this capability (to do per series aggregation within "GROUP > BY time" intervals) be technically difficult? > > -- > Remember to include the InfluxDB version number with all issue reports > --- > You received this message because you are subscribed to the Google Groups > "InfluxDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/influxdb. > To view this discussion on the web visit > https://groups.google.com/d/msgid/influxdb/c7be9920-759c-49e5-a23f-a4800c18b979%40googlegroups.com > . > For more options, visit https://groups.google.com/d/optout. > -- Sean Beckett Director of Support and Professional Services InfluxDB -- Remember to include the InfluxDB version number with all issue reports --- You received this message because you are subscribed to the Google Groups "InfluxDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/influxdb. To view this discussion on the web visit https://groups.google.com/d/msgid/influxdb/CALGqCvPvaBsKuruQ5j1mXtftTo70R7LjYm%2BTNq43QBwCRtzwZA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
