ローカル管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.3
スタンドアロン Content Engine の モニタリングとトランザクション
スタンドアロン Content Engine のモニタリングとトランザクション
発行日;2012/02/03 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 10MB) | フィードバック

目次

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

スタンドアロン 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 のモニタリング

アラームの重大度(Severity)レベル

過負荷アラーム

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

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

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

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

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

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

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

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

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

SMART によるディスクの状態のプロアクティブなモニタリング

スタンドアロン Content Engine によるシステム ロギング

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

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

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

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

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

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

CiscoWorks2000 の使用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作業ログのアーカイブ

スタンドアロン Content Engine でのトランザクション ロギングのエクスポートの無効化

HTTP 要求の認証失敗のリアルタイム モニタリング

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

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

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

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

特定 URL のパフォーマンスのモニタリング

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

この章では、ローカル側で管理配置されるスタンドアロン Content Engine をモニタリングする方法について説明します。この章の構成は、次のとおりです。

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

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

「スタンドアロン Content Engine によるシステム ロギング」

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

「特定 URL のパフォーマンスのモニタリング」


) ACNS 5.3.1 ソフトウェア リリースでは、Secure FTP(SFTP)を使用して Content Engine に接続し、ログ ファイルを安全に取得する機能が追加されました。

この章に記述されている CLI コマンドの構文と使用方法については、『Cisco ACNS Software Command Reference, Release 5.3 』を参照してください。Content Router、Content Distribution Manager、または、Content Distribution Manager に登録されている Content Engine(Content Distribution Manager に登録されていない Content Engine の場合とは異なる)のモニタリングについては、『中央管理配置に関する Cisco ACNS ソフトウェア コンフィギュレーション ガイド Release 5.3』を参照してください。


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

Content Engine のパフォーマンスを測定することで、設定調整および Content Engine の追加導入が必要となる兆候を見つけ出すには、Content Engine をモニタリングすることが重要です。ここでは、Simple Network Management Protocol(SNMP;簡易ネットワーク管理プロトコル)と ACNS ソフトウェア アラームを使用してスタンドアロン Content Engine をモニタリングする方法を説明します。ACNS 5.2.1 ソフトウェア以降が実行されているスタンドアロン 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 のモニタリング

Simple Network Management Protocol(SNMP)は、相互運用可能な標準ベースのプロトコルで、外部から SNMP エージェントによる Content Engine をモニタリングできます。

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

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

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

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

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 管理ステーションに送信します。

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

図21-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 つがあります。

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

 

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

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

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


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

ACNS 5.3.1 ソフトウェア リリースでは、CISCO-CONTENT-ENGINE-MIB の機能が変更され、Windows Media 9 クライアントおよびサーバ(つまり Windows Media 9 Player および Windows Media 9 サーバ)用の WMT RTSP ストリーミングがサポートされるようになりました。

ACNS 5.2.1 ソフトウェア以降では、SNMP と Node Health Manager の間の整合性を保つため、CISCO-CONTENT-ENGINE-MIB に 6 つの汎用アラーム トラップが備わっています。6 つの汎用アラーム トラップのリストについては、表21-5を参照してください。


ACNS 5.1.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 ]}]]

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

 

表21-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

エンジン アイデンティティ オクテット ストリング。

次の例では、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 name グローバル設定コマンドを使用して、セキュリティ モデル グループ(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 Content Engine 上ですべての SNMP トラップを有効にします。

ContentEngine(config)# snmp-server enable traps
 

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

ステップ 3 Content Engine からの SNMP トラップをどのホストが受信するかを指定します。

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

ContentEngine(config)# snmp-server host 172.31.2.160 public

) SNMP トラップを送信するには、少なくとも 1 つの SNMP トラップ ホストを設定する必要があります。ACNS 5.1 ソフトウェア以前では、設定できる SNMP ホストは最大で 4 つまでです。ACNS 5.2.1 ソフトウェア以降では、Content Engine 上に最大で 8 つまでの SNMP ホストを設定できます。


ステップ 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 に対するビュー ベースのアクセス制御が行われますが、バージョン相互間の下位互換性も引き続き確保されます。

ASNS 5.1 ソフトウェア リリースより前の ACNS 5.x ソフトウェアでは、 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 は、「SNMP によるスタンドアロン Content Engine のモニタリング」に説明されているとおり、引き続きこのモニタリング方式を使用しています。

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

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

Node Health Manager(過負荷状況と Node Manager の動作状況をアラームします)

Node Manager for service failures(モニタリングされているアプリケーションの動作状況)

System Monitor (sysmon) for disk failures

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


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


ACNS 5.2.1 ソフトウェアでは、ACNS ソフトウェア アラーム(問題の原因)の発信元を系統立てて識別できるようにするため、複数の CLI コマンドが追加されました( 表21-3 を参照)。CLI コマンドを使用すると、数多くの ACNS ソフトウェア ログを検索することなく、問題の発信元を特定できます。

 

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

CLI コマンド
説明
詳細

show alarm

Content Engine 上で現在通知されているすべての ACNS ソフトウェア アラーム(Critical、Major、Minor の各アラーム)のリストを表示する。

「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 コマンドのリストについては、表21-3 を参照してください。


アラームの重大度(Severity)レベル

ACNS ソフトウェア アラームには、3 つのレベルがあります( 表21-4 を参照)。

 

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

アラーム レベル
説明

Critical

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

Major

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

Minor

サービスに影響を及ぼさないと考えられる状況(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.1 ソフトウェア以降では、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 により sevicedied アラームが生成され、その状況がレポートされます。次に、サービスが再起動されます。サービスの実行が短時間(通常は 10 秒間)確認された場合、「sevicedied」アラームは解除されます。

再起動後にもアプリケーションが動作しない場合は、sevicedied アラームが継続して通知され、Node Manager によってサービスの再起動が試行されます。再起動は、通常、Node Manager によって最大 10 回まで行われます。その後、Node Manager により、そのサービスについて svcdisabled アラームが通知され、「sevicedied」アラームが解除されて、サービス再起動の試行を停止します。

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

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

Content Engine が、特定のアラーム状況に対して SNMP トラップを生成するように設定することができます。下記に基づいて、スタンドアロン Content Engine 上での、SNMP アラーム トラップの生成を設定できます。

アラームの重大度(Critical、Major、Minor)

アクション(アラーム通知時または解除時)

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

 

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

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

cceAlarmCriticalRaised

Critical

通知

snmp-server enable traps alarm raise-critical

cceAlarmCriticalCleared

Critical

解除

snmp-server enable traps alarm clear-critical

cceAlarmMajorRaised

Major

通知

snmp-server enable traps alarm raise-major

cceAlarmMajorCleared

Major

解除

snmp-server enable traps alarm clear-major

cceAlarmMinorRaised

Major

通知

snmp-server enable traps alarm raise-minor

cceAlarmMinorCleared

Major

解除

snmp-server enable traps alarm clear-minor


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


この 6 つの汎用アラーム トラップにより、SNMP と Node Health Manager の間の整合性が保持されます。6 つの汎用アラーム トラップは、Content Engine CLI を使用して有効や無効にできます。ACNS 5.2.1 ソフトウェア以降では、 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 上で現在通知されているすべてのCritical、Major、Minor の各アラームに関する情報を表示する場合は、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 コマンドを使用します。


) アラームのさまざまな重大度(Critical、Major、Minor)に関する詳細は、表21-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:04.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 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 が適切に動作するためには、次のようなクリティカル ディスク ドライブが必要です。

「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 システム自体が動作を一時的に中断または停止する可能性があります。したがって、Content Engine 上のクリティカル ディスク ドライブをモニタリングし、ディスク ドライブ エラーが通知されるようにすることが重要です。

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

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

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

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

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

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

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


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


ACNS 5.2.1 ソフトウェア リリースでは、SCSI ドライブの不良(しかし使用されていない)セクタの再配置がサポートされるようになりました。ACNS 5.3.1 ソフトウェア リリースでは、この機能が IDE およびシリアル ATA ドライブにまで拡張されました。このトピックに関する詳細は、『Cisco ACNS Software Update and Maintenance Guide, Release 5.x.』を参照してください。

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

ACNS 5.2.1 ソフトウェア以降では、ディスク エラー処理しきい値を設定できます。このしきい値によって、ディスク ドライブが不良とマークされるまでに検出されるディスク エラーの数を指定できます。デフォルトでは、このしきい値は 10 に設定されています。

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

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

ContentEngine(config)# disk error-handling threshold 5
 

bad ディスク ドライブがクリティカル ディスク ドライブの場合で、自動リロード機能( disk error-handling reload コマンド)が有効になっている場合、ACNS ソフトウェアによってディスク ドライブが不良とマークされ、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 }]

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

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


ステップ 1 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 disk03 は、Content Engine のブート後にマークされたため、「*」がマークされていることを確認します。

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)
......
 

disk03 は「Normal」(現在使用中)と表示されていることに注意してください。

ステップ 3 reload EXEC コマンドを入力して、Content Engine をリロードします。次のプロンプトが表示されたら、 Enter キーを押して、リロードを実行します。

Content Engine# reload
Proceed with reload?[confirm]
......
 
Content Engine がリロードされた後、disk03 は不良ディスクとしてマークされています。このディスク ドライブは使用されません。
 

ステップ 4 disk03 が not used とマークされていることを確認します。

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

disk03 は、ContentEngine のリブート後に bad であると検出されたため、「Not used (*)」と表示されています。

ステップ 5 disk03 のマークを手作業で bad から good に変更します。

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

ステップ 6 disk03 が Not used とマークされていることを確認します。

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


 

SMART によるディスクの状態のプロアクティブなモニタリング

ACNS 5.3.1 ソフトウェア リリースでは、Self Monitoring、Analysis、および Reporting Technology、つまり SMART により、ディスクの状態をプロアクティブにモニタリングする機能が追加されました。SMART は、ハード ドライブ診断情報と近い将来発生するディスク障害についての情報を提供します。

SMART は多くのディスク ベンダーによってサポートされており、ディスク状態の識別に使用される標準的な方式です。SMART には、近い将来発生するディスク障害を示す可能性のある動作や環境の状態に関する情報を ACNS ソフトウェアに提供する、読み取り専用の属性(時間ごとの仕事率や、ロードとアンロードの回数など)があります。

SMART のサポートは、ベンダーによって異なります。各ディスク ベンダーがサポートする SMART の属性セットは異なります。次の出力例では、 show disk SMART-info EXEC コマンドを 2 つの異なる Content Engine(Content Engine A と Content Engine B)に入力しています。これらの 2 つの Content Engine には、それぞれ異なるベンダーが製造したハード ディスクが備えられています。

ContentEngineA# show disks SMART-info
=== disk00 ===
Device: IBM IC35L036UCD210-0 Version: S5BS
Serial number: 22222222
Device type: disk
Transport protocol: Fibre channel (FCP-2)
Local Time is: Sun Jan 2 03:14:16 2005 Etc
Device supports SMART and is Enabled
Temperature Warning Disabled or Not Supported
SMART Health Status: OK
 
=== disk01 ===
disk01: Not present
 
ContentEngineB# show disk SMART-info
Disk 01:
========
Device Model: HITACHI_DK23BA-20
Serial Number: 111111
Firmware Version: 00E0A0D2
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
SMART overall-health self-assessment test result: PASSED
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000d 100 083 050 Pre-fail - 677
3 Spin_Up_Time 0x0007 100 100 050 Pre-fail - 0
4 Start_Stop_Count 0x0032 100 100 050 Old_age - 249
5 Reallocated_Sector_Ct 0x0033 099 099 010 Pre-fail - 30
<cr>
 

さらに詳細な情報を表示するには、 show disk SMART-info details EXEC コマンドを入力します。 show disk SMART-info コマンドおよび show disk SMART-info details コマンドの出力は、ディスク ベンダーとドライブ技術の種類(IDE、SCSI、および シリアル ATA ディスク ドライブ)によって異なります。

SMART 属性はベンダーによって異なりますが、属性の多くには共通の解釈方法があります。各 SMART 属性には、正規化された現在の値としきい値があります。現在の値がしきい値を超えると、そのディスクは障害があると見なされます。ACNS ソフトウェアは、SMART 属性を監視し、syslog メッセージ、SNMP トラップ、およびアラームにより、近い将来に発生する障害を報告します。

ACNS 5.3.1 ソフトウェア以降では、 show tech-support EXEC コマンドからの出力に SMART 情報も含まれるようになりました。

スタンドアロン Content Engine によるシステム ロギング

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

スタンドアロン Content Engine 上では、システム ロギングは、デフォルトで有効になっています。 表21-6 に、システム ロギングのデフォルト設定をリストします。

 

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

設定
デフォルト設定

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

warning

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

debug

ログ ファイル

/local1/var/log/syslog.txt

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

0,000,000 バイト

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

ACNS 5.3.1 ソフトウェア リリースでは、プロキシ モードのネイティブ FTP サポートが追加されました。プロキシ モードのネイティブ FTP サポートに関する syslog メッセージが、ACNS 5.3.1 ソフトウェア リリースで追加されました。プロキシ モードのネイティブ FTP サポートに関する sysylog の例を次に示します。

CE-FTP_PROXY-3-252009: Failed to configure FTP Proxy-mode listener on port
'[port]'.
 
Explanation: Could not start proxy-mode listener for FTP control
connection for the specified port. The port is temporarily
in an un-bindable state, or is in use by some other
application.
 
Action: Check whether the port has been configured for use by a
different application. If not, retry the ftp-native
incoming proxy command after 2 minutes. If this error
repeats frequently, contact Cisco TAC.
 

ACNS 5.1.x ソフトウェア以前では、不良セクタにアクセスするたびに、ディスク障害 syslog メッセージが生成されます。ACNS 5.2.1 ソフトウェア リリースでは、IDE 上の単一の不良セクタに対する複数の syslog メッセージをフィルタリングする機能が追加されました。ACNS 5.3.1 ソフトウェア リリースでは、SCSI ディスク および SATA ディスク上の単一の不良セクタに対する複数の syslog メッセージをフィルタリングする機能が追加されました。

ACNS 5.3.1 ソフトウェア以降では、 show disk failed-sectors EXEC コマンドを入力すると、Content Engine ディスク上の不良セクタをリストできます。

ContentEngine# show disk failed-sectors
List of failed sectors on disk00
--------------------------------
89923
9232112
List of failed sectors on disk01
--------------------------------
<None>

特定のディスク ドライブの不良セクタのみをリストするには、 show disk failed-sectors コマンドの入力時にディスク名を指定します。次の例は、disk01 の不良セクタをリストする方法を示しています。

ContentEngine# show disk failed-sectors disk01
 

ディスク障害がある場合は、ACNS 5.3.1 ソフトウェア以降を実行している Content Engine にログインする際に、障害を通知するメッセージが出力されます。

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

スタンドアロン Content Engines 上で現在の 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 ホストに対するシステム ロギングの設定」

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

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

logging console { enable | priority loglevel }

表21-7 では、これらのコマンド パラメータを示しています。

 

表21-7 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 }

表21-8 では、これらのコマンド パラメータを示しています。

 

表21-8 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.1 ソフトウェア以降では、トランザクション ログ メッセージを最大で 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.1 ソフトウェア以前では、デフォルト ポートは変更できませんでした。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 プライオリティ レベルとの対応を、 表21-9 に示します。

 

表21-9 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 レベル。デバッグ メッセージ。

CiscoWorks2000 の使用

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

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

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

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

CiscoWorks2000 アベイラビリティ モジュールでは、Content Engine をトラッキングできます。

Content Engine CLI か GUI のいずれかを使用して、CiscoWorks2000 に準拠した形式での syslog メッセージの生成を有効、または無効にできます。たとえば、「スタンドアロン Content Engine でのシステム ロギングの設定」に説明されているように、Content Engine CLI の logging host hostname グローバル設定コマンドを使用すると、CiscoWorks2000 をリモート syslog ホストとして設定できます。

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

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

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

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

問題の特定と解決

負荷のモニタリング

課金請求

統計分析

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

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

ACNS 5.2.1 ソフトウェア以降では、Windows Media Services 9 ロギングがサポートされています。Windows Media Services 9 Series では、Windows Media Services Version 4.1 よりもより強固なロギング モデルが提供されています。

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


) ACNS 5.3.1 ソフトウェア以降では、SFTP を使用して、トランザクション ログの内容を外部サーバにエクスポートできます。


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

HTTP 要求

HTTPS 要求

FTP 要求

WMT 要求

RTSP ストリーミング要求

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
monitor Display http monitor 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
 

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

 

表21-10 show protocol-name statistics EXEC コマンド

コマンド
説明

show statistics https [ error | requests ]

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

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

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

show statistics ftp-over-http

Content Engine の FTP 統計情報を表示する。FTP-over-HTTP 要求の統計情報が含まれます。

show statistics ftp-native

Content Engine の FTP ネイティブの統計情報を表示する。FTP ネイティブ要求についての統計情報(たとえば GET 要求に対する FTP ネイティブ エラー)が含まれます。

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 要求の統計情報を表示する。


) ACNS 5.3.1 ソフトウェアでは、show statistics ftp EXEC コマンドが show statistics ftp-over-http および show statistics ftp-native EXEC コマンドに変わりました。ACNS 5.3.1 ソフトウェアでは、clear statistics ftp EXEC コマンドが clear statistics ftp-over-http および clear statistics ftp-native EXEC コマンドに変更されました。


次の例では、特定の監視対象 URL(たとえば http://www.abccorp.com)の HTTP モニタリング統計情報を表示する方法を示しています。

ContentEngine# show statistics http monitor
HTTP Monitor URL statistics
---------------------------
 
Monitor URL = http://www.abccorp.com
Total requests = 2547
Failed requests = 3
Requests above acceptable delay = 1
Minimum response time = 0.072 seconds
Maximum response time = 120.281 seconds
 

次の例では、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
 

次の例では、正常終了または異常終了した発信プロキシ要求のモニタリング統計情報を表示する方法を示しています。

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

次の例では、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 が、HTTP 要求に対してオリジン Web サーバからコンテンツを取ってくるかわりに、ローカル 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 %
 

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

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

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

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

問題の特定と解決

負荷のモニタリング

課金請求

統計分析

セキュリティ上の問題

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

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

Content Engines 上の translog モジュールは、トランザクション ロギングを処理し、次の 4 つの主要ロギング形式をサポートしています。

Apache Common Log Format(CLF; 共通ログ形式)

Squid

拡張 Squid

World Wide Web Consortium(W3C)運営グループによって定義されたカスタマイズ可能なログ形式

Apache CLF および Squid 形式は、それらを派生したオリジナル アプリケーションに対応する固定形式です。Content Engines は、W3C のカスタマイズ可能なログ形式で定義されている形式( 表21-12 を参照)の大部分をサポートしています。

Windows Media Services 9 Series では、Windows Media Services Version 4.1 よりもより強固なロギング モデルが提供されています。ACNS 5.2.1 ソフトウェア以降では、Windows Media Services 9 ロギングがサポートされています。

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


) ログ形式のタイプは、一時点で 1 形式のみアクティブにできます。Content Engine GUI からトランザクション ロギングを動作可能にした場合は、Squid ログ形式が使用されます。


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

トランザクション ロギングは、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
 

表21-11 では、スタンドアロン Content Engine でのトランザクション ロギングのデフォルト設定を示しています。

 

表21-11 スタンドアロン 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 の各トランザクション ログ 形式を選択することができます。また、ユーザが指定するカスタム ログ形式をログの追加フィールドに加えることもできます( 表21-12 を参照)。

 

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

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

Squid

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

拡張 Squid

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

Apache

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

カスタム

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


) 一度にアクティブにできるログ形式のタイプは、1 形式のみです。Content Engine GUI からトランザクション ロギングを有効にした場合は、Squid ログ形式が使用されます。


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

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

Squid スタイル形式のトランザクション ロギングを有効にするには、 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 トランザクション ログは、キャッシュのワークロードやパフォーマンスに関する貴重な情報源です。

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

 

表21-13 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 応答ヘッダーに表示されるオブジェクトの MIME タイプ。ACNS 5.x ソフトウェアでは、このフィールドには常に「-」(ダッシュ)が入っています。


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


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

拡張 Squid スタイル形式のトランザクション ロギングを有効にするには、 transaction-logs format extended-squid グローバル設定コマンドを使用します。拡張 Squid 形式では、Squid スタイルの形式でロギングされるフィールドの他に、ログ ファイル内の各レコードに関連したユーザ名がロギングされ、課金請求に使用されます。この形式では、Squid 形式に関連した Rfc931 フィールド( 表21-13 )が、許可ユーザのログ記録に使用されます。ユーザ情報が入手できない場合、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 グローバル設定コマンドを使用します。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;共通ログ形式)です。この形式は、多くの業界標準のログ ツールとの互換性があります。詳細については、 http://www.w3.org/Daemon/User/Config/Logging.html の、W3C Common Log File Format Web サイトを参照してください。

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

 

表21-14 Apache 共通ログ形式に関する説明

フィールド
説明

Remotehost

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

Rfc931

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

Authuser

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

Date

要求の日付と時刻。

Request

要求の先頭行。

Status

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

Bytes

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

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

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

ContentEngine(config)# transaction-logs format custom log-format-string
 

log-format-string は、カスタム形式を指定するトークンの引用符付きストリングです。このログ形式ストリングには、 表21-15 にリストされたトークンを含むことができ、Apache ログ形式ストリングに似ています。

ログ形式ストリングは、これらのリテラル文字を含むことが可能で、ログ ファイルにコピーされるときに使用されます。

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

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

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


) ACNS 5.3.1 ソフトウェア以降では、無効なカスタム ログ形式ストリングは設定できません。ただし、リリース 5.3 より前の ACNS ソフトウェアでは、無効なカスタム ログ形式文字列を設定できます。したがって、Content Engine を ACNS 5.2 ソフトウェアから ACNS 5.3 ソフトウェアにアップグレードすると、既に設定してある無効なカスタム ログ形式はすべて削除されます。


次の例は、よく知られている Apache Common Log ファイル形式を生成するカスタム ログ形式を指定する方法を示しています。

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

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

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

User-Agent

Referer

Host

Cookie

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

%r

%{Referer}i

%{User-Agent}i

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

表21-15 に、ログ形式ストリングで使用が許されている形式のトークンを示します。 表21-15 に示されている形式トークンの「...」部分は、オプションの条件を表しています。format tokens のこの部分は、%a のようにブランクにしておくことも可能です。オプションの条件が format tokens に指定されていて、その条件が合致している場合は、 表21-15 の値欄に示されいる内容が transaction log output.に含められます。オプションの条件が形式トークンで指定されていて、条件が合致しない場合は、結果のトランザクション ログ出力は、ダッシュ(-)で埋められます。条件の形式は、HTTP ステータス コードをリストにしたもので、感嘆符(!)が行頭に付く場合と付かない場合があります。

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

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

たとえば、「%400,501{User-Agent}i」を指定すると、エラー 400 および 501(Bad Request, Not Implemented)のみの、User-Agent ヘッダー値をロギングします。「%!200,304,302{Referer}i」 を指定すると、ノーマル ステータスを戻してこないすべての要求の Referer ヘッダー値をロギングします。

 

表21-15 カスタム ログ形式ストリングの値

形式トークン

%...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

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

%...T

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

%...u

リモート ユーザ。

%...U

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

%...v
%...V

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

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

 

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

形式トークン

%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 進数表示の時間(範囲:00 ~ 23)。

%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

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

%%

リテラル % 文字。

W3C のカスタマイズ可能なログ形式は、HTTP Web サーバ パースペクティブから定義され、固定 Squid 形式で提供されるような Web キャッシュ固有のカスタム オプションを提供しない点で、制限されています。したがって、ACNS 5.3.1 ソフトウェアでは、W3C のカスタマイズ可能なログ形式を拡張する形式トークンが追加され、Cisco や Squid のようなカスタマイズされたロギング フィールドがサポートされます。これらの新しい形式トークンにより、W3C のカスタマイズ可能なトークン セット内から Squid のようなロギング形式がサポートされます。

ACNS 5.3.1 ソフトウェア リリースでは、次のトランザクション ロギング サポートが追加されました。

W3C 形式でサポートされなかった拡張 Squid-equivalent トークンのサポート。

設定された HTTP 発信プロキシ(「http 発信プロキシ」)を Squid-style 「DEFAULT_PARENT」階層イベントとして扱う、追加の階層トークンのサポート。

ACNS 5.3.1 ソフトウェア リリースでは、W3C Customizable Logging Format が拡張され、次の特別な

%...{<translog-token>}C

トークン シーケンスがサポートされるようになりました。

「...」フィールドはオプションです。このオプションを指定すると、一連の条件付き HTTP 応答コードを、カンマで区切ることができます。「C」は大文字で、カスタマイズ可能な拡張動作トークン セットを定義します。この拡張セットのトークンは、<translog-token> ディレクティブで定義されます。これは 2 文字のトークン ディレクティブです。

表21-17 では、拡張 Squid 形式の、既存および新規の <translog-token> ディレクティブをリストしています。拡張 Squid 形式は、W3C 定義ではすぐにはサポートされませんが、ACNS 5.3.1 ソフトウェア以降でサポートされています。

 

表21-17 translog トークン ディレクティブ

形式トークン

%...{es}C

新時代(1970 年 1 月 1 日)以降経過した秒数で表された、現在の時刻。

%...{em}C

新時代(1970 年 1 月 1 日)以降経過したミリ秒の数値。1970).

%...{te}C

要求が完了するまでに経過したミリ秒の数値。

%...{rd}C

Squid のようなキャッシュ状況のコード ストリング(たとえば TCP_HIT and TCP_CLIENT_REFRESH_MISS)。

%..{cs}C

クライアントに送信されたバイト数(プロトコルヘッダーを含む)。

%...{rh}C

Content Engine に適用する、厳密な Squid スタイルの階層。

%...{rH}C

拡張 Squid スタイルの階層。発信プロキシが明示的に定義され、要求を満たすために使用されて、「DIRECT/ origin_server_ip_address 」ではなく「DEFAULT_PARENT/ proxy_ip_addess 」が記録された場合を除き、「%...{rh}C」と同じです。

%...{rt}C

応答内のオブジェクトのMIME タイプで、左記のように定義されるプロトコル ヘッダーによって指定。ACNS 5.x ソフトウェアでは、このフィールドには常に「-」(ダッシュ)が入っています。

%...{ru}C

要求されている URL で、追加の照会ストリングを含む。

%...{as}C

アプリケーション固有の情報。アプリケーションを処理する要求が、この文字列を記録する可能性があります。これは、Squid 形式の仕様の一部としてサポートされます。たとえば、SmartFilter URL フィルタリングは、このトークン シーケンスが使用される情報を記録します。

表21-17 にリストされているトークンに加え、複数の %...{xx}C スタイル トークンを単一のトークン シーケンスに圧縮して、%...{xx}C スタイル内に組み込むことができます。複数のスタイル トークンを単一の組み込みトークン シーケンスに圧縮するには、中カッコ {} 内に複数のトークンを指定し、各トークンにプレフィックスとして「%」記号を付ける必要があります。次に例を示します。

%{rh}C %{rt}C %{as}C

これを、圧縮した組み込みトークン形式で、次のように記述しなおすことができます。

%{%rh %rt %as}C

コマンド行構文は、次のように記述された単一のトークンを認識します。

%{%rh}C

および

%{rh}C

は同義です。

出力ファイルでは、組み込みトークン シーケンスの一部ではない文字(たとえばスペース)が、逐語的に繰り返されます。

次の例は、W3C のカスタマイズ可能なログ形式の指定内に定義された拡張 Squid です。

%{es}C.%{em}C %{te}C %a %{rd}C/%s %{cs}C %m %{ru}C %u %{rh}C %{rt}C %{as}C

次の例は、拡張 Squid に類似した形式で、Squid の seconds-since-epoch タイムスタンプ形式の代わりにユーザが読み取り可能なタイムスタンプが使用されることと、設定された発信プロキシ(「%...{rH}C」によって指定)が記録されることを指定しています。

[%{%d/%b/%Y:%H:%M:%S %z}t] %{te}C %a %{rd}C/%s %{cs}C %m %{ru}C %u %{rH}C %{rt}C %{as}C

不明またはサポートされていない translog トークンは、ログ ファイルに記録されません。トークンの指定シーケンス外の文字はすべて、ログ ファイルに逐語的に繰り返されます。

認証ユーザ名の 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 形式を使用します。 transaction-logs sanitize コマンドは、CLI で設定された、つまり transaction-logs format custom string グローバル設定コマンドで設定された、カスタム ログ形式ストリングに関連するクライアント IP(%a)値には影響しません。このグローバル設定コマンドの string は、カスタム ログ形式を含む引用符付きログ形式ストリングです。カスタム ログ形式のクライアント IP のユーザ ID を隠すには、カスタム ログ形式ストリングに 0.0.0.0 をハード コーディングするか、クライアント IP を表す %a トークンを形式ストリングから除きます。

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

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

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

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

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 サーバまたは SFTP サーバへエクスポートすることができます。

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

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


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

ステップ 2 各ターゲット FTP サーバに、次の情報を指定します。

ContentEngine(config)# 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 Export transaction logs to an external SFTP server.

ContentEngine(config)# 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 アーカイブしたログ ファイルを外部の FTP または SFTP サーバにエクスポートする前に、gzip 形式に圧縮します。

ContentEngine(config)# transaction-logs export compress
 

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


 

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

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

transaction-logs export ftp-server グローバル設定コマンドを使用して、FTP サーバの現行の設定を変更します。

transaction-logs exportsftp-server グローバル設定コマンドを使用して、SFTP サーバの現行の設定を変更します。

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

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

現行の設定から FTP サーバを削除するには、次のように指定します。

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

現行の設定から SFTP サーバを削除するには、次のように指定します。

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

表21-18 では、これらのコマンド パラメータを示しています。

 

表21-18 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

HTTP 要求の認証失敗のリアルタイム モニタリング

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


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


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

[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 が使用されます。このポートは、システム ロギング用としてよく知られているポートです。

rate-limit は 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.1 ソフトウェア以降では、トランザクションをロギングするように設定されているリモート syslog ホストとの通信エラーをレポートするために、Content Engine のシステム syslog メッセージがサポートされています。%CE-TRNSLG-6-460013 から %CE-TRNSLG-3-460016 までの範囲の syslog メッセージは、エラー メッセージです。最後のメッセージ(%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.1 ソフトウェア以降では、HTTP 要求認証の失敗に関連したトランザクションのみを送信するように、または、すべてのトランザクションを送信するように Content Engine を設定できます。

会社や団体などは、一般的に、セキュリティの目的で、HTTP 要求認証の失敗のみに注目します。会社や団体は、リアルタイムでこれらのタイプの認証失敗をモニタリングすることにより、どのエンド ユーザが 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

特定 URL のパフォーマンスのモニタリング

ACNS 5.2.3 ソフトウェア以降では、特定の URL のパフォーマンスをモニタするよう Content Engine を設定する機能が追加されています。Content Engine は、モニタ対象の各 URL について、さまざまな応答特性の統計情報を管理します(新しい show statistics http monitor コマンドを使用すると、これらの統計情報を表示できます。使用方法は後の項を参照)。

http monitor url url グローバル設定コマンドを使用すると、Content Engine でモニタする URL を最大 10 まで指定できます。

ContentEngine(config)# http monitor url ?
WORD URL for monitoring
 

http monitor url url コマンドには、 acceptable-delay および interval の 2 つのコマンド オプションがあります。次の出力例では、 acceptable-delay オプションを使用して、許容可能な遅延秒数(指定した監視対象 URL の取得に要する最大秒数)を指定しています。デフォルトの許容可能遅延秒数は 60 秒です。

Content Engine(config)# http monitor url http://www.abc.com/ ?
acceptable-delay Threshold time in seconds before which the URL should be
retrieved.(default is 60 seconds)
interval Interval in seconds for monitoring the URL.(default is 60 seconds)
<cr>
 

次のコマンドの出力例では、 acceptable-delay オプションを使用して、許容可能な遅延時間、つまり指定した URL の取得に要する最大秒数を指定しています。

Content Engine(config)# http monitor url http://www.abc.com/ acceptable-delay ?
<1-3600> Acceptable delay in seconds
 

http monitor url url コマンドを使用して個別の間隔または許容可能遅延時間の設定を使って同一 URL を設定すると、最も新しい設定が優先し、その特定 URL について以前に設定された内容は無効になります。


次のコマンドの出力例では、 interval オプションを使用してモニタ間隔(つまり、Content Engine が 特定 URL の要求をモニタする頻度)を指定しています。モニタリング間隔は、秒単位で指定されます。デフォルトの監視間隔は 60秒です。

ContentEngine(config)# http monitor url http://www.abc.com/ acceptable-delay 100
interval ?
<1-3600> Monitor interval in seconds
 

次の例では、デフォルト値(間隔および許容可能遅延時間がそれぞれ 60 秒)を使用して http://www.abc.com/ という URL をモニタするように Content Engine を設定しています。

http monitor url http://www.abccorp.com/
 

次の例では、http://www.abc.com/ という URL をモニタするように Content Engine を設定しています。Content Engine は、URL を取得するまでに最大 100 秒まで待機し、URL への要求を 100 秒ごとにモニタするように設定しています。

ContentEngine(config)# http monitor url http://www.abc.com/ acceptable-delay 100
interval 100
 

URL が取得されるまでに 100 秒以上が経過すると、指定した許容可能遅延時間を超えます。Content Engine は、応答時間(最小または最大遅延時間)と、特定 URL について許容可能遅延時間を超えた回数を追跡します。これらの統計情報は、新しい show statistics http monitor EXEC コマンドの出力に表示されます。

モニタ対象 URL の統計情報を表示するには、 show statistics http monitor EXEC コマンドを入力します。

ContentEngine# show statistics http monitor
HTTP Monitor URL statistics
---------------------------
 
Monitor URL = http://www.abc.com
Total requests = 118
Failed requests = 30
Requests above acceptable delay = 37
Minimum response time = 8.183 seconds
Maximum response time = 210.021 seconds
 
Monitor URL = http://www.abccorp.com/
Total requests = 275
Failed requests = 44
Requests above acceptable delay = 26
Minimum response time = 0.071 seconds
Maximum response time = 164.061 seconds
 

このコマンド出力では、次のことが適用されます。

Failed requests は、成功しなかった要求(たとえば、その URL のドメイン名の解決に失敗した要求)です。

Requests above acceptable delay は、指定された許容可能遅延時間(acceptable-delay 設定で指定された最大秒数)を超えた要求です。

show running-configuration EXEC コマンドの出力には、URL モニタ設定に関する情報も含まれます。次の例では、 show running-configuration コマンドの出力からの抜粋で、この特定情報はボールド体で強調されています。

ContentEngine# show running-configuration
! ACNS version 5.3
!
!
hostname sust-7320-ce1
!
http persistent-connections timeout 300
http proxy incoming 8080
http proxy outgoing preserve-407
http tcp-keepalive enable
http monitor url http://www.abc.com/ interval 100 acceptable-delay 100
http monitor url http://www.abccorp.com/
!
ftp proxy incoming 8080
!
clock timezone US/Eastern -5 0
!
!
.
.
.
 

show running-configuration コマンドからの出力には、デフォルト以外の値のみが表示されます。したがって、Content Engine がデフォルト値を使って URL http://www.abccorp.com をモニタするように設定されているので、出力例では、その URL についてこれらの値が表示されていません。

モニタ対象 URL のリストを表示するには、各モニタ対象 URL について間隔および許容可能遅延時間の設定を含め、 show http monitor EXEC コマンドを入力します。

ContentEngine# show http monitor
 
Monitor URL: http://www.abc.com/
Monitor Interval: 100
Acceptable Delay: 100
 
Monitor URL: http://www.abccorp.com/
Monitor Interval: 60
Acceptable Delay: 60