Ah, right, there is some sort of "single request" option, and only if you choose to use that, might you want to disable pretty printing ...
I have no idea. On 2018-09-28 21:21, Edwin A. Epstein III wrote: > 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:[email protected]:::::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/8eacb971/attachment-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
