Cisco ACNS キャッシング/ストリーミング コンフィギュレーション ガイド
モニタリングおよびトラブルシュー ティング
モニタリングおよびトラブルシューティング
発行日;2012/02/03 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

モニタリングおよびトラブルシューティング

SNMP を使用したモニタリング

SNMP の異なるバージョンの概要

SNMP セキュリティ モデルとセキュリティ レベル

サポートされる MIB

ContentEngine でのSNMP エージェントのイネーブル化

SNMP ユーザの定義

ContentEngine GUI を使用した SNMPv3 ユーザの定義

CLI コマンドを使用する SNMPv3 ユーザの定義

SNMP トラップを送信するための ContentEngine の設定

ContentEngine GUI を使用した SNMP トラップの設定

CLI コマンドを使用した SNMP トラップの設定

Cisco Discovery Protocol の使用

CDP イネーブル化の例

トランザクションのロギング

トランザクション ログ形式

Squid スタイルのトランザクション ロギング

拡張 Squid スタイルのトランザクション ロギング

拡張 Squid スタイル形式

Apache スタイルのトランザクション ロギング

トランザクション ロギング時のカスタム形式

トランザクション ロギングと NTLM 認証

ログ ファイルの使用ガイドライン

作業ログの理解

アーカイブ作業ログ

トランザクション ログのサニタイジング

トランザクション ログ ファイルのエクスポート

トランザクション ログの外部の FTP または SFTP サーバへのエクスポート

ContentEngine GUI を使用したトランザクション ロギングのイネーブル化と設定

ContentEngine GUI を使用したトランザクション ログの FTP、または SFTP サーバへのエクスポート

CLI コマンドを使用したトランザクション ロギングのイネーブル化と設定

システム ロギングの設定

CiscoWorks2000 の使用

ContentEngine GUI を使用したシステム ロギングの設定

CLI コマンドを使用したシステム ロギングの設定

Syslog 優先レベルの RealProxy エラー コードへのマッピング

HTTP カスタム エラー ページの作成

使用上のガイドライン

ContentEngine GUI を使用した HTTP カスタム エラー ページの設定

CLI コマンドを使用した HTTP カスタム エラー ページ

HTTP カスタム エラー メッセージの設定例

Traceroute のサポート

モニタリングおよびトラブルシューティング

この章では、Simple Network Management Protocol(簡易ネットワーク管理プロトコル; SNMP)を使用して Content Engine をモニタリングする方法を説明します。またこの章では、Content Engine がサポートしているトランザクション ロギング、およびシステム ロギング機能の使用法も説明します。さらにこの章では、Traceroute の使用法も説明します。この章の構成は、次のとおりです。

「SNMP を使用したモニタリング」

「トランザクションのロギング」

「システム ロギングの設定」

「HTTP カスタム エラー ページの作成」

「Traceroute のサポート」


) この章で使用される CLI コマンドの構文と使用法については、『Cisco ACNS Software Command Reference, Release 5.1』を参照してください。


SNMP を使用したモニタリング

SNMP (簡易ネットワーク管理プロトコル)は、相互運用可能な標準ベースのプロトコルであり、SNMP エージェントを使用して Content Engine を外部からモニタリングできるようにします。

SNMP 管理ネットワークは、3 つの主要なコンポーネントで構成されています。それらは、管理対象デバイス、エージェント、および管理システムです。

管理対象デバイスとは、SNMP エージェントを含み、管理対象ネットワークに置かれるネットワーク ノードです。

管理対象デバイスは、管理情報の収集と保存を行い、SNMP を使用して、SNMP を使用する管理システムにこの情報を提供します。管理対象デバイスには、ルータ、アクセス サーバ、スイッチ、ブリッジ、ハブ、コンピュータ ホスト、およびプリンタがあります。

SNMP エージェントとは、管理対象デバイスに置かれるソフトウェア モジュールです。エージェントは、管理情報をローカル側で認識し、SNMP と両立可能な形式にその情報を変換します。SNMP エージェントは、管理情報ベース (MIB)からデータを収集します。MIB は、デバイス パラメータとネットワーク データについての情報のリポジトリです。また、このエージェントは、トラップ、または特定イベントの通知をマネージャに送信することもできます。

ACNS 5.x を実行している各 Content Engine には、Content Engine のデバイス設定およびアクティビティに関する情報収集の役割を担う SNMP エージェントがあります。この SNMP 情報にアクセスする前に、SNMP 管理アプリケーションが管理ステーション上に導入済みであることが必要です。この SNMP 管理ステーションは、Content Engine から情報を取得するために、SNMP を使用してデバイス エージェントに SNMP Get 要求を送信することから、「SNMP ホスト」と呼ばれます。

1. SNMP 管理ステーション(SNMP ホスト)は、SNMP を使用して Content Engine に情報を要求します。

2. SNMP 要求の受信後、デバイス エージェントは、各デバイス(Content Engine)に関する情報を含むテーブルにアクセスします。このテーブル、すなわちデータベースは、Management Information Base(MIB; 管理情報ベース)と呼ばれます。


) Content Engine 上の SNMP エージェントは、異常な状況下では、SNMP ホストとの通信を開始するのみで、このエージェントにホストへ送信する必要のあるトラップが設定されているときに、通信を開始します。このトピックに関する詳細は、「SNMP トラップを送信するための Content Engine の設定」を参照してください。


3. デバイス エージェントは、MIB 内で指定された情報を特定した後、SNMP を使用してその情報を SNMP ホストに送信します。

図 16-1 は、Content Engine がローカルに配置されているときのこれら SNMP 動作を示します。

図 16-1 ローカルに配置された ACNS Content Engine を使用する SNMP コンポーネント

 

SNMP の異なるバージョンの概要

ACNS 5 x ソフトウェアは、次のバージョンの SNMP をサポートします。

バージョン 1(SNMPv1) :これは、SNMP の最初に実現された製品です。機能の詳細については、RFC 1157 を参照してください。

バージョン 2(SNMPv2c) :これは、2 番目のリリースの SNMP であり、RFC 1902 に記述されています。データ タイプ、カウンタ サイズ、およびプロトコル オペレーションに追加がされました。

バージョン 3(SNMPv3) :これは、最新バージョンの SNMP であり、RFC 2271 ~ RFC 2275 で定義されています。

SNMP セキュリティ モデルとセキュリティ レベル

SNMPv1 と SNMPv2c には、通信回線上の SNMP パケット トラフィックを機密にする、セキュリティ(つまり認証またはプライバシ)メカニズムがありません。その結果、通信回線上のパケットをのぞき見することが可能であり、SNMP コミュニティ ストリングが漏えいする可能性があります。

SNMPv1 と SNMPv2c のセキュリティ上の欠点を補うために、SNMPv3 は、ネットワーク上のパケットの認証と暗号化を行って、Content Engine への安全なアクセスを確保します。ACNS 5.x ソフトウェアの SNMP エージェントは、SNMPv1 と SNMPv2c 以外に、SNMPv3 もサポートしています。

SNMPv3 は、次のセキュリティ機能を備えています。

メッセージの完全性 :伝送中のパケットに何の干渉もされないことを保証します。

認証 :メッセージが正当なソースから発信されたかどうかを判別します。

暗号化 :パケットの内容を暗号化して、無許可のソースから見えないようにします。

SNMPv3 は、セキュリティ モデルとセキュリティ レベルの両方を備えています。セキュリティ モデルとは、ユーザ、およびそのユーザのグループ用にセットアップされた認証プロセスです。セキュリティ レベルとは、セキュリティ モデル内で許容されるセキュリティのレベルです。セキュリティ モデルとセキュリティ レベルを組み合せると、SNMP パケットの処理時にどのセキュリティ プロセスを使用するかが決まります。セキュリティ モデルが 3 つあります。SNMPv1、SNMPv2c、および SNMPv3 です。

表 16-1 では、セキュリティ モデルとセキュリティ レベルの組み合せを説明します。

 

表 16-1 SNMP セキュリティ モデルとセキュリティ レベル

モデル
レベル
認証
暗号化
プロセス

v1

noAuthNoPriv

コミュニティ ストリング

なし

ユーザ認証にコミュニティ ストリングの一致を使用する。

v2c

noAuthNoPriv

コミュニティ ストリング

なし

ユーザ認証にコミュニティ ストリングの一致を使用する。

v3

noAuthNoPriv

Username

なし

ユーザ認証にユーザ名の一致を使用する。

v3

AuthNoPriv

Message Digest 5 (MD5)、
または Secure Hash Algorithm (SHA)

なし

Hash-Based Message Authentication Code (HMAC)-MD5、または HMAC-SHA アルゴリズムに基づいて認証を行う。

v3

AuthPriv

MD5 または SHA

あり

HMAC-MD5、または HMAC-SHA アルゴリズムに基づいて認証を行う。cipher block chaining (CBC)-DES (DES-56) 標準に基づいて、Data Encryption Standard (DES) の 56 ビット暗号化(パケット認証)を行う。

SNMPv3 エージェントは、次のモードで使用できます。

noAuthNoPriv モード(つまり、パケットに対してオンになっているセキュリティ メカニズムがない)。

AuthNoPriv モード(プライバシ アルゴリズム [DES 56] を使用して暗号化する必要がないパケット用)。

AuthPriv モード(暗号化が必要なパケット用。プライバシとしては、パケットに対して認証が実行されることを要求する)。

SNMPv3 を使用すると、ユーザは、データを改ざんされる心配がなく、SNMP エージェントから管理情報を安全に収集できます。また、Content Engine の設定を変更する SNMP セット パケットなどの機密情報が暗号化されるので、ワイヤ上で内容が流出するのを防止できます。さらに、グループ ベースの管理モデルでは、異なるユーザが、異なるアクセス権限を使って同じ SNMP エージェントにアクセスすることも可能です。

サポートされる MIB

ACNS 5 x ソフトウェアの SNMP のインプリメンテーションでは、次の MIB をサポートしています。

MIB-II

ENTITY-MIB

HOST-RESOURCES-MIB

CISCO-CONTENT-ENGINE-MIB

CISCO-ENTITY-ASSET-MIB

CISCO-CONFIG-MAN-MIB

CISCO-CDP-MIB

前述の MIB にアクセスするには、次のリンクを使用してください。

ftp://ftp.cisco.com/pub/mibs/v2/


) ACNS 5.0 ソフトウェアでは、WMT、RealProxy および Cisco Streaming Engine の統計情報のストリーミングをサポートするために、CISCO-CONTENT-ENGINE-MIB がアップデートされました。


ACNS 5.1 ソフトウェア リリースでは、Content Engine 上で SNMP アクセスを制御するために、IP アクセス制御リスト(ACL)を使用できます。IP ACL の詳細な定義については、「IP アクセス コントロール リストの作成および管理」を参照してください。

Content Engine でのSNMP エージェントのイネーブル化

デフォルトでは、SNMP エージェントは Content Engine 上でディセーブルとなっており、SNMP コミュニティ ストリングは定義されていません。SNMP コミュニティ ストリングは、Content Engine 上の SNMP エージェントにアクセスするときに、認証用パスワードとして使用されます。認証されるには、Content Engine に送信されるすべての SNMP メッセージに含まれる Community Name フィールドが、その Content Engine 上で定義された SNMP コミュニティ ストリングと一致する必要があります。

SNMP コミュニティ ストリングが Content Engine 上で定義されていると、SNMP エージェントは Content Engine 上でイネーブルになります。SNMP コミュニティ ストリングを定義し、SNMP エージェントをイネーブルにするには、CLI または Content Engine GUI を使用して次の手順を実行します。

CLI から、 snmp-server community コマンドを使用します。たとえば、次のとおりです。

ContentEngine(config)# snmp-server community comaccess
 

Content Engine GUI から、 System > SNMP の順に選択します。表示される SNMP ウィンドウで、Community フィールドまでスクロールし、図 16-2 に示されているように、SNMP コミュニティ ストリングを入力します。 Update をクリックします。

図 16-2 SNMPv1 および SNMPv2 用の SNMP ウィンドウ

 

SNMPv3 プロトコルを SNMP 要求に使用する場合、次のステップで、SNMP ユーザ アカウントを定義します。SNMP ユーザ アカウントは、SNMP を介した Content Engine へのアクセスに使用されます。

SNMPv 3 ユーザ アカウントを Content Engine 上に作成する方法に関する詳細は、次項、「SNMP ユーザの定義」を参照してください。

SNMP ユーザの定義

SNMP ユーザをローカルに配置する Content Engine 上に定義するときには、次の点に注意してください。

SNMPv3 プロトコルを SNMP 要求に使用する場合、Content Engine が SNMP を介してアクセスされるように、少なくとも 1 つの SNMP v3 ユーザ アカウントを Content Engine 上に定義する必要があります。

SNMPv1 または SNMPv2c セキュリティ モデルを使用して定義されたグループは、SNMP ユーザと関連付けないでください。SNMP ユーザはコミュニティ ストリングのみに関連付けられます。

SNMPv3 ユーザ アカウント定義に、Content Engine GUI または CLI を使用できます。

Content Engine GUI を使用した SNMPv3 ユーザの定義

ローカルに配置する Content Engine で、SNMPv3 ユーザ アカウントを設定し、イネーブルにする手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 System > SNMP の順に選択します。SNMPv1 または SNMPv2 設定用の SNMP ウィンドウが表示されます(図 16-3 を参照)。

図 16-3 SNMPv1 および SNMPv2 用の SNMP ウィンドウ

 

ステップ 2 SNMP ウィンドウの一番下までスクロールします。

ステップ 3 SNMP ウィンドウの一番下で、SNMPv3 Configuration Click here リンクをクリックします。SNMPv3(SNMPv3 ユーザ アカウントを含む)設定用の SNMP ウィンドウが表示されます(図 16-4 を参照)。

図 16-4 SNMPv3 ウィンドウ

 

ステップ 4 SNMP v3 ウィンドウ(図 16-5 を参照)の SNMPV3 User configuration セクションまでスクロールします。

図 16-5 SNMPv3 ユーザ アカウントの定義

 

ステップ 5 SNMPV3 User configuration フィールドとドロップダウン リストを使用して、新規の SNMPv3 ユーザ アカウントをこの Content Engine 上に定義します。

a. Name フィールドに、SNMP ユーザの名前を入力します。文字、数字、ダッシュ、およびアンダースコアの使用は許可されますが、ブランクは使用できません。この名前が、Content Engine 上の SNMP エージェントと通信しようとする SNMP ホスト上でのユーザー名です。

b. Group フィールドに、SNMP ユーザが所属するグループ名を入力します。

c. Remote SnmpID フィールドに、SNMP ユーザのうちの少なくとも 1 人に対してリモート SNMP エンティティのグローバルに一意な識別子(たとえば、SNMP ネットワーク管理ステーション)を入力します。


ヒント SNMPv3 通知メッセージを送信するには、リモート SnmpID オプションを持つ SNMPv3 ユーザが少なくとも 1 人、Content Engine 上に設定されている必要があります。SnmpID は、octet ストリング形式で入力されます。たとえば、リモート SNMP エンティティが 192.147.142.129 である場合、octet ストリングは 00:00:63:00:00:00:a1:c0:93:8e:81 となります。

d. Auth-Algorithm ドロップダウン リストから、SNMP ユーザ認証に使用するアルゴリズムを選択します( md5 sha 、または none )。デフォルトでは、 none が選択されています。

Hashed-Based Message Authentication Code Message Digest 5(HMAC-MD5-96) 認証レベルには、md5 を選択します。

HMAC Secure Hash Algorithm (HMAC-SHA-96) 認証レベルには、sha を選択します。

e. オプションの Auth-Password フィールドに、HMAC MD5 ユーザ認証パスワードを入力します。このフィールドは、 md5 を認証タイプとして選択した場合にのみ、使用されます。

f. オプションの Priv-Password フィールドに、HMAC MD5 ユーザのプライベート パスワードを入力します。このフィールドは、 md5 を認証タイプとして選択した場合にのみ、使用されます。これは、SNMP エージェントがホストからのパケット受信をできるようにするストリングです。

ステップ 6 Update をクリックして、新規の SNMPv3 ユーザ アカウントを追加します。作成されたばかりの新規ユーザ アカウントが SNMPv3 ウィンドウにリストされます。

ステップ 7 引き続き、SNMPv3 ユーザ アカウントを追加、あるいは既存の SNMPv3 ユーザ アカウントを削除します。既存の SNMPv3 ユーザ アカウントを削除する場合、削除しようとするアカウントの隣りにある Delete チェックボックスをクリックします。

ステップ 8 Update を再度クリックして、SNMPv3 ユーザ アカウントに加えた変更を保存します。


 

CLI コマンドを使用する SNMPv3 ユーザの定義

SNMPv3 ユーザ アカウントを Content Engine(SNMP サーバ)上に定義するには、 snmp-server user グローバル設定コマンドを使用します。SNMP アクセスを除去するには、このコマンドの no 形式を使用します。

snmp-server user name group [ auth { md5 password [ priv password ] | sha password [ priv password ]} | remote octetstring [ auth { md5 password [ priv password ] | sha password [ priv password ]}]]

表 16-2 では、 snmp-server user コマンドに関するパラメータを説明します。

 

表 16-2 snmp-server user 用の CLI コマンド パラメータ

パラメータ
説明

name

SNMP ユーザの名前。

group

SNMP ユーザが所属するグループ。

auth

(オプション)ユーザ認証パラメータを設定する。

md5

HMAC MD5 認証アルゴリズムを設定する。

password

HMAC MD5 ユーザ認証パスワード。

priv

(オプション)パケット用の認証パラメータを設定する。

password

HMAC MD5 ユーザ プライベート パスワード。

sha

HMAC SHA 認証アルゴリズムを設定する。

password

HMAC SHA 認証パスワード。

remote

(オプション)ユーザが所属するリモート SNMP エンティティのエンジン アイデンティティを指定する。

octetstring

エンジン アイデンティティ octet ストリング。

次の例では、SNMPv3 ユーザ アカウントが Content Engine で作成されています。この SNMPv3 user は acme という名前で、 admin という名前のグループに属しています。この SNMP ユーザ アカウントは認証パスワードでセットアップされていなかったため、Content Engine 上の SNMP エージェントは、このユーザからの SNMP 要求の認証を実行しません。

ContentEngine(config)# snmp-server user acme admin
 

SNMP トラップを送信するための Content Engine の設定

ACNS 5.x を実行している各 Content Engine には、Content Engine のデバイス設定、およびアクティビティに関する情報収集の役割を担う SNMP エージェントがあります。この SNMP 情報にアクセスする前に、SNMP 管理アプリケーションが管理ステーション上に導入済みであることが必要です。この SNMP 管理ステーションは、Content Engine から情報を取得するために、SNMP を使用してデバイス エージェントに SNMP Get 要求を送信することから、「SNMP ホスト」と呼ばれます。

1. SNMP 管理ステーション(SNMP ホスト)は、SNMP を使用して Content Engine から情報を要求します。

2. SNMP 要求の受信後、デバイス エージェントは、各デバイス(Content Engine)に関する情報を含むテーブルにアクセスします。このテーブル、すなわちデータベースは、Management Information Base(MIB; 管理情報ベース)と呼ばれます。


) Content Engine 上の SNMP エージェントは、異常な状況下では、SNMP ホストとの通信を開始するのみで、このエージェントにホストへ送信する必要のあるトラップが設定されているときに、通信を開始します。このトピックに関する詳細は、「SNMP トラップを送信するための Content Engine の設定」を参照してください。


3. デバイス エージェントは、MIB 内で指定された情報を特定した後、SNMP を使用してその情報を SNMP ホストに送信します。

Content Engine GUI または CLI を使用して、ローカルに配置された Content Engine で SNMP トラップを設定できます。

Content Engine GUI を使用した SNMP トラップの設定

ローカルに配置する Content Engine 上で SNMP トラップを設定する手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 System > SNMP の順に選択します。SNMP ウィンドウが表示されます(図 16-6 を参照)。

図 16-6 SNMPv1 および SNMPv2 用の SNMP ウィンドウ

 

ステップ 2 SNMP ウィンドウから、次のどちらかを実行します。

SNMP トラップを特定の SNMP ホストに送信するように Content Engine の SNMP v1、または SNMPv2 エージェントを設定するには、この SNMP ウィンドウに設定項目を入力し、 Update をクリックします。

たとえば、必須フィールドの 1 つに、SNMP トラップ ホストを定義するフィールドがあります。Content Engine から SNMP トラップ メッセージで送信される SNMP トラップ ホストのホスト名、または IP アドレスを指定する必要があります。

SNMP トラップを特定の SNMP ホストに送信するように Content Engine の SNMP v3 エージェントを設定するには、SNMP ウィンドウの一番下までスクロールします。SNMPv3 Configuration Click here リンクをクリックします。SNMP v3 エージェントを Content Engine 上で設定するための SNMP ウィンドウが表示されます(図 16-4 を参照)。SNMPv3 ウィンドウを使用して、この Content Engine 用に SNMP トラップおよび SNMP v3 ユーザ アカウントを設定します。

SNMP Version 3 ユーザ アカウントの設定に関する詳細は、「Content Engine GUI を使用した SNMPv3 ユーザの定義」を参照してください。SNMP ウィンドウのフィールドに関する詳細は、SNMP ウィンドウの一番下の Help ボタンをクリックして、状況依存ヘルプを使用して参照できます。


 

CLI コマンドを使用した SNMP トラップの設定

ローカルに配置する Content Engine 上で SNMP トラップを設定するときに、CLI を使用することもできます。SNMP トラップをローカルに配置する Content Engine 上に設定するときに、CLI を使用する場合は、次のガイドラインを使用してください。

snmp-server enable traps グローバル設定コマンドを使用して、トラップをイネーブルにします。 snmp-server enable traps コマンドを入力しない場合、トラップは送信されません。すべての SNMP トラップ、または SNMP 認証トラップだけをディセーブルにするには、このコマンドの no 形式を使用します。

snmp-server enable traps コマンドは、 snmp-server host コマンドと一緒に使用されます。
snmp-server host
コマンドは、SNMP トラップを Content Engine から受信するホスト(複数)を指定する場合に使用します。トラップを送信するには、少なくとも 1 つの SNMP トラップ ホストを設定する必要があります。

SNMP ホストがトラップを受信するには、そのホストに対する snmp-server enable traps コマンド、および snmp-server host コマンドの両方がイネーブルでなければなりません。さらに、 snmp-server community コマンドを使用して SNMP をイネーブルにする必要もあります。

MIB-II SNMP 認証トラップの送信をディセーブルにするには、 no snmp-server enable traps snmp authentication コマンドを入力する必要があります。

3 つの SNMP バージョン(SNMPv1、SNMPv2c、または SNMPv3)の中からどれかを選択するには、 snmp-server group グローバル設定コマンドを使用します。指定したバージョンを除去するには、このコマンドの no 形式を使用します。

snmp-server community string コマンドは、SNMPv1、SNMPv2c、および SNMPv3 に対するビュー ベースのアクセス制御を行いますが、バージョン相互間の下位互換性も引き続き維持します。

snmp-server community string コマンドの旧バージョンには、SNMP メッセージが MIB オブジェクト上で一連の動作を実行できるようにする、コミュニティ ストリングを作成するオプションがありませんでした。そのため、 rw オプションが導入されました。また、旧バージョンの SNMP エージェントは、MIB オブジェクトへの選択的なアクセス制御も備えておらず、どの MIB オブジェクトへのアクセスも、SNMP コミュニティ ストリングの認証に基づいて拒否または許可されていました。

ビュー ベースのアクセス制御を導入することにより、MIB サブツリーの一部だけへのアクセスを許可するコミュニティ ストリングを設定できるようになりました。このコマンドの旧バージョンとの下位互換性を維持するために、グループ名が指定されない場合、デフォルトの読み取りグループ、またはデフォルトの書き込みグループ( rw オプションがコマンド行で指定される場合)が、コミュニティ ストリングに関連付けられます。これらのデフォルト グループはどちらも、ユーザには非表示であり、コンフィギュレーション ファイルまたは show snmp group コマンドに表示されません。しかしこれらのデフォルト グループは、SNMP エージェントの初期化時に作成されます。


) SNMP エージェントは、デフォルトで使用不可であり、コミュニティ ストリングは設定されません。


ローカルに配置する Content Engine 上で CLI を使用して SNMP トラップを設定する場合は、 表 16-3 を参照してください。このコマンドや他の SNMP コマンドの使用方法の詳細は、『Cisco ACNS Software Command Reference, Release 5.1』を参照してください。

 

表 16-3 ローカルの Content Engine 上で SNMP トラップ設定を行う CLI の例

目的
コマンド

Content Engine 上の SNMP トラップすべてをイネーブルにする。

ContentEngine(config)# snmp-server enable traps

Content Engine がコミュニティ ストリング、 public を使用して、すべての SNMP トラップをホスト 172.31.2.160 に送信するように設定する。

ContentEngine(config)# snmp-server enable traps
ContentEngine(config)# snmp-server host 172.31.2.160 public

SNMP エージェントをイネーブルにし、コミュニティ ストリング comaccess を SNMP に割り当てる。

ContentEngine(config)# snmp-server community comaccess
 

前述の例では、Content Engine の SNMP エージェントにアクセスするときに、認証用のパスワードとして使用されるコミュニティ ストリング comaccess を定義しています。Content Engine に送信されるすべての SNMP メッセージでは、メッセージの「Community Name」フィールドが、認証のためにここで定義されたコミュニティ ストリングと一致する必要があります。コミュニティ ストリングを入力すると、SNMP エージェントがイネーブルになります。

この例では、SNMP エージェントをディセーブルにし、以前に定義されたコミュニティ ストリングを削除します。

ContentEngine(config)# no snmp-server community
 
 
 

Content Engine 上の SNMP トラップすべてをディセーブルにする。

ContentEngine (config)# no snmp-server enable traps

Cisco Discovery Protocol の使用

Cisco Discovery Protocol(CDP)は、すべての Cisco 製デバイス上で実行されるデバイス ディスカバリ プロトコルです。CDP を使用すると、ネットワーク内の各デバイスは、定期的なメッセージをネットワーク内のすべてのデバイスに送信します。これらのデバイスは、他のデバイスから送信される定期的なメッセージを受信して、近隣デバイスについての情報を入手し、近隣デバイスのインターフェイスの状況を判断します。

CDP により、ネットワーク管理アプリケーションは、近隣デバイスのデバイス タイプ、および SNMP エージェント アドレスを確認できます。その後アプリケーションは、ネットワーク内で SNMP 照会を送信できます。また CiscoWorks2000 は、ブート後に Content Engine から送信される CDP パケットを認識することによって、Content Engine の存在を知ります。

Content Engine 関連のタスクが Content Engine プラットフォームの存在、タイプ、およびバージョンをシステム マネージャーに通知するには、Content Engine プラットフォームが CDP をサポートしている必要があります。

CDP イネーブル化の例

次の例では、単一の CLI コマンドによって CDP の実行をイネーブルにします。

ContentEngine(config)# interface FastEthernet 0/0 cdp enable
 

トランザクションのロギング

システム管理者は、トランザクション ログを使用して、Content Engine を通過したトラフィックを表示できます。通常トランザクション ログに記録される一般的なフィールドは、要求が行われた日付と時刻、要求された URL、キャッシュ ヒットであったかキャッシュ ミスであったか、要求のタイプ、転送されたバイト数、およびソース IP です。

高性能キャッシングには、ストレージ、メモリ、および Web からよりすばやくオブジェクトを取り出すことに加え、さらに改善の余地があります。多くの場合、キャッシュの管理者は、キャッシュに対してどのような要求が行われたかや、その要求の結果がどうであったかに注目します。この情報は、次のようなアプリケーションに使用されます。

問題の特定と解決

負荷のモニタリング

課金請求

統計分析

セキュリティ上の問題分析

コスト分析とプロビジョニング

デフォルトでは、トランザクション ロギングは、ACNS Content Engine 上でディセーブルになっています。トランザクション ロギングを Content Engine 上でイネーブルにするには、Content Engine GUI または CLI のどちらかを使用できます。Content Engine GUI からトランザクション ロギングをイネーブルにした場合は、Squid ログ形式が使用されます。

トランザクション ログ形式

ACNS 5.x ソフトウェアでは、Squid、拡張 Squid、または Apache log のいずれかのログ形式を選択できます。また、ユーザが指定するカスタム ログ形式をログの追加フィールドに加えることもできます。ログ形式は、一時点では 1 形式だけ有効になります。Content Engine GUI からトランザクション ロギングをイネーブルにした場合は、Squid ログ形式が使用されます。

Squid スタイルのトランザクション ロギング

Squid スタイルのログ形式は、Content Engine のトランザクション ロギングのデフォルト形式です。使用される Squid ログ ファイル形式は、Squid-1.1 access.log ファイル形式を使用したネイティブ ログ ファイル形式です。Squid-1.1 ネイティブ ログ ファイル形式の詳細については、次の URL で Squid 資料「Frequently Asked Questions」、6.6項の、access.log 見出しを参照してください。
http://www.squid-cache.org/doc/FAQ/FAQ-6.html

Squid ログ ファイル形式

Squid ログ ファイル形式は、次のとおりです。

time elapsed remote host code/status bytes method URL rfc931 peer status/peer host type

Squid ログ形式の例は、次のとおりです。

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 -

Squid ログは、キャッシュのワークロードまたはパフォーマンスに関する貴重な情報源です。ログ レコードは、情報にアクセスするだけではなく、システム設定エラー、およびメモリやディスク空間のようなリソースの消費状況にもアクセスします。

次の例に示すように、Squid スタイル形式のトランザクション ロギングをイネーブルにするには、 transaction-logs format squid コマンドを使用します。

ContentEngine(config)# transaction-logs format squid
 

表 16-4 では、Squid スタイル形式に関連したフィールドをリストします。


) 公開ツールの中から、Squid スタイルのトランザクション ログをレポートに変換するツールを多数利用できます。このツールのリストについては、http://www.squid-cache.org/Scripts を参照してください。


 

表 16-4 Squid スタイル形式の説明

フィールド
説明

Time

ミリ秒単位で表示される世界標準時(UTC) を使用した UNIX タイムスタンプ(秒単位)。

Elapsed

キャッシュがトランザクションで使用されていた時間の長さ(ミリ秒)。


) エントリがログに記録されるのは、トランザクションの存続中ではなく、応答の送信後です。


Remote host

要求側インスタンスの IP アドレス。

Code/status

スラッシュで区切られた 2 つのエントリ。最初のエントリは、トランザクションの結果についての情報をもっています。つまり、要求の種類、処理の方法、または失敗の状況などです。2 番目のエントリには、HTTP 結果コードが入っています。

Bytes

クライアントに送付されたデータの量。ヘッダーもカウントされているので、これはオブジェクトの正味サイズではありません。また、失敗した要求がエラー ページを配信する場合、そのページのサイズもここに記録されます。

Method

オブジェクトを取得するための要求方式(たとえば、GET)。

URL

要求された URL。

Rfc931

認証サーバの ID、または要求側クライアントの検索名が入っている。このフィールドは、常に「-」(ダッシュ)です。

Peer status/Peer host

スラッシュで区切られた 2 つのエントリ。最初のエントリは、要求が処理された方法(たとえば、ピアに要求を転送した、または送信元に要求を戻した)を説明するコードを表します。2 番目のエントリには、オブジェクトの要求元ホストの名前が入っています。このホストは、オリジン サイト、親、またはその他のピアである場合があります。また、ホスト名が数値の場合があることにも注意してください。

Type

HTTP 応答ヘッダーに表示されるオブジェクトのコンテンツ タイプ。ACNS 5.x ソフトウェアでは、このフィールドには常に「-」(ダッシュ)が入っています。

拡張 Squid スタイルのトランザクション ロギング

拡張 Squid 形式では、Squid スタイルの形式でロギングされるフィールドの他に、ログ ファイル内の各レコードに関連したユーザ名がロギングされ、課金請求に使用されます。この形式では、Squid 形式に関連した Rfc931 フィールド( 表 16-4 )が、許可ユーザのロギング記録に使用されます。ユーザ情報が入手できない場合、Rfc931 フィールドには常に「-」(ダッシュ)が入ります。

拡張 Squid スタイル形式

拡張 Squid スタイル ログ形式の例は、次のとおりです。

1012429341.115 100 172.16.100.152 TCP_MISS/302 184 GET http://www.cisco.com/cgi-bin/login myloginname DIRECT/www.cisco.com -

次の例に示すように、Squid スタイル形式のトランザクション ロギングをイネーブルにするには、 transaction-logs format extended-squid コマンドを使用します。

ContentEngine(config)# transaction-logs format extended-squid
ContentEngine(config)#
 

Apache スタイルのトランザクション ロギング

この形式は、World Wide Web Consortium(W3C)運営グループによって定義された Common Log File Format(CLF;共通ログ形式)です。この形式は、多くの業界標準のログ ツールと両立性があります。詳細については、 http://www.w3.org/Daemon/User/Config/Logging.html の、W3C Common Log File Format Web サイトを参照してください。

次の例に示すように、Apache スタイル形式のトランザクション ロギングをイネーブルにするには、 transaction-logs format apache コマンドを使用します。

ContentEngine(config)# transaction-logs format apache
ContentEngine(config)#
 

Apache スタイルのログ形式

Apache スタイルのログ ファイル形式は、次のとおりです。

remotehost rfc931 authuser date request status bytes

次に示す例は、Apache スタイルのログ ファイル形式の一例です。

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

表 16-5 では、Apache 共通ログ形式に関連したフィールドをリストします。

 

表 16-5 Apache 共通ログ形式の説明

フィールド
説明

Remotehost

リモート ホスト名または IP アドレス。

Rfc931

認証サーバの ID、または要求側クライアントの検索名が入る。このフィールドには、常に「-」(ダッシュ)が入っています。

Authuser

ユーザが認証のために入力するユーザ名。ユーザ情報が入手できない場合、このフィールドは常に「-」(ダッシュ)です。

Date

要求の日付と時刻。

Request

要求の先頭行。

Status

HTTP ステータス コード。例:200

Bytes

転送された文書のコンテンツの長さ。

トランザクション ロギング時のカスタム形式

transaction-logs format custom コマンドを使用すると、事前定義されたネイティブ Squid または 拡張 Squid 形式、あるいは Apache 共通ログ形式に含まれていないログ追加フィールドに対してログ形式ストリングを使用できます。ログ形式ストリングは、 表 16-6 にリストされているトークンを含む文字列で、Apache ログ形式に似せたものです。ログ形式ストリングは、リテラル文字を含むことが可能で、ログ ファイルにコピーされる時に使用されます。

ダブル バックスラッシュ(\\)は、リテラル バックスラッシュを表すのに使用できます。

バックスラッシュ 1 文字に単一引用符(\')を続けると、リテラル シングル クォートを表すことができます。ダブル クォートをログ形式ストリング中に含めることはできません。

次の制御文字、\t および \n は、それぞれタブおよび改行文字として使用されます。

表 16-6 では、ログ形式ストリングで使用が許されている形式のトークンを示しています。

この表に示されている形式トークンの "..." 部分は、オプションの条件を表しています。形式トークンのこの部分は、%a のようにブランクにしておくこともできます。

オプションの条件が形式トークンに含まれていて、その条件が合致している場合、 表 16-6 の値欄に示される内容がトランザクション ログ出力に含められます。

オプションの条件が形式トークンで指定されていて、条件が合致しない場合は、結果のトランザクション ログ出力は、ハイフン(-)で埋められます。

条件の形式は、HTTP 状況コードをリストにしたもので、感嘆符(!)が行頭に付く場合と付かない場合があります。

感嘆符は、感嘆符に続くすべての状況コードを否定するときに使用されます。このことは、「!」の後にリストされている状況コードのいずれもが、要求の HTTP 状況コードと一致しないときは、形式トークンと関連する値がログされることを意味します。

「!」の後にリストされている状況コードのいずれかが要求の HTTP 状況コードと一致する場合は、ハイフン(-)がログされます。

たとえば、「%400,501{User-Agent}i」の指定では、エラー 400 および 501 のとき(Bad Request, Not Implemented)だけに、User-Agent ヘッダー値をログ記録します。一方、「%!200,304,302{Referer}i」 の指定では、ノーマル ステータスを戻してこないどの要求にも、Refer ヘッダー値をログ記録します。

カスタム形式は現在、次の要求ヘッダーをサポートしています。

User-Agent

Referer

Host

Cookie

次の各要求に対する出力では、カスタム ログ形式ストリングで指定されている Request、Refer、および User-Agent 形式トークンは、トランザクション ログ エントリ内では二重引用符で囲まれています。

%r

%{Referer}i

%{User-Agent}i

%{Cookie}i 形式のトークンは、二重引用符で囲まなくても生成できます。これは Cookie 値がすでに二重引用符で囲まれているからです。Cookie 値には、複数の attribute-value ペアがあり、各ペアはスペースで区切られています。この理由により、Cookie 形式トークンをカスタム形式ストリングで使用する場合は、ストリングの最後尾に指定することをお勧めします。Cookie 形式トークンを最後尾で指定すると、ログを transaction log reporting tool で解析するときも簡単になります。または形式トークン ストリングを「\'%{Cookie}i\'」のように指定した場合、Cookieヘッダーは単一引用符で囲む必要があります。

次のコマンドを入力すると、よく知られている 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"

次に示すトランザクション ログ エントリの例は、Apache Combined Format のもので、前述のカスタム形式ストリングを使用して設定したものです。

[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)"
 

 

表 16-6 カスタム形式のログ形式ストリング値

形式トークン

%...a

要求側クライアントの IP アドレス。

%...A

オブジェクトがサービスされているサーバの IP アドレス(たとえば、オリジン サーバあるいはキャッシュ ミスの場合の発信プロキシ、またはキャッシュ ヒットの場合の 0.0.0.0)。

%...B
%...b

HTTP ヘッダーを除く送信バイト数。

%...c

要求の完了時の接続ステータス。ここで、

X = 接続は異常終了(応答が完了する前)
+ = 接続は継続可能(応答後)
─ = 接続は終了(応答後)

%...f

ファイル名。

%...h

リモート ホスト(要求側クライアントの IP アドレスがログに記録される)。

%...H

要求プロトコル。

%...{Foobar}i

Foobar コンテンツ: サーバに送られた要求中のヘッダー行。Foobar 値は、次のヘッダーの1つ:User-Agent、Referer、Host、または Cookie。

%...l

リモート ログ名。Content Engine では未実装のため、ハイフン(-)がログ記録される。

%...m

要求方式。

%...p

要求に対してサービスを提供するサーバの正規ポート。Content Engine は該当しないため、ハイフン(-)がログ記録される。

%...P

要求に対してサービスを提供した子のプロセス ID。

%...q

照会ストリング(照会ストリングが存在する場合は ? が先頭に付き、存在しなければ空のストリング)。

%...r

要求の先頭行。

%...s

ステータス。translog code は、要求に対して、必ず HTTP 応答コードを戻す。

%...t

共通ログ時刻形式(または標準英語形式)の時刻。

%...{format}t

表 16-7 に指定されている形式トークンによって記録される時刻。

%...T

要求のサービスに要した時間(秒数:小数部 3 桁の浮動小数点数値)。

%...u

リモート ユーザ。

%...U

要求された URL パス(照会ストリングを含まない)。

%...v
%...V

ホストが要求の中で指定された場合に報告されるホスト要求ヘッダー フィールドの値。ホスト要求ヘッダーにホストが指定されていない場合は、URL に指定されたサーバの IP アドレスが報告されます。

表 16-7 では、 表 16-6 で説明した形式トークン、%...{format}t で表示される日付と時刻の形式トークンを示します。

 

表 16-7 日付および時刻を表す形式トークン

形式トークン

%a

曜日名(省略形)。

%A

曜日名(正式形)。

%b

月名(省略形)。

%B

月名(正式形)。

%c

日付と時刻。

%C

世紀呼称番号 (年を 100 で割り、2 桁の整数で表す)。

%d

10 進数表示の月内の日にち(1~31)。

%D

%m/%d/%y に相当(注:米国以外の国では、%d/%m/%y が普通。インターナショナルな意味合いでは、この形式はあいまいになるため、使用しないようお勧めします)。

%e

%d と同じですが、日にちの数字の先頭が 0 の場合は、スペースが代入される。

%G

ISO 8601 に規定された 10 進数表記の世紀を入れた年。ISO 週数に対応する 4 桁の年数(参照:%V)。これは、%y, と同じ形式と値です。ただし、ISO 週数を前年および翌年に含める場合は、その年を使用します。

%g

%G と同様です。ただし、世紀を使用しません。つまり、2 桁の年数(00-99)。

%h

%b と同一。

%H

24 時を採用する場合の 10 進数表示の時間(範囲:00 ~ 23)。

%I

12 時を採用する場合の 10 進数表示の時間(範囲:01 ~ 12)。

%j

10 進数表示の年内の日にち(001~366)。

%k

10 進数表示の時間(24 時方式)(範囲:0 ~ 23)、1 桁の場合は先頭の 0 は省略。(参照:%H)。

%l

10 進数表示の時間(12 時方式)(範囲:1 ~ 12)、1 桁の場合は先頭の 0 は省略。(参照:%I)。

%m

10 進数表示の月(範囲:01 ~ 12)。

%M

10 進数表示の分(範囲:00 ~ 59)。

%n

改行文字。

%p

所定のタイム値に応じた AM または PM 表示、または現行のロケールに対応するストリング。正午は pm、真夜中は am として表示。

%P

%p と同様。ただし、小文字で表示。am、pm、または現行ロケールに対応するストリングとして表示。

%r

a.m. または p.m. 表示の時刻(「%I:%M:%S %p.」と同一)。

%R

24 時表示の時刻(%H:%M)。秒表示は、下の %T を参照。

%s

新時代(1970-01-01 00:00:00 UTC)以降の秒数。

%S

10 進数表示の秒(範囲:00 ~ 61)。

%t

タブ文字。

%T

24 時表示の時刻(%H:%M:%S)。

%u

10 進数表示の週内の曜日(範囲:1 ~ 7、月曜は 1。参照:%w)。

%U

10 進数表示の現行年内での週数(範囲:00 ~ 53、年頭の最初の日曜日を 01 週の最後の日と指定。参照:%V および %W)。

%V

ISO 8601:10 進数表示の現行年(1988 年)の週数。週数の範囲は、1 ~ 53。第 1 週は少なくても 4 日は現行年に存在し、月曜日が週の第 1 日となる。(参照 %U および %W)。

%w

10 進数表示の週内の曜日(範囲:0 ~ 6、日曜は 0、参照:%u)。

%W

現行年内での週数を数字で表示(範囲:00 ~ 53、年頭の最初の月曜日を 01 週と指定)。

%x

日付(時刻を表示しない)。

%X

時刻(日付を表示しない)。

%y

世紀を表示しない 10 進数表示の年(範囲:00 ~ 99)。

%Y

世紀を表示する 10 進数表示の年。

%z

GMT との偏差時間帯。RFC822 適合日付の発行に必要 (“%a, %d %b %Y %H:%M:%S %z” を使用)。

%Z

時間帯、名称、または略語。

%%

リテラル % 文字。

トランザクション ロギングと NTLM 認証

使用しているデバイスが、NT LAN Manager (NTLM) 認証用に設定されていて、拡張 Squid スタイル形式だけではなく、Apache スタイルを使用している場合、transaction-logs log-windows-domain コマンドは、トランザクション ログの "authenticated username" フィールド内に、Windows のドメイン名とユーザ名を記録します。ドメイン名が使用可能な場合、ドメイン名とユーザ名の両方が "authenticated username" フィールドに、domain\ユーザ名の形式で記録されます。ユーザ名だけが使用可能の場合、ユーザ名だけが "authenticated username" フィールドに記録されます。ドメイン名とユーザ名の両方が使用不可能な場合、"-"(ダッシュ)がこのフィールドに記録されます。

Apache スタイル フォーマット、および拡張 Squid スタイル フォーマットで NTLM パラメータのロギングを無効にするには、 no transaction-logs log-windows-domain コマンドを使用します。

ログ ファイルの使用ガイドライン

この項では、ログ ファイルを取り扱うときのガイドラインのいくつかを示します。

作業ログの理解

sysfs がマウントされている場所により、トランザクションは、ファイル内のローカル ディスク上にある次の作業ログにロギングされます。

/local1/logs/working.log または

/local2/logs/working.log

sysfs がマウントされている場所により、次のログ ファイルは、ファイル内のローカル ディスク上にある作業ログに、次のようにロギングされます。

WMT ログは、ファイル内のローカル ディスクにある次の作業ログにロギングされます。

/local1/logs/export/working.log または

/local2/logs/export/working.log

Real-subscriber ログは、ファイル内のローカル ディスクにある次の作業ログにロギングされます。

/local1/logs/real-subscriber-logs/working.log または

/local2/logs/real-subscriber-logs/working.log

Cisco-streaming-engine ログは、ファイル内のローカル ディスクにある次の作業ログにロギングされます。

/local1/logs/cisco-streaming-engine/working.log または

/local2/logs/cisco-streaming-engine/working.log

Real Proxy ログは、ファイル内のローカル ディスクにある次の作業ログにロギングされます。

/local1/logs/real-proxy/working.log または

/local2/logs/real-proxy/working.log

アーカイブ作業ログ

ユーザは作業ログをクリアする間隔を設定できます。作業ログのクリアはデータをアーカイブ ログに移動させることで行われます。sysfs ファイルがマウントされている場所によって、アーカイブ ログ ファイルは、ディレクトリ/local1/logs/ または /local2/logs/ 内のローカル ディスクに配置されます。

多数のアーカイブ ファイルが保存されるため、ファイル名にはファイルがアーカイブされた日時のタイムスタンプが含まれます。これらのファイルは FTP/SFTP サーバにエクスポート可能なため、ファイル名にはこの Content Engine の IP アドレスも含まれます。

アーカイブ ファイル名の形式は、次のとおりです。

celog_IPADDRESS_YYYYMMDD_HHMMSS.txt

トランザクション ログのサニタイジング

クライアントは、トランザクション ログ ファイルにログされるときに身元が表示されないようにするために、IP アドレスとユーザ名を別名でログすることができます。デフォルトでは、このトランザクション ログはサニタイズされません。サニタイズ機能を有効にしたトランザクション ログでは、クライアントのネットワーク上の身元を識別する IP アドレスは、0.0.0.0 に変更されてトランザクション ファイルにログ記録されます。

次のインターフェイスを使用して、トランザクション ログのサニタイズ機能をイネーブルにできます。

Content Engine GUI :Content Engine GUI で、 Cache > Transaction Logs を選択します。 Transaction Log Enable チェックボックスにチェックマークを付けて、トランザクション ロギングを Content Engine 上でアクティブにします。次に Sanitize transaction logs オプション ボタンをクリックして、サニタイズ機能をイネーブルにします。 Update をクリックして設定値を適用します。

CLI Command :次の例に示すとおり、 transaction-logs sanitized コマンドを使用します。

ContentEngine(config)# transaction-logs sanitize
ContentEngine(config)#
 

サニタイズ機能をディセーブルにするには、 no 形式を使用します。

トランザクション ログ ファイルのエクスポート

キャッシュ ログ ファイルの後処理を容易にするために、トランザクション ログを外部ホストにエクスポートできます。

この機能により、FTP を使用して、設定可能な間隔でログ ファイルを外部ホストに自動的にエクスポートできます。FTP に使用されるユーザ名とパスワードは設定可能で、ログ ファイルのアップロード先のディレクトリも設定可能です。

ログ ファイルには、自動的に次のファイル名が付けられます。

type_ipaddr_yyyymmdd_hhmmss.txt

ここでは、次のとおりです。

type は、ログ ファイルのタイプを表します。HTTP、HTTPS、および FTP などのキャッシュ ログの場合は celog 、WMT ログの場合は mms_export です。

ipaddr は、Content Engine の IP アドレスを表します。

yyyymmdd_hhmmss は、ログがエクスポートのためにアーカイブされた日付と時刻を表します。


) MMS タイプ ログの場合、ファイル名に .txt 拡張子がありません。


トランザクション ログの外部の FTP または SFTP サーバへのエクスポート

トランザクション ログを外部の FTP またはセキュア FTP (SFTP) サーバにエクスポートするには、次のどちらかのインターフェイスを使用できます。

「CLI を使用したトランザクション ログの外部 FTP サーバへのエクスポート」 および 「CLI を使用したトランザクション ログの外部 SFTP サーバへのエクスポート」で説明されている CLI コマンド。

「Content Engine GUI を使用したトランザクション ログの FTP、または SFTP サーバへのエクスポート」で説明されている Content Engine GUI。

Content Engine GUI を使用したトランザクション ロギングのイネーブル化と設定

Content Engine 上でトランザクション ロギングをイネーブルにし、設定する手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 Caching > Transaction Logs を選択します。Transaction Logs ウィンドウが表示されます(図 16-7 を参照)。

図 16-7 Transaction Logs ページ

 

ステップ 2 Enable transaction logging オプション ボタンをクリックして、この Content Engine 上でトランザクション ロギングをアクティブにします。

ステップ 3 アーカイブ ファイルの最大サイズをキロバイトで Maximum size of Archive file フィールドに指定します。

ステップ 4 データをアーカイブ ログに移動して作業ログをクリアする間隔を選択します。表示される時間オプションを使用して、間隔を指定します。

ステップ 5 トランザクション ログをサニタイズする場合は、 Sanitize transaction logs On オプション ボタンをクリックします。


) サニタイズ機能に関しての詳細は、「トランザクション ログのサニタイジング」を参照してください。


ステップ 6 Update をクリックして設定値を保存します。

ステップ 7 Transaction Logs ウィンドウをクローズするか、またはこのウィンドウを使用して、次の項
「Content Engine GUI を使用したトランザクション ログの FTP、または SFTP サーバへのエクスポート」)で説明されている手順で FTP サーバにエクスポートします。


 

Content Engine GUI を使用したトランザクション ログの FTP、または SFTP サーバへのエクスポート

外部の FTP またはセキュア FTP (SFTP) サーバへのエクスポートをイネーブルにする手順は、次のとおりです。


ステップ 1 Transaction Logs ウィンドウ(図 16-7)で、 Transaction Log FTP Export オプション ボタンにチェックマークを付けます。

ステップ 2 データを FTP サーバに移動して作業ログをクリアする間隔を選択します。表示される時間オプションを使用して、間隔を指定します。

ステップ 3 FTP サーバの必要情報を入力します。


) FTP エクスポート機能は、最高 4 つのサーバをサポートできます。各サーバに対して、そのサーバに有効なユーザ名、パスワード、およびディレクトリを設定する必要があります。


a. FTP Export Server フィールドに、FTP サーバの IP アドレスまたはホスト名を入力します。

b. Name フィールドに、ユーザのユーザ ID を入力します。パスワード フィールドに、このユーザ用のパスワードを入力します。

c. Directory フィールドに、トランザクション ログを格納する作業ディレクトリの名前を入力します。


) Name フィールドに指定するユーザは、指定のディレクトリの書き込み許可を持っている必要があります。


ステップ 4 選択した FTP サーバがセキュア FTP サーバの場合は、 SFTP チェックボックスにチェックマークを付けます。

ステップ 5 Update をクリックして設定値を保存します。


 

CLI コマンドを使用したトランザクション ロギングのイネーブル化と設定

この項では、Squid、拡張 Squid、Apache、またはカスタマイズされたログ形式をイネーブルにするときに、CLI を使用する方法を説明します。

表 16-8 では、Content Engine 上でトランザクション ロギングをイネーブルにし、設定するのに使用可能な各種トランザクション ロギング形式、および CLI コマンドの概要を説明します。これらの CLI コマンドの構文と使用法については、『Cisco ACNS Software Command Reference, Release 5.1』を参照してください。

 

表 16-8 トランザクション ロギング形式のリスト

形式
説明

Squid スタイル

Squid スタイル形式のトランザクション ロギングをイネーブルにするには、次の transaction-logs format squid コマンドを使用します。

ContentEngine(config)# transaction-logs format squid
 

Squid スタイルの詳細は、「システム ロギングの設定」を参照してください。

拡張 Squid スタイル

拡張 Squid 形式のトランザクション ロギングをイネーブルにするには、 transaction-logs format extended-squid コマンドを使用します。

ContentEngine(config)# transaction-logs format extended-squid
 

拡張 Squid スタイルの詳細は、「拡張 Squid スタイルのトランザクション ロギング」を参照してください。

Apache

Apache スタイル形式のトランザクション ロギングをイネーブルにするには、次の例に示すように transaction-logs format apache コマンドを使用します。

ContentEngine(config)# transaction-logs format apache
 

Apache スタイルの詳細は、「Apache スタイルのトランザクション ロギング」を参照してください。

カスタム

ログ形式ストリングを事前定義済みのネイティブ Squid、拡張 Squid、あるいは Apache 共通ログ形式に含まれていないログ追加フィールドに対して使用するには、 transaction-log format custom コマンドを使用します。

Custom スタイルの詳細は、「トランザクション ロギング時のカスタム形式」を参照してください。

CLI を使用したトランザクション ログの外部 FTP サーバへのエクスポート

トランザクション ログを外部 FTP サーバにエクスポートするときに CLI を使用する場合、最初にトランザクション ログのエクスポート機能をイネーブルにしてから、FTP サーバのパラメータを設定します。外部 FTP サーバへのトランザクション ログのエクスポートを可能にするには、 transaction-logs export enable コマンドを使用します。その後、 transaction-logs export ftp-server オプションを使用すると、FTP サーバ パラメータを入力できます。このオプションは、最高 4 つの FTP サーバをサポートできます。

次の情報が、各ターゲット FTP サーバに必要です。

サーバの IP アドレス、またはホスト名

Content Engine は、DNS 検索を行ってホスト名を変換し、次に設定ファイルにこの IP アドレスを保存します。

FTP ユーザのログイン名、およびユーザ パスワード

転送されたファイルが書き込まれるディレクトリのパス

ユーザのログイン用に完全修飾パス、または相対パスを使用します。ユーザは、このディレクトリに対する書き込み許可を所有している必要があります。

アーカイブされたログ ファイルを外部 FTP サーバにエクスポートする前に、gzip 形式に圧縮するには、 transaction-logs export compress コマンドを使用します。圧縮されたファイル名には、.gz 拡張子が付きます。この機能を使用すると、Content Engine と FTP エクスポート サーバの両方において、使用するアーカイブ ファイル用のディスク スペースが少なくなり、エクスポート時に必要な帯域幅も少なくて済みます。

次の例では、2 台の FTP サーバが設定されます。

ContentEngine(config)# transaction-logs export ftp-server 10.1.1.1 mylogin mypasswd /ftpdirectory
ContentEngine(config)# transaction-logs export ftp-server myhostname mylogin mypasswd /ftpdirectory
 

FTP サーバを削除するときは、このコマンドの no 形式を使用します。

ContentEngine(config)# no transaction-logs export ftp-server 10.1.1.1
ContentEngine(config)# no transaction-logs export ftp-server myhostname
 

transaction-logs export enable コマンドの no 形式を使用すると、トランザクション ログ エクスポート機能全体を使用不可にし、同時に他の設定部分を保持できます。

ContentEngine(config)# no transaction-logs export enable
 

ユーザ名、パスワード、またはディレクトリを変更するには、行全体を再入力します。

ContentEngine(config)# transaction-logs export ftp-server 10.1.1.1 mynewname mynewpass /newftpdirectory
 

show transaction-logging コマンドは、Content Engine 内のトランザクション ロギング設定についての情報を表示します。表示されるトランザクション ログ ファイル情報は、HTTP および WMT の、Microsoft Media Server(MMS)キャッシング プロキシ トランザクションであることに注意してください。

ContentEngine# show transaction-logging
Transaction log configuration:
---------------------------------------
Logging is enabled.
Logging of ecdn internal communication is disabled.
End user identity is hidden. (sanitized)
File markers are disabled.
Archive interval: every-day every hour.
Maximum size of archive file: 2000000 KB
Log File format is extended-squid.
 
Exporting files to ftp servers is enabled.
File compression is disabled.
Export interval: every-day at 11:45 local time
 
ftp-server username directory
10.1.1.1 mylogin /ftpdirectory
10.2.2.2 mylogin /ftpdirectory
HTTP Caching Proxy Transaction Log File Info
Working Log file - size : 83
age: 502845
Archive Log file - celog_10.1.1.21_20020107_150300.txt size: 1075
Archive Log file - celog_10.1.1.21_20020117_150300.txt size: 1199746
Archive Log file - celog_10.1.1.21_20020118_000000.txt size: 137583
Archive Log file - celog_10.1.1.21_20020118_150300.txt size: 12667
Archive Log file - celog_10.1.1.21_20020123_150300.txt size: 298
WMT MMS Caching Proxy/Server Transaction Log File Info
Working Log file - size : 541
age: 54117
Archive Log file - mms_export_10.1.1.21_20020107_225942 size: 541
Archive Log file - mms_export_10.1.1.21_20020107_232156 size: 938
Archive Log file - mms_export_10.1.1.21_20020117_193239 size: 541
Archive Log file - mms_export_10.1.1.21_20020122_224556 size: 1993
Archive Log file - mms_export_10.1.1.21_20020124_150334 size: 541
Archive Log file - mms_export_10.1.1.21_20020131_025505 size: 541
ContentEngine#

) セキュリティ上の理由により、パスワードが表示されることはありません。


外部 FTP サーバからパーマネント エラーを受信後のエクスポートの再開

FTP サーバが Content Engine にパーマネント エラーを返したときは、それ以降、アーカイブ トランザクション ログは、そのサーバにはエクスポートされません。このエラー状態をクリアするには、設定に誤りがあるサーバに対して、Content Engine のトランザクション ログ エクスポート パラメータを再入力する必要があります。 show statistics transaction-logs コマンドは、トランザクション ログのエクスポート準備の現状を表示します。

パーマネント エラー(Permanent Negative Completion Reply、RFC 959) は、サーバへの FTP コマンドが受信されず、アクションがとられなかったときに発生します。パーマネント エラーの原因は、無効なユーザのログイン、無効なユーザ パスワード、および十分な許可のないディレクトリや、存在しないディレクトリへのアクセス試行です。

次の例では、無効なユーザ ログイン パラメータが、 transaction-logs export ftp-server コマンドに含まれていました。 show statistics transaction-logs コマンドを使用すると、Content Engine がアーカイブ ファイルのエクスポートに失敗したことが示されます。

ContentEngine# show statistics transaction-logs
Transaction Log Export Statistics:
 
Server:172.16.10.5
Initial Attempts:1
Initial Successes:0
Initial Open Failures:0
Initial Put Failures:0
Retry Attempts:0
Retry Successes:0
Retry Open Failures:0
Retry Put Failures:0
Authentication Failures:1
Invalid Server Directory Failures:0
 

アーカイブ トランザクション ログのエクスポートを再開するには、 transaction-logs export ftp- server パラメータを再入力する必要があります。

ContentEngine(config)# transaction-logs export ftp-server 172.16.10.5 goodlogin pass /ftpdirectory
 

CLI を使用したトランザクション ログの外部 SFTP サーバへのエクスポート

transaction-logs export sftp-server オプションを使用すると、トランザクション ログを外部 SFTP サーバにエクスポートできます。最初に transaction-logs export enable コマンドを発行し、SFTP サーバ パラメータを設定します。次の情報が、各ターゲット SFTP サーバに必要です。

SFTP サーバの IP アドレス、またはホスト名

Content Engine は、DNS 検索を行ってホスト名を変換し、次に設定ファイルにこの IP アドレスを保存します。

SFTP ユーザのログイン名、およびユーザ パスワード

転送されたファイルが書き込まれるディレクトリのパス

ユーザのログイン用に完全修飾パス、または相対パスを使用します。ユーザは、このディレクトリに対する書き込み許可を所有している必要があります。

transaction-logs export enable コマンドの no 形式を使用すると、トランザクション ログの SFTP サーバへの書き出しをディセーブルにできます。

システム ロギングの設定

システム ログ ファイル(sylog) 専用のパラメータを設定するには、ACNS システム ロギング機能を使用します。このファイルには、認証エントリ、特権レベルの設定値、および管理に関する詳細情報が保存されます。システム ロギングは、内部では常にイネーブルになっています。システム ログ ファイルは、システム ファイル システム(sysfs) 区画に /local1/syslog.txt として置かれます。

Content Engine が各種レベルのイベント メッセージをディスク、コンソール、またはホストに送信するように設定するには、次のインターフェイスのどちらかを使用します。

「Content Engine GUI を使用したシステム ロギングの設定」で説明されている Content Engine GUI。

「CLI コマンドを使用したシステム ロギングの設定」で説明されている Content Engine CLI。

CiscoWorks2000 の使用

CiscoWorks2000 (CW2K) は、ほとんどのシスコ デバイスの管理に使用される一連の管理アプリケーションを提供するシスコ製品です。次のように、Content Engine は、まったく修正することなく CiscoWorks2000 と相互運用できます。

CW2K は、Generic SNMP デバイスの下に Content Engine をリストできます。

CW2K インベントリ モジュールは、Content Engine をデバイス名、システム名、説明(ソフトウェア バージョンなど)、アップタイム、およびネットワーク インターフェイス情報とともにリストします。

CW2K syslog モジュールは、Content Engine の syslog を解釈できます。

CW2K アベイラビリティ モジュールは、Content Engine を追跡できます。

Content Engine CLI または GUI を使用して、CiscoWorks2000 に準拠した形式での syslog メッセージの生成をイネーブル、またはディセーブルにできます。

syslog メッセージを CW2K syslog サーバに転送するには、 logging host コマンドを使用します。特定の重大度レベルの syslog メッセージを CW2K syslog サーバに送信するには、 logging host priority コマンドを使用します。

Content Engine GUI を使用したシステム ロギングの設定

システム ロギングを Content Engine 上に設定する手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 System > Syslog の順に選択します。Syslog ウィンドウが表示されます(図 16-8 を参照)。

図 16-8 Syslog ウィンドウ

 

ステップ 2 Syslog Server フィールドに、syslog サーバの IP アドレスまたはホスト名を入力します。これは、syslog メッセージをこの Content Engine から受信するホストです。


) この Content Engine が syslog メッセージを外部ホストに送信できないようにするには、Syslog Server フィールドの IP アドレスを削除するか、Syslog ページ上で Logging Host オプションをディセーブルにします。


ステップ 3 Syslog File フィールドに、ディスク内の syslog ファイルのパスを入力します。

ステップ 4 Facility ドロップダウン リストからオプションを 1 つ選択して、通知方法を指定します。

ステップ 5 Enable チェックボックスにチェックマークを付け、Console、Disk、または Host への syslog メッセージ送信をイネーブルにします。

ステップ 6 Priority ドロップダウン リストからオプションを 1 つ選択して、対応するイベントのプライオリティ レベルを指定します( 表 16-9 を参照)。

表 16-9 Syslog ページでのシステム ロギングのプライオリティ レベルと説明

条件
syslog 優先レベル

Emergency

システムは使用不能。

Alert

即時の処置が必要。

Critical

クリティカルな状態。

Error

エラー状態。

Warning

警告状態。

Notice

正常だが重要な状態。

Informational

情報メッセージ。

Debug

デバッグ メッセージ。

ステップ 7 Update をクリックして設定値を保存します。


 

CLI コマンドを使用したシステム ロギングの設定

logging コマンドを使用すると、システム ログ ファイル(syslog)に特定のパラメータを設定できます。syslog ファイルには、認証エントリ、特権レベルの設定値、および管理上の詳細情報が含まれています。システム ロギングは、内部では常にイネーブルになっています。システム ログ ファイルは、システム ファイル システム(sysfs)区画に /local1/syslog.txt として置かれます。

CLI を使用すると、 logging host コマンドを使用して、Content Engine がさまざまなレベルのイベント メッセージを外部 syslog ホストに送信するように設定できます。 logging console priority オプションを使用すると、各種レベルのメッセージをコンソールに送信するようにロギングを設定できます( 表 16-10 を参照)。

表 16-10 システム ロギングのプライオリティ レベルと説明

プライオリティ コード
条件
syslog 優先レベル

0

Emergency

Priority 0:LOG_EMERG,
Emergency レベル。システムは使用不能。

1

Alert

Priority 1:LOG_ALERT,
Alert レベル。即時の処置が必要。

2

Critical

Priority 2:LOG_CRI,
Critical レベル。クリティカルな状態。

3

Error

Priority 3:LOG_ERR,
Error レベル。エラー状態。

4

Warning

Priority 4:LOG_WARNING
Warning レベル。警告状態。

5

Notice

5:LOG_NOTICE
Notice レベル。正常だが重要な状態。

6

Informational

6:LOG_INFO
Information レベル。情報メッセージ。

7

Debug

7:LOG_DEBUG
Debug レベル。デバッグ メッセージ。


) Content Engine からリモート ホストへの syslog メッセージは、ポート 514 を使用せずに、ポート 10000 から発信されます。


次の例では、 type-tail コマンドを使用して syslog.txt ファイルを表示する例を示します。このコマンドは、指定されたテキスト ファイルの最後の数行だけをリストします。

ContentEngine# type-tail syslog.txt
Jan 18 17:50:03 ContentEngine Host[3766]: authentication failure; (uid=0) -> aaHH for content_engine_config service
Jan 18 17:50:05 ContentEngine login[3766]: Failed login session from 172.16.1.1 for user aaHH: Authentication service cannot retrieve authentication info.
Jan 18 18:39:05 ContentEngine Host[6787]: set privilege level to `0'
Jan 18 18:39:05 ContentEngine login: user login on 1 from 172.16.66.148
ContentEngine#

Syslog 優先レベルの RealProxy エラー コードへのマッピング

RealProxy は、エラー メッセージを生成し、RealProxy ログ ファイルに書き込みます(「RTSP とは」を参照)。これらのエラー メッセージは、ACNS ソフトウェアにより取り込まれ、システム ログ ファイルに渡されます。RealProxy エラー コードと syslog 優先レベルとの間には、1 対 1 のマッピング対応があります( 表 16-11 を参照)。

表 16-11 RealProxy エラー レベルと Syslog 優先レベルとのマッピング

RealProxy エラー コード
RealProxy の状態
RealProxy の用途
syslog 優先レベル

0

Panic

システム障害を起こす可能性があるエラー。RealProxy は、問題の解決に必要な処置を取ります。

Priority 0:LOG_EMERG,
Emergency レベル。システムは使用不能。

1

Severe

問題を防止するためにただちにユーザの介入が必要なエラー。

Priority 1:LOG_ALERT,
Alert レベル。即時の処置が必要。

2

Critical

問題を解決するためにユーザの介入が必要な場合があるエラー。

Priority 2:LOG_CRI,
Critical レベル。クリティカルな状態。

3

General

通常のシステム稼働には重大な問題を引き起こさないエラー。

Priority 3:LOG_ERR,
Error レベル。エラー状態。

4

Warning

システムの問題を引き起こさないが、注意が必要な状態であることを警告。

Priority 4:LOG_WARNING
Warning レベル。警告状態。

5

Notice

システムの問題を引き起こさないが、注意すべき状態であることを通知。

5:LOG_NOTICE
Notice レベル。正常だが重要な状態。

6

Informational

情報提供の目的だけのメッセージ。

6:LOG_INFO
Information レベル。情報メッセージ。

7

Debug

プログラムのデバッグ時だけに使用される情報。

7:LOG_DEBUG
Debug レベル。デバッグ メッセージ。

HTTP カスタム エラー ページの作成

ACNS 5.1 ソフトウェアでは、HTTP のカスタマイズされたエラー ページの作成が可能です。これらのカスタマイズされたページを作成する場合、Content Engine は、プロキシ エラー発生時にデフォルトのエラー メッセージを使用せずに、適宜カスタマイズされたエラー ページを表示します。

使用上のガイドライン

Content Engine の GUI または CLI を使用して、HTTP によるカスタマイズされたエラー ページを、 表 16-12 にリストされているすべてのプロキシ エラー メッセージに対して作成することができます。

特定のメッセージ用のテキストを変更するには、http custom-error-page download コマンドを使用し、変更しようとするメッセージを確認した上で、カスタム メッセージ ファイルに対するソースである URL を指定します。カスタム メッセージ ファイルは最大で 16 KB のサイズになることがあり、指定したメッセージ用に標準のメッセージ ページの代わりに使用されます。

特定のメッセージをデフォルトのメッセージ テキストにリセットするには、
http custom-error-page reset コマンドを使用し、デフォルト ページに戻そうとするメッセージを確認します。

指定したメッセージ ページの現行コンテンツをコピーする場合、http custom-error-page upload コマンドを使用して、その指定ページをコピーしようとするホスト名または IP アドレス、ディレクトリ、およびファイル名を確認します。ホストは、指定したディレクトリへのアクセスを許し、ファイルのコピーを許可しなければなりません。

表 16-12 では、プロキシ エラー メッセージとその使用について説明します。

 

表 16-12 プロキシ エラー メッセージ

メッセージ識別子
使用条件

blocked-dueto-filter-error

フィルタが設定されているために要求がブロックされたときのエラー応答。

cache-read-error

cfs の読み取りに失敗したときのエラー応答。

cache-write-error

cfs の書き込みに失敗したときのエラー応答。

cdn-not-found-error

ACNS ネットワークが見つからないときのエラー応答。

client-access-denied-msg

アクセスが拒否されたときのエラー メッセージ。

client-connection-broken-error

クライアント接続が失われたときのエラー応答。

cr-domain-not-found-err

Content Router が見つからないときのエラー応答。

cr-general-error

Content Router が稼働していないときのエラー応答。

cr-not-in-cz-error

Content Router が Coverage Zone 内で見つからないときのエラー応答。

cr-unavailable-error

Content Router が使用できないときのエラー応答。

dns-not-available-error

DNS が解決に使用できないときのエラー応答。

ftp-bad-login-error

FTP のログインに失敗したときのエラー応答。

ftp-bad-url-error

FTP 要求が正しくない URL を受け取ったときのエラー応答。

ftp-disabled-error

FTP がディセーブルのときのエラー応答。

ftp-failure-error

障害時のエラー応答。

ftp-internal-error

FTP 間隔が超過したときのエラー応答。

ftp-not-found-error

FTP ファイルが見つからないときのエラー応答。

ftp-put-created-msg

FTP PUT が正常であるときの応答。

ftp-put-error

FTP PUT に失敗したときのエラー応答。

ftp-put-modified-msg

FTP 更新が正常であるときの応答。

ftp-unavailable-msg

FTP ファイルが使用不可のときのエラー応答。

https-blocked-port-msg

HTTPS 要求がブロックされたポートに到達したときのエラー応答。

invalid-port-error

無効なポートにアクセスしたときのエラー応答。

looped-req-error

ループされた要求が正常でないときのエラー応答。

not-enough-resources-error

要求された処理に対して十分なリソースが利用できないときのエラー応答。

not-in-cache

オブジェクトがキャッシュ内に見つからないときのエラー応答。

offline-miss-error

Content Engine オフラインがキャッシュ ミスを検出したときのエラー応答。

outgoing-proxy-fail-error

すべての発信プロキシに障害が発生したときのエラー応答。

proxy-unauthenticated-error

プロキシ認証が失敗したときのエラー応答。

radius-redirect-error

RADIUS リダイレクト メッセージに対してのエラー応答。

request-blocked-msg

要求がブロックされたときのエラー応答。

request-malformed-error

要求ヘッダが異常に変形したときのエラー応答。

rev-dns-not-available-msg

DNS が使用できないときのエラー応答。

server-connection-broken-error

サーバ接続が失われたときのエラー メッセージ。

unsupported-cr-method-error

サポートされていない Content Router 方式が使用されたときのエラー応答。

www-unauthenticated-error

サーバ認証が失敗したときのエラー応答。

Content Engine GUI を使用した HTTP カスタム エラー ページの設定

ローカルに配置する Content Engine 上で HTTP カスタム エラー ページの設定を行う手順は、次のとおりです。


ステップ 1 Content Engine GUI から、 Caching > Customized Error Page の順に選択します。Custom Error Page Configuration ウィンドウが表示されます(図 16-9 を参照)。

図 16-9 Customized Error Page ウィンドウ

 


ヒント Proxy Error Messages ドロップダウンをクリックして、カスタマイズされたエラー ページが作成できるプロキシ エラー メッセージすべてのリストを表示します。プロキシ エラー メッセージのこのリストに関する詳細は、表 16-12を参照してください。


ステップ 2 設定が必要なエラー メッセージを Proxy Error Messages ドロップダウン リストから選択します。

ステップ 3 Download オプション ボタンをクリックし、URL を Download URL フィールドに入力します。この URL により、カスタマイズされたエラー ページを取り出して、Content Engine にダウンロード可能なロケーションが指定されます。

カスタマイズされたエラー ページが、指定したプロキシ エラー ページにダウンロードされた場合、Content Engine は、デフォルトのエラー メッセージの代わりにこのエラー ページを表示します。

ステップ 4 Server IP フィールドに、syslog サーバの IP アドレスまたはホスト名を入力します。これは、syslog メッセージをこの Content Engine から受信するホストです。

ステップ 5 Upload オプション ボタンをクリックします。

ステップ 6 Upload Server IP、Remote Directory、Remote File Name、Username、および Password フィールドを使用して、アップロード パラメータを表示します。


ヒント Custom Error Page Configuration ウィンドウにあるすべてのフィールドに関する詳細を参照するときは、Help ボタンをクリックして状況依存ヘルプにアクセスします。

ステップ 7 Update をクリックします。


 

CLI コマンドを使用した HTTP カスタム エラー ページ

CLI を使用して、HTTP カスタム エラー ページを設定するには、 http custom-error-page EXEC コマンドを使用します。

http custom-error-page download message url | reset { all | message } | upload { ip-address | hostname } dirname filename message

表 16-13 では、 http custom-error-page コマンドに関するパラメータについて説明します。

 

表 16-13 https custom-error-page CLI コマンド用パラメータ

パラメータ
説明

download

指定した URL からカスタム エラー ファイルを Content Engine にコピーする。

url

カスタム エラー ファイルのソースを指定する。ファイル サイズは 16 KB を超えてはなりません。

message

プロキシ エラー メッセージのタイプ(たとえば、ftp-put-error)を指定する。これらプロキシ エラー メッセージのリストについては、表 16-12 を参照してください。

reset

デフォルトのエラー ページに戻す。

upload

カスタム エラー ページを指定したホスト、ディレクトリ、およびファイルにアップロードする。

ip-address

エラー ページのコピー先となるホストの IP アドレスを指定する。

hostname

エラー ページのコピー先となるホスト名を指定する。

dirname

エラー ページのコピー先となるディレクトリ名を指定する。

filename

エラー ページのコピー先となるファイル名を指定する。

HTTP カスタム エラー メッセージの設定例

次のコマンドを使用すると、cache-read-error ページに対するカスタム エラー ページが、Content Engine にコピーされます。

ContentEngine# http custom-error-page download http://www.myserver.com/errors/cache-read-error.txt cache-read-error
ContentEngine#
 

次のコマンドを使用すると、cache-read-error ページの現行コンテンツが、192.168.1.1 の IP アドレスをもつホスト上の errors ディレクトリ内のファイルにコピーされます。

ContentEngine# http custom-error-page upload 192.168.1.1 /errors cache-read-error.txt cache-read-error
ContentEngine#
 

次のコマンドを使用すると、cache-read-error ページがデフォルトのテキストにリセットされます。

ContentEngine# http custom-error-page reset cache-read-error
ContentEngine#
 

Traceroute のサポート

Traceroute は、現在市販されているほとんどのオペレーティング システムで広く使用されているユーティリティです。Traceroute は、ping と同様に、ネットワークの接続状態を判定する重要なツールです。ユーザは、ping を使用して、両端のシステム間が接続されているかどうかを知ることができます。Traceroute は ping と同様に動作しますが、さらに両端のシステム間を中継する中間ルータもリストします。したがって、ユーザは、あるシステムから次のシステムにパケットが移動するルートを知ることができます。

traceroute EXEC コマンドを使用すると、ホスト名または IP アドレスが既知の場合は、リモート ホストへのルートを見つけることができます。

ContentEngine# traceroute yahoo.com
traceroute to 66.218.71.113 (66.218.71.113), 30 hops max, 38 byte packets
***
***
***
***
10 p3-3.paloalto-cr2.bbnplanet.net (4.0.26.13) 3.219 ms 2.001 ms 2.097 ms
11 p7-1.paloalto-nbr2.bbnplanet.net (4.0.6.77) 3.133 ms 1.949 ms 2.076 ms
12 p4-0.paloalto-nbr1.bbnplanet.net (4.0.5.65) 2.755 ms 2.204 ms 2.037 ms
13 p1-0.paix-bi2.bbnplanet.net (4.0.6.98) 2.928 ms 2.146 ms 2.334 ms
14 p1-0.xpaix17-level3.bbnplanet.net (4.0.1.70) 3.397 ms 3.631 ms 3.081 ms
15 gige10-0.ipcolo4.SanJose1.Level3.net (64.159.2.42) 3.334 ms 2.999 ms 2.388 ms
16 cust-int.level3.net (64.152.69.18) 3.871 ms 3.031 ms *
17 ge-3-3-0.msr1.pao.yahoo.com (216.115.101.42) 3.695 ms ge-2-3-0.msr2.pao.yahoo.com (216.115.101.46) 6.998 ms *
18 vl16.bas1.scd.yahoo.com (66.218.64.146) 6.282 ms 5.091 ms 5.162 ms
19 w2.rc.scd.yahoo.com (66.218.71.113) 6.028 ms 5.782 ms 5.544 ms
ContentEngine#