[mrtg] Graphing Uptime
Daniel Beardsmore
resident at telcontar.net
Tue Oct 2 17:42:48 CEST 2018
Ah, I see a gotcha.
When using external scripts, they are tasked with providing a "string (in any human readable format), telling the uptime of the target."
Chances are this is why HTML generation just magically assumes that the time is already processed.
In my case, not an issue, but using /^\d+$/ would at least guess that it got timeticks (a timestamp in some other format, such as UNIX, wouldn't hurt).
(That or move the uptime check to a script after all ...)
> -----Original Message-----
> From: mrtg [mailto:mrtg-bounces+resident=telcontar.net at lists.oetiker.ch] On
> Behalf Of Daniel Beardsmore
> Sent: 01 October 2018 10:25
> To: mrtg at lists.oetiker.ch
> Subject: Re: [mrtg] Graphing Uptime
>
> Oops, it seems that the temporary code change I made *did* work -- it just
> took a while to take effect for some reason.
>
> For the moment (and realistically, "forever") I'm going to use this change
> (applied against Debian's 2.17.4-2+b1):
>
>
> diff -u mrtg.old mrtg
> --- mrtg.old 2013-06-09 20:49:05.000000000 +0100
> +++ mrtg 2018-10-01 09:10:06.229385030 +0100
> @@ -1684,6 +1684,7 @@
> &$LOC("The statistics were last updated <strong>$Today</strong>");
> }
> if ($uptime and ! $$rcfg{options}{noinfo}{$router}) {
> + $uptime = BER::pretty_uptime_value($uptime);
> print HTML
> ",<br />\n".
> &$LOC("at which time $namestring had been up for
> <strong>$uptime</strong>.") @@ -2218,6 +2219,8 @@ }
>
> sub getsnmparg ($$$$){
> + $BER::pretty_print_timeticks = 0;
> +
> my $confcache = shift;
> my $target = shift;
> my $cfg = shift;
>
>
> I don't know if this is a legal change, in terms of whether BER is expected
> to be loaded (or installed) at all times, and whether timeticks is expected
> to be in human-readable format anywhere else.
>
> However, to my mind this now behaves as one would expect it to.
>
>
> Interestingly, I notice that this isn't quite accurate:
>
> Target[FOO-uptime]:
> 1.3.6.1.2.1.1.3.0&1.3.6.1.2.1.1.3.0:community at host/8640000
>
> I get 167.0 days instead of 166.9 days for 1442053341, so there seems to be a
> loss of precision somewhere in the calculation. Setting Factor to 1/8640000
> is more accurate but it so happens that the above method (multiply or divide
> by an integer within the target) is already part of the configuration
> generation, and it's cleaner than putting a minuscule number into the
> settings!
>
>
> > -----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_communi
> > ty_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
>
> _______________________________________________
> mrtg mailing list
> mrtg at lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
More information about the mrtg
mailing list