Carl,
thanks for your advice!
> The easy way is to use LIMIT values when producing the graphs to
> cause impossible values to become "unknown" and to not get graphed;
So, if I got you correctly, it's not only the lower limit ("0") but also
the upper limit that has to be submitted by performance data to "force"
values above this limit being updated as "unknown"!?
What does it mean "not to get graphed"? will there be an(y)
interpolation our just nothing displayed?
Thanks, Philipp
On 20.08.2013 13:10, Carl R. Friend wrote:
> On Tue, 20 Aug 2013, Philipp Herz - Profihost AG wrote:
>
>> But I noticed some "strange" behavior when I shutdown a machine. As
>> Icinga can not get any values from remote nrpe daemon while remote
>> system is down, it's status changed from OK to UNKNOWN (without
>> perfdata).
>>
>> Up to the point when the remote system is powered on again the graph
>> is ok.
>>
>> Now, when Icinga is able get "new" performance data from remote system,
>> it draws huge peaks of values the hardware does not even support.
>
> This is an intrinsic problem with RRDtool and the way it deals
> with counters -- more specifically the way it deals with counters
> when they "wrap" (i.e. normally cycle back to zero after overflowing).
> In a perfect world, one can deduce a correct *rate* from a mono-
> tonically-increasing counter even if that counter occasionally wraps
> back to zero by taking the last known value (before the wrap) and the
> new one (after the wrap) and summing the before-wrap and wrap-point
> delta and the new value. This yields no problems in the data.
>
> However, we don't live in a perfect world, and occasionally counters
> get forcefully reset to zero when they otherwise would not have. This
> causes RRD to mistakenly apply the "wrap" logic and produce erroneous
> results.
>
> Tobi goes to some length to outline coping strategies for these
> contingencies in the RRD documentation, including laying out what
> values are acceptable when data are written into the RRD and ways
> to remove obviously errant data from graphs when producing them, but
> those facilities may not be available in the pnp4nagios (and other)
> tools in common use.
>
> In short, this is not an Icinga problem, it's an RRD problem and,
> depending on the actual tool and implementation you're working with
> you may have a large hill to climb to "solve" your issue. The easy
> way is to use LIMIT values when producing the graphs to cause impossible
> values to become "unknown" and to not get graphed; the trick is picking
> the "right" value that'll work for everything.
>
> Cheers!
>
> +------------------------------------------------+---------------------+
> | Carl Richard Friend (UNIX Sysadmin) | West Boylston |
> | Minicomputer Collector / Enthusiast | Massachusetts, USA |
> | mailto:crfri...@rcn.com +---------------------+
> | http://users.rcn.com/crfriend/museum | ICBM: 42:22N 71:47W |
> +------------------------------------------------+---------------------+
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
icinga-users mailing list
icinga-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/icinga-users
