Cisco MCS-7825-H3-IPC1, Руководство по обслуживанию

Страница: 237 / 974

6-3
Cisco Unified Communications Manager Managed Services Guide
OL-22523-01
Chapter 6 Cisco Unified Serviceability Alarms and CiscoLog Messages
Cisco Unified Serviceability Alarms and CiscoLog Messages
•
Clock Synchronization, page 6-4
• Multipart Messages, page 6-4
•
CiscoLog Message Format, page 6-5
• Internationalization, page 6-18
•
Versioning, page 6-18
Log File and Syslog Outputs
When CiscoLog messages are written directly into a log file by an application, each message is on a
separate line. The line separator should be a standard line separator used on a given platform. On
Windows, the line separator must be the sequence of carriage return and line feed characters (ASCII
decimal values 13 and 10; often designated as “\r\n” in programming languages). On Solaris and Linux,
the line separator is a single line feed character (ASCII decimal value 10 and in programming languages
typically “\n”). Two line separators must never appear one after another,
for example, you cannot have
“\r\n\r\n” on Windows, but “\r\n” is fine because these two characters are a single line separator.
In practical terms, this means that applications should be careful when appending data to an existing log.
In some cases an initial line break is required and in others not. For example, if application crashes when
writing CiscoLog message, but before it wrote a line break to file, then when the application starts up,
it should print an initial line break before printing the next message. An application can determine if an
initial line break is necessary during startup by checking the last character sequence in the log file that
will be used for appending.
CiscoLog message format is identical for messages written directly to a log file or those generated by
using the syslog protocol with two minor exceptions. When CiscoLog messages are written directly into
to a file they must be appended with line separators. When CiscoLog messages are sent by using the
syslog protocol then the syslog RFC 3164 protocol PRI header must be prepended to each CiscoLog
message.
The syslog PRI field encodes syslog message severity and syslog facility. The severity encoded in the
PRI field must match the value of the CiscoLog SEVERITY field. Any syslog facility can be used
regardless of the content of the message. Typically, a given application is configured to send all its
messages to a single syslog facility (usually RFC 3164 facilities local 0 through local 7). Refer to RFC
3164 for details about how to encode the PRI field. Below is an example of a CiscoLog message with
the syslog protocol PRI field <165> which encodes the severity level of notice (5) and facility value
local4.
<165>11: host.cisco.com: Jun 13 2003 12:11:52.454 UTC: %BACC-5-CONFIG: Configured from
console by vty0 [10.0.0.0]
Messages as shown in the example above can be sent to UDP port 514 if using RFC 3164 logging
mechanism.
Syslog RFC 3164 provides additional guidelines for message content formatting beyond the PRI field.
However, RFC 3164 is purely information (not on IETF standards track) and actually allows messages
in any format to be generated to the syslog UDP port 514 (see section 4.2 of RFC 3164). The RFC
provides observation about content structure often encountered in implementations, but does not dictate
or recommend its use. CiscoLog format does not follow these observations due to practical limitations
of the format defined in the RFC. For example, the time stamp is specified without a year, time zone or
milliseconds while the hostname can only be provided without the domain name.
CiscoLog messages must remain unaltered when relayed. The PRI field is not part of a CiscoLog
message, but rather a protocol header. It can be stripped or replaced if necessary. Additional headers or
footers can be added to and stripped from the CiscoLog message for transport purposes.