Cisco Unified Communications Manager マネー ジド サービス ガイド リリース 8.5(1)

CiscoLog のフォーマット

Cisco ソフトウェア アプリケーションの統一されたロギングのための仕様である CiscoLog は、Cisco Unified RTMT で使用されています。CiscoLog では、メッセージがファイルに記録される際や syslog プロトコルによって使用される際のメッセージ フォーマットが定義されています。Cisco ソフトウェア アプリケーションからの出力は、これらのアプリケーションによって提供されるサービスの監査、障害管理、トラブルシューティングに使用されます。

CiscoLog メッセージのフォーマットは、Cisco IOS ソフトウェアを次のコマンドで設定した場合に、syslog プロトコルを使用して Cisco IOS Release 12.3 によって生成されるメッセージのフォーマットの 1 つと互換性があることに注意してください。

• service sequence-numbers ：Cisco IOS によって生成されるデフォルトのシーケンス番号。このコマンドでは、追加のシーケンス番号もイネーブルにできます。このコマンドを実行すると、シーケンス番号が端末の出力に表示されますが、syslog 出力には 2 つのシーケンス番号が書き込まれることになります。CiscoLog は、シーケンス番号を 1 つだけ持つフォーマットについて標準化されています。そのため、Cisco IOS ソフトウェアの設定に対応するのは、 no service sequence-numbers コマンドを使用して第 2 の番号をディセーブルにした場合です。

• logging origin-id hostname ：CiscoLog の HOST フィールドは、このコマンドを使用して設定した場合、Cisco IOS Release 12.3 によって生成されるフィールドと一致します。このコマンドは、Cisco IOS ソフトウェアのマニュアルに記載されていませんが、Cisco IOS Release 12.3 で使用できます。CiscoLog は、Cisco IOS ソフトウェアがこのフィールドに生成する結果と互換性があります。

• service timestamps log datetime localtime msec show-timezone year ：CiscoLog の TIMESTAMP フィールドは、このコマンドを使用して設定した場合、Cisco IOS Release 12.3 によって生成されるタイムスタンプ フォーマットと一致します。

（注） CiscoLog では、Cisco IOS ソフトウェア Release 12.3 と同じフィールド区切りを使用します。

この項では次の内容について説明しています。

• 「ログ ファイルと Syslog 出力」

• 「標準の syslog サーバの実装」

• 「クロックの同期」

• 「マルチパート メッセージ」

• 「CiscoLog メッセージのフォーマット」

• 「国際対応」

• 「バージョン設定」

ログ ファイルと Syslog 出力

CiscoLog メッセージを、アプリケーションによって直接ログ ファイルに書き込んだ場合、各メッセージは個別の行に書き込まれます。行区切りは、所定のプラットフォームで使用されている標準的な行区切りです。Windows での行区切りは、復帰文字と改行文字（ASCII 10 進数値 13 および 10。プログラミング言語では「\r\n」と指定します）です。Solaris および Linux では、行区切りは単一の改行文字（ASCII 10 進数値 10。プログラミング言語では一般に「\n」と指定します）です。2 つの行区切りが連続して現れることはありません。たとえば、Windows では「\r\n\r\n」を使用できませんが、「\r\n」は問題ありません。これは、これらの 2 つの文字で 1 つの行区切りであるためです。

実際には、既存のログ ファイルにデータを追加する際にアプリケーション側で注意する必要があります。最初に改行が必要な場合とそうでない場合があります。たとえば、CiscoLog メッセージを書き込んでいるアプリケーションが、改行をファイルに書き込む前にクラッシュした場合、アプリケーション起動時に、次のメッセージを書き込む前に最初に改行を書き込む必要があります。アプリケーションは、起動時に最初の改行が必要かどうかを、追加用に使用されるログ ファイル中の最後の文字シーケンスを確認することで判断できます。

CiscoLog メッセージ フォーマットは、2 つの軽微な例外を除き、ログ ファイルに直接書き込まれるメッセージや、syslog プロトコルを使用して生成されたメッセージと同じです。CiscoLog メッセージがファイルに直接書き込まれる場合、行区切りを使用して追加する必要があります。CiscoLog メッセージが syslog プロトコルを使用して送信される場合、syslog RFC 3164 のプロトコル PRI ヘッダーを各 CiscoLog メッセージの前に追加する必要があります。

syslog PRI フィールドには、syslog メッセージの重大度と syslog ファシリティが符号化されます。PRI フィールドで符号化された重大度は、CiscoLog の SEVERITY フィールドの値と一致する必要があります。メッセージの内容にかかわらず、任意の syslog ファシリティを使用できます。一般に、既定のアプリケーションは、そのすべてのメッセージを 1 つの syslog ファシリティに送信するように設定されます（通常は RFC 3164 ファシリティの local 0 ～ local 7）。PRI フィールドの符号化方法の詳細については、RFC 3164 を参照してください。次に、重大度「通知（5）」とファシリティ値 local4 を符号化した、syslog プロトコルの PRI フィールドが <165> の CiscoLog メッセージの例を示します。

RFC 3164 のロギング メカニズムを使用した場合、前述の例に示すメッセージを UDP ポート 514 に送信できます。

Syslog RFC 3164 は、PRI フィールド以外のメッセージ内容のフォーマット用の追加のガイドラインを提供します。ただし、RFC 3164 は単なる情報であり（IETF の標準トラックにない）、実際には任意の形式でメッセージを syslog UDP ポート 514 に生成できます（RFC 3164 のセクション 4.2 を参照）。RFC には、実装に頻繁に見られる内容の構造についての所見が記載されていますが、その使用を要求または推奨しているわけではありません。CiscoLog フォーマットは、RFC で定義されているフォーマットの実用上の制限から、これらの所見に従っていません。たとえば、タイムスタンプが年、時間帯、ミリ秒なしで指定されていたり、ホスト名にドメイン名が指定できないという制限があります。

CiscoLog メッセージは、リレー時に変更されないことが必要です。PRI フィールドは CiscoLog メッセージの一部ではなく、プロトコル ヘッダーの一部です。これは、必要に応じて除去または置換できます。転送用に、CiscoLog メッセージにヘッダーやフッターを追加または除去できます。

標準の syslog サーバの実装

標準の syslog サーバの実装は、受信したログ メッセージを転送したり、メッセージをローカルに保存するように設定できます。ほとんどの syslog サーバの実装は、受信したメッセージから PRI フィールドを除去し、保存前にメッセージの先頭に追加の情報を付与します。一般に、この追加の情報には、メッセージを生成または中継したサーバのローカル タイムスタンプとホスト ID（IP または DNS 名）の 2 つのフィールドが含まれます。

次の CiscoLog メッセージの例は、Solaris 8 syslog サーバによってログに記録された後の出力を示します。

syslog サーバがメッセージを保存する方法を定義する標準はありません。実装は大きく異なります。CiscoLog は、メッセージが syslog サーバに送信されるフォーマットだけを扱い、それを受信したサーバが保存する方法は扱っていません。特に、syslog ログ ファイル中の追加のヘッダー フィールドのフォーマットや存在確認は、この仕様の範囲外です。

（注） CiscoLog 仕様では、syslog サーバの実装が CiscoLog メッセージを保存する際、受信したメッセージから PRI フィールドだけを除去し、ヘッダーを追加しない形式であることを推奨しています。これにより、アプリケーションによってログ ファイルに直接書き込まれた CiscoLog メッセージや、syslog プロトコルを通じてログに記録されたメッセージと同じ格納形式になります。

クロックの同期

分散アプリケーションのすべてのホストのクロックが、1 つの信頼できるクロックに同期していることは重要です。そのためには、NTP などのプロトコルを使用します。クロックの同期が推奨されるのは、複数のプロセスや複数のホストで生成されたメッセージに基づいて正しいイベント シーケンスを再構築するために、ログ メッセージ中のタイムスタンプが必要なためです。それでもクロックのズレが発生する可能性がありますが、継続的に同期することで、この問題を最小限に抑えることができます。

マルチパート メッセージ

ASCII 制御文字は、CiscoLog メッセージ フォーマットのどのフィールドでも使用できません。制御文字には、改行、フォーム フィード、復帰などの文字が含まれます。これは、次の目的以外で複数行のメッセージが使用できないことを意味します。

• 見やすさ（たとえば、スタック トレース）

• 800 オクテットの制限を超えるメッセージの分割

マルチパート CiscoLog メッセージは、複数の有効な CiscoLog メッセージのセットで構成されます。メッセージは、特別なタグ キー「part」を使用してグループ化されます。これは、元のメッセージのパート番号とシーケンス番号を示します。

マルチパート メッセージに含まれるすべてのメッセージは、「part」タグを含むとともに、HOST、TIMESTAMP、APPNAME、SEVERITY の各フィールドとその他の TAG 値と同じ値を含んでいる必要があります。ただし、各メッセージのシーケンス番号は、通常どおり 1 ずつ増える必要があります。

マルチパート メッセージの例

この例で、最初のメッセージのパート番号は 1 であり、そのシーケンス番号 16 は、part タグに埋め込まれています。以降のメッセージには、最初のメッセージ パートのシーケンス番号が埋め込まれ、固有のパート番号が設定されます。各 part タグの後ろに付与されている「/3」の値は、そのメッセージが 3 つのパートで構成されていることを意味しています。

CiscoLog メッセージのフォーマット

CiscoLog メッセージのフォーマットは次のとおりです。

<SEQNUM>: <HOST>: <TIMESTAMP>: %<HEADER>: [TAGS: ]<MESSAGE>

すべてのフィールドは、1 個のコロン文字（ASCII 10 進数値 58）と 1 個の空白文字（ASCII 10 進数値 32）で区切られます。また、HEADER フィールドの前には、パーセント文字（ASCII 10 進数値 37）が付与されます。

TIMESTAMP、HEADER、TAGS の各フィールドには内部的なフォーマットがあります。TIMESTAMP フィールドと HEADER フィールドの完全なフォーマットと詳細は次のとおりです。

<SEQNUM>: <HOST>: [ACCURACY]<MONTH> <DAY> <YEAR> <HOUR>:<MINUTES>:<SECONDS>.<MILLISECONDS> <TIMEZONE>: %<APPNAME>-<SEVERITY>-<MSGNAME>: [TAGS: ]<MESSAGE>

ACCURACY と TAGS 以外のすべてのフィールドは必須です。

次の例では、CiscoLog メッセージを示します。

次の例では、CiscoLog メッセージにおけるオプションの TAGS フィールドと ACCURACY フィールドを示します。

前述の例の、各フィールドの値は次のとおりです。

• SEQNUM：「12」

• HOST：「host.cisco.com」

• ACCURACY：「*」

• MONTH：「Jun」

• DAY：「13」

• YEAR：「2003」

• HOUR：「23」

• MINUTES：「11」

• SECONDS：「52」

• MILLISECONDS：「454」

• TIMEZONE：「UTC」

• APPNAME：「BACC」

• SEVERITY：「4」

• MSGNAME：「BAD_REQUEST」

• TAGS：「%[pname.orig=rdu][comp=parser][mac=1,6,aa:bb:cc:11:22:33][txn=mytxn123]」

• MESSAGE：「Bad request received from device [1,6,aa:bb:cc:11:22:33].Header missing.」

メッセージ長の制限

CiscoLog メッセージ全体の長さは、800 オクテットを超えてはなりません。オクテットという用語は、バイトの代わりに 8 ビット データ タイプを表すために使用されます。これは、一部のプラットフォームでは 1 バイトが 8 ビットでないためです。「文字」および「オクテット」という単語は、この仕様の中では同義ではありません。国際対応がサポートされている場合、1 文字を複数のオクテットで表現する必要があるためです。この制限は RFC 3164 によって定められています。1024 オクテットの制限により、後の仕様で形式化される可能性がある syslog 転送ヘッダーやフィールドのための領域が予約されます。

CiscoLog メッセージに syslog PRI フィールドが含まれている場合、結合された CiscoLog メッセージと PRI フィールドの長さは 805 オクテットを超えてはなりません。

SEQNUM フィールド

SEQNUM フィールドには、シーケンス番号が格納されます。これは、同じプロセスによって、同じタイムスタンプで複数のメッセージが生成される場合に、メッセージを時間の順に並べるために使用されます。シーケンス番号は、プロセスが起動してから最初に送信されるメッセージを 0 とし、同じプロセスによって生成される以降のロギング メッセージに対して 1 ずつ増やされます。アプリケーション プロセスが再起動されるたびに、そのシーケンス番号は 0 にリセットされます。各メッセージのシーケンス番号は、メッセージがアプリケーションによって送信/ログ記録された順番に付与される必要があります。

マルチスレッド化されたアプリケーションでは、そのための何らかの同期処理が必要となる可能性があります。また、JNI によるネイティブな（C）コードを含む Java アプリケーションでは、それ以外にも注意が必要になります。同じプロセスのネイティブな部分と Java 部分でログ メッセージを生成する場合、プロセスの 2 つの部分で同じシーケンス番号カウンタを使用し、シーケンス番号の順にメッセージを送信するには、実装を同期させる必要があります。

SEQNUM フィールドの最大値は 4,294,967,295 です。この値になったら、カウンタを 0 にリセットする必要があります。これは、Cisco IOS で使用されている 32 ビット符号なし整数の最大の正の値です。Cisco IOS は、シーケンス番号カウンタに ulong を使用しています。ulong は、mips、ppc、および 68k を含む、現在のすべての Cisco IOS プラットフォームでの、32 ビット符号なし整数です。

シーケンス番号はプロセス固有です。単一のホスト上に、1 つのロギング デーモンを共有する複数のアプリケーション プロセスがあるアプリケーション アーキテクチャの場合でも、シーケンス番号はプロセス固有である必要があります。そのため、各プロセスは独自のシーケンス番号を保持して増分します。

シーケンス番号は、失われたメッセージの検出にも役立ちます。そのため、シーケンス番号は省略できません。つまり、シーケンスの順のすべての番号に対してメッセージを生成する必要があります。

HOST フィールド

HOST フィールドは、メッセージの生成元のシステムを、Fully Qualified DNS Name（FQDN）、ホスト名、IPv4/IPv6 アドレスのいずれかで示します。FQDN またはホスト名がわかっている場合、2 つのうちのいずれかを HOST フィールドで使用する必要があります。ほとんどの展開ではホスト名で十分であると予想されます。ただし、展開が複数のドメインにまたがっている場合は、FQDN を使用することを推奨します。アプリケーションを両方のシナリオに展開することが予想される場合、デフォルトで FQDN を使用し、設定可能なオプションにすることを推奨します。

FQDN もホスト名も特定できない場合は、ホストの IP アドレスを使用する必要があります。IP アドレスを特定できない場合は、HOST フィールドの代わりに定数 0.0.0.0 を使用します。

（注） Cisco IOS フォーマットに関して、Cisco IOS Release 12.3 では、ホスト名、IP アドレス、任意のユーザ定義文字列を HOST フィールドで使用できます。ホスト名を使用するように設定されており、デバイスでホスト名が設定されていない場合は、「Router」などの文字列を使用します。

HOST フィールドの長さは 255 オクテットを超えてはなりません。

FQDN とホスト名

1 台のシステムに対して複数の FQDN またはホスト名がわかっている場合、アプリケーションはプライマリ FQDN/ホスト名を使用する必要があります。プライマリが指定されていない場合は、任意の FQDN/ホスト名を使用できます。ただし、関連する設定変更が行われるまで、アプリケーションは同じ HOST フィールドの値を使用する必要があります。つまり、システムに複数の FQDN/ホスト名が設定されている場合、FQDN/ホスト名の値をメッセージごとに自由に変えることはできません。

FQDN またはホスト名を符号化する際、印刷可能な US ASCII 文字（10 進数値 32 ～ 126）と外国語の文字だけを HOST フィールドで使用できます。HOST の適切な文字セットと符号化については、RFC 1123/STD-3 に準拠する必要があります。

これらの標準に従った使用可能な文字セットには、US ASCII 文字、数字、ダッシュ、およびドット区切り文字が含まれます（ただし先頭と末尾にはダッシュを使用できません）。標準に準拠することが推奨にとどまっている理由は、実際には、多くのホストがこの規約に従っておらず、アンダースコアなどの文字をホスト名で使用しているためです。ただし、HOST フィールドには文字シーケンス「: 」（コロンと空白）を含めることができません。このシーケンスは、CiscoLog フォーマットでフィールド区切りとして使用されているためです。

印刷可能な US ASCII 文字以外の外国語の文字は、国際対応ルールに従って符号化する必要があります。

印刷不可能な（制御）ASCII 文字は、HOST フィールドでは使用できません。制御文字には、ASCII 10 進数値 0 ～ 31 と 127 が含まれます。アプリケーションが、1 つ以上の制御文字を含む CiscoLog 準拠のライブラリとホスト文字列を提供している場合、ロギング ライブラリでは次のことを実行する必要があります。水平タブ文字（ASCII 10 進数値 9）が見つかったら、1 つ以上の空白文字（ASCII 10 進数値 32）で置き換える必要があります。タブあたり 8 個のスペースを推奨します。これは、ほとんどの Unix および Windows プラットフォームでこれが規約になっているためです。その他の制御文字は、疑問符文字（ASCII 10 進数値 63）で置き換える必要があります。

DNS で大文字と小文字が区別されない場合、CiscoLog では、HOST フィールドの読みやすさのために、小文字だけを使用することも推奨します。FQDN の最後のドットの使用はオプションです。次の例は有効な HOST フィールドです。

• host123

• host-123

• host123.cisco.com

• host123.cisco.com.

IP アドレス

HOST フィールドで使用される IP アドレスの値は、IPv4 アドレスまたは IPv6 アドレスです。デバイスに複数の IP アドレスがある場合は、CiscoLog メッセージを syslog サーバに送信する際に経由するインターフェイスにかかわらず、デバイスのプライマリ IP アドレスを使用する必要があります。プライマリ IP アドレスが指定されていない場合は、動的に割り当てられたアドレスよりも固定または静的 IP アドレスを優先させます。複数の静的 IP アドレスが存在する場合は、どれを使用しても構いませんが、関連する設定イベントがシステムで実行されるまでは、すべてのメッセージで一貫して使用する必要があります。

• IPv4 アドレス：IPv4 アドレスは、ドット表記「x.x.x.x」で表現します。ここで、x は 10 進数値 0 ～ 255 を ASCII テキストとして符号化したものです。IP アドレスが不明な場合は、プレースホルダとして 0.0.0.0 を使用します。有効な IPv4 アドレスの例は、0.0.0.0 と 212.1.122.11 です。

次に、HOST フィールドで IPv4 アドレスを使用したメッセージの例を示します。

次に、FQDN、ホスト名、IP がすべてわからない場合の CiscoLog メッセージの例を示します。

• IPv6 アドレス：IPv6 アドレス表現は、RFC 3513 のセクション 2.2.1、2.2.2、および 2.2.3 に記載されている表記法に従います。具体的には 3 つの表記法すべてがサポートされています。IPv6 アドレスでは小文字と大文字の両方を使用できますが、小文字を推奨します。IP アドレスが不明な場合は、IP アドレスとして 0.0.0.0 を使用します。次に、有効な IPv6 アドレスの例を示します。

– 1080:0:0:800:ba98:3210:11aa:12dd（完全表記）

– 1080::800:ba98:3210:11aa:12dd（「::」表記を使用）

– 0:0:0:0:0:0:13.1.68.3（最後の 4 オクテットを IPv4 として展開）

– 0.0.0.0（FQDN、ホスト名、および IP アドレスが不明）

次に、HOST フィールドで IPv6 アドレスを使用したメッセージの例を示します。

TIMESTAMP フィールド

TIMESTAMP フィールドには、年を含む日付、ミリ秒単位の時刻、時間帯識別子が、次の形式で表示されます。

[ACCURACY]<MONTH> <DAY> <YEAR> <HOUR>:<MINUTES>:<SECONDS>.<MILLISECONDS> <TIMEZONE>

次に、有効なタイムスタンプの例をいくつか示します。

場合によっては、ハードウェアやソフトウェアの制限により、デバイスで日付または時刻が認識されないことがあります。その場合には、文字列「--- 00 0000 00:00:00.000 ---」が TIMESTAMP フィールドに表示されます。次に日付と時刻が認識されていないデバイスからの CiscoLog メッセージの例を示します。

クロックがないデバイスは、相対的な時刻の指標として動作期間を設定できます。デバイスが動作期間を設定できる場合は、タイムスタンプが使用できない場合の代わりとして動作期間を設定することを推奨します。動作期間を設定する場合は、CiscoLog 標準タグ仕様で規定されているように、標準の動作期間タグを使用して設定します。

表 6-1 に各フィールドの仕様を示します。

HEADER フィールド

HEADER フィールドの形式は次のとおりです。

<APPNAME>-<SEVERITY>-<MSGNAME>

1 個のダッシュ文字（ASCII 10 進数値 45）を 3 つのフィールドの区切りとして使用します。

APPNAME フィールド

HEADER の中の APPNAME フィールドは、メッセージを生成するアプリケーションの名前を定義します。Cisco IOS は、APPNAME の代わりに、メッセージを生成する論理コンポーネントの名前を示す FACILITY を使用します。Cisco IOS 12.3 では、3950 個のメッセージに対して約 287 個のファシリティが定義されています。わかりやすいファシリティの例としては、AAAA、SYS、ATM、BGP、CRYPTO、ETHERNET、FTPSERVER、CONFIG_I、IP、ISDN、RADIUS、SNMP、SYS、TCP、UBR7200、X25 などがあります。定義されているファシリティの全リストについては、Cisco IOS のマニュアルを参照してください。

Cisco IOS の外部では、同じホスト上の複数のアプリケーションがログ メッセージを生成する可能性があります。そのため、APPNAME フィールドで指定のアプリケーションを確認する必要があります。追加の生成元の識別子は、HOST フィールドと、標準の TAGS フィールドのさまざまな値（pname、pid、comp など）で使用できます。

APPNAME フィールドは、2 つ以上の大文字または数字で指定し、アンダースコア文字を含んでいる必要があります。より正確には、使用できる文字セットは、ASCII 10 進数値 48 ～ 57（数字）、65 ～ 90（大文字）、および 95（アンダースコア）に限定されています。

APPNAME フィールドの長さは 24 文字を超えてはなりません。

アプリケーション名は、他の Cisco ソフトウェア アプリケーションや Cisco IOS ファシリティと競合してはなりません。

Solaris プラットフォームでは、APPNAME フィールドで使用するアプリケーション名の値を、アプリケーションのインストール パッケージ名と同じにし、大文字だけを使用し、CSCO プレフィクスを付けないことを推奨します（必須ではありません）。たとえば、Solaris 上で「CSCObacc」と登録されるアプリケーションでは、APPNAME フィールドの値として「BACC」を使用します。

一部のアプリケーションは、APPNAME フィールドの一部としてバージョンを指定します。それで問題はなく、特定のメッセージの意味がリリースごとに再定義される場合にはこのほうが便利です。たとえば、BACC バージョン 2.5 の APPNAME の値を、「BACC_2_5」とします。アプリケーション名の中でのバージョンの使用は任意であり、任意のリリースのアプリケーションで採用できます。

SEVERITY フィールド

SEVERITY フィールドは 0 ～ 7 の数値で示され、8 段階の重大度を示します。次に示す重大度は、Cisco IOS の重大度に一致しています。これは標準的な syslog の重大度でもあります。

メッセージで正しい重大度を使用することが大切です。特定のコンポーネントにおけるエラーは、コンポーネントに関する限りは重大であっても、アプリケーション全体がそれを適切に扱うことで、アプリケーション全体としては重大度を下げることができる場合があります。 表 6-2 に、メッセージの重大度を決定する際に従うべきガイドラインを示します。

アプリケーションがデフォルトの重大度を使用してログに記録するメッセージを判断する場合、このレベルを 5（通知）に設定することを推奨します。これにより、重大度が 5 以上のすべてのメッセージがデフォルトでログに記録されます。

MSGNAME フィールド

HEADER の MSGNAME フィールドは、特定の APPNAME のコンテキスト内でメッセージを一意に識別します。固定の重大度と論理的な意味が、特定の APPNAME の中で特定の MSGNAME に関連付けられています。つまり、メッセージが異なるプロセスによって生成される場合であっても、同じ APPNAME 値に対して、同じメッセージ名を異なる重大度で使用したり、論理的にまったく異なる意味で使用できません。

メッセージが標準的なメッセージの 1 つでない限り、メッセージ名は特定のアプリケーション（特定の値の APPNAME）に対してだけ固有です。そのため、CiscoLog メッセージを解釈するアプリケーション側で、特定の名前を持つメッセージが、このメッセージ名を使用するすべてのアプリケーションで同じ意味であることを仮定しないように注意する必要があります。メッセージが標準的なメッセージの 1 つでない場合は、アプリケーションごとにその重大度と意味が違うことがあります。

MSGNAME フィールドには、2 文字以上を設定する必要があります。使用できる文字は、ASCII 10 進数の 48 ～ 57（数字）、65 ～ 90（大文字）、および 95（アンダースコア）に限定されています。IOS では小文字も使用できますが、大多数の IOS メッセージは大文字だけを使用しています。確立された表記法に合わせるため、文字セットを大文字、数字、アンダースコアに限定しています。

メッセージ名は数字だけでも英数字でも構いません。ただし、IOS の表記法に従って、数値だけのラベルよりも、わかりやすい英数字のラベルを使用することを推奨します。たとえば、「341234」という識別子よりも、メッセージ名「NO_MEMORY」が推奨されます。

CiscoLog 標準タグ仕様では、メッセージ名に対応する数値の ID を示すための特殊なタグ mid が定義されています。このタグは、MSGNAME に加えて数値のメッセージを提供するために使用できます。このタグを使用する場合、特定の MSGNAME は、必ず 1 つのメッセージ ID 値に対応する必要があります。CiscoLog では、各標準メッセージに対して mid タグ値が定義されています。

MSGNAME フィールドの長さは 30 文字を超えてはなりませんが、ほとんどのメッセージ名はこれよりも短くします。MSGNAME の値は、この標準で定義されている名前と競合してはなりません。

論理的に異なる各メッセージに対しては、個別のメッセージ名を定義する必要があります。つまり、あるメッセージ名のメッセージ テキストは、いくつかの置換可能なパラメータによって変化できますが、論理的に異なるメッセージのメッセージ名は異なっている必要があります。

メッセージ名の正しい使用例を次に示します。

ホストの IP アドレスが変化しても、論理的に同じ種類のメッセージであることに注意してください。次に、メッセージ名での INCORRECT の使用例を示します。

前述の例では、2 つの異なるイベントに対して 1 つのメッセージ名を使用していますが、これは正しくなく、許容できません。これは、「catch-all」（何にでも使用できる）メッセージ名と呼ばれ、避ける必要があります。もう 1 つの極端な例は、「ERROR」という名前のメッセージを定義し、すべてのエラー ログ メッセージを同じメッセージ名で生成することです。これにより、メッセージ外部フィルタリングや容易なアクションのトリガを可能にするという、メッセージ名フィールドの目的が失われてしまいます。

「no-catch-all」（特定のものにしか使用できない）ルールに対する唯一の例外は、前もって一般的な記述よりも詳しくメッセージを識別できない場合や、メッセージのサブタイプをいくつかに区別してもユーザにとってのメリットがない場合です。

通常、すべてのデバッグ メッセージに対して個別のメッセージ名を定義する必要はありません（ただし、一部のアプリケーションはそのようにしています）。これは、デバッグ メッセージが、メッセージ名に基づく自動的なフィルタリングとアクションのトリガで使用することを目的としていないためです。デバッグ メッセージは数が多く、その中で生成される内容が非常に動的であるという性質から、個別のメッセージを定義することは非常に困難です。

この仕様では、特定のメッセージを定義する方法に関して疑問がある場合に、相談のためにグループで使用するメーリング リストを構築することを提案しています。現在、そのためのメーリング リストのエイリアスは「cmn-logging」です。

TAGS フィールド

メッセージ フォーマット内では、TAGS フィールドはオプションです。このフィールドは、メッセージ セットを外部的に分類またはフィルタするために使用できる、キーと値のペアの形で構造化された内容を提供するためのアプリケーションに対し、標準的なメカニズムを提供します。

タグは、仮想的なロギング チャネルを示すために使用できます。同じタグでフラグを設定されたメッセージのセットは、後で同じグループに分類できます。たとえば、アプリケーションは、特定のスレッドに属するメッセージに対応するタグを付与することで、フラグを設定できます。これにより、スレッドに基づくメッセージのフィルタリングと参照が可能になります。

仮想的なロギング チャネルは、複数のアプリケーションにまたがって確立することもできます。たとえば、すべてのアプリケーションが、あるデバイスからの要求をデバイス ID（MAC、IP など）でタグ付けできる場合、複数のコンポーネントと通信する場合でも、そのデバイスに関するすべてのメッセージを簡単にフィルタできます。

各アプリケーションは、サポートされるタグの独自のセットを定義できます。1 つのタグは、[KEY=VALUE] の形式のように、等号記号で区切られたキーと値のペアからなり、角カッコ文字で囲まれます。[ip=123.23.22.22] は有効なタグのキーと値のペアの例です。

TAGS フィールドの先頭にはパーセント文字（ASCII 10 進数値 37）が付与され、コロンと空白文字（ASCII 10 進数値 58 および 32）のシーケンスで終わります。複数のタグを組み合わせる場合、タグの間に区切り文字として文字を入れません。次の例は、4 つのタグがある完全な CiscoLog メッセージです。

TAGS フィールドがない場合、パーセント文字のプレフィクスと、後続のコロンと空白を省略します。このように、TAGS フィールドがない場合は、HEADER フィールドと MESSAGE フィールドを、HEADER フィールドの後の 1 個のコロンと空白だけで区切ります。次に例を示します。

同じタグ キーを持つ複数のタグを同じメッセージで使用できます。これにより、複数の値を持つキーの処理が可能になります。次に、デバイスに 2 つの IP アドレスがあり、アプリケーションでプロセス名とともに TAGS フィールドで両方の IP アドレスを生成する場合に生成されたメッセージの例を示します。

メッセージではタグをいくつでも使用できます。唯一の制限は、CiscoLog メッセージ全体の長さが 800 オクテットに制限されることです。

複数のタグがある場合、キーを英数字の順に並べることを推奨します。これにより、タグが常に同じ順序で生成されます。ただし、タグの順序を使用して何らかの意味を示す場合は、アプリケーションでこれ以外の順序を選択してもかまいません。

タグ キー

タグ キーには 1 つ以上の文字が含まれている必要があります。文字は ASCII 文字の 10 進数値 48 ～ 57（数字）、65 ～ 90（大文字）、95（アンダースコア）、97 ～ 122（小文字）に制限されます。小文字を使用することを推奨します。タグ キーの長さに対する厳格な制限はありませんが、一般的なメッセージ制限の 800 オクテットが適用され、短いタグ キー名を定義することが求められます。

タグの意味拡張

タグは標準的な値の構文を持つこともありますが、使用されているコンテキストに応じて異なる意味を持ちます。タグの意味拡張は、タグの文脈上の意味を区別するために使用されます。

意味拡張タグは、タグ キー、単一のドット文字（ASCII 10 進数値 46）、正しい文字セットのテキスト文字列を追加することで作成されます。

たとえば、"ip" タグは、IP アドレス表現のための構文を定義しますが、意味的な価値はありません。CiscoLog メッセージで使用されている "ip" タグは、一般にこの IP アドレスがメッセージに何らかの形で関係していることを意味します。場合によっては、そのような漠然とした関連付けで十分です。しかし、意味的価値を伝えることが有効な場合もあります。

メッセージに、送信元と宛先の 2 つの IP アドレス タグが関連付けられているとします。この場合、タグ「ip.from」と「ip.to」を使用することで、タグの構文と意味的価値の両方を示すことができます。もう 1 つの例は、標準的なタグ「ip.orig」です。これは、メッセージの送信元のホストの IP アドレスを示します。3 つのタグすべてを使用した例を次に示します。

複数のレベルの意味拡張タグを使用でき、それぞれの拡張でより詳細な意味を示すことができます。たとえば、タグ キー「ip.to.primary」は有効であり、宛先ホストのプライマリ IP アドレスを意味します。

コンテキストによってある値に無限の数の意味が考えられるため、意味的価値の標準化は構文よりもはるかに困難です。そのため、タグの意味拡張を定義する作業は、アプリケーション固有となることが予想されます。

タグの値

タグの値には、0 個以上の文字を指定できます。空の（0 文字の）値は、不明または未確定の値と解釈されます。値には、印刷可能な US ASCII 文字（ASCII 10 進数値範囲 32 ～ 126）と、外国語の文字だけを使用できます。

「[」、「]」、および「\」の 3 つの文字の使用については制限があります。カッコ文字（ASCII 10 進数値 91 と 93）は、バックスラッシュ文字（ASCII 10 進数値 92）でエスケープする必要があります。これにより、タグの開始と終了を示すカッコとの混同を避けることができます。このように、タグの値で文字「[」または「]」を表現する必要がある場合は、代わりにそれぞれ「\[」または「\]」のシーケンスを使用します。エスケープ文字自体をタグの値で表現する必要がある場合は、文字「\」の代わりに文字シーケンス「\\」を使用します。

印刷不可能な（制御）ASCII 文字は、TAG の値フィールドでは使用できません。制御文字には、ASCII 10 進数値 0 ～ 31 と 127 が含まれます。アプリケーションが、1 つ以上の制御文字を含む CiscoLog 準拠のライブラリとタグ値の文字列を提供している場合、ロギング ライブラリでは次のことを実行する必要があります。水平タブ文字（ASCII 10 進数値 9）が見つかったら、1 つ以上の空白文字（ASCII 10 進数値 32）で置き換える必要があります。タブあたり 8 個のスペースを推奨します。これは、ほとんどの Unix および Windows プラットフォームでこれが規約になっているためです。その他の制御文字は、疑問符文字（ASCII 10 進数値 63）で置き換える必要があります。技術的には、閉じカッコだけをエスケープすれば済みます。ただし、開きカッコと閉じカッコの両方でエスケープを必須とすることにより、パーサー コードが単純になり、そのままの形式でより一貫した表示になります。

タグ値の長さに対する厳格な制限はありませんが、一般的なメッセージ長制限の 800 オクテットが適用され、長さを控えめにすることが求められます。

タグのガイドライン

CiscoLog メッセージ フォーマット内では、TAGS フィールドはオプションです。タグは、メッセージ本体の中の置換可能パラメータを置き換えるものではありません。タグは、メッセージを識別および分類するための追加の方法を提供するだけです。

タグはオプションであるため、必要に応じてアプリケーションまたはユーザにより有効または無効にできます。同じメッセージが常に同じタグ セットで生成されることに対する要件はありません。アプリケーションが特定のタグをサポートしている場合、必ずしもそれを常に生成する必要があるわけではありません。これは設定可能です。実際には、アプリケーションが管理者に対し、少なくとも生成されるタグに対する制限された制御を提供することを推奨します。

アプリケーション開発者は、タグに設定する情報の内容と、メッセージ本体に設定する情報の内容について選択できます。場合によっては、情報が 2 つの間で重複しても構いません。これは許容可能です。

一般的なガイドラインは、必要なすべての情報をメッセージ本体に設定し、適切な情報をタグで設定することです。つまり、メッセージは、すべてのタグが無効にされた場合でも、十分な意味を提供する必要があります。タグは、単に追加の便利な情報を、標準的でフィルタしやすい形式で提供します。

メッセージとメッセージ タグの両方に MAC アドレスが含まれる、2 つの有効なメッセージの例を次に示します。タグを無効にした例

上の例で、MAC アドレスは、タグではなくメッセージ フィールドの一部として出力されています。次の例では、タグが有効になっています。MAC アドレスがタグとメッセージの両方で重複していますが、これは許容されます。

プロセス識別タグ

標準的なタグの 1 つ pname.orig は、メッセージの生成元の論理的なプロセス名を示すために使用されます。生成元プロセス情報を提供するアプリケーションは、必ず「pname.orig」タグを使用する必要があります。

このタグは、APPNAME フィールドの情報に加えて、非常に価値があります。アプリケーションによっては複数のプロセスが含まれ、それぞれがロギング メッセージを生成する場合があるためです。複数のプロセスで構成されるアプリケーションは、常に「pname.orig」タグを生成することを推奨します。

MESSAGE フィールド

MESSAGE フィールドは、ロギング イベントに関する説明のメッセージを提供します。このフィールドは、1 つ以上の文字からなります。文字セットは、印刷可能な US ASCII 文字（ASCII 10 進数値 32 ～ 126）と、外国語の文字に制限されています。

印刷できない（制御）ASCII 文字は、MESSAGE フィールドでは使用できません。制御文字には、ASCII 10 進数値 0 ～ 31 と 127 が含まれます。アプリケーションが、1 つ以上の制御文字を含む CiscoLog 準拠のライブラリとメッセージ文字列を提供している場合、ロギング ライブラリでは次のことを実行する必要があります。水平タブ文字（ASCII 10 進数値 9）が見つかったら、1 つ以上の空白文字（ASCII 10 進数値 32）で置き換える必要があります。タブあたり 8 個のスペースを推奨します。これは、ほとんどの Unix および Windows プラットフォームでこれが規約になっているためです。その他の制御文字は、疑問符文字（ASCII 10 進数値 63）で置き換える必要があります。

MESSAGE フィールドの最大長は、メッセージ全体の最大長だけによって制限されます。CiscoLog メッセージの最大長は 800 オクテットを超えてはなりません。もう 1 つの実用上の制限は、TAGS フィールドの長さが大きく変化する可能性があることです。

メッセージ テキストは、メッセージに関する必要な詳細を提供する、置換可能パラメータを含むことができます。たとえば、次の例の IP アドレスは置換可能パラメータです。

置換可能パラメータは、上の例のように、カッコ文字「[」と「]」で囲むことを推奨します（必須ではありません）。さらに、置換可能パラメータのメッセージ テキストと値にカッコ文字を含めないことを推奨します。置換可能パラメータの値の中でカッコ文字を使用することが避けられない場合は、値に少なくともカッコが片方しか含まれない状態（閉じカッコなしの開きカッコなど）にならないようにしてください。これらの推奨事項に従うことで、CiscoLog メッセージから置換可能パラメータの値をプログラムによって抽出できるようになります。ただし、この推奨事項は、厳格な要件ではありません。

メッセージ テキストはスペル チェックする必要があります。編集上のレビューをすることを推奨します。これは、お客様が目にする可能性があるすべてのメッセージが対象となり、デバッグ メッセージも含まれます。

メッセージの最初の単語が英語の場合、先頭文字は大文字にします。単文のメッセージでは、末尾のピリオドは不要です。

国際対応

外国語の文字は、ASCII 10 進数値 0 ～ 126 の文字として定義されます。外国語の文字は、HOST フィールド、TAGS フィールドの値の部分、および MESSAGE フィールドでサポートされています。

外国語の文字は、Unicode 標準の UTF-8 を使用して符号化する必要があります。UTF-8 ではいかなる言語も符号化でき、アプリケーションが特定の言語に対するローカルの符号化/復号化ルールを認識している必要はありません。実際に、メッセージを符号化するアプリケーションは、メッセージの言語すら知る必要がありません。UTF-8 では、すべての Unicode 文字を符号化できます。

UTF-8 では、US ASCII 文字が、7 ビット ASCII 規約で通常どおり符号化された場合と同じように符号化されます。そのため、CiscoLog メッセージを解釈するアプリケーションは、メッセージ全体が UTF-8 で符号化されていると仮定できます。ただし、CiscoLog メッセージを生成するアプリケーションは、その製品で外国語をサポートする必要がないことがわかっている場合、メッセージ全体を US-ASCII 7 ビット規約で符号化できます。

UTF-8 は任意の言語で文字符号化できるため、異なる言語を組み合わせることができます。たとえば、1 つの使用例として、外国語を使用しない場合に英語が生成されるメッセージにおいて、外国語のいくつかのパラメータだけを含めることが考えられます。たとえば、ユーザ認証に関する英語のメッセージでユーザ名に日本語を含めることが考えられます。同様に、任意の数の言語を CiscoLog メッセージで組み合わせることができます。

外国語を含むメッセージを活用するためには、ログ ビューアで UTF-8 を解釈できることが必要です。また、多くの場合、システムに適切な言語のフォントがインストールされていることも必要になります。US-ASCII 専用のエディタでは、UTF-8 で符号化された US-ASCII 以外の文字は文字化けして表示されますが、US-ASCII テキストはすべて表示されます。

国際対応のサポートは、ローカル ファイルに書き込まれた CiscoLog メッセージとともに容易に使用できます。ただし、syslog RFC 3164 では、現在外国語のサポートが定義されていません。そのため、syslog サーバで国際対応のメリットを享受するためには、各オクテットの 8 ビットすべてをそのまま正しくリレーまたは保存することがテスト済みのサーバ実装を使用する必要があります。これにより、外国語を使用した場合に、メッセージの UTF-8 で符号化された部分ですべての情報が保持されます。

UTF-8 では、1 つの文字が 1 つ以上のオクテットに符号化されます。CiscoLog メッセージの長さの制限は、800 オクテットと規定されています。外国語では、800 オクテットの長さの制限は 800 文字よりも短くなることがある点に注意してください。「マルチパート メッセージ」で説明したガイドラインに従ってメッセージをマルチパート メッセージに分割する場合、1 つの文字に属する複数のオクテットを複数の行に分けることはできません。

バージョン設定

CiscoLog では、メッセージ フォーマット中でバージョン情報が提供されません。フォーマットに対する拡張は、フォーマットの制限の中で行う必要があります。CiscoLog メッセージ フォーマットでは、追加のタグを定義することで拡張できます。

アプリケーションで既存のメッセージに対する変更が必要な場合、APPNAME の値により新しい空間でメッセージを再定義できます。たとえば、BACC 2.5 の場合、BACC_2_5 のようにアプリケーション名にアプリケーションのバージョンを追加できます。

AuthenticationFailed

認証では、ログイン時に送信されたユーザ ID とパスワードが検証されます。無効なユーザ ID またはパスワードが使用された場合、アラームが生成されます。

表 6-3 に、AuthenticationFailed RTMT アラートのデフォルト設定を示します。

CiscoDRFFailure

このアラートは、Disaster Recovery Framework（DRF; 障害回復フレームワーク）バックアップまたは復元処理でエラーが発生したときに生成されます。

表 6-4 に、CiscoDRFFailure RTMT アラートのデフォルト設定を示します。

CoreDumpFileFound

このアラートは、CoreDumpFileFound イベントが生成されたときに発生します。このアラートは、コア アンプ ファイルがシステムに存在することを示します。

表 6-5 に、CoreDumpFileFound RTMT アラートのデフォルト設定を示します。

CpuPegging

CPU 使用率は、設定可能なしきい値に基づいてモニタされます。使用率が、設定されているしきい値を上回ると、このアラートが生成されます。

表 6-6 に、CpuPegging RTMT アラートのデフォルト設定を示します。

CriticalServiceDown

CriticalServiceDown アラートは、サービスのステータスがダウン状態の場合に生成されます（その他の状態の場合には生成されません）。

表 6-7 に、CriticalServiceDown RTMT アラートのデフォルト設定を示します。

HardwareFailure

このアラートは、ハードウェア障害イベント（ディスク ドライブの障害、電源の障害など）がトリガーされたときに発生します。

表 6-8 に、HardwareFailure RTMT アラートのデフォルト設定を示します。

LogFileSearchStringFound

このアラートは、LogFileSearchStringFound イベントが生成されたときに発生します。これは、検索文字列がログ ファイル中に見つかったことを示します。

表 6-9 に、LogFileSearchStringFound RTMT アラートのデフォルト設定を示します。

LogPartitionHighWaterMarkExceeded

このアラートは、ログ パーティションの使用済みディスク領域のパーセンテージが、設定された上限を超えると発生します。このアラートが生成された場合、Log Partition Monitoring Tool（LPM）はログ パーティション中のファイルを削除し（下限に達するまで）、ディスク領域が不足するのを防ぎます。

（注） LPM により、保持しておきたいファイルが削除される可能性があります。LogPartitionHighWaterMarkExceeded アラートを受信した場合はすぐに対処してください。

表 6-10 に、LogPartitionHighWaterMarkExceeded RTMT アラートのデフォルト設定を示します。

LogPartitionLowWaterMarkExceeded

このアラートは、LogPartitionLowWaterMarkExceeded イベントが生成されたときに発生します。これは、ログ パーティションの使用済みディスク領域のパーセンテージが、設定されている下限を超えたことを示します。

（注） このアラートは早期に発生する警告であることに注意してください。管理者は、ディスク領域を空ける作業を開始する必要があります。RTMT/TLC を使用すると、トレースおよびログ ファイルの収集や、サーバからの削除を行うことができます。管理者は、再度下限を超えないように、トレース ファイルの数を調整することを推奨します。

表 6-11 に、LogPartitionLowWaterMarkExceeded RTMT アラートのデフォルト設定を示します。

LowActivePartitionAvailableDiskSpace

このアラートは、アクティブ パーティションの利用可能なディスク領域のパーセンテージが、設定されている値を下回ると発生します。

表 6-12 に、LowActivePartitionAvailableDiskSpace RTMT アラートのデフォルト設定を示します。

LowAvailableVirtualMemory

RTMT は、仮想メモリの使用率をモニタしています。メモリが少なくなると、LowAvailableVirtualMemory アラートが生成されます。

表 6-13 に、LowAvailableVirtualMemory RTMT アラートのデフォルト設定を示します。

LowInactivePartitionAvailableDiskSpace

このアラートは、非アクティブ パーティションの利用可能なディスク領域のパーセンテージが、設定されている値を下回ると発生します。

表 6-14 に、LowInactivePartitionAvailableDiskSpace RTMT アラートのデフォルト設定を示します。

LowSwapPartitionAvailableDiskSpace

このアラートは、スワップ パーティションの利用可能ディスク領域が少ないことを示します。

（注） スワップ パーティションは仮想メモリの一部なので、スワップ パーティションとして利用可能なディスク領域が不足すると仮想メモリも不足することになります。

表 6-15 に、LowSwapPartitionAvailableDiskSpace RTMT アラートのデフォルト設定を示します。

ServerDown

このアラートは、リモート ノードに到達できない場合に発生します。

（注） Cisco Unified CM クラスタのみ：ServerDown アラートは、現在アクティブな AMC（プライマリ AMC、または プライマリ AMC が使用不可の場合にはバックアップ AMC）がクラスタ内の別のサーバに到達できない場合に生成されます。このアラートは、サーバ ダウン状態以外に、ネットワーク接続の問題も示します。

表 6-16 に、ServerDown RTMT アラートのデフォルト設定を示します。

SparePartitionHighWaterMarkExceeded

このアラートは、SparePartitionHighWaterMarkExceeded イベントが生成されたときに発生します。このアラートは、予備パーティション内の使用済みディスク領域のパーセンテージが、設定されている上限を超えたことを示します。予備パーティションの使用済みディスク領域のパーセンテージが、設定されている下限を下回るまで、いくつかのコア ファイルまたはログ ファイルがパージされます。予備パーティションの使用済みディスク領域に設定されている上限が低すぎないかどうかを確認します。

Cisco Log Partition Monitoring Tool（LPM）は、予備パーティション内のトレース ログ ファイルのパージを開始し、予備パーティションのディスク使用率が下限を下回るまで予備パーティション内のトレース ログ ファイルを削除し続けます。

このアラームを生成するサービスの名前は、Cisco Log Partition Monitoring Tool です。

予備パーティションの使用済みディスク領域に設定されている上限が低すぎないかどうかを確認します。上限が低すぎる場合、上限の設定を高い値に変更します。また、予備パーティションの下にある各アプリケーションのトレース ログ ファイルを調べ、古すぎる、または大きすぎるトレース ログ ファイルを削除します。

（注） Intercompany Media Engine サーバでは、予備パーティションは使用されません。そのため、Intercompany Media Engine ではこのアラートはトリガーされません。

表 6-17 に、SparePartitionHighWaterMarkExceeded RTMT アラートのデフォルト設定を示します。

SparePartitionLowWaterMarkExceeded

このアラートは、SparePartitionLowWaterMarkExceeded イベントが生成されたときに発生します。このアラートは、予備パーティションの使用済みディスク領域のパーセンテージが、設定されている下限しきい値を超えたことを示します。Cisco Log Partition Monitoring Tool（LPM）により、ファイルがパージされます。予備パーティションのディスク使用率が、設定されている上限を超えるまで増加し続ける場合、Cisco LPM は予備パーティション内のトレース ログ ファイルのパージを開始します。予備パーティションのディスク使用率が変わらない場合、Cisco LPM はこのアラームを定期的に送信します。

このアラームを生成するサービスの名前は、Cisco Log Partition Monitoring Tool です。

予備パーティションの使用済みディスク領域に設定されている下限が低すぎないかどうかを確認します。下限が低すぎる場合、下限および上限の設定を高い値に変更します。また、予備パーティションの下にある各アプリケーションのトレース ログ ファイルを調べ、使用済みディスク領域が上限を超える前に古すぎる、または大きすぎるトレース ログ ファイルをクリーンアップします。

（注） Intercompany Media Engine サーバでは、予備パーティションは使用されません。そのため、Intercompany Media Engine ではこのアラートはトリガーされません。

表 6-18 に、SparePartitionLowWaterMarkExceeded RTMT アラートのデフォルト設定を示します。

SyslogSeverityMatchFound

このアラートは、SyslogSeverityMatchFound イベントが生成されたときに発生します。このアラートは、一致する重大度を含む syslog メッセージが存在することを示します。

SyslogStringMatchFound

このアラートは、SyslogStringMatchFound イベントが生成されたときに発生します。このアラートは、一致する検索文字列を含む syslog メッセージが存在することを示します。

SystemVersionMismatched

このアラートは、システムのバージョンが一致しない場合に発生します。

TotalProcessesAndThreadsExceededThreshold

このアラートは、TotalProcessesAndThreadsExceededThreshold イベントが生成されたときに発生します。このアラートは、プロセスおよびスレッドの現在の合計数が、Cisco RIS Data Collector サービス パラメータに設定されている最大タスク数を超えていることを示します。この場合、プロセスがリークしているか、プロセスでスレッド リークが発生している可能性があります。

BeginThrottlingCallListBLFSubscriptions

このアラートは、BeginThrottlingCallListBLFSubscriptions イベントが生成されたときに発生します。このアラートは、Cisco Unified Communications Manager がシステムのオーバーロードを防ぐために CallList Busy Lamp Field（CallList BLF; コールリスト ビジー ランプ フィールド）サブスクリプションの制御を開始したことを示します。

CallProcessingNodeCpuPegging

このアラートは、コール処理サーバの CPU 負荷率が、設定された時間で設定された割合を超えたときに発生します。

（注） 管理者が対処しない場合、特に CallManager サービスで、CPU の高い使用率が原因でクラッシュするおそれがあります。また、CoreDumpFound アラートと CriticalServiceDown アラートも発行される場合があります。

CallProcessingNodeCpuPegging アラートにより、Cisco Unified Communications Manager のクラッシュを未然に防ぐことができます。

CDRAgentSendFileFailed

このアラートは、Call Detail Record（CDR; コール詳細レコード）Agent が CDR ファイルを Cisco Unified Communications Manager ノードから Cisco Unified Communications Manager クラスタ内の CDR リポジトリ ノードに送信できない場合に発生します。

CDRFileDeliveryFailed

このアラートは、外部の課金サーバへの CDR ファイルの FTP 配信が失敗した場合に発生します。

CDRHighWaterMarkExceeded

このアラートは、CDR ファイルの上限を超えた場合に発生します。また、このアラートは、正常に配信された CDR ファイルのいくつかが削除されたことも示します。

CDRMaximumDiskSpaceExceeded

このアラームは、CDR ファイルのディスク使用率が最大ディスク割り当てを超えたときに発生します。また、このアラームは、配信不能なファイルがいくつか削除されたことも示します。

CodeYellow

AverageExpectedDelay カウンタは、着信メッセージを処理する現在の平均予測遅延を表します。値が Code Yellow Entry Latency サービス パラメータで指定されている値を超えた場合、CodeYellow アラームが生成されます。CodeYellow アラートは、トラブルシューティングの目的でトレース ファイルをダウンロードするように設定できます。

DBChangeNotifyFailure

このアラートは、Cisco Database Notification サービスに問題が発生し、このサービスが停止する可能性がある場合に発生します。この状態は、データベース内でキューに入れられている変更通知要求が停止し、システムに加えられた変更内容が有効にならないことを示します。アラートが存在するノードで Cisco Database Layer Monitor が実行されているかどうかを確認します。実行されている場合、このサービスを再起動します。サービスを再起動してもこのアラートが安全な範囲に戻らない場合、 show tech notify および show tech dbstateinfo の出力を収集し、対処方法についてシスコ テクニカル アシスタンス センター（TAC）までお問い合せください。

DBReplicationFailure

このアラームは、Informix Dynamic Server（IDS）の複製に障害があることを示し、データベース管理者の介入を必要とします。

（注） DBReplicationFailure は、（従来の DBReplicationFailure アラームではなく）複製ステータス perfmon カウンタに基づいていることに注意してください。このアラートは、対応する複製ステータス perfmon カウンタの値が 3（不正な複製）または 4（複製の設定失敗）になったときにトリガーされます。

DDRBlockPrevention

このアラートは、アラーム番号 31 の IDSReplicationFailure アラームが発生したときにトリガーされます。このアラームは、サービスの拒否を避けるための予防的なプロシージャを呼び出します。このプロシージャはコール処理に影響を与えないので、このプロセス中に複製アラームを無視できます。

このプロシージャは、完了するまでに最大 60 分かかります。このプロシージャが完了したことを確認するには、各ノードの RTMT 複製ステータスが 2 になっていることを確認します。このプロセス中にシステムをリブートしないでください。

DDRDown

このアラートは、アラーム番号 32 の IDSReplicationFailure アラームが発生したときにトリガーされます。バックグラウンドで自動回復プロシージャが実行されるので、対処は必要ありません。

このプロシージャは、完了するまでに約 15 分かかります。このプロシージャが完了したことを確認するには、各ノードの RTMT 複製ステータスが 2 になっていることを確認します。

ExcessiveVoiceQualityReports

このアラートは、設定されている時間間隔中に報告された Quality Report Tool（QRT）の回数が、設定されている値を超えたときに生成されます。デフォルトのしきい値は、60 分以内に 0 回です。

IMEDistributedCacheInactive

このアラームは、Cisco Unified Communications Manager が Cisco IME サーバに接続を試行したものの、IME 分散キャッシュがアクティブでない場合に生成されます。

Cisco IME サーバの証明書がプロビジョニングされていることと、IME 分散キャッシュがアクティブ化されていることを CLI を使用して確認します。

デフォルト設定

IMEOverQuota

このアラートは、この Cisco IME サービスを使用する Cisco Unified Communications Manager サーバが、IME 分散キャッシュに対してパブリッシュされた Direct Inward Dialing（DID; ダイヤル イン）数の割り当てを超えたことを示します。アラートには、Cisco IME サーバの名前に加え、現在およびターゲットの割り当て値が含まれます。

この Cisco IME サービスを使用するすべての Cisco Unified Communications Manager サーバで DID プレフィクスが正しくプロビジョニングされていることを確認します。

プレフィクスが正しくプロビジョニングされている場合は、Cisco IME サービスの容量を超えています。サービスをもう 1 つ設定し、異なる Cisco IME サービス上の Cisco IME クライアント インスタンス（Cisco Unified Communications Manager）に DID プレフィクスを分割する必要があります。

デフォルト設定

IMEQualityAlert

このアラートは、ネットワーク品質の問題によってかなりの数の Cisco IME コールが PSTN にフェールバックされたか、コールが確立されなかったことを Cisco Unified Communications Manager が特定したときに生成されます。このアラートは次の 2 種類のイベントによってトリガーされます。

現在アクティブな多数の Cisco IME コールがすべてフォールバックを要求した、または PSTN にフォールバックされた場合。

直近の多数のコールの試行が PSTN に送信されたが、IP 上に確立されなかった場合。

このアラートを受信したときは、IP 接続を確認します。IP 接続に問題がない場合、CDR、CMR、およびファイアウォールのログを確認し、コールが PSTN にフォールバックされた理由または IP 上に確立されなかった理由を判別します。

デフォルト設定

InsufficientFallbackIdentifiers

このアラートは、同一のフォールバック DID を使用する現在進行中の Cisco IME コールが多すぎて、Cisco Unified Communications Manager が処理している新しい Cisco IME コールに割り当てる DTMF ディジット シーケンスが足りないときに生成されます。新しいコールは継続しますが、音声品質が低下しても PSTN にフォールバックすることができません。

このアラームが生成された場合、このコールに関連付けるフォールバック プロファイルを確認します。Cisco Unified Communications Manager の管理ページでプロファイルを確認し、「Fallback Number of Correlation DTMF Digits」フィールドの現在の設定を調べます。このフィールドの値を 1 つ上げて、新しい値によってこれらのアラートが解消されるかどうかを確認します。一般に、このパラメータは十分大きい値にする必要があり、このプロファイルに関連付ける登録数に対して作成された Cisco IME 同時コール数が、この登録数を指数とする 10 の累乗の値よりも常にずっと低くなるようにします。たとえば、このフォールバック プロファイルに関連付けるパターンの Cisco IME 同時コール数が常に 10,000 未満である場合、この値を 5 に設定する（10 の 5 乗は 100,000）ことで、Cisco Unified Communications Manager からこのアラートが生成されなくなります。

ただし、この値を大きくすると、フォールバックに要する時間が若干長くなります。このため、「Fallback Number of Correlation DTMF Digits」フィールドの値は、このアラートが生成されない程度に大きい値を設定する必要があります。

DTMF ディジット フィールドの値を大きくする代わりに、異なるフォールバック DID を持つ別のフォールバック プロファイルを追加して、より少ない数の登録パターンをそのフォールバック プロファイルに関連付けることができます。この方法を使用すると、より少ない桁数を使用できます。

デフォルト設定

IMEServiceStatus

このアラートは、特定の Cisco IME クライアント インスタンス（Cisco Unified Communications Manager）の Cisco IME サービスに対する接続の全体的な健全性を示します。アラートは次の状態を示します。

• 0：不明。Cisco IME サービスがアクティブ化されていないことを示している可能性があります。

• 1：健全。Cisco Unified Communications Manager が Cisco IME クライアント インスタンスのプライマリおよびバックアップ サーバ（設定されている場合）への接続を正常に確立したことを示します。

• 2：動作不良。Cisco IME はアクティブ化されているが、Cisco IME サーバとのハンドシェイク手順を正常に完了していないことを示します。このカウンタの値はプライマリ IME サーバとセカンダリ IME サーバの両方のハンドシェイク ステータスを反映していることに注意してください。

デフォルト設定

InvalidCredentials

このアラートは、Cisco Unified Communications Manager で設定されたユーザ名とパスワードが Cisco IME サーバで設定されたものと一致しないために、Cisco Unified Communications Manager が Cisco IME サーバに接続できないことを示します。

アラートには、Cisco IME サーバへの接続に使用されたユーザ名とパスワードに加え、ターゲット Cisco IME サーバの IP アドレスおよび名前が含まれます。このアラートを解決するには、Cisco IME サーバにログインし、設定されているユーザ名およびパスワードが Cisco Unified Communications Manager で設定されているユーザ名およびパスワードと一致することを確認します。

デフォルト設定

LowCallManagerHeartbeatRate

このアラートは、CallManager のハートビート率が、設定されている値を下回ると発生します。

LowTFTPServerHeartbeatRate

このアラートは、Trivial File Transfer Protocol（TFTP; トリビアル ファイル転送プロトコル）サーバのハートビート率が、設定されている値を下回ると発生します。

MaliciousCallTrace

これは、Cisco Unified Communications Manager に迷惑呼が存在することを示します。Malicious Call Identification（MCID; 迷惑呼の識別）機能が呼び出されます。

MediaListExhausted

このアラートは、MediaListExhausted イベントの回数が、設定されている時間間隔中に、設定されているしきい値を超えたときに発生します。このアラートは、メディア リストで定義されている使用可能なメディア リソースがすべて使用中であることを示します。デフォルトの値は、60 分以内に 0 回です。

MgcpDChannelOutOfService

このアラートは、Media Gateway Control Protocol（MGCP; メディア ゲートウェイ コントロール プロトコル）D チャネルがアウト オブ サービスのままである場合にトリガーされます。

NumberOfRegisteredDevicesExceeded

このアラートは、NumberOfRegisteredDevicesExceeded イベントが生成されたときに発生します。

NumberOfRegisteredGatewaysDecreased

このアラートは、クラスタに登録されたゲートウェイの数が、連続したポーリング間で減少したときに発生します。

NumberOfRegisteredGatewaysIncreased

このアラートは、クラスタに登録されたゲートウェイの数が、連続したポーリング間で増加したときに発生します。

NumberOfRegisteredMediaDevicesDecreased

このアラートは、クラスタに登録されたメディア デバイスの数が、連続したポーリング間で減少したときに発生します。

NumberOfRegisteredMediaDevicesIncreased

このアラートは、クラスタに登録されたメディア デバイスの数が、連続したポーリング間で増加したときに発生します。

NumberOfRegisteredPhonesDropped

このアラートは、クラスタに登録された電話機の数が、連続したポーリング間で、設定されている割合を超えて減少したときに発生します。

RouteListExhausted

示されたルート リストで使用可能なルートが見つかりませんでした。

SDLLinkOutOfService

このアラートは、SDLLinkOutOfService イベントが生成されたときに発生します。このイベントは、ローカルの Cisco Unified Communications Manager がリモートの Cisco Unified Communications Manager と通信できないことを示します。通常、このイベントは、ネットワーク エラーまたはリモートの Cisco Unified Communications Manager が実行されていないことを示します。

TCPSetupToIMEFailed

このアラートは、Cisco Unified Communications Manager が Cisco IME サーバへの TCP 接続を確立できないときに発生します。このアラートは一般に、Cisco IME サーバの IP アドレスとポートが Cisco Unified Communications Manager の管理ページで正しく設定されていない場合か、イントラネット接続の問題が存在するために接続が確立されない場合に発生します。

アラートの Cisco IME サーバの IP アドレスとポートが有効であることを確認します。問題が解決しない場合は、Cisco Unified Communications Manager サーバと Cisco IME サーバ間の接続をテストします。

TLSConnectionToIMEFailed

このアラートは、Cisco IME サービスによって提示された証明書の期限が切れていたか、証明書が Cisco Unified Communications Manager CTL になかったために、Cisco IME サービスへの TLS 接続を確立できなかったときに発生します。

Cisco IME サービス証明書が Cisco Unified Communications Manager に設定されていることを確認します。

デフォルト設定

BDINotStarted

エラーが発生したため、BDI アプリケーションを起動できませんでした。

ファシリティ/サブファシリティ

CCM_JAVA_APPS-TOMCATAPPLICATIONS

Cisco Unified Serviceability アラーム定義カタログ

System/Java アプリケーション

重大度

緊急（0）

パラメータ

Reason [String]

推奨処置

アプリケーション ログで、エラーがないかどうかを確認します。

CallDirectorCreationError

CallDirector の作成中にエラーが発生しました。

ファシリティ/サブファシリティ

CCM_TCD-TCD

Cisco Unified Serviceability アラーム定義カタログ

CallManager/TCD SRV

重大度

緊急（0）

パラメータ

なし

推奨処置

なし

CiscoDirSyncStartFailure

Cisco DirSymc アプリケーションを正常に起動できませんでした。アプリケーションの起動中にエラーが発生しました。

ファシリティ/サブファシリティ

CCM_JAVA_APPS-TOMCATAPPLICATIONS

Cisco Unified Serviceability アラーム定義カタログ

System/Java アプリケーション

重大度

緊急（0）

推奨処置

アプリケーション ログで、エラーがないかどうかを確認します。アプリケーションの再起動が必要になる場合もあります。

ExcceptionInInitSDIConfiguration

InitSDIConfiguration 関数で例外が発生しました。

ファシリティ/サブファシリティ

CCM_TCD-TCD

Cisco Unified Serviceability アラーム定義カタログ

CallManager/TCD SRV

重大度

緊急（0）

パラメータ

なし

推奨処置

なし

FileWriteError

プライマリ ファイル パスに書き込めませんでした。

Cisco Unified Serviceability アラーム定義カタログ

System/汎用

重大度

緊急（0）

パラメータ

Primary File Path（String）

推奨処置

プライマリ ファイル パスが有効であり、対応するドライブに十分なディスク領域があることを確認します。また、このパスにデフォルトのログ ファイル パスと同等のセキュリティ権限があることも確認します。

GlobalSPUtilsCreationError

GlobalSPUtils の作成中にエラーが発生しました。

ファシリティ/サブファシリティ

CCM_TCD-TCD

Cisco Unified Serviceability アラーム定義カタログ

CallManager/TCD SRV

重大度

緊急（0）

パラメータ

なし

推奨処置

なし

HuntGroupControllerCreationError

HuntGroupController の作成中にエラーが発生しました。

ファシリティ/サブファシリティ

CCM_TCD-TCD

Cisco Unified Serviceability アラーム定義カタログ

CallManager/TCD SRV

重大度

緊急（0）

パラメータ

なし

推奨処置

なし

HuntGroupCreationError

Hunt Group の作成中にエラーが発生しました。

ファシリティ/サブファシリティ

CCM_TCD-TCD

Cisco Unified Serviceability アラーム定義カタログ

CallManager/TCD SRV

重大度

緊急（0）

パラメータ

なし

推奨処置

なし

IPAddressResolveError

ホスト IP アドレスが解決されませんでした。

ファシリティ/サブファシリティ

CCM_TCD-TCD

Cisco Unified Serviceability アラーム定義カタログ

CallManager/TCD SRV

重大度

緊急（0）

パラメータ

HostName [String]

推奨処置

なし

IPMANotStarted

エラーが発生したため、IP Manager Assistant（IPMA）アプリケーションを起動できませんでした。

ファシリティ/サブファシリティ

CCM_JAVA_APPS-TOMCATAPPLICATIONS

Cisco Unified Serviceability アラーム定義カタログ

System/Java アプリケーション

重大度

緊急（0）

パラメータ

Servlet Name [String] Reason [String]

推奨処置

アプリケーション ログで、エラーがないかどうかを確認します。

LineStateSrvEngCreationError

LineStateSrvEng の作成中にエラーが発生しました。

ファシリティ/サブファシリティ

CCM_TCD-TCD

Cisco Unified Serviceability アラーム定義カタログ

CallManager/TCD SRV

重大度

緊急（0）

パラメータ

なし

推奨処置

なし

LostConnectionToCM

CallManager への Telephony Call Dispatcher（TCD）接続が失われました。

ファシリティ/サブファシリティ

CCM_TCD-TCD

Cisco Unified Serviceability アラーム定義カタログ

CallManager/TCD SRV

重大度

緊急（0）

パラメータ

なし

推奨処置

なし

NoCMEntriesInDB

データベースに CallManager エントリが存在しません。

ファシリティ/サブファシリティ

CCM_TCD-TCD

Cisco Unified Serviceability アラーム定義カタログ

CallManager/TCD SRV

重大度

緊急（0）

パラメータ

なし

推奨処置

なし

NoFeatureLicense

機能ライセンスが見つかりません。Cisco Unified Communications Manager（Unified CM）を使用するには、ライセンスが必要です。また、Unified CM のライセンスはバージョン固有であるため、ライセンスが、実行しようとしているバージョン用のものであることを確認します。Cisco Unified CM の管理ページでライセンス ユニット レポートを実行できます（[システム（System）] > [ライセンス（Licensing）] > [ライセンス ユニット レポート（License Unit Report）] の順に選択）。

ファシリティ/サブファシリティ

CCM_CALLMANAGER-CALLMANAGER

Cisco Unified Serviceability アラーム定義カタログ

CallManager/CallManager

重大度

緊急

推奨処置

使用しているバージョンの Unified CM 用の Cisco Unified Communications Manager SW FEATURE のライセンスの生成を依頼し、Cisco Unified CM の管理ページでライセンスをアップロードします（[システム（System）] > [ライセンス（Licensing）] > [ライセンス ファイルのアップロード（License File Upload）] の順に選択）。

OutOfMemory

プロセスからオペレーティング システムに対してメモリが要求されていますが、使用可能なメモリが不足しています。

Cisco Unified Serviceability アラーム定義カタログ

System/汎用

重大度

緊急（0）

パラメータ

なし

推奨処置

なし

ServiceNotInstalled

実行可能ファイルの開始が試行されていますが、サービス制御マネージャでサービスとして設定されていないため、開始できません。サービス名は %s です。サービスがインストールされていません。

Cisco Unified Serviceability アラーム定義カタログ

System/汎用

重大度

緊急（0）

パラメータ

Service（String）

推奨処置

サービスを再インストールします。

SyncDBCreationError

SysController で SyncDB の作成中にエラーが発生しました。

ファシリティ/サブファシリティ

CCM_TCD-TCD

Cisco Unified Serviceability アラーム定義カタログ

CallManager/TCD SRV

重大度

緊急（0）

パラメータ

なし

推奨処置

なし

SysControllerCreationError

SysController の作成中にエラーが発生しました。

ファシリティ/サブファシリティ

CCM_TCD-TCD

Cisco Unified Serviceability アラーム定義カタログ

CallManager/TCD SRV

重大度

緊急（0）

パラメータ

なし

推奨処置

なし

TapiLinesTableCreationError

TapiLinesTable の作成中にエラーが発生しました。

ファシリティ/サブファシリティ

CCM_TCD-TCD

Cisco Unified Serviceability アラーム定義カタログ

CallManager/TCD SRV

重大度

緊急（0）

パラメータ

なし

推奨処置

なし

TimerServicesCreationError

TimerServices の作成中にエラーが発生しました。

ファシリティ/サブファシリティ

CCM_TCD-TCD

Cisco Unified Serviceability アラーム定義カタログ

CallManager/TCD SRV

重大度

緊急（0）

パラメータ

なし

推奨処置

なし

TestAlarmEmergency

緊急アラームのテストです。

ファシリティ/サブファシリティ

CCM_CALLMANAGER-CALLMANAGER

Cisco Unified Serviceability アラーム定義カタログ

System/テスト

重大度

緊急（0）

推奨処置

なし

WDNotStarted

エラーが発生したため、WebDialer アプリケーションを起動できませんでした。

ファシリティ/サブファシリティ

CCM_JAVA_APPS-TOMCATAPPLICATIONS

Cisco Unified Serviceability アラーム定義カタログ

System/Java アプリケーション

重大度

緊急（0）

パラメータ

Servlet Name [String] Reason [String]

推奨処置

アプリケーション ログで、エラーがないかどうかを確認します。

CertValidLessthanADay

証明書が 24 時間以内で期限切れになるか、すでに期限切れになっています。

Cisco Unified Serviceability アラーム定義カタログ

System/CertMonitorAlarmCatalog

重大度

アラート（1）

ルーティング リスト

イベント ログ

システム ログ

パラメータ

Message（String）

推奨処置

Cisco Unified Operating System にアクセスし Certificate Management に進むことで、期限切れになろうとしている証明書を再生成します。証明書が CA によって発行されている場合は、CSR を生成し、CSR を CA に送信して、CA から新しい証明書を入手し、Cisco Unified CM にアップロードします。

CMIException

データベースの読み取り中にエラーが発生しました。

このアラームは、CMI サービス パラメータを無効な値で設定するか、シリアル ポートから無効なハンドル値が返されることでトリガーされる、他のアラームに常に関連付けられます。

Cisco Unified Serviceability アラーム定義カタログ

CMIAlarmCatalog/CMI

重大度

アラート

ルーティング リスト

イベント ログ

SDI

パラメータ

CMI Exception（String）

推奨処置

詳細については、関連するアラームを参照してください。

CMOverallInitTimeExceeded

Cisco Unified Communications Manager システムの初期化にかかる時間が、System Initialization Timer サービス パラメータで指定された値の許容時間よりも長くかかっています。このため、システムは自動的に再起動され、初期化が再試行されます。初期化が失敗した理由には、データベース エラー、システムに追加された大量の新しいデバイス、またはその他のいくつかの潜在的原因が考えられます。Cisco Unified Communications Manager の初期化に必要な時間が、Cisco CallManager サービス パラメータの System Initialization Timer で許容される時間を超えています。システム サイズの増加が、このエラーの原因である可能性があります。