Header
Cisco Log
formatted log entries include a more comprehensive header compared to DUMPLOG
standard format.
DumpLog
Standard Format
Standard formatted
DUMPLOG entries display the following fields:
<TIMESTAMP> <COMPONENT-PROCESS> <MESSAGE>
The timestamp is
represented as a 24-hour value (hh:mm:ss). It does not include the date, which
appears on a separate line at the beginning of the file and when a new day
starts. For example:
Events from February 8, 2007
00:37:44 ra-rtr MDS is in service.
Cisco Log
Format
Cisco Log
formatted DUMPLOG entries display the following fields:
<SEQNUM>: <HOST>: <TIMESTAMP> <TIMEZONE>: %APPNAME: %<TAGS>:<MESSAGE>
Example DUMPLOG message
Below is an example of a Cisco Log formatted DUMPLOG message. An actual log entry appears on a single line.
10: CICMRGRA: Feb 8 2007 05:37:44.658 +0000: %ICM_Router_ProcessSynchronization: [comp=Router-A]
[pname=rtr][iid=acme][sev=info]: MDS is in service.
Note |
The contents of the APPNAME and TAGS fields differ from those previously described in section 5.1.
|
Table 30. APPNAME and TAGS Used in DUMPLOG Trace Output
Field
|
Description
|
APPNAME
|
PRODUCT_COMPONENT_MESSAGECATEGORY
- PRODUCT - always ICM
- COMPONENT – such as Router
- MESSAGECATEGORY – such as ProcessSynchronization
|
TAGS
|
Acceptable tags are:
- [comp=%s] - component name including side, such as Router A
- [pname=%s] - process name, such as rtr
- [iid=%s] - instance name, such as acme
- [sev=%s] – severity, such as info
- and optionally [part=%1.%2/%3], which is used only for multi-line entries as described later in this section.
|
Timestamp
The timestamp
displayed in DUMPLOG standard format is in local time relative to the server on
which DUMPLOG is run. The timestamp displayed in Cisco Log format is in GMT
time independent of the server on which DUMPLOG is run.
Note |
Date/time options
specified on the command line are entered in local time, regardless of whether
the Cisco Log option is selected. Therefore, timestamps displayed as part of
the Cisco Log formatted entry might appear to be outside of the date/time range
selected.
|
Multi-line Entries
The message portion of some DUMPLOG entries might contain one or more embedded new line characters ('\n'), which cause the
messages to appear on multiple lines and might also include blank lines. This is especially true for entries that contain
statistics.
For a DUMPLOG standard formatted message, only the first line contains the header field as shown in the following example:
00:36:09 ra-nm ICM\acme\RouterA node reporting process statistics for process ccag.
Process name: ccag
Process status: A
Process ID: 6c0
Number of times process started: 1
Last start time: 00:35:31 2/8/2007
Pings completed in zero time: 0
Pings completed in first third: 0
Total first third milliseconds: 0
Pings completed in second third: 0
Total second third milliseconds: 0
Pings completed in third third: 0
Total third third milliseconds: 0
Longest Ping time: 0
For a Cisco Log formatted message, each line contains a separate header. In the example below, however, each entry spans several
lines due to page size constraints.
19: CICMRGRA: Feb 8 2007 05:36:09.890 +0000: %ICM_Router_unknown: [comp=Router-A][pname=nm][iid=acme]
[sev=info][part=19.1/14]: ICM\acme\RouterA node reporting process statistics for process ccag.
20: CICMRGRA: Feb 8 2007 05:36:09.890 +0000: %ICM_Router_unknown: [comp=Router-A][pname=nm][iid=acme]
[sev=info][part=19.2/14]: Process name: ccag
21: CICMRGRA: Feb 8 2007 05:36:09.890 +0000: %ICM_Router_unknown: [comp=Router-A][pname=nm][iid=acme]
[sev=info][part=19.3/14]: Process status ACTIVE
22: CICMRGRA: Feb 8 2007 05:36:09.890 +0000: %ICM_Router_unknown: [comp=Router-A][pname=nm][iid=acme]
[sev=info][part=19.4/14]: Process ID 6c0
23: CICMRGRA: Feb 8 2007 05:36:09.890 +0000: %ICM_Router_unknown: [comp=Router-A][pname=nm][iid=acme]
[sev=info][part=19.5/14]: Number of times process started 1
24: CICMRGRA: Feb 8 2007 05:36:09.890 +0000: %ICM_Router_unknown: [comp=Router-A][pname=nm][iid=acme]
[sev=info][part=19.6/14]: Last start time: 00:35:31 2/8/2007
25: CICMRGRA: Feb 8 2007 05:36:09.890 +0000: %ICM_Router_unknown: [comp=Router-A][pname=nm][iid=acme]
[sev=info][part=19.7/14]: Pings completed in zero time: 0
26: CICMRGRA: Feb 8 2007 05:36:09.890 +0000: %ICM_Router_unknown: [comp=Router-A][pname=nm][iid=acme]
[sev=info][part=19.8/14]: Pings completed in first third: 0
27: CICMRGRA: Feb 8 2007 05:36:09.890 +0000: %ICM_Router_unknown: [comp=Router-A][pname=nm][iid=acme]
[sev=info][part=19.9/14]: Total first third milliseconds: 0
28: CICMRGRA: Feb 8 2007 05:36:09.890 +0000: %ICM_Router_unknown: [comp=Router-A][pname=nm][iid=acme]
[sev=info][part=19.10/14]: Pings completed in second third: 0
29: CICMRGRA: Feb 8 2007 05:36:09.890 +0000: %ICM_Router_unknown: [comp=Router-A][pname=nm][iid=acme]
[sev=info][part=19.11/14]: Total second third milliseconds: 0
30: CICMRGRA: Feb 8 2007 05:36:09.890 +0000: %ICM_Router_unknown: [comp=Router-A][pname=nm][iid=acme]
[sev=info][part=19.12/14]: Pings completed in third third: 0
31: CICMRGRA: Feb 8 2007 05:36:09.890 +0000: %ICM_Router_unknown: [comp=Router-A][pname=nm][iid=acme]
[sev=info][part=19.13/14]: Total third third milliseconds: 0
32: CICMRGRA: Feb 8 2007 05:36:09.890 +0000: %ICM_Router_unknown: [comp=Router-A][pname=nm][iid=acme]
[sev=info][part=19.14/14]: Longest Ping Time: 0
To differentiate each line in the entry, the part tag is added to each header:
[part=#1.#2/#3]
Where:
#1 = the sequence number of the first line (this is the same for all lines in the entry)
#2 = the part number of the specific line
#3 = the total number of parts in the entry
Note the line beginning with sequence number 32, where [part=19.14/14]
:
#1 = 19. #2 = 14 / #3 = 14
Note |
The log files are zipped according to the parameters specified in the EMS registry settings. While dumping the logs, if one
log file transitions to the next log file very quickly, then do one of the following to avoid an error:
|
Note |
Collecting logs on the UCCE system using dumplog utility impacts CPU and disk utilization. Running dumplog simultaneously
on multiple VMs sharing the same disk can cause problems for the disk during peak busy hour if system resources are being
stretched near the system limits for BHCA.
For information about system limits for busy hour call attempts (BHCA), see Solution Design Guide for
Cisco Unified Contact Center Enterprise at https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-implementation-design-guides-list.html.
Some possible workaround include:
-
Saving off EMS zip files, and dumping them on an idle system.
-
Using System CLI which runs at a lower system priority.
-
Serialize dumplog log collection by taking the logs that are likely to wrap first.
|