Cisco MCS-7825-H3-IPC1 Service Guide - Page 251

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 OL-22523-01 Cisco Unified Communications Manager Managed Services Guide 6-17