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

Cisco Unified Serviceability Alarms and CiscoLog Messages Chapter 6 Cisco Unified Serviceability Alarms and CiscoLog Messages TAGS Field Both numeric-only or alphanumeric message names are acceptable. However, per IOS convention, it is recommended that a user-friendly alphanumeric label be preferred to a numeric-only label. For example, "NO_MEMORY" message name is preferred to a "341234" identifier. A special tag mid is defined in the CiscoLog Standard Tags specification for identifying a numeric id corresponding to a message name. This tag can be used to provide a numeric message is in addition to the MSGNAME. When this tag is used, a given MSGNAME must always correspond to a single message id value. CiscoLog defines mid tag values for each standard message. The length of the MSGNAME field must not exceed 30 characters, but most message names should be more concise. MSGNAME value may not conflict with the names defined in this standard. A separate message name must be defined for each logically different message. In other words, while the message text for a given message name can vary by virtue of some substitutable parameters, logically different messages must have different message names. The following is an example of correct use of message name: 11: host.cisco.com: Jun 13 2003 23:11:52.454 UTC: %BACC-4-CONNECTION_LOST: %[pname.orig=rdu]: Server lost connection to host [1.1.1.1] 12: host.cisco.com: Jun 13 2003 23:11:52.458 UTC: %BACC-4-CONNECTION_LOST: %[pname.orig=rdu]: Server lost connection to host [2.2.2.2] Notice that while the IP address of the host changes, it is still logically the same type of message. The following is an example of an INCORRECT use of the message name: 15: host.cisco.com: Jun 13 2003 23:11:52.458 UTC: %BACC-4-CONNECTION: %[pname.orig=rdu]: Server lost connection to host [2.2.2.2] 16: host.cisco.com: Jun 13 2003 23:11:52.468 UTC: %BACC-4-CONNECTION: %[pname.orig=rdu]: Server re-established connection to host [2.2.2.2] The use of a single message name for two different events in the above example is wrong and unacceptable. This is referred to as a "catch-all" message name and they must be avoided. Another extreme example is defining a message named "ERROR" and providing all error log messages under the same message name. This defeats the purpose of having the message name field, which is to enable external filtering of messages or easily trigger actions. The only exception to the "no-catch-all" rule is when message cannot be identified ahead of time with anything better than a generic description or the users will not benefit from distinguishing the various subtypes of the message. Although some applications may choose to do so, there is generally no need to define a separate message name for all debugging messages because debugging messages are not intended for automated filtering and action triggering based on message name. The sheer number of debugging messages and the highly dynamic nature of what is produced in them makes it very hard to define separate messages. This specification proposes establishing a mailing list that could be used by groups for consulting purposes when in doubt about how to define certain messages. Currently, the mailing list alias used for this purpose is "cmn-logging". The TAGS field is optional in the message format. It provides a standard mechanism for applications to provide structured content in the form of key-value pairs which can be used to categorize or filter a set of messages externally. Tags can be used to identify virtual logging channels. A set of messages flagged with the same tag can later be grouped together. For example, an application may flag messages belonging to a particular thread by supplying the corresponding tag. This would then allow filtering and viewing messages based on threads. 6-14 Cisco Unified Communications Manager Managed Services Guide OL-22523-01