SNMP Traps Collector
Description
- Waits on the
/opt/opsview/snmptraps/var/run/snmp
fifo and once a trap is received it reads it and processes it via the traps processing lib available with theopsview-snmptraps-base
. - Once a trap is processed, it is either a result which is sent to the results forwarder fifo, or an exception which is sent to the
snmp-traps-exception-queue
- This also manages traces, start and stopping of traces set on a host.
- If a trace is enabled on a host, it runs that trace for the given duration in minutes or hours, max is 48hrs.
- The collector manages traces, starting, stopping, removal and update.
- Collector reads messages from the
snmptrace-request-<machine-ref>
queue and sends messages to theorchestrator-queue
andsnmp-traps-exception-queue
Dependencies
- The package requires
opsview-datastore
to be installed on the collector so that it can create trace documents. - The package requires access to the
opsview-messagequeue
to send traces and exceptions to theresult-snmp
. - The package requires access to the
opsview-messagequeue
to receive trace request message from the orchestrator
Installation
This is deployed when installating Opsview Monitor.
See MIBs for SNMP Traps and Gets to add your MIBs that are required for translating SNMP Traps.
Configuration
Configuration options available for the component:
-
The default configuration file is available in
/opt/opsview/snmptrapscollector/etc/snmptrapscollector.defaults.yaml
. -
The user can provide their configs in the same locations as above in the file named
snmptrapscollector.yaml
-
The defaults config file:
---
# This is the default configuration file.
# Please only make configuration changes in "snmptrapscollector.yaml".
#
snmptrapscollector:
queue_max_size: 0
worker_timeout_secs: 30
snmptrapstrace_channel_timeout: 10
orchestrator_reply_delay_secs: 10
traps_fifo: /opt/opsview/snmptraps/var/run/snmp
results_fifo: /opt/opsview/var/results.sock
snmp_config_file: snmptraps.cfg
script: /opt/opsview/snmptrapsbase/bin/snmptrap2opsview
local_message_queue: &local_message_queue
provider: rabbitmq
encoder: aes
encoder_key: ZHVtbXllbmNvZGVya2V5MTIzNA==
host: 127.0.0.1
port: 35672
management_port: 45672
user: opsview
password: opsview
snmptrapsexception:
queue: snmp-traps-exception-queue
messagequeue: *local_message_queue
durable: true
snmptrapstrace:
queue: snmptraptrace-exchange:direct.snmptrace-request-@:?
messagequeue: *local_message_queue
durable: true
orchestrator:
queue: orchestrator-queue
messagequeue: *local_message_queue
durable: true
registry:
provider: etcd
host: 127.0.0.1
port: 12379
datastore:
name: opsview-collector
cache: opsviewcache,max_age=5;max_size=10
connection:
provider: couchhttp
host: 127.0.0.1
port: 15984
user: opsview
password: opsview
Management
Managing the component
The command to start, stop and restart the component is:
$ sudo /opt/opsview/watchdog/bin/opsview-monit <start|stop|restart> opsview-snmptrapscollector
The component logs in the syslog like all other components. Note: You may see errors in syslog regarding No such file or directory: "/opt/opsview/snmptrapscollector/var/conf/snmptraps.cfg"
until the first SNMP Trap rule is associated with a host and a Reload is performed.
Updated over 1 year ago