サポートセンターホーム


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

概要

ほとんどのLinuxホストの場合、監視に必要なのは、コレクターマシンからSNMPとNTPにアクセスできるようにすることだけです。 ホストでSNMPデータソースのデータを取得していない場合は、トラブルシューティング項目のリストをまとめて確認します。

一般的なトラブルシューティング

次の基本的なチェックから始めます。

  • SNMPdは実行されていますか?
  • SNMPv1またはv2を使用している場合:デバイスは 正しいコミュニティ文字列 LogicMonitor(グローバル、グループ、またはデバイスレベルのいずれか)で? コミュニティ文字列が設定されていない場合、LogicMonitorはデフォルトでpublicを使用します。 注:一部のLinuxディストリビューションでは、コミュニティ文字列が「public」に設定されている場合に公開されるメトリックが大幅に制限されています。 したがって、コミュニティ文字列を別のものに設定することをお勧めします。 以下のセクションを参照してください デバイスに正しいコミュニティ文字列が設定されていることを確認します.
  • SNMPv3を使用している場合: 正しいauthpass、privpass、およびusernameで構成されたデバイス (グローバル、グループ、またはデバイスレベルのいずれかで)? 以下のセクションを参照して、デバイスを確認してください 正しいv3資格情報が設定されている.
  • コレクターデバイスからのクエリは監視対象デバイスに到達できますか? これは、監視対象のホストでtcpdumpを実行することで確認できます。 クエリがデバイスに到達しない場合は、ファイアウォールの問題がある可能性があります。
  • 監視対象のデバイスはコレクターからのクエリに応答していますか?

クエリがホストに到達しているが、ホストが応答していない場合は、次のことを確認してください。

  • snmpd.confのアクセス制限により、コレクターからのクエリが許可されないか、コミュニティストリングが間違っている可能性があります。
    • 最も単純なSNMPdv1 / v2構成は、次のXNUMX行です。 rocommunity [コミュニティ]
    • 設定ファイルの内容を変更した後、SNMPdを再起動する必要があることに注意してください。 (/etc/init.d/snmpd restart)
  • SNMPdは、ループバックアドレスでのみリッスンしている可能性があります。
    • DebianとRedhatの一部のディストリビューションでは、デフォルトでSNMPdは127.0.0.1でのみリッスンします。 / etc / default / snmpdまたは/etc/syconfig/snmpd.optionsでこれを修正し、SNMPdを再起動できます。
    • 次の行が表示されている場合:agentAddress udp:127.0.0.1:161は、ホストがSNMPクエリのループバックアドレスのみをリッスンしていることを意味します。 その行にコメントしてください。
  • IPアクセス制限により、SNMP要求の受け入れがブロックされている可能性があります。
    • /etc/hosts.allowは、SNMPが応答するIPアドレスを制限している可能性があります(「接続が拒否されました」に関するsyslogメッセージが表示されます)。 ファイルが存在する場合は、SNMPアクセス用にコレクターがこのファイルにリストされていることを確認してください。
    • IPTablesルール コレクターからのSNMPパケットの受信を妨げている可能性があります。

辞書式順序の問題:

  • 「エージェントが辞書式順序で変数バインディングを返しませんでした」という一般的なエラーメッセージが表示される場合は、 snmp.ignore.lexicographic.order コレクター設定をTRUEに設定します。 で説明したように コレクター構成ファイルの編集、この設定は、コレクターのagent.confファイルから更新する必要があります。

LogicMonitorでのSNMP資格情報の検証

他のパスワードと同様に、LogicMonitor内でsnmp v1 / v2コミュニティ文字列、v3認証トークン、v3プライバシートークン、またはv3ユーザー名をクリアテキストで表示することはできません。

次の手順は、これらの値を検証する方法を提供します。

  1. 案内する 設定| コレクター| コレクターの管理| デバッグコマンドを実行する| サポート.
  2. デバッグウィンドウで、下部に次のコマンドを入力します。!snmpgetあなたのホスト名> .1.3.6.1.2.1.1.2.0
    • ホスト名は、IPアドレスまたはDNS名のいずれかである必要があります。 表示名は使用しないでください。
    • .1.3.6.1.2.1.1.2.0は、コレクターがホストからデータを収集できるようにSNMPが構成されている場合に、すべてのSNMPデバイスが返すシステムオブジェクトID(OID)です。
    • 特にコミュニティ文字列が不正確で、システムがタイムアウトするまで待機する必要がある場合、結果が表示されるまでに60秒以上かかる場合があります。
  3. コレクタデバッグウィンドウは、デバイスグループからの継承を通じて直接、またはグローバルレベルで、デバイスに現在適用されているコミュニティ文字列またはauthpass、privpass、およびusernameを使用します。 コミュニティ文字列が設定されていない場合、LogicMonitorはデフォルトでpublicを使用します。

    SNMPv1およびv2

    SNMPv1またはv2を使用していて、デバイスに正しいコミュニティ文字列がある場合は、SysObjectIDに値が返されるはずです。

    SNMPv1およびv2

    SNMPv1またはv2を使用していて、間違ったコミュニティストリングが使用されている場合は、次のエラーが表示されます。

    LogicMonitorがデバイスに使用しているコミュニティ文字列は、デバッグコマンドウィンドウで指定することで上書きできます。


    !snmpget community=<your_community_string> <your.hostname> .1.3.6.1.2.1.1.2.0.

    以前に失敗したコミュニティストリングを指定したときにこのコマンドが成功した場合、LogicMonitorではこのホストに間違ったコミュニティストリングが設定されています。 これがどこに設定されているかを判断する必要があります。ホストから始めて、グローバル設定のメンバーであるホストグループを介して作業を進めます。 見る デバイスのプロパティと認証資格情報の定義 詳細については。 ホストレベルでのプロパティの設定は、グループレベルで設定された同じプロパティよりも優先されます。

    適切なsnmp.communityエントリを編集し、正しい値を指定します。 次に、デバッグコマンドを繰り返すことにより、変更によって正しい値が設定されたことを確認できます。!snmpget .1.3.6.1.2.1.1.2.0。

    注意: コミュニティ値がグループまたはグローバルレベルで設定されていて、グループ内の他のSNMPホストがデータを返している場合は、グループまたはグローバルプロパティを変更しないでください。 特定のホストにsnmp.communityプロパティを設定するか、ホストのsnmpd.confファイルを変更して、他のホストと同じコミュニティ文字列を使用します。

    上記のdebugコマンドが値を正常に返したが、ホスト上の他のSNMPデータソースが値を返さない場合、ホストのsnmpd.confファイルがコレクターが表示できるOIDを制限している可能性があります。 コミュニティ文字列を定義する行がないかファイルを確認してください。 許可された収集IPまたは範囲の後の値は、以下の例のように、公開されたOIDをOIDツリーのそのセクションに制限します。

    基本的なシステム情報(説明、オブジェクトID、稼働時間、連絡先情報など)のみに制限されます。

     rocommunity <community_string> <collector.ip/range> .1.3.6.1.2.1.1

    
制限なし:

     rocommunity <community_string> <collector.ip/range> A restriction to .1 is in effect no restriction.

    SNMPv3

    SNMPv3を使用していて、デバイスに正しい資格情報が設定されている場合、SysOIDが返されます。

    SNMPv3

    認証情報が正しくない場合、リクエストはタイムアウトになります。  

    見る このページ デバイスのSNMPv3資格情報の設定については。

記事上で