Cisco Unified Communications Manager トラブルシューティング ガイド リリース 9.0(1)
SNMP のトラブルシューティング
SNMP のトラブルシューティング
発行日;2012/11/25   |   ドキュメントご利用ガイド   |   ダウンロード ;   この章 pdf   ,   ドキュメント全体 pdf    |   フィードバック

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

この章では、SNMP のトラブルシューティングで使用する情報について説明します。

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

トラブルシューティングのヒントについては、この項を参照してください。

  • 『Cisco Unified Serviceability Administration Guide』の「SNMP Services」にリストされているすべての機能およびネットワーク サービスが実行されていることを確認します。
  • コミュニティ ストリングまたは SNMP ユーザがシステム上に適切に設定されていることを確認します。 SNMP コミュニティ ストリングまたはユーザを設定するには、Cisco Unified サービスアビリティ[SNMP] > [V1/V2] > [コミュニティ ストリング(Community String)]、または [SNMP] > [V3] > [ユーザ(User)] を選択します。 詳細については、『Cisco Unified Communications Manager Administration Guide』を参照してください。

システムから MIB をポーリングできない

この状態は、コミュニティ ストリングまたは SNMP ユーザがシステム上に設定されていないか、システム上に設定されているものと一致しないことを意味します。


(注)  


デフォルトでは、コミュニティ ストリングまたはユーザはシステム上に設定されていません。


SNMP の設定ウィンドウを使用して、コミュニティ ストリングまたは SNMP ユーザがシステム上に適切に設定されているかどうかを確認します。

システムから通知を受信できない

この状態は、通知の宛先がシステム上に正しく設定されていないことを意味します。

[通知先(Notification Destination)](V1/V2c または V3)設定ウィンドウで、通知の宛先を正しく設定したことを確認します。

Cisco Unified Communications Manager ノードから SNMP トラップを受信できない

この状態は、Cisco Unified Communications Manager ノードからの SNMP トラップを確認できないことを意味します。

電話機の登録/登録解除/障害に関連する次の MIB オブジェクト ID(OID)を次の値に設定したことを確認します(どちらの値もデフォルトは 0 です)。

  • ccmPhoneFailedAlarmInterval(1.3.6.1.4.1. 9.9.156.1.9.2)が 30 ~ 3600 に設定されていること。 次の CLI コマンドを使用できます。snmpset -c <community string> -v2c <transmitter ipaddress> 1.3.6.1.4.1.9.9.156.1.9.2.0 i <value>
  • ccmPhoneStatusUpdateAlarmInterval(1.3.6.1.4.1.9.9.156.1.9.4)が 30 ~ 3600 に設定されていること。 次の CLI コマンドを使用できます。snmpset -c <community string> -v2c <transmitter ipaddress> 1.3.6.1.4.1.9.9.156.1.9.4.0 i <value>

『Cisco Unified Serviceability Administration Guide』の「SNMP Services」にリストされているすべての機能およびネットワーク サービスが実行されていることを確認します。

[通知先(Notification Destination)](V1/V2c または V3)設定ウィンドウで、通知の宛先を正しく設定したことを確認します。

[コミュニティ ストリング(Community String)](V1/V2c)または [ユーザ(User)](V3)設定ウィンドウで、コミュニティ ストリング/ユーザ特権(通知の権限を含む)を正しく設定したことを確認します。

CISCO-CCM-MIB のヒント

ここでは、CISCO-CCM-MIB に関するヒントを示します。

一般的なヒント

  • 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 データを詳細な分析に送ります。

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

表 1 CISCO-CCM-MIB SNMP トラップのチェック方法

トラップ

確認手順

ccmPhoneStatusUpdate

  1. CiscoSyslog->dogBasic MIB テーブルで MaxSeverity=Info を設定します。
  2. ccmAlarmConfigInfo MIB テーブルで PhoneStatusUpdateAlarmInterv に 30 以上を設定します。
  3. 電話機の登録先の Cisco Unified Communications Manager サーバを接続解除します。
  4. 電話機が登録解除されます。
  5. Cisco Unified Communications Manager サーバを再接続します。
  6. 電話機が再登録されます。
  7. ccmPhoneStatusUpdate トラップが生成されることを確認します。

ccmPhoneFailed

  1. CiscoSyslog->clogBasic MIB テーブルで MaxSeverity=Info を設定します。
  2. ccmAlarmConfigInfo MIB テーブルで PhoneFailedAlarmInterv に 30 以上を設定します。
  3. 電話機が機能しないようにします。 電話機を Cisco Unified Communications Manager の管理から削除し、再登録します。
  4. ccmPhoneFailed トラップが生成されることを確認します。

MediaResourceListExhausted

  1. 標準の会議ブリッジ リソース(CFB-2)のいずれかを含むメディア リソース グループ(MRG)を作成します。
  2. 作成した MRG を含むメディア リソース グループ リスト(MRGL)を作成します。
  3. 電話機設定のウィンドウ(実際の電話機の)で、電話機のメディア リソース グループ リストとして MRGL を設定します。
  4. IPVMS を停止します。これにより、会議ブリッジ リソース(CFB-2)が動作を停止します。
  5. メディア リストを使用する電話機で電話会議を行うと、電話機の画面に「使用可能な会議ブリッジがありません(No Conference Bridge available)」と表示されます。
  6. MediaListExhausted アラーム/アラート/トラップが生成されることを確認します。

RouteListExhausted

  1. ゲートウェイを 1 つ含むルート グループ(RG)を作成します。
  2. 作成した RG を含むルート グループ リスト(RGL)を作成します。
  3. 9XXXX のコールを RGL 経由でルーティングするルート パターン(9.XXXX)を作成します。
  4. ゲートウェイの登録を解除します。
  5. 電話機の 1 つで 9XXXX にダイヤルします。
  6. RouteListExhausted アラーム/アラート/トラップが生成されることを確認します。

MaliciousCallFailed

  1. ソフトキー テンプレートを作成します。 テンプレートで、電話機のさまざまな状態に [迷惑呼(MaliciousCall)] ソフトキーを追加します。
  2. 新しいソフトキー テンプレートを実際の電話機に割り当てて、電話機をリセットします。
  3. 電話をかけ、コール中およびコール後に電話機の画面で [迷惑呼(MaliciousCall)] ソフトキーを選択します。
  4. 「MaliciousCallFailed」アラーム/アラート/トラップが生成されることを確認します。

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

  • /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 で多数の getbulk を実行しないようにします。 このようなシナリオでは、更新が発生すると常に 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 サービスアビリティの 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 トラップ通知をイネーブルにするには、これを true1)に設定します。 デフォルト値は false2)です。 例: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):トラップを受け取る最低の重大度レベルを設定します。 デフォルト値は warning5)です。 通知がイネーブルの場合、設定した重大度以下のアラーム重大度の 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 に電話機を接続します。 電話機ステータスは不明のままです。 次のメッセージが表示されます。
      2007-10-31:2007-10-31 14:53:40 Local7.Debug 172.19.240.221 community=public, enterprise=1.3.6.1.4.1.9.9.156.2.0.2, enterprise_mib_name=ccmPhoneFailed, uptime=7988879, agent_ip=128.107.143.68, version=Ver2, ccmAlarmSeverity=error, ccmPhoneFailures=1.
      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 サービスアビリティで、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 Communications Manager の管理から削除した場合でも、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 サービスアビリティで、[アラーム(Alarm)] > [設定(Configuration)] を選択します。 サーバを選択します。次に、[移動(Go)] をクリックします。 サービス グループの [CM サービス(CM Services)] を選択します。次に、[移動(Go)] をクリックします。 サービスの [Cisco CallManager] を選択します。次に、[移動(Go)] をクリックします。
  2. [ローカル Syslog(Local Syslog)]、[SDI トレース(SDI Trace)]、および [SDL トレース(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 デバイス登録アラームには、現在はデバイス プール情報は含まれていません。

HOST-RESOURCES-MIB のヒント

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

収集するログ

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

  • 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 の報告値を使用して使用済みディスク容量の値が表示されます。この値は、[(合計容量 - 使用可能容量) / 合計容量] X 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 にどのようにマッピングされますか。

次の表に、メモリ使用率の値を示します。

表 2 メモリ使用率の値

メモリ使用率

RTMT カウンタ

HOST-RESOURCES-MIB

スワップ メモリの使用率

メモリ\使用されているスワップのキロバイト数

hrStorageUsed.2(説明は仮想メモリ)

物理メモリの使用率

メモリ\使用されているキロバイト数

hrStorageUsed.1(この説明は物理 RAM になっています)

物理メモリとスワップ メモリの使用率の合計

メモリ\使用されている仮想メモリのキロバイト数

実際の値ではありません。 基本的には、hrStorageUsed.2 と hrStorageUsed.1 を足し合わせる必要があります。

使用率の低いサーバではスワップ メモリを使用できないため、HR 仮想メモリによって 0 が返される場合があります。 HR 仮想メモリが正しく返されていることを確認するには、値を RTMT の Memory\Used Swap KBytes と比較する必要があります。 RTMT と HR では、「仮想メモリ」という用語の使用法が異なります。 物理メモリの hrStorageUsed では、データは使用済み(バッファ + キャッシュ)という観点で表示されます。

物理メモリの hrStorageUsed は、使用済みに関するデータ(バッファ + キャッシュ)を示します。

HOST-RESOURCES-MIB によって示される共有メモリ情報は、::hrStorageDescr.10 = STRING: /dev/shm です。 HOST-RESOURCES-MIB によって報告される仮想メモリは、RTMT ではスワップ メモリと見なされるもので構成されます。

HOST RESOURCES MIB の場合、次の公式が使用されます。
  • %物理メモリ使用率 =(物理 RAM の hrStorageUsed + /dev/shm の hrStorageUsed)/(物理 RAM の hrStorageSize)
  • %使用されている仮想メモリ = (物理 RAM の hrStorageUsed + /dev/shm hrStorageUsed + 仮想メモリの hrStorageUsed) / (物理 RAM の hrStorageSize + 仮想メモリの hrStorageSize)

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

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

RTMT では、使用済みディスク容量の値は df 報告値から表示されます。[(合計容量 - 使用可能容量) / 合計容量] X 100 であり、合計容量には minfree も含まれます。 HOST-RESOURCES-MIB の場合、これは [hrStorageUsed/hrStorageSize] X 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 コマンドを使用することで、物理 RAM の合計メモリは 4090068K として表示されます。

物理 RAM ストレージ タイプの hrStorageUnits が 4096 バイトの場合、物理 RAM の hrStorageSize は 1022517 として表示されます。これは 4090078K [(1022517 X 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 の報告値を使用して使用済みディスク容量の値が表示されます。この値は、[(合計容量 - 使用可能容量) / 合計容量] X 100 で計算されます。合計容量には最小空き容量も含まれます。
  • HOST-RESOURCES-MIB での使用済みディスク容量の値は [hrStorageUsed / hrStorageSize] X 100 で計算されます。hrStorageSize には最小空き容量は含まれません。

CISCO-CDP-MIB のヒント

この項では、次のトピックを扱います。

一般的なヒント

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

  • set trace enable Detailed cdpmib コマンドを使用して、cdpAgt () の詳細トレースを設定します。
  • [Cisco Unified サービスアビリティ(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 および Cisco CDP(Cisco CDP Agent and Cisco CDP)] を使用して、Cisco CDP Agent およびデーモンのトレースをイネーブルにします。
  • ログが収集されたあと、set trace disable cdpmib コマンドを使用してトレース設定をリセットします。

よくあるご質問

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

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

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

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

SYSAPP-MIB のヒント

ここでは、SYSAPP-MIB のヒントについて説明します。

ログの収集

次のログおよび情報を収集して分析します。 コマンド 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 サービス
  • Cisco CallManager Personal Directory
  • Cisco CallManager のサービスアビリティ
  • Cisco CallManager のサービスアビリティ RTMT
  • Cisco Dialed Number Analyzer
  • Cisco Extension Mobility
  • Cisco Extension Mobility アプリケーション
  • Cisco RTMT Reporter Servlet
  • Cisco Tomcat Stats Servlet
  • Cisco Trace Collection Servlet
  • Cisco AXL Web Service
  • Cisco Unified Mobile Voice Access Service
  • Cisco Extension Mobility
  • Cisco IP Manager Assistant
  • Cisco WebDialer Web Service
  • Cisco CAR Web Service
  • Cisco Dialed Number Analyzer

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

  • GetServiceStatus という Cisco Unified サービスアビリティ API を使用します。 この API では、Web アプリケーション タイプと Web 以外のアプリケーション サービス両方のアクティベーション ステータスなど、完全なステータス情報が提供されます。 (詳細については、『AXL Serviceability API Guide』を参照してください)。
  • utils service list コマンドを使用して、さまざまなサービスのステータスをチェックします。
  • syslog メッセージを使用して、servM で生成されたメッセージをモニタします。 次に例を示します。
    Mar 18 16:40:52 ciscart26 local7 6 : 92: Mar 18 11:10:52.630 UTC : %CCM_SERVICEMANAGER-SERVICEMANAGER-6-ServiceActivated: Service Activated. Service Name:Cisco CallManager SNMP Service App ID:Cisco Service Manager Cluster ID: Node ID:ciscart26

SNMP 開発者のヒント

SNMP 開発者のトラブルシューティングのヒントについて、この項を確認してください。

  • CISCO-CCM-MIB のサポート リストについては、次のリンクで CISCO-CCM-CAPABILITY-MIB を参照してください。 http:/​/​tools.cisco.com/​Support/​SNMP/​do/​BrowseMIB.do?local=en&step=2&mibName=CISCO-CCM-CAPABILITY CISCO-CCM-CAPABILITY 「CISCO-CCM-CAPABILITY-MIB」で説明されているとおり、ccmPhoneDevicePoolIndex はサポートされていないため、0 を返します。 Cisco UCM デバイス登録アラームには、現在はデバイス プール情報は含まれていません。
  • Cisco UCM SNMP Service が実行中でない場合、MIB の次のテーブルだけが応答します。
    • ccmGroupTable
    • ccmRegionTable
    • ccmRegionPairTable
    • ccmDevicePoolTable
    • ccmProductTypeTable
    • ccmQualityReportAlarmConfigInfo
    • ccmGlobalInfo Cisco UCM SNMP Service を実行中にするには、Cisco Unified サービスアビリティでサービスをアクティブにして起動します。
  • SYS-APPL MIB の SysApplInstallPkgTable を照会して、システムにインストールされている Cisco Unified Communications Manager アプリケーションのインベントリを取得します。 SYS-APPL MIB の SysApplRunTable を照会して、システムで実行されている Cisco Unified Communications Manager アプリケーションのインベントリを取得します。 システム アプリケーション エージェントでは、アクティブまたは非アクティブになっているサービスを表示したり、Web アプリケーションのサービスやサーブレットをモニタしたりすることができないため、システムの健全性や Cisco Unified Communications Manager アプリケーションのサービス ステータスをモニタするには、次の方法を使用します。
    • getservicestatus という Cisco Unified サービスアビリティ API を使用して、Web アプリケーションと Web 以外のアプリケーションの両方について、アクティベーション ステータスなどの完全なステータス情報を提供します。 詳細については、『AXL Serviceability API Guide』を参照してください。
    • CLI コマンド utils service list を使用して、サービス ステータスを確認します。
    • syslog を使用して、servM で生成されたメッセージをモニタします(次の例を参照)。
      Mar 18 16:40:52 ciscart26 local7 6 : 92: Mar 18 11:10:52.630 UTC :  %CCM_SERVICEMANAGER-SERVICEMANAGER-6-ServiceActivated: Service Activated. Service Name:Cisco CallManager SNMP Service App ID:Cisco Service Manager Cluster ID: Node ID:ciscart26

(注)  


Cisco Unified Communications Manager が使用する Web アプリケーション サービスおよびサーブレットは次のとおりです。Cisco UCM Admin、Cisco UCM Cisco IP Phone サービス、Cisco UCM Personal Directory、Cisco Unified サービスアビリティ、Cisco Unified RTMT、Cisco Extension Mobility、Cisco Extension Mobility アプリケーション、Cisco Unified RTMT Reporter Servlet、Cisco Tomcat Stats Servlet、Cisco Trace Collection Servlet、Cisco AXL Web Service、Cisco Unified Mobile Voice Access Service、Cisco Extension Mobility、Cisco IP Manager Assistant、Cisco WebDialer Web Service、Cisco CAR Web Service、および Cisco Dialed Number Analyzer。


要求タイムアウトの回避策

SNMP 要求で複数の OID を指定し、変数が空のテーブルを指している場合、タイムアウトの問題により、NO_SUCH_NAME(SNMPv1 の場合)または GENERIC ERROR(SNMPv2c または SNMPv3 の場合)が返されることがあります。 Cisco Unified Communications Manager 処理エンジンを保護するために制御を強化すると、タイムアウトが発生することがあります。


(注)  


スカラ オブジェクトを使用すると、CCMH323DeviceTable および ccmSIPDeviceTable のエントリ数を取得できます。そのため、SNMP マネージャ(クライアント)は、エントリが存在しない場合に、これらのテーブルでの不要な get/getnext オペレーションをしなくて済みます。


SNMP 開発者は、この問題に対する次の回避策を使用できます。

  • 最初に、テーブルにアクセスする前に利用可能なスカラ変数(1.3.6.1.4.1.9.9.156.1.5)を使用してテーブル サイズを判別するか、目的のテーブルで get 操作を実行してから、空ではないテーブルを照会します。
  • 1 回の要求で照会する変数の数を減らします。たとえば、空のテーブルに対して管理アプリケーションのタイムアウトが 3 秒に設定されている場合、OID を 1 つだけ指定します。 (空でないテーブルの場合、1 つのデータ行の取得に 1 秒かかります)。
  • 応答タイムアウトの値を大きくします。
  • 再試行回数を減らします。
  • getbulk SNMP API を使用しないようにします。 getbulk API では MaxRepetitions で指定されているレコード数が取得されるため、次のオブジェクトがテーブルまたは MIB の範囲外であっても、それらのオブジェクトが取得されます。 空のテーブルの場合は、さらに遅延が大きくなります。 テーブルが空でなく、レコード数が既知の場合は、getbulk API を使用します。 このような場合には、MaxRepetitions を 5 秒に設定し、5 秒以内の応答を要求します。
  • 既存の制限に適合させるには、SNMP 照会を作成します。
  • 多数の電話機が Cisco UCM に登録されている場合は、複数の getbulk を実行して PhoneTable を定期的にウォークしないようにします。 電話機の更新が存在する場合に更新を行う ccmPhoneStatusUpdateTable を使用すると、PhoneTable をウォークするかどうかを決定できます。

詳細情報の入手先

関連資料

  • 『Command Line Interface Reference Guide for Cisco Unified Solutions』
  • 『Cisco Unified Serviceability Administration Guide』の「SNMP」の章