2. Application Output Streams

2.1. Output Types

There are currently four implemented application output types:

FIFOs: App_Out_Fifo.pm

Standard Unix/Linux named pipes, or FIFOs — the FIFOs themselves live in _var/_FIFO.

Standard: App_Out_Std

...meaning normal, rotated, log files — rotation is built into the framework and can be configured to trigger on either time- or file-size-based criteria.

Disk buffers: App_Out_Disk_Buffs

Log files living in _var/_disk_buffs, except that rather than rotate the files, output is added at the end and old lines are trimmed from the beginning, so that the file size remains within configured upper and lower bounds.

Events

Given a warning or trouble that needs to be reported a small file is created in _var/Events with a filename based on the message. If the filename exists already it is not updated. Such files are never removed by SyMon — they should be removed by the system sys-admin after necessary action has been taken.

Other types are planned:

Email

...for example...

2.2. Output Streams

There are five output streams intended for use by any application script: warning, trouble, ticker, log and error. The first three are intended for operating-system (and hardware) monitoring; the last two are intended for application script-related messages.

Each stream can be implemented by one or (usually) more types (see App_Output_Streams.pm and App_Outs_Config.pm).

warning

messages regarding things that merit attention, e.g., a partition is getting full, a user is hogging all the CPU on a general-purpose machine...

trouble

portents of impending doom, e.g., SCSI transport errors, 99%-full partitions...

ticker

just to show that the OS is ticking along nicely — the target system is up and accessible and generally what's going on, in a nice relaxed way...

log

a record of what's being going on --- what the application script has asked of the modules. Much of this is echoed to stdout --- there are two methods which write messages to log: std_log and std_log_echo.

error

a record of things that have gone wrong with the monitoring software — not with the target host or hardware — e.g., failed to open output file.