SNMP input plugin

The smidump function looks for mib dependencies in its pre-configured path lists. You may need to provide the paths to locations of MIBs in your particular environment.

You can avoid to avoid a failed to locate MIB module error by providing the additional path configuration information with:

See the "MODULE LOCATIONS" section of the smi_config documentation for more info.

Set the SMIPATH env var with the path to your mibs. Be sure to include a prepended colon (:) for the path.

$ SMIPATH=":/path/to/mibs/" smidump -k -f python CISCO-PROCESS-MIB.mib > CISCO-PROCESS-MIB_my.dic 

The other approach is to create a configuration file with the path option. For example, you could create a file called smi.conf.

path :/path/to/mibs/

Use the config with smidump:

$ smidump -c smi.conf -k -f python CISCO-PROCESS-MIB.mib > CISCO-PROCESS-MIB_my.dic

Use the get option to query for scalar values for the given OID(s). One or more OID(s) are specified as an array of strings of OID(s).

Example

input {
  snmp {
    get => ["1.3.6.1.2.1.1.1.0", "1.3.6.1.2.1.1.3.0", "1.3.6.1.2.1.1.5.0"]
    hosts => [{host => "udp:127.0.0.1/161" community => "public"}]
  }
}

The hosts option specifies the list of hosts to query the configured get and walk options.

Each host definition is a hash and must define the host key and value. host must use the format {tcp|udp}:{ip address}/{port}, for example host => "udp:127.0.0.1/161"

Each host definition can optionally include the following keys and values:

Specifying all hosts options

input {
  snmp {
    get => ["1.3.6.1.2.1.1.1.0"]
    hosts => [{host => "udp:127.0.0.1/161" community => "public" version => "2c"  retries => 2  timeout => 1000}]
  }
}

Specifying multiple hosts

input {
  snmp {
    get => ["1.3.6.1.2.1.1.1.0"]
    hosts => [{host => "udp:127.0.0.1/161" community => "public"}, {host => "udp:192.168.0.1/161" community => "private"}]
  }
}

Specifying IPv6 hosts

input {
  snmp {
    get => ["1.3.6.1.2.1.1.1.0"]
    hosts => [{host => "udp:[::1]/161" community => "public"}, {host => "udp:[2001:db8::2:1]/161" community => "private"}]
  }
}

The interval option specifies the polling interval in seconds. If polling all configured hosts takes longer than this interval, a warning will be emitted to the logs.

The mib_paths option specifies the location of one or more imported MIB files. The value can be either a dir path containing the imported MIB .dic files or a file path to a single MIB .dic file.

This plugin includes the IETF MIBs. If you require other MIBs, you need to import them. See Importing MIBs.

The oid_root_skip option specifies the number of OID root digits to ignore in the event field name. For example, in a numeric OID like "1.3.6.1.2.1.1.1.0" the first 5 digits could be ignored by setting oid_root_skip => 5 which would result in a field name "1.1.1.0". Similarly when a MIB is used an OID such "1.3.6.1.2.mib-2.system.sysDescr.0" would become "mib-2.system.sysDescr.0"

The oid_path_length option specifies the number of OID root digits to retain in the event field name. For example, in a numeric OID like "1.3.6.1.2.1.1.1.0" the last 2 digits could be retained by setting oid_path_length => 2 which would result in a field name "1.0". Similarly when a MIB is used an OID such "1.3.6.1.2.mib-2.system.sysDescr.0" would become "sysDescr.0"

Use the walk option to retrieve the subtree of information for the given OID(s). One or more OID(s) are specified as an array of strings of OID(s).

Queries the subtree of information starting at the given OID(s).

Example

  snmp {
    walk => ["1.3.6.1.2.1.1"]
    hosts => [{host => "udp:127.0.0.1/161" community => "public"}]
  }
}

The tables option is used to query for tabular values for the given column OID(s).

Each table definition is a hash and must define the name key and value and the columns to return.

Specifying a single table

input {
  snmp {
    hosts => [{host => "udp:127.0.0.1/161" community => "public" version => "2c"  retries => 2  timeout => 1000}]
    tables => [ {"name" => "interfaces" "columns" => ["1.3.6.1.2.1.2.2.1.1", "1.3.6.1.2.1.2.2.1.2", "1.3.6.1.2.1.2.2.1.5"]} ]
  }
}

Specifying multiple tables

input {
  snmp {
    get => ["1.3.6.1.2.1.1.1.0"]
    tables => [ {"name" => "interfaces" "columns" => ["1.3.6.1.2.1.2.2.1.1", "1.3.6.1.2.1.2.2.1.2", "1.3.6.1.2.1.2.2.1.5"]}, {"name" => "ltmPoolStatTable" "columns" => ["1.3.6.1.4.1.3375.2.2.5.2.3.1.1", "1.3.6.1.4.1.3375.2.2.5.2.3.1.6"]} ]
  }
}

The auth_pass option specifies the SNMPv3 authentication passphrase or password.

The auth_protocol option specifies the SNMPv3 authentication protocol or type

Controls this plugin’s compatibility with the Elastic Common Schema (ECS).

The priv_pass option specifies the SNMPv3 encryption password.

The priv_protocol option specifies the SNMPv3 privacy/encryption protocol.

The security_name option specifies the SNMPv3 security name or user name.

The security_level option specifies the SNMPv3 security level between Authentication, No Privacy; Authentication, Privacy; or no Authentication, no Privacy.

The name of the field under which SNMP payloads are assigned. If not specified data will be stored in the root of the event.

Setting a target is recommended when ecs_compatibility is enabled.

Add a field to an event

Disable or enable metric logging for this specific plugin instance by default we record all the metrics we can, but you can disable metrics collection for a specific plugin.

Add a unique ID to the plugin configuration. If no ID is specified, Logstash will generate one. It is strongly recommended to set this ID in your configuration. This is particularly useful when you have two or more plugins of the same type, for example, if you have 2 snmp inputs. Adding a named ID in this case will help in monitoring Logstash when using the monitoring APIs.

input {
  snmp {
    id => "my_plugin_id"
  }
}

Add any number of arbitrary tags to your event.

This can help with processing later.

Add a type field to all events handled by this input.

Types are used mainly for filter activation.

The type is stored as part of the event itself, so you can also use the type to search for it in Kibana.

If you try to set a type on an event that already has one (for example when you send an event from a shipper to an indexer) then a new input will not override the existing type. A type set at the shipper stays with that event for its life even when sent to another Logstash server.