[mrtg] Graphing Uptime
Daniel Beardsmore
resident at telcontar.net
Mon Oct 1 15:24:27 CEST 2018
Yes, because the MRTG logs only hold integers, so the y axis values must be integral, meaning that they cannot be a unit as large as an hour or day unless you want the graph to increment by whole numbers of that amount.
So, yes, for now, the y axis (Target scaling) will have to be the update granularity (e.g. YLegend[Foo-uptime]: Uptime (minutes)) and then the Factor value is whatever will scale that down to days.
(Minute granularity is not needed, but having the y axis scale as (say) ten minuteses is even weirder. Ultimately the reason it's a problem is that we don't have metric time, while all other metrics make sense when scaled with k/M/G.)
Well, I think this will have to suffice for the time being -- thank you all for your help.
> -----Original Message-----
> From: Volk,Gregory B [mailto:greg.volk at edwardjones.com]
> Sent: 01 October 2018 13:56
> To: Daniel Beardsmore <resident at telcontar.net>
> Subject: RE: [mrtg] Graphing Uptime
>
> >I can only assume that you are using RRDTool logging, as that is the
> >only circumstance that I can see where your arrangement should work.
>
> You are correct, I am using RRDTool and that is probably why my graphs have
> non-integers.
>
>
>
>
>
>
> 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 Daniel Beardsmore
> Sent: Monday, October 01, 2018 7:50 AM
> To: mrtg at lists.oetiker.ch
> 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.
>
>
> I don't want the configuration generation entangled with scripts.
>
> Looking at your configuration, you're using target/8640000 and *not* getting
> it rounded, while if I do that, it gets rounded.
>
> The documentation states:
>
> "MRTG automatically rounds the result of the expression to an integer unless
> RRDTool logging is in use and the gauge option is in effect for the target."
>
> I can only assume that you are using RRDTool logging, as that is the only
> circumstance that I can see where your arrangement should work.
>
>
> > -----Original Message-----
> > From: Volk,Gregory B [mailto:greg.volk at edwardjones.com]
> > Sent: 01 October 2018 13:40
> > To: Daniel Beardsmore <resident at telcontar.net>; mrtg at lists.oetiker.ch
> > Subject: RE: [mrtg] Graphing Uptime
> >
> > >Is there a way to ever have the y axis in days *and* generate a graph
> > >with
> > the y axis in fractional days?
> >
> > When I use the bash script and MRTG config that I included below to
> > collect and plot uptime, my graphs have fractional days.
> >
> > I'm attaching two example PNGs uptime_monthly.png and uptime_daily.png.
> > Notice the values at the bottom of each graph have uptime-day
> > precision to 3 decimals.
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: mrtg
> > [mailto:mrtg-bounces+greg.volk=edwardjones.com at lists.oetiker.ch]
> > On Behalf Of Daniel Beardsmore
> > Sent: Monday, October 01, 2018 7:24 AM
> > To: mrtg at lists.oetiker.ch
> > 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.
> >
> >
> > 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_commu
> > > ni
> > > 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/8eacb97
> > > 1/
> > > 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
>
> _______________________________________________
> mrtg mailing list
> mrtg at lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
More information about the mrtg
mailing list