Syslog message content

One of the difficulties of syslog protocol, that distinguishes it from SNMP and other request/response protocols, is that the end user has no control over the message content. If there was some certification procedure that was required in order to participate in the syslog development process, this might not be too aggravating. However, any designer can generate syslog messages that eventually end up in the BMC Defender Server.  RFC 3164 elaborates on this issue as follows:

• The writers of the operating systems, processes and applications have had total control over the circumstances that would generate any message. In some cases, messages are generated to give status. These can be either at a certain period of time, or at some other interval such as the invocation or exit of a program.  
• In other cases, the messages may be generated due to a set of conditions being met. In those cases, either a status message or a message containing an alarm of some type may be generated.  It was considered that the writers of the operating systems, processes and applications would quantify their messages into one of several broad categories.

In practice, it appears that most syslog messages are very relevant. The BMC Defender Server handles erroneous or badly formed messages as follows:

• If the message facility code or the severity of the message seems inappropriate, based upon the message content or the various other factors of the message, the user can configure the system to override the facility or severity code, thereby making the message more proper. The end user has complete control over these two fields.
• If no particular facility seems to match the message such as, the message is in a special class that is not covered by the RFC 3164 facility codes, the user can actually define a new facility that makes sense in the context of the enterprise, and then override the normal facility to be the new facility.
• If the message content is not fixable or patchable, or has no pertinence whatsoever, and is just wasting bandwidth, the user can elect to simply filter the message out at very input of the system, with no other processing taking place on the message. The filtered messages are still collected and logged (for a time) but are purged from the system at a higher rate. In the case of the BMC Defender Server, filtered messages are retained only for 24 hours maximum.

The preceding features of the BMC Defender Server greatly enhance the practicality of using syslog protocol by increasing the end user control over the message.