Log File Monitor directives
The Log file monitor directives are similar to those used in Event log monitoring as discussed. Following the Event log specifications, you can configure one or more log file monitors, default facilities and severities, and match patterns that overwrite these defaults. The following directives are supported:
LogFile | This directive indicates the pathname to a streaming text log file on the system. You can specify the pathname as a relative pathname, with respect to the location of the CO-sysmsg.exe program, or absolute pathname, using either forward or backward slashes. All the directives that follow, until the next LogFile directive, apply to the specified log file. This directive can contain Time Format values, such as %y, %m, %d, to respectively match the two-digit year, two-digit month, or the two-digit day. Such as the file specification C:/windows/logfiles/f-%y%m%d.log can be used to monitor a file with a name such as f-091231.log. Additionally, the root filename can contain a (*) wildcard to match the file that was most recently modified. Such as, the file specification C:/windows/logfiles/*.log matches the file in the logfiles directory that was most recently modified. |
LogName | This optional directive, if it exists, must follow the LogFile directive. It is the name of the log file (or subsystem) that is displayed in the syslog message. If this value is not provided, the event message is not identified with the log file other than in the message content. The value can be any arbitrary text string. It is commonly punctuated with a trailing semicolon, supplied by you, such as Oracle Data: or HTTP Log File: |
Encoding | This optional directive, if it exists, describes the encoding for messages in the file. The values can be Western, UTF-8, GB2312, Big5, or KR-EUC. If this directive does not exist (or the value of this setting is Default), then the device type settings determine the message encoding. This switch works only for BMC Defender implementations and is not applicable to third party syslog receivers that might receive messages from the agent. The setting is mainly useful for those systems where a log file might be written using an encoding scheme that is different from the rest of the encoding used on the platform, such as when a UTF-8 encoded file is being written on a GB2312 type system. |
Formatter | This optional directive, if it exists, is an interface to a custom formatter. This custom formatter consists of a DLL (supplied by BMC Defender or some other vendor) installed at the agent and used to process data to format syslog records. If this directive is specified, its value can be user01, user02, user03, or user04, based upon information supplied by BMC Defender and the DLL designer. |
MaxSizeChange | This optional directive, if it exists, must follow the LogFile directive. It is an integer size, in bytes. If the file increases by this number of bytes or more during a single 500 msec interval, it triggers a special message indicating that the file has increased rapidly in size. If this value is not furnished, the value of 10,000 bytes is used. (The value might be increased to 1 Mbyte.) This parameter helps prevent excessive syslog messages from being generated should a file undergo extremely rapid updates, such as a new file being copied into place. Each log file has its own MaxSizeChange value. |
LogStatType | This optional directive, if it exists, must follow the LogFile directive, and must have a value of Active or Passive. The default Active causes the relevant log file monitor to actively open log files to determine their sizes, whereas the Passive (default) setting uses the operating system to determine log file sizes. The Active setting might be useful for files that are flushed to the disk only occasionally, but this mode of operation is much more intrusive and might cause unexpected crashes of the log processes. If the directive is not specified, Log files are checked passively, such as you can not open a Log file unless a change to the file exists. |
LogStatChange | This optional directive, if it exists, must follow the LogFile directive, and have a value of disable, enable. The directive indicates that the monitor agent is not to read the file, but only send a syslog message (with the DefaultFacilty and DefaultSeverity) should the file modification time change. This is useful for monitoring file objects that are not necessarily log files. The file object specified by LogFile can be a directory or any file, including an executable file or configuration file. |
RequireChangeSecs | This optional directive, it exists, should follow the LogFile directive (usually after the MaxSizeChange directive). The value specifies the number of seconds that might pass without the log file changes. This directive is useful for monitoring files that are expected to change within a certain period of time, such as every 300 seconds. If the file does not change in the specified period of time, then an IDLE message is generated. |
DefaultFacility | This optional directive might follow the LogFile directive. The value specifies a facility name (or an official facility number between 0–23) that identifies the default facility code used in all messages that are logged to the specified file. If this directive gets omitted, the default facility is assumed to be user. |
DefaultSeverity | This optional directive might follow the LogFile directive. The value specifies a severity name (or an official facility number between 0 and y), that identifies the severity code used in all messages that are logged to the specified. The value of this directive is commonly disabled or -1, indicating that no message is processed unless it matches one of the UseSeverity patterns. If this directive gets omitted, the default severity is assumed to be disabled. |
UseFacility | This directive might follow the DefaultFacility directive and is followed by one or more MatchKeyWord directives. This operates identically to the Event Log monitor directive, described previously. The directive is followed by a series of match patterns, any of that causes the UseFacility value to be specified as the message facility. Multiple UseFacility directives, each followed by multiple MatchKeyWord directives, can be configured. |
UseSeverity | This directive is similar to preceding UseFacility directive but affects the message severity instead of the facility code. This operates identically to the Event Log monitor directive, described previously. The directive is followed by a series of match patterns, any of that causes the UseSeverity value to be specified as the message facility. Multiple UseSeverity directives, each followed by multiple MatchKeyWord directives, can be configured. |
MatchKeyWord | This directive operates identically to the Event Log monitor directive, discussed previously. The directive nested within a UseFacility or UseSeverity directive, and specifies a single match keyword, with possible * or ? wildcards. If a new log file entry matches the specified pattern, then the related severity or facility is used. Multiple patterns can be specified, without limit. Any other directive ends the MatchKeyWord list, so the MatchKeyWord directives must all be contiguous within a single UseFacility or UseSeverity block. |
This section provides information about the following topics: