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

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

6-15
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
Virtual logging channels can also be established across multiple applications. For example, if all
applications could tag requests from a device with device id (mac, ip, etc), then it would be easy to filter
all messages related to that device even thought it communicates with multiple components.
Each application may define its own set of supported tags. A single tag consists of key and value pair
separated by the equals sign and surrounded by square bracket characters as in the following format:
[KEY=VALUE]. This is an example of a valid tag key-value pair [ip=123.23.22.22].
The TAGS field is prefixed with a percent character (ASCII decimal value 37) and ends with a sequence
of colon and space characters (ASCII decimal values 58 and 32). When multiple tags are assembled
together, no characters should appear between the tags as separators. The following example has a
complete CiscoLog message with four tags:
12: host.cisco.com: Jun 13 2003 23:11:52.454 UTC: %BACC-4-BAD_REQUEST:
%[pname.orig=rdu][comp=parser][mac=1,6,aa:bb:cc:11:22:33][txn=mytxn123]: Bad request
received from device [1,6,aa:bb:cc:11:22:33]. Missing header.
If TAGS field is missing, the percent character prefix and the trailing colon and space must be omitted.
Thus, when the TAGS field is missing, the HEADER and MESSAGE fields must be separated by just a
single colon and a space which follows the HEADER field. For example:
12: host.cisco.com: Jun 13 2003 23:11:52.454 UTC: %BACC-4-BAD_REQUEST: Bad request
received from device [1,6,aa:bb:cc:11:22:33]. Missing header.
Multiple tags with the same tag key can be provided in the same message. This essentially provides the
capability for handling multi-valued keys. Below is an example of a message produced from a device
which has two IP addresses where the application chose to provide both IP addresses in the TAGS field
as well as the process name:
12: host.cisco.com: Jun 13 2003 23:11:52.454 UTC: %BACC-4-BAD_REQUEST:
%[pname.orig=rdu][ip.orig=1.1.1.1][ip.orig=1.1.1.2]: Bad request received from device
[1,6,aa:bb:cc:11:22:33]. Missing header.
Any number of tags can be provided in a given message. The only limit is the overall length limit of the
CiscoLog message of 800 octets.
If multiple tags are present, it is recommended that they appear in the alphanumeric order of the keys.
This insures that tags are always produced in the same order. However, a different order may be chosen
by an application if the order of tags is used to communicate some semantic value.
Tag Keys
Tag key must contain at least one character. The characters are limited to ASCII characters with decimal
values 48-57 (numbers), 65-90 (upper-case letters), 95 (underscore), 97-122 (lower case letters). Use
of lower-case letters is recommended. There is no strict limit on tag key length, although a general
message limit of 800 octets applies and dictates that one should attempt to define short tag key names.
Tag Semantic Extensions
In some cases, a tag can have a standard value syntax, but different meaning depending on the content
in which it is used. Tag semantic extensions are used to differentiate the contextual meaning of tags.
The semantic extension tags are created by appending the tag key with a single dot character (ASCII
decimal value 46) and a text string consisting of characters from a proper character set.
For example, an “ip” tag defines syntax for an IP address representation, but no semantic value. An “ip”
tag found in a CiscoLog message generally means only that this IP address is somehow related to the
message. In some cases, such vague association is sufficient. However, sometimes, communicating
semantic value could be useful.