Forwarding syslog messages

The ability to forward syslog messages is at the foundation of the protocol. All meaningful systems that implement syslog support it. The facility and severity code were originally intended to permit filtering and forwarding of messages based both on their interest level and pertinence, but also based upon the administrative station would be interested in aggregating certain messages, such as mail administrators, or UUCP administrators.It might be that a message is forwarded several different times before it reaches its destination. Obviously, information at one level of the enterprise might have no pertinence, while the same information (such as in the hands of a network administrator or application specialist) might be extremely useful. RFC 3164 discusses this as follows:

• Flexibility was designed into this process so that the operations staff would have the ability to configure the destination of messages sent from the processes running on a device.  In one dimension, the events that were received by the syslog process could be logged to different files and also displayed on the console of the device.  In another dimension, the syslog process could be configured to forward the messages across the network to the syslog process on another machine.
• The syslog process had to be built network-aware for some modicum of scalability, since it was known that the operators of multiple systems would not have the time to access each system to review the messages logged there, The syslog process running on the remote devices could therefore be configured to either add the message to a file, or to subsequently forward it to another machine.

Without this ability, there could be no system like the BMC Defender Server program. Administrators would have to either gather information from each machine, or build software to relay information themselves, such as with remote shell or RCP calls. However, given that messages are easily forwarded, it makes sense to forward them, a fact so trivial and obvious that it seems peculiar that this is not commonplace in all enterprises.

What makes this data aggregation slightly difficult is that the volume of syslog messages can be tremendous, so that the scalability of the central syslog server is quickly brought to its limit. Previously, the ability to search through these messages, catalog these messages in significant ways, has become too cumbersome for average software systems. This is precisely the role that BMC Defender Server is intended fo, and the basic problem that the system answers. BMC Defender Server is meant to be the single data aggregation point for huge volumes of syslog messages.