Cisco Unified Communications Manager トラブ ルシューティング ガイド
SNMP の トラブルシューティング
SNMP のトラブルシューティング
発行日;2012/01/31 | 英語版ドキュメント(2010/02/24 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 4MB) | フィードバック

目次

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

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

CISCO-CCM-MIB のヒント

一般的なヒント

制限事項

よくあるご質問

HOST-RESOURCES-MIB のヒント

収集するログ

ディスク容量および RTMT

よくあるご質問

CISCO-CDP-MIB のヒント

一般的なヒント

よくあるご質問

SYSAPP-MIB のヒント

ログの収集

8.0 でのサーブレットの使用

SNMP 開発者のヒント

追加情報の参照先

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

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

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

「CISCO-CCM-MIB のヒント」

「HOST-RESOURCES-MIB のヒント」

「CISCO-CDP-MIB のヒント」

「SYSAPP-MIB のヒント」

「SNMP 開発者のヒント」

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

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

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

コミュニティ ストリングまたは SNMP ユーザがシステム上に適切に設定されていることを確認します。SNMP コミュニティ ストリングまたはユーザを設定するには、Cisco Unified Serviceability で [SNMP] > [V1/V2] > [Community String] または [SNMP] > [V3] > [User] を選択します。詳細については、『 Cisco Unified Serviceability Administration Guide 』を参照してください。

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

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


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


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

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

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

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

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

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

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

ccmPhoneFailedAlarmInterval(1.3.6.1.4.1.9.9.156.1.9.2)を 30-3600 に設定。CLI コマンド snmpset -c <コミュニティ ストリング> -v2c <トランスミッタ IP アドレス> 1.3.6.1.4.1.9.9.156.1.9.2.0 i <値> を使用できます。

ccmPhoneStatusUpdateAlarmInterval(1.3.6.1.4.1.9.9.156.1.9.4)を 30-3600 に設定。CLI コマンド snmpset -c <コミュニティ ストリング> -v2c <トランスミッタ IP アドレス> 1.3.6.1.4.1.9.9.156.1.9.4.0 i <値> を使用できます。

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

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

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

CISCO-CCM-MIB のヒント

この項は、次のトピックで構成されています。

「一般的なヒント」

「制限事項」

「よくあるご質問」

一般的なヒント

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

コマンド snmp walk -c <コミュニティ> -v2c <IP アドレス> 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 を使用)

SNMP パッケージのバージョン(CLI コマンド show packages active snmp を使用)

電話機の MMF Spy 出力(CLI コマンド show risdb query phone を使用)

トレース ログおよび MMFSpy データをその後の分析のために送信します。

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

 

表 9-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 CM の管理 から削除し、再登録します。

4. ccmPhoneFailed トラップが生成されることを確認します。

MediaResourceListExhausted

1. 標準の会議ブリッジ リソース(CFB-2)のいずれかを含む Media Resource Group(MRG; メディア リソース グループ)を作成します。

2. 作成した MRG を含む Media Resource Group List(MRGL; メディア リソース グループ リスト)を作成します。

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

4. IPVMS を停止します。これにより、会議ブリッジ リソース(CFB-2)は機能を停止します。

5. メディア リストを使用する電話機で電話会議を行うと、電話機の画面に「使用可能な会議ブリッジがありません(No Conference Bridge available)」が表示されます。

6. MediaListExhausted アラーム/アラート/トラップが生成されることを確認します。

RouteListExhausted

1. ゲートウェイを 1 つ含む Route Group(RG; ルート グループ)を作成します。

2. 作成した RG を含む Route Group List(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 < パス > 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 Communication 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 < コミュニティ ストリング > -v 2c < トランスミッタ IP アドレス > 1.3.6.1.4.1.9.9.156.1.9.2.0 i < >

snmpset -c < コミュニティ ストリング > -v 2c < トランスミッタ IP アドレス > 1.3.6.1.4.1.9.9.156.1.9.4.0 i < >

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

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

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

トラップがまだ生成されない場合は、対応するアラームが生成されるかどうかを確認します。これらのトラップはアラーム イベントに基づいて生成されるため、SNMP エージェントがこれらのアラーム イベントを取得していることを確認します。ローカル Syslog をイネーブルにします。Cisco UCM Serviceability のウィンドウ [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 < コミュニティ ストリング > -v 2c < トランスミッタ IP アドレス > 1.3.6.1.4.1.9.9.41.1.1.2.0 i < > とします。

clogMaxSeverity(1.3.6.1.4.1.9.9.41.1.1.3):どの重大度を超えるとトラップが必要となるかを設定します。デフォルト値は warning 5 )です。通知がイネーブルの場合、設定した重大度以下のアラーム重大度の syslog メッセージはすべてトラップとして送信されます。たとえば、 snmpset -c < コミュニティ ストリング > -v 2c < トランスミッタ IP アドレス > 1.3.6.1.4.1.9.9.41.1.1.3.0 i < > とします。

Cisco Unified Communication 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、

Cisco Unified Communication 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 トラップ

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

Media Resource Group List(MRGL; メディア リソース グループ リスト)を作成し、作成した MRG が含まれるようにします。

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

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

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

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

RouteListExhausted トラップ

Route Group(RG; ルート グループ)を作成し、ゲートウェイが 1 つ含まれるようにします。

Route Group List(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-TimeMonitoringTool(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 を使用します。

この項は、次のトピックで構成されています。

「収集するログ」

「ディスク容量および RTMT」

「よくあるご質問」

収集するログ

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

hostagt ログ ファイル( file get activelog /platform/snmp/hostagt/ コマンドを実行)

syslog ファイル( file get activelog /syslog/ コマンドを実行)

Master SNMP Agent ログ ファイル( file get activelog /platform/snmp/snmpdm/ コマンドを実行)

実行された操作の順序

ディスク容量および RTMT

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

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

Host Resources MIB の場合、使用済みディスク容量の値は [hrStorageUsed/hrStorageSize] * 100 で計算され、hrStorageSize には minfree は含まれません。

よくあるご質問

HOST-RESOURCES-MIB はプロセスの監視に使用できますか。

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

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

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

 

表 9-2 メモリ使用率の値

メモリ使用率
RTMT カウンタ
HOST-RESOURCES-MIB

SWAP メモリ使用率

Memory\Used Swap Kbytes

hrStorageUsed.2(説明は virtual memory)

物理メモリ使用率

Memory\Used Kbytes

hrStorageUsed.1(説明は Physical RAM)

合計メモリ(物理 + スワップ)使用率

Memory\Used VM Kbytes

同等のものはありません。基本的には、hrStorageUsed.2 と hrStorageUsed.1 を加算する必要があります。

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

物理メモリの hrStorageUsed では、データは使用済み(バッファ + キャッシュ)という観点で表示されます。

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

HOST RESOURCES MIB の場合、次の公式が使用されます。

%Physical memory usage = (Physical RAM hrStorageUsed + /dev/shm hrStorageUsed) / (Physical RAM hrStorageSize)

%VM used = (Physical RAM hrStorageUsed + /dev/shm hrStorageUsed + Virtual Memory hrStorageUsed) / (Physical RAM hrStorageSize + Virtual Memory hrStorageSize)

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

一般的に、df サイズは表示される使用済みおよび使用可能なディスク容量データと一致しません。これは、予約済みのファイル システム ディスク ブロックの minfree パーセンテージのために発生します。リリース 6.x および 7.0 の Cisco Unified Communication 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 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 を使用します。

予約済みのファイル システム ディスク ブロックの minfree パーセンテージにより、HOST-RESOURCES-MIB によって表示される使用済みおよび使用可能なディスク容量の値は、RTMT によって表示されるディスク容量の値と一致しない場合があります。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 は含まれません。

CISCO-CDP-MIB のヒント

この項は、次のトピックで構成されています。

「一般的なヒント」

「よくあるご質問」

一般的なヒント

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

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 リリースにこの機能があることを確認します。機能がない場合は、アップグレードします。

CDP MIB のインターフェイス テーブルおよびグローバル テーブルで MessageInterval 値はどのように設定されますか。

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

SYSAPP-MIB のヒント

この項は、次のトピックで構成されています。

「ログの収集」

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

ログの収集

次のログおよび情報を分析用に収集します。コマンド file get activelog < 次の項目のパス > を実行します。

SNMP Master Agent のパス:/platform/snmp/snmpdm/*

System Application Agent のパス:/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 Serviceability

Cisco CallManager Serviceability RTMT

Cisco Dialed Number Analyzer

Cisco Extension Mobility

Cisco Extension Mobility Application

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 Serviceability 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-MIB に記述されているように、ccmPhoneDevicePoolIndex はサポートされていないため 0 が返されます。Cisco UCM デバイス登録アラームには、現在はデバイス プール情報は含まれていません。

Cisco UCM SNMP Service が実行中でない場合、MIB の次のテーブルだけが応答します。

ccmGroupTable

ccmRegionTable

ccmRegionPairTable

ccmDevicePoolTable

ccmProductTypeTable

ccmQualityReportAlarmConfigInfo

ccmGlobalInfo

Cisco UCM SNMP Service を実行中にするには、Cisco Unified Serviceability でサービスをアクティブにして起動します。

SYS-APPL MIB の SysApplInstallPkgTable を照会して、システムにインストールされている Cisco Unified Communications Manager アプリケーションのインベントリを取得します。SYS-APPL MIB の SysApplRunTable を照会して、システムで実行されている Cisco Unified Communications Manager アプリケーションのインベントリを取得します。System Application Agent はアクティブおよび非アクティブなサービスの表示または Web App サービスまたはサーブレットの監視はできないため、このアプローチを使用して Cisco Unified Communications Manager アプリケーションのシステムの健全性およびサービス ステータスを監視します。

getservicestatus という Cisco Unified Serviceability 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 Services、Cisco UCM Personal Directory、Cisco Unified Serviceability、Cisco Unified RTMT、Cisco Extension Mobility、Cisco Extension Mobility Application、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(SNMP V1 の場合)または GENERIC ERROR(SNMP V2c または V3 の場合)が表示されることがあります。タイムアウトは、Cisco Unified Communications Manager 処理エンジンを保護するために拡張機能を制御した結果として発生する可能性があります。


) スカラ オブジェクトを使用して CCMH323DeviceTable および ccmSIPDeviceTable 内のエントリ数を取得できます。その結果、SNMP Manager(クライアント)は、エントリが存在しない場合にこれらのテーブルでの不要な get/getnext 操作を回避できます。


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

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

単一の要求内で照会される変数の数を減らします。たとえば、空のテーブルについて、管理アプリケーションのタイムアウトが 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」の章