[mrtg] machines uitzetten, stats naar nul ?

[AlterEgo]

Duffe titel, maar beter weet ik het niet te verwoorden.

Ik monitor een aantal machines via snmps en laat sexy grafieken maken met mrtg. Maar een aantal van die machines gaan ook wel eens uit . En de grafieken in mrtg geven dan gedurende de periode dat de machine uit staat de laatse echt gemeten waarde weer.
En dat is eigenlijk niet mooi, en ook niet juist.

Nu kan ik wel een dramatisch stop-script verzinnen dat alle uitgelezen waarden naar "nul" zet alvorens af te sluiten, maar dat zal geen schoonheidsprijs verdienen.

Er is vast een betere oplossing

[Bor]

Yep, dat staat zelfs in de mrtg faq. Ik zal het voor je opzoeken.

Edit: ah hier dus:

Volgende keer svp eerst zelf zoeken.

My graphs show a flat line during an outage. Why ?

Well, the short answer is that when an SNMP query goes out and a response doesn't come back, MRTG has to assume something to put in the graph, and by default it assumes that the last answer we got back is probably closer to the truth than zero. This assumption is not perfect (as you have noticed). It's a trade-off that happens to fail during a total outage.

If this is an unacceptable trade-off, use the unknaszero option.

You may want to know what you're trading off, so in the spirit of trade-offs, here's the long answer:

The problem is that MRTG doesn't know *why* the data didn't come back, all it knows is that it didn't come back. It has to do something, and it assumes it's a stray lost packet rather than an outage.

Why don't we always assume the circuit is down and use zero, which will (we think) be more nearly right? Well, it turns out that you may be taking advantage of MRTG's ``assume last'' behaviour without being aware of it.

MRTG uses SNMP (Simple Network Management Protocol) to collect data, and SNMP uses UDP (User Datagram Protocol) to ship packets around. UDP is connectionless (not guaranteed) unlike TCP where packets are tracked and acknowledged and, if needed, retransmitted. UDP just throws packets at the network and hopes they arrive. Sometimes they don't.

One likely cause of lost SNMP data is congestion; another is busy routers. Other possibilities include transient telecommunications problems, router buffer overflows (which may or may not be congestion-related), ``dirty lines'' (links with high error rates), and acts of God. These things happen all the time; we just don't notice because many interactive services are TCP-based and the lost packets get retransmitted automatically.

In the above cases where some SNMP packets are lost but traffic is flowing, assuming zero is the wrong thing to do - you end up with a graph that looks like it's missing teeth whenever the link fills up. MRTG interpolates the lost data to produce a smoother graph which is more accurate in cases of intermittent packet loss. But with V2.8.4 and above, you can use the ``unknaszero'' option to produce whichever graph is best under the conditions typical for your network.

[ Voor 95% gewijzigd door Bor op 26-01-2005 21:33 ]

[CyBeR]

unknaszero in je Options zetten.

[AlterEgo]

Dankjewel Bor_de_Wollef,

ik zal direct toegeven dat ik dit gemakkelijk gevonden zou kunnen hebben, als ik de juiste zoekwoorden zou hebben geweten (en ik heb dit MRTG FAQ afgelopen week ook nog gelezen, en het "probleem" is me pas een paar dagen geleden opgevallen, zonder verdere herinnering dat ik dit gelezen heb )

[Bor]

Geen probleem joh, daar zijn we voor. Gelukkig heb je nu de complete uitleg erbij