Cisco Unified Communications Manager 8.6(1) トラブルシューティング ガイド

一般的なヒント

• Cisco UCM SNMP Service のトレース設定を詳細に設定します（『 Cisco Unified Serviceability Administration Guide 』を参照）。

• コマンド snmp walk -c <community> -v2c <ipaddress> 1.3.6.1.4.1.9.9.156.1.1.2 を実行します。

• Cisco Unified Communications Manager のバージョンの詳細を取得します。

• 次の処理を実行してログと情報を収集します。

– SNMP Master Agent（パス：platform/snmp/snmpdm/*）および Cisco UCM SNMP Service（パス：cm/trace/ccmmib/sdi/*）（RTMT の TLC を使用するか CLI コマンド file get activelog を使用）

– CLI コマンド show packages active snmp を使用して、SNMP パッケージのバージョンを取得します。

– CLI コマンド show risdb query phone を使用して、MMF Spy の出力を取得します。

• トレース ログと MMFSpy データを詳細な分析に送ります。

表 9-1 では、CISCO-CCM-MIB SNMP トラップが送信されたことを確認する手順を示します。

次のログおよび情報を収集して分析します。

• /platform/snmp/snmpdm/* に格納される SNMP Master Agent ログ。

• Cisco UCM SNMP Service（Real Time Monitoring Tool（RTMT）を使用するか、 file get activelog < path > CLI コマンドを入力）。ログが格納されるパスは /cm/trace/ccmmib/sdi/* です。

• /usr/local/Snmpri/conf フォルダ内のすべてのファイル。（これは、ROOT/REMOTE ログインが可能な場合にだけ可能です）。

• 上記のフォルダの 'ls -l'リスト。（これは、ROOT/REMOTE ログインが可能な場合にだけ可能です）。

• perfmon のログ（ file get activelog /cm/log/ris/csv/ CLI コマンドを実行）。

• 問題を引き起こした一連の実行処理の詳細。

• ccmservice のログ（ file get activelog /tomcat/logs/ccmservice/log4j CLI コマンドを実行）。

• SNMP パッケージのバージョン（ show packages active snmp CLI コマンドを実行）。

• 電話機の MMF Spy 出力（ show risdb query phone CLI コマンドを実行）。

制限事項

SNMP 要求に複数の OID が指定されている場合、および変数が CISCO-CCM-MIB の空のテーブルを指している場合、要求には時間がかかります。getbulk/getnext/getmany 要求の要求 PDU 内に複数の OID があり、CISCO-CCM-MIB で後続のテーブルが空の場合、SNMP v1 バージョンでは NO_SUCH_NAME、SNMP v2c または v3 バージョンでは GENERIC_ERROR が応答で指定されることがあります。

• 理由：このタイムアウトは、CCMAgent のパフォーマンスを向上させ、大量の照会を取得したときに抑制する（これにより Cisco Unified Communications Manager コール処理エンジンのプライオリティが保護される）ために追加されたコードが原因で発生します。

• 回避策：

– テーブルにアクセスする前に利用可能なスカラ変数（1.3.6.1.4.1.9.9.156.1.5）を使用してテーブル サイズを判別するか、目的のテーブルで get 操作を実行してから、空ではないテーブルを照会します。

– 単一の要求内で照会される変数の数を減らします。たとえば、空のテーブルについては、管理アプリケーションのタイムアウトが 3 秒に設定されている場合、指定する OID は 1 つだけにすることを推奨します。空ではないテーブルについては、1 行のデータを取得するのに 1 秒かかります。

– 応答タイムアウトの値を大きくします。

– 再試行回数を減らします。

– getbulk SNMP API を使用しないようにします。getbulk API では、MaxRepetitions で指定されているレコード数が取得されます。つまり、次のオブジェクトがテーブルまたは MIB の範囲外であっても、それらのオブジェクトが取得されます。そのため、CISCO-CCM-MIB に空のテーブルがある場合は、次の MIB に進みます。この場合、応答に時間がかかります。テーブルが空ではないことがわかっており、レコード数もわかっている場合は、getbulk API を使用します。この状況では、応答を 5 秒以内に取得するために、最大繰り返し回数を 5 に制限します。

– SNMP 照会を構成し、現在の制限にあわせて調整します。

– 多数の電話機が Cisco Unified Communications Manager に登録されている場合は、PhoneTable で多数の getbulks を実行しないようにします。このようなシナリオでは、更新が発生すると常に ccmPhoneStatusUpdateTable が更新されます。

よくあるご質問

CISCO-CCM-MIB について、Cisco Unified Communications Manager ノードから SNMP トラップが取得されないのはなぜですか。

CISCO-CCM-MIB の SNMP トラップを受信するには、次の MIB OID の値が適切な値に設定されていることを確認する必要があります。ccmPhoneFailedAlarmInterval（1.3.6.1.4.1.9.9.156.1.9.2）および ccmPhoneStatusUpdateAlarmInterv（1.3.6.1.4.1.9.9.156.1.9.4）は、30 ～ 3600 に設定します。デフォルトでは、ゼロ（0）に指定されています。

Linux コンピュータから次のコマンドを実行します。

• snmpset -c < Community String > -v 2c < transmitter ip address > 1.3.6.1.4.1.9.9.156.1.9.2.0 i < value >

• snmpset -c < Community String > -v 2c < transmitter ip address > 1.3.6.1.4.1.9.9.156.1.9.4.0 i < value >

次の問題は、電話機の登録/登録解除/障害に関連しています。

• 通知の宛先の設定：通知の宛先が設定されていることを確認する必要があります。確認は Cisco Unified Serviceability Web ウィンドウから実行できます。[SNMP] > [Notification Destinations] というメニューがあります。

通知の宛先を設定する前に、必要な SNMP サービスがアクティブであり、実行されていることを確認します（SNMP Master Agent および Cisco UCM SNMP Service）。また、コミュニティ ストリング/ユーザの特権を正しく設定してあることを確認します。通知の権限も含まれている必要があります。

トラップがまだ生成されない場合は、対応するアラームが生成されるかどうかを確認します。これらのトラップはアラーム イベントに基づいて生成されるため、SNMP エージェントがこれらのアラーム イベントを取得していることを確認します。ローカル Syslog をイネーブルにします。Cisco UCM サービスアビリティのウィンドウ [アラーム（Alarm）] > [設定（Configuration）] で利用できるアラーム設定から、ローカル Syslog の宛先について Cisco UCM のアラーム設定を情報レベルに設定します。トラップを再現し、対応するアラームが CiscoSyslog ファイルにロギングされるかどうかを確認します。

• トラップとしての syslog メッセージの受信：特定の重大度を超える syslog メッセージをトラップとして受信するには、clogBasic テーブルで次の 2 つの MIB オブジェクトを設定します。

– clogNotificationsEnabled（1.3.6.1.4.1.9.9.41.1.1.2）：syslog トラップ通知をイネーブルにするには、これを true （ 1 ）に設定します。デフォルト値は false （ 2 ）です。例： snmpset -c < Community String > -v 2c < transmitter ip address > 1.3.6.1.4.1.9.9.41.1.1.2.0 i < value >

– clogMaxSeverity（1.3.6.1.4.1.9.9.41.1.1.3）：トラップを受け取る最低の重大度レベルを設定します。デフォルト値は warning （ 5 ）です。通知がイネーブルの場合、設定した重大度以下のアラーム重大度の syslog メッセージはすべてトラップとして送信されます。例： snmpset -c < Community String > -v 2c < transmitter ip address > 1.3.6.1.4.1.9.9.41.1.1.3.0 i < value >

Cisco Unified Communications Manager に対して定義されているさまざまなトラップは何ですか。

CISCO-CCM-MIB には、次の定義済みトラップのリストが含まれています。

• ccmCallManagerFailed：Cisco UCM プロセスが重要なサブシステムの 1 つで障害を検出することを示します。ハートビート/イベント モニタリング プロセスから検出することもできます。

• ccmPhoneFailed：ccmPhoneFailedAlarmInterval で指定された間隔によって ccmPhoneFailedTable 内の少なくとも 1 つのエントリが示されることを通知します。

• ccmPhoneStatusUpdate：ccmPhoneStatusUpdateTable 内に 1 つのエントリが存在する場合に ccmPhoneStatusUpdateInterv で指定された間隔で生成される通知です。

• ccmGatewayFailed：少なくとも 1 つのゲートウェイが Cisco UCM への登録および通信を試行して失敗したことを示します。

• ccmMediaResourceListExhausted：Cisco UCM が指定されたタイプのリソースを使い果たしたことを示します。

• ccmRouteListExhausted：指定されたルート リスト内で Cisco UCM が使用可能なルートを見つけることができなかったことを示します。

• ccmGatewayLayer2Change：Skinny ゲートウェイの登録済みインターフェイスの D チャネル/レイヤ 2 で状態が変更されることを示します。

• ccmMaliciousCall：ユーザがコールを悪質としてローカル Cisco UCM サーバに登録することを示します。

• ccmQualityReport：ユーザが Quality Report Tool を使用して品質の問題を報告することを示します。

• ccmTLSConnectionFailure：Cisco Unified Communications Manager が指定されたデバイスの TLS 接続のオープンに失敗したことを示します。

トラップのアラームへのマッピングは、次のとおりです。

• ccmCallManagerFailed--CallManagerFailure

• ccmPhoneFailed--DeviceTransientConnection

• ccmPhoneStatusUpdate

• ccmGatewayFailed--DeviceTransientConnection

• ccmMaliciousCall--MaliciousCall

• ccmMediaResourceListExhausted--MediaResourceListExhausted

• ccmQualityReportRequest--QRTRequest

• ccmRouteListExhausted--RouteListExhausted

• ccmGatewayLayer2Change--DChannelOOS, DChannelISV

Cisco Unified Communications Manager からのさまざまな SNMP トラップをどのようにしてチェックできますか。

少数のトラップを起動する次の手順を実行します。

• ccmPhoneStatusUpdate トラップ

– ccmAlarmConfigInfo MIB テーブルで ccmPhoneStatusUpdateAlarmInterv（1.3.6.1.4.1.9.9.156.1.9.4）を 30 以上に設定します。

– 電話機が登録されている Cisco Unified Communications Manager サーバを接続解除します。電話機が登録解除されます。

– Cisco Unified Communications Manager サーバを再接続します。電話機が再登録され、ccmPhoneStatusUpdate トラップが取得されます。

• ccmPhoneFailed トラップ

– ccmAlarmConfigInfo MIB テーブルで ccmPhoneFailedAlarmInterval（1.3.6.1.4.1.9.9.156.1.9.2）を 30 以上に設定します。

– 電話機が機能しないようにします。電話機を Cisco Unified Communications Manager から削除し、再登録します。電話機の障害のトラップの場合、次の 2 つの異なるシナリオを試行できます。

tftp/Cisco Unified Communications Manager サーバ A を指すように電話機を設定します。異なるスイッチで Cisco Unified Communications Manager サーバ B に電話機を接続します。電話機ステータスは不明のままです。次のメッセージが表示されます。

Cisco UCM で 7960 電話機を 7940 電話機として登録し、電話機障害トラップを生成する db 問題を発生させます。

• MediaResourceListExhausted トラップ

– メディア リソース グループ（MRG）を作成し、標準の ConferenceBridge リソース（CFB-2）のいずれかが含まれるようにします。

– メディア リソース グループ リスト（MRGL）を作成し、作成した MRG が含まれるようにします。

– 実際の電話機の [電話の設定（Phone Configuration）] ウィンドウで、MRGL を電話機の [メディア リソース グループ リスト（Media Resource Group List）] として設定します。

– IPVMS を停止します。これにより、ConferenceBridge リソース（CFB-2）は機能を停止します。

– メディア リストを使用して電話機で電話会議を行います。電話機の画面に「使用可能な会議ブリッジがありません（No Conference Bridge available）」が表示されます。

– MediaListExhausted アラーム/アラート/トラップが生成されるかどうかを確認します。

• RouteListExhausted トラップ

– ルート グループ（RG）を作成し、ゲートウェイが 1 つ含まれるようにします。

– ルート グループ リスト（RGL）を作成し、作成した RG が含まれるようにします。

– 9XXXX コールを RGL によって再ルーティングするルート パターン（9.XXXX）を作成します。

– ゲートウェイの登録を解除します。

– 電話機の 1 つで 9XXXX にダイヤルします。

– RouteListExhausted アラーム/アラート/トラップが生成されるかどうかを確認します。

• MaliciousCallFailed トラップ

– ソフトキー テンプレートを作成します。テンプレートで、使用可能なすべての [迷惑呼（MaliciousCall）] ソフトキーを電話機ステータスに追加します。

– この新しいソフトキー テンプレートを実際の電話機に割り当てます。電話機をリセットします。

– 電話をかけ、コール中およびコール後に電話機の画面で MaliciousCall を選択します。

– MaliciousCallFailed アラーム/アラート/トラップが生成されるかどうかを確認します。

• GatewayFailed トラップ

– 方法 1：Web Admin を使用してデータベースからゲートウェイ設定を削除するか、ゲートウェイ MAC アドレスを無効な値に変更して更新します。ゲートウェイをリブートします。または、ゲートウェイが接続されている Cisco UCM サービスを再起動します。

– 方法 2：ccmAlarmConfigInfo MIB テーブルで、GatewayAlarmEnable=true を設定します。Cisco Unified Serviceability で、SNMP の設定ウィンドウに移動し、SNMP コミュニティ ストリングおよびトラップの宛先が正しく設定されていることを確認します。ゲートウェイ障害イベントを作成すると、トラップ受信側にトラップが表示されます。ゲートウェイ障害およびフェールオーバーを発生させるには、Cisco UCM を再起動します。ゲートウェイが冗長 Cisco UCM サーバにフェールオーバーします。冗長 Cisco UCM サーバのデータベース内にゲートウェイを設定しないでください。

• ccmGatewayLayer2Change トラップ

– ccmGatewayLayer2Change トラップは、Cisco UCM からの D-Channel Out Of Service（DChannelOOS）または D-Channel Inservice（DChannelISV）中に起動されます。テスト目的で、そのようなイベントが起動されるかどうかを確認します。

• ccmCallManagerFailed トラップ

– Cisco UCM 障害アラームは、内部エラーの発生時に生成されます。これらのアラームには、CPU 不足、タイマーの問題などによる内部スレッド停止が含まれます。これは、Cisco UCM チームがこれらのいずれかを意図的に発生させないかぎり再現が難しいトラップです。

Cisco UCM Agent の高い CPU 消費が継続する場合、何を行う必要がありますか。

分析用のログを収集し、障害 CSCsm74316 を参照します。使用している Cisco UCM リリースに障害の修正が追加されているかどうかを確認します。

CTI Routepoint が Cisco Unified CM の管理から削除された場合、ccmCTIDeviceTable mib 内に対応するエントリがあります。なぜですか。

「RIS Unused Cisco CallManager Device Store Period」というサービス パラメータによって、未登録デバイスが RIS データベースおよび MIB 内に残される時間が定義されています。[Cisco UCM の管理（Cisco UCM Administration）] ウィンドウと SNMP MIB は同期していない場合があります。[Cisco UCM の管理（Cisco UCM Administration）] ウィンドウにはデータベースからの情報が表示され、SNMP では RIS データベースが使用されるためです。

ccmPhoneType を Cisco-CCM-MIB の ccmPhoneTable で照会したときに情報が返されません。なぜですか。

これは、ccmPhoneType が古いことを意味します。CcmProductTypeEntry に対する ccmPhoneProductTypeIndex から、同じ情報を取得できます。テーブルでは、インデックスはそのテーブルでリストされているインデックスと名前に対応します。

次のリストに、その他の古い OID の一部と、参照する必要がある代替 OID を示します。

• ccmGatewayType は古いため、ccmGateWayProductTypeIndex を参照する必要があります。

• ccmMediaDeviceType は古いため、ccmMediaDeviceProductTypeIndex を参照する必要があります。

• ccmCTIDeviceType は古いため、ccmCTIDeviceProductTypeIndex を参照する必要があります。

ccmPhoneProductTypeIndex に対する照会でゼロが返ります。なぜですか。

使用している Cisco Unified Communications Manager リリースにこの機能があることを確認します。

WALK が ccmPhoneTable に対して実行されていますが、ccmPhoneUserName によって値が返されません。ユーザ名は IP Phone にどのように関連付けられていますか。

エンド ユーザを作成し、登録済みの電話機に移動して、オーナーのユーザ ID を関連付けます。これを実行したあとに、SNMP Walk 内の OID によってユーザが表示されます。

SNMP を使用して各電話機のファームウェアのバージョンを取得するにはどうすればいいですか。

ccmPhoneTable 内の ccmPhoneLoadID オブジェクトによって、各電話機のファームウェア バージョンが示されます。新しいイメージ ダウンロードが失敗した場合にはこの値が異なることがあります。SNMP では、設定済みのファームウェア ID（ccmPhoneLoadID）と実際に実行されているファームウェア（ccmPhoneActiveLoad）の両方が示されるためです。

CCM MIB によって ccmVersion が 5.0.1 として返されますが、これは間違いです。

使用している Cisco Unified Communications Manager リリースにこの機能があることを確認します。ない場合はアップグレードしてください。

CCM MIB が正しくない ccmPhoneLoadID を返します。

ccmPhoneLoadID の値は RIS データベースから取得されます。このデータベースには、電話機の登録中に受信されたアラームに基づいて情報が入力されます。次の手順を実行し、詳細な分析のためのログを収集してください。

ステップ 1 Cisco Unified Serviceability で、[Alarm] > [Configuration] を選択します。サーバを選択します。次に、[Go] をクリックします。サービス グループの [CM Services] を選択します。次に、[Go] をクリックします。サービスの [Cisco CallManager] を選択します。次に、[Go] をクリックします。

ステップ 2 [Local Syslog]、[SDI Trace]、および [SDL Trace] の [Enable Alarm] をオンにします。それぞれの [Alarm Event Level] ドロップダウン リスト ボックスから [Informational] を選択します。

ステップ 3 [Trace Configuration] ウィンドウで、Cisco UCM サービスの [Debug Trace Level] を [Detailed] に設定します。

ステップ 4 正しくない LoadID が表示されている電話機をリセットします。

ステップ 5 Syslog および Cisco UCM トレースを収集します。

ステップ 6 電話機の詳細を収集します。

Cisco Call Manager のステータス（START/STOP）はどのようにすればモニタできますか。

サービス監視には次のオプションがあります。

• SYSAPPL MIB

• HOST-RESOURCE-MIB

• CISCO-CCM-MIB（ccmStatus）

• SOAP インターフェイス

• Real-Time Monitoring Tool（RTMT）アラート

Cisco UCM サービス障害用に ccmCallManagerFailed トラップがあります。ただし、このトラップでは、通常のサービス停止および不明のクラッシュは対象になりません。

ポーリングされたデバイスのデバイス プール情報が正しくないように見えます。なぜですか。使用された OID は ccmPhoneDevicePoolIndex です。

CISCO-CCM-CAPABILITY MIB に記述されているように、ccmPhoneDevicePoolIndex はサポートされていないためゼロ（0）が返されます。Cisco UCM デバイス登録アラームには、現在はデバイス プール情報は含まれていません。

収集するログ

トラブルシューティング目的で次のログおよび情報を収集します。

• hostagt ログ ファイル。 file get activelog /platform/snmp/hostagt/ コマンドを実行して収集します。

• syslog ファイル。 file get activelog /syslog/ コマンドを実行して収集します。

• Master SNMP Agent ログ ファイル。 file get activelog /platform/snmp/snmpdm/ コマンドを実行して収集します。

• 実行した一連の操作。

ディスク容量および RTMT

HOST-RESOURCES-MIB で表示される使用済みディスク容量と使用可能ディスク容量の値は、RTMT で表示されるディスク容量の値と一致しない場合があります。これは、ファイル システムの予約済みディスク ブロックにおける最小空き容量の割合が原因です。リリース 7.1(x) 以降のシステムでの Cisco Unified Communications Manager の minfree 値は 1% のため、RTMT および HOST-RESOURCES-MIB によって表示される使用済みディスク容量の値には 1% の相違があります。

• RTMT では、df の報告値を使用して使用済みディスク容量の値が表示されます。この値は、[（合計容量 - 使用可能容量）/ 合計容量] × 100 で計算されます。合計容量には最小空き容量も含まれます。

• HOST-RESOURCES-MIB での使用済みディスク容量の値は [hrStorageUsed / hrStorageSize] x 100 で計算されます。hrStorageSize には最小空き容量は含まれません。

よくあるご質問

HOST-RESOURCES-MIB をプロセスのモニタリングに使用できますか。

Host Resources MIB では、hrSwRunTable 内の、システムで実行されているプロセスに関する情報が取得されます。ただし、システムで実行されているすべてのプロセスが監視されます。インストールされているシスコのアプリケーションだけを監視する必要がある場合は、SYSAPPL-MIB の使用を推奨します。

Real-Time Monitor Tool によって表示されるメモリ使用率の値は HOST-RESOURCES-MIB にどのようにマッピングされますか。

表 9-2 に、メモリ使用率の値の一覧を示します。

RTMT で表示されるディスク容量の値と HOST-RESOURCES-MIB のディスク容量の値が異なるのはなぜですか。

一般的に、df サイズは表示される使用済みおよび使用可能なディスク容量データと一致しません。これは、予約済みのファイル システム ディスク ブロックの minfree パーセンテージのために発生します。リリース 6.x および 7.0 の Cisco Unified Communications Manager の minfree 値は 1% です。RTMT および HOST-RESOURCES-MIB で表示される使用済みディスク容量の値には、1% の差異が発生します。

RTMT では、使用済みディスク容量の値は df 報告値から表示されます。[(合計容量 - 使用可能容量) / 合計容量] * 100 であり、合計容量には minfree も含まれます。HOST-RESOURCES-MIB の場合、これは [hrStorageUsed/hrStorageSize] * 100 で計算されます。hrStorageSize には minfree は含まれません。

hrStorageUsed の値は、ホスト エージェントではどのように表示されますか。

物理 RAM の hrStorageUsed ではデータは使用済み（バッファ + キャッシュ）という観点で表示されるように修正されました。ホスト エージェントのバージョンが正しいかどうかを確認するには、 show packages active snmp コマンドを使用して、システムにインストールされている snmp-rpm バージョンを収集します。

メモリ容量/使用率の値は HOST-RESOURCES-MIB の値とどのように比較されますか。

HOST-RESOURCES-MIB では、サイズおよび使用済みストレージは hrStorageUnits で表されます。そのストレージ タイプで、hrStorageUnits が 4096 バイトの場合、MIB 値で照会される hrStorageUsed または hrStorageSize の値には 4096 が掛けられます。たとえば、 show status コマンドを使用することで、Physical RAM の合計メモリは 4090068K として表示されます。

physicalRAM ストレージ タイプの hrStorageUnits が 4096 バイトの場合、Physical RAM の hrStorageSize は 1022517 として表示されます。これは 4090078K [(1022517 × 4096)/1024 = 4090068K] です。

Windows で、HOST-RESOURCES-MIB の hrSWRunName に対する SNMP 照会で断続的に正しくないエントリが返されるのはなぜですか。

Microsoft 社の SNMP 拡張エージェント（hostmib.dll）では、HOST-RESOURCE-MIB がサポートされています。Microsoft のサポートがこの問題に役立つ場合があります。この問題が継続する場合は、次の手順を実行します。

ステップ 1 tlist snmp.exe ファイルを使用して、hostmib.dll が出力内にリストされていることを確認します。

ステップ 2 SNMP サービスの開始時に、SNMP からのエラー/警告メッセージがイベント ビューアにないことを確認します。

ステップ 3 snmp サービス プロパティで、使用されるコミュニティ ストリングが読み取り権限で設定されていることを確認します。

ステップ 4 MSSQL-MIB（MssqlSrvInfoTable）を使用して、SQL プロセスのステータスを確認します。

プロセスのモニタリング

HOST-RESOURCES-MIB は、システムで実行されているすべてのプロセスに関する情報を hrSWRunTable から取得します。システムで実行されているすべてのプロセスをモニタする場合は、この MIB を使用します。インストールされているシスコのアプリケーションだけを監視するには、SYSAPPL-MIB.Disk Space および RTMT を使用します。

HOST-RESOURCES-MIB で表示される使用済みディスク容量と使用可能ディスク容量の値は、RTMT で表示されるディスク容量の値と一致しない場合があります。これは、ファイル システムの予約済みディスク ブロックにおける最小空き容量の割合が原因です。6.x および 7.0 システムでの Cisco Unified Communications Manager の minfree 値は 1% のため、RTMT および HOST-RESOURCES-MIB によって表示される使用済みディスク容量の値には 1% の相違があります。

• RTMT では、df の報告値を使用して使用済みディスク容量の値が表示されます。この値は、[（合計容量 - 使用可能容量）/ 合計容量] × 100 で計算されます。合計容量には最小空き容量も含まれます。

• HOST-RESOURCES-MIB での使用済みディスク容量の値は [hrStorageUsed / hrStorageSize] x 100 で計算されます。hrStorageSize には最小空き容量は含まれません。

一般的なヒント

次のログおよび情報を収集して分析します。

• set trace enable Detailed cdpmib コマンドを使用して、cdpAgt () の詳細トレースを設定します。

• Cisco Unified Serviceability ウィンドウ（[ツール（Tools）] > [コントロール センター（Control Center）] > [ネットワーク サービス（Network Services）]）から Cisco CDP Agent サービスを再起動し、しばらく待機します。

• 次のトレース ファイルを収集します。

– file get activelog cm/trace/cdpmib/sdi コマンドを使用して Cisco CDP Agent のトレースをイネーブルにし、 file get activelog cm/trace/cdp/sdi コマンドを使用して Cisco CDP デーモンのトレースをイネーブルにします。

– [Real-Time Monitoring Tool（RTMT）] > [Trace & Log Central] > [Collect Files] > [Cisco CallManager SNMP Service] > [Cisco CDP Agent and Cisco CDP] を使用して、Cisco CDP Agent およびデーモンのトレースをイネーブルにします。

• ログが収集されたあと、 set trace disable cdpmib コマンドを使用してトレース設定をリセットします。

よくあるご質問

CDP インターフェイス テーブルおよび globalinfo テーブルが空白なのはなぜですか。

使用している Cisco UCM リリースにこの機能があることを確認します。ない場合は、アップグレードしてください。

インターフェイス テーブルに設定されている MessageInterval の値が、CDP MIB のグローバル テーブルにも設定されているのはなぜですか。

HoldTime 値が MessageInterval 値よりも大きいかどうかを確認します。小さい場合、インターフェイス テーブルとグローバル テーブルのどちらからも MessageInterval 値は設定されません。

ログの収集

次のログおよび情報を収集して分析します。コマンド file get activelog < paths in the following bullets > を実行します。

• SNMP Master Agent のパス：/platform/snmp/snmpdm/*

• システム アプリケーション エージェントのパス：/platform/snmp/sappagt/*

Cisco Unified Communications Manager 8.0 でのサーブレットの使用

SysAppl MIB には、インストールされて実行されているコンポーネントを一度に取得する方法が用意されています。SysAppl エージェントからは、アクティブまたは非アクティブなサービスのリストは提供されません。アプリケーションとサービスの実行中状態または実行中以外の状態だけ示すことができます。Web App サービス/サーブレットは、SysAppl MIB を使用して監視できません。8.0 システムには、次のサーブレットがあります。

• Cisco CallManager Admin

• Cisco CallManager Cisco IP Phone Services

• Cisco CallManager Personal Directory

• Cisco CallManager のサービスアビリティ

• Cisco CallManager のサービスアビリティ RTMT

• Cisco Dialed Number Analyzer

• Cisco エクステンション モビリティ

• Cisco エクステンション モビリティ アプリケーション

• Cisco RTMT Reporter Servlet

• Cisco Tomcat Stats Servlet

• Cisco Trace Collection Servlet

• Cisco AXL Web Service

• Cisco Unified Mobile Voice Access Service

• Cisco エクステンション モビリティ

• Cisco IP Manager Assistant

• Cisco WebDialer Web Service

• Cisco CAR Web Service

• Cisco Dialed Number Analyzer

システムの健全性のために重要なサービス ステータスを監視するには、次のアプローチを推奨します。

• GetServiceStatus という Cisco Unified Serviceability API を使用します。この API では、Web アプリケーション タイプと Web 以外のアプリケーション サービス両方のアクティベーション ステータスなど、完全なステータス情報が提供されます。（詳細については、『 AXL Serviceability API Guide 』を参照してください）。

• utils service list コマンドを使用して、さまざまなサービスのステータスをチェックします。

• syslog メッセージを使用して、servM で生成されたメッセージをモニタします。例：