July 28, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Play it Cool: Creating Reports from Stored Data

  • September 20, 2006
  • By Steve Schafer
  • Send Email »
  • More Articles »

Using Packaged Graphing Applications

Several prepackaged graphing programs are available on the Internet, especially in the open source arena. I'll cover a couple of the more useful options.

Graphing data with MRTG

One popular application, Multi Router Traffic Grapher (MRTG), traditionally is used to graph bandwidth usage flowing across routers on local LANs and the Internet. Many a system administrator uses MRTG to keep an eye on server bandwidth usage.

Note: MRTG is available from the main MRTG site, http://oss.oetiker.ch/mrtg/, and has been packaged for most Linux distributions.

MRTG uses a set of Perl programs to collect, store, and display graphical data. A set of fast, specialized C routines consolidate the data and generate the graphs, which then are embedded in Web pages for display. MRTG can read a specially formatted text file for its data, or can use basic SNMP queries to gather the data. Whereas SNMP queries are better suited for collecting data from network peripherals (such as routers), a text file is readily accessible via your temperature-reading infrastructure.

MRTG runs as an executable and takes its data collection and reporting cues from a monolithic configuration file. The file I use for my temperature collection is shown in Listing 3.

Listing 3: My mrtg.cfg file for temperature-data reporting

Workdir:  /var/www/mrtg
Logdir:   /var/www/mrtg/logs
Interval: 5

Target[office.temp]: 'awk '{print $1; print $1;
                            print "quite some time";
                            print "temp sensor"}'
   </home/sschafer/officetemp/currtemp.log'
Title[office.temp]: Office Temperature
PageTop[office.temp]: <H1>Office Temp Stats</H1>
MaxBytes[office.temp]: 100
Unscaled[office.temp]: ymwd
Options[office.temp]: nopercent,gauge,integer
LegendI[office.temp]: &nbsp;temp:
LegendO[office.temp]: &nbsp;temp:
Ylegend[office.temp]: deg
ShortLegend[office.temp]: deg
Legend1[office.temp]: Temp
Legend2[office.temp]: Temp
Legend3[office.temp]: Temp
Legend4[office.temp]: Temp

Notice that the configuration file delimits targets (in this case, just one, office.temp) by using bracketed identifiers for each configuration option. The Target line specifies the protocol and location of the device to monitor, or specifies the external data-gathering script that will supply the data. The target is also used to name the generated reports—my temperature report is office.temp.html.

In the case of an external script, which is used here, the data returned must consist of four lines:

  • First variable (usually incoming bytes)
  • Second variable (usually outgoing bytes)
  • Uptime of target
  • Name of the target
Note: To simplify matters, a handful of shell scripting lines are used in place of calling an external script containing those lines. I chose this method to avoid maintaining yet another script outside the MRTG framework. However, these lines rely upon the file "currtemp.log" being present and containing the last temperature read by the reading script.

As previously mentioned, MRTG is used primarily to track bandwidth across a router—hence the separate incoming and outgoing variables. However, you only need one variable, so your external script simply repeats the temperature value twice. A typical line of data from the shell scripting code resembles the following:

77
77
quite some time
temp sensor

The rest of the configuration directives are mostly subversions of the MRTG system to display legends and markers on the MRTG page. MRTG should be run periodically from a standard scheduling service, such as cron on Linux; the data is collected and new graphs (and pages to house them) are generated on each run.

For example, the following line in my system's crontab file runs MRTG with the appropriate configuration file every five minutes, to correspond to the five-minute interval specified in the configuration file:

*/5 * * * *     mrtg /var/www/mrtg/mrtg.cfg

Figure 3 shows a sample of what the resulting MRTG document looks like on my server.



Click here for a larger image.

Figure 3: The MRTG temperature-reporting page on my server (office.temp.html).

More detail, but more complexity: RRDtool and Cricket

Users who want more detail and flexibility in their reports might want to check into using RRDtool, a popular SNMP data-collection tool; and Cricket, a framework for presenting the data collected by RRDtool.

Figure 4 shows a sample page of the reporting generated by these tools.



Click here for a larger image.

Figure 4: My temperature reporting via RRDtool and Cricket.

The infrastructure for using RRDtool with Cricket is not trivial to set up, but can be worth the effort if you need a powerful, flexible SNMP data infrastructure. Both applications are packaged for most Linux distributions, or can be found at the following locations on the Internet:

One advantage of this infrastructure is that the reports are generated in real time when the reporting page is loaded. Although the temperature readings aren't time sensitive, other data-monitoring applications may need to have up-to-the-minute data on tap.

For my temperature needs, I co-opted a Cricket configuration file from the contribution section of the Cricket Web site—one that was specifically designed to report the temperature of Sun servers. It was much easier to implement that feature than it would have been to create a configuration from scratch.

Conclusion

This series of articles demonstrated several technologies and methods for collecting and reporting data from a variety of sources. Although the series used examples from a particular application, a thermometer connected to a serial port, the techniques used in that application can be applied to any situation in which data collection and reporting is a necessary component.

About the Author

Freelance consultant Steve Schafer has written multiple technology books and articles. In the business world, he most recently worked in-house as COO/CFO of Progeny Linux Systems in Indianapolis. Serving as president and CEO in the company's startup years, Steve led Progeny's business and financial turnaround during the tech crash of the early 2000s. Prior to joining Progeny, he was a senior title manager for Macmillan Digital USA, overseeing the operating system and entertainment software products and tripling Macmillan's Linux product line revenue. He partnered Macmillan with Mandrake, bringing Mandrake's Linux distribution to the competitive retail market.



Page 2 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel