Differences between current version and predecessor to the previous major change of MRTG.

Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History

Newer page: version 6 Last edited on Monday, November 12, 2007 5:31:12 pm by GreenGecko
Older page: version 5 Last edited on Tuesday, August 9, 2005 8:25:59 pm by BlairHarrison Revert
@@ -1,17 +1,22 @@
-MRTG [Acronym] for Multi Router Traphic Grapher 
+MRTG [Acronym] for Multi Router Traphic Grapher. Written by Tobias Oetiker -  
-but MRTG will do much more that graph traffic.  
+MRTG will do much more than graph traffic:  
 Designed initially to collect traffic data by snmp from routers and graph traffic usage, but can be extended to graph any range of information including 
 * NameServer activity 
 * MailServer Activity 
 * Proxy/Cache Performance 
 * System Load Average/Memory Usage/Disk Space 
+* mail/webserver performance  
+* absolutely anything else you're prepared to write a script for - exchange rates, disk temperatures, tide height...  
-information can be collected either via [SNMP] or from scripts 
+information can be collected either via [SNMP] or from scripts, and is stored in such a way that the latest information is very detailed, and the data is averaged more and more to allow for graphing of data over longer periods of time without using huge amounts of disk space to store the raw data. In addition to the graphging function, it has the ability to run scripts on triggering thresholds - allowing for everything from emails/sms to be sent right through to automated shutdowns.  
-to a large extent has been replaced by [Cacti], [Cricket] and other rrdtool based packages  
+The only limitation of MTRG is that it it will only display 2 sets of data on any graph. Because of this, Tobias then created the rrdtool - which didn't have this limitation. Many packages - for example, [Cacti], [Cricket] are build on top of the original rrdtool engine.  
+This is one of the most useful tools that any systems administrator can implement, as it will eventually be telling you when to look at something *before* it goes wrong, allowing for a proactive approach to administreing your server(s).