Standard Syslog Server Implementations; Clock Synchronization; Multipart Messages - Cisco MCS-7825-H3-IPC1 Service Manual

Cisco Unified Serviceability Alarms and CiscoLog Messages

Standard Syslog Server Implementations

Standard syslog server implementations can be configured to forward received log messages or to store
the messages locally. Most syslog server implementations strip the PRI field from the received messages
and prefix additional information to the message before storage. This additional information typically
includes two extra fields: the local time stamp and the host identifier (IP or DNS name) of the server,
which generated or relayed the message.
The following example of a CiscoLog message shown the output after being logged by the Solaris 8
syslog server:
There is no standard that defines how syslog servers must store messages. Implementations vary greatly.
CiscoLog only addresses the format in which messages are sent to the syslog server, not how they are
stored by the server that receives them. Specifically, the format and presence of any additional header
fields in syslog log files is outside of the scope of this specification.
Note The CiscoLog specification recommends that the syslog server implementation store CiscoLog
messages in exactly the same format as it receives them only stripping the PRI field and without any
extra headers. This would provide an identical storage format for CiscoLog messages written directly
to the log file by an application or logged through syslog protocol.

Clock Synchronization

It is important that the clocks of all hosts of a distributed application be synchronized with one
authoritative clock. This can be accomplished by using protocols such as NTP. Clock synchronization
is recommended because the time stamps in log messages are required in order to be able to reconstruct
the correct sequence of events based on messages originating from multiple processes or multiple hosts.
Clock drifts can still occur, but ongoing synchronization should reduce this issue to a minimum.

Multipart Messages

ASCII control characters are not permitted in any of the fields of CiscoLog message format. Control
characters include characters such as line feed, form feed and carriage returns. This means that multi-line
messages are not allowed unless to allow:
•
•
Multi-part CiscoLog message consists of a set of multiple valid CiscoLog messages. Messages are
grouped together using a special tag key "part", which identifies the part number and the sequence
number of the original message.
All messages which are part of a multi-part message must have a "part" tag as well as identical values
for the HOST, TIMESTAMP, APPNAME, SEVERITY fields and other TAG values. However, the
sequence number of each message has to be incremented as usual.
Example of a multi-part message:
Cisco Unified Communications Manager Managed Services Guide
6-4
Jun 13 12:12:09 host.cisco.com 11: host.cisco.com: Jun 13 2003 12:11:52.454 UTC:
%BACC-5-CONFIG: Configured from console by vty0 [10.0.0.0]
Better presentation (for example, a stack trace)
Fragmenting messages which exceed 800 octet limit
16: host.cisco.com: Jun 13 2003 23:11:52.468 UTC: %BACC-3-UNEXPECTED_EXCEPTION:
%[pname.orig=rdu][part=16.1/3]: Null pointer exception
17: host.cisco.com: Jun 13 2003 23:11:52.468 UTC: %BACC-3-UNEXPECTED_EXCEPTION:
%[pname.orig=rdu][part=16.2/3]:
Chapter 6 Cisco Unified Serviceability Alarms and CiscoLog Messages
com.cisco.Source:123
OL-22523-01