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

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

6-17
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
The general guideline is to put all required information in the message body and make appropriate
information available via tags. In other words, the message should provide sufficient meaning even
when all tags are disabled. Tags merely provide additional useful information and a way to present it in
a standard, easily filtered, form.
The following are two valid examples of a message where both the message and the message tags contain
a MAC address. Example with tags disabled:
11: host.cisco.com: Jun 13 2003 23:11:52.454 UTC: %BACC-3-BAD_REQUEST: Bad request
received from device [1,6,aa:bb:11:22:33:aa]. Missing header.
In the above example, the MAC address appears as part of the message field – it is not a tag. In the
following example, the tags are enabled. Even though MAC address is duplicated between the tag and
the message, it is acceptable.
11: host.cisco.com: Jun 13 2003 23:11:52.454 UTC: %BACC-3-BAD_REQUEST:
%[mac=1,6,aa:bb:11:22:33:aa][tid=thread1][txn=mytxn123]: Bad request received from
device [1,6,aa:bb:11:22:33:aa]. Missing header.
Process Identification Tag
One of the standard tags, pname.orig, is used to identify the logical process name which originates the
message. Any application that seeks to provide originating process information must do so using the
“pname.orig” tag.
This tag is extremely valuable in addition to information in the APPNAME field because some
applications consist of multiple processes, each of which may originate logging messages. It is
recommended that any application which consists of multiple processes always provide the
“pname.orig” tag.
MESSAGE Field
The MESSAGE field provides a descriptive message about the logging event. This field may consist of
one or more characters. The character set is limited to printable US ASCII characters (ASCII decimal
values 32-126) and foreign language characters.
Use of non-printable (control) ASCII characters is not permitted in the MESSAGE field. Control
characters include characters with ASCII decimal values 0-31 and 127. If application provides a
CiscoLog-compliant library with message string, which includes one or more control characters, the
logging library must do the following. If the horizontal tab character (ASCII decimal value 9) is
encountered, it must be replaced with one or more space characters (ASCII decimal value 32). Eight
spaces per tab are recommended because this is a convention on most Unix and Windows platforms.
Other control characters must each be replaced with a question mark character (ASCII decimal value
63).
The maximum length of the MESSAGE field is constrained only by the maximum length of the entire
message. The maximum length of the CiscoLog message must not exceed 800 octets. Another practical
limitation is a potentially highly variable length of the TAGS field.
Message text may contain substitutable parameters, which provide necessary details about the message.
For example, the IP address in the following example is a substitutable parameter.
11: host.cisco.com: Jun 13 2003 23:11:52.454 UTC: %BACC-3-INVALID_REQUEST: Invalid
request received from device [1.22.111.222]. Missing header.
It is recommended (but not required) that substitutable parameters be surrounded by bracket characters
“[“ and “]” as in the above example. It is further recommended that the message text and values of
substitutable parameters do not include bracket characters. When it is not possible to avoid brackets