SNMP トラップのログソース構成
最終更新日: 10 年 2025 月 XNUMX 日SNMP トラップ タイプ LogSource を使用すると、LogicMonitor コレクタは、アラートを構成せずに SNMP トラップを LogicMonitor ログに取り込むことができます。
要件
- コレクターのバージョン EA Collector 34.500 以降。 コレクターのアップグレードの詳細については、「」を参照してください。 コレクターの管理.
- LogicMonitor UIv4 へのアクセス
設定オプション
構成オプションには、SNMP トラップ ログソースに固有の構成の詳細が含まれます。 LogSource の追加の詳細については、次を参照してください。 LogSource の構成.

ご注意: を削除しました。 エンタープライズ OID 分野。 EA Collector 35.300 以降、SNMP トラップの変換に Enterprise OID は必要ありません。ただし、SNMP トラップ変換は、LogicMonitor でサポートされているすべてのすぐに使用できるエンタープライズ/MIB で引き続き機能します。
インフォ
選択 LM ログ: SNMP トラップ 種類 ドロップダウンをクリックして、名前、グループ名、説明、技術メモなどの基本情報を提供します。
に適用されます
コレクタへの LogSource の適用
コレクター バージョン EA-35.200 以降では、 コレクターに申し込む オプション。デフォルトでは、 コレクターに申し込む オプションは無効です。
LogSource をコレクタに適用すると、次のシナリオで役立ちます。
- コレクタは、SNMP トラップをコレクタに転送するデバイスを監視しません。
- LogicMonitor は、SNMP トラップをコレクタに転送しているデバイスを監視しません。
SNMP トラップをコレクタに転送するデバイスの場合は、次の手順を実行して LogSource をコレクタに適用します。
- SNMP コミュニティ (SNMP v1/v2 トラップの場合) または SNMP 資格情報 (SNMP v3 トラップの場合) をコレクタ (自己監視デバイス) プロパティとして追加して、コレクタが転送されたトラップを認証できるようにします。詳細については、次を参照してください。 LM ログとして SNMP トラップを取り込むためのコミュニティ文字列と SNMP 認証情報の定義.
- LogSource を作成し、有効にします。 コレクターに申し込む LogSource をコレクタに適用するオプション。

ご注意:
- 「AppliesTo」セクションには、EA Collector 35.200 以降がインストールされている自己監視コレクタのみがリストされます。
- 自己監視コレクタに適用できる SNMP トラップ タイプの LogSource は 1 つだけです。
- デバイスがトラップを受信するコレクタによって監視されている場合、デバイスに適用される LogSource がコレクタに適用される LogSource よりも優先されます。詳細については、「 SNMP トラップ処理の設定 のセクションから無料でダウンロードできます。
除外フィルター
EA Collector 36.400 より前にリリースされたコレクター バージョンの場合、除外フィルターの条件に一致するトラップは取り込まれません。
EA Collector 36.400 以降では、除外フィルターの条件のいずれかに一致するトラップは取り込まれません。次のフィルターを使用して、SNMP トラップを除外できます。
利用可能なパラメータ
Attributes | 比較演算子 | 値の例 | TrapOIDの例 | Varbind キーの例 | Varbind値の例 | 説明 |
トラップOID | 等しい、等しくない、で始まる | 1.3.6.1.4.1.9.9.61.2.0.1 | – | – | – | トラップのトラップOID |
ヴァルビンド | 正規表現一致、正規表現不一致 | 1.3.6.1.4.1.9.9.13.1.3.1.2 | 1.3.6.1.4.1.9.9.61.2.0.1 | 1.3.6.1.4.1.9.9.13.1.3.1.2 | [az]+ | Varbind キーとトラップの値を持つ TrapOID |
ログフィールド
ログ フィールド (タグ) を構成して、ログ エントリにメタデータを追加できます。
利用可能なパラメータ
方法 | 主な例 | 値の例 | 説明 |
静的 | Customer | 顧客_XYZ | キーと値はそのままログエントリのメタデータに追加されます |
LM プロパティ(トークン) | デバイス | ##システム.デバイスID## | LogicMonitorのデバイスプロパティから抽出されたデバイスID値 |
リソースマッピング
リソース マッピングの場合、監視対象リソースの LM プロパティと一致するように LM ログ キーを構成できます。
利用可能なパラメータ
方法 | 主な例 | 値の例 | 説明 |
静的 | 顧客ID | 1219 | キーと値はリソース マッピングにそのまま使用されます。 |
IP | システム.ips | 10.20.30.40 | SNMP トラップ ホスト フィールド情報を使用して、それを IP に解決します。 の 値 この方法を選択すると、フィールドは無効になります。 キーのみを入力できます。 |
FQDN | システムのホスト名 | application.service.example.com | トラップのホスト アドレスから受信したホスト名の DNS 解決からの完全修飾ドメイン名。 の 値 この方法を選択すると、フィールドは無効になります。 キーのみを入力できます。 |
ホスト名 | システムのホスト名 | host1.example.com | この 値 この方法を選択すると、フィールドは無効になります。 キーのみを入力できます。 |
DNS なしのホスト | システムのホスト名 | host1 | この 値 この方法を選択すると、フィールドは無効になります。 キーのみを入力できます。 |
正しいリソース マッピングを行うには、SNMP トラップ バージョンに基づいてトラップからソース (ホスト) アドレスがどのように抽出され、コレクター デバイスに転送されるかを知ることが重要です。
EA Collector 36.100 以降では、SNMP トラップ バージョンに基づいて、コレクターはトラップ PDU の次の要素からのホスト アドレスを使用します。
SNMP トラップ バージョン | PDUエレメント |
---|---|
v1 | エージェントアドレス |
v2c と v3 | 変数バインディング OID '1.3.6.1.6.3.18.1.3' の値 (SNMP-COMMUNITY-MIB.snmpTrapAddress) |
ご注意: 各 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 構成の例です。
基本情報
フィールド名 | 値の例 |
お名前 | SNMP トラップのログソース |
グループ | SNMP トラップのログソース |
種類 | LM ログ: SNMP トラップ |
説明 | UPS 関連のトラップは、この LogSource を使用して処理されます。 |
に適用されます | (カスタムクエリ) isLinux() || isNetwork() |
除外フィルター
属性 | 比較演算子 | 値 |
トラップOID | 等しい | 1.3.6.1.4.1.9.9.61.2.0.1 |
ログフィールド
方法 | キー | 値 |
静的 | Customer | 顧客_xyz |
リソースマッピング
方法 | キー | 値 |
LM プロパティ(トークン) | system.deviceId | ##システム.デバイスID## |
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 トラップは無視されます(つまり、処理されません)。
デバイス | ログソースは適用されていますか | イベントソースは適用されていますか |
デバイス1 | Yes | Yes |
デバイス2 | いいえ | Yes |
デバイス3 | Yes | いいえ |
シナリオ2
どのデバイスにも LogSource が適用されていないため、コレクターは、EventSource のみを使用してデバイス 1 とデバイス 2 の両方からの SNMP トラップを処理します。デバイス 3 には EventSource が適用されていないため、デバイス 3 からの SNMP トラップは無視されます (つまり、処理されません)。
デバイス | ログソースは適用されていますか | イベントソースは適用されていますか |
デバイス1 | いいえ | Yes |
デバイス2 | いいえ | Yes |
デバイス3 | いいえ | いいえ |
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 トラップを処理する設定を理解するには、次のシナリオを参照してください。
シナリオ # | デバイスはコレクターによって監視されていますか* | デバイスに適用される通常の LogSource です | コレクターに適用される LogSource です | lmlogs.snmptrap.enabled が true に設定されているか | 結果 |
1 | Yes | Yes | 任意(はい/いいえ) | 任意(はい/いいえ) | SNMP トラップは、SNMP トラップを転送するデバイスに適用される通常の LogSource を使用して処理されます。 |
2 | Yes | いいえ | Yes | 任意(はい/いいえ) | SNMP トラップは、SNMP トラップを受信するコレクタに適用される LogSource を使用して処理されます。 |
3 | いいえ | 任意(はい/いいえ) | Yes | 任意(はい/いいえ) | SNMP トラップは、SNMP トラップを受信しているコレクタに適用された LogSource を使用して処理されます。 |
4 | いいえ | 任意(はい/いいえ) | いいえ | Yes | SNMP トラップは、 lmlogs.snmptrap.enabled SNMP トラップを受信するコレクタの Agent.conf 設定のプロパティ。 |
* コレクターは、次の 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 トラップの翻訳された変数バインディング キーは、それぞれの値とともに、翻訳された変数バインディング キーごとに個別のログ フィールドに含まれます。変数バインディング値が翻訳されていない場合、フィールドには生の変数バインディング値が含まれます。この例では、ログに次のフィールドが存在します。
ログ フィールド | 値 |
ifIndex | 5 |
ifDescr | ギガビットイーサネット1/0/5 |
ifOperStatus | ダウン |
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 個々のログ フィールドの代わりに。
ログ フィールド | 値 |
varbinds | {"ifIndex":"5","ifDescr":"GigabitEtherenet1/0/5","ifOperStatus":"down"} |
ご注意:
- lmlogs.snmptrap.formatMessageAsJson.enabledプロパティの値をtrueまたはfalseに設定するかどうかに関係なく、
Variable Binding 4 => 1.3.6.1.2.1.2.2.7=3
この変数バインディングの OID (1.3.6.1.2.1.2.2.7) は変換されないため、ログ フィールドに含まれません。 - SNMP トラップは、SNMP トラップのバージョンに関係なく変換されます。
ユーティリティを使用するための要件
- カスタム MIB ファイルとそのすべての依存関係または親 MIB ファイル。
- マシンに Python バージョン 3.8 ~ 3.12 がインストールされている必要があります。
- このユーティリティは、コレクタのインストールに使用したのと同じユーザーで実行する必要があります。
- MIB ファイルの定義が複数の入力 MIB ファイルの一部でないことを確認してください。存在する場合、ユーティリティはそのようなファイルのいずれかを考慮します。たとえば、ABC MIB の場合、次の行を含む複数のファイルがあってはなりません。
ABCDEFINITIONS ::= BEGIN
- ユーティリティの依存関係をインストールします。これを行うには、ユーティリティ ディレクトリに移動します。 [LogicMonitor コレクタ ディレクトリ]/bin/snmpMibsToJsonConversionUtil/ そして、次のコマンドを実行します。
pip install -r requirements.txt
ユーティリティが JSON ファイルを生成する方法
- 実行する
snmpMibsToJsonConverter.py
ユーティリティディレクトリにあるファイル。 - カスタム MIB ファイルを配置するディレクトリ パスを指定します。
- 変換された JSON ファイルを生成するディレクトリ パスを指定します。デフォルトでは、ファイルはデフォルトのディレクトリに生成されます。 [LogicMonitorコレクタディレクトリ]/snmpdb/custom。ただし、別のディレクトリを指定することもできます。
- ユーティリティは MIB ファイルを変換し、指定したディレクトリに JSON ファイルを生成します。
- JSON ファイルが別のディレクトリに生成された場合は、ファイルをデフォルトのディレクトリにコピーします。 [LogicMonitorコレクタディレクトリ]/snmpdb/custom.
- コレクターが再起動すると、コレクターは JSON ファイルを使用して、対応する SNMP トラップを変換します。
ご注意: 両方に存在する共通のエンタープライズ JSON ファイルの場合、 [LogicMonitorコレクタディレクトリ]/snmpdb/core と [LogicMonitorコレクタディレクトリ]/snmpdb/custom ディレクトリ内に共通のトラップまたは OID がこれらの JSON ファイルに存在する場合、SNMP トラップはカスタム ディレクトリに存在する JSON ファイルを使用して変換されます。排他的トラップまたは OID の場合、SNMP トラップ変換は対応する JSON ファイルに従って機能します。
質問がある場合、またはユーティリティの使用中に問題が発生した場合は、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 はユーティリティによってすでにコンパイルされているため、このエラーは無視できます。