ローカル管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.2
モニタリングおよびトラブルシュー ティング
モニタリングおよびトラブルシューティング
発行日;2012/02/02 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

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

識別情報の表示

スタンドアロンContent Engine のモニタリング

Cisco Discovery Protocol によるスタンドアロンContent Engine のモニタリング

SNMP によるスタンドアロンContent Engine のモニタリング

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

サポートされる MIB

スタンドアロンContent Engine への MIB ファイルのダウンロード

スタンドアロンContent Engine での SNMP エージェントの有効化

スタンドアロンContent Engine での SNMP ユーザの定義

SNMP トラップを送信するためのスタンドアロンContent Engine の設定

スタンドアロンContent Engine での SNMP エージェントの無効化

スタンドアロンContent Engine での SNMP トラップの無効化

ACNS ソフトウェア アラームによるスタンドアロンContent Engine のモニタリング

アラームの重大度

過負荷アラーム

アプリケーションの動作状況の確認

スタンドアロンContent Engine での SNMP アラーム トラップの設定

ACNS ソフトウェア アラームに関する情報の表示

ACNS ソフトウェア アラームに関する詳細情報の表示

ACNS ソフトウェア アラームに関する履歴情報の表示

ACNS ソフトウェア アラームに関するステータス情報の表示

スタンドアロンContent Engine でのトランザクションのモニタリング

特定プロトコルの統計情報の表示

スタンドアロンContent Engine でのクリティカル ディスク ドライブのモニタリング

ディスク エラー処理しきい値の指定

Content Engine ディスク ドライブに対する手作業でのマークとマークの解除

現在のディスク設定に関する詳細情報の表示

単一ディスク ドライブ上でのすべてのディスク パーティションの削除

ACNS ソフトウェア トランザクション ログの使用

トランザクション ロギングの有効化

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

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

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

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

認証ユーザ名の Windows ドメインの記録

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

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

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

スタンドアロンContent Engine でのトランザクション ロギングのエクスポート設定の変更

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

作業ログのアーカイブ

スタンドアロンContent Engine でトランザクション ロギングのエクスポートをディセーブルにするには

HPPT 要求認証障害のリアルタイムでのモニタリング

リアルタイム トランザクション ロギングのためのリモート Syslog ホストの設定

リモート syslog ホストへのロギングの際のトランザクション ログ ファシリティの設定

リモート syslog ホストへのロギングの際のトランザクション ログ エントリ タイプの指定

スタンドアロンContent Engine でのトランザクション ログ設定の表示

システム ロギング機能の使用

システム ロギングの現在の設定の表示

スタンドアロンContent Engine でのシステム ロギングの設定

コンソールに対するシステム ロギングの設定

ディスクに対するシステム ロギングの設定

リモート syslog ホストに対するシステム ロギングの設定

syslog プライオリティ レベルの RealProxy エラー コードへのマッピング

CiscoWorks2000 の使用

スタンドアロンContent Engine での HTTP カスタム エラー ページの作成

HTTP CLI クライアントでのトラブルシューティング

ログ表示ツールでのトラブルシューティング

Telnet クライアントでのトラブルシューティング

Ping のトラブルシューティング

traceroute を使用したトラブルシューティング

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

この章では、ローカル側で管理される環境(スタンドアロンContent Engine)でのモニタリングとトラブルシューティングの方法を説明します。この章の構成は、次のとおりです。

「識別情報の表示」

「スタンドアロンContent Engine のモニタリング」

「スタンドアロンContent Engine でのトランザクションのモニタリング」

「HPPT 要求認証障害のリアルタイムでのモニタリング」

「システム ロギング機能の使用」

「スタンドアロンContent Engine での HTTP カスタム エラー ページの作成」

「HTTP CLI クライアントでのトラブルシューティング」

「ログ表示ツールでのトラブルシューティング」

「Ping のトラブルシューティング」

「traceroute を使用したトラブルシューティング」


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

Content Router、Content Distribution Manager、または、Content Distribution Manager に登録されている Content Engine(Content Distribution Manager に登録されていない Content Engine の場合とは異なる)のモニタリングとトラブルシューティングについては、『中央管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.2』を参照してください。


識別情報の表示

Cisco Content Engine には、次の 3 つの識別項目が含まれています。

製品 ID (PID)

バージョン ID (VID)

シリアル番号 (SN)

この識別情報は、不揮発性メモリに格納されています。各 Content Engine には、一意のデバイス識別番号 (UDI) があります。つまり、UDI = PID + VID + SN となります。

UDI は、固有のハードウェア デバイスを識別する場合に、製品のオペレーティング システムやネットワーク管理アプリケーションによって電子的にアクセスされます。したがって、UDI データの整合性は、お客様にとってきわめて重大です。Content Engine の不揮発性メモリにプログラムされる UDI は、製品ラベルや製品が収められるダンボール箱に印刷される UDI と一致します。また、この UDI は、お客様が所有するすべてのシステムやツールでも、電子的に表示できるすべての UDI と一致します。

ACNS 5.2 ソフトウェアでは、Content Engine の管理者が Content Engine の UDI を参照できるように show inventory EXEC コマンドが追加されました。現在のところ、CLI アクセスの場合、UDI 情報の表示は可能ですが、SNMP アクセスの場合、UDI 情報の表示はできません。

ACNS 5.2 ソフトウェアでサポートされるすべての Content Engine モデルで、この新しい識別情報の表示機能がサポートされます。

新しい Content Engine モデルでは、 show inventory EXEC コマンドを使用して、Content Engine の UDI を表示することができます。

CE-256.28kg show inventory
PID: CE-565-K9 VID: 0 SN: serial number
 

ここで、 serial number は、Content Engine のシリアル番号です。バージョン番号が利用できる場合は、あわせて表示されます。バージョン番号が利用できない場合は、ゼロ 「0」 と表示されます(前述の例のとおり)。

従来の Content Engine モデル(CE-507、CE-2636 など)で Content Engine の UDI を表示する場合には、 show tech-support コマンドと show inventory EXEC コマンドを使用する必要があります。

CE-507# show inventory
Please look at 'sh tech-support' for information!
CE-507# show tech-support

) ACNS ソフトウェアの Release 5.2 でサポートされるハードウェア プラットフォームのリストは、『Release Notes for Cisco ACNS Software, Release 5.2』を参照してください。


スタンドアロンContent Engine のモニタリング

パフォーマンスを測定して、設定の調整に必要な兆候を見つけたり、Content Engine を追加導入したりするためには、Content Engine をモニタリングすることが重要です。ここでは、Simple Network Management Protocol(簡易ネットワーク管理プロトコル; SNMP)と ACNS ソフトウェア アラームを使用してスタンドアロンContent Engine をモニタリングする方法を説明します。

ACNS ソフトウェア リリース 5.2 以降が実行されているスタンドアロンContent Engine のパフォーマンスをモニタリングするために、複数のツールが用意されています。これらのツールには、Cisco Discovery Protocol (CDP)、SNMP、ACNS ソフトウェア アラームなどがあります。詳しくは、次の項を参照してください。

Cisco Discovery Protocol によるスタンドアロンContent Engine のモニタリング

SNMP によるスタンドアロンContent Engine のモニタリング

ACNS ソフトウェア アラームによるスタンドアロンContent Engine のモニタリング

Cisco Discovery Protocol によるスタンドアロンContent Engine のモニタリング

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

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

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

次の例では、単一の CLI コマンドによってスタンドアロンContent Engine での CDP の実行を有効にします。

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

SNMP によるスタンドアロンContent Engine のモニタリング

簡易ネットワーク管理プロトコル(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 ホスト」と呼ばれます。

SNMP 管理ステーションとデバイス エージェント(Content Engine 上の SNMP エージェント)は、SNMP を使用して次のような通信を行います。

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

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


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


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

図 20-1 に、Content Engine がスタンドアロンの場合の、SNMP の動作を示します。

図 20-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 パケットの処理時に使用するセキュリティ プロセスが決まります。セキュリティ モデルには、SNMPv1、SNMPv2c、および SNMPv3 の 3 種類があります。

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

 

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

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

v1

noAuthNoPriv

コミュニティ ストリング

なし

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

v2c

noAuthNoPriv

コミュニティ ストリング

なし

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

v3

noAuthNoPriv

ユーザ名

なし

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

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


) CISCO-CONTENT-ENGINE-MIB では、WMT ストリーミング、RealProxy、および、Cisco Streaming Engine の統計情報がサポートされるようになりました。スタンドアロンContent Engine では、WMT と RealProxy がサポートされます。Cisco Streaming Engine は、Content Distribution Manager に登録された Content Engine でのみサポートされます。つまり、Cisco Streaming Engine は、Content Engine ではサポートされません。

ACNS 5.2 ソフトウェアでは、SNMP と Node Health Manager との整合性のため、この MIB に 6 つの汎用アラーム トラップが追加されました。6 つの汎用アラーム トラップのリストについては、表 20-5を参照してください。


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

スタンドアロンContent Engine への MIB ファイルのダウンロード

次の Cisco FTP サイトから MIB ファイルをダウンロードすることにより、ACNS 5.x ソフトウェアが実行されているスタンドアロンContent Engine でサポートされているすべての MIB を入手できます。

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

各 MIB で定義されている MIB オブジェクトの説明は、前述の FTP サイトにある MIB ファイルに記載されています。

スタンドアロンContent Engine での SNMP エージェントの有効化

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

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

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

Content Engine CLI から、 snmp-server community コマンドを使用します。次に例を示します。

ContentEngine(config)# snmp-server community comaccess
 

SNMPv3 プロトコルを SNMP 要求に使用する場合、次のステップで、SNMP ユーザ アカウントを定義します。SNMP ユーザ アカウントは、SNMP を介したスタンドアロンContent Engine へのアクセスに使用されます。SNMPv 3 ユーザ アカウントをスタンドアロンContent Engine 上に作成する方法に関する詳細は、「スタンドアロンContent Engine での SNMP ユーザの定義」を参照してください。

スタンドアロンContent Engine での 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 上で SNMPv3 ユーザ アカウントを定義できます。

Content Engine GUI を使用してスタンドアロンContent Engine 上に SNMPv3 ユーザ アカウントを設定する手順は、次のとおりです。


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

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

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

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

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

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


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

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

HMAC-MD5-96 認証レベルの場合は、md5 を選択します。

HMAC-SHA-96 認証レベルの場合は、sha を選択します。

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

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

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

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

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


 

Content Engine CLI を使用してスタンドアロンContent Engine(SNMP サーバ)上に SNMPv3 ユーザ アカウントを定義するには、 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 ]}]]

表 20-2 では、 snmp-server user コマンドのパラメータについて説明します。

 

表 20-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 の設定

Content Engine GUI または CLI のいずれかを使用すると、スタンドアロンContent Engine 上で SNMP トラップの送信を設定できます。

Content Engine GUI から、 System > SNMP の順に選択します。SNMP ウィンドウが表示されます。SNMP ウィンドウから、次のいずれかを実行します。

SNMP トラップを特定の SNMP ホストに送信するように Content Engine の SNMP v1 または SNMPv2 のエージェントを設定する場合は、このウィンドウの該当するフィールドに情報を入力し、 UPDATE をクリックします。

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

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

SNMPv3 ユーザ アカウントを設定する場合の詳細は、「SNMPv3 ユーザの定義」を参照してください。SNMP ウィンドウのフィールドに関する詳細は、ウィンドウの一番下の HELP ボタンをクリックし、情報を参照してください。

Content Engine CLI を使用して、SNMP トラップを送信するようスタンドアロンContent Engine を設定する場合は、次の点に注意してください。

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

SNMP エージェントは、デフォルトで無効にされており、コミュニティ ストリングは設定されていません。

Content Engine GUI を使用してスタンドアロンContent Engine 上に SNMPv3 トラップを設定する手順は、次のとおりです。


ステップ 1 snmp-server group グローバル設定コマンドを使用して、セキュリティ モデル グループ(SNMPv1、SNMPv2c、SNMPv3)の中からいずれか 1 つを選択します。

snmp-server group name { v1 [ notify name ] [ read name ] [ write name ] | v2c [ notify name ] [ read name ] [ write name ] | v3 { auth [ notify name ] [ read name ] [ write name ] | noauth [ notify name ] [ read name ] [ write name ] | priv [ notify name ] [ read name ] [ write name ]}}

ここで各パラメータの意味は、次のとおりです。

 

name

グループの名前。

v1

Version 1 セキュリティ モデルを使用するグループを指定する。

notify

(オプション)グループの通知ビューを指定する。

name

通知ビューの名前。

read

(オプション)グループの読み取りビューを指定する。

name

読み取りビューの名前。

write

(オプション)グループの書き込みビューを指定する。

name

書き込みビューの名前。

v2c

Version 2c セキュリティ モデルを使用するグループを指定する。

v3

ユーザ セキュリティ モデル (SNMPv3) を使用するグループを指定する。

auth

AuthNoPriv セキュリティ レベルを使用するグループを指定する。

noauth

noAuthNoPriv セキュリティ レベルを使用するグループを指定する。

priv

AuthPriv セキュリティ レベルを使用するグループを指定する。

ステップ 2 snmp-server enable traps グローバル設定コマンドを使用して、Content Engine 上のすべての SNMP トラップをイネーブルにします。

ContentEngine(config)# snmp-server enable traps
 

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

ステップ 3 snmp-server host グローバル設定コマンドを使用して、SNMP トラップを Content Engine から受信するホスト(単数または複数)を指定します。SNMP トラップを送信するには、少なくとも 1 つの SNMP トラップ ホストを設定する必要があります。


) ACNS ソフトウェア リリース 5.1 以前の場合、設定できる SNMP ホストは最大で 4 つまでです。ACNS ソフトウェア リリース 5.2 以降では、Content Engine 上に最大で 8 つまでの SNMP ホストを設定できます。


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

ContentEngine(config)# snmp-server host 172.31.2.160 public
 

ステップ 4 Content Engine 上の SNMP エージェントを有効にし、Content Engine 上で SNMP エージェントにアクセスする際の認証パスワードとして、コミュニティ ストリングを割り当てます。

次の例では、パスワードとして comaccess を指定していることを示しています。

ContentEngine(config)# snmp-server community comaccess

ヒント Content Engine に送信されるすべての SNMP メッセージでは、メッセージの「Community Name」フィールドが、認証のためにここで定義されたコミュニティ ストリングと一致する必要があります。

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

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

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


 

スタンドアロンContent Engine での SNMP エージェントの無効化

スタンドアロンContent Engine 上で SNMP エージェントをディセーブルにするには、 no snmp-server グローバル設定コマンドを使用します。

ContentEngine(config)# no snmp-server
 

SNMP エージェントを無効にし、定義済みのコミュニティ ストリングを削除する場合は、 no snmp-server community グローバル設定コマンドを使用します。

ContentEngine(config)# no snmp-server community

スタンドアロンContent Engine での SNMP トラップの無効化

スタンドアロンContent Engine 上ですべての SNMP トラップを無効にするには、 no snmp-server enable traps グローバル設定コマンドを使用します。

ContentEngine(config)# no snmp-server enable traps
 

MIB-II SNMP 認証トラップの送信を無効にする場合は、 no snmp-server enable traps snmp authentication コマンドを使用する必要があります。

ACNS ソフトウェア アラームによるスタンドアロンContent Engine のモニタリング

SNMP は、従来より、SNMP トラップ生成時のエラー条件のレポートに使用されてきました。ACNS 5.x では、「スタンドアロンContent Engine でのトランザクションのモニタリング」に説明されているとおり、引き続きこのモニタリング メカニズムが使用されます。

ACNS 5.2 ソフトウェアでは、Node Health Manager 機能が追加されました。Node Health Manager を使用すると、ACNS アプリケーションでは、エラーや特に注意すべき状態の場合に注意を促すようにアラームを生成できるようになります。Node Health Manager とは、このようなアラームのデータ リポジトリで、Content Engine 上でモニタリングされているアプリケーション、サービス(キャッシュ サービスなど)、リソース(ディスク ドライブなど)の状況やアラーム情報が収集されます。たとえば、この新機能のメカニズムによって、モニタリングされているアプリケーション(HTTP プロキシ キャッシング サービスなど)が、Content Engine 上で正常に動作しているかどうかを調べることができます。これらのアラームは、「ACNS ソフトウェア アラーム」と呼ばれています。

ACNS 5.2 ソフトウェアでは、次のアプリケーションで ACNS ソフトウェア アラームを生成させることが可能です。

Node Health Manager (過負荷状況と Node Manager の動作状況に関するアラーム)

サービス障害発生時の Node Manager (モニタリングされているアプリケーションの動作状況)

ディスク障害発生時の System Monitor (sysmon)

Content Engine によって通知されたアラームは、 表 20-3 のように、Content Engine の CLI コマンドを使用してリストできます。通知されたアラームと解除されたアラームすべてについて、SNMP トラップが送信されます。送信される SNMP トラップのタイプは、アラームによってさまざまです。


) Content Distribution Manager に登録されている Content Engine の場合、Content Distribution Manager に対しても、Node Health Manager によってアラームの通知が送信されます。このトピックの詳細は、『中央管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.2』を参照してください。


ACNS 5.2 ソフトウェアでは、ACNS ソフトウェア アラーム(問題の原因)の発信元を系統立てて調べることができるようにするため、複数のCLI コマンドが追加されました。 表 20-3 を参照してください。CLI コマンドを使用すると、非常に多くの ACNS ソフトウェア ログを 1 つ 1 つ確認することなく、問題の発信元を特定できます。

 

表 20-3 Show Alarms CLI コマンドのリスト

CLI コマンド
説明
詳細

show alarm

Content Engine 上で現在通知されているすべての ACNS ソフトウェア アラーム(クリティカル、メジャー、マイナーの各アラーム)のリストを表示する。

「ACNS ソフトウェア アラームに関する情報の表示」を参照してください。

show alarm critical

Content Engine 上で現在通知されているACNS ソフトウェア クリティカル アラームのみのリストを表示する。

「ACNS ソフトウェア アラームに関する情報の表示」を参照してください。

show alarm major

Content Engine 上で現在通知されている ACNS ソフトウェア メジャー アラームのみのリストを表示する。

「ACNS ソフトウェア アラームに関する情報の表示」を参照してください。

show alarm minor

Content Engine 上で現在通知されているACNS ソフトウェア マイナー アラームのみのリストを表示する。

「ACNS ソフトウェア アラームに関する情報の表示」を参照してください。

show alarm detail

現在通知されている ACNS ソフトウェア アラームに関する詳細情報を表示する。

「ACNS ソフトウェア アラームに関する詳細情報の表示」を参照してください。

show alarms history

Content Engine 上で以前通知され、解除された ACNS ソフトウェア アラームの履歴を表示する。CLI には、以前に通知され、解除されたイベントのうち、最新の 100 アラームのみが記録される。

「ACNS ソフトウェア アラームに関する履歴情報の表示」を参照してください。

show alarms status

Content Engine 上で現在通知されているACNS ソフトウェア マイナー アラームの数を表示する。過負荷状態のアラームと過負荷設定のアラームもリストされる。

「ACNS ソフトウェア アラームに関するステータス情報の表示」を参照してください。


) スタンドアロンContent Engine では、ACNS ソフトウェア アラームに関する情報は、Content Engine CLI を介した場合だけでなく、SNMP を介した場合でも利用可能です。スタンドアロンContent Engine 上でこのアラーム情報にアクセス可能な CLI コマンドのリストについては、表 20-3 を参照してください。


アラームの重大度

ACNS ソフトウェア アラームには、3 つのレベルがあります。 表 20-4 を参照してください。

 

表 20-4 ACNS ソフトウェア アラームのアラーム重大度のレベル

アラーム レベル
説明

クリティカル

Content Engine を介した既存のトラフィックに影響を及ぼすアラームで、致命的な状況と見なされる(Content Engine は回復不能で、トラフィック処理を継続できない)。

メジャー

主要サービス(キャッシュ サービスなど)に障害が発生しているか、通信不能な状況を示すアラーム。このサービスを回復させるための処置が早急に必要とされる。しかし、他のノード コンポーネントは正常に動作しており、既存サービスへの影響は最小限であると考えられる。

マイナー

サービスに影響を及ぼさないと考えられる状況(Non-service Affecting 状況)を示すアラームが発生しているが、深刻な障害の発生を防ぐため、修正処置が必要とされる。

show alarms history EXEC コマンドによる出力には、ACNS ソフトウェア アラームの重大度が含まれることに、注意してください。出力例については、以下を参照してください。

ContentEngine# show alarms history
 
Op Sev Alarm ID Module/Submodule Instance
-- --- -------------------- -------------------- --------------------
1 C Mi servicedead nodemgr mediacache
2 C Mi servicedead nodemgr cache
3 R Mi servicedead nodemgr mediacache
4 R Mi servicedead nodemgr cache
5 C Mi servicedead nodemgr rpc_httpd
6 R Mi servicedead nodemgr rpc_httpd
7 C Mi servicedead nodemgr rpc_httpd
8 R Mi servicedead nodemgr rpc_httpd
9 C Mi servicedead nodemgr mediacache
10 C Mi servicedead nodemgr cache
11 R Mi servicedead nodemgr mediacache
12 R Mi servicedead nodemgr cache
13 C Mi servicedead nodemgr cache
14 C Mi servicedead nodemgr mediacache
15 C Mi servicedead nodemgr rtspg
16 R Mi servicedead nodemgr cache
17 R Mi servicedead nodemgr mediacache
18 R Mi servicedead nodemgr rtspg
 
 
Op - Operation: R-Raised, C-Cleared
Sev - Severity: Cr-Critical, Ma-Major, Mi-Minor

過負荷アラーム

ACNS ソフトウェア リリース 5.2 以降が実行されている Content Engine では、Node Health Manager からの一定時間あたりのアラームの着信量をトラッキングできます。一定時間あたりのアラームの着信量が最高水準点 (HWM) を超えた場合、Content Engine はアラーム過負荷状態になります。スタンドアロンContent Engine がアラーム過負荷状態になった場合、次の状況が発生します。

以降に通知されるアラームと解除されるアラームに対する SNMP トラップは、一時停止されます。通知アラームと解除アラームに対し、それぞれ過負荷アラームのトラップが送信されます。しかし、通知アラームの過負荷アラームと解除アラームの過負荷アラームの間に発生するアラーム操作に関するトラップは、一時停止されます。

過負荷アラームの通知と解除の送信はブロックされません。

一定時間あたりのアラームの着信量が最低水準点(LWM)より小さくなるまで減少した場合、Content Engine の状態はアラーム過負荷状態のままになります。

アプリケーションの動作状況の確認

Node Manager により、Content Engine 上で実行中のアプリケーション(HTTP キャッシュ アプリケーション、WMT ストリーミング アプリケーション、RTSP ゲートウェイ (RTSPG) ストリーミング アプリケーションなど)の動作状況がトラッキングされます。Node Manager によってアプリケーションの障害が検出された場合、アラームが生成されます。Node Manager がアプリケーションからキープアライブ信号を受信しなくなった時点で、アプリケーションに障害が発生したと見なされます。

アプリケーションに障害が発生した際は、Node Manager によってサービス障害アラームが生成され、状況がレポートされます。次に、サービスが再起動されます。サービスの実行が短時間(通常は 10 秒間)確認された場合、「サービス障害」アラームは解除されます。

再起動後にもアプリケーションに障害が発生した場合は、サービス障害アラームの通知が継続され、Node Manager によってサービスの再起動が試行されます。再起動は、通常、Node Manager によって最大 10 回まで行われます。Node Manager により、該当サービスについてサービス無効アラームが通知された後、「サービス障害」アラームが解除され、サービス再起動の試行は停止されます。

サービスを再起動するためには、該当機能の設定を解除し、設定し直す必要があります(たとえば、NTP サービスの場合、no ntp server hostname | IP address グローバル設定コマンドを使用して NTP サービスの設定を解除し、ntp server hostname | IP address グローバル設定コマンドを使用して NTP サービスを再設定します)。

スタンドアロンContent Engine での SNMP アラーム トラップの設定

Content Engine では、特定のアラーム状況に対して SNMP トラップを生成させるように設定することができます。スタンドアロンContent Engine では、次の観点から、SNMP アラーム トラップの生成を設定できます。

アラームの重大度(クリティカル、メジャー、マイナー)

アクション(アラーム通知と解除の際の)

ACNS 5.2 ソフトウェアでは、CISCO-CONTENT-ENGINE-MIB (CCE MIB) に次の 6 つの汎用アラーム トラップが追加されました。 表 20-5 を参照してください。

 

表 20-5 汎用アラーム トラップ

アラーム トラップの名前
重大度
アクション
Content Engine 上でアラーム トラップを
有効にする CLI コマンド

cceAlarmCriticalRaised

クリティカル

通知

snmp-server enable traps alarm raise-critical

cceAlarmCriticalCleared

クリティカル

解除

snmp-server enable traps alarm clear-critical

cceAlarmMajorRaised

メジャー

通知

snmp-server enable traps alarm raise-major

cceAlarmMajorCleared

メジャー

解除

snmp-server enable traps alarm clear-major

cceAlarmMinorRaised

マイナー

通知

snmp-server enable traps alarm raise-minor

cceAlarmMinorCleared

マイナー

解除

snmp-server enable traps alarm clear-minor


) これら 6 つの汎用アラーム トラップは、デフォルトで、無効にされています。


この 6 つの汎用アラーム トラップにより、SNMP と Node Health Manager の間の整合性が保たれます。6 つの汎用アラーム トラップは、Content Engine CLI を使用して有効や無効にできます。ACNS 5.2 ソフトウェアでは、 snmp-server enable traps グローバル設定コマンドの機能が拡張され、 alarm オプションが追加されるようになりました(下記を参照)。

ContentEngine(config)# snmp-server enable traps alarm ?
clear-critical Enable clear-critical alarm trap
clear-major Enable clear-major alarm trap
clear-minor Enable clear-minor alarm trap
raise-critical Enable raise-critical alarm trap
raise-major Enable raise-major alarm trap
raise-minor Enable raise-minor alarm trap
 

次の例では、クリティカル アラームが解除された場合に SNMP トラップが生成されるように、Content Engine (SNMPサーバ)上で設定を行っています。

ContentEngine(config)# snmp-server enable traps alarm clear-critical

ACNS ソフトウェア アラームに関する情報の表示

スタンドアロンContent Engine 上で現在通知されているすべてのクリティカル、メジャー、マイナーの各アラームに関する情報を表示する場合は、show alarm EXEC コマンドを使用します。Content Engine 上で現在通知されているアラームがない場合は、「None」と表示されます。次の例を参照してください。

ContentEngine# show alarm
 
Critical Alarms:
----------------
None
 
Major Alarms:
-------------
None
 
Minor Alarms:
-------------
None
 

また、次に示すとおり、Content Engine 上で現在通知されている ACNS ソフトウェア アラームのうち、指定したレベルのみの情報を表示することもできます。

クリティカル アラームのみの情報を表示するには、show alarm critical EXEC コマンドを使用します。

メジャー アラームのみの情報を表示するには、 show alarm major EXEC コマンドを使用します。

マイナー アラームのみの情報を表示するには、show alarm minor EXEC コマンドを使用します。


) アラームのさまざまな重大度(クリティカル、メジャー、マイナー)に関する詳細は、表 20-4 を参照してください。


ACNS ソフトウェア アラームに関する詳細情報の表示

現在通知されている SNMP アラームの詳細を表示する場合は、 show alarm detail EXEC コマンドを使用します。このコマンドを使用すると、特定のアラームに関するより詳細な情報を確認できます。

ACNS ソフトウェア アラームに関する履歴情報の表示

スタンドアロンContent Engine 上で以前通知され、解除された ACNS ソフトウェア アラームの履歴を表示する場合は、 show alarms history EXEC コマンドを使用します。

ContentEngine# show alarms history
 
Op Sev Alarm ID Module/Submodule Instance
-- --- -------------------- -------------------- --------------------
1 C Mi servicedead nodemgr mediacache
2 C Mi servicedead nodemgr cache
3 R Mi servicedead nodemgr mediacache
4 R Mi servicedead nodemgr cache
5 C Mi servicedead nodemgr rpc_httpd
6 R Mi servicedead nodemgr rpc_httpd
7 C Mi servicedead nodemgr rpc_httpd
8 R Mi servicedead nodemgr rpc_httpd
9 C Mi servicedead nodemgr mediacache
10 C Mi servicedead nodemgr cache
11 R Mi servicedead nodemgr mediacache
12 R Mi servicedead nodemgr cache
13 C Mi servicedead nodemgr cache
14 C Mi servicedead nodemgr mediacache
15 C Mi servicedead nodemgr rtspg
16 R Mi servicedead nodemgr cache
17 R Mi servicedead nodemgr mediacache
18 R Mi servicedead nodemgr rtspg
 
 
Op - Operation: R-Raised, C-Cleared
Sev - Severity: Cr-Critical, Ma-Major, Mi-Minor
 

アラームに関するより詳細な情報を表示する場合は、 show alarms history detail support EXEC コマンドを使用します。

Content Engine# show alarms history detail support
Op Sev Alarm ID Module/Submodule Instance
-- --- -------------------- -------------------- --------------------
1 C Mi servicedead nodemgr rtspg
Jul 2 18:22:040.577 UTC, Processing Error Alarm, #000001, 2000:330004
nodemgr: The rtspg service has died.
 
/alm/min/nodemgr/-service_name-/servicedead:
-service name- service has died.
Explanation:
The node manager found the specified service to be dead.
Attempts will be made to restart this service.
Action:
Examine the syslog for messages relating to cause of service
death. The alarm will be cleared if the service stays
alive and does not restart in a short while.
2 R Mi servicedead nodemgr rtspg
Jul 2 18:21:54.231 UTC, Processing Error Alarm, #000001, 2000:330004
nodemgr: The rtspg service has died.
 
/alm/min/nodemgr/-service_name-/servicedead:
-service name- service has died.
Explanation:
The node manager found the specified service to be dead.
Attempts will be made to restart this service.
Action:
Examine the syslog for messages relating to cause of service
death. The alarm will be cleared if the service stays
alive and does not restart in a short while.
Op - Operation: R-Raised, C-Cleared
Sev - Severity: Cr-Critical, Ma-Major, Mi-Minor

ACNS ソフトウェア アラームに関するステータス情報の表示

スタンドアロンContent Engine 上で現在通知されているすべてのアラームの数を表示する場合は、show alarms status EXEC コマンドを使用します。現在通知されている ACNS ソフトウェア アラームの数は、次の例のように表示されます。表示には、過負荷アラーム設定(Content Engine 上で現在過負荷検出が有効にされているか無効にされているかなど)に関する情報も含まれます。

ContentEngine# show alarms status
 
Critical Alarms : 0
Major Alarms : 0
Minor Alarms : 0
 
Overall Alarm Status : None
Device is NOT in alarm overload state.
Device enters alarm overload state @ 10 alarms/sec.
Device exits alarm overload state @ 1 alarms/sec.
Overload detection is DISABLED.

スタンドアロンContent Engine でのトランザクションのモニタリング

Content Engine の管理者は、一般的に、Content Engine 上で行われた要求のタイプや要求によってもたらされた結果に注目します。たとえば、ストリーミング メディアが会社の収入源である場合、その会社では、どのお客様がどのコンテンツにアクセスしたか、ユーザがどれくらいの時間コンテンツを見たか、また、その表示時の品質などをトラッキングする手段が必要になります。これらの会社では、オンデマンド コンテンツやライブ ブロードキャストの配信について課金する必要があるため、コンテンツ アクセス サービスに関するお客様への請求については、記録された情報に基づいて行う必要があります。

Content Engine によって処理された要求の履歴は、ソフトウェアによって記録され、「トランザクション ログ」と呼ばれます。通常トランザクション ログに記録される一般的なフィールドは、クライアントの要求が行われた日付と時刻、要求された URL、キャッシュ ヒットであったかキャッシュ ミスであったか、要求のタイプ、転送されたバイト数、およびソース IP アドレスです。

トランザクション ログは、通常、次のような目的で使用されます。

問題の特定と解決

負荷のモニタリング

課金請求

統計分析

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

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

ACNS 5.2 ソフトウェアでは、Windows Media Services 9 のログ機能のサポートが追加されました。Windows Media Services 9 シリーズでは、Windows Media Services Version 4.1 よりもより強固なロギング モデルが提供されています。

定義済みの形式での記録が可能です(Squid、拡張 Squid、Apache の各形式や、ユーザが指定するカスタム トランザクション ログ形式をログ追加フィールドに追加することも可能)。トランザクション ログの内容は、FTP を使用して定期的に外部サーバにエクスポートできます。また、ログ ローテーション ポリシーの設定も可能です。

ACNS 5.x ソフトウェアが実行されているスタンドアロンContent Engine では、レポートの目的で、すべてのエラーとアクセス アクティビティを記録できます。ACNS 5.x ソフトウェアでは、Content Engine 上の各コンテンツ サービス モジュール(HTTP モジュール、WMT サーバ、FTP プロキシ プロセス、TFTP サーバなど)によって、サービスされた要求のログが記録されます。たとえば、次のタイプの要求が記録されます。

HTTP 要求

HTTPS 要求

FTP 要求

WMT 要求

RTSP ストリーミング要求

WMT 要求

TFTP 要求


) 「トランザクション」という用語は、Web リソースにおいてクライアントによって実行され、正常終了または異常終了した要求を指します。


特定プロトコルの統計情報の表示

コンテンツ転送の各プロトコルには、それぞれ、個々のプロトコルの統計情報を表示するための show protocol-name statistics EXEC コマンドがあります。たとえば、show statistics http EXEC コマンドを使用すると、Content Engine によってサービスされた HTTP 要求に関する重要な統計情報を表示することが可能です。

ContentEngine# show statistics http ?
cluster Display healing mode statistics
ims Display If-Modified-Since statistics
miss-reason Display miss/revalide/no-store reason statistics
object Display object statistics
performance Display performance statistics
proxy Display proxy mode statistics
requests Display request statistics
savings Display savings statistics
usage Display usage statistics
 

show protocol-name statistics EXEC コマンドのリストについては、 表 20-6 を参照してください。このコマンドの詳細については、『Cisco ACNS Software Command Reference, Release 5.2』を参照してください。

 

表 20-6 show protocol-name statistics EXEC コマンド

コマンド
説明

show statistics https [ error | requests ]

Content Engine の HTTPS 統計情報を表示する。

show statistics http { cluster | ims | miss-reason | object | performance | proxy outgoing | requests | savings | usage }

Content Engine の HTTP 統計情報を表示する。

show statistics ftp

Content Engine の FTP 統計情報を表示する。ネイティブの FTP 要求だけでなく、FTP-over-HTTP 要求の統計情報も含まれる(透過的な FTP GET 要求の数など)。

show statistics rtsp { proxy media-real { requests | savings }} { all | bw-usage | performance | requests }

Content Engine の RealMedia 要求の統計情報を表示する。

show statistics wmt { all | bytes [ incoming | outgoing ] | errors | multicast | requests | rule | savings | streamstat | urlfilter | usage }

Content Engine の WMT 要求の統計情報を表示する。

次の例では、 show statistics https requests EXEC コマンドを使用して、Content Engine によってサービスされた HTTPS 要求に関する統計情報を表示する方法を示します。

ContentEngine# show statistics https requests
 
HTTPS Statistics
Total % of Total
---------------------------------------------------
Total connections: 1328 -
Tunneled (CONNECT): 0 0.0
Tunneled (wccp): 0 0.0
SSL terminated: 0 0.0
Connection errors: 0 0.0
Total bytes: 8013157 -
Bytes received from client: 1602824 20.0
Bytes sent to client: 6410333 80.0
Bytes received from server: 0 0.0
 

次の例では、 show statistics http proxy outgoing EXEC コマンドを使用して、正常終了または異常終了したプロキシ要求の発信に関する統計情報を表示する方法を示します。

ContentEngine# show statistics http proxy outgoing
HTTP Outgoing Proxy Statistics
 
IP PORT ATTEMPTS FAILURES
--------------------------------------------------------------------
10.10.10.10 1 49026 49026
 

次の例では、 show statistics http requests EXEC コマンドを使用して、Content Engine で受信された HTTP 要求に関する統計情報を表示する方法を示します。

ContentEngine# show statistics http requests
Statistics - Requests
Total % of Requests
---------------------------------------------------
Total Received Requests: 525979748 -
Forced Reloads: 501468 0.1
Client Errors: 81834 0.0
Server Errors: 149808 0.0
URL Blocked (Reset): 514998075 97.9
URL Blocked: 0 0.0
Sent to Outgoing Proxy: 0 0.0
Failures from Outgoing Proxy: 0 0.0
Excluded from Outgoing Proxy: 0 0.0
ICP Client Hits: 0 0.0
ICP Server Hits: 0 0.0
If-Range Hits: 32 0.0
HTTP 0.9 Requests: 677 0.0
HTTP 1.0 Requests: 524097101 99.6
HTTP 1.1 Requests: 1881966 0.4
HTTP Unknown Requests: 4 0.0
Non HTTP Requests: 0 0.0
Non HTTP Responses: 1380 0.0
Chunked HTTP Responses: 1631953 0.3
Http Miss Due To DNS: 31050 0.0
Http Deletes Due To DNS: 12914 0.0
Objects cached for min ttl: 575986 0.1
 

次の例は、 show statistics http performance EXEC コマンドの出力例です。このコマンド出力では、Content Engine によって処理された HTTP 要求のパフォーマンスに関する統計情報が表示されます。

ContentEngine# show statistics http performance
Statistics - Performance
Avg Min Max Last
-------------------------------------------------------------
Requests / Second: - - 677 3
Bytes / Second: - - 5995814 81801
Seconds / Request: 0.067 0.000 15453.547 1.499
Seconds / Hit: 0.308 0.000 979.442 0.158
Seconds / Miss: 0.066 0.000 15453.547 1.572
-------------------------------------------------------------
Object Size: 150.2 Avg
0 Min
718732317 Max
21386.0 Last
 

次の例は、 show statistics http savings EXEC コマンドの出力例です。このコマンドでは、Content Engine が、オリジン Web サーバからコンテンツを受信したのではなく、ローカル HTTP キャッシュ(キャッシュ ヒット)から HTTP 要求を処理したために起こった節約に関する統計情報が表示されます。

ContentEngine# show statistics http savings
Statistics - Savings
Requests Bytes
-----------------------------------------------------------
Total: 525980242 79047534484
Hits: 1966223 19865155481
Miss: 524014019 59182379003
Savings: 0.4 % 25.1 %
 

次の例は、 show statistics rtsp proxy media-real requests EXEC コマンドの出力例です。このコマンド出力では、Content Engine によってサービスされた RTSP 要求の RealMedia キャッシングに関する統計情報が表示されます。

ContentEngine# show statistics rtsp proxy media-real requests
Media Cache Statistics - Requests
Total % of Requests
---------------------------------------------------
Total Received Requests: 0 -
Demand Cache Hit: 0 0.0
Demand Cache Miss: 0 0.0
Demand Pass-Through: 0 0.0
Live Split: 0 0.0
Live Pass-Through: 0 0.0
 

次の例は、 show statistics rtsp proxy media-real savings EXEC コマンドの出力例です。このコマンド出力例では、コンテンツをオリジン ストリーミング サーバから複数回受信するのではなく、ローカル キャッシュからサービスされたために起こった、RealMedia コンテンツに関するメディア キャッシュのヒットおよびミスの数と、節約の量が表示されます。

ContentEngine# show statistics rtsp proxy media-real savings
Media Cache Statistics - Savings
Requests Bytes
-----------------------------------------------------------
Total: 525980242 79047534484
Hits: 1966223 19865155481
Miss: 524014019 59182379003
Savings: 0.4 % 25.1 %
 

スタンドアロンContent Engine でのクリティカル ディスク ドライブのモニタリング

Content Engine が適切に動作するためには、次のようなクリティカル ディスク ドライブが必要です。

「disk00」と呼ばれる 1 台目のディスク ドライブ。

1 つめの sysfs (システム ファイル システム)パーティションが含まれるディスク ドライブ。

sysfs パーティションは、トランザクション ログ、システム ログ (syslog)、内部デバッグ ログを含むログ ファイルを保存するために使用されます。Content Engine 上のイメージ ファイルや設定ファイルの保存にも使用できます。


) 「クリティカル ドライブ」という用語は、disk00 または 1 台目の sysfs パーティションが含まれるディスク ドライブのいずれかを指すディスク ドライブとして定義されています。Content Engine モデルによって、クリティカル ドライブの状況も異なります。たとえば、より小規模な、ディスク ドライブが 1 台の Content Engine では、クリティカル ディスク ドライブは 1 台のみです。一方、より高性能な、複数のディスク ドライブがある Content Engine では、Content Engine 上にクリティカル ディスク ドライブが複数台ある場合もあります。


Content Engine がブートされた際のシステム起動時にクリティカル ディスク ドライブが検出されなかった場合、Content Engine 上の ACNS システムはサービス低下状態で実行されることになります。クリティカル ディスク ドライブの 1 台で実行時に障害が発生した場合、ACNS システムでは、不調、ハング、クラッシュなどの兆候が現れるか、ACNS システム自体のハングやクラッシュが発生する可能性があります。したがって、Content Engine 上のクリティカル ディスク ドライブをモニタリングし、ディスク ドライブ エラーが通知されるようにすることが非常に重要です。

ACNS システムでは、ディスク デバイス エラーは、次のいずれかのイベントとして定義されています。

Linux カーネルによって検出された SCSI または IDE デバイス エラー。

アプリケーションによるディスク デバイス アクセス(open(2)、read(2)、write(2)などのシステム コール)によって、EIO エラー コードで障害が発生した場合。

起動時に検出されたディスク デバイスに、実行時にアクセスできない場合。

ACNS 5.2 ソフトウェアでは、Content Engine ディスク ドライブをモニタリングする機能が追加されました。ディスク ステータスは、フラッシュ(不揮発性ストレージ)に記録されます。Content Engine のディスク ドライブにエラーが発生した際、sysfs パーティションが動作可能な場合にはメッセージがシステム ログに書き込まれ、Content Engine 上に SNMP が設定されている場合には SNMP トラップが生成されます。

Content Engine 上では、クリティカル ディスク ドライブの状態のトラッキングに加えて、ディスク デバイス エラー処理のしきい値も設定できます。ディスク デバイス エラーの数が指定されたしきい値に到達した場合、該当するディスク デバイスは自動的に「bad」とマークされます。ACNS システムでは、「bad」ディスク デバイスの使用がただちに中止されるわけではありません。「bad」ディスク ドライブの使用は、次のリブート後に中止されます。

指定されたしきい値を超えた場合、Content Engine では、このイベントが記録されるか、リブートが実行されます。自動リロード機能が有効の場合にしきい値を超えると、ACNS システムによって Content Engine が自動的にリブートされます。このしきい値を指定する場合の詳細は、「ディスク エラー処理しきい値の指定」を参照してください。


disk drive mark EXEC コマンドを使用すると、ディスク ドライブに手作業で「bad」または「good」とマークできます。このトピックに関する詳細は、「Content Engine ディスク ドライブに対する手作業でのマークとマークの解除」を参照してください。


ディスク エラー処理しきい値の指定

ACNS 5.2 ソフトウェアでは、ディスク エラー処理しきい値オプションが追加されました。このしきい値によって、ディスク ドライブが「bad」とマークされるまでに許容するディスク エラーの数を指定できます。デフォルトでは、このしきい値は 10 に設定されています。

デフォルトのしきい値を変更する場合は、 disk error-handling threshold グローバル設定コマンドを使用します。有効値は 0 ~ 100 までです。ディスク ドライブが「bad」とマークされるのを許容しない場合は、0 と指定します。

次の例では、ディスク ドライブが自動的に「bad」とマークされるまでに、指定されたディスク ドライブ(disk00など)に対して 5 回のディスク ドライブ エラーが許容されます。

ContentEngine(config)# disk error-handling threshold 5
 

bad ディスク ドライブがクリティカル ディスク ドライブの場合で、自動リロード機能( disk error-handling reload コマンド)が有効の場合、ACNS ソフトウェアによってディスク ドライブが「bad」とマークされ、Content Engine は自動的にリロードされます。Content Engine のリロード後、syslog メッセージと SNMP トラップが生成されます。

Content Engine 上での自動リロード機能は、デフォルトで無効です。自動リロード機能を有効にする場合は、 disk error-handling reload グローバル設定コマンドを使用します。

ContentEngine(config)# disk error-handling reload
 

自動リロード機能をイネーブルにした後で、また無効にする場合は、 no disk error-handling reload グローバル設定コマンドを使用します。

ContentEngine(config)# no disk error-handling reload

Content Engine ディスク ドライブに対する手作業でのマークとマークの解除

Content Engine 上のディスク ドライブは、次のような方法を使用して手作業でマークを解除するまで、「Not used」状態になります。

スタンドアロンContent Engine 上で、次のいずれかの disk add EXEC コマンドを使用します。これらの disk add コマンドのいずれかを使用すると、「Not used」状態がリセットされます。

disk add diskname [ sysfs { remaining | disk-space }] [cfs { remaining | disk-space }] |
[mediafs {
remaining | disk-space }]

disk mark EXEC コマンドを使用して、1 台またはすべてのディスク ドライブを手作業で「good」(使用する)または「bad」(リロード後には使用されない)とマークします。

次のシナリオでは、disk03 を「bad」とマークし、Content Engine をリロードし、disk03 から「bad」のマークを解除し、再び使用できるようにする方法を示します。

1. disk mark EXEC コマンドを使用して、disk03 を「bad」とマークします。

Content Engine# disk mark ?
WORD Disk name (e.g. disk00, disk01,..)
Content Engine# disk mark disk03 ?
bad Mark as bad disk drive, don't use it
good Mark as good disk drive
Content Engine# disk mark disk03 bad
disk03 is marked as bad.
It will be not used after reload.
 

2. show disks details EXEC コマンドを使用します。disk03 は、Content Engine のブート後にマークされたため、「*」が表示されています。disk03 は「Normal」(現在使用中)と表示されていることに注意してください。

Content Engine# show disks details
(*) Disk drive won't be used after reload.
......
disk03: Normal (h00 c00 i03 l00 - Int DAS) 70001MB( 68.4GB) (*)
FREE: 70001MB( 68.4GB)
......
 

3. reload EXEC コマンドを使用して、Content Engine をリロードします。次のプロンプトが表示されたら、 Enter キーを押して、リロードを実行します。Content Engine がリロードされた後、disk03 は「bad」とマークされています。このディスク ドライブは使用されません。

Content Engine# reload
Proceed with reload?[confirm]
......
 

4. リロードの完了後、 show disks details EXEC コマンドを使用します。disk03 は、ContentEngine のリブート後に「bad」と検出されたため、「Not used (*)」と表示されています。

Content Engine# show disks details
(*) Disk drive won't be used after reload.
......
disk03: Not used (*)
......
 

5. disk mark EXEC コマンドを使用し、手作業で「good」とマークすることにより、disk03 から「bad」のマークを解除します。

Content Engine# disk mark disk03 good
disk03 is marked as good.
It will be used after reload.
 

6. show disks details EXEC コマンドを使用して、disk03 が「Not used」とマークされていることを確認します。

Content Engine# show disks details
......
disk03: Not used
......

現在のディスク設定に関する詳細情報の表示

Content Engine の現在のディスク設定に関する詳細情報を表示する場合は、 show disks details EXEC コマンドを使用します。

ContentEngine# show disks details
disk00: Normal (IDE disk) 38160MB( 37.3GB)
disk00/04: PHYS-FS 15137MB( 14.8GB) mounted internally
disk00/04: MEDIAFS 532MB( 0.5GB) mounted internally
disk00/05: SYSFS 1023MB( 1.0GB) mounted at /local1
disk00/06: CFS 15359MB( 15.0GB)
System use: 6,130MB( 6.0GB)
FREE: 16MB( 0.0GB)
disk01:Not present
No NAS share is attached to this device.
 

現在「bad」とマークされているディスク ドライブは、 show disks details EXEC コマンドの出力では「Not used」と表示されます。「bad」状態になる予定のディスク ドライブ(Content Engine の次回のリロード後には使用されないドライブ)には、アスタリスク記号 (*) が付加されます。次の例では、Content Engine がリロードされた後、disk03 は「bad」状態になり、このディスク ドライブは使用されません。

ContentEngine# show disks details
(*) Disk drive won't be used after reload.
......
disk03: Normal (h00 c00 i03 l00 - Int DAS) 70001MB( 68.4GB) (*)
FREE: 70001MB( 68.4GB)
......

単一ディスク ドライブ上でのすべてのディスク パーティションの削除

単一のディスク ドライブ上のすべてのディスク パーティションを削除する場合は、 disk delete-partitions EXEC コマンドを使用します。


注意 disk delete-partitions EXEC コマンドは、指定されたディスク上からすべてを削除します。

このコマンドは、通常、他のオペレーティング システム(Microsoft Windows や Linux などのオペレーティング システム)で以前使用されていたディスク ドライブを、新しいディスク ドライブとして追加する場合に使用します。ディスク上のすべてを削除するかどうかを確認するプロンプトが表示された場合、処理を進めるときは、次のように「yes」と指定します。

ContentEngine# disk delete-partitions disk03
This will erase everything on disk. Are you sure? [no] yes

ACNS ソフトウェア トランザクション ログの使用

スタンドアロンContent Engine (キャッシングおよびストリーミング エンジン)の管理者は、一般的に、Content Engine 上で行われた要求のタイプや要求によってもたらされた結果に注目します。たとえば、ストリーミング メディアが会社の収入源である場合、その会社では、どのお客様がどのコンテンツにアクセスしたか、ユーザがどれくらいの時間コンテンツを見たか、また、その表示時の品質などをトラッキングする手段が必要になります。これらの会社では、オンデマンド コンテンツやライブ ブロードキャストの配信について課金する必要があるため、コンテンツ アクセス サービスに関するお客様への請求については、記録された情報に基づいて行う必要があります。

ACNS 5.x ソフトウェアが実行されているスタンドアロンContent Engine では、すべてのエラーとアクセス アクティビティを記録できます。ACNS 5.x ソフトウェアでは、Content Engine 上の各コンテンツ サービス モジュール(HTTP モジュール、WMT サーバ、FTP プロキシ プロセス、TFTP サーバなど)によって、サービスされた要求のログが記録されます。これらのログは、「トランザクション ログ」と呼ばれています。

通常トランザクション ログに記録される一般的なフィールドは、要求が行われた日付と時刻、要求された URL、キャッシュ ヒットであったかキャッシュ ミスであったか、要求のタイプ、転送されたバイト数、およびソース IP アドレスです。トランザクション ログは、通常、次のような目的で使用されます。

問題の特定と解決

負荷のモニタリング

課金請求

統計分析

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

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

トランザクション ログの生成、格納、管理において高い信頼性を確保することは、課金、コスト分析、プロビジョニングにとって非常に重要です。

Windows Media Services 9 シリーズでは、Windows Media Services Version 4.1 よりもより強固なロギング モデルが提供されています。ACNS 5.2 ソフトウェアでは、Windows Media Services 9 のログ機能のサポートが追加されました。

定義済みの形式での記録が可能です(Squid、拡張 Squid、Apache の各形式や、ユーザが指定するカスタム トランザクション ログ形式をログ追加フィールドに追加することも可能)。トランザクション ログの内容は、FTP を使用して外部サーバにエクスポートできます。また、ログ ローテーション ポリシーの設定も可能です。


) ログ形式は、一時点で 1 形式のみ有効になります。Content Engine GUI からトランザクション ロギングを有効にした場合は、Squid ログ形式が使用されます。


ACNS 5.2 ソフトウェアでは、新しいトランザクション ログ機能が追加され、他のデバイスへのリアルタイム トランザクション ログ機能が実行できるようになりました。リモート syslog サーバに対して HTTP トランザクション ログ メッセージを送信するよう、Content Engine を設定することが可能です。これによって、HTTP トランザクション認証障害のモニタリングがリアルタイムで行えるようになります。このトピックに関する詳細は、「HPPT 要求認証障害のリアルタイムでのモニタリング」を参照してください。

トランザクション ロギングは、ACNS ソフトウェアが実行されている Content Engine 上では、デフォルトで無効になっています。トランザクション ロギングを Content Engine 上で有効にするには、Content Engine GUI または CLI のいずれかを使用できます。Content Engine GUI からトランザクション ロギングを有効にした場合は、以下の出力例のように、Squid ログ形式が使用されます。

ContentEngine(config)# transaction-logs ?
archive Configure archive parameters
enable Enable transaction log feature
export Configure file export parameters
file-marker Add entries to translog indicating the file begin and end
format log file format (default squid)
log-windows-domain Log Windows domain with authenticated username if
available
sanitize Mask end user identities in log file
 

表 20-7 は、スタンドアロンContent Engine でのトランザクション ロギングのデフォルト設定のリストです。

 

表 20-7 スタンドアロンContent Engine でのトランザクション ロギングのデフォルト設定

オプション
デフォルト設定
詳細

アーカイブ

無効

「作業ログのアーカイブ」を参照してください。

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

無効

「トランザクション ロギングの有効化」を参照してください。

エクスポート時の圧縮

無効

「トランザクション ログ ファイルのエクスポート」を参照してください。

トランザクション ログのエクスポート

無効

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

ファイル マーカー

無効

ファイルの先頭と末尾を示すため、トランザクション ログ ファイルにエントリを追加する際に使用する。

サニタイズ トランザクション ロギング

無効

「トランザクション ログのサニタイジング」を参照してください。

アーカイブ間隔

毎日、1 時間ごと

「作業ログのアーカイブ」を参照してください。

最大のアーカイブ ファイル サイズ

2,000,000 KB

「作業ログのアーカイブ」を参照してください。

エクスポート間隔

毎日、1 時間ごと

「トランザクション ログ ファイルのエクスポート」を参照してください。

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

Squid ネイティブ ログ ファイル形式

「トランザクション ロギングの有効化」を参照してください。


) SmartFilter によって、許可されるトランザクションと拒否されるトランザクションの URL に関連するカテゴリを示す情報が、トランザクション ログに書き込まれます。この機能を利用する場合、SmartFilter GUI を使用して、すべての SmartFilter ロギング オプションを有効にする必要があります(SmartFilter GUI から Logging Options で All オプションを選択)。


ACNS トランザクション ログを使用する場合の詳細は、次の項を参照してください。

トランザクション ロギングの有効化

認証ユーザ名の Windows ドメインの記録

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

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

スタンドアロンContent Engine でのトランザクション ロギングのエクスポート設定の変更

スタンドアロンContent Engine でのトランザクション ログ設定の表示

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

トランザクション ロギングの有効化

ACNS 5.x ソフトウェアでは、Squid、拡張 Squid、Apache の各トランザクション ログ 形式を選択することができます。また、ユーザが指定するカスタム ログ形式をログの追加フィールドに加えることもできます( 表 20-8 を参照)。

 

表 20-8 サポートされるトランザクション ログ形式のリスト

トランザクション ログ形式のスタイル
詳細

Squid

「Squid スタイルのトランザクション ロギングの有効化」を参照してください。

拡張 Squid

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

Apache

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

カスタム

「トランザクション ロギング時のカスタム形式の有効化」を参照してください。


) ログ形式は、一時点で 1 形式のみ有効になります。Content Engine GUI からトランザクション ロギングを有効にした場合は、Squid ログ形式が使用されます。


ACNS 5.2 ソフトウェアでは、リモート syslog サーバに HTTP トランザクション ログ メッセージを送信する機能が追加されました。これによって、HTTP トランザクション認証の障害がリアルタイムでモニタリングできます。ローカル ファイル システムへの既存のトランザクション ログ記録は、変更されずに残ります。リアルタイムなトランザクション ロギングの詳細は、「HPPT 要求認証障害のリアルタイムでのモニタリング」を参照してください。

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

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

ContentEngine(config)# transaction-logs format squid
 

Squid スタイルのログ形式は、Content Engine のトランザクション ロギングのデフォルト形式です。使用される Squid ログ ファイル形式は、Squid-1.1 access.log ファイル形式を使用したネイティブ ログ ファイル形式です。

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 トランザクション ログは、キャッシュのワークロードやパフォーマンスに関する貴重な情報源です。ログ レコードは、情報にアクセスするだけではなく、システム設定エラー、および、メモリやディスク スペースのようなリソースの消費状況にもアクセスします。

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

 

表 20-9 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 スタイルのトランザクション ログをレポートに変換するツールが多数あります。このツールのリストについては、http://www.squid-cache.org/Scripts を参照してください。


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

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

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

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

拡張 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 -

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

Apache スタイル形式のトランザクション ロギングを有効にするには、 transaction-logs format apache グローバル設定コマンドを使用します。

ContentEngine(config)# transaction-logs format 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
 

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

表 20-10 に、Apache 共通ログ形式 (Common Log file Format) に関連したフィールドをリストします。

 

表 20-10 Apache 共通ログ形式に関する説明

フィールド
説明

Remotehost

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

Rfc931

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

Authuser

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

Date

要求の日付と時刻。

Request

要求の先頭行。

Status

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

Bytes

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

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

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

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

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

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

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

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

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

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

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

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

「!」の後にリストされているステータス コードのいずれかが要求の HTTP ステータス コードと一致する場合は、ダッシュ (-) がログに記録されます。

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

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

User-Agent

Referer

Host

Cookie

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

%r

%{Referer}i

%{User-Agent}i

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

次のコマンドを入力すると、広く知られている Apache 共通ログ形式を作成できます。

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 共通ログ形式のもので、前述のカスタム形式ストリングを使用して設定したものです。

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

 

表 20-11 カスタム ログ形式ストリングの値

形式トークン

%...a

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

%...A

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

%...B
%...b

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

%...c

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

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

%...f

ファイル名。

%...h

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

%...H

要求プロトコル。

%...{Foobar}i

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

%...l

リモート ログ名。Content Engine には実装されていないため、ダッシュ (-) がログに記録されます。

%...m

要求方式。

%...p

要求に対してサービスを提供するサーバの正規ポート。Content Engine には適用されないため、ダッシュ (-) がログに記録されます。

%...P

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

%...q

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

%...r

要求の先頭行。

%...s

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

%...t

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

%...{format}t

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

%...T

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

%...u

リモート ユーザ。

%...U

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

%...v
%...V

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

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

 

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

形式トークン

%a

曜日名(省略形)。

%A

曜日名(正式形)。

%b

月名(省略形)。

%B

月名(正式形)。

%c

日付と時刻。

%C

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

%d

10 進数表示の月内の日にち(01 ~ 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 週の第 1 日と指定。%V と %W も参照)。

%V

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

%w

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

%W

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

%x

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

%X

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

%y

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

%Y

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

%z

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

%Z

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

%%

リテラル % 文字。

認証ユーザ名の Windows ドメインの記録

Content Engine がNTLM 認証用に設定されており、拡張 Squid スタイル形式またはカスタム形式が使用されている場合、transaction-logs log-windows-domain グローバル設定コマンドによって、トランザクション ログのユーザ名フィールド内に、Windows のドメイン名とユーザ名が記録されます。ドメイン名が使用可能な場合、ドメイン名とユーザ名の両方が、ユーザ名フィールドに、domain\username の形式で記録されます。ユーザ名のみが使用可能な場合は、ユーザ名のみがユーザ名フィールドに記録されます。ドメイン名とユーザ名の両方が使用不可能な場合、「-」(ダッシュ)がこのフィールドに記録されます。

NTLM 認証に使用される Windows ドメイン名は、トランザクション ログのユーザ名フィールドに表示されます。%u 形式トークンが使用されているユーザ名が含まれている拡張 Squid スタイル形式またはカスタム形式のトランザクション ログでは、ユーザ名が「domain\username」の形式で表示されます(%u 形式トークンでは、曜日が 10 進数で指定されます。範囲は 1 ~ 7 で、1 は月曜日です)。

Apache スタイル形式または拡張 Squid スタイル形式のトランザクション ログで NTLM パラメータのロギングを無効にする場合は、 no transaction-logs log-windows-domain グローバル設定コマンドを使用します。

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

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

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

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

Content Engine CLI transaction-logs sanitized グローバル設定コマンドを使用します。

ContentEngine(config)# transaction-logs sanitize
 

サニタイズ機能を無効にするには、 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 サーバへのエクスポート

Content Engine GUI または CLI を使用すると、トランザクション ログを外部の FTP サーバまたはセキュア FTP (SFTP) サーバへエクスポートすることができます。

Content Engine GUI から、 Caching > Transaction Logs の順に選択します。表示された Transaction Logs ウィンドウを使用して、トランザクション ログを FTP サーバまたは SFTP サーバにエクスポートします。Transaction Logs ウィンドウの使用方法に関する詳細は、ウィンドウの HELP ボタンをクリックしてください。

Content Engine CLI を使用して、外部の FTP サーバまたはセキュア FTP (SFTP) サーバへのトランザクション ログのエクスポートを有効にする手順は、次のとおりです。


ステップ 1 transaction-logs export enable グローバル設定コマンドを使用し、外部 FTP サーバまたは SFTP サーバへのトランザクション ログのエクスポートを有効にします。

ステップ 2 transaction-logs export ftp-server コマンドを使用し、ターゲットとなる各 FTP サーバの情報を次のように指定します。

transaction-logs export ftp-server { hostname | server-ip-address } login password directory

ここで各パラメータの意味は、次のとおりです。

hostname および server-ip-address は、それぞれ、FTP サーバのホスト名と IP アドレスです。

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

login は、ターゲット FTP サーバに対するユーザのログインです。

password は、ターゲット FTP サーバに対するユーザのパスワードです。

directory は、エクスポートされるファイル(トランザクション ファイル)が書き込まれる、指定の FTP サーバ上のターゲット ディレクトリ パスです。トランザクション ログを格納する作業ディレクトリの名前を指定します。ユーザのログインには、完全修飾パスまたは相対パスを使用します。


) このコマンドの login オプションで指定するユーザは、指定されたディレクトリの書き込み許可を持っている必要があります。


この例では、2 つの FTP サーバに対してトランザクション ログをエクスポートするよう、Content Engine が設定されています。

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
 

ステップ 3 transaction-logs export sftp-server グローバル設定コマンドを使用し、トランザクション ログを外部 SFTP サーバにエクスポートします。

transaction-logs export sftp-server { hostname | server-ip-address } login password directory

ここで各パラメータの意味は、次のとおりです。

hostname および server-ip-address は、それぞれ、SFTP サーバのホスト名と IP アドレスです。

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

login は、ターゲット SFTP サーバに対するユーザのログインです(40 文字未満)。

password は、ターゲット SFTP サーバに対するユーザのパスワードです(40 文字未満)。

directory は、エクスポートされるファイル(トランザクション ファイル)が書き込まれる、指定の SFTP サーバ上のターゲット ディレクトリ パスです。トランザクション ログを格納する作業ディレクトリの名前を指定します。ユーザのログインには、完全修飾パスまたは相対パスを使用します。

ステップ 4 transaction-logs export compress グローバル設定コマンドを使用して、アーカイブされたログ ファイルを外部 FTP サーバまたは SFTP サーバにエクスポートする前に、gzip 形式に圧縮します。

圧縮されたファイル名には、.gz 拡張子が付きます。この機能を使用すると、Content Engine と FTP エクスポート サーバの両方において、使用するアーカイブ ファイル用のディスク スペースが少なくなり、エクスポート時に必要な帯域幅も少なくて済みます。


 

スタンドアロンContent Engine でのトランザクション ロギングのエクスポート設定の変更

トランザクション ロギングのエクスポート設定(「トランザクション ロギングの有効化」を参照)を行った後で、ユーザ名、パスワード、ディレクトリを変更する手順は、次のとおりです。

FTP サーバ用の現在の設定を変更する場合は、 transaction-logs export ftp-server グローバル設定コマンドを使用し、新しいパラメータを指定します。

SFTP サーバ用の現在の設定を変更する場合は、 transaction-logs export sftp-server グローバル設定コマンドを使用し、新しいパラメータを指定します。

次の例のように、新しいパラメータ(この例の mynewname mynewpass newftpdirectory のように)を使用して行全体を入力し直すことにより、ユーザ名、パスワード、またはディレクトリを変更できます。

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

現在の設定から FTP サーバを削除する場合は、 transaction-logs export ftp-server グローバル設定コマンドの no 形式を使用します。

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

現在の設定から SFTP サーバを削除する場合は、 transaction-logs export sftp-server グローバル設定コマンドの no 形式を使用します。

ContentEngine(config)# no transaction-logs export sftp-server sftphostname

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

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

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

次の例は、無効なユーザ ログイン パラメータが、 transaction-logs export ftp-server グローバル設定コマンドに含まれていた例です。 show statistics transaction-logs EXEC コマンドを使用した際に、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

作業ログのアーカイブ

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

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

/local1/logs/export/working.log

/local2/logs/export/working.log

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

/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

作業ファイルをアーカイブする場合は、 transaction-logs archive グローバル設定コマンドを使用します。

transaction-logs archive interval seconds

transaction-logs archive interval every-day { at hour:minute | every hours }

transaction-logs archive interval every-hour { at minute | every minutes }

transaction-logs archive interval every-week [ on weekdays at hour:minute ]

transaction-logs archive max-file-size filesize

コマンド パラメータについては、 表 20-13 を参照してください。

 

表 20-13 transaction-logs archive CLI コマンドのパラメータ

パラメータ
説明

archive

アーカイブ パラメータを設定します。

interval

アーカイブ ファイルが保管される頻度を決定します。

seconds

アーカイブの頻度(秒単位、120 ~ 604800)。

every-day

アーカイブの使用間隔が 1 日以内。

at

アーカイブが行われる毎日のローカル時刻を指定します。

hour:minute

アーカイブが行われるローカル時刻(時:分)。

every

間隔(時間単位)。この間隔は、午前 0 時に調整されます。

hours

毎日のファイル アーカイブの間隔(時間単位)。

1 1 時間ごと
12 12 時間ごと
2 2 時間ごと
24 24 時間ごと
3 3 時間ごと
4 4 時間ごと
6 6 時間ごと
8 8 時間ごと

every-hour

アーカイブの使用間隔が 1 時間以内。

at

アーカイブが行われる毎時の時刻。

minute

時間ごとのアーカイブを分単位で指定 (0~59)します。

every

時間ごとのアーカイブの間隔(分)。この間隔は、毎時 0 分に調整されます。

minutes

時間ごとのアーカイブの間隔(分)。

10 10 分ごと
15 15 分ごと
2 2 分ごと
20 20 分ごと
30 30 分ごと
5 5 分ごと

every-week

アーカイブの使用間隔が 1 週間に一度以上。

on

(オプション)アーカイブが行われる曜日。

weekdays

アーカイブが行われる曜日。複数の曜日を指定できます。

Fri 毎週金曜日
Mon 毎週月曜日
Sat 毎週土曜日
Sun 毎週日曜日
Thu 毎週木曜日
Tue 毎週火曜日
Wed 毎週水曜日

at

(オプション)アーカイブが行われる毎日のローカル時刻。

hour:minute

アーカイブが行われるローカル時刻(時:分)。

max-file-size

最大のアーカイブ ファイル サイズを設定します。

filesize

最大のアーカイブ ファイル サイズを KB 単位で指定(1000~2000000)します。

スタンドアロンContent Engine でトランザクション ロギングのエクスポートをディセーブルにするには

スタンドアロンContent Engine 上で、トランザクション ロギング エクスポートの設定(たとえば、FTP サーバや SFTP サーバの IP アドレスなどの設定情報)を残したままトランザクション ロギングのエクスポート機能を無効にするには、 transaction-logs export enable グローバル設定コマンドの no 形式を使用します。

ContentEngine(config)# no transaction-logs export enable

HPPT 要求認証障害のリアルタイムでのモニタリング

ACNS 5.2 ソフトウェアでは、リモート syslog サーバに HTTP トランザクション ログ メッセージを送信する機能が追加されました。これによって、HTTP 要求認証の障害がリモート syslog サーバ上でリアルタイムにモニタリングできます。このリアルタイム トランザクション ログ機能を使用すると、HTTP 要求認証エラーなどの特定のエラーについて、トランザクション ログをリアルタイムにモニタリングできます。ローカル ファイル システムへの既存のトランザクション ログ記録は、変更されずに残ります。


) Syslog は UDP であるため、リモート syslog ホストに転送されるメッセージには信頼性がありません。


リアルタイム トランザクション ロギング機能をサポートするため、次の CLI コマンドが ACNS 5.2 ソフトウェア リリースで追加されました。

[no] transaction-logs logging enable

[no] transaction-logs logging host {hostname | ipaddr} [port port-num rate-limit msgs-per-sec]

[no] transaction-logs logging facility fac-name

[no] transaction-logs logging entry-type entry-type [request-auth-failures | all]

これらの CLI コマンドを使用すると、トランザクション ログ メッセージをリアルタイムに受信するリモート syslog ホストを指定できます。トランザクション ログ プロセスがリモート syslog サーバへの送信を認められる転送率(1 秒ごとのメッセージ数)を制限するため、転送率制限オプション(rate-limit オプション)が追加されました。トランザクション ログ メッセージを 1 つのリモート syslog ホストへリアルタイムに送信するように、Content Engine を設定できます。

リアルタイム トランザクション ロギング機能のデフォルト設定は、次のとおりです。

リアルタイム トランザクション ロギング機能は無効です(no transaction-logs logging enable グローバル コマンド)。

指定されているリモート syslog サーバはありません(no transaction-logs logging host グローバル設定コマンド)。

指定されているロギング ファシリティはありません(no transaction-logs logging facility グローバル設定コマンド)。

「user」ファシリティ(ユーザ プロセス)のトランザクション ロギング モジュールと関連付けられているファシリティを使用する場合、デフォルト ファシリティは「*」です。

デフォルト エントリ タイプは、request-auth-failures です。詳細は、「リモート syslog ホストへのロギングの際のトランザクション ログ エントリ タイプの指定」を参照してください。

transaction-logs logging オプションのデフォルトは、次のとおりです。

ポート 514 が使用されます。このポートは、システム ロギング用としてよく知られているポートです。

転送率は 0 に設定されています。一定時間あたりの転送量に制限がないことを意味します。指定範囲は 1 秒につき 1 ~ 10,000 メッセージです。

リモート syslog ホストへのトランザクション ログ エントリのメッセージ形式は、トランザクション ログ ファイルと同じで、Cisco の標準 syslog ヘッダー情報の前に付加されます。

Apr 22 20:10:46 ce-host cache:%CE-TRNSLG-6-460012: <translog formatted msg>
 

ここで各パラメータの意味は、次のとおりです。

「ce-host」は、メッセージを送信する Content Engine のホスト名または IP アドレスです。

「cache」は、メッセージを送信する Content Engine のプロセスの名前です。

「%CE-TRNSLG-6-460012」は、Cisco 標準形式の syslog ヘッダーです。

<translog formatted msg> は、トランザクション ログ ファイルに表示されるトランザクション ログ メッセージです。

トランザクション ログのユーザ名とドメイン名を含める場合は、次の Content Engine CLI コマンドを使用します。

ContentEngine(config)# transaction-logs log-windows-domain
 

これによって、NTLM 認証に使用される Windows ドメイン名は、トランザクション ログのユーザ名フィールドに表示されます。%u 形式トークンが使用されているユーザ名が含まれている拡張 Squid スタイル形式またはカスタム形式のトランザクション ログでは、ユーザ名が
「domain\username」の形式で表示されます。HTTP トランザクション ログのプロキシ要求認証障害は、「401/407」エラーとレポートされ、ユーザ名が含まれます。このタイプのエラーは、HTTP 認証障害であることを示します。これらのエラーは、システムの syslog にも含められます。

リアルタイム トランザクション ロギングのためのリモート Syslog ホストの設定

リモート syslog ホストにリアルタイムでトランザクション ログ メッセージを送信するようスタンドアロンContent Engine を設定する場合は、transaction-logs logging host グローバル設定コマンドを使用します。

ACNS 5.2 ソフトウェアでは、トランザクション ロギングが設定されたリモート syslog ホストとの通信エラーをレポートするため、Content Engine のシステム syslog メッセージが追加されました。新しい syslog メッセージは、エラー メッセージの %CE-TRNSLG-6-460013 ~ %CE-TRNSLG-3-460016 の範囲にあります。最後のエラー メッセージ (%CE-TRNSLG-3-460016) は、レベル「6」(情報レベル メッセージ)ではなく、レベル「3」(エラー レベル メッセージ)であることに、注意してください。情報レベルのメッセージは、一定時間あたりの転送量の制限が原因でメッセージ転送が中断された場合に、中断されたメッセージ数とともにレポートされます。

リモート syslog ホストへのロギングの際のトランザクション ログ ファシリティの設定

リモート syslog ホストにトランザクションを記録する際には、transaction-logs logging facility グローバル設定コマンドを使用して、トランザクション ログ ファシリティを設定します。

ContentEngine(config)# transaction-logs logging facility ?
auth Authorization system
daemon System daemons
kern Kernel
local0 Local use
local1 Local use
local2 Local use
local3 Local use
local4 Local use
local5 Local use
local6 Local use
local7 Local use
mail Mail system
news USENET news
syslog Syslog itself
user User process
uucp UUCP system
 

リアルタイム トランザクション ログ エントリ用に、リモート syslog ホスト上に別のログを作成する場合は、Content Engine 上に一意のファシリティ(「local1」など)を設定します。

ContentEngine(config)# transaction-logs logging facility local1
 

リモート syslog ホスト上で、この一意のファシリティから別のファイルへメッセージが記録されるように設定します。リモート syslog ホストが UNIX サーバの場合の設定例は、次のとおりです。

1. /etc/syslog.conf ファイルを編集し、local1 の情報レベル メッセージが、local1 ファシリティに関連付けられている /var/log/translog-messages ファイルに書き込まれるよう、次の行を追加します。

local1.=info /var/log/translog-messages
 

2. 標準出力ファイル( /var/log/messages ファイル)から情報レベル メッセージが除外されるよう、/etc/syslog.conf ファイルの次の行を変更します。

*.info;mail.none;news.none;authpriv.none;cron.none;local1.none /var/log/messages
 

UNIX システムでは、/etc/syslog.conf ファイルの構文に関するヘルプが、「man syslog.conf」コマンドで表示されます。

UNIX システムでは、syslog デーモンのポートが /etc/services で定義されています。

syslog 514/udp
 

ポート 514 以外のポートが syslog ホスト上で設定されている場合は、それと同じポートを Content Engine で設定する必要があります(transaction-logs logging host {hostname | ipaddr} [port port-num] グローバル設定コマンド)。

リモート syslog ホストへのロギングの際のトランザクション ログ エントリ タイプの指定

ACNS ソフトウェア リリース 5.2 以降では、HPPT 要求認証の障害に関連したトランザクションのみを送信するように、または、すべてのトランザクションを送信するように Content Engine を設定できます。

会社や団体などは、一般的に、セキュリティの目的で、HPPT 要求認証の障害のみに注目します。会社や団体は、リアルタイムでこれらのタイプの認証障害をモニタリングすることにより、どのエンド ユーザが Content Engine を介した認証に失敗したかを特定できます。

ContentEngine(config)# transaction-logs logging entry-type ?
all Log all transaction messages to remote syslog host
request-auth-failures Log transactions CE failed to authenticate with the auth server
 

認証サーバとの通信を試みたエンド ユーザに関連する認証障害トランザクションのみが記録されることに、注意してください。認証サーバとの通信を試行しているトランザクションからの応答を待っている「pending」トランザクションは、記録されません。このアプローチによって、Content Engine での認証に失敗したユーザを特定するために必要な情報が得られ、一方で、syslog ホストに対するトラフィックは最小限に抑えられます。認証に失敗したユーザをトラッキングするためには、拡張 Squid 形式かカスタム ログ形式のいずれかでカスタム形式トークン %u を設定することにより、ユーザ名を記録するトランザクション ログ形式を設定する必要があります。トランザクション ログ形式の指定に関する詳細は、「トランザクション ロギングの有効化」を参照してください。

transaction-logs logging enable グローバル設定コマンドが指定されると、HTTP 要求認証障害のみの記録がデフォルトになります。このデフォルト設定を変更し、すべてのトランザクションを記録する場合は、Content Engine 上で transaction-log logging entry-type all グローバル設定コマンドを入力する必要があります。しかし、すべてのトランザクションを記録すると、syslog ホストが着信するトラフィックを処理できなくなった場合、UDP での処理量も急激に少なくなる可能性があります。

スタンドアロンContent Engine でのトランザクション ログ設定の表示

スタンドアロンContent Engine 上でトランザクション ロギングの現在の設定に関する情報を表示する場合は、show transaction-log EXEC コマンドまたは show transaction-logging EXEC コマンドを使用します。この 2 つの EXEC コマンドによる出力は同じです。トランザクション ログ ファイル情報は、TFTP トランザクションと ICAP トランザクションの場合だけでなく、HTTP および WMT の Microsoft Media Server (MMS) キャッシング プロキシ トランザクションの場合も表示されることに注意してください。出力例については、以下を参照してください。


) セキュリティを確保するため、show transaction-log EXEC コマンドによる出力にはパスワードは表示されません。


ContentEngine# show transaction-log
Transaction log configuration:
---------------------------------------
Logging is enabled.
End user identity is visible.
File markers are disabled.
Archive interval: every-day every 1 hour
Maximum size of archive file: 2000000 KB
Log File format is squid.
Windows domain is not logged with the authenticated username
 
Exporting files to ftp servers is disabled.
File compression is disabled.
Export interval: every-day every 1 hour
 
HTTP Caching Proxy logging to remote syslog host is disabled.
Remote syslog host is not configured.
Facility is the default "*" which is "user".
Log HTTP request authentication failures with auth server to remote syslog host.
 
HTTP Caching Proxy Transaction Log File Info
Working Log file - None existing
 
WMT MMS Caching Proxy/Server Transaction Log File Info
Working Log file - size : 584
age: 404
Archive Log file - mms_export_10.1.1.21_20040622_230415 size: 584
Archive Log file - mms_export_1.1.1.1_20040623_205825 size: 584
Translog directory doesn't exist. Maybe because /local1 has no sysfs mounted.
Translog directory doesn't exist. Maybe because /local1 has no sysfs mounted.
 
TFTP Transaction Log File Info
Working Log file - size : 88
age: 403
Archive Log file - tftp_server_10.1.1.21_20040622_230415 size: 88
Archive Log file - tftp_server_1.1.1.1_20040623_205826 size: 88
 
ICAP Transaction Log File Info
Working Log file - size : 61
age: 403
Archive Log file - icap_10.1.1.21_20040622_230415 size: 61
Archive Log file - icap_1.1.1.1_20040623_205826 size: 61

システム ロギング機能の使用

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

スタンドアロンContent Engine 上では、システム ロギングは、デフォルトでイネーブルになっています。 表 20-14 に、システム ロギングのデフォルト設定をリストします。

 

表 20-14 システム ロギングのデフォルト設定

設定
デフォルト設定

コンソール用メッセージのプライオリティ

warning

ログ ファイル用メッセージのプライオリティ

debug

ログ ファイル

/local1/var/log/syslog.txt

ログ ファイル リサイクル サイズ

0,000,000 バイト

Content Engine GUI または CLI を使用すると、スタンドアロンContent Engine が各種レベルのイベント メッセージをディスク、コンソール、またはリモート syslog ホストに送信するように設定できます。デフォルト syslog 設定の変更方法の詳細については、「スタンドアロンContent Engine でのシステム ロギングの設定」 を参照してください。

システム ロギングの現在の設定の表示

スタンドアロンContent Engine 上で現在の syslog ホスト設定を表示する場合は、 show logging EXEC コマンドを使用します。

ContentEngine# show logging
Syslog to host is enabled.
Priority for host logging to 1.2.1.1:514 is set to: warning
Syslog to console is disabled
Priority for console logging is set to: warning
Syslog to disk is enabled
Priority for disk logging is set to: notice
Filename for disk logging is set to: /local1/syslog.txt
Syslog facility is set to syslog
Syslog disk file recycle size is set to 10000000
 

スタンドアロンContent Engine でのシステム ロギングの設定

Content Engine GUI または CLI のいずれかを使用すると、スタンドアロンContent Engine 上で システム ロギングを設定できます。設定の一部として、Content Engine が各種レベルのメッセージをディスク、コンソール、または最大で 4 つまでの syslog ホストに送信するかどうかを指定します。

Content Engine GUI から、 System > Syslog の順に選択します。表示された Syslog ウィンドウを使用して、Content Engine のシステム ロギングを設定します。Syslog ウィンドウの使用方法に関する詳細は、ウィンドウの Help ボタンをクリックし、状況依存ヘルプにアクセスしてください。

Content Engine CLI から、 logging グローバル設定コマンドを使用して、該当する syslog 用のパラメータを設定します。

ContentEngine(config)# logging ?
console Log to console
disk Store log in a file
facility Facility parameter when log to host
host Log to host (maximum of 4 hosts)
 

Content Engine CLI を使用して、スタンドアロンContent Engine 上で システム ロギングを設定する方法の詳細については、次の項を参照してください。

syslog プライオリティ レベルの RealProxy エラー コードへのマッピング

syslog プライオリティ レベルの RealProxy エラー コードへのマッピング

リモート syslog ホストに対するシステム ロギングの設定

コンソールに対するシステム ロギングの設定

システム ロギングは、各種レベルのメッセージ(プライオリティ レベル)をコンソールに送信するように設定することができます。コンソールに対してシステム ロギングを設定し、コンソールに送信されるべき各種レベルのメッセージを指定する場合は、 logging console priority グローバル設定コマンドを使用します。

logging console { enable | priority loglevel }

コマンド パラメータについては、 表 20-15 を参照してください。

 

表 20-15 logging console CLI コマンドのパラメータ

パラメータ
説明

console

コンソールに対してシステム ロギングを設定。

enable

コンソールに対するシステム ロギングを有効にする。

priority

コンソールに対して送信されるメッセージのプライオリティ レベルを設定。

loglevel

次のキーワードのいずれかを使用。

alert

ただちに処置を講じることが必要とされる。プライオリティ 1。

critical

ただちに処置を講じることが必要とされる。プライオリティ 2。

debug

デバッグ メッセージ。プライオリティ 7。

emergency

システムは使用不能である。プライオリティ 0。

error

エラー状態。プライオリティ 3。

information

情報メッセージ。プライオリティ 6。

notice

正常だが重大な状態。プライオリティ 5。

warning

警告状態。プライオリティ 4。


) Content Engine からリモート ホストへの syslog メッセージは、ポート 514 ではなくポート 10000 から発信されます。


次の例では、 type-tail EXEC コマンドを使用して 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

ディスクに対するシステム ロギングの設定

システム ロギングは、各種レベルのメッセージ(プライオリティ レベル)をディスクに送信するように設定することができます。ディスクに対してシステム ロギングを設定し、ディスクに送信されるべき各種レベルのメッセージを指定する場合は、 logging disk priority グローバル設定コマンドを使用します。

logging disk { enable | filename filename | priority loglevel | recycle size }

コマンド パラメータについては、 表 20-16 を参照してください。

 

表 20-16 logging disk CLI コマンドのパラメータ

パラメータ
説明

disk

ディスク ファイルに対してシステム ロギングを設定。

enable

ディスク ファイルに対するシステム ロギングを有効にする。

filename

syslog ファイルの名前を設定する。

filename

syslog ファイルの名前を指定する。

priority

syslog ファイルに対して送信されるメッセージのプライオリティ レベルを設定。

loglevel

次のキーワードのいずれかを使用。

alert

ただちに処置を講じることが必要とされる。プライオリティ 1。

critical

ただちに処置を講じることが必要とされる。プライオリティ 2。

debug

デバッグ メッセージ。プライオリティ 7。

emergency

システムは使用不能。プライオリティ 0。

error

エラー状態。プライオリティ 3。

information

情報メッセージ。プライオリティ 6。

notice

正常だが重大な状態。プライオリティ 5。

warning

警告状態。プライオリティ 4。

recycle

ファイルがリサイクル サイズを超えた場合に、 syslog.txt (ログ ファイル)を上書きする。

size

syslog ファイルのサイズ(バイト単位、1000000 ~ 50000000)。

リモート syslog ホストに対するシステム ロギングの設定

ACNS 5.1 ソフトウェアでは、リモート syslog ホスト 1 つのみに対するロギングがサポートされており、スタンドアロンContent Engine に対するリモート syslog ホストを 1 つ設定する場合に、次の 2 つのコマンドが使用されていました。

ContentEngine(config)# logging host hostname
ContentEngine(config)# logging priority priority
 

ACNS 5.2 ソフトウェアでは、トランザクション ログ メッセージを最大で 4 つまでのリモート syslog ホストへ送信するように、Content Engine を設定できます。この変更を反映させるため、ACNS 5.1.x の logging host priority priority グローバル設定コマンド(前述)は推奨されなくなり、 logging host hostname グローバル設定コマンドが次のように拡張されました。

ContentEngine(config)# [no] logging host hostname [priority priority-code | port port |rate-limit limit]
 

ここで各パラメータの意味は、次のとおりです。

hostname は、リモート syslog ホストのホスト名か IP アドレスです。最大で 4 つまでのリモート syslog ホストを指定します。複数の syslog ホストを指定する場合は、複数のコマンドラインを使用します。つまり、1 つのコマンドにつき 1 つのホストを指定します(ACNS 5.1.x 以前のリリースでは、1 つのリモート syslog ホストにのみにメッセージを送信するよう、Content Engine を設定できました)。

priority-code は、指定されたリモート syslog ホストに送信されるメッセージの重大度です。デフォルトの priority-code は「warning」(レベル 4)です。各 syslog ホストでは、それぞれ、異なるレベルのイベント メッセージを受信できます。プライオリティ コードについては、以下を参照してください。

ContentEngine(config)# logging host 1.2.3.4 priority ?
alert (1) Immediate action needed
critical (2) Critical conditions
debug (7) Debugging messages
emergency (0) System is unusable
error (3) Error conditions
information (6) Informational messages
notice (5) Normal but significant conditions
warning (4) Warning conditions

) 複数の syslog ホストに同じ種類のメッセージを送信することも可能で、この場合、Content Engine 上に複数の syslog ホストを設定し、設定されたそれぞれの syslog ホストに同じプライオリティ コードを割り当てます(たとえば、sylog host 1、sylog host 2、syslog host 3 のそれぞれに、レベル 2 のプライオリティ コード「critical」を割り当てます)。


port は、Content Engine によってメッセージが送信されるリモート syslog ホストの宛先ポートです。デフォルトのポートは 514 です(ACNS 5.2 より前のリリースでは、デフォルト ポートは変更できませんでした。syslog メッセージは、指定された syslog ホストのポート 514 に対してのみ送信されました)。

rate-limit は、リモート syslog ホストへの送信が許可される 1 秒あたりのメッセージ数です。帯域幅や他のリソースの消費を制限するため、リモート syslog ホストへの一定時間あたりのメッセージ送信量は制限できます。この制限を超えた場合、指定されたリモート syslog ホストではメッセージが受信されません。デフォルトでは、一定時間あたりの送信量に制限はありませんので、すべての syslog メッセージが、設定されたすべての syslog ホストに対して送信されます。一定時間あたりの送信量を超えた場合、CLI EXEC shell login に対して、「message of the day」 (motd) が出力されます。

Content Engine がさまざまなレベルのイベント メッセージを最大で 4 つまでの外部 syslog ホストに送信するように設定する場合は、 logging host グローバル設定コマンドを使用します。次の例では、IP アドレスが 172.31.2.160 のリモート syslog ホストにプライオリティ コード「error」(レベル 3)のメッセージを送信するように Content Engine を設定しています。

ContentEngine(config)# logging host 172.31.2.160 priority error

syslog プライオリティ レベルの RealProxy エラー コードへのマッピング

RealProxy は、エラー メッセージを生成し、RealProxy ログ ファイルに書き込みます。これらのエラー メッセージは、ACNS ソフトウェアにより取り込まれ、システム ログ ファイルに渡されます。RealProxy エラー コードと syslog プライオリティ レベルとの対応を、 表 20-17 に示します。

 

表 20-17 RealProxy エラー レベルと Syslog プライオリティ レベルとのマッピング

RealProxy
エラー
コード
RealProxy
での状態
RealProxy での用途
syslog プライオリティ レベル

0

Panic

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

プライオリティ 0 ― LOG_EMERG
Emergency レベル。システムは使用不能。

1

Severe

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

プライオリティ 1 ― LOG_ALERT
Alert レベル。ただちに処置を講じることが必要。

2

Critical

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

プライオリティ 2 ― LOG_CRI
Critical レベル。クリティカルな状態。

3

General

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

プライオリティ 3 ― LOG_ERR
Error レベル。エラー状態。

4

Warning

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

プライオリティ 4 ― LOG_WARNING
Warning レベル。警告状態。

5

Notice

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

5 ― LOG_NOTICE
Notice レベル。正常だが重大な状態。

6

Informational

情報提供のみが目的のメッセージ。

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

7

Debug

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

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

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 メッセージの生成を有効、または無効にできます。たとえば、「スタンドアロンContent Engine でのシステム ロギングの設定」に説明されているように、Content Engine CLI の logging host hostname グローバル設定コマンドを使用すると、CW2K をリモート syslog ホストとして設定できます。

スタンドアロンContent Engine での HTTP カスタム エラー ページの作成

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

表 20-18 に、スタンドアロンContent Engine のプロキシ エラー メッセージとその用途について説明します。

 

表 20-18 スタンドアロンContent Engine での カスタム エラー ページのメッセージ

メッセージ識別子
用途

blocked-dueto-filter-error

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

cache-read-error

キャッシュ ファイル システム (cfs) の読み取りに失敗したときのエラー応答。

cache-write-error

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

client-access-denied-msg

クライアント アクセスが拒否されたときのエラー応答。

client-connection-broken-error

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

dns-not-available-error

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

expect-failed-error

HTTP 要求ヘッダーの Expect 記述子の条件が満たされていなかったときのエラー応答。

ftp-bad-login-error

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

ftp-bad-url-error

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

ftp-disabled-error

FTP が無効のときのエラー応答。

ftp-failure-error

FTP の障害時のエラー応答。

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 ファイルが使用不可のときのエラー応答。

http-blocked-port-msg

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

https-blocked-port-msg

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

icap-processing-error

ICAP 処理でエラーが発生したときのエラー応答。

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

サーバ接続が失われたときのエラー応答。

www-unauthenticated-error

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

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

Content Engine GUI から、 Caching > Customized Error Page の順に選択します。表示される Custom Error Page Configuration ウィンドウを利用します。Custom Error Page Configuration ウィンドウの使用方法に関する詳細は、ウィンドウの HELP ボタンをクリックしてください。

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

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

表 20-19 に、 http custom-error-page コマンドのパラメータについて説明します。

 

表 20-19 http custom-error-page CLI コマンドのパラメータ

パラメータ
説明

download

指定された URL から Content Engine にカスタム エラー メッセージ ファイルをコピーする。特定のメッセージ用のテキストを変更するには、このオプションを使用して変更しようとしているメッセージを指定し、さらにカスタム メッセージ ファイルに対するソースである URL を指定します。カスタム メッセージ ファイルは最大で 16 KB のサイズになることがあり、標準のメッセージ ページの代わりに指定されたメッセージで使用されます。

url

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

message

カスタム エラー メッセージのタイプ(ftp-put-error など)を指定する。カスタム エラー メッセージのリストについては、 表 20-18 を参照してください。

reset

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

message

デフォルトのページに戻すメッセージを指定する。

upload

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

ip-address

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

hostname

エラー ページのコピー先となるホスト名を指定する。ホストでは、指定されたディレクトリへのアクセスを許し、ファイルのコピーを許可しなければなりません。

dirname

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

filename

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

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

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

次のコマンドを使用すると、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
 

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

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

HTTP CLI クライアントでのトラブルシューティング

ACNS 5.2 ソフトウェアでは、HTTP CLI クライアントが追加されました。この機能を使用すると、接続をテストし、キャッシングに関する問題をデバッグできます。エンド ユーザが Content Engine CLI からデバッグを行う場合は、test-url EXEC コマンドを使用します。このコマンドを使用すると、Web サーバやプロキシ サーバを介して、URL へのアクセスや接続の可能性をテストできます。HTTP、HTTPS、FTP の各プロトコルを介した URL の機能をテストできます(以下を参照)。このコマンドでは、HTTP プロキシ サーバや FTP プロキシ サーバを介して、URL の機能がテストされます。このコマンドによる出力は、標準出力(コンソール)に表示されます。

ContentEngine# test-url ?
ftp For request over FTP
http For request over HTTP
https For request over HTTPS
 

test-url コマンドの詳細については、 表 20-20 を参照してください。

 

表 20-20 test-url CLI コマンド

Content Engine の test-url CLI コマンド
説明

test-url http test-URL

指定された URL(テスト URL)への接続性をテストする。HTTP プロキシ サーバ (Content Engine) を介して、URL への接続性(HTTP を介したコンテンツ要求)がテストされます。また、HTTP 要求認証、プロキシ認証、HTTP HEAD 要求、カスタム ヘッダーもテストされます。

ContentEngine# test-url http ?
custom-header Custom header to send to server
head-only To fetch only header information
use-http-proxy Test a url through a proxy. This option can be used only with http protocol

test-url https test-URL

指定された URL(HTTPS を介したコンテンツ要求)への接続性をテストする。HTTPS 要求認証や HTTPS HEAD 要求もテストされます。

ContentEngine# test-url https ?
WORD The test url. Format https://domain.com/path or
https://user:password@domain.com/path

test-url ftp test-URL

指定された URL(テスト URL)への接続性をテストする。FTP プロキシ サーバ (Content Engine) を介して、URL への接続性(FTP [FTP-over-HTTP] を介したコンテンツ要求)がテストされます。FTP-over-HTTP 要求に対する HTTP 認証や、プロキシ認証もテストされます。

ContentEngine# test-url ftp ?
WORD The test url. Format ftp://domain.com/path or ftp://user:password@domain.com/path
 
ContentEngine# test-url ftp use-ftp-proxy ?
use-ftp-proxy Test a url through a proxy. This option can be used only with
http protocol

test-url EXEC コマンドを使用する際には、次のいずれかの形式(以下を参照)でテスト URL (test-url protocol test-URL EXEC コマンド)を指定できます。

http://domain.com/path または http://user:password@domain.com/path

テスト URL (www.cisco.com) に対して HTTP 要求を行った場合の例は、次のとおりです。要求は正常終了しています。

ContentEngine# test-url http http://www.cisco.com
--17:34:50-- http://www.cisco.com/=> `/dev/null'
Len - 21 , Restval - 0 , contlen - 0 , Res - 134728056Resolving www.cisco.co
done.
Connecting to www.cisco.com[192.168.0.0]:80... connected.
HTTP request sent, awaiting response...
1 HTTP/1.1 200 OK
2 Date: Fri, 25 Jun 2004 17:09:06 GMT
3 Server: Apache/1.0 (Unix)
4 Content-Type: text/html
5 Set-Cookie: CP_GUTC=172.16.0.0.133781088183346835; path=/; expires=T
19-Jun-29 17:09:06 GMT; domain=.cisco.com
6 Via: 1.1 Application and Content Networking System Software 5.2.0
7 Connection: Close
(-1 to go)
[<=> ] 0 --.--K/s
en - 1185 ELen - 0 Keepalive - 0
[ <=> ] 56,249 1.38M/s
 
17:34:50 (1.38 MB/s) - `/dev/null' saved [56249]
 

ホストが見つからなかったため、テスト URL (gmail.google.com) への HTTPS 要求が失敗した場合の例は、次のとおりです。

ContentEngine# test-url https https://gmail.google.com head-only
--17:43:13-- https://gmail.google.com/=> `/dev/null'
Len - 25 , Restval - 0 , contlen - 0 , Res - 134728056Resolving gmail.google.com
...
Resolving gmail.google.com failed: Host not found.
 

FTP プロキシの IP アドレスが 172.16.0.0 の Content Engine への FTP-over-HTTP 要求が、テスト URL として使用された場合の例は、次のとおりです。

ContentEngine# test-url ftp ftp://1234567:pAB6rB7x@smartfilter.com use-ftp-proxy ?
WORD Proxy-url. Format http://proxyIp:proxyPort or
http://proxyUser:proxypasswd@proxyIp:proxyPort
ContentEngine# test-url ftp ftp://1234567:pAB6rB7x@smartfilter.com use-ftp-proxy 172.16.0.0:8080

ログ表示ツールでのトラブルシューティング

ACNS 5.2 ソフトウェアでは、less EXEC コマンドが追加されました。このコマンドを使用すると、表示される ACNS ソフトウェア ログのファイル名を指定できます。

ContentEngine# less ?
WORD file name

Telnet クライアントでのトラブルシューティング

ACNS 5.2 ソフトウェアでは、Telnet CLI クライアントが追加されました。この Telnet クライアントを使用すると、宛先ポートを指定できます。Content Engine CLI から Web サイトに対して telnet を実行することよって、Web サイトをテストできます。この機能をサポートするため、telnet EXEC コマンドが追加されました。

ContentEngine# telnet ?
Hostname or A.B.C.D Remote host or IP address

Ping のトラブルシューティング

基本的なネットワークの接続性を診断するため、ネットワーク上にエコー パケットを送信する場合は、ping EXEC コマンドを使用します。

ping { hostname | ip-address } | PING options

ACNS 5.2 ソフトウェアでは、すべての標準 ping オプションをコマンド引数としてサポートするため、ping EXEC コマンドの機能が拡張されました(標準 ping オプションの詳細は、Linux の man ページを参照してください)。

ContentEngine# ping ?
LINE Destination Host or IP Address (or PING options)
 

hostname 引数とともに ping EXEC コマンドを使用する場合は、Content Engine 上で DNS の機能を設定しておくようにしてください。応答がないホストに対してタイムアウトを強制実行する場合や、ループの繰り返しを排除する場合は、 Ctrl-C キーを押します。

Content Engine CLI から IP アドレス 172.19.131.189 のホストに対して ping する場合の例は、次のとおりです。

ContentEngine# ping 172.19.131.189
PING 172.19.131.189 (172.19.131.189) from 10.1.1.21 : 56(84) bytes of
data.
64 bytes from 172.19.131.189: icmp_seq=0 ttl=249 time=613 usec
64 bytes from 172.19.131.189: icmp_seq=1 ttl=249 time=485 usec
64 bytes from 172.19.131.189: icmp_seq=2 ttl=249 time=494 usec
64 bytes from 172.19.131.189: icmp_seq=3 ttl=249 time=510 usec
64 bytes from 172.19.131.189: icmp_seq=4 ttl=249 time=493 usec
 
--- 172.19.131.189 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/mdev = 0.485/0.519/0.613/0.047 ms
 

ACNS 5.2 ソフトウェアでは、すべての標準 ping オプションをサポートするため、ping コマンドの機能が拡張されました(標準 ping オプションの詳細は、Linux の man ページを参照してください)。

ContentEngine# ping ?
LINE Destination Host or IP Address (or PING options)

traceroute を使用したトラブルシューティング

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

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