[mrtg] Graphing Uptime

Mon Oct 1 14:24:26 CEST 2018

Is there a way to ever have the y axis in days *and* generate a graph with the y axis in fractional days?

This does not work:

Target[Foo-uptime]: OID&OID:community at host/8640000

Putting division here is defined in the documentation as an operation that converts to an integer, so this gives you whole numbers of days. After a router reboot, the graph will show as 0.0 for 12 hours I guess, after which I suppose you get 1.0 days prematurely. This results in a graph with misleading figures and cannot report multiple reboots reliably.

Nor does this work (setting factor as 1/8640000):

Factor[Foo-uptime]=0.000000115740740741

Factor only applies to the figures shown below the graph on the HTML page. These figures are now days as before, but the y axis is now in hundreds of kilodays or even megadays, as the factor is not applied to the graph!

It seems that any attempt to get the y axis into days will involve losing precision lower than 0.5 days!

I am guessing that the best you can do, is this:

Target[Foo-uptime]: OID&OID:community at host/360000
Factor[Foo-uptime]: 0.0416667
YLegend[Foo-uptime]: Uptime (hours)
LegendI[Foo-uptime]: Uptime in days
ShortLegend[Foo-uptime]: days

That is, divide timeticks by 360000 to get hours (in whole numbers, for the y axis) and then multiply by 1/24 to get the figures below the graph in days.

It does mean having two units in use at once, but so far as I can tell, MRTG seems not to be capable of graphing uptime correctly.

> -----Original Message-----
> From: mrtg [mailto:mrtg-bounces+resident=telcontar.net at lists.oetiker.ch] On
> Behalf Of Volk,Gregory B
> Sent: 28 September 2018 21:37
> To: mrtg <mrtg at lists.oetiker.ch>
> Subject: Re: [mrtg] Graphing Uptime
> 
> >>
> >>uptime=`snmpwalk -v1 -c public 10.0.0.1 SysUptime | awk -F'[()]'
> >>'{print $2}'` let hours=uptime let hours=$hours/100/60/60 echo $hours
> >>
> >>If you run that bash and pass it into MRTG, with directives to create
> >>a gauge type graph, you should get a fairly nifty uptime graph. With
> >>correct units for time as a bonus.
> 
> 
> Similar to the above script, this is what I use for plotting uptime with
> MRTG.
> If your snmpget binary supports the "-Otv" formatting flags it should work.
> 
> 
> #!/bin/bash
> #
> # uptime.sh
> # make a call to snmpget with -Otv formatting to just uptime in # timeticks
> only, not with x days hours etc.
> #
> # ./uptime.sh <read_community> <devicename_or_ip> # ./uptime.sh public
> myrouter1 #
> COMMUNITY=$1
> HOST=$2
> UPTIMETICKS=$(/usr/bin/snmpget -v2c -Otv -c $COMMUNITY $HOST
> .1.3.6.1.2.1.1.3.0) #UPTIMEDAYS=$(expr $UPTIMETICKS / 8640000) echo
> $UPTIMETICKS echo $UPTIMETICKS echo $UPTIMETICKS echo $UPTIMETICKS # end
> uptime.sh
> 
> 
> 
> And the MRTG target config that calls uptime.sh looks like this:
> 
> ShortLegend[myrouter_uptime]: days
> YLegend[myrouter_uptime]: days
> LegendI[myrouter_uptime]: days
> LegendO[myrouter_uptime]: days
> Directory[myrouter_uptime]: myrouter
> WithPeak[myrouter_uptime]: ywm
> MaxBytes[myrouter_uptime]: 100000
> Options[myrouter_uptime]: growright, gauge, nopercent
> Title[myrouter_uptime]: myrouter Uptime in Days
> Target[myrouter_uptime]: `/opt/mrtg/bin/scripts/uptime.sh public myrouter` /
> 8640000
> PageTop[myrouter_uptime]: <H1>myrouter Uptime in Days</H1>
>   <TABLE>
>     <TR><TD>ifType:</TD><TD>gauge</TD></TR>
>     <TR><TD>Resource:</TD><TD><br>
>     uptime.sh
>     </TD></TR><br>
>   </TABLE>
> 
> 
> 
> 
> 
> 
> 
> If you are not the intended recipient of this message (including attachments)
> or if you have received this message in error, immediately notify us and
> delete it and any attachments.
> 
> If you do not wish to receive any email messages from Edward Jones, excluding
> administrative communications, please email this request to Opt-
> Out at edwardjones.com from the email address you wish to unsubscribe.
> 
> For important additional information related to this email, visit
> http://www.edwardjones.com/disclosures/email.html. Edward D. Jones & Co.,
> L.P. d/b/a Edward Jones, 12555 Manchester Road, St. Louis, MO 63131 © Edward
> Jones. All rights reserved.
> 
> 
> -----Original Message-----
> From: mrtg [mailto:mrtg-bounces+greg.volk=edwardjones.com at lists.oetiker.ch]
> On Behalf Of Edwin A. Epstein III
> Sent: Friday, September 28, 2018 3:21 PM
> To: mrtg
> Subject: Re: [mrtg] Graphing Uptime
> 
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
> 
> 
> Hi Daniel,
> 
> Yes that example was horribly bodged. I haven't inspected the code, but I
> suspect MRTG works with the value returned by SNMP. For example, I receive
> this:
> 
> SNMPv2-MIB::sysUpTime.0 = Timeticks: (105630500) 12 days, 5:25:05.00
> 
> That cannot be graphed because it is not a number. Everything that MRTG
> graphs must be turned into some number. The example is also horribly bodged
> because it's trying to use a bandwidth graph instead of a gauge. MRTG
> provides for graphing values like CPU load, Memory, and Free disk space. You
> really want to grab the most recent book as it will tell you how to construct
> these. I'll give you an example:
> 
> Target[the_graph]:
> 1.3.6.1.4.1.32050.2.1.27.5.1&1.3.6.1.4.1.32050.2.1.27.5.1:snmp_community_name
> @10.0.0.1:::::2 * -1.1034882
> Options[the_graph]:       unknaszero,gauge,growright,nopercent,expscale,noo
> SetEnv[the_graph]:        MRTG_INT_IP="No Ip" MRTG_INT_DESCR="n/a"
> Colours[the_graph]:       ORANGE#dd8811,NONE#000000,VIOLET#0000ff,DARK
> GREEN#006600
> Title[the_graph]:         Voltage Monitor
> MaxBytes[the_graph]:      850
> AbsMax[the_graph]:        850
> XSize[the_graph]:         600
> 
> All of these directives are explained in the book. The two most important
> ones are the Target and Options directives. The gauge option is what makes it
> a gauge graph, and the noo option suppresses one side of the graph (input or
> output). With the directives you can construct your own custom graph with
> correct units for uptime, and a scale that will make sense. You can control
> titles, legend values, etc.
> 
> Your first issue is how to convert 'Timeticks: (105630500) 12 days,
> 5:25:05.00' to a number. I would suggest graphing the hours of uptime. Even
> after a few years of uptime, the value itself will be less than 100,000 and
> probably graph well over time.
> 
> MRTG provides for pre-processing of SNMP values before they are passed to
> MRTG. I'm performing math before I use the voltage value. Since I'm pretty
> sure that the math is any valid perl statement, you might be able to get away
> with Perl. That being said, you may be best served by simply creating your
> own data collection plug-in, which is thankfully easier done than said.
> Straight from the book:
> 
> Target[ezwf]: `/usr/local/bin/mrtg-scripts -a 1`
> 
> All you need to is create a bash script that pipes your snmpwalk output into
> a awk, and then convert the returned value into the number of hours.
> Timeticks can be converted to hours: Hours = Timeticks / 100 / 60 / 60.
> 
> Something like:
> 
> uptime=`snmpwalk -v1 -c public 10.0.0.1 SysUptime | awk -F'[()]' '{print
> $2}'` let hours=uptime let hours=$hours/100/60/60 echo $hours
> 
> If you run that bash and pass it into MRTG, with directives to create a gauge
> type graph, you should get a fairly nifty uptime graph. With correct units
> for time as a bonus.
> 
> 
> 
> Sincerely,
> 
> Edwin A Epstein, III
> Rhinobee Internet Services
> 707.237.7504 ext 209
> 707.737.0288 Mobile
> 
> ----- Original Message -----
> From: "mrtg-request" <mrtg-request at lists.oetiker.ch>
> To: "mrtg" <mrtg at lists.oetiker.ch>
> Sent: Friday, September 28, 2018 3:00:02 AM
> Subject: mrtg Digest, Vol 132, Issue 1
> 
> Send mrtg mailing list submissions to
>         mrtg at lists.oetiker.ch
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
> or, via email, send a message with subject or body 'help' to
>         mrtg-request at lists.oetiker.ch
> 
> You can reach the person managing the list at
>         mrtg-owner at lists.oetiker.ch
> 
> When replying, please edit your Subject line so it is more specific than "Re:
> Contents of mrtg digest..."
> 
> 
> Today's Topics:
> 
>    1. Graphing uptime (Daniel Beardsmore)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 28 Sep 2018 10:06:23 +0100
> From: "Daniel Beardsmore" <resident at telcontar.net>
> To: <mrtg at lists.oetiker.ch>
> Subject: [mrtg] Graphing uptime
> Message-ID: <041801d4570a$88f67650$9ae362f0$@telcontar.net>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hello
> 
> 
> 
> I can see that graphing uptime is possible, as you can see here:
> 
> 
> 
> http://www.hotelsvillegia.com/mrtg/uptime.html
> 
> 
> 
> The HTML pages report uptime in the format: "163 days, 21:07:10"
> 
> 
> 
> If I check manually, I get this:
> 
> 
> 
> snmpget -v2c -c somecommunity somehost 1.3.6.1.2.1.1.3.0
> 
> DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1415941565) 163 days,
> 21:10:15.65
> 
> 
> 
> The format is almost the same, but the latter contains the full centisecond
> accuracy. You do nonetheless get the raw number included.
> 
> 
> 
> Now, using this in MRTG yields:
> 
> 
> 
> 2018-09-27 19:56:04 -- 2018-09-27 19:51:33: WARNING: Expected a number but
> got '163 days, 7:17:10'
> 
> 
> 
> Looking at the source code, I cannot determine quite how uptime is processed.
> It seems odd that the format is almost the same (without the centiseconds),
> which suggests (along with other code) that MRTG receives pre-formatted
> output, and then has to scrape out the useful bits. (Which is just plain
> horrible if this is true.)
> 
> 
> 
> Am I right in thinking that MRTG presently has no way to extract the raw
> figure here? It seems that the SNMP library is formatting the data
> prematurely and MRTG just works with that preformatted value as it suits its
> own purposes, but that you cannot get the raw data out if you choose, for
> example if you want to record uptime as a graph for checking for reboots.
> 
> 
> 
> In the example posted, I suspect that was bodged to get that to work.
> 
> 
> 
> Regards
> 
> 
> 
> Daniel.
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.oetiker.ch/pipermail/mrtg/attachments/20180928/8eacb971/attachm
> ent-0001.html>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> mrtg mailing list
> mrtg at lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
> 
> 
> ------------------------------
> 
> End of mrtg Digest, Vol 132, Issue 1
> ************************************
> (null)
> 
> _______________________________________________
> mrtg mailing list
> mrtg at lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
> _______________________________________________
> mrtg mailing list
> mrtg at lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/mrtg