| Version 15 (modified by human, 10 years ago) (diff) |
|---|
MRTG 3
| DRAFT (!!!!) by Tobi Oetiker, 2006-08-22, v2 |
Use Cases
- Automated Discovery
- When MRTG gets started, it will discover the network and start moniting the devices it finds.
- Device Database
- If information about the devices to be monitored are available in a database, this information can be used by mrtg to define its workload.
- Device Knowledge
- When MRTG detects the type of device it is monitoring, it tries to read a device config file for more information.
- Extensions
- Functional extensions can be realised as plugins. Plugins are perl modules that can inherit functionality from existing plugins.
- Presentation
- Data is presented in a webinterface where it can be organised according to differnt properties like type of data, type of device, location, organisational structure, imporance.
- Low Latency
- Polling data from remote devices is a high latency affair. By running probes in parallel, this task gets faster.
Components
Inventory
Takes care of figuring out what objets are available for monitoring.
- mrtg2_cfg_reader
- reads an mrtg2 config file to figure out which devices were being monitored.
- database_reader
- polls a SQL database for information about devices
- nmapper
- runns nmap or a similar tool to figure out who is present on the network
- snmp_discovery
- uses snmp figure out what devices are on the network and also what sortof information they can provide.
The inventory will be kept current as mrtg runs.
Poller
Gets the actual monitoring data off the devices.
- pinger
- send pings to devices to measure latency
- snmpbulkget
- pull blocks of data off snmp capable devices
- expecter
- execute an external program under perl-expect control to get some data back.
- rstat
- use rstat to query hosts abouttheir load and users
Storage
The storage modules use information from the inventory to determine what data should be stored and instruct the pollers to get it for them.
- latency
- store latency measurements
- network-if
- store networkinterface data
- host
- store information on a hosts memory, kerel and cpu status
- disks
- store information about disk fill state
Graphing
Modules that take the stored infomation and turn it into neat graphs
- mrtg_classic
- produce a graph that thries to look like the thing that mrtg-2 did
- smokeping
- create a smokeping graph
- host
- graph depicting the state of a host
- disk
- graph for disks
- cluster_state
- take information from many hosts and create an overview graph
Presentation
Modules that organize the data for presentation. They call upon the graphing modules to produce the graphs.
- network_topology
- present information according to the network topology.
- information_type
- organize by the type of information
- graph_interest
- sort the graphs by 'interest'
There is also a way to define the template for the look and feel of the web interface.
Rating
The rating plugins decide how interesting a graph is from 0 to 100. This allows to display interesting graphs 'on top' and also to send alarms once a graph gets a sufficiently high rating.
- latency
- is there a 'unexpected' change in latency.
- threshold
- check data for threshold, based on local rules or on information acquired by an inventory module.
Architecture
The mrtg daemon will use forking to reduce latency. The forked instances will do the polling and once the information is received also the storing. For improved performance, the storing could also be off loaded to a writer process that caches data and does bulk-updates to the rrds. There must be a way for the webinterface to partially flush the cache before drawing a graph.
Open Questions
Some plugins depend heavily on others in order to function, there must be some standard way for them to communicate configuration information.
