Shinken integrated SNMP Module¶
Contents:
SNMP Booster: How does it works¶
Overview¶
What is it¶
The SnmpBooster module allows Shinken Pollers to directly manage SNMP data acquisition. This is an all Python cross-platform SNMP module. It is tightly integrated with the Shinken Poller, Scheduler and Arbiter daemons to provide the best possible user experience.
Why use it¶
The SnmpBooster module is designed to be very efficient and scalable. It has a very flexible configuration method to make it easy to use with Shinken Monitoring Packs and Shinken discovery runners like genDevConfig.
This acquisition module was professionally designed and developed.
It is meant to be used by the very capable discovery engine genDevConfig (v3.0.5 and newer) originally developed for the Cricket SNMP monitoring tool and converted for use with Shinken.
It is one of the very few serious SNMP v2c implementation making use of SnmpGetBulk type requests.
How does it work¶
Shinken Integration¶
- 1 - The SnmpBooster Arbiter module reads the Shinken SnmpBooster configuration file(s). It reads the check commands and based on the values in the check commands that use the snmp_poller module it will creates a shared configuration cache using memcached/memcachedb. The memcache key is always the combination of the hostname. This permits to tie together Shinken Hosts and Services with the SNMP specific configuration. (MongoDB and Redis are planned to be supported in the future) The Scheduler daemon schedules Host and Service checks as it normally does.
- 3 - The SnmpBooster module will check that a memcache host key exists for the check to be launched. Then the SnmpBooster poller module will query all services related to a host for a given acquisition frequency in one pass. (all checks done every 2 minutes will be executed in bulk, same for those every 5 minutes)
- 5 - Check results are cached for the acquisition check_interval. The next time a check request for data from the same host is received from the Scheduler, the data will be fetched from memcache. Resulting is extremely low check latency.
- 2 and 6 - The SNMP checks still benefit from retries, timeouts, forced checks, dependencies and the powerful Scheduler daemon logic.
- 6 - The Scheduler daemon can still force an immediate re-check by flushing the cache. This is required for the dependency model.
Performance¶
SnmpBooster uses SNMP v2c getbulk for high efficiency, unless forced to use SNMP v2c get-next or SNMPv1 get-next. GetBulk uses a single request PDU to ask for multiple OIDs or even entire tables, instead of sending one request PDU per OID.
For example: A typical 24 port network switch with two uplinks might use 375 OIDS (8 OIDs per interface, plus general OIDs for chassis health, memory, cpu, fans, etc.). **SnmpBooster will only require around 4 request PDUs instead of 375 request PDUs*. Each PDU is a request packet which takes time to create, send get processed and return. More timeouts to manage, more connections, more impact on the remote device and more latency means much fewer checks per second.*
The SnmpBooster module supports automatic instance mapping for OIDs. (Ex. Based on the interface name it will figure out that the SNMP index(or instance) is 136. This is automatically handled by genDevConfig and SnmpBooster, no user input required. :-)
The generic SNMP configuration information is stored in the Shinken SnmpBooster INI files. There is a Defaults_unified.ini and a series of other Defaults files, one per discovery plugin for genDevConfig.
Important
genDevConfig plugins have all been converted to use the new dynamic instance mapping methods. You are now free to use most if not all Defaults*.ini files included with genDevConfig. 2012-10-28
Limitations¶
You should have memcached instances running on each poller responsible for snmp polling.
You should have your pollers with SnmpBooster in the same datacenter, as they need to be on the same machine with good connectivity to the active memcached instance.
SnmpBooster is not compatible with distributed pollers in multiple datacenters, sorry, the current design of SnmpBooster uses a single centralized memcached instance for storing the timeseries data. For distributed datacenters to be supported, each poller+scheduler+memcached must be realm restrained, which is not the case today.
Design specification¶
SnmpBooster design specification and current development status.
Data model¶
The information required to define the data is split in two locations.
The first location is the host and service Shinken configuration (You need to generate or write this)
- Device specific information * IP addresses, host_names, device types, instance keys * A DSTEMPLATE must be referred to in the Service definition * A static SNMP instance could be referred to in the Service definition * An SNMP instance MAP function could be referred to in the Service definition * A TRIGGERGROUP could be refered to in the Service definition
The second location is SNMP Defaults.* templates. (Here you can create new devices or add new data sources)
- DATASOURCE information * SNMP OID * Type of data and how can it be interpreted (GAUGE, COUNTER, COUNTER64, DERIVE, DERIVE64, TEXT, TIMETICK) * Data format preparation (Scaling the data for example bits to bytes) * Is there an instance to append to the
- Instance MAP function * Mapping the instance dynamically using a function * Data or rules related to the mapping function
- DSTEMPLATEs to associate DATASOURCE to actual device classes * List of DATASOURCES associated with a, for example, Cisco 1900 router. Which in turn can be applied to a Shinken service
- TRIGGER and TRIGGERGROUPS to apply thresholding rules * Define triggers and associate them with a TRIGGERGROUP name that can be applied to a Shinken Service
A final location containes rules to build your Shinken configuration.
- genDevConfig plugins create Shinken configurations
Installation and configuration¶
Reference Dictionnary¶
Troubleshooting¶
Graph templates¶
These are .graph files defined in your Shinken configuration directory. Refer to the Shinken graphite templates(Not yet created) or PNP4Nagios how-to documentation. The graph templates are independent from SnmpBooster and provide templates for any collected data from Shinken.
SNMP Booster: Install and setup¶
SnmpBooster Download Install and Configure¶
Downloads¶
- The SnmpBooster module and genDevConfig are currently in public beta prior to integration within Shinken. You can consult the design specification to see the current development status.
- https://github.com/xkilian/genDevConfig
- https://github.com/titilambert/mod-booster-snmp (use for_shinken_1.4 branch)
- Download and copy mod-booster-snmp/shinken/modules/snmp_booster to shinken/modules/
Requirements¶
The SnmpBooster module requires:
- Python 2.6+
- Shinken 1.2+ < 2.0
- PySNMP 4.2.1+ (Python module and its dependencies)
- ConfigObj (Python module)
- python-memcached
- memcachedb or memcached package for your operating system (ex. For Ubuntu: apt-get install memcachedb) See memcached note.
Note
On Ubuntu 12.04 the default instalation is on port 21201 instead of 11211. This causes the error ”[SnmpBooster] Memcache server (127.0.0.1:11211) is not reachable” when shinken starts. To change it, you must edit the file /etc/memcachedb.conf
The genDevConfig profile generator depends on:
- Perl 5.004+
- 4 perl modules available from CPAN and network repositories. genDevConfig/INSTALL has the installation details.
STRONGLY RECOMMENDED: Use the same version of Python and Pyro on all hosts running Shinken processes.
Installation¶
SnmpBooster:
- Install the dependencies
- Copy the snmp_booster directory from the git repository to your shinken/modules directory.
- Configuration steps are listed in the present web page.
genDevConfig:
- Download and extract the archive to your server.
- See genDevConfig/INSTALL on how to install and configure it.
Configuration¶
How to define the SnmpBooster module in the Shinken daemons¶
You need to modify shinken-specific.cfg, which is located in shinken/etc/shinken-specific.cfg
Arbiter daemon configuration¶
Simply declare the module inside arbiter definition:
modules SnmpBoosterArbiter
Scheduler daemon configuration¶
Simply declare the module inside scheduler definition:
modules SnmpBoosterScheduler
Poller daemon configuration¶
Simply declare the module inside poller definition:
modules SnmpBoosterPoller
SnmpBooster Module declaration¶
You have to declare all least 3 modules.
One for the Arbiter:
define module {
module_name SnmpBoosterArbiter
module_type snmp_booster
datasource /etc/shinken/snmpbooster_datasource/ ; SET THE DIRECTORY FOR YOUR Defaults*.ini FILES provided by genDevConfig
memcached_host 192.168.1.2 ; SET THE IP ADDRESS OF YOUR memcached SERVER
memcached_port 21201 ; default port for a memcached process
loaded_by arbiter
show_from_cache False
}
One for the Scheduler:
define module {
module_name SnmpBoosterScheduler
module_type snmp_booster
datasource /etc/shinken/snmpbooster_datasource/ ; SET THE DIRECTORY FOR YOUR Defaults*.ini FILES provided by genDevConfig
memcached_host 192.168.1.2 ; SET THE IP ADDRESS OF YOUR memcached SERVER
memcached_port 21201 ; default port for a memcached process
loaded_by scheduler
show_from_cache False
}
One for the Poller:
define module {
module_name SnmpBoosterPoller
module_type snmp_booster
datasource /etc/shinken/snmpbooster_datasource/ ; SET THE DIRECTORY FOR YOUR Defaults*.ini FILES provided by genDevConfig
memcached_host 192.168.1.2 ; SET THE IP ADDRESS OF YOUR memcached SERVER
memcached_port 21201 ; default port for a memcached process
loaded_by poller
show_from_cache False
life_time 1000 ; Nb of checks done before kill the worker (and restart an other one)
}
If you do not know the IP adress on which your memcache is listening, check under /etc/memcached.conf. Or do a:
netstat -a | grep memcached
If you are running a test on the local machine you can leave memcached on 127.0.0.1 (localhost), but if your poller, scheduler or arbiter is on a different machine, set the memcached to listen on a real IP address.
Parameters¶
module_name: | Module Name. Example: SnmpBoosterPoller |
---|---|
module_type: | Module type. Must be: snmp_booster |
datasource: | Datasource folder. Where all your Defaults*.ini are. Example: /etc/shinken/snmpbooster_datasource/ |
memcached_host: | Memcached host IP. Example: 192.168.1.2 |
memcached_port: | Memcached host port. Example: 21201 |
loaded_by: | Which part of Shinken load this module. Must be: poller, arbiter or scheduler. Example: arbiter |
show_from_cache: | |
Prefix output by FROM CACHE string when datas come from memcached. Usefull for debugging. Default: False |
How to define a Host and Service¶
Step 1¶
Create a template for your SNMP enabled devices.
Sample template:
cd shinken/etc/packs/network/
mkdir SnmpBooster
vi shinken/etc/packs/network/SnmpBooster/templates.cfg
To edit the file
define command {
command_name check_snmp_booster
command_line check_snmp_booster -H $HOSTNAME$ -C $SNMPCOMMUNITYREAD$ -V 2c -t $ARG1$ -i $_SERVICEINST$ -T $_SERVICETRIGGERGROUP$
module_type snmp_booster
}
Parameters for check_snmp_booster command¶
-H: | server hostname |
---|---|
-P: | SNMP port. Default: 161 |
-C: | SNMP community |
-V: | SNMP version |
-t: | dstemplate name |
-i: | instance mapping |
-T: | trigger group |
-b: | Use snmp getbulk requests. Default: False |
-M: | Instance mapping max_repetititon parameters for snmp getbulk requests. Default: 64 |
-m: | max_repetition parameters for snmp getbulk requests. Default: 64 |
define service {
name default-snmp-template
check_command check_snmp_booster!$_SERVICEDSTEMPLATE$!$_SERVICEINST$!$_SERVICETRIGGERGROUP
_inst None
_triggergroup None
max_check_attempts 3
check_interval 1
retry_interval 1
register 0
}
host {
name SnmpBooster-host
alias SnmpBooster-host template
check_command check_host_alive
max_check_attempts 3
check_interval 1
retry_interval 1
use generic-host
register 0
}
Step 2¶
Define some hosts and services. You would typically use genDevConfig or another configuration generator to create these for you.
Mandatory service arguments related to SNMP polling:
_dstemplate Cisco-Generic-Router ; Name of a DSTEMPLATE defined in the SnmpBooster config.ini file
snmpcommunityread which is set in your resource.cfg file
Optional service arguments related to SNMP polling with default values:
_inst None ; Could be numeric: 0, None or an instance mapping function like: map(interface-name,FastEthernet0_1)
_triggergroup None ; Name of the triggergroup defined in the SnmpBooster config.ini file to use for setting warning and critical thresholds
Sample Shinken host and service configuration:
# Generated by genDevConfig 3.0.0
# Args: --showunused -c publicstring 192.168.2.63
# Date: Thu Aug 30 17:47:59 2012
#######################################################################
# Description: Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 12.2(50)SE4, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2010 by Cisco Systems, Inc. Compiled Fri 26-Mar-10 09:14 by prod_rel_team
# Contact:
# System Name: SITE1-ASW-Lab04
# Location:
#######################################################################
define host {
host_name 192.168.2.63
display_name 192.168.2.63
_sys_location
address 192.168.2.63
hostgroups
notes
parents
use default-snmp-host-template
register 1
}
define service {
host_name 192.168.2.63
service_description chassis
display_name C2960 class chassis
_dstemplate Cisco-Generic-Router
_inst 0
use default-snmp-template
register 1
}
define service {
host_name 192.168.2.63
service_description chassis.device-traffic
display_name Switch fabric statistics - Packets per Second
_dstemplate Device-Traffic
use default-snmp-template
register 1
}
define service {
host_name 192.168.2.63
service_description if.FastEthernet0_1
display_name FastEthernet0_1 Description: Link to Router-1 100.0 MBits/s ethernetCsmacd
_dstemplate standard-interface
_inst map(interface-name,FastEthernet0_1)
use default-snmp-template
register 1
}
Here is an example configuration of the config.ini file¶
[DATASOURCE]
OidmyOidDefinition = .1.3.6.1.45.0
[myOidDefinition] ; Use the same name as the myOidDeiniftion, but omit the leading "Oid"
ds_type = DERIVE
ds_calc = 8,* ; RPN expression : Oid, 8, * Which means Oid * 8 = ds_calc
ds_oid = $OidmyOidDefinition
[DSTEMPLATE]
[myCiscoRouter]
ds = myOidDefinition
[TRIGGER]
[trigger1]
warning = RPN expression
critical = RPN expression
[trigger2]
warning = RPN expression
critical = RPN expression
[TRIGGERGROUP]
[CiscoRouterTriggers]
triggers = trigger1, trigger2</code>
SnmpBooster Troubleshooting¶
Check your config¶
- Have you defined the poller module name?
- Have you defined the correct path to the directory containing your Defaults*.ini files?
- Have you addded the Snmpbooster module to your arbiter, poller, scheduler?
- Have you added copied the genDevConfig templates.cfg in shinken/packs/network/SnmpBooster/
- Have you installed PySNMP, memcached and other dependencies?
Software version consistency¶
Shinken and SnmpBooster now require the same Python and Pyro version on all hosts running a Shinken daemon.
If you cannot use the packaged version of Python and its modules (Pyro, memcached, etc.). Use virtualenv to declare a python version to use and install all required modules in that virtualenv.
Software version requirements¶
Have you verified that the requirements are met. Python, PySNMP, Shinken, Pyro, memcached, etc.
Validate your check command arguments¶
Use the check_plugin command and comment out the module to learn what were the exact arguments sent by the poller. This will permit you to validate all the arguments, like snmp community string, inheritance, template application, etc.
Validate connectivity¶
- Take a packet trace using a tool like Wireshark to validate that the remote host is responding.
Has the host responded
- Is SnmpBooster repeating the request more often than the polling interval.
- If you are seeing repeated requests your device may have a compatibility issues.
- Save an snmpwalk of the device, get a packet trace using Wireshark, set the poller to debug and save the poller.log file (/var/log/shinken/pollerd.log). Send all three to the SnmpBooster developers.
Note
It is normal to see one or more bulkGet requests if you are getting large amounts of data. Ex. a 24 port switch will take 2-3 request packets.
Performance¶
Make sure you have a low latency connection to your memcache from the Poller. Your memcache server can be replicated to all your poller hosts that should also run memcache instances. Check that memcached is running: netstat -a | grep memcached
Faulty Template¶
A bad snmp_template file was distributed in the genDevConfig sample-config directory, there were two glaring errors.
This was fixed on 2012-10-16. Make sure you update your template, or use the data from the wiki.
Note that the template should be called: SnmpBooster-template.cfg to make it easier to troubleshoot in the logs. So when you search for SnmpBooster in your logs it will show up as well.
Log files¶
All warnings and errors generated by the SnmpBooster module start with “[SnmpBooster] error text” and are logged using the standard Shinken logger.
The Arbiter daemon can output initial configuration, loading of host keys and intervals in memcached type error messages. The Scheduler daemon can output scheduling and alert related messages. The Poller daemon can output messages related to instance mapping, acquisition timeouts, invalid community strings, cache failures and more. These are available in the Web interface, as they are placed in the check results for the service.
You can simply do a grep SnmpBooster * in your shinken/var directory to see the latest messages related to the SnmpBooster module. You can also sort messages by timestamp to make it easy to find where and when errors occurred.
cd shinken/var
grep SnmpBooster *
memcache persistence¶
If you restart your memcache server or memcache crashes, your poller will no longer be able to validate that a host exists in memcache prior to writing.
You should use memcachedb to achieve persistence in case of memcache failures.
Common errors returned by SnmpBooster in the log file¶
Errors should be fairly explicit and mean what they say, though there can be exceptions. Lets try to clear some of them.
Arbiter log errors¶
Missing ds_oid
This means that a variable in your OID definitions is missing, or your DATASOURCE is not named correctly or your ds_oid variable is missing. There is a typo in your ds_oid variable (ex. ds-oid, or ds_oid = $OidNameIncorrectFFFRA.%(instance)s).
Datasource not defined
Your DSTEMPLATE uses a DATASOURCE that doesn’t exist check the [DataSourceName] you are referring to. Does it contain the expected OID variable, $OidName.
Missing ds_type
The DATASOURCE always needs to have a ds_type definition, GAUGE, COUNTER, DERIVE, TEXT, TIMETICK, DERIVE64, COUNTER64.
Poller log errors¶
Problems with calculations, repeated polling, hosts not responding, etc.
Memcached errors¶
memcachedb and memcached do not use the same default port. Configure the correct memcachedb port to match what is declared in your SnmpBooster module under shinken-specific.cfg.
On Ubuntu 12.04 the default installation is on port 21201 instead of 11211. This causes the error [SnmpBooster] Memcache server (127.0.0.1:11211) is not reachable when Shinken starts.
To change it, you must edit the file /etc/memcachedb.conf
Design specification¶
What is it¶
The SnmpBooster module allows Shinken Pollers to directly manage SNMP data acquisition. This is an all Python cross-platform SNMP module. It is tightly integrated with the Shinken Poller, Scheduler and Arbiter daemons to provide the best possible user experience.
Design specification summary¶
- STATUS - DESIGN SPEC PERFORMANCE
- [Done] Functions as an integrated Shinken Poller module
- [Done] Necessary integration code commited to Shinken official release (Integrated starting at v1.2)
- [Done] Ability to collect thousands of SNMP metrics per second
- [Done] Be compatible with distributed data acquisition
- [Done] Collect data for a host/check_interval tuple via SNMP in a single pass
- [Done] Use all builtin Shinken scheduler logic for retries, forced checks, timeouts, dependencies, parents
- [Done] Store collected data for the duration of the check_interval in a memcached/membase
- [Done] On a restart, after the first collection, be able to pick up where the last check left and calculate derived values
- [Done] Forced check are not allowed within 30 seconds of last SNMP query to the same host/check_interval, all other requests get data from the cache.
- [Done] Only a single request to the host/check_interval via SNMP is allowed at a time, all other requests get data from the cache.
- STATUS - DESIGN SPEC USABILITY
- [Done] Usage documentation
- [xxxx] SkonfUI and Discovery usage documentation
- [xxxx] Provide sample configuration packs in Shinken
- [Done] Provide sample config.ini with examples of all types of data
- SNMP OIDS, DATASOURCES, DSTEMPLATES, TRIGGERS and TRIGGERGROUPS
- [Done] Directly compatible for use with [[https://github.com/xkilian/genDevConfig|genDevConfig]] Shinken SNMP configuration generator
- [Done] Provide meaningful feedback for users on errors
- [Done] Capture all tracebacks and convert them to actual error or warning messages
- STATUS - DESIGN SPEC FEATURES
- [Done] Return state and performance metrics
- [Done] Performance metrics can be returned in a Weathermap compatible format
- [Done] Configuration file format is ConfigObj INI
- [Done] Load all valid INI configuration files from a directory and merge them
- [Done] Load a single INI configuration file
- [xxxx] Load a list of INI configuration files
- [Done] Configuration file describes all generic acquisition parameters (OID, DATASOURCE, DSTEMPLATE, MAP, TRIGGER, TRIGGERGROUP)
- [Done] Supports Triggers which are calculation rules to determine states
- [Done] Triggers support an RPN (Reverse Polish Notation) calculation engine which includes mathematical and logical operators
- [Done] Each TRIGGER is associated with a severity level, WARNING or CRITICAL
- [Done] Multiple TRIGGERS can be associated with a TRIGGERGROUP
- [Done] Use builtin Python Operators
- [Done] Support DERIVE, TEXT, GAUGE and COUNTER data types
- [xxxx] Support TIMETICKS data type
- [Done] Support applying RPN based calculations to received metric for scaling or conversion purposes
- [Done] Use a Python SNMP library which supports asynchronous acquisition PySNMP
- [Done] Datasources can use rule based runtime instance mapping
- [Done] Set Snmp version as a check runtime option
- [Done] Set Snmp DSTEMPLATE as a check runtime option
- [Done] Set Snmp TRIGGERGROUP as a check runtime option
- [Done] Set Snmp COMMUNITY as a check runtime option
- [Done] Use Snmp version 2c GetBulk
- [xxxx] Support Snmp version 2c GetNext if GetBulk is not supported
- [xxxx] Support Snmp version 1 GetNext
- [xxxx] Set Snmp Timeout as a check runtime option, instead of a hardcoded value at 5 seconds
- STATUS - DESIGN SPEC MAINTAINABILITY
- [xxxx] Functions documented in the source code
- [Done] Critical functions documented in the source code
- [Done] Locking sections identified in the code
- [xxxx] Unit tests with at least 80% coverage
- [xxxx] Unit tests integrated with Shinken test suite
- [Done] Code hosted on github
- [xxxx] configuration validity and integrity checking of all INI files
- [xxxx] Pep8 compliant
- [xxxx] Pylint pass
genDevConfig Plugins - Compatibility status with SnmpBooster¶
- STATUS - genDevConfig maintained Plugins
- [Done] Avaya ES switches
- [Done] Avaya ERS routing switches
- [Done] Cisco 29x0 switches
- [Done] MIB-II Interfaces
- [Done] Cisco PIX/ASA
- [Done] JUNOS devices
- [Done] Cisco IOS routers
- [Done] NetSNMP unix hosts ** Validation required**
- [Done] Packeteer devices ** Validation required**
- [Done] Sensatronics devices ** Validation required**
- [Done] Foundry devices ** Validation required**
- [Done] Packeteer devices ** Validation required**
- [Done] Cisco CSS ** Validation required**
- [InProgress] New Cisco Access points
- STATUS - Other maintained Plugins
Tip
- [xxxx] Denotes a specification that is planned but not implemented
- [InProgress] Denotes a specification that is under development
- [Done] Denotes a specification that is implemented
SnmpBooster reference dictionary¶
SnmpBooster.ini dictionary¶
- There are five dictionaries:
DATASOURCE DICTIONARY¶
OidVariableName refers to an actual OID that can be queries using SNMP against the device on the network.
[VariableName] refers to a Datasource and all the information required to gather and prepare the data using SNMP ds_type refers to how the data should be prepared ds_calc refers to any scaling manipulations to make the data more understandable. This is an RPN expression, where the first variable is omitted, as it is always the $OidVariable ds_oid refers to the actual $OidVariable name. An instance identifier can be appended to the name to signify that an instance is provided by the Shinken service definition. This information is passed when the check is called. ...
DSTEMPLATE DICTIONNARY¶
[DsTemplateName] refers to the name of the DSTEMPLATE that will be referred to in the Shinken service definitions. ds refers to the list of DATASOURCES to be collected. If an instance is expected for the list of DATASOURCES, it MUST be the same instance for all Oids. If a different instance is required, use a second DSTEMPLATE.
TRIGGER DICTIONNARY¶
...
TRIGGERGROUP DICTIONNARY¶
...
MAP DICTIONNARY¶
SnmpBooster.ini example configuration¶
This example definition will be used to explain each section.
[DATASOURCE]
OidmyOidDefinition = .1.3.6.1.45.0
[myOidDefinition] ; Use the same name as the myOidDeiniftion, but omit the leading "Oid"
ds_type = DERIVE
ds_calc = 8,* ; RPN expression : Oid, 8, * Which means Oid * 8 = Total
ds_oid = $OidmyOidDefinition
[DSTEMPLATE]
[myCiscoRouter]
ds = myOidDefinition
[TRIGGER]
[trigger1]
warning = RPN expression
critical = RPN expression
[trigger2]
warning = RPN expression
critical = RPN expression
[TRIGGERGROUP]
[CiscoRouterTriggers]
triggers = trigger1, trigger2
SnmpBooster.ini configuring SNMP Datasources¶
The first location is generic data related to SNMP parameters.
- DATASOURCE information * SNMP OID * Type of data and how can it be interpreted (GAUGE, COUNTER, COUNTER64, DERIVE, DERIVE64, TEXT, TIMETICK) * Data format preparation (Scaling the data for example bits to bytes) * Is there an instance to append to the
- Instance MAP function * Mapping the instance dynamically using a function * Data or rules related to the mapping function
SnmpBooster.ini configuring SNMP DSTEMPLATES¶
- DSTEMPLATEs to associate DATASOURCE to actual device classes * List of DATASOURCES associated with a, for example, Cisco 1900 router. Which in turn can be applied to a Shinken service
SnmpBooster.ini setting triggers/thresholds¶
- TRIGGER and TRIGGERGROUPS to apply thresholding rules * Define triggers and associate them with a TRIGGERGROUP name that can be applied to a Shinken Service