SNMP トラップのログソース構成

SNMP トラップ タイプ LogSource を使用すると、LogicMonitor コレクタは、アラートを構成せずに SNMP トラップを LogicMonitor ログに取り込むことができます。

要件

• コレクターのバージョン EA Collector 34.500 以降。 コレクターのアップグレードの詳細については、「」を参照してください。 コレクターの管理.
• LogicMonitor UIv4 へのアクセス

設定オプション

構成オプションには、SNMP トラップ ログソースに固有の構成の詳細が含まれます。 LogSource の追加の詳細については、次を参照してください。 LogSource の構成.

インフォ

選択する LM ログ: SNMP トラップ タイプ ドロップダウンをクリックして、名前、グループ名、説明、技術メモなどの基本情報を提供します。

に適用されます

コレクタへの LogSource の適用

コレクター バージョン EA-35.200 以降では、 コレクターに申し込む オプション。デフォルトでは、 コレクターに申し込む オプションは無効です。

LogSource をコレクタに適用すると、次のシナリオで役立ちます。

• コレクタは、SNMP トラップをコレクタに転送するデバイスを監視しません。
• LogicMonitor は、SNMP トラップをコレクタに転送しているデバイスを監視しません。

SNMP トラップをコレクタに転送するデバイスの場合は、次の手順を実行して LogSource をコレクタに適用します。

1. SNMP コミュニティ (SNMP v1/v2 トラップの場合) または SNMP 資格情報 (SNMP v3 トラップの場合) をコレクタ (自己監視デバイス) プロパティとして追加して、コレクタが転送されたトラップを認証できるようにします。詳細については、次を参照してください。 LM ログとして SNMP トラップを取り込むためのコミュニティ文字列と SNMP 認証情報の定義.
2. LogSource を作成し、有効にします。 コレクターに申し込む LogSource をコレクタに適用するオプション。

除外フィルター

EA Collector 36.400 より前にリリースされたコレクター バージョンの場合、除外フィルターの条件に一致するトラップは取り込まれません。

EA Collector 36.400 以降では、除外フィルターの条件のいずれかに一致するトラップは取り込まれません。次のフィルターを使用して、SNMP トラップを除外できます。

利用可能なパラメータ

ログフィールド

ログ フィールド (タグ) を構成して、ログ エントリにメタデータを追加できます。

利用可能なパラメータ

リソースマッピング

リソース マッピングの場合、監視対象リソースの LM プロパティと一致するように LM ログ キーを構成できます。

利用可能なパラメータ

正しいリソース マッピングを行うには、SNMP トラップ バージョンに基づいてトラップからソース (ホスト) アドレスがどのように抽出され、コレクター デバイスに転送されるかを知ることが重要です。

EA Collector 36.100 以降では、SNMP トラップ バージョンに基づいて、コレクターはトラップ PDU の次の要素からのホスト アドレスを使用します。

例

シナリオ - トラップは、コレクター デバイスに到達する前に、あるデバイスから別のデバイスに転送されます。 

• デバイスA (トラップ生成デバイス) - SNMP トラップを生成するデバイス。このデバイスの IP アドレスは 192.168.1.10 です。
• デバイスB (トラップ転送デバイス) - デバイス A からトラップを受信し、トラップ コレクター デバイスに転送するデバイス。このデバイスの IP アドレスは 192.168.1.20 です。
• デバイスC (トラップ コレクター デバイス) - トラップが収集され、監視されるコレクター デバイス。

SNMP v1 トラップ

• エージェントの住所—SNMPトラップを生成するデバイス（デバイスA）のIPアドレスは、 エージェントアドレス トラップ メッセージのフィールド。
• トラップ転送—デバイスBがトラップをデバイスCに転送する場合、通常、デバイスBはトラップの宛先アドレスとしてデバイスCのアドレスを使用しますが、 エージェントアドレス フィールドにはデバイス A の IP アドレスがまだ含まれています。

 SNMPv1 トラップ パケットの例

PDU Type: Trap
Agent Address (agent-addr): 192.168.1.10  (Device A’s IP)
Variable Bindings: ... 

SNMP v2c および v3 トラップ

• 変数バインディング—agent-addr はトラップの変数バインディングの一部です。agent-addr 変数は、トラップ メッセージ内の OID 値ペアの 1 つとして明示的に含まれています。
• トラップ転送—デバイス B がトラップを転送すると、変数バインディングにデバイス A の IP アドレスが含まれます。その結果、デバイス C はトラップ メッセージ内の IP アドレスを表示できます。

SNMP v2c および v3 トラップ パケットの例

PDU Type: Trap
Variable Bindings:
    1.3.6.1.6.3.18.1.3.0 (agent-addr): 192.168.1.10  (Device A’s IP)
    ...

サポートされているすべての SNMP バージョンにおいて、デバイス B がトラップをデバイス C に転送すると、デバイス A の IP アドレスが関連フィールド (SNMP v1 の場合は agent-addr、SNMP v2c および v3 の場合は変数バインディング) に保持され、デバイス C がトラップの元のソースを認識していることを確認できます。

v1 トラップの agent-addr が欠落しているか空の場合、または SNMPv2c および SNMPv3 トラップの指定された変数バインディングが欠落している場合、コレクター デバイスは、リソース マッピングにデバイス B のアドレス (192.168.1.20) であるソケット アドレスを使用します。

SNMP トラップ LogSource 構成例

以下は、SNMP トラップ LogSource 構成の例です。

基本情報

除外フィルター

ログフィールド

リソースマッピング

LogSource と EventSource を使用した SNMP トラップの処理

コレクターは、LogSource または EventSource を使用して SNMP トラップを処理します。一度に LogSource または EventSource のいずれかが使用されますが、どのようなシナリオでも両方を同時に使用することはできません。

• LogSource を使用した SNMP トラップの処理– コレクタが LogSource が適用されているデバイスを監視する場合、コレクタは LogSource が適用されているデバイスからの SNMP トラップのみを処理します。コレクタは、LogSource が適用されていないデバイスからのトラップを無視します（つまり、処理しません）。
• EventSource を使用した SNMP トラップの処理– コレクターによって監視されているすべてのデバイスに LogSource が適用されていないが、それらのデバイスに EventSource が適用されている場合、コレクターは EventSource が適用されているデバイスからの SNMP トラップを処理します。

コレクターが SNMP トラップを処理する方法を理解するには、次のシナリオを参照してください。これらのシナリオでは、同じコレクターによって監視される 3 つのデバイスを考慮しました。 

シナリオ1

LogSource が適用されたデバイスが少なくとも 1 つあるため、コレクタは LogSource のみを使用してデバイス 3 とデバイス XNUMX の両方からの SNMP トラップを処理します。

LogSource がデバイス 2 に適用されないため、デバイス 2 からの SNMP トラップは無視されます（つまり、処理されません）。

シナリオ2

どのデバイスにも LogSource が適用されていないため、コレクターは、EventSource のみを使用してデバイス 1 とデバイス 2 の両方からの SNMP トラップを処理します。デバイス 3 には EventSource が適用されていないため、デバイス 3 からの SNMP トラップは無視されます (つまり、処理されません)。

SNMP トラップ処理の設定

顧客の要件に応じてコレクタに LogSource を適用する機能を使用すると、コレクタが SNMP トラップを処理できる方法が 3 つあります。

• コレクターが受信した SNMP トラップを取り込むには、 lmlogs.snmptrap.enabled Agent.conf 設定のプロパティ。あるいは、 Syslog および SNMP トラップのログ収集を有効にする このプロパティを有効にするには、[コレクターの追加] ページのオプションを使用します。コレクタを有効にすると、フィルタやリソース マッピングなどのカスタマイズを行わずに、すべての SNMP トラップが取り込まれます。
• カスタマイズを追加するには - トラップのフィルタリングやリソース マッピングの別の方法の追加などのカスタマイズの場合は、LogSource を作成し、SNMP トラップを受信するコレクタに適用する必要があります。 コレクターに申し込む LogSource のオプション。
• 特定の LogSource 定義を使用してデバイスからの SNMP トラップを処理するには、SNMP トラップをコレクタに転送するデバイスに通常の LogSource を適用する必要があります。 

デバイスに適用される通常の LogSource は、SNMP トラップを処理するコレクタに適用される LogSource よりも優先されます。

コレクターに適用される LogSource は、コレクターの Agent.conf プロパティよりも優先されます。 lmlogs.snmptrap.enabled SNMP トラップを処理するため。

コレクター (SNMP トラップを受信する) が SNMP トラップを処理する設定を理解するには、次のシナリオを参照してください。

* コレクターは、次の 2 つのシナリオでデバイスを監視します。

• [リソースの管理] ページで、コレクタが優先コレクタとしてデバイスに割り当てられます。
• [リソースの管理] ページで、コレクタは、 LM ログ コレクターの設定 オプションを選択します。

カスタム MIB を使用した SNMP トラップの変換

EA Collector 35.400リリース以降では、MIBからJSONへのコンバーターユーティリティを使用してMIBファイルをJSONファイルに変換できます。コレクターでは、ユーティリティは次の場所にあります。 [LogicMonitor コレクタ ディレクトリ]/bin/snmpMibsToJsonConversionUtil.

この Python ベースのユーティリティは、カスタム MIB (LogicMonitor がそのままではサポートしていない) をエンタープライズ JSON ファイルに変換するように設計されており、コレクターはそれを使用して SNMP トラップを変換します。デフォルトでは、エンタープライズ JSON ファイルは [LogicMonitorコレクタディレクトリ]/snmpdb/custom ディレクトリにあります。 

SNMPトラップ変換の仕組み

SNMP トラップは、SNMP プロトコル データ ユニット (PDU) の形式でデータの塊として受信されます。PDU には、最初にエンコードされた複数の要素が含まれています。SNMP トラップ PDU をデコードすると、SNMP トラップに関連付けられたメタデータのさまざまな要素、トラップの種類を表すオブジェクト識別子 (OID)、および各ペアが OID とそれに対応する値で構成されるペアのリストである一連の変数バインディング (varbinds) が取得されます。

SNMP トラップ変換は次の目的で使用されます。

• LM ログによってキャプチャされた SNMP トラップに含まれる OID のすぐ隣に、括弧で囲まれた判読可能な値を提供します。
• 人間が判読可能な値を、SNMP トラップに関連付けられたフィールドとして、対応する値とともにマッピングします。これらのフィールドは、LM ログ プラットフォームのフィルターやクエリ、ログ パイプラインやアラート条件で使用できます。

例

SNMPトラップPDUの要素

トラップオイド => 1.3.6.1.4.1.9.9.276.0.1
変数バインディング 1 => 1.3.6.1.2.1.2.2.1.1=5
変数バインディング 2 => 1.3.6.1.2.1.2.2.1.2=ギガビットイーサネット1/0/5
変数バインディング 3 => 1.3.6.1.2.1.2.2.1.8=2
変数バインディング 4 => 1.3.6.1.2.1.2.2.7=3

EA Collector 36.200以降では、SNMPトラップメッセージをJSONとしてフォーマットするには、 lmlogs.snmptrap.formatMessageAsJson.enabled プロパティへ true agent.conf設定でこのプロパティはデフォルトで falseまた、SNMP トラップの変換された変数バインディング キーは、変換された変数バインディング キーごとに個別のログ フィールドではなく、単一のログ フィールドに含まれます。 

Status lmlogs.snmptrap.formatMessageAsJson.enabled プロパティがに設定されています false

変換後にSNMPトラップがLMログとして取り込まれる
Message => trapOid=1.3.6.1.4.1.9.9.276.0.1(cieLinkDown) 1.3.6.1.2.1.2.2.1.1(ifIndex)=5 1.3.6.1.2.1.2.2.1.2(ifDescr)=GigabitEtherenet1/0/5 1.3.6.1.2.1.2.2.1.8(ifOperStatus)=2(down) 1.3.6.1.2.1.2.2.7=3

メッセージ フィールドとは別に、SNMP トラップの翻訳された変数バインディング キーは、それぞれの値とともに、翻訳された変数バインディング キーごとに個別のログ フィールドに含まれます。変数バインディング値が翻訳されていない場合、フィールドには生の変数バインディング値が含まれます。この例では、ログに次のフィールドが存在します。

Status lmlogs.snmptrap.formatMessageAsJson.enabled プロパティがに設定されています true

SNMP トラップ メッセージは JSON 形式です。

{
  "trapOID": {
    "value": "1.3.6.1.4.1.9.9.276.0.1",
    "name": "cieLinkDown"
  },
  "1.3.6.1.2.1.2.2.1.1": {
    "name": "ifIndex",
    "value_raw": "5"
  },
  "1.3.6.1.2.1.2.2.1.2": {
    "name": "ifDescr",
    "value_raw": "GigabitEtherenet1/0/5"
  },
  "1.3.6.1.2.1.2.2.1.8": {
    "name": "ifOperStatus",
    "value_raw": "2",
    "value_desc": "down"
  },
  "1.3.6.1.2.1.2.2.7": {
    "value_raw": "3"
  }
}

翻訳された変数バインディングOIDは、単一のログフィールドに含まれる。 varbind 個々のログ フィールドの代わりに。 

ユーティリティを使用するための要件

• カスタム MIB ファイルとそのすべての依存関係または親 MIB ファイル。
• マシンに Python バージョン 3.8 ～ 3.12 がインストールされている必要があります。
• このユーティリティは、コレクタのインストールに使用したのと同じユーザーで実行する必要があります。
• MIB ファイルの定義が複数の入力 MIB ファイルの一部でないことを確認してください。存在する場合、ユーティリティはそのようなファイルのいずれかを考慮します。たとえば、ABC MIB の場合、次の行を含む複数のファイルがあってはなりません。
  ABC DEFINITIONS ::= BEGIN
• ユーティリティの依存関係をインストールします。これを行うには、ユーティリティ ディレクトリに移動します。 [LogicMonitor コレクタ ディレクトリ]/bin/snmpMibsToJsonConversionUtil/ そして、次のコマンドを実行します。

pip install -r requirements.txt

ユーティリティが JSON ファイルを生成する方法

1. 実行する snmpMibsToJsonConverter.py ユーティリティディレクトリにあるファイル。
2. カスタム MIB ファイルを配置するディレクトリ パスを指定します。
3. 変換された JSON ファイルを生成するディレクトリ パスを指定します。デフォルトでは、ファイルはデフォルトのディレクトリに生成されます。 [LogicMonitorコレクタディレクトリ]/snmpdb/custom。ただし、別のディレクトリを指定することもできます。
4. ユーティリティは MIB ファイルを変換し、指定したディレクトリに JSON ファイルを生成します。
5. JSON ファイルが別のディレクトリに生成された場合は、ファイルをデフォルトのディレクトリにコピーします。 [LogicMonitorコレクタディレクトリ]/snmpdb/custom.
6. コレクターが再起動すると、コレクターは JSON ファイルを使用して、対応する SNMP トラップを変換します。

質問がある場合、またはユーティリティの使用中に問題が発生した場合は、LogicMonitor カスタマー サクセス マネージャー (CSM) にお問い合わせください。

ユーティリティの問題のトラブルシューティング

このセクションでは、ソース MIB の欠落や MIB の障害など、MIB から JSON へのコンバーター ユーティリティに関連する問題のトラブルシューティングについて説明します。

不足しているソース MIB のトラブルシューティング

ユーティリティを実行するときは、「不足しているソースMIB」を探してください。:” ログに記録されます。ログ内の MIB ファイル名は、その MIB ファイルが見つからないために MIB 変換が失敗したことを示します。たとえば、次のログ メッセージは、“ABC-MIB” が見つからないために変換が失敗したことを示しています。

Missing source MIBs: ABC-MIB

解決策

指定したディレクトリに、不足しているソース MIB「ABC-MIB」を他の MIB とともに追加し、ユーティリティを再度実行します。

失敗した MIB のトラブルシューティング

ユーティリティを実行するときは、「失敗した MIB:」ログを探します。ログにエラーがある場合は、MIB 変換が失敗したことと、失敗の理由が示されます。「失敗した MIB:」ログには、次のログ メッセージが表示されます。

親 MIB または依存 MIB がありません

Failed MIBs: ABC (no module "XYZ" in symbolTable at MIB ABC)

ログには、ABC MIB の変換が失敗したことが示されています。

解決策

指定したディレクトリに「XYZ」MIB を他の MIB とともに追加し、ユーティリティを再度実行します。

Winエラー183

Failed MIBs: ABC (failure writing file inter_json\ABC.json: [WinError 183] Cannot create a file when that file already exists: 'C:\\snmpMibsToJsonConversionUtil\\inter_json\\tmp44ahdl2d' -> 'inter_json\\ABC.json' at MIB ABC)

解決策

このエラーは Windows OS でのみ発生する可能性があります。 MIB はユーティリティによってすでにコンパイルされているため、このエラーは無視できます。