Table Of Contents
Monitoring the ACNS Network
Monitoring ACNS Network Device Statistics
Viewing Content Engine Statistics
Viewing Device Group Statistics
Viewing Routing Statistics
Monitoring Replication Status
Viewing the System-Wide Replication Status by Channel
Viewing the Replication Status for a Specific Channel
Viewing the Detailed Replication Status for a Specific Channel
Viewing Detailed Replication Status for Channel by Device
Viewing the Detailed Item Replication Status Across All Content Engines in a Channel
Viewing the System-Wide Replication Status by Content Engine
Viewing the Replication Status for a Specific Content Engine
Viewing the Detailed Replication Status for a Specific Content Engine
Using CLI Commands for Replication Status
Using the System Message Log
Configuring System Event Logging Using the Content Distribution Manager GUI
Configuring System Event Logging Using CLI Commands
Viewing the System Message Log
Transaction Logging
Understanding the Transaction Log Formats
Squid-Style Transaction Logging
Extended Squid Log Format
Apache-Style Transaction Logging
Custom Format Transaction Logging
Transaction Logging and NTLM Authentication
Usage Guidelines for Log Files
Understanding Working Logs
Archive Working Log
Sanitizing Transaction Logs
Exporting Log Files
Exporting Transaction Logs to External FTP Servers
Exporting Transaction Logs to External SFTP Servers
Enabling Transaction Logging with the Content Distribution Manager GUI
Monitoring with SNMP
Configuring SNMP Server Settings
Configuring SNMP Community Settings
Configuring SNMP Group Settings
Configuring SNMP User Settings
Configuring SNMPv2 View Settings
Configuring SNMP Host Settings
Supported MIBs
Key SNMP CLI Commands
Configuring SNMP Traps Using the CLI
Monitoring the ACNS Network
This chapter provides information on monitoring the ACNS network by viewing device statistics, and viewing system message logs and transaction logs.
This chapter contains the following sections:
•
Monitoring ACNS Network Device Statistics
•Monitoring Replication Status
•Using the System Message Log
•Transaction Logging
•Monitoring with SNMP
Monitoring ACNS Network Device Statistics
The Monitoring area of the Content Distribution Manager GUI allows you to view statistics for your Content Engines, device groups, and Content Routers.
Viewing Content Engine Statistics
It is often useful to be able to assess the performance of Content Engines across your network. You can do this using the Content Engine statistics feature, available from the Monitoring area of the Content Distribution Manager GUI.
The Content Engine statistics feature enables you to view, at a glance, which Content Engines are online, as well as assess their available resources, the volume of traffic being routed to them, and their performance in serving requests. The information displayed is based on a snapshot of your ACNS network that represents the state of your Content Engines at the end of every 2 polling periods. You can configure the length of a polling period in the Content Distribution Manager GUI (System > System Configuration > System.datafeed.pollRate). The default polling rate is 300 seconds (5 minutes).
To view Content Engine statistics for your ACNS network, follow these steps:
Step 1 From the Content Distribution Manager GUI, choose Monitoring > Statistics.
Step 2 In the Contents pane, click Content Engines, and then choose one of the following submenu options to view the Content Engine statistics for that option:
•Cisco Streaming Engine
•HTTP
•RTSP
•WMT
Step 3 To print the statistics data, click the Printer icon.
Table 17-1 explains the meaning of each Content Engine statistic presented in the GUI.
Table 17-1 Content Engine and Device Group Statistics
Content Engine Property
|
Description
|
Cisco Streaming Engine
|
Bandwidth (bits/sec)
|
Current bandwidth output by the server in bits per second.
|
Total Bytes
|
Total bytes output by the server since it was started.
|
Total Packets
|
Total packets output by the server since it was started.
|
RTSP Connections
|
Number of clients currently connected over RTSP.
|
All Connections
|
Number of clients currently connected since startup.
|
Updated
|
Time stamp indicating when the statistics were updated.
|
HTTP
|
Requests/Sec
|
Number of requests per second.
|
Bytes/Sec
|
Number of bytes per second.
|
Service Time
|
Length of time that the Content Engine has been operating successfully.
|
Hit Rate
|
Average number of content items per minute successfully served from the cache of the Content Engine or from all the Content Engines in the channel or virtual ACNS network during the preceding quarter hour.
|
Updated
|
Time stamp indicating when the statistics were updated.
|
RealProxy (RTSP)
|
Requests/Sec
|
Number of requests per second.
Note This value is not a rate but a total number and corresponds to the output from the show statistics rtsp proxy media-real savings command.
|
Bytes/Sec
|
Number of bytes per second.
Note This value is not a rate but a total number and corresponds to the output from the show statistics rtsp proxy media-real savings command.
|
Hit Rate
|
Average number of content items per minute successfully served from the cache of the Content Engine or from all the Content Engines in the channel or virtual ACNS network during the preceding quarter hour.
|
Updated
|
Time stamp indicating when the statistics were updated.
|
WMT
|
Requests/Sec
|
Number of requests per second.
|
Bytes/Sec
|
Number of bytes per second.
|
Hit Rate
|
Average number of content items per minute successfully served from the cache of the Content Engine or from all the Content Engines in the channel or virtual ACNS network during the preceding quarter hour.
|
Updated
|
Time stamp indicating when the statistics were updated.
|
Viewing Device Group Statistics
To view device group statistics for your ACNS network, follow these steps:
Step 1 From the Content Distribution Manager GUI, choose Monitoring > Statistics.
Step 2 In the Contents pane, click Device Groups, and then choose one of the following submenu options to view the Content Engine statistics for that option:
•Cisco Streaming Engine
•HTTP
•RTSP
•WMT
Statistics for device groups are the same as for Content Engines. See Table 17-1 for an explanation of the meaning of each device group statistic presented in the GUI.
Step 3 To print the statistics data, click the Printer icon.
Viewing Routing Statistics
To view routing statistics for Content Routers and routing Content Engines, follow these steps:
Step 1 From the Content Distribution Manager GUI, choose Monitoring > Statistics.
Step 2 In the Contents pane, click Routing Statistics, and then choose one of the following submenu options to view the Content Engine statistics for that option:
•Routing Requests
•Routing Redirects
Step 3 To print the statistics data, click the Printer icon.
Table 17-2 explains the meaning of each Content Router statistic presented in the GUI.
Table 17-2 Content Router Statistics
Content Router Property
|
Description
|
Routing Requests
|
Total Requests
|
Total number of content requests received by simplified hybrid routing.
|
Http Requests
|
Number of ASX and traditional HTTP web requests received.
|
Rtsp Requests
|
Number of RTSP requests received.
|
Updated
|
Time stamp indicating when the statistics were updated.
|
Routing Redirects
|
Total Requests
|
Total number of content requests received by simplified hybrid routing.
|
Reqs Redirected
|
Total number of content requests received by simplified hybrid routing that were redirected.
|
Reqs Not Directed
|
Total number of content requests received by simplified hybrid routing that were not redirected.
|
Updated
|
Time stamp indicating when the statistics were updated.
|
You can also view additional content routing statistics through the Content Distribution Manager GUI, by choosing Device > Content Routers > Show/Clear Commands > Show Commands. The show commands are further documented in the Cisco ACNS Software Command Reference, Release 5.1 publication.
Monitoring Replication Status
The replication status feature allows you to view the status of content replication using the Content Distribution Manager GUI, output from CLI commands, or an API file The progressive file count status shows different information depending on which device provides the display.
•Content Distribution Manager GUI—During acquisition and replication, shows the number of files replicated, files yet to be replicated, files that failed to be replicated, and total number of files in a channel associated with a Content Engine.
•Root Content Engine—Shows the number of files acquired, files yet to be acquired, files that failed to be acquired, and files that failed to update.
•Receiver Content Engine—Shows the number of files replicated, files yet to be replicated, files that failed to replicate, and files that failed to update.
Note Individual Content Engines report their known status, but the Content Distribution Manager has a global view of the channel and may modify the state that the Content Engine reports. If the root Content Engine is processing an updated manifest file or has found new content that a receiver Content Engine is unaware of, the receiver Content Engine reports the replication status as complete, whereas the Content Distribution Manager reports the status as "Update Pending." If the root Content Engine fails to update files, all the receiver Content Engines are reported as status "Unknown" because there is no way to determine the state of the receiver Content Engines.
System-level replication status is provided under the Monitoring tab in the Content Distribution Manager GUI. You can view the replication status by channel or by device. The Content Distribution Manager GUI also allows you to move from a system-wide view to a detailed view for a specific Content Engine or channel. You can also view detailed replication status for a particular content item in a channel.
Note In ACNS 5.1 software, replication information formerly under the Channels tab has been moved under the Monitoring tab.
Use the Content Distribution Manager GUI to perform the following tasks:
•Viewing the System-Wide Replication Status by Channel
•Viewing the Replication Status for a Specific Channel
•Viewing the Detailed Replication Status for a Specific Channel
•Viewing Detailed Replication Status for Channel by Device
•Viewing the Detailed Item Replication Status Across All Content Engines in a Channel
•Viewing the System-Wide Replication Status by Content Engine
•Viewing the Replication Status for a Specific Content Engine
•Viewing the Detailed Replication Status for a Specific Content Engine
Viewing the System-Wide Replication Status by Channel
The Channel Replication Status window lists all channels on the system and displays the replication status information for each channel. This display summarizes the replication status of all Content Engines associated with a specific channel in a given state.
To view system-wide replication status for each channel, follow these steps:
Step 1 From the Content Distribution Manager GUI, choose Monitoring > Replication.
Step 2 In the Contents pane, choose Replication Status > Channel. The Channel Replication Status window appears. (See Figure 17-1.)
Figure 17-1 Channel Replication Status Window
Step 3 View the replication status information for each channel. Table 17-3 describes the status information that is displayed in this window.
Table 17-3 Channel Replication Status Window
Column Heading
|
Description
|
Channel
|
Name of the channel.
|
Complete
|
Number of Content Engines in this channel that are in a complete state.
|
In Process
|
Number of Content Engines in the channel in the acquiring/receiving state.
|
Failed
|
Number of Content Engines in this channel that have failed to acquire, receive, or update content.
|
Unknown
|
Number of Content Engines in this channel in the unknown state.
|
Root CE
|
State of the root Content Engine.
|
Valid Since
|
Time of the oldest Content Engine update.
|
Viewing the Replication Status for a Specific Channel
To view the replication status for a particular channel, follow these steps:
Step 1 Choose Monitoring > Replication. The Monitoring window appears.
Step 2 In the Contents pane, choose Replication Status > Channel. The Channel Replication Status window appears.
Step 3 Click the View icon next to the channel that you want to view. (See Figure 17-1.) The Replication Status for Channel window appears. This window displays the acquisition status of the channel. (See Figure 17-2.) Table 17-4 describes the acquisition status information that is displayed in this window.
Note Alternatively, you can choose Channels > Channels, click the Edit icon next to the channel for which you want to view the replication status, and choose Basic Settings > Replication Status from the Modifying Channel window. However, we recommend that you use the Monitoring path instead of the Channels path to access this window because a more detailed and complete description of replication status has been added under the Monitoring path in ACNS 5.1 software.
Figure 17-2 Replication Status for Channel Window
This window also allows you to do the following:
•See a detailed view of replication status using search criteria. (See the "Viewing the Detailed Replication Status for a Specific Channel" procedure.)
•Query the replication status of content items (by pattern) for a selected Content Engine in the channel. (See the "Viewing Detailed Replication Status for Channel by Device" procedure.)
•View the replication status of individual Content Engines assigned the particular channel. (See Table 17-5.)
Table 17-4 Acquisition Status for Channel
Field
|
Description
|
Root CE
|
Name of the root Content Engine.
|
Status
|
Root Content Engine States
•Unknown: The Content Distribution Manager is unable to determine the status of the root Content Engine. This occurs typically when the root Content engine has not yet reported its status.
•Processing Manifest: The Content Engine is parsing the manifest file.
•Crawling/Acquiring: Crawling or file acquisition is occurring.
•Complete: All content has currently been successfully received.
•Failed Processing Manifest: The Content Engine has failed to parse the updated manifest file.
•Failed Crawling/Acquiring: The Content Engine has failed to fetch the updated content from origin servers.
•
|
| |
Receiver Content Engine States
•Unknown: The Content Distribution Manager is unable to determine the status of the receiver Content Engine. This occurs typically when the receiver Content Engine has not yet reported its status or its status is not consistent with that of the root Content Engine. Receiver Content Engine is in an intermediate state when the error on the root Content Engine is yet to be cleared.
•Pending Update: The root Content Engine is either in the Processing Manifest or the Crawling/Acquiring states, but has not yet started replicating content to the receiver Content Engine.
•Receiving: The receiver Content Engine is receiving content from the root Content Engine.
•Failed Receiving: The receiver Content Engine has failed to receive content from the root Content Engine.
•Complete: All content has currently been successfully received.
|
Disk Quota Used
|
Amount of disk quota used for the channel.
|
Manifest Last Acquired
|
Time when the manifest was last acquired, as recorded on the Content Engine.
|
Manifest Error
|
Description of the manifest error, if there is an error.
|
Table 17-5 Replication Status for Devices Assigned to a Specific Channel
Field
|
Description
|
Content Engine
|
Name of the Content Engine assigned to the channel.
|
Type of Content Engine
|
Root, receiver, or temporary root.
|
State
|
See description of states in the Status field description.
|
Complete
|
Number of files that have been acquired and received.
|
In Process
|
Number of files to be acquired and replicated.
|
Failed
|
Number of files that failed to be acquired and replicated.
|
Failed to Update
|
Number of files which failed to be updated, or which might or might not still be valid.
|
Valid Since
|
Time stamp of the last metadata update.
|
Viewing the Detailed Replication Status for a Specific Channel
To view the detailed replication status for a channel, follow these steps:
Step 1 Choose Monitoring > Replication. The Monitoring window appears.
Step 2 In the Contents pane, choose Replication Status > Channel. The Channel Replication Status window appears.
Step 3 Click the View icon next to the channel for which you want to view the replication status of individual Content Engines. The Replication Status for Channel window appears.
Step 4 In the View Detailed Replication Status section (see Figure 17-2), enter a string in the Get Detailed Status using Search Criteria field. Use an asterisk (*) to match one or more characters, or a question mark (?) to match only a single character.
The criteria are matched to the relative cdn-url attribute specified in the <item> tag in the manifest file. It is recommended that you start the search criteria by specifying wildcards such as *.htm or *clip.mpeg.
Step 5 Click the Go button. The Replication Items - Channel window appears. (See Figure 17-3.) Table 17-6 describes the information that is displayed in the window.
Figure 17-3 Replication Items - Channel Window
Table 17-6 Replication Item Status for a Channel
Column Heading
|
Description
|
Url
|
URL of the origin web server that stores the website content.
|
Size
|
Size of the file to be acquired or crawled.
|
Status
|
Status of replication of content in the channel.Status will be shown as Complete if the replication is complete on all Content Engines assigned to the channel.
|
Replied CEs
|
Number of Content Engines that have replicated this item
|
Playtime
|
Duration of playback of the file.
|
Modification Time
|
Time stamp of the earliest update for that channel from an active Content Engine.
|
Viewing Detailed Replication Status for Channel by Device
Queries to determine the detailed replication status trigger extensive CPU cycles and high consumption of memory because all the Content Engines assigned to a channel need to be polled, and the retrieved replication status is cached in the memory of the Content Distribution Manager. This results in performance degradation. To optimize the usage of memory resources without compromising the need to obtain detailed replication status of a particular content item, you can select a Content Engine assigned to a channel and generate a query.
To view the detailed replication status for a channel by device, follow these steps:
Step 1 Choose Monitoring > Replication. The Monitoring window appears.
Step 2 In the Contents pane, choose Replication Status > Channel. The Channel Replication Status window appears.
Step 3 Click the View icon next to the channel for which you want to view the replication status of individual Content Engines. The Replication Status for Channel window appears.
Step 4 In the Devices Assigned to Channel section (see Figure 17-2), click the radio button next to the name of the device that you want to view.
Step 5 In the View Detailed Replication Status for Channel by Device section, choose all, replicated, or nonreplicated content items from the Get drop-down list, enter a string in the Search Criteria for Selected Device field, and click the Go button.
For example, enter Get replicated content items using Search Criteria *.bin for selected Device.
Note Use an asterisk (*) to match one or more characters, or a question mark (?) to match only a single character.
The Replication Items - Channel: Content Engine window appears. (See Figure 17-4.) Table 17-7 describes the fields displayed in this window.
Figure 17-4 Replication Items - Channel: Content Engine: Window
Table 17-7 Replication Item Status
Column Heading
|
Description
|
Url
|
URL of the origin web server that stores the website content.
|
Size
|
Size of the file to be acquired or crawled.
|
Status
|
Status of replication of content in the channel. Status is shown as Complete if replication is complete on all Content Engines assigned to the channel.
|
Playtime
|
Duration of playback of the file.
|
Modification Time
|
Time stamp in Greenwich mean time (GMT) of the latest update to the content item as recorded on the origin server.
|
Note When you click the Force replication information refresh icon in the taskbar of the Replication Items - Channel window, the system displays a dialog box asking you to confirm whether you want to refetch the information from Content Engines assigned to this channel. Click OK to continue with the refresh process. You are notified that the request has been queued and notified to check back later.
Step 6 To refine your search from this window, make a choice from the Get drop-down list, enter a search string in the Search Criteria field, and click the Go button.
Step 7 To return to the Replication Status for Channel window click the Back arrow in the Content Distribution Manager GUI taskbar (not the back button for your browser).
Viewing the Detailed Item Replication Status Across All Content Engines in a Channel
You can choose a URL of the origin server and make a request for a detailed item replication status across all Content Engines to trigger an aggregated replication status request. The detailed item replication status window shows a time stamp indicating the time in Greenwich mean time (GMT) at which the replication status was last cached to provide information about the freshness of the detailed content replication status.
To view the detailed replication status of an item across all Content Engines in a channel, follow these steps:
Step 1 Choose Monitoring > Replication. The Monitoring window appears.
Step 2 In the Contents pane, choose Replication Status > Channel. The Channel Replication Status window appears.
Step 3 Click the View icon next to the channel for which you want to view the replication status of individual Content Engines. The Replication Status for Channel window appears.
Step 4 In the View Detailed Replication Status section (see Figure 17-2), enter a string in the Get Detailed Status using Search Criteria field. Use an asterisk (*) to match one or more characters, or a question mark (?) to match only a single character.
Step 5 Click the Go button. The Replication Items - Channel window appears. (See Figure 17-3.)
Click the View icon next to the URL that you want to view. The Replication Item Channel: window appears. (See Figure 17-5.) Table 17-8 describes the fields in this window.
Figure 17-5 Replication Item Channel: Window
Note The Replication Item Channel: window is specifically designed to limit listings to 5000 objects for scalability reasons. These are system limits and not specifically enforced for replication status reporting.
Table 17-8 Replication Item Status for a All Content Engines in a Channel
Column Heading
|
Description
|
CE
|
Name of the Content Engine to which the item has been replicated.
|
Size
|
Size of the file to be acquired or crawled.
|
Status
|
Status of replication of content in the channel. Status is shown as Complete if replication is complete on all Content Engines assigned to the channel.
|
Playtime
|
Duration of playback of the file.
|
Modification Time
|
Time stamp of the latest update for the content item as recorded on the origin web server.
|
Step 6 To return to the Replication Status for Channel window click the Back arrow in the Content Distribution Manager GUI taskbar (not the back button for your browser).
Viewing the System-Wide Replication Status by Content Engine
To view the system-wide replication status by device, follow these steps:
Step 1 From the Content Distribution Manager GUI, choose Monitoring > Replication.
In the Contents pane, choose Replication Status > Device. The Device Replication Status window appears. The Device Replication Status window lists all Content Engines on the system. This window summarizes the replication status of all channels associated with a specific Content Engine in a given state. (See Figure 17-6.)
Figure 17-6 Device Replication Status Window
Step 2 View the replication status information for each device. Table 17-9 describes the status information that is displayed in this window.
Table 17-9 Device Replication Status Window
Column Heading
|
Description
|
Device
|
Name of the Content Engine.
|
Complete
|
Number of channels on this Content Engine that are in a complete state.
|
In Process
|
Number of channels on this Content Engine in the acquiring, crawling, receiving, or pending state.
|
Failed
|
Number of channels on this Content Engine in the failed or failed update state.
|
Unknown
|
Number of channels on this Content Engine in the unknown state.
|
Valid Since
|
Time of the oldest Content Engine update.
|
Step 3 To query the replication status of individual channels assigned to a particular Content Engine, proceed to the next section, "Viewing the Replication Status for a Specific Content Engine."
Viewing the Replication Status for a Specific Content Engine
To view the replication status for a particular Content Engine, follow these steps:
Step 1 Choose Monitoring > Replication. The Monitoring window appears.
Step 2 In the Contents pane, choose Replication Status > Device. The Device Replication Status window appears.
The Replication Status for Device window displays the replication status of individual channels assigned to a particular Content Engine. You can filter the information by channels or by any of the other categories displayed in this window.
Step 3 Click the View icon (see Figure 17-6) next to the Content Engine for which you want to view the replication status of assigned channels. The Replication Status for Device window appears. (See Figure 17-7.) Table 17-10 describes the status information that is displayed in this window.
Note Another way to view the same information is by looking up the replication status for a particular Content Engine in the Devices menu (Devices > Content Engines > Replication Status); however, we recommend that you use the Monitoring path instead of the Devices path to access this information, because the ability to obtain a more detailed and complete description of replication status has been added in the Monitoring area in ACNS 5.1 software.
Figure 17-7 Replication Status for Device Window
Table 17-10 Replication Status for Device Window
Column Heading
|
Description
|
Channel
|
Name of the channel to which the Content Engine is assigned.
|
Type
|
Root, temporary root, or receiver Content Engine for this channel.
|
State
|
Root Content Engine States
•Unknown: The Content Distribution Manager is unable to determine the status of the root Content Engine. This occurs typically when the root Content engine has not yet reported its status.
•Processing Manifest: The Content Engine is parsing the manifest file.
•Crawling/Acquiring: Crawling or file acquisition is occurring.
•Complete: All content has currently been successfully received.
•Failed Processing Manifest: The Content Engine has failed to parse the updated manifest file.
•Failed Crawling/Acquiring: The Content Engine has failed to fetch the updated content from origin servers.
|
State
|
Receiver Content Engine States
•Unknown: The Content Distribution Manager is unable to determine the status of the receiver Content Engine. This occurs typically when the receiver Content Engine has not yet reported its status or its status is not consistent with that of the root Content Engine. Receiver Content Engine is in an intermediate state when the error on the root Content Engine is yet to be cleared.
•Pending Update: The root Content Engine is either in the Processing Manifest or the Crawling/Acquiring states, but has not yet started replicating content to the receiver Content Engine.
•Receiving: The receiver Content Engine is receiving content from the root Content Engine.
•Failed Receiving: The receiver Content Engine has failed to receive content from the root Content Engine.
•Complete: All content has currently been successfully received.
|
Complete
|
Number of files that have been acquired and received.
|
In Process
|
Number of files being acquired and replicated.
|
Failed
|
Number of files that failed to be acquired and replicated.
|
Failed to Update
|
Number of files that have failed to be updated, and might or might not still be valid.
|
Valid Since
|
Time stamp of the last metadata update.
|
Step 4 To view replication details for the selected channel, see the next section, "Viewing the Detailed Replication Status for a Specific Content Engine."
Viewing the Detailed Replication Status for a Specific Content Engine
In ACNS 5.1 software, a time stamp denoting the time in Greenwich mean time (GMT) when the replication status was last cached is displayed to indicate the freshness of the detailed content replication status. Also, a request for a detailed replication status triggers an aggregated replication status update request. This ensures that the cache status is refreshed on both the Content Engine and the Content Distribution Manager at the same time.
To view the status of replication of content items for a selected channel, follow these steps:
Step 1 Choose Monitoring > Replication. The Monitoring window appears.
Step 2 In the Contents pane, choose Replication Status > Device. The Device Replication Status window appears.
Step 3 Click the View icon next to the Content Engine for which you want to view the replication status of assigned channels. The Replication Status for Device window appears.
Step 4 Click the radio button next to a channel name to view replication details for the selected channel.
You can display all content items, replicated content items, or nonreplicated content items by entering a regular expression in the Search Criteria for Selected Channel field, choosing an item from the drop-down list, and clicking the Go button. The Replication Items - Channel: Content Engine: window appears. (See Figure 17-8.) Table 17-11 describes the fields displayed in this window.
Figure 17-8 Replication Items - Channel: Content Engine: Window
Table 17-11 Replication Items for Content Engines in a Selected Channel
Column Heading
|
Description
|
URL
|
URL of the origin web server that stores the website content.
|
Size
|
Size of the file to be acquired or crawled.
|
Status
|
Status of replication of content from the root Content Engine.
|
Play time
|
Duration of playback of the file.
|
Modification Time
|
Time stamp of the earliest update for that channel from an active Content Engine.
|
Step 5 In the Replication Items - Channel: Content Engine: window, you can further qualify your search by specifying a regular expression in the Search Criteria field (such as *.html, *.mpg or *.jpg) and choosing the type of items (replicated, nonreplicated, or all items) from the drop-down list. Use an asterisk (*) to match one or more characters, and a question mark (?) to match exactly one character.
Note The Replication Items - Channel: Content Engine: window is specifically designed to limit listings to 5000 objects for scalability reasons. These are system limits and not specifically enforced for replication status reporting.
Step 6 Click the Force replication information refresh icon in the taskbar of the Replication Items window, to forcibly refetch the latest content replication information. You are asked to confirm whether you wish to refetch the information from the Content Engine assigned to the particular channel.
Step 7 Click OK to continue with the refresh process. You are notified that your request has been sent and prompted to check back after a few minutes.
Step 8 To return to the Replication Status for Device window, click the Back button in the taskbar.
Using CLI Commands for Replication Status
You can use the Content Engine CLI to view the content replication status for a channel by using the following commands:
•Use the show distribution channel channel-id command to see if there is an unfinished job listed for the channel. The last line in this example shows that there are no unfinished jobs.
ContentEngine# show distribution channel channel-id 158
ID of Configured Root CE: 140
Name of Configured Root CE: sz590b
IP of Configured Root CE: 10.1.1.170
This CE's Role: Not a Root CE
Metadata-Forwarder ID: 140
Metadata-Forwarder Name: sz590b
Metadata-Forwarder IP: 10.1.1.170
Ucast-Forwarder Name: sz590b
Ucast-Forwarder IP: 10.1.1.170
Last gen-id Switch: Never
ID of Effective Root CE: 140
Current root-ce-uid: 1042665163
Current low-water-marker: 1
Current max-del-gen-id: 0
Note The Has Unfinished Job line is only available if the Content Engine is not a root Content Engine. It is available on the receiver Content Engine.
•Use the show statistics replication command to view replication status of content items in the channel. The show statistics replication commands display the progressive file count status during acquisition and replication.
CDM# show statistics replication channels
Replication status for channel channel_2 ID 197
-------------------------------------------------------------
Replication status for channel test ID 153
-------------------------------------------------------------
State: Failed Processing Manifest, Manifest Error: Failed to fetch manifest file: NO
Host(906)
Valid as of: Tue Apr 01 12:45:30 UTC 2003
CDM# show statistics replication content-engines selected-channel Website1 test
content-engine ContentEngine
Replication status for channel test (ID 153) for CE ID 103
-------------------------------------------------------------
State: Failed Processing Manifest
Files failed to be updated: 0
Valid as of: Wed Apr 09 22:05:43 UTC 2003
ContentEngine# show statistics replication channels
Content Engine: ce1 (ID 88) root
Channel: 'test', WebSite: 'Website1' (channel ID 153)
Files failed to be updated: 0
Using the System Message Log
Use the ACNS system logging feature to set specific parameters for the system log file (sylog). This file contains authentication entries, settings of privilege levels, and administrative details. System logging is always enabled internally. The system log file is located on the system file system (sysfs) partition as /local1/syslog.txt.
You can use either of the following interfaces to configure the Content Engine to send varying levels of event messages to disk, console, or host.
•Content Distribution Manager GUI, as described in the "Configuring System Event Logging Using the Content Distribution Manager GUI" section
•Content Engine CLI, as described in the "Configuring System Event Logging Using CLI Commands" section
Configuring System Event Logging Using the Content Distribution Manager GUI
To enable system logging, follow these steps:
Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines.
Step 2 Click the Edit icon next to the Content Engine for which you want to enable system logging. The Contents pane appears on the left.
Step 3 From the Contents pane, choose Platform > Sys Logs. The Syslog Settings for Content Engine window appears. (See Figure 17-9.)
Figure 17-9 Syslog Settings Window
Step 4 Under the Syslog settings heading, check the Enable check box to enable system logging.
Step 5 Choose the appropriate facility from the Facility drop-down list.
Step 6 Click Submit to save the settings.
You can enable sending syslog files to the console, disk, or a host.
To enable syslog files to be sent to the console, follow these steps under Console Settings:
Step 1 Check the Enable check box to enable sending syslog files to the console.
Step 2 Choose a priority level from the Priority drop-down list. (See Table 17-13 for a list of priority levels.)
Step 3 Click Submit to save the settings.
To enable syslog files to be sent to disk, follow these steps under Disk Settings:
Step 1 Check the Enable Disk Settings check box to enable sending syslog files to disk.
Step 2 In the File Name field, enter a path and a filename where the syslog files will be stored on disk.
Step 3 Choose a priority level from the Priority drop-down list. (See Table 17-13 for a list of priority levels.)
Step 4 In the Recycle field, specify the size of the syslog file (in bytes) that can be recycled when it is stored on disk.
Step 5 Click Submit to save the settings.
To enable syslog files to be sent to a host, follow these steps under Host Settings:
Step 1 Check the Enable Host Settings check box to enable sending syslog files to a host.
Step 2 Enter a host name or IP address in the Host Name field.
Step 3 Choose a priority level from the Priority drop-down list. See Table 17-13 for a list of priority levels.
Step 4 Click Submit to save the settings.
Configuring System Event Logging Using CLI Commands
Use the logging command to set specific parameters for the system log file (syslog). This file contains authentication entries, settings of privilege levels, and administrative details. System logging is always enabled internally. The system log file is located in the system file system (sysfs) storage area as /local1/syslog.txt.
Logging can be configured to send messages to the console, to disk, or to an external syslog host. See Table 17-12 for a list of the key system logging parameters, descriptions, and CLI commands.
Table 17-12 System Logging Parameter Settings
Parameter
|
Description
|
CLI Command
|
Host Server
|
IP address or host name of the host that receives syslog messages from the device group.
|
logging host hostname or ip-address
|
Console
|
Enables sending syslog files to the console.
|
logging console enable
|
Disk
|
Enables sending syslog files to disk.
|
logging disk enable
|
Priority
|
Determines priority level when system logging is enabled to disk, console, or host.
|
logging disk priority, logging console priority, logging host priority
|
Syslog file
|
Path of the syslog file in the hard drive.
|
logging disk filename filename
|
Recycle
|
Rewrites the syslog file when it surpasses the specified recycle size.
|
logging recycle size
|
Logging can be configured to send various levels of messages to disk, console, or host using the priority option of the logging command. Table 17-13 lists the different priority levels of detail to send to the recipient of the syslog messages for a corresponding event.
Table 17-13 System Logging Priority Levels and Descriptions
Priority Code
|
Condition
|
Description
|
0
|
Emergency
|
System is unusable.
|
1
|
Alert
|
Immediate action needed.
|
2
|
Critical
|
Critical condition.
|
3
|
Error
|
Error conditions.
|
4
|
Warning
|
Warning conditions.
|
5
|
Notice
|
Normal but significant conditions.
|
6
|
Information
|
Informational messages.
|
7
|
Debug
|
Debugging messages.
|
Viewing the System Message Log
Using the system message log feature of the Content Distribution Manager GUI, you can view information about events that have occurred in your ACNS network.
To view logged information for your ACNS network, follow these steps.
Note The Content Distribution Manager logs messages only of the severity level "critical" or higher from registered nodes.
Step 1 From the Content Distribution Manager GUI, choose Monitoring > Logs.
The System Message Log window appears. (See Figure 17-10.)
Figure 17-10 System Message Log (Showing All Messages)
Step 2 Choose one of the following types of messages to display from the System Message Log drop-down list:
•All
•CLI
•Critical
•Database
A table listing and describing each message is displayed.
Step 3 Click a column heading to sort the messages chronologically, by node type, node name, module, severity, or message text. By default, messages are listed chronologically. (See Figure 17-10.)
Note If no name is available for a node, the name displayed is "Unavailable." This might occur if the node has been deleted or has been reregistered with Cisco ACNS software.
Step 4 If you have many event messages, you might need to view multiple pages to view the activity that you are interested in. Click the forward (>>) and back (<<) buttons to move between pages. Alternatively, click the link for a specific page number to jump to that page.
Note You can choose the number of rows to be displayed in the System Message Log window by choosing a number from the Rows drop-down list.
Transaction Logging
Transaction logs allow administrators to view the traffic that has passed through the Content Engine. Typical fields in the transaction log are the date and time when a request was made, the URL that was requested, whether it was a cache hit or a cache miss, the type of request, the number of bytes transferred, and the source IP address.
Understanding the Transaction Log Formats
In ACNS 5.x software, the user can choose among Squid, Extended Squid, Apache, or customized log format for the transaction log.
Squid-Style Transaction Logging
The Squid-style log format is the default format for transaction logging in the Content Engine. The Squid log file format used is the native log file format associated with the Squid-1.1 access.log file format. For details on the Squid-1.1 native log file format, refer to the Squid documentation "Frequently Asked Questions," section 6.6, access.log heading at the following URL:
http://www.squid-cache.org/doc/FAQ/FAQ.html
The Squid log file format is:
time elapsed remotehost code/status bytes method URL rfc931 peerstatus/peerhost type
A Squid log format example looks like this:
1012429341.115 100 172.16.100.152 TCP_REFRESH_MISS/304 1100 GET http://www.cisco.com/images/homepage/news.gif - DIRECT/www.cisco.com -
Extended Squid Log Format
The Extended Squid format logs the associated username for each record in the log file in addition to the fields logged by the Squid-style format, and is used for billing purposes. In this format the Rfc931 field associated with the Squid format is used to log the authorized user. This field always contains a "-" (dash) if no user information is available.
An Extended Squid-style log format example looks like this:
1012429341.115 100 172.16.100.152 TCP_MISS/302 184 GET http://www.cisco.com myloginname DIRECT/www.cisco.com
Apache-Style Transaction Logging
The Apache format is the Common Log File (CLF) format defined by the World Wide Web Consortium (W3C) working group. This format is compatible with many industry-standard log tools. For more information, see the W3C Common Log Format website at the following URL:
http://www.w3.org/Daemon/User/Config/Logging.html.
The Apache-style log file format is:
remotehost rfc931 authuser date request status bytes
An Apache-style log file format example looks like this:
172.16.100.152 - - [Wed Jan 30 15:26:26 2002] "GET/http://www.cisco.com/images/homepage/support.gif HTTP/1.0" 200 632
Custom Format Transaction Logging
The transaction-logs format custom command allows you to use a log format string to log additional fields that are not included in the predefined native Squid or Extended Squid formats, or the Apache CLF format. The log format string is a string which can contain the tokens listed in Table 17-14 and which mimics the Apache log format string. The log format string can contain literal characters that are copied into the log file. Double backslashes (\\) can be used to represent a literal backslash, and a backslash followed by a single quote (\') can be used to represent a literal single quote. A literal double quote cannot be represented as part of the log format string. The control characters \t and \n can be used to represent a tab and a new line character, respectively.
Table 17-14 lists the acceptable format tokens for the log format string. The "..." portion of the format tokens shown in this table represents an optional condition. This portion of the format token can be left blank, as in %a. If an optional condition is included in the format token and the condition is met, then what is shown in the Value column of Table 17-14 is included in the transaction log output. If an optional condition is included in the format token but the condition is not met, the resulting transaction log output is replaced with a hyphen (-). The form of the condition is a list of HTTP status codes, which may or may not be preceded by an exclamation point (!). The exclamation point is used to negate all of the status codes that follow it, meaning that the value associated with the format token is logged if none of the status codes listed after the ! match the HTTP status code of the request. If any of the status codes listed after the ! match the HTTP status code of the request, then a hyphen (-) is logged.
For example, "%400,501{User-Agent}i" logs the User-Agent header value on 400 errors and 501 errors (Bad Request, Not Implemented) only, whereas "%!200,304,302{Referer}i" logs the Referer header value on all requests that did not return a normal status.
The custom format currently supports the following request headers:
•User-Agent
•Referer
•Host
•Cookie
The output of each of the following Request, Referer, and User-Agent format tokens specified in the custom log format string is always enclosed in double quotation marks in the transaction log entry:
%r
%{Referer}i
%{User-Agent}i
The %{Cookie}i format token is generated without the surrounding double quotation marks, because the Cookie value itself can contain double quotes. The Cookie value can contain multiple attribute-value pairs that are separated by spaces. For this reason, it is recommended that when the Cookie format token is used in a custom format string, it be positioned as the last field in the format string. This positioning of the Cookie format token allows it to be more easily parsed by transaction log reporting tools. Alternatively, if you use the format token string "\'%{Cookie}i\'", the Cookie header can be surrounded by single quotes.
The following command can be entered to generate the well-known Apache Combined Log Format:
transaction-logs format custom "[%{%d}t/%{%b}t/%{%Y}t:%{%H}t:%{%M}t:%{%S}t %{%z}t] %r %s %b %{Referer}i %{User-Agent}i"
The following transaction log entry example in the Apache Combined Format is configured using the preceding custom format string:
[11/Jan/2003:02:12:44 -0800] "GET http://www.cisco.com/swa/i/site_tour_link.gif HTTP/1.1" 200 3436 "http://www.cisco.com/" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"
Table 17-14 Custom Format Log Format String Values
Format Token
|
Value
|
%...a
|
IP address of the requesting client.
|
%...A
|
IP address of the Content Engine.
|
%...B
%...b
|
Bytes sent, excluding HTTP headers.
|
%...c
|
Connection status when response is completed, where:
X = Connection was aborted before the response was completed.
+ = Connection can be kept alive after the response is sent.
- = Connection is closed after the response is sent.
|
%...f
|
Filename.
|
%...h
|
Remote host (IP address of the requesting client is logged).
|
%...H
|
Request protocol.
|
%...{Foobar}i
|
Contents of Foobar: header lines in the request that is sent to the server. The value of Foobar can be one of the following headers: User-Agent, Referer, Host, or Cookie.
|
%...l
|
Remote log name. Not implemented on the Content Engine, so a hyphen (-) is logged.
|
%...m
|
Request method.
|
%...p
|
Canonical port of the server servicing the request. Not applicable on the Content Engine, so a hyphen (-) is logged.
|
%...P
|
Process ID of the child that serviced the request.
|
%...q
|
Query string (which is preceded by a ? if a query string exists; otherwise, it is an empty string).
|
%...r
|
First line of the request.
|
%...s
|
Status. The translog code always returns the HTTP response code for the request.
|
%...t
|
Time in common log time format (or standard English format).
|
%...{format}t
|
Time in the form given by the format token specified in Table 17-15.
|
%...T
|
Time consumed to serve the request in seconds (a floating point number with 3 decimal places).
|
%...u
|
Remote user.
|
%...U
|
URL path requested, not including query strings.
|
%...v
%...V
|
Value of the host request header field reported if the host appeared in the request. If the host did not appear in the host request header, the IP address of the server specified in the URL is reported.
|
Table 17-15 specifies the format token for the date and time of the format token %...{format}t listed in Table 17-14.
Table 17-15 Format Token for Date and Time
Format Token
|
Value
|
%a
|
Abbreviated weekday name.
|
%A
|
Full weekday name.
|
%b
|
Abbreviated month name.
|
%B
|
Full month name.
|
%c
|
Date and time representation.
|
%C
|
Century number (year/100) as a 2-digit integer.
|
%d
|
Day of the month as a decimal number (01-31).
|
%D
|
Equivalent to %m/%d/%y. (Note that in countries other than the USA, %d/%m/%y is rather common. This means that in international context this format is ambiguous and should not be used.)
|
%e
|
Like %d, the day of the month as a decimal number, but a leading zero is replaced by a space.
|
%G
|
ISO 8601 year with the century as a decimal number. The 4-digit year corresponding to the ISO week number (see %V). This has the same format and value as %y, except that if the ISO week number belongs to the previous or next year, that year is used instead.
|
%g
|
Like %G, but without century; that is, with a 2-digit year (00-99).
|
%h
|
Equivalent to %b.
|
%H
|
Hour as a decimal number using a 24-hour clock (00-23).
|
%I
|
Hour as a decimal number using a 12-hour clock (01-12).
|
%j
|
Day of the year as a decimal number (001-366).
|
%k
|
Hour (24-hour clock) as a decimal number (0-23); single digits are preceded by a blank. (See also %H.)
|
%l
|
Hour (12-hour clock) as a decimal number (1-12); single digits are preceded by a blank. (See also %I.)
|
%m
|
Month as a decimal number (01-12).
|
%M
|
Minute as a decimal number (00-59).
|
%n
|
New line character.
|
%p
|
Either AM or PM according to the given time value, or the corresponding strings for the current locale. Noon is treated as pm and midnight as am.
|
%P
|
Like %p but in lowercase: am or pm or a corresponding string for the current locale.
|
%r
|
Time in a.m. or p.m. notation. This is equivalent to `%I:%M:%S %p.'
|
%R
|
Time in 24-hour notation (%H:%M). For a version including the seconds, see %T below.
|
%s
|
Number of seconds since the epoch; that is, since 1970-01-01 00:00:00 UTC.
|
%S
|
Second as a decimal number (00-61).
|
%t
|
Tab character.
|
%T
|
Time in 24-hour notation (%H:%M:%S).
|
%u
|
Day of the week as a decimal (1-7), Monday being 1. See also %w.
|
%U
|
Week number of the current year as a decimal number (00-53), starting with the first Sunday as the first day of week 01. See also %V and %W.
|
%V
|
ISO 8601:1988 week number of the current year as a decimal number (01-53), where week 1 is the first week that has at least 4 days in the current year, and with Monday as the first day of the week. See also %U and %W.
|
%w
|
Day of the week as a decimal (0-6), Sunday being 0. See also %u.
|
%W
|
Week number of the current year as a decimal number (00-53), starting with the first Monday as the first day of week 01.
|
%x
|
Date representation without the time.
|
%X
|
Time representation without the date.
|
%y
|
Year as a decimal number without a century (00-99).
|
%Y
|
Year as a decimal number, including the century.
|
%z
|
Time zone as hour offset from GMT. Required to emit RFC822-conformant dates (using "%a, %d %b %Y %H:%M:%S %z").
|
%Z
|
Time zone or name or abbreviation.
|
%%
|
Literal % character.
|
Transaction Logging and NTLM Authentication
If your device is configured for NT LAN Manager (NTLM) authentication and uses Apache-style or Extended Squid-style format, you can record the Windows domain name and username in the "authenticated username" field of the transaction log. If the domain name is available, both the domain name and the username are recorded in the "authenticated username" field, in the form domain\username. If only the username is available, only the username is recorded in the "authenticated username" field. If neither a domain name nor a username is available, a "-" (hyphen) is recorded in the field.
Usage Guidelines for Log Files
This section provides some guidelines for working with log files.
Understanding Working Logs
Depending upon where the sysfs is mounted, transactions are logged to a working log on the local disk in one of these files:
•/local1/logs/working.log
•/local2/logs/working.log
Depending upon where the sysfs is mounted, the following log files are logged to a working log on the local disk as follows:
•WMT logs are logged to a working log on the local disk in one of these files:
–/local1/logs/export/working.log
–/local2/logs/export/working.log
•Real-subscriber logs are logged to a working log on the local disk in one of these files:
–/local1/logs/real-subscriber-logs/working.log
–/local2/logs/real-subscriber-logs/working.log
•Cisco-streaming-engine logs are logged to a working log on the local disk in one of these files:
–/local1/logs/cisco-streaming-engine/working.log
–/local2/logs/cisco-streaming-engine/working.log
•Real Proxy logs are logged to a working log on the local disk in one of these files:
–/local1/logs/real-proxy/working.log
–/local2/logs/real-proxy/working.log
Archive Working Log
You can specify the interval at which the working log should be cleared by moving the data to an archive log. The archive log files are located on the local disk in the directory /local1/logs/ or /local2/logs/, depending upon where the sysfs is mounted.
Because multiple archive files are saved, the filename includes the time stamp when the file was archived. Because the files can be exported to an FTP/SFTP server, the filename also contains the IP address of this Content Engine.
The archive file name format is:
celog_IPADDRESS_YYYYMMDD_HHMMSS.txt.
Sanitizing Transaction Logs
You can disguise the IP address and usernames of clients in the transaction log file. The default is that transaction logs are not sanitized. A sanitized transaction log disguises the network identity of a client by changing the IP address in the transaction logs to 0.0.0.0.
Exporting Log Files
In order to facilitate the postprocessing of cache log files, it is possible to export transaction logs to an external host. This feature allows log files to be automatically exported by FTP to an external host at configurable intervals. The username and password used for FTP are configurable, as is the directory to which the log files are uploaded.
The log files automatically have a filename of:
<type>_<ipaddr>_yyyymmdd_hhmmss.txt
where
•<type> represents the type of log file with celog for cache logs such as HTTP, HTTPS, and FTP, and mms_export for Windows Media Technologies (WMT) logs.
•<ipaddr> represents the Content Engine IP address.
•yyyymmdd_hhmmss represents the date and time when the log was archived for export.
Note For WMT logs, there is no .txt extension in the filename.
Exporting Transaction Logs to External FTP Servers
To export transaction logs to an FTP server, you must first enable exporting of transaction logs and then configure the FTP or secure FTP (SFTP) server parameters. This option can support up to four FTP servers. The following information is required for each target FTP server:
•Server IP address or the host name
The Content Engine translates the host name with a DNS lookup and then stores the IP address in the configuration.
•FTP user login and user password
•Path of the directory where transferred files are written
Use a fully qualified path or a relative path for the user login. The user must have write permission to the directory.
You can also compress archived log files into gzip format before exporting them to external FTP servers. The compressed filename has a .gz extension in the filename. This compression feature uses less disk space than that required for noncompressed archived files on both the Content Engine and the FTP export server and also requires less bandwidth during export because of the smaller size of the files to be exported.
Restarting Export After Receiving a Permanent Error from the External FTP Server
When an FTP server returns a permanent error to the Content Engine, the archive transaction logs are no longer exported to that server. You must reenter the Content Engine transaction log export parameters for the misconfigured server to clear the error condition.
A permanent error (Permanent Negative Completion Reply, RFC 959) occurs when the FTP command to the server cannot be accepted, and the action does not take place. Permanent errors can be caused by invalid user logins, invalid user passwords, and attempts to access directories with insufficient permissions or directories that do not exist.
Exporting Transaction Logs to External SFTP Servers
You can also export transaction logs to an SFTP server. You must first enable the feature and configure the SFTP server parameters. The following information is required for each target SFTP server:
•SFTP server IP address or the host name
The Content Engine translates the host name with a DNS lookup and then stores the IP address in the configuration.
•SFTP user login and user password
•Path of the directory where transferred files are written
Use a fully qualified path or a relative path for the user login. The user must have write permission to the directory.
Enabling Transaction Logging with the Content Distribution Manager GUI
To enable transaction logging, follow these steps:
Step 1 From the Content Distribution Manager GUI, choose Devices > Content Engines.
Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.
Step 3 From the Contents pane, choose Content Services > Transaction Logs. The Transaction Logs settings window appears. (See Figure 17-11.)
Figure 17-11 Transaction Log Settings Window
Step 4 Under the General Settings heading, check the Transaction Log Enable check box to activate transaction logging on your device.
Step 5 Check the Enable Sanitize Transaction Logs check box to disguise the IP address and username of clients.
Step 6 Check the Enable File-Marker check box to add entries to the transaction logs, indicating where the files begin and end.
Step 7 Check the Log Windows Domain check box to record the Windows domain name and username in the "authenticated username" field of the transaction log.
Note This option is operational if your device is configured for NT LAN Manager (NTLM) authentication and uses either the Apache-style or the Extended Squid-style transaction log format.
Step 8 Check the Compress Files before Export check box to enable compression of archived log files into gzip format before exporting them to external FTP servers.
Step 9 Click the Log File Format radio button and choose a log file format from the drop-down list. Choose apache, extended-squid, or squid.
Alternatively, click the Log Format Custom radio button if you want to use a custom format for the transaction log. Then enter a custom format string in the field provided. (See the "Custom Format Transaction Logging" section.)
Step 10 Under the Archive Settings heading, in the Maximum Size of Archive field, specify a value for the maximum size of the archive file in kilobytes.
This is the value of the maximum size of the archived file to be maintained on the local disk.
Step 11 Choose the interval when the working log should be cleared by moving data into the archive log. Schedule the interval using the time options shown.
If you want to enable exporting to an FTP server, follow these steps:
Step 1 Under the Export Settings heading, check the Enable Export check box.
Step 2 Specify the interval when the working log should be cleared by moving data into the FTP server. Schedule the interval using the time options shown.
Step 3 Enter an IP address or host name information for the FTP server in the Export Server field.
Note The FTP export feature can support up to four servers. Each server must be configured with a username, password, and directory that are valid for that server.
Step 4 Enter a user ID in the Name field.
Step 5 In the Password and Confirm Password fields, enter a password for the user specified in Step 4.
Step 6 Enter the name of a working directory that will contain the transaction logs in the Directory field.
Note The user specified in the Name field must have write permission to the specified directory.
Step 7 Check the SFTP check box if the server chosen is a secure FTP server.
Step 8 Click Submit to save the settings.
Monitoring with SNMP
ACNS 5.x software supports Simple Network Management Protocol (SNMP), which is an interoperable standards-based protocol that allows external monitoring of the Content Engine through an SNMP agent. ACNS 5.x software supports the following versions of SNMP:
•Version 1 (SNMPv1)—This is the initial implementation of SNMP. Refer to RFC 1157 for a full description of its functionality.
•Version 2 (SNMPv2c)—This is the second release of SNMP, described in RFC 1902. It provides additions to data types, counter size, and protocol operations.
•Version 3 (SNMPv3)—This is the most recent version of SNMP, defined in RFC 2271 through RFC 2275.
SNMPv1 and SNMPv2c do not have any security (that is, authentication or privacy) mechanisms to keep SNMP packet traffic on the wire confidential. As a result, packets on the wire can be detected and SNMP community strings compromised.
To solve the security shortcomings of SNMPv1 and SNMPv2c, SNMPv3 provides secure access to Content Engines by authenticating and encrypting packets over the network. In ACNS 5.x software, SNMPv3 features are added to the SNMP agent in addition to SNMPv1 and SNMPv2c features.
Note Registering a new SNMP agent with your ACNS network, as well as modifying or removing a registered SNMP agent, causes each of your ACNS nodes to restart as they register the configuration change. Restarting your ACNS devices results in a temporary interruption in service across your ACNS network for the time it takes for each of your devices to come back online—usually a few minutes.
Each Cisco device running ACNS 5.x software contains the software necessary to communicate information about device configuration and activity using the SNMP protocol. Before you can begin logging SNMP data, you must acquire and deploy an SNMP manager application for use with the ACNS network.
This section contains the following Content Distribution Manager GUI procedures for configuring SNMP traps, recipients, community strings and group associations, user security model groups, and user access permissions:
•Configuring SNMP Server Settings
•Configuring SNMP Community Settings
•Configuring SNMP Group Settings
•Configuring SNMP User Settings
•Configuring SNMPv2 View Settings
•Configuring SNMP Host Settings
Configuring SNMP Server Settings
To enable the Content Engine to send SNMP traps, follow these steps:
Step 1 Choose Devices > Content Engines. The Content Engines window appears.
Step 2 Click the Edit icon next to the Content Engine that you want to enable. The Modifying Content Engine window appears with the Contents pane on the left.
Step 3 In the Contents pane, choose SNMP > Configuration. The SNMP Server Settings for Content Engine window appears. (See Figure 17-12.) Table 17-16 describes the fields in this window.
Figure 17-12 SNMP Server Settings Window
Table 17-16 SNMP Server Settings
SNMP Server Settings Property
|
Description
|
Traps Configurations
|
|
Content Engine
|
Enables SNMP Content Engine traps:
•Disk-Read—Enables disk read error trap.
•Disk-Write—Enables disk write error trap.
•Disk-Failure—Enables disk failure error trap.
•Overload-Bypass—Enables WCCP overload bypass error trap.
•Transaction-Logging—Enables transaction log write error trap.
|
Enable Entity
|
Enables SNMP entity traps.
|
Enable Event
|
Enables the Event MIB.
|
Enable Config
|
Enables CiscoConfigManEvent error traps.
|
SNMP
|
Enables SNMP-specific traps:
•Authentication—Enables authentication trap.
•Cold-Start—Enables cold start trap.
|
Enable Trap
|
Enables Content Engine, entity, config, and SNMP-specific traps.
|
Other Configurations
|
|
Contact
|
Specifies a string for the MIB-II object sysContact. The name identifies the contact person for this managed node.
|
Location
|
Specifies a string for the MIB-II object sysLocation. The name identifies the physical location of the node.
|
MIB Persistent Event
|
Enables persistence for the SNMP Event MIB.
|
Notify Inform
|
Enables the SNMP notify inform request.
|
Step 4 Check the appropriate check boxes to enable SNMP traps.
Step 5 Click Submit to save the settings.
A "Click Submit to Save" message appears in red next to the current settings when there are pending changes to be saved. You can also revert to the previously configured window settings by clicking Reset. The Reset button is visible only when you apply default or device group settings to change the current device settings but the settings have not yet been submitted.
Step 6 To delete the configured settings for the device, click the Remove Device Settings icon in the taskbar. This icon appears only if you have configured the settings for the Content Engine.
Step 7 To restore the factory default settings to the device, click the Apply Defaults icon in the taskbar.
Step 8 To override the device group settings applied to the device with the factory default settings, click the Override Group Settings with Defaults icon in the taskbar. This icon appears only if you have applied the device group settings to the Content Engine.
Step 9 To override the device group settings that have been applied from device groups with which the device is associated, click the Override Group Settings icon in the taskbar and configure the device settings. This icon appears only if you have applied the device group settings to the Content Engine.
To apply settings from a different device group to this device, choose the device group name from the drop-down list that appears in the taskbar.
Configuring SNMP Community Settings
Note Community strings are listed in the order in which they have been created. The maximum number of SNMP communities that can be created is ten. By default, an SNMP agent is disabled and a community string is not configured. When a community string is configured, it permits read-only access to all agents by default.
To enable the SNMP agent and configure a community string to permit access to the SNMP agent, follow these steps:
Step 1 Choose Devices > Content Engines. The Content Engines window appears.
Step 2 Click the Edit icon next to the Content Engine for which you want to configure a community setting. The Contents pane appears on the left.
Step 3 In the Contents pane, choose SNMP > Community. The Community Configurations for Content Engine window appears.
Step 4 Click the Create New Community icon in the taskbar. The Creating New SNMP Community String for Content Engine window appears. Table 17-17 describes the fields in this window.
Table 17-17 SNMP Community Settings
Field Name
|
Description
|
Community*1
|
Community string used as a password for authentication when accessing the SNMP agent of the Content Engine. Any SNMP message sent to the Content Engine must have the "Community Name" field of the message match the community string defined here in order to be authenticated. Entering a community string enables the SNMP agent. You can enter a maximum of 256 characters in this field.
|
Groupname/rw*
|
Group to which the community string belongs. The rw option allows a read or write group to be associated with this community string. The rw option permits access to only a portion of the MIB subtree. Choose one of the following three options from the drop-down list:
•None—Select this option if you do not want to specify a group name to be associated with the community string. If you enter a group name after selecting this option, an error message is displayed. The Group Name field remains disabled if you select this option.
•Rw—Select this option if you want to allow read-write access to the group associated with a community string. The Group Name field remains disabled if you select this option.
•Group—Select this option if you want to specify a group name.
|
Group Name*
|
Name of the group to which the community string belongs. You can enter a maximum of 256 characters in this field. This field is enabled only if you have chosen the group option in the previous field.
|
Step 5 Enter the community string, whether read-write access to the group is allowed, and group name in the appropriate fields.
Step 6 Click Submit to save the settings.
Configuring SNMP Group Settings
Note Groups are listed in the order in which they have been created. The maximum number of SNMP groups that can be created is ten.
To define a user security model group, follow these steps:
Step 1 Choose Devices > Content Engines. The Content Engines window appears.
Step 2 Click the Edit icon next to the Content Engine fro which you want to create a group. The Modifying Content Engine window appears with the Contents pane on the left.
Step 3 In the Contents pane, choose SNMP > Group. The Group Configurations for Content Engine window appears.
Step 4 Click the Create New Group icon in the taskbar. The Creating New SNMP Group String for Content Engine window appears. Table 17-18 describes the fields in this window
Table 17-18 SNMP Group Settings
Field Name
|
Description
|
Name
|
Name of the SNMP group. You can enter a maximum of 256 characters.
|
Sec. Model
|
Security model for the group. Choose one of the following options from the drop-down list:
•v1—Version 1 security model (SNMP Version 1 [noAuthNoPriv])
•v2c—Version 2c security model (SNMP Version 2 [noAuthNoPriv])
•v3-auth—User security level SNMP Version 3 AuthNoPriv
•v3-noauth—User security level SNMP Version 3 noAuthNoPriv
•v3-priv— User security level SNMP Version 3 AuthPriv
|
Read View
|
Name of the view (a maximum of 64 characters) that enables you only to view the contents of the agent. By default, no view is defined. In order to provide read access to users of the group, a view must be specified.
|
Write View
|
Name of the view (a maximum of 64 characters) that enables you to enter data and configure the contents of the agent. By default, no view is defined.
|
Notify View
|
Name of the view (a maximum of 64 characters) that enables you to specify a notify, inform, or trap. By default, no view is defined.
|
Step 5 Enter the SNMP group configuration name, security model, and names of the read, write, and notify views in the appropriate fields..
Step 6 Click Submit to save the settings.
Configuring SNMP User Settings
Note Users are listed in the order in which they have been created. The maximum number of users that can be created is ten.
To define a user who can access the SNMP engine, follow these steps:
Step 1 Choose Devices > Content Engines. The Content Engines window appears.
Step 2 Click the Edit icon next to the Content Engine for which you want to create an SNMP user. The Modifying Content Engine window appears with the Contents pane on the left.
Step 3 In the Contents pane, choose SNMP > User. The User Configurations for Content Engine window appears.
Step 4 Click the Create New User icon in the taskbar. The Creating New SNMP User for Content Engine window appears. Table 17-19 describes the fields in this window.
Table 17-19 SNMP User Settings
Field Name
|
Description
|
Name
|
String representing the name of the user (256 characters maximum) who can access the Content Engine.
|
Group
|
Name of the group (256 characters maximum) to which the user belongs.
|
Remote SnmpID
|
Globally unique identifier for a remote SNMP entity. In order to send an SNMPv3 message to the Content Engine, at least one user with a remote SnmpID must be configured on the Content Engine. The SnmpID must be entered in octet string format.
|
Auth Algorithm
|
Authentication algorithm that ensures the integrity of SNMP packets during transmission. Choose one of the following three options from the drop-down list:
•No-auth—Requires no security mechanism to be turned on for SNMP packets.
•MD5—Provides authentication based on the hash-based Message Authentication Code Message Digest 5 (HMAC-MD5) algorithm.
•SHA—Provides authentication based on the hash-based Message Authentication Code Secure Hash (HMAC-SHA) algorithm.
|
Authentication Password
|
String (256 characters maximum) that configures the user authentication (HMAC-MD5 or HMAC-SHA) password. The number of characters is adjusted to fit the display area if it exceeds the limit for display.
This field is optional if the no-auth option is chosen for the authentication algorithm. Otherwise, this field must contain a value.
|
Confirmation Password
|
Authentication password for confirmation. The reentered password must be the same as the one entered in the previous field.
|
Private Password
|
String (256 characters maximum) that configures the authentication (HMAC-MD5 or HMAC-SHA) parameters to enable the SNMP agent to receive packets from the SNMP host. The number of characters will be adjusted to fit the display area if it exceeds the limit for display.
|
Confirmation Password
|
Private password for confirmation. The reentered password must be the same as the one entered in the previous field.
|
Step 5 In the appropriate fields, enter the user name, group to which the user belongs, engine identity of the remote entity to which the user belongs, authentication algorithm used to protect SNMP traffic from tampering, user authentication parameters, and authentication parameters for the packet.
Step 6 Click Submit to save the settings.
Configuring SNMPv2 View Settings
Note Views are listed in the order in which they have been created. The maximum number of views that can be created is ten.
To define a Version 2 SNMP (SNMPv2) MIB view, follow these steps:
Step 1 Choose Devices > Content Engines. The Content Engines window appears.
Step 2 Click the Edit icon next to the Content Engine for which you want to create an SNMPv2 view. The Contents pane appears on the left.
Step 3 In the Contents pane, choose SNMP > View. The View Configurations for Content Engine window appears. Table 17-20 describes the fields in this window.
Table 17-20 SNMPv2 View Settings
Field Name
|
Description
|
Name
|
String representing the name of this family of view subtrees (256 characters maximum). The family name must be a valid MIB name such as entity MIB.
|
Family
|
Object identifier (256 characters maximum) that identifies a subtree of the MIB.
|
View Type
|
View option that determines the inclusion or exclusion of the MIB family from the view. Choose one of the following two options from the drop-down list:
•Included—The MIB family is included in the view.
•Excluded—The MIB family is excluded from the view.
|
Step 4 Click the Create New View icon in the taskbar. The Creating New SNMP View for Content Engine window appears.
Step 5 Enter the view name, family name, and view type in the appropriate fields.
Step 6 Click Submit to save the settings.
Configuring SNMP Host Settings
Note Hosts are listed in the order in which they have been created. The maximum number of SNMP hosts that can be created is four.
To configure SNMP host settings, follow these steps:
Step 1 Choose Devices > Content Engines. The Content Engines window appears.
Step 2 Click the Edit icon next to the Content Engine for which you want to define an SNMP host. The Modifying Content Engine window appears with the Contents pane on the left.
Step 3 In the Contents pane, choose SNMP > Host. The Host Configurations for Content Engine window appears.
Step 4 Click the Create New Host icon in the taskbar. The Creating New SNMP Host for Content Engine window appears. Table 17-21 describes the fields in this table.
Table 17-21 SNMP Host Settings
Field Name
|
Description
|
Trap Host
|
Host name or IP address of the SNMP trap host that is sent in SNMP trap messages from the Content Engine.
|
Community/User
|
Name of the SNMP community or user (256 characters maximum) that is sent in SNMP trap messages from the Content Engine.
|
Authentication
|
Security model to use for sending notification to the recipient of an SNMP trap operation. Choose one of the following options from the drop-down list:
•No-auth—Sends notification without any security mechanism.
•v2c-noauth—Sends notification using Version 2c security.
•Model v3-auth—Sends notification using SNMP Version 3 AuthNoPriv.
•Security Level v3-noauth—Sends notification using SNMP Version 3 NoAuthNoPriv security.
•Level v3-priv—Sends notification using SNMP Version 3 AuthPriv security.
|
Retry
|
Number of retries (1-10) allowed for the inform request. The default is 2 tries.
|
Timeout
|
Timeout for the inform request in seconds (1-1000). The default is 15 seconds.
|
Step 5 Enter the host name or IP address of an SNMP trap host, SNMP community or user name, security model to send notification, and retry count and timeout for inform requests.
Step 6 Click Submit to save the settings.
Supported MIBs
The SNMP agent supports the following MIBs:
•CISCO-CDP-MIB
•ENTITY-MIB
•CISCO-ENTITY-ASSET-MIB
•MIB-II
•CISCO-CONFIG-MAN-MIB
•CISCO-CONTENT-ENGINE-MIB (supports streaming media-related MIB objects)
•HOST-RESOURCES-MIB
•EVENT-MIB
The EVENT-MIB can set the threshold on any MIB variables supported by ACNS 5.x software and store the threshold permanently on disk. The HOST-RESOURCES-MIB provides statistics on system resources.
The CISCO-CONTENT-ENGINE-MIB is extended to incorporate MIB objects related to streaming. The WMT, Cisco Streaming Engine, and RealProxy MIB groups incorporate statistics about the WMT server or proxy, Cisco Streaming Engine, and Real Proxy. For each 64-bit counter MIB object, a 32-bit counter MIB object is implemented so that SNMP clients using the SNMPv1 protocol can retrieve data associated with 64-bit counter MIB objects. The MIB objects of each of these groups are read-only.
•The WMT MIB group provides statistics about WMT proxy and server performance. Twenty-eight MIB objects are implemented in this group. Six of these MIB objects are implemented as 64-bit counters.
•The Cisco Streaming Engine MIB group provides statistics about RTSP streaming engine performance. Seven MIB objects are implemented in this group. Two of these MIB objects are implemented as 64-bit counters.
•The RealProxy MIB group provides statistics about RealProxy performance. Fourteen MIB objects are implemented in this group.
Use the following link to access these MIBs:
ftp://ftp.cisco.com/pub/mibs/v2/
Key SNMP CLI Commands
Use the snmp-server group global configuration command to select one of the three SNMP versions, SNMPv1, SNMPv2c, or SNMPv3. Use the no form of this command to remove the specified version. Refer to the Cisco ACNS Software Command Reference, Release 5.1 for more information on how to use this and other SNMP commands.
The snmp-server community string command provides view-based access control for SNMPv1, SNMPv2c, and SNMPv3 but also continues to provide backward compatibility between different versions. The previous version of this command did not have an option to create a community string that allows SNMP messages to execute a set operation on a MIB object. An rw option has been introduced for this purpose. Also, the previous version of the SNMP agent did not provide selective access control to MIB objects. Access to any MIB object was denied or granted based on authentication of the SNMP community string. With the introduction of view-based access control, it is now possible to configure a community string that grants access to only part of the MIB subtree. To provide backward compatibility with the previous version of this command, a default read group or default write group (if the rw option is specified on the command line) is associated with the community string if no group name is specified. Both of these default groups are hidden from users and not displayed in the configuration file or in the show snmp group command, but are created during initialization of the SNMP agent.
Note The SNMP agent is disabled by default, and a community string is not configured.
The following example enables the SNMP agent and assigns the community string comaccess to SNMP:
507-1(config)# snmp-server community comaccess
The preceding example defines a community string comaccess used as a password for authentication when you access the SNMP agent of the Content Engine. Any SNMP message sent to the Content Engine must have the "Community Name" field of the message match the community string defined here in order to be authenticated. Entering a community string enables the SNMP agent.
The following example disables the SNMP agent and removes the previously defined community string.
507-1(config)# no snmp-server community
Configuring SNMP Traps Using the CLI
To enable the Content Engine to send SNMP traps, use the snmp-server enable traps global configuration command. If you do not enter the snmp-server enable traps command, no traps are sent. Use the no form of this command to disable all SNMP traps or only SNMP authentication traps.
The snmp-server enable traps command is used in conjunction with the snmp-server host command. Use the snmp-server host command to specify which hosts or hosts receive SNMP traps. To send traps, you must configure at least one host.
For a host to receive a trap, both the snmp-server enable traps command and the snmp-server host command for that host must be enabled.
In addition, SNMP must be enabled with the snmp-server community command.
To disable the sending of the MIB-II SNMP authentication trap, you must enter the command no snmp-server enable traps snmp authentication.
The following example enables the Content Engine to send all traps to the host 172.31.2.160 using the community string public:
ContentEngine(config)# snmp-server enable traps
ContentEngine(config)# snmp-server host 172.31.2.160 public
The following example disables all traps:
Content Engine (config)# no snmp-server enable traps
