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:[email protected]] > Sent: 01 October 2018 13:56 > To: Daniel Beardsmore <[email protected]> > 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- > [email protected] 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:[email protected]] > On Behalf Of Daniel Beardsmore > Sent: Monday, October 01, 2018 7:50 AM > To: [email protected] > 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:[email protected]] > > Sent: 01 October 2018 13:40 > > To: Daniel Beardsmore <[email protected]>; [email protected] > > 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:[email protected]] > > On Behalf Of Daniel Beardsmore > > Sent: Monday, October 01, 2018 7:24 AM > > To: [email protected] > > 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@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@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:[email protected]] On > > > Behalf Of Volk,Gregory B > > > Sent: 28 September 2018 21:37 > > > To: mrtg <[email protected]> > > > 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- [email protected] 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:[email protected]] > > > 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" <[email protected]> > > > To: "mrtg" <[email protected]> > > > Sent: Friday, September 28, 2018 3:00:02 AM > > > Subject: mrtg Digest, Vol 132, Issue 1 > > > > > > Send mrtg mailing list submissions to > > > [email protected] > > > > > > 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 > > > [email protected] > > > > > > You can reach the person managing the list at > > > [email protected] > > > > > > 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" <[email protected]> > > > To: <[email protected]> > > > Subject: [mrtg] Graphing uptime > > > Message-ID: <[email protected]> > > > 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 > > > [email protected] > > > https://lists.oetiker.ch/cgi-bin/listinfo/mrtg > > > > > > > > > ------------------------------ > > > > > > End of mrtg Digest, Vol 132, Issue 1 > > > ************************************ > > > (null) > > > > > > _______________________________________________ > > > mrtg mailing list > > > [email protected] > > > https://lists.oetiker.ch/cgi-bin/listinfo/mrtg > > > _______________________________________________ > > > mrtg mailing list > > > [email protected] > > > https://lists.oetiker.ch/cgi-bin/listinfo/mrtg > > > > _______________________________________________ > > mrtg mailing list > > [email protected] > > https://lists.oetiker.ch/cgi-bin/listinfo/mrtg > > _______________________________________________ > mrtg mailing list > [email protected] > https://lists.oetiker.ch/cgi-bin/listinfo/mrtg _______________________________________________ mrtg mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
