Help
Help Description: Fast Track Systems Monitor (FTMON) is a open source monitoring engine (written in Perl) that can be integrated with other systems management vendor solutions. It also defines a standard that allows applications/devices to be instrumented rapidly. The intent is that one day there will be a FTMON monitor for virtually every device or application you can think of, and that any detected problems from these monitors will be able to be forwarded to any systems management solution. It is completely configuration file based (a WebMin interface is planned and a WxWindows perl interface is currently being developed).
If you have any support related questions or would like to offer suggestions for improvement please email support@ftmon.org
The following is a brief description of what each of the menu items are for.
Shows the products (applications/devices etc) that are currently being monitored as well as the highest severity event condition that currently exists for each product. From here you can drill down and see the highest event conditions for individual monitors for that product. At the lowest level you can see what thresholds are set, the instantaneous monitor values and graphs of monitor values over time.
Shows all the currently open events for all products being monitored (ordered by event severity). CLOSED event conditions can still be displayed and not closed off immediately if you adjust the $FT::EVENT_TLL variable in $FT::CONFIG_DIR/ftmon.cfg
Shows the event conditions that have existed in the past (by default the last 30 event conditions are shown). To change this adjust the $FT::EVENT_HISTORY_SIZE variable in $FT::CONFIG_DIR/ftmon.cfg
Shows what jobs are scheduled to be run and when they run if they were successful or not. Jobs can be monitors, command actions in response to monitors, html generation jobs etc.
Show what severity levels are supported by the currently active Event Manager. NB Event Managers can be changed by changing the $EVENT_MGR variable in $FT::CONFIG_DIR/event_manager.cfg. to point to an alternative EventManager. Read this configuration file for details on how to do this.
FTMON is completely configuration file based. A configuration file hierarchy exists so that changes made at high level configuration file can be applied to
Monitors run at the <product> level in the hierarchy where they include (import) the implementation files in the impl directory below and the common.cfg file hierarchy (mentioned above) in the directories above. The <product> level is also the level at which configuration thresholds can be adjusted in each <monitor>.cfg file. This is were most of you adjustments will be made.
$FT::CONFIG_DIR
ftmon.cfg (NB ftmon must be re-started for changes to this file to take effect)
event_manager.cfg
common.cfg
<vendor> (e.g. Sybase)
common.cfg
<product> (e.g. ReplicationServer)
common.cfg
<monitor>.cfg (e.g. queue.cfg)
impl
common.cfg
<monitor>.cfg
The <monitor>.cfg files are were thresholds are set. It has the following form
$FT::MONITOR::NAME = "<monitor>";$FT::INTERP[0] = "<interp>"; #Optionaldo "common.cfg";do "impl/$FT::MONITOR::NAME";<variables><thresholds>
A threshold is made up of the following fields.
[<resource>, <calculation>, <severity>, <eventid>, <message>, <mode>, <mail>, <action>];
Unless you are writing a new monitor the only field you should adjust is <calculation> , specifically the threshold value in the calculation .e.g in the calculation ($Value > 10), 10 is the threshold value.
This is the "thing" being monitored. You can identify resources in this column
If there is no resource associated with the monitor then you can leave the resource column empty.
Calculation specifies the limit or threshold of a resource attribute. If the calculation returns true (i.e limit reached) then the event specified by the rest of the configuration line is carried out as well as any associated actions.
Severity depends on the EventManager the events are being forwarded to. Ideally it best to keep the severity labels generic so you can direct to a new EventManager should your existing ESM product become "legacy" - or use the ISO standard.
The EventId uniquely identifies the event being generated. It also provides a summary of the problem. The standard format is <Vendor>/<Product>/<Monitor>/<key>=<Instance>
A monitor could check multiple things so Check uniquely identifies the "calculation" or threshold/limit being breached.
The message is the text that is sent as part of the Event to identify the condition of the resource as a result of the threshold/limit being breached.
Action specifies "any corrective" action to carry out as a result of the resource condition.