web-dev-qa-db-ja.com

Snmpdアップデートインターフェイスカウンターが遅いか、このようなもの

Freebsdボックスの1つを9-stable（完全に新規インストール）に更新し、監視用にnet-snmpをインストールします。

uname -r 
9.1-PRERELEASE

pkg_info net-snmp-5.7.1_7 
Information for net-snmp-5.7.1_7:

Comment:
An extendable SNMP implementation
....


cat /var/db/ports/net-snmp/options 
# This file is auto-generated by 'make config'.
# Options for net-snmp-5.7.1_7
_OPTIONS_READ=net-snmp-5.7.1_7
_FILE_COMPLETE_OPTIONS_LIST= IPV6 MFD_REWRITES Perl PERL_EMBEDDED PYTHON DUMMY TKMIB DMALLOC MYSQL AX_SOCKONLY UNPRIVILEGED
OPTIONS_FILE_UNSET+=IPV6
OPTIONS_FILE_UNSET+=MFD_REWRITES
OPTIONS_FILE_SET+=Perl
OPTIONS_FILE_SET+=Perl_EMBEDDED
OPTIONS_FILE_UNSET+=PYTHON
OPTIONS_FILE_SET+=DUMMY
OPTIONS_FILE_UNSET+=TKMIB
OPTIONS_FILE_SET+=DMALLOC
OPTIONS_FILE_UNSET+=MYSQL
OPTIONS_FILE_UNSET+=AX_SOCKONLY
OPTIONS_FILE_UNSET+=UNPRIVILEGED

このマシンには約500のVLANがあり、snmpdを介してzabbixとcactiの2つの異なるソフトウェアへのインターフェイスに関する情報を収集します。

そして、それらは両方とも空白のフィールドでグラフをプロットします。

zabbixcacti

Zabbixのポーリング時間を15秒から30,60,90,120,10に変更してみました。そしてとにかく私は空白のフィールドを持っています。

snmpd.confは空です-アクセス制御のみです。

この設定はfreebsd8でうまく機能しました。

私のせいはどこですか？このグラフをどのように修正しますか？

UPD：プーリング時間を変更し、エージェントの1つをオフにしますが、役に立ちません。 zabbixログ（snmpdから受信したデータ）を見ると、次のことがわかります。ロシア語のロケールで申し訳ありません。数字を見てください。 zabbix data

私の「iftop」の表示速度は約90Mビットだったので、それは真実ではありませんが、snmpdは2Mビットを返します。

Snmpdは速度を返さず、カウンターだけを返すことを理解しています。しかし、それはどのように可能ですか？なぜ2Mbit/s？

64ビットカウンターを使用して、使用せずにsnmpdを再コンパイルしてみました。どちらのバリアントでも、この空白のフィールドが存在します。

だから私はそのOS（freebsd）がインターフェースカウンターをうまく更新しないと思います。

この要求/応答が見つかったため、まだtcpdumpを収集しています。しかし、多くのゴミに、それで問題があります。

UPD2：tcpdumpされたファイルを復号化し、これをgoogle docとして gdocfile で公開します。

Timediffは奇妙に見えます..zabbixのように、リクエストを「忘れる」ことがあり、その後、行で2回実行します。

UPD3：コマンドからログを解析します "while true; do netstat -bin -I vlan4008 >>/var/log/netstat; sleep 300; done" google docsとしてロードし、速度の式を追加します： link

OSのすべてのカウンターが良好なようです。今私は問題があると思います：1。zabbixは行で2回リクエストを取得します（そしてサボテンはどうですか）2。snmpduse counter32

monitoringfreebsdsnmpzabbixnet-snmp
4
Korjavin Ivan

これは通常、SNMP応答がタイムリーに受信されないことに関連しています。
SNMPはUDPを使用しているため、ネットワークの輻輳またはホストの輻輳が原因で要求/応答が失われる可能性がありますが、より一般的には、関係する2台のマシンの1つがタイムリーに要求を処理できませんでした。そして他のマシンは待つことにうんざりしました。

ワークロードに応じて、いずれかのマシンが遅れる可能性が高くなります-特定のホストにクエリを実行するSNMPエージェントが多数ある場合、一部のエージェントが期待するほどタイムリーに応答を処理できない可能性があります（これらのエージェントは空白で表示されます）グラフ内のスポット、または他のエラーを報告します）。
逆に、1つのエージェントが多数のホストにクエリを実行している場合（ポーリング間隔で処理できる以上）、ポーリング間隔中にクエリが実行されないマシンでは、グラフにギャップが生じます。 （この問題は、CactiのPHPポーラーで特に一般的であり、cactid（現在はspine）の開発につながります。これを使用することを強くお勧めします。まだ使用していません）。

これを修正するための私の一般的なアドバイス：

  1. 可能であれば、5分ごとにポーリングします。
    ほとんどの環境では、1/5/15/30/60/90/120秒のポーリング間隔は必要ありません。
    5分の粒度で十分な場合は、それを使用してください。サーバーの作業が減り、SNMP監視エージェントの作業が減り、保存するデータが減ります（または「完全な粒度」での期間が長くなります）。

  2. エージェントのSNMPタイムアウトを増やします。
    サーバーがリクエストに対応するための時間を増やします。 SNMPデーモンは、プロセスの怠惰な10代の若者です。月曜日に部屋を掃除する（またはツリーに相当するデータを提供する）ように依頼すると、水曜日または木曜日に靴下をいくつか拾った可能性があります。

  3. ポーリングごとにサーバーに要求する量を制限します。
    1つのカウンターだけが必要な場合は、インターフェイスMIB全体を要求しないでください。（通常）ツリーをウォークして完全な出力を生成するのに、1つのOIDを与えるよりも長い時間がかかります。

  4. データを要求するエージェントの数を制限します。
    モニタリングを1つのボックス（ZabbixまたはCacti）に統合できれば、サーバーへの要求が少なくなり、タイムリーに応答しない可能性が低くなります。

上記を試しても問題が解決しない場合は、最終的なデバッグ手順があります：ログをハントするおよびSNMPトラフィックをスニッフィングする。リクエストとレスポンスがタイムリーに行き来し、何らかの理由で不正な形式として失われたり拒否されたりしないようにしてください。多くの場合、ネットワーク上のデータを見ると、何が問題で、どのように修正するかがわかります。

4
voretaq7

どのバージョンのSNMPプロトコルを使用していますか？ SNMP v1は、64ビットカウンターをサポートしていません。これはCactiの古い問題であり、関連する「デバイス」で「バージョン2」に切り替えるだけです。

2
MrBr