This section explains the operation of the Syslog FileLine Gleaner from the GT.M Monitoring Reference Implementation and discusses the caveats of gleaning the syslog messages on a system with multiple GT.M versions in use.

The following summarizes categorization used by the Syslog Gleaner:

When processing GT.M messages, the Syslog Gleaner utilizes preconstructed parsing clues (primarily for argument extraction) specific to the GT.M version that the gleaner is running on. Because old messages occasionally get removed or reworded in new releases of GT.M, the Syslog Gleaner may sometimes be unable to recognize or parse a particular message for the purpose of reporting it in an appropriate InfoDictItem. This is a possibility when a system has multiple database instances with different GT.M versions configured to report their messages in the same syslog file. InfoHub logs every occurrence of unparseable or unrecognizable message in the syslog as well as in the error InfoDictItem, if one is configured.

Depending on the OS and configuration of the syslog utility, certain messages may never reach the log file due to the use of load-induced skipping or repetition-induced compression techniques; such messages are thus unavailable for gleaning. For example, the popular rsyslog daemon allows the reduction of repeated messages via the $RepeatedMsgReduction configuration directive. When in effect, this mode replaces repeated content with a message like "last line repeated n times." Because such messages only qualify in the most general category (All Messages InfoDictItem), use message reduction with the FileLine Syslog Gleaner after considering its impact. Factors to contemplate in this regard are any rate based Subscriptions and Subscriptions to critical messages such as the ones from gtmsecshr or having fatal severity.

loading table of contents...