LogFile monitoring directives


Following are the optional parameters:

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 an 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 two-digit day. For instance, you can use the file specification C:/windows/logfiles/f-%y%m%d.log to monitor a file with a name such as f-091231.log.

LogName

This optional directive, if it exists, must follow the LogFile directive. It is the name of the log file (or subsystem) 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 commonly punctuates with a trailing semicolon, such as Oracle Data: or HTTP Log File:.

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 amount 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 you do not provide this value, the value of 10,000 bytes is used. (You can increase the value 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.

LogStatChange

This optional directive, if it exists, must follow the LogFile directive, and has a value of disable or enable. The directive indicates that the monitor agent is not to read the file, but only to send a syslog message (with the DefaultFacilty and DefaultSeverity) if the file modification time changes.

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. You cannot use this directive with any MatchKeyword expressions. If no LogStatChange directive exists, then changes to the file modification times are not monitored.

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 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 logged to the specified file. The value of this directive is commonly disabled or -1, indicating that no message is processed unless it matches one of the UseSeverity patterns (described further). If this directive is 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 EventLog monitor directive, described previously. The directive is followed by a series of match patterns, any of which, 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 the UseFacility directive in the preceding row of this table, but affects the message severity instead of the facility code. This operates identically to the EventLog monitor directive, described previously. The directive is followed by a series of match patterns, any of which, 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 EventLog monitor directive, discussed previously. The directive is 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. The MatchKeyWord list is ended by any other directive, so the MatchKeyWord directives must be contiguous within a single UseFacility or UseSeverity block.

Special LogFile names

The LogFile specification allows you to incorporate a time format specification into the file name. This allows BMC Defender to monitor log files whose names change each day. BMC Defender employs standard UNIX type time formatting of file names, where the following symbols have special significance in a file name:

%a

Abbreviated weekday name

%A  

Full weekday name

%b

Abbreviated month name

%B

Full month name

%d

Day of the month as a decimal number (01 – 31)

%H

Hour in 24-hour format (00 – 23)

%I

Hour in 12-hour format (01 – 12)

%j 

Day of year as a decimal number (001 – 366)

%m

Month as a decimal number (01 – 12)

%M

Minute as a decimal number (00 – 59)

%U

Week of, with Sunday as the first day  (00 – 51)

%w

Weekday as a decimal number (0 – 6; Sunday is 0)

%W

Week of year, with Monday as the first day (00 – 51)

%y

Year without century, as a decimal number (00 – 99)

%Y

Year with century, as a decimal number

%z 

Time-zone name or abbreviation

%% 

Percent sign

Example

Consider the case where a log is created each night with the month and date, and placed in a folder each night with the name of the specified year. Assume that the file is named Z:\logs\2014\ex0620.log. You can specify this file in the LogFile directive as  Z:\logs\%Y\ex%m%d.log, that resolves to the correct name without any further adjustments.

Other notes

Each log file has a DefaultFacility and a DefaultSeverity value, followed by multiple optional UseFacility and UseSeverity statements. Each UseFacility and UseSeverity statement can have multiple MatchKeyWord statements. This provides a simple way to configure facilities and severities for any particular message.

Unlike the EventLog specifications, the DefaultSeverity statement in the LogFile Specification has no auto value available. This is because, unlike the event logs, there is no obvious severity assigned to arbitrary text strings in a file. You must define these severities.

To filter unimportant out data, you can make the DefaultSeverity for each log file disabled. The default severity is applied only if no other severity specification is found. In this way, only those messages that have assigned severities get sent as syslog messages. This reduces the load on the syslog server, especially if you have thousands of log file monitors. The administrator can specifically target a key set of messages using this technique.

The LogStatChange directive allows you to monitor for the existence or modification of any file system object. This directive should not be with any UseFacility or UseSeverity values, or any MatchKeywords. The directive permits the operator to watch for changes to critical file system objects, such as password files, configuration files, or directories. This directive can be used only with the LogFile directive.

Note

There is a special and optional MaxSizeChange directive associated with log file monitoring. If the log file increases to a very large value, rather than sending out many syslog messages, the program sends out a single File Size Changed syslog message to indicate this condition. This prevents a situation where the administrator truncates the file by hand or copies some other file on top of the monitored file (as might often occur).

Additional Notes

  • The BMC Defender Syslog Message service configuration file resides in the same directory as the CO-sysmsg.exe executable and is the CO-sysmsg.cnf file. By default, this file locates in the installationDirectory\wintools directory.
  • This file is read on service startup and contains the name of the destination host, as well as other directives.
  • The file does not need to be modified and comes ready-to-run. However, you can tailor the file with match patterns that filter and set the severities and facilities associated with event log messages.
  • The file has an additional section (that does not require or interact with the event log monitors) that allows you to specify up to 50 different streaming log files to get monitored. This works independent of the event log monitor, and is extremely useful for instrumenting arbitrary system log files, such as those associated with Oracle and Apache.
  • Log file paths (used by the log file monitor) can be dynamically derived to contain dates and times using standard time specifications incorporated as part of the pathname.
  • Log file paths (used by the log file monitor) can contain wildcards (either an asterisk (*) to match multiple characters, or a question mark (?) to match a single character). In this case, the file that matches the wildcard and has recently modified on the system is used as the operant file.
  • The agent can contain a marker function that permits a "heartbeat" type indication to be sent at periodic intervals. This heartbeat can be used to schedule periodic activities, but cannot coordinate to a particular time of day such as midnight or noon.
  • The agent can send data to multiple IP Addresses using the AuxAddress directive. Zero to eight auxiliary addresses can be defined. These addresses are not authorized to reconfigure the agent remotely, and cannot be encrypted, but otherwise serve as destinations for all syslog messages generated by the program.
  • The CO-sysmsg.log file contains a transcript of actions (and errors) encountered during the execution of the agent. This file is useful for diagnosing system-level problems. The file gets created in the same folder as the CO-sysmsg.exe program.
  • The LogLocal directive within CO-sysmsg.cnf configuration file can be used to locally log all messages sent in the CO-sysmsg.log file (as described). This directive also creates the CO-sysmsg.dbg file, useful for system level diagnosis.

Tip

The best way to learn about the configuration items is to experiment with the file, adding directives, and then possibly running CO-sysmsg.exe program in foreground (using the -foreground option.) With this technique, you can quickly target specific messages on the system. To check the configuration file without executing the CO-sysmsg.exe program, use the CO-sysmsg –check option.



 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*