Hi,
Some plugin results have discrete values for which it makes no sens to compute an average (no way a host had 1,725 cron process running any time…) I understand it is due to the aggregation RRD is doing. But averaging, while the default aggregation method used for RRD isn’t the only one that exists. There are also “min” and “max” (and another fourth I don’t remember I think).
What about the possibility to use them (“min” obviously in the case of a number of process(es) check) optionally?
Declined
RRD
+18Thanks for this. We intend on offering an alternative -true- TSDB which will have the ability to store all datapoints and also return aggregates.
Implementing your proposed solution on RRD would actually impact both the load on RRD and the storage required which is not something we can consider.
+18New→Declined
Hi,
Thanks for your reply.
I noticed you put dashes around “true”, and you’re right to do so. Because RRD definitively is a true TSDB. What of the oldest and still maintained though.
I don’t get your two points.
About load, I didn’t mean storing both AVG and MAX or MIN, but having the possibility to choose between the three. So I really don’t understand how it could impact load or storage (I’d even say MAX/MIN means less computing than AVG, but it is probably negligible anyway).
Are you aiming at a particular TSDB already? One that would « store all datapoints » ? Won’t it be more storage then anyway? What are the (roughly) expected saving on load compared to RRD? What are the expected enhancements from a final user point of view, or from a developer point of view?
I agree newer TSDBs have advantages, but stable oldies like RRD have too.
Anyway I’m also aware that, while fundamentally basic it can be (that’s a native functionality of RRD) it’s not an easy thing to implement considering the existing code base. And as you relevantly pointed during our last talk: this is free software and anybody is free of working on this on his own…
So I can understand your decision, but’s the justifications you give, I don’t, really. But maybe that’s me.
Have a nice day.
+18What I meant is RRD is reaching its limits with the current use Centreon makes of it and we are careful with new developments arount it. Whilst I generally agree with your idea, the solution to it will not be to use other operators than avg with RRD.
As far as where we stand with that, we have chosen the technology and started implementing support for it. Some example criteria we evaluated: pure performance, horizontal scalability, deployment model, support for remote storage, aggregation options etc.
>Centreon makes of it and we are careful with new developments arount it.
That I can understand. And I prefer stability over functionality, so I can’t disagree on this.
>the solution to it will not be to use other operators than avg with RRD
I didn’t pretend it can be a solution for any other RRD issues but just the one I cited. You’re telling me it could not even be done technically? I don’t see how but you know better for sure. I suppose it relates to how Centreon use RRD or maybe PHP, but it doesn’t matter anyway. Thx for your time.
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.