-
Cisco IOS XR System Monitoring Configuration Guide, Release 3.7
-
Preface
-
Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software
-
Configuring and Managing Embedded Event Manager Policies on Cisco IOS XR Software
-
IP Service Level Agreements on Cisco IOS XR Software
-
Implementing Logging Services on Cisco IOS XR Software
-
Onboard Failure Logging on Cisco IOS XR Software
-
Implementing Performance Management on Cisco IOS XR Software
-
Index
-
Table Of Contents
Implementing Logging Services on Cisco IOS XR Software
Prerequisites for Implementing Logging Services on Cisco IOS XR Software
Information About Implementing Logging Services on Cisco IOS XR Software
Format of System Logging Messages
Interruption of Message Suppression
Logging History and Syslog Comparison
Guidelines for Sending Syslog Messages to Destinations Other Than the Console
Logging for the Current Terminal Session
Syslog Messages Sent to Syslog Servers
UNIX System Logging Facilities
UNIX Syslog Daemon Configuration
Archiving Logging Messages on a Local Storage Device
Syslog Message Severity Level Definitions
Syslog Severity Level Command Defaults
How to Implement Logging Services on Cisco IOS XR Software
Setting Up Destinations for System Logging Messages
Configuring Logging to a Remote Server
Configuring the Settings for the Logging History Table
Modifying Logging to the Console Terminal and the Logging Buffer
Modifying the Format of Time Stamps
Suppressing Duplicate Syslog Messages
Disabling the Logging of Link-Status Syslog Messages
Displaying System Logging Messages
Archiving System Logging Messages to a Local Storage Device
Configuration Examples for Implementing Logging Services on Cisco IOS XR Software
Configuring Logging to the Console Terminal and the Logging Buffer: Example
Setting Up Destinations for Syslog Messages: Example
Configuring the Settings for the Logging History Table: Example
Modifying Time Stamps: Example
Configuring a Logging Archive: Example
Implementing Logging Services on Cisco IOS XR Software
The Cisco IOS XR software provides basic logging services. Logging services provide a means to gather logging information for monitoring and troubleshooting, to select the type of logging information captured, and to specify the destinations of captured system logging (syslog) messages.
This module describes the new and revised tasks you need to implement logging services on your Cisco IOS XR network.
Note
For more information about logging services on the Cisco IOS XR software and complete descriptions of the logging commands listed in this module, see the "Related Documents" section of this module. To locate documentation for other commands that might appear in the course of running a configuration task, search online in the Cisco IOS XR software master command index.
Feature History for Implementing Logging Services on Cisco IOS XR Software Contents
Contents
•
•
•
•
Prerequisites for Implementing Logging Services on Cisco IOS XR Software
The following prerequisites are required to implement logging services in your network operating center (NOC):
•
•
Information About Implementing Logging Services on Cisco IOS XR Software
To implement logging services, you need to understand the following concepts:
•
•
•
•
•
System Logging Process
By default, routers are configured to send syslog messages to a syslog process. The syslog process controls the distribution of messages to the destination of syslog messages such as the logging buffer, terminal lines, or a syslog server. The syslog process also sends messages to the console terminal by default.
Note
Format of System Logging Messages
By default, the general format of syslog messages generated by the syslog process on the Cisco IOS XR software is as follows:
node-id:timestamp : process-name [pid] : %message-group-severity-message-code : message-text
The following is a sample syslog message:
RP/0/0/CPU0:Nov 28 23:56:53.826 : config[65710]: %SYS-5-CONFIG_I : Configured from console by consoleTable 1 describes the general format of syslog messages on Cisco IOS XR software.
Table 1 General Syslog Message Format
node-id
Node from which the syslog message originated.
timestamp
Time stamp in the form month day HH:MM:SS, indicating when the message was generated.
Note
process-name
Process that generated the syslog message.
[pid]
Process ID (pid) of the process that generated the syslog message.
%message-group-severity-message-code
Message group name, severity, and message code associated with the syslog message.
message-text
Text string describing the syslog message.
Duplicate Message Suppression
Suppressing duplicate messages, especially in a large network, can reduce message clutter and simplify the task of interpreting the log. The duplicate message suppression feature substantially reduces the number of duplicate event messages in both the logging history and the syslog file. The suppression and logging process is the same for logging history and for external syslog servers.
When duplicate message suppression is enabled, two types of events are handled differently:
•
New messages are always logged immediately.
•
Repeated messages are subject to suppression (See Message Suppression). The suppression of repeated messages is interrupted when a new message occurs (see Interruption of Message Suppression).
For information about configuring this feature, see the "Suppressing Duplicate Syslog Messages" section.
Message Suppression
The first occurrence of an event is always logged immediately, but subsequent identical messages are suppressed during three different time intervals. Initially, duplicate messages are suppressed for 30 seconds after the first event, then for 120 seconds, and finally every 600 seconds (10 minutes). At the end of each interval, the next identical event triggers the "last message repeated nn times" message, and resets the count of duplicate messages. The end of the interval does not automatically trigger a message, so the summary message can be delayed well beyond the suppression interval.
For example, the following syslog excerpt shows the log entries for repeated Telnet failures when the suppress duplicate feature s is enabled. In this case, Telnet failures occur at the rate of four per minute:
Jul 24 09:39:10 [10.1.1.1.2.2] 326: ROUTER-TEST RP/0/0/CPU0:Jul 24 00:24:45.113 : TELNETD_[65778]: %IP-TELNETD-3-ERR_CONNECT : Failed to obtain a VTY for a session: ''tty-server' detected the 'resource not available' condition 'There are no TTYs availableJul 24 09:39:45 [10.1.1.1.2.2] 333: ROUTER-TEST last message repeated 2 timesJul 24 09:41:50 [10.1.1.1.2.2] 358: ROUTER-TEST last message repeated 8 timesJul 24 09:52:04 [10.1.1.1.2.2] 391: ROUTER-TEST last message repeated 40 timesJul 24 10:02:35 [10.1.1.1.2.2] 412: ROUTER-TEST last message repeated 40 timesThe first Telnet failure was logged at 9:39 as a normal error message. Thirty seconds later, a summary message reports two repetitions. Then after another 120 seconds, another message reports eight more repetitions. Finally, two more messages report the 40 repetitions that occurred in two consecutive 600 second intervals. Because the errors are occurring at regular 15-second intervals, a new error triggers a summary message just after the end of a suppression interval. The end of a suppression interval itself does not trigger a message.
Interruption of Message Suppression
The sequence of suppression intervals is interrupted if a different event occurs. The first occurrence of all new events is always logged immediately, so a new event aborts the current suppression interval and immediately triggers the repeated message summary, followed by the new event message. This clears the message queue, so another message from the previous sequence is then treated as a new event, and the suppression sequence starts over.
The following syslog excerpt shows how a new commit message interrupts a repeated sequence of Telnet failures:
Jul 24 13:52:50 [10.1.1.1.2.2] 442: ROUTER-TEST RP/0/0/CPU0:Jul 24 04:38:19.208 : TELNETD_[65778]: %IP-TELNETD-3-ERR_CONNECT : Failed to obtain a VTY for a session: ...Jul 24 13:53:34 [10.1.1.1.2.2] 445: ROUTER-TEST last message repeated 2 timesJul 24 13:55:50 [10.1.1.1.2.2] 454: ROUTER-TEST last message repeated 8 timesJul 24 13:57:53 [10.1.1.1.2.2] 462: ROUTER-TEST last message repeated 7 timesJul 24 13:57:53 [10.1.1.1.2.2] 462: ROUTER-TEST RP/0/0/CPU0:Jul 24 04:43:22.867 : config[65677]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user ...Jul 24 13:58:04 [10.1.1.1.2.2] 463: ROUTER-TEST RP/0/0/CPU0:Jul 24 04:43:33.769 : TELNETD_[65778]: %IP-TELNETD-3-ERR_CONNECT : Failed to obtain a VTY for a session: ...This log begins like the log in the previous example; however during the first 600-second interval, a new commit message occurs, which triggers an immediate message showing the number of repeated messages counted so far, followed by the new commit message. A subsequent Telnet failure is then logged as if it were the first occurrence of a new event.
Logging History and Syslog Comparison
The logging process with suppression is the same for logging history and for external syslog servers. Both suppress duplicate messages using a sequence of suppression intervals. The following example shows an excerpt from the show logging history command for the example shown in the "Interruption of Message Suppression" section.
RP/0/0/CPU0:Jul 24 04:38:19.208 : TELNETD_[65778]: %IP-TELNETD-3-ERR_CONNECT : ...last message repeated 2 timeslast message repeated 8 timeslast message repeated 7 timesRP/0/0/CPU0:Jul 24 04:43:22.867 : config[65677]: %MGBL-CONFIG-6-DB_COMMIT : ...RP/0/0/CPU0:Jul 24 04:43:33.769 : TELNETD_[65778]: %IP-TELNETD-3-ERR_CONNECT : ...The logging history and syslog entries are the same in this case, but they can be different under other conditions. They can differ because of the severity level configured for each type of log and because of the timing of the log messages. Also, if there are just a few repeated messages that occur in less than 30 seconds, the reporting of duplicates can seem to be suppressed altogether. These duplicates ultimately are reported however, just before the next new event is logged.
Syslog Message Destinations
Syslog message logging to the console terminal is enabled by default. To disable logging to the console terminal, use the no logging console command in global configuration mode. To reenable logging to the console terminal, use the logging console command in global configuration mode.
Syslog messages can be sent to destinations other than the console, such as the logging buffer, syslog servers, and terminal lines other than the console (such as vtys). Table 2 lists the commands used to specify syslog destinations.
The logging buffered command copies logging messages to the logging buffer. The buffer is circular, so newer messages overwrite older messages after the buffer is full. To display the syslog messages that are logged in the logging buffer, use the show logging command. The first message displayed is the oldest message in the buffer. To clear the current contents of the logging buffer, use the clear logging command. To disable logging to the logging buffer, use the no logging buffered command in global configuration mode.
The logging command identifies a syslog server host to receive logging messages. By issuing this command more than once, you build a list of syslog servers that receive logging messages. To delete the syslog server with the specified IP address or hostname from the list of available syslog servers, use the no logging command in global configuration mode.
The logging monitor command globally enables the logging of syslog messages to terminal lines other than the console, such as vtys. To disable logging to terminal lines other than the console, use the no logging monitor command in global configuration mode.
Guidelines for Sending Syslog Messages to Destinations Other Than the Console
The logging process sends syslog messages to destinations other than the console terminal and the process is enabled by default. Logging is enabled to the logging buffer, terminal lines and syslog servers.
Logging for the Current Terminal Session
The logging monitor command globally enable the logging of syslog messages to terminal lines other than console terminal. Once the logging monitor command is enabled, use the terminal monitor command to display syslog messages during a terminal session.
To disable the logging of syslog messages to a terminal during a terminal session, use the terminal monitor disable command in EXEC mode.The terminal monitor disable command disables logging for only the current terminal session.
To reenable the logging of syslog messages for the current terminal session, use the terminal monitor command in EXEC mode.
Note
Syslog Messages Sent to Syslog Servers
The Cisco IOS XR software provides the following features to help manage syslog messages sent to syslog servers:
•
•
•
UNIX System Logging Facilities
You can configure the syslog facility in which syslog messages are sent by using the logging facility command. Consult the operator manual for your UNIX operating system for more information about these UNIX system facilities. The syslog format is compatible with Berkeley Standard Distribution (BSD) UNIX version 4.3.
Table 3 describes the facility type keywords that can be supplied for the type argument.
Hostname Prefix Logging
To help manage system logging messages sent to syslog servers, Cisco IOS XR software supports hostname prefix logging. When enabled, hostname prefix logging appends a hostname prefix to syslog messages being sent from the router to syslog servers. You can use hostname prefixes to sort the messages being sent to a given syslog server from different networking devices.
To append a hostname prefix to syslog messages sent to syslog servers, use the logging hostname command in global configuration mode.
Syslog Source Address Logging
By default, a syslog message contains the IP address of the interface it uses to leave the router when sent to syslog servers. To set all syslog messages to contain the same IP address, regardless of which interface the syslog message uses to exit the router, use the logging source-interface command in global configuration mode.
UNIX Syslog Daemon Configuration
To configure the syslog daemon on a 4.3 BSD UNIX system, include a line such as the following in the /etc/syslog.conf file:
local7.debug /usr/adm/logs/cisco.logThe debugging keyword specifies the syslog level; see Table 7 for a general description of other keywords. The local7 keyword specifies the logging facility to be used; see Table 3 for a general description of other keywords.
The syslog daemon sends messages at this level or at a more severe level to the file specified in the next field. The file must already exist, and the syslog daemon must have permission to write to it.
Archiving Logging Messages on a Local Storage Device
Syslog messages can also be saved to an archive on a local storage device, such as the hard disk or a flash disk. Messages can be saved based on severity level, and you can specify attributes such as the size of the archive, how often messages are added (daily or weekly), and how many total weeks of messages the archive will hold.
Setting Archive Attributes
To create a logging archive and specify how the logging messages will be collected and stored, use the logging archive command in global configuration mode. The logging archive command enters the logging archive submode where you can configure the attributes for archiving syslogs. Table 4 lists the commands used to specify the archive attributes once you are in the logging archive submode.
Table 4 Commands Used to Set Syslog Archive Attributes
archive-length weeks
Specifies the maximum number of weeks that the archive logs are maintained in the archive. Any logs older than this number are automatically removed from the archive.
archive-size size
Specifies the maximum total size of the syslog archives on a storage device. If the size is exceeded then the oldest file in the archive is deleted to make space for new logs.
device {disk0 | disk1 | harddisk}
Specifies the local storage device where syslogs are archived. By default, the logs are created under the directory <device>/var/log. If the device is not configured, then all other logging archive configurations are rejected. We recommend that syslogs be archived to the harddisk because it has more capacity than flash disks.
file-size size
Specifies the maximum file size (in megabytes) that a single log file in the archive can grow to. Once this limit is reached, a new file is automatically created with an increasing serial number.
frequency {daily | weekly}
Specifies if logs are collected on a daily or weekly basis.
severity severity
Specifies the minimum severity of log messages to archive. All syslog messages greater than or equal to this configured level are archived while those lesser than this are filtered out. See the "Severity Levels" section for more information.
Archive Storage Directories
By default, syslog archives are stored in the directory <device>/var/log. Individual archive files are saved to sub directories based on the year, month, and day the archive was created. For example, archive files created on February 26, 2006 are stored in the following directory:
harddisk:/var/log/2006/02/26Severity Levels
You can limit the number of messages sent to a logging destination by specifying the severity level of syslog messages sent to a destination (see Table 7 for severity level definitions). Table 5 lists the commands used to control the severity level of syslog messages.
The logging buffered, logging console, logging monitor, and logging traps commands limit syslog messages sent to their respective destinations to messages with a level number at or below the specified severity level, which is specified with the severity argument.
Note
Logging History Table
If you have enabled syslog messages traps to be sent to a Simple Network Management Protocol (SNMP) network management station (NMS) with the snmp-server enable traps syslog command, you can change the level of messages sent and stored in a history table on the router. You can also change the number of messages that get stored in the history table.
Messages are stored in the history table, because SNMP traps are not guaranteed to reach their destination. By default, one message of the level warning and above (see Table 7) is stored in the history table even if syslog traps are not enabled.
Table 6 lists the commands used to change the severity level and table size defaults of the logging history table.
Note
Syslog Message Severity Level Definitions
Table 7 lists the severity level keywords that can be supplied for the severity argument and corresponding UNIX syslog definitions in order from the most severe level to the least severe level.
Syslog Severity Level Command Defaults
Table 8 lists the default severity level settings for the commands that support the severity argument.
How to Implement Logging Services on Cisco IOS XR Software
This section contains the following procedures:
•
•
•
•
•
•
•
•
•
Setting Up Destinations for System Logging Messages
This task explains how to configure logging to destinations other than the console terminal.
For conceptual information, see the "Syslog Message Destinations" section.
SUMMARY STEPS
1.
2.
3.
4.
or
commit5.
DETAILED STEPS
Configuring Logging to a Remote Server
This task explains how to configure logging to remote syslog servers.
Prerequisites
You must have connectivity with syslog servers to configure syslog server hosts as the recipients for syslog messages.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
or
commitDETAILED STEPS
Configuring the Settings for the Logging History Table
This task explains how to configure the settings for the logging history table.
For conceptual information, see the "Severity Levels" section.
Prerequisites
Logging of messages to an SNMP NMS is enabled by the snmp-server enable traps syslog command. For more information about SNMP, see the "Related Documents" section of this module.
SUMMARY STEPS
1.
2.
3.
4.
or
commit5.
DETAILED STEPS
Modifying Logging to the Console Terminal and the Logging Buffer
This task explains how to modify logging configuration for the console terminal and the logging buffer.
Note
SUMMARY STEPS
1.
2.
3.
4.
or
commitDETAILED STEPS
Modifying the Format of Time Stamps
This task explains how to modify the time-stamp format for syslog and debugging messages.
SUMMARY STEPS
1.
2.
or
service timestamps log uptime3.
or
service timestamps debug uptime4.
or
commitDETAILED STEPS
Disabling Time Stamps
This tasks explains how to disable the inclusion of time stamps in syslog messages.
SUMMARY STEPS
1.
2.
or
no service timestamps [debug | log] [datetime [localtime] [msec] [show-timezone]] | uptime]3.
or
commitDETAILED STEPS
Suppressing Duplicate Syslog Messages
This task explains how to suppress the consecutive logging of duplicate syslog messages.
SUMMARY STEPS
1.
2.
3.
or
commitDETAILED STEPS
Disabling the Logging of Link-Status Syslog Messages
This task explains how to disable the logging of link-status syslog messages for logical and physical links.
When the logging of link-status messages is enabled, the router can generate a high volume of link-status updown syslog messages. Disabling the logging of link-status syslog messages reduces the number of messages logged.
SUMMARY STEPS
1.
2.
3.
or
commitDETAILED STEPS
Displaying System Logging Messages
This task explains how to display the syslog messages stored in the logging buffer.
Note
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Examples
In this example, the output displays all syslog messages stored in the logging buffer:
RP/0/0/CPU0:router# show loggingSyslog logging: enabled (20 messages dropped, 0 flushes, 0 overruns)Console logging: level debugging, 45 messages loggedMonitor logging: level debugging, 0 messages loggedTrap logging: level informational, 10 messages loggedLogging to 172.19.72.224, 10 message lines loggedBuffer logging: level debugging, 30 messages loggedLog Buffer (16384 bytes):RP/0/0/CPU0:Dec 3 10:28:24.245 : wdsysmon[296]: %HA_WD-4-DISK_ALARM : A monitored disk is above 80% utilization. Please remove unwanted user files and configuration rollback points.RP/0/0/CPU0:Dec 3 10:28:24.247 : wdsysmon[296]: %HA_WD-6-DISK_USAGE : /disk0: usage 88%RP/0/0/CPU0:Dec 3 10:28:31.247 : lrd[215]: LRd waited 40 seconds for inventory... rc = 1082230272 nCount = -1...In this example, the output displays s syslog messages stored in the logging buffer that originated from node 0/0/CPU0:
RP/0/0/CPU0:router# show logging location 0/0/CPU0Syslog logging: enabled (20 messages dropped, 0 flushes, 0 overruns)Console logging: level debugging, 45 messages loggedMonitor logging: level debugging, 0 messages loggedTrap logging: level informational, 10 messages loggedLogging to 172.19.72.224, 10 message lines loggedBuffer logging: level debugging, 30 messages loggedLog Buffer (16384 bytes):RP/0/0/CPU0:Dec 3 10:28:24.245 : wdsysmon[296]: %HA_WD-4-DISK_ALARM : A monitored disk is above 80% utilization. Please remove unwanted user files and configuration rollback points.RP/0/0/CPU0:Dec 3 10:28:24.247 : wdsysmon[296]: %HA_WD-6-DISK_USAGE : /disk0: usage 88%RP/0/0/CPU0:Dec 3 10:28:31.247 : lrd[215]: LRd waited 40 seconds for inventory... rc = 1082230272 nCount = -1RP/0/0/CPU0:Dec 3 10:30:35.068 : locald[210]: %LOCALD-3-ROOT_USERDB_INIT_FAIL : Failed to create aaa directory: File existsRP/0/0/CPU0:Dec 3 10:30:41.023 : config[129]: %CONFIGCLI-7-INFRA_READY : Infrastructure not ready to consume configuration.RP/0/0/CPU0:Dec 3 10:31:10.504 : sip[252]: sxa_iox_chkpt_init 154 SIP-LOG: SIP started - performing a cold start....In this example, the output displays syslog messages stored in the logging buffer that were related to the wdsysmon process:
RP/0/0/CPU0:router# show logging process wdsysmonSyslog logging: enabled (20 messages dropped, 0 flushes, 0 overruns)Console logging: level debugging, 45 messages loggedMonitor logging: level debugging, 0 messages loggedTrap logging: level informational, 10 messages loggedLogging to 172.19.72.224, 10 message lines loggedBuffer logging: level debugging, 30 messages loggedLog Buffer (16384 bytes):RP/0/0/CPU0:Dec 3 10:28:24.245 : wdsysmon[296]: %HA_WD-4-DISK_ALARM : A monitored disk is above 80% utilization. Please remove unwanted user files and configuration rollback points.RP/0/0/CPU0:Dec 3 10:28:24.247 : wdsysmon[296]: %HA_WD-6-DISK_USAGE : /disk0: usage 88%LC/0/2/CPU0:wdsysmon[186]: %HA_WD-6-MEMORY_RECOVERY_DISABLED : Node physical memory 256MBLC/0/7/CPU0:wdsysmon[186]: %HA_WD-6-MEMORY_RECOVERY_DISABLED : Node physical memory 256MBLC/0/6/CPU0:wdsysmon[186]: %HA_WD-6-MEMORY_RECOVERY_DISABLED : Node physical memory 256MB...In this example, the output displays syslog messages stored in the logging buffer that contained the string MgmtEth:
RP/0/0/CPU0:router# show logging string MgmtEthSyslog logging: enabled (20 messages dropped, 0 flushes, 0 overruns)Console logging: level debugging, 45 messages loggedMonitor logging: level debugging, 0 messages loggedTrap logging: level informational, 10 messages loggedLogging to 172.19.72.224, 10 message lines loggedBuffer logging: level debugging, 30 messages loggedLog Buffer (16384 bytes):RP/0/0/CPU0:Dec 3 10:32:15.608 : ifmgr[171]: %LINK-3-UPDOWN : Interface MgmtEth0/0/CPU0/0, changed state to DownRP/0/0/CPU0:Dec 3 10:32:15.642 : ifmgr[171]: %LINK-3-UPDOWN : Interface MgmtEth0/0/CPU0/0, changed state to Up...In this example, the output displays syslog messages stored in the logging buffer that were logged on or after 11:00 on December 3:
RP/0/0/CPU0:router# show logging start december 3 11:00:00Syslog logging: enabled (20 messages dropped, 0 flushes, 0 overruns)Console logging: level debugging, 45 messages loggedMonitor logging: level debugging, 0 messages loggedTrap logging: level informational, 10 messages loggedLogging to 172.19.72.224, 10 message lines loggedBuffer logging: level debugging, 30 messages loggedLog Buffer (16384 bytes):RP/0/0/CPU0:Dec 3 11:48:44.513 : sysmgr[76]: sip(1) (jid 252) abnormally terminated, restart scheduledRP/0/0/CPU0:Dec 3 11:48:48.431 : sip[252]: sxa_iox_chkpt_init 130 SIP-LOG: SIP restart - warm start - 2 sessions so far.LC/0/5/CPU0:Dec 3 13:28:19.070 : DI_Partner[50]: %SONET-4-ALARM : SONET0_5_0_0: SLOSLC/0/5/CPU0:Dec 3 13:34:12.281 : DI_Partner[50]: %SONET-4-ALARM : SONET0_5_0_0: SLOS cleared...In this example, the output displays syslog messages stored in the logging buffer that were logged on or before 10:29:00 on December 3:
RP/0/0/CPU0:router# show logging end december 3 10:29:00Syslog logging: enabled (20 messages dropped, 0 flushes, 0 overruns)Console logging: level debugging, 45 messages loggedMonitor logging: level debugging, 0 messages loggedTrap logging: level informational, 10 messages loggedLogging to 172.19.72.224, 10 message lines loggedBuffer logging: level debugging, 30 messages loggedLog Buffer (16384 bytes):RP/0/0/CPU0:Dec 3 10:28:24.245 : wdsysmon[296]: %HA_WD-4-DISK_ALARM : A monitored disk is above 80% utilization. Please remove unwanted user files and configuration rollback points.RP/0/0/CPU0:Dec 3 10:28:24.247 : wdsysmon[296]: %HA_WD-6-DISK_USAGE : /disk0: usage 88%RP/0/0/CPU0:Dec 3 10:28:31.247 : lrd[215]: LRd waited 40 seconds for inventory... rc = 1082230272 nCount = -1...In this example, the output displays syslog messages stored in the logging buffer that were logged on or between 10:30 and 11:00 on December 3:
RP/0/0/CPU0:router# show logging start december 3 10:30:00 end december 3 11:00:00Syslog logging: enabled (20 messages dropped, 0 flushes, 0 overruns)Console logging: level debugging, 45 messages loggedMonitor logging: level debugging, 0 messages loggedTrap logging: level informational, 10 messages loggedLogging to 172.19.72.224, 10 message lines loggedBuffer logging: level debugging, 30 messages loggedLog Buffer (16384 bytes):RP/0/0/CPU0:Dec 3 10:30:35.068 : locald[210]: %LOCALD-3-ROOT_USERDB_INIT_FAIL : Failed to create aaa directory: File existsRP/0/0/CPU0:Dec 3 10:30:41.023 : config[129]: %CONFIGCLI-7-INFRA_READY : Infrastructure not ready to consume configuration.RP/0/0/CPU0:Dec 3 10:31:10.504 : sip[252]: sxa_iox_chkpt_init 154 SIP-LOG: SIP started - performing a cold start.RP/0/0/CPU0:Dec 3 10:31:33.782 : config[129]: %CONFIGCLI-7-INFRA_READY : Infrastructure ready to consume configuration...Archiving System Logging Messages to a Local Storage Device
This task explains how to display save syslog messages to an archive on a local storage device.
Restrictions
The local storage device must have enough space available to store the archive files. We recommend that syslogs be archived to the harddisk because it has more capacity than flash disks.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
or
commitDETAILED STEPS
Step 1
configure
Example:RP/0/RP0/CPU0:router# configure
Enters global configuration mode.
Step 2
logging archive
Example:RP/0/RP0/CPU0:router(config)# logging archive
Enters logging archive configuration mode.
Step 3
device {disk0 | disk1 | harddisk}
Example:RP/0/RP0/CPU0:router(config-logging-arch)# device disk1
Specify the device to be used for logging syslogs.
•
•
•
Step 4
frequency {daily | weekly}
Example:RP/0/RP0/CPU0:router(config-logging-arch)# frequency weekly
(Optional) Specifies if logs are collected on a daily or weekly basis.Logs are collected daily by default.
Step 5
severity severity
Example:RP/0/RP0/CPU0:router(config-logging-arch)# severity warnings
(Optional) Specifies the minimum severity of log messages to archive. All syslog messages greater than or equal to this configured level are archived while those lesser than this are filtered out. The severity levels are:
•
•
•
•
•
•
•
•
See the "Syslog Message Severity Level Definitions" section for information.
Step 6
archive-length weeks
Example:RP/0/RP0/CPU0:router(config-logging-arch)# archive-length 6
(Optional) Specifies the maximum number of weeks that the archive logs are maintained in the archive. Any logs older than this number are automatically removed from the archive.
By default, archive logs are stored for 4 weeks.
Step 7
archive-size size
Example:RP/0/RP0/CPU0:router(config-logging-arch)# archive-size 50
(Optional) Specifies the maximum total size of the syslog archives on a storage device. If the size is exceeded then the oldest file in the archive is deleted to make space for new logs.
The default archive size is 20 MB.
Step 8
file-size size
Example:RP/0/RP0/CPU0:router(config-logging-arch)# file-size 10
(Optional) Specifies the maximum file size (in megabytes) that a single log file in the archive can grow to. Once this limit is reached, a new file is automatically created with an increasing serial number.
By default, the maximum file size is 1 megabyte.
Step 9
end
or
commit
Example:RP/0/RP0/CPU0:router(config)# end
or
RP/0/RP0/CPU0:router(config)# commit
Saves configuration changes.
•
Uncommitted changes found, commit them before exiting(yes/no/cancel)? [cancel]:–
–
–
•
Examples
The following example shows how to configure a logging archive, and define the archive attributes:
RP/0/RP0/CPU0:router# configureRP/0/RP0/CPU0:router(config)# logging archiveRP/0/RP0/CPU0:router(config-logging-arch)# device disk1RP/0/RP0/CPU0:router(config-logging-arch)# frequency weeklyRP/0/RP0/CPU0:router(config-logging-arch)# severity warningsRP/0/RP0/CPU0:router(config-logging-arch)# archive-length 6RP/0/RP0/CPU0:router(config-logging-arch)# archive-size 50RP/0/RP0/CPU0:router(config-logging-arch)# file-size 10Configuration Examples for Implementing Logging Services on Cisco IOS XR Software
This section provides the following configuration examples:
•
•
•
•
•
Configuring Logging to the Console Terminal and the Logging Buffer: Example
The following example shows a logging configuration where logging to the logging buffer is enabled, the severity level of syslog messages sent to the console terminal is limited to syslog messages at or below the critical severity level, and the size of the logging buffer is set to 60,000 bytes.
!logging console criticallogging buffered 60000!Setting Up Destinations for Syslog Messages: Example
The following example shows a logging configuration where logging is configured to destinations other than the console terminal. In this configuration, the following is configured:
•
•
•
•
•
!logging trap warningslogging monitor criticallogging buffered 60000logging 172.19.72.224!Configuring the Settings for the Logging History Table: Example
The following example shows a logging configuration in which the size of the logging history table is to 200 entries and the severity of level of syslog messages sent to the logging history table is limited to messages at or below the errors severity level:
logging history size 200logging history errorsModifying Time Stamps: Example
The following example shows a time-stamp configuration in which time stamps are configured to follow the format month date HH:MM:SS time zone:
service timestamps log datetime show-timezoneThe following example shows a time-stamp configuration in which time stamps are configured to follow the format month date HH:MM:SS.milliseconds time zone:
service timestamps log datetime msec show-timezoneConfiguring a Logging Archive: Example
The following example shows how to configure a logging archive, and define the archive attributes:
RP/0/RP0/CPU0:router# configureRP/0/RP0/CPU0:router(config)# logging archiveRP/0/RP0/CPU0:router(config-logging-arch)# device disk1RP/0/RP0/CPU0:router(config-logging-arch)# frequency weeklyRP/0/RP0/CPU0:router(config-logging-arch)# severity warningsRP/0/RP0/CPU0:router(config-logging-arch)# archive-length 6RP/0/RP0/CPU0:router(config-logging-arch)# archive-size 50RP/0/RP0/CPU0:router(config-logging-arch)# file-size 10Where to Go Next
To configure alarm log correlation, see the Implementing and Monitoring Alarms and Logging Correlation on Cisco IOS XR Software module in the Cisco IOS XR System Management Configuration Guide.
Additional References
The following sections provide references related to implementing logging services on Cisco IOS XR software.
Related Documents
Standards
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
—
To locate and download MIBs using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL and choose a platform under the Cisco Access Products menu: http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
RFCs
No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.
—
Technical Assistance
