Am 29.01.2015 um 23:04 schrieb Will Tatam:
On 29/01/15 20:59, Michael Friedrich wrote:
Am 29.01.2015 um 19:54 schrieb Will Tatam:
Hi Mark
I failed to get the whitelist / blacklist stuff working and it would
be a waste of network bandwidth too to send data only to drop, so I
have quickly hacked a build that only sends what I want
https://github.com/red61wjt/icinga2/commit/892217b17241354bacc0c79deceff642de122110
Anyone fancy tuning this into a proper config value ?
We already thought about it, but our decision is to keep these values
as they are extremly useful for reporting. Additional config options
are not necessary, just follow Markus' approach.
https://dev.icinga.org/issues/6390
Regards,
Michael
Hi Michael
They are very useful for people investigating the performance of
icinga, but I would argue that this is the minority of users. e.g If
you want to record the ping times to a host, you care about the ping
time, not any of the other values. For example, you probably don't
change the max_check_attempts value much, if ever, yet you would be
saving this value once per minute. Yes you can configure graphite to
only store these "internal" values for less times than your real
values requires further configuration, or as mentioned, if you want to
discard a value totally you can blacklist (in theory) but this is a
total waste of system resources to fire more data over the network
than required.
I have changed my patch to use a boolean, though I don't know enough C
or icinca2's config parsing to read from the config file, so it's a
compile time value currently. I'm sure someone could do this very
quickly and then users have the choice
https://github.com/red61wjt/icinga2/commit/48cb2ee718e1d45b0bf94a8389e1ec63ae5dda02
Don't get it the wrong way, but I don't think that everything needs to
be configurable. There should a certain amount of features with a fixed
set, and nothing but data written.
We did it wrong with 1.x (look at the cgi.cfg mess for example), and I
don't think we will start again adding more and more config options for
choices 99% of the users don't really understand. Once there is one
choice for "all or nothing", the next feature request starts with "i
want a filter for option A, B and C, but not D and E". That's sometimes
hard when developers say no, but generally speaking it's better for the
project's quality afterall.
In the end, it really doesn't hurt putting a graphite filter into the
carbon cache configuration. Except network traffic, but hey - that
shouldn't be an issue in times where giga bits of data sent through the net.
Such discussions always remind me of this nice picture I found recently:
https://twitter.com/Jack_Ashman/status/550961942358425600
Regards,
Michael
Will
_______________________________________________
icinga-users mailing list
[email protected]
https://lists.icinga.org/mailman/listinfo/icinga-users
--
https://twitter.com/dnsmichi
https://github.com/dnsmichi
http://www.legendiary.at
_______________________________________________
icinga-users mailing list
[email protected]
https://lists.icinga.org/mailman/listinfo/icinga-users
