Simple Network Management Protocol（SNMP）は、監視対象のデバイスと監視システムが、異なるオペレーティングシステムを実行している場合でも、すべて話すことができる標準のメッセージ形式を提供します。 SNMPは、最も広く展開されている管理プロトコルです。 理解しやすく（常に使用するとは限りませんが）、ユビキタスなサポートを享受しています。
次のeBookは、SNMPと一般的に使用されるXNUMXつのバージョンのデコードに役立ち、使用される一般的な頭字語を定義し、SNMPの構成と監視のベストプラクティスを示しています。
SNMPとは何ですか？
SNMP は Simple Network Management Protocol の略です。 実生活では、多くの場合単純ではありません。 ネットワーク デバイスだけに適用されるわけではありません。 多くの場合、デバイスの管理には使用できず、監視のみに使用されます。 ただし、これは間違いなくプロトコルです。
SNMP は Simple Network Management Protocol の略です。 SNMP は、監視対象のデバイスと監視システムが異なるオペレーティング システムを実行している場合でも、すべて話すことができる標準メッセージ形式を提供します。
SNMP は主に、CPU 負荷、メモリ使用量などのデバイスに関するデータの収集に使用されます。SNMP は、実質的にすべてのネットワーク機器 (スイッチ、ルーター、ロード バランサーなど) でサポートされていますが、ほとんどのサーバー オペレーティング システムでもサポートされています。一部のストレージ デバイス、さらには一部のサーバー アプリケーション ソフトウェア。 ただし、SNMP の「サポート」が実際に意味する範囲は大きく異なる可能性がありますが、それについては後で詳しく説明します。
これを読んでいるあなたは、おそらく IT インフラストラクチャのパフォーマンス、可用性、およびキャパシティに責任を負っています。 (ニューメキシコ州警察の完全なガイドだと思ってこれを読んでいる場合、これはあなた向けではありません。) 可用性が重要な量の IT インフラストラクチャがある場合は、収入を生み出したり、他の人が仕事をできるようにしたりする場合、インフラストラクチャが機能していることを確認し、適切に機能する方法が必要です。 眠りたい場合は、一晩中起きてコマンド ライン ツール top の出力を見てサーバー上のプロセスを監視する代わりの方法が必要です。 特に、1000 台のサーバーと 100 台のルーターがある場合。
これを解決する標準的な方法は、監視システムを実行することです。監視システムは、サーバー、ルーター、スイッチ、およびその他のデバイスにクエリを実行し、それらがどのように動作しているかを尋ね、アラートを生成します (電子メール、テキスト、または音声通話で受け取ることができます)。それらのいずれかがうまくいっていないと報告した場合。 (これは、母親が妹に電話して様子を見てから、悪い知らせを伝えるのと同じようなものです。)
SNMPは、監視システム、ルーター、スイッチ、サーバー、ストレージアレイ、UPSデバイスなどが、異なるオペレーティングシステムを実行している場合でも、すべて話すことができる標準のメッセージ形式を提供します。 もちろん、SNMPにはさまざまなバージョンがあり、さまざまなセキュリティの問題があり、さまざまなデバイスが報告できるさまざまな種類の情報があります。
しかし、インフラストラクチャのパフォーマンス、可用性、容量を確保する責任がある場合は、SNMP と監視システムを有効にして使用し、データを収集してアラートを出すことが最善の方法です。 このシステムは、XNUMX 台のデバイスの監視から数万台のデバイスの監視に拡張でき、何か問題が発生したときに警告を発します (そして、うまくいけば、すべてが正常なときにスリープ状態になります)。
SNMP エージェントとネットワーク管理ステーションの仕組み
SNMPに関する議論には、多くの場合、SNMPエージェントとネットワーク管理ステーションのXNUMXつの概念が含まれます。 簡単に言うと、ネットワーク管理ステーション（NMS）が質問をします。 SNMPエージェントがそれらに応答します。
SNMP エージェントは、SNMP クエリを受信し、要求されたデータを取得して返信するソフトウェア プロセスです。 完全なオペレーティング システムを持たないほとんどのルーター、スイッチ、ファイアウォール、およびその他のシステムには、SNMP サポートがソフトウェアに組み込まれています。 汎用サーバー (Linux、Solaris、AIX、Windows、FreeBSD など) には、選択したインストール オプションによっては、デフォルトで SNMP エージェントがインストールされていない場合がありますが、いつでも追加できます。 Linux および Unix ベースのシステムで最も一般的な SNMP エージェントは、snmpd (SNMP デーモン) として実行される net-snmp エージェントです。このエージェントをインストール、構成、および実行すると、それをサポートするシステムに SNMP サポートが追加されます。
ネットワーク管理ステーションを突き止めるのはより困難です。 デバイスに対してアドホックなコマンド ライン クエリを実行するために使用される snmpwalk を備えた単一の Linux マシンから、What's Up Gold のような単純な管理システム、LogicMonitor のような完全で強力なシステム (コレクターが SNMP の質問を開始する場所) まで、何でもあり得ます。ただし、ストレージ、分析、およびアラートは SaaS インフラストラクチャで集中化されます。) ただし、前述のように、システムが SNMP の質問を開始する場合、それは NMS と見なすことができます。 (システムには、SNMP エージェントと NMS の両方がインストールされている可能性があることに注意してください。)
SNMP エージェントと NMS の両方が互いに SNMP を使用します。つまり、定義済みの IP プロトコル (前述の標準メッセージ形式) です。
SNMP の主要な頭字語のガイド: SMI、MIB、OID、およびその他の TLA
SNMP に関する議論には、すぐに頭字語の選択が含まれます。 ここでは最も一般的なものについて説明します。
SMI: 管理情報の構造。
SMI は ASN 1 (Abstract Syntax Notation One – SNMP のコンテキストでは、これ以上のことを知る必要はありません。「ASN.1」と表示されている場所ならどこでも「SMI」と読むことができます) のサブセットです。SMI は基本的にMIB が記述される構文、使用可能なデータ型の定義、および他の MIB ファイルの参照方法。 たとえば、SMI v2 は TIMETICK オブジェクトを次のように定義します。
タイムティック
TimeTicks 型は、2 つのエポック間の時間を 32 分の 4294967296 秒単位で表すモジュロ 1^XNUMX (XNUMX 進数で XNUMX) の負でない整数を表します。 この ASN.XNUMX タイプを使用するオブジェクトが定義されている場合、オブジェクトの説明は両方の参照エポックを識別します。
その後、TimeTick タイプを使用して、MIB 内の他のオブジェクトを定義できます。
MIB: 管理情報ベース。
通常、MIB はプレーンテキスト ファイルであり、エンティティのデータベースをツリー構造で定義します。これは、SNMP エージェントで使用可能な一連の管理情報です。 MIB ファイル内の各オブジェクトには、オブジェクト識別子があります。
OID: オブジェクト識別子。
これは、ツリー内のオブジェクトを一意に識別するための単純な方法です。 OID の各番号は、MIB ツリーのノードを識別します。 覚えておくべき重要なことは、完全な各 OID が MIB 内の単一のオブジェクトを表すということです。通常、これは SNMP エージェントに尋ねることができる XNUMX つの特定の質問を意味し、ルート ノードから開始してツリーをたどることでそのオブジェクトに到達します。 .
たとえば、下の図では、OID .1.3.6.1.2 が管理ノードを参照していることがわかります。
各組織は、その下の番号の管理を管理または委任します。 したがって、ISO (国際標準化機構) (.1) は、識別された組織を意味するように .1.3 を割り当て、国防総省を意味するように .1.3.6 を割り当てました (インターネットの起源が米国の国防研究プロジェクトであることを反映しています)。
実際には、これは、扱うすべての OID が .1.3.6.1.2 (ベンダーに依存しない標準の管理 OID) で始まることを意味します。 または .1.3.6.1.4.1 (プライベート OID。各ベンダーには、.4.1 の下に独自のプライベート番号を割り当てることができ、その後、これの下に独自の OID オブジェクトを管理できます。Cisco Systems には .9 が割り当てられました。つまり、すべての Cisco Systems OID を参照してください)。彼らが返品したいのは、Cisco 機器に固有のものであり、.1.3.6.1.4.1.9 の下にあります。)
プライベート OID 番号が割り当てられている企業の完全なリストは、http://www.iana.org/assignments/enterprise-numbers/enterprisenumbers で確認できます。
MIB ファイルの例は、右側の RFC1213 MIB からの抜粋です。
上記の長いテキスト ファイルの抜粋では、オブジェクト .1.3.6.1.2.1.1.1.0 を sysDescr オブジェクトとして定義し、SNMP エージェントがこの OID を照会されたときに、システムのテキスト記述を返す必要があることを指定しています。
これを少し抽象化するために、ほとんどの Linux パッケージに含まれている単純なツール snmpwalk を使用してこのクエリを実行できます。
ここでは、Linux サーバーに OID .1.3.6.1.2.1.1.1.0 を照会します。
[demo1.dc7:~]$ snmpwalk -v1 -cSecret 127.0.0.1 .1.3.6.1.2.1.1.1.0その応答は、そのシステムの説明を教えてくれます。
SNMPv2=MIB::sysDescr.0 = STRING: Linux demo1.logicmonitor.net
2.6.32-358.6.2.el6.centos.plus.x86_64 #1 SMP Thu May 16 17:43:34 UTC
2013 x86_64ここでは、Cisco スイッチを照会します。
[demo1.dc7:~]$ snmpwalk -v1 -cSecret sw-core2 .1.3.6.1.2.1.1.1.0別の説明を返します。
SNMPv2=MIB::sysDescr.0 = STRING: Cisco IOS Software, C3560 Software
(C3560-IPSERVICESK9-M), Version 12.2(58)SE1, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2011 by Cisco Systems, Inc.
Compiled Thu 05 May 11 02:19 by prod_rel_team注意すべきことの XNUMX つは、SNMP エージェントが問題のオブジェクトを含む複数のアイテムを持っている可能性がある場合、OID はテーブル内のオブジェクトを表すことができるということです。 この場合、テーブルの各行は項目の XNUMX つに関するものになります。 たとえば、インターフェース – インターフェースの説明用の OID があります。 もう XNUMX つは、そのインターフェイスで受信したオクテットの数です。 しかし、コンピューターには多くのインターフェイスがある場合があります
SNMP のバージョン
SNMP には、一般的に使用される XNUMX つのバージョンがあります。
SNMPバージョン1： 最も古い味。 セットアップが簡単 - 必要なのはプレーンテキスト コミュニティのみです (サポートのみ)。 最大の欠点は、64 ビット カウンターがサポートされておらず、32 ビット カウンターのみがサポートされていることと、セキュリティがほとんどないことです。
SNMP バージョン 2c: 実際には、v2c はバージョン 1 と同じですが、64 ビット カウンターのサポートが追加されています。 これは特にインターフェイスにとって重要です。1Gbps のインターフェイスでさえ、32 ビットのカウンターを 34 秒でラップできます。 これは、32 分間隔でポーリングされる 30 ビット カウンターが役に立たないことを意味します。40 と 10 の連続したサンプルが、その 4294967306 分間に 2 オクテットしか送信されなかったという事実によるものなのか、それとも 32 ( 10^2 +2) オクテットがその分に送信されました。 現在、ほとんどのデバイスは snmp VXNUMXc をサポートしており、通常は自動的にサポートします。 一部のデバイスでは、vXNUMXc を明示的に有効にする必要があります。その場合、常にそうする必要があります。 欠点はありません。
SNMPバージョン3： 64 ビット カウンターにセキュリティを追加します。 SNMP バージョン 3 では、暗号化と認証の両方が追加されており、これらを一緒に使用することも、別々に使用することもできます。 セットアップは、コミュニティ ストリングを定義するだけよりも複雑ですが、そうでないセキュリティとは何でしょうか? ただし、セキュリティが必要な場合は、これがその方法です。
では、どちらを使用する必要がありますか?
SNMP バージョン 1 および 2c の唯一のセキュリティ対策は、平文で送信されるコミュニティ ストリングと、クエリを発行できる IP アドレスを制限する機能です。 これは事実上、ネットワークにアクセスできる人物からのセキュリティではありません。そのような人物は、コミュニティ ストリングを平文で見ることができ、UDP パケットのソース IP のスプーフィングは簡単です。 ただし、デバイスが SNMP 読み取り専用アクセスのみを許可するように設定されている場合、リスクはかなり小さく、限定されます。
あなたのネットワークにアクセスできる悪人。 このアクセス権を持つ悪意のある人がいる場合、SNMP によってデバイスの統計情報を読み取る人は、おそらく心配する必要はありません。 したがって、SNMP v2c の脆弱なセキュリティ モデルを受け入れることができる場合は、それを使用してください。 そうでない場合は、V3 を暗号化と認証とともに使用します。
質問、答え、そして罠
SNMP での情報転送には 1.3.6.1.4.1.9.9.13.1.3.1.3 つの方法があります。 1.3.6.1.4.1.9.9.13.1.3.1.6 つは、OID を照会し、回答を受け取ることです (この照会行為は通常定期的に行われるため、これはしばしばポーリングと呼ばれます)。Cisco デバイスの温度をチェックするために、OID テーブルの行をポーリングできます。 .XNUMX で温度を取得し、.XNUMX で温度が警告またはエラー状態をトリガーしているかどうかを確認します。
情報転送のもう XNUMX つの方法は、トラップを使用することです。 トラップは、SNMP エージェントによって開始されます。 つまり、NMS が OID を定期的にポーリングして温度状態がアラームの原因であるかどうかを確認する代わりに、温度がしきい値を超えたときにデバイスが NMS に通知を送信するだけです。 これは、ポーリングが状態を検出するのを待つのではなく、アラート状態が発生するとすぐに通知を受け取るという点で、良さそうです。 もう XNUMX つの考えられる利点は、NMS、ネットワーク、または監視対象デバイスに負荷がかからず、定期的なポーリングをサポートできることです。 ただし、トラップにはいくつかの重大な欠点があります。
まず、トラップとは何かを考えてみましょう。つまり、デバイスに問題が発生したことを通知するためにデバイスから送信される単一の UDP データグラムです。 現在、UDP (ユーザー データグラム プロトコル) パケットは (TCP とは異なり) 確認応答されず、紛失して到着しない場合でも再送信されません。これは、送信者が到着したかどうかを知る方法がないためです。 そのため、トラップは単一の信頼できない通知であり、UDP パケットが管理ステーションに到達する可能性が最も低い正確な時刻にデバイスから送信されます。定義上、何かがうまくいかないためです。
問題が発生すると、スパニング ツリーの再計算、ルーティング プロトコルの再コンバージェンス、または冗長電源への切り替えによるインターフェイス バッファのリセットが発生する可能性があります。重要なイベントについて通知するために単一のパケットに依存する場合ではありません。 トラップは、インフラストラクチャに重大な影響を与える可能性があることを知らせる信頼できる手段ではありません。これが、可能であれば回避する主な理由です。
皮肉なことに、トラップが問題になるもう XNUMX つの理由は、管理のしやすさです。 トラップを送信して管理ステーションに到達させるには、トラップの送信先 (NMS の IP アドレス) をすべてのデバイスに設定する必要があります。
すべてのスイッチ、すべてのルーター、すべてのサーバーで…. しかし、ポーリングを有効にするために、とにかくデバイスに SNMP コミュニティを設定するためにこれを行う必要はないのでしょうか? はい。ただし、通常、SNMP コミュニティが定義されている場合、ネットワーク全体またはサブネットに対してポーリングが有効になります。 監視システムを同じサブネット上の別の IP に移動でき、構成を変更する必要はありません。
しかし、トラップに依存している場合は、すべてのデバイスに触れて、トラップを新しい宛先に送信するように再構成する必要があります。 さらに重要なことに、トラップが機能するかどうかをテストするのは非常に困難です。 ポーリングを使用すると、コミュニティ、ファイアウォール、またはアクセス リストの構成ミスが原因で返されないデータを簡単に確認 (および警告) できます。 システムが適切な場所にトラップするように設定されていること、およびトラップを許可するようにアクセス リストが正しく設定されていることを確認するのは非常に困難です。 (もちろん、トラップは通常の SNMP クエリとは異なるポートを使用するため、ポーリングが機能するという事実は、トラップが機能するかどうかについては何もわかりません。)
定義上、ポーリングは約 XNUMX 分ごとにテストされます。 通常、トラップは重大なイベントが発生した場合にのみ送信され、失敗した場合は通知やフィードバックはありません。 インフラストラクチャとアプリケーションの健全性を維持するために、どちらに依存しますか?
ポーリングの最後の利点は、傾向とコンテキストを提供できることです。 次のグラフを検討してください。
トラップまたはポーリングを使用して、CPU 使用率が 80% を超えたという事実に関するアラートを受け取ることができます。 しかし、データのトラップのみに依存している場合、それ以上の情報はありません。 XNUMX つのシステムで早急な対応が必要なようです。CPU 使用率が急速に上昇し始めました。 もう XNUMX つの星系は XNUMX 週間にわたってゆっくりと着実に使用量を増やしているため、災害が発生するまでには少なくともあと数日はあると思われます。 このデータを提供しないトラップに頼ると、これら XNUMX つのシステムにどのように反応するかについて十分な情報に基づいた決定を下すことができなくなります。
デバイスの「SNMP サポート」とは何を意味しますか?
データセンターや IT スペースに販売されているほとんどのデバイスは、「SNMP サポート」を謳っています。 これは、XNUMX 歳の幼児とウサイン ボルトの両方が走ることができると言っているようなものです。「SNMP サポート」が意味するものには、非常に大きな違いがあります。 一部のデバイスは、SNMP を介して入手できる非常に限定された情報セットをサポートします。 すべての標準的な管理オブジェクトをサポートするものもあります。 また、標準オブジェクトだけでなく、独自の MIB で公開する何千もの OID をサポートするものもあります。
最悪のケースは、おそらくデバイスが実行しているソフトウェアのバージョンを除いて、デバイスが SNMP 経由で何も提供しない場合です。 これは名前だけの SNMP サポートです。
デバイスがサポートする最低限の機能は、mgmt サブツリーにあるデータなどの基本的な管理機能です。 (これにより、インターフェイスの使用率、XNUMX 秒あたりのパケット数、CPU とメモリの使用率、TCP 統計などを検出して報告できるようになります。)
しかし、多くの場合、基本的な管理データは確かに十分ではありません。 たとえば、インターフェース データと TCP 統計を知っていても、UPS (無停電電源装置) やストレージ アレイ (特に、データがファイバー チャネル経由で転送され、インターフェースが使用状況を示さないようにする場合) を監視する場合にはほとんど役に立ちません。このような場合、.1.3.6.1.2 ツリーの下で標準化されていないデータを測定および報告するさまざまな OID を提供するベンダー提供の MIB をデバイスがサポートする必要があります。
たとえば、UPS デバイスは、バッテリで動作している時間などを報告する必要があります。 バッテリーに切り替えた理由; バッテリーが枯渇する前にバッテリーに残っているランタイム。 バッテリ パックの状態など。ストレージ アレイは、ドライブの状態などを報告する必要があります。 空き/プロビジョニングされていないスペース; ボリュームまたは LUN などによる読み取り/書き込み要求の遅延。
デバイス ベンダーが多くの有用な情報を含む MIB を提供している可能性があるという事実は、必ずしも問題を解決するとは限りません。 たとえば、APC は非常に強力な SNMP エージェントと詳細なプライベート MIB (MIB には 4500 を超えるオブジェクトが含まれています) を提供していますが、すべてのオブジェクトがすべての APC デバイスでサポートされているわけではありません。 また、ほとんどはデバイスの通常の使用には意味がありません (例: 1:「整流器の物理アドレス (バス上のアドレス)」)。
管理システムの「SNMP サポート」とは何を意味しますか?
前述のように、NMS は、SNMP ユーティリティがインストールされた Linux ワークステーションと同じくらい単純で、SNMP 取得を実行できます。 理論的には、snmpget と snmpwalk にいくつかのスクリプトをラップして、関心のあるデータをクエリすることができます。 それをいくつかのハードコードされたしきい値と比較します。 スクリプトを cron ジョブから実行して、5 分ごとに繰り返すようにします。
ただし、これは実際の NMS とは考えられないでしょう。
そのため、SNMP クエリへの応答を照会して表示できるシステムはすべて NMS と呼ぶことができますが、実用的なレベルから存在する必要がある基本的なことがいくつかあります。
照会する OID を簡単に定義します。
理想的には、これについて考える必要さえありません。 真の SNMP サポートを備えた NMS は、デバイスの種類を検出します。 次に、そのデバイスを照会するのに適切な OID を認識します。 また、デバイスの構成に変更があり、新しい異なる OID を確認する必要があるかどうかを定期的に確認します。 (たとえば、スイッチで Power-over Ethernet を有効にすると、照会する必要がある MIB ツリーのまったく新しいセクションがオンになります。) 最悪のケースは、確認する OID を手動で定義する必要がある NMS です。 はい、技術的には SNMP をサポートしていますが、UPS が正しく監視されていることを確認するためだけに、APC MIB の 4500 個のオブジェクトを通過する必要がある場合、生活が楽になるわけではありません。
返されるデータの解釈方法を簡単に定義できます。
SNMP データはゲージとして返すことができます (摂氏での現在の温度など)。 カウンター (システムが開始されてからインターフェースを通過したパケットの数); 文字列、ビットマップなど。カウンターは、ほとんどの場合、現在のカウンター値から前のカウンター値を減算し、サンプル間の時間間隔で割ることによって、レートに変換する必要があります。 これは、NMS によって自動的に処理されます。
アラートをトリガーするしきい値を簡単に定義します。
繰り返しますが、理想的には、NMS はこれに対する多くの必要性を取り除き、本番システムに影響を与える可能性のあるすべてのものに対して事前定義されたアラートを備えている必要がありますが、ミッション クリティカルではないシステムなどの場合は、常にカスタマイズが必要になります。パフォーマンスの問題に対する許容度が高くなります。 または事前定義されていないカスタム メトリックの場合。 この調整は簡単な作業です。
上記のすべての項目が使いやすさに重点を置いていることに気付くでしょう。これは、NMS を使用する主な目標である必要があります。これは、システムの運用上の可用性、容量、およびパフォーマンスを確保する作業を容易にするためです。 テキストまたは XML ファイルを変更したり、数千の MIB ファイルを調べたり、すべての SNMP OID を照会するように構成したりする必要がある NMS システムは、技術的には NMS システムである可能性があります。
この点に関して、NMS が実行できることは他にもたくさんありますが、組織によって有用性が異なります。
• 収集された変数をグラフ化して、収集されたオブジェクトの履歴傾向を確認できます。
• アラートをさまざまなメカニズム (チャット、電子メール、SMS、音声通話) を介してさまざまな人にルーティングして配信し、さまざまな人やチームを通じてエスカレートします。 これは別のツールで行うこともできます。
• さまざまなメカニズムを介して監視対象のデバイスを検出します。 • デバイスをさまざまな OSI レイヤーで論理的に、または地理的にマッピングします。
• SNMP 以外のさまざまなデータ収集メカニズムを使用して、SNMP のサポートをまったく提供しない、または限定的にサポートするデバイスをサポートします。 WMI、JMX、およびその他のさまざまな API などの他のプロトコルを介してデータを収集できる NMS を使用して、複数のツールを XNUMX つに統合して置き換え、環境全体のよりまとまりのあるビューを提供できます。
などがあります。
Linux への SNMPd のインストール
Linux に snmp デーモンをインストールするのは非常に簡単です。 パッケージ マネージャーを使用して netsnmp パッケージとユーティリティをインストールするだけです。 Redhat または Centos では、次のようになります。
yum install net-snmp
yum install net-snmp-utilssnmpd を設定するには多くのオプションがあります。IP アドレスでクエリできるホストを制限できます。 SNMP v3 で使用する暗号化と認証を有効にすることができます。 さまざまな IP アドレス、コミュニティ、またはユーザーから問い合わせがあった場合に、エージェントが応答する OID を制限することもできます。
ただし、ほとんどの場合、単純な構成が適切です (ホストがファイアウォールの背後にあり、インターネットに公開されていないと仮定します)。 最も単純な構成は、/etc/snmp/snmpd.conf の内容を次のように設定することです。
rocommunity MyCommunityこれにより、デバイスがコミュニティ MyCommunity を認識している場合、SNMP によってこのシステムにクエリを実行できるようになります。 ただし、書き込み操作や設定操作では SNMP は有効になりません。
次に、SNMP がシステムの起動時に自動的に開始するように設定されていることを確認し、次のコマンドを使用して今すぐ開始する必要があります。
chkconfig snmpd on
service snmpd restartSNMP が他のホストからのクエリに応答していないことがわかった場合は、次のトラブルシューティング手順を確認してください。
- サーバーで iptables などのファイアウォールを実行している場合は、SNMP クエリ (UDP ポート 161) が通過できるように設定されていることを確認してください。
- 同様に、NMS とサーバーの間に他のファイアウォールがある場合は、それらが SNMP クエリを通過できるように構成されていることを確認してください。 tcpdump ポート 161 を実行すると、リクエストがサーバーに到着しているかどうかを確認できます (複数のインターフェースがある場合は、-i フラグを使用して正しいインターフェースを指定する必要があります)。ローカル システムのファイアウォールがパケットを拒否しているかどうかは表示されません。
- 一部のディストリビューションには、アクセスをさらに制限するために、/etc ディレクトリ内の hosts.allow および hosts.deny ファイルを tcpwrappers と組み合わせて使用するバージョンの snmp エージェントが含まれます。 snmpd: ALL という行を /etc/hosts に追加することで、これをテストできます。 許可し、テストを再試行します。
- もちろん、正しい SNMP コミュニティ文字列を使用していることを確認してください。
大規模な作業
管理するサーバーが複数ある場合は、すべてのデバイスで SNMP アクセスをセットアップする必要があります。 これは、一般的な構成管理ツール (Ansible、Chef、Puppet、CFEngine など) を使用して簡単に実行できます。
これは SNMP に固有のものではありません。複数のサーバーにまたがる構成の管理には、同じ方法を使用する必要があります。 ただし、SNMP 構成ファイルが構成管理ツールによって管理されていることを確認すると、すべてのサーバーに正しく展開されていることを簡単に確認できます。 SNMPコミュニティを簡単に変更できます。 SNMP v3の採用など
まとめ
SNMP とは何か、つまり SNMP が使用される理由について理解できたと思います。 構成方法; それを使用するシステムの種類。 そして、SNMP サポートについて話す際のいくつかの落とし穴。 SNMP は、最も広く導入されている管理プロトコルです。 理解しやすく (常に使用できるわけではありませんが)、ユビキタスなサポートを楽しんでいます。 一部のシステムには代替管理システムがありますが (最も顕著なのは WMI を優先的に使用する Windows です)、SNMP に関する十分な知識があれば、さまざまなデバイスやサーバーを監視するための準備が整います。
LogicMonitorの統合監視プラットフォームは、背後にあるテクノロジーを進歩させることにより、ビジネスの可能性を広げます。