Search Exchange
Search All Sites
Nagios Live Webinars
Let our experts show you how Nagios can help your organization.Login
New ListingsDirectory Tree
check ICP Vortex GDT8x14RZ gdth
Owner
Hits
95042
Files:
| File | Description |
|---|---|
| Readme.txt | The Readme |
| snmptt.conf.vortex | Configuration for the controller for snmptt |
| srcd_redhat | Start script for srcd (Red Hat, Centos ...). Place in in /etc/rc.d/init.d |
| srcd_suse | Start script for srcd (Suse). Place in in /etc/init.d |
| vortex_critical_trap_wrapper | Script for wrapping critical traps |
| vortex_info_trap_wrapper | Script for wrapping informational traps |
| vortex_warning_trap_wrapper | Script for wrapping major traps as warning |
| VORTEX-TRAP-template.cfg | Sample service definition |
The srcd demon running on the host conatining the ICP Vortex controller will send a snmptrap in cause of trouble to the monitor host.
On the monitor host the trap ist received by snmptrapd and passed to snmptt. snmptt will process the trap as defined (see Installation and Appendix A. of Readme.txt).
Instead of passing the trapvalues directly via submit_check_result to nagios they are passed to several wrapper scripts. Do this provides several benefits like testing the Nagios construct without the need to send traps, filtering of values/characters and several other things.
There are three types of traps:
- MAJOR, wich will cause a warning in my case (Returncode 1)
- INFO, which will only change the plugin-output but stays green (Returncode 0)
- CRITICAL, which is an actual alarm and causes red (Returncode 2)
The wrapper script will address the host, the service definition , the returncode and the payload (i.e. the information) from the trap.
Doing it this way makes it very easy to use it in Nagios. All major definitions are done in a template (see Appendix B of Readme.txt). For every host you need a service definition (see Appendix C of Readme.txt)
Please modify it to your need.
Seperate it in 3 services has the benefit that you see what happened. If all types of alert will be in one service definition can cause that you will not take notice of a potential problem because every plugin output is replaced with a next.
On the monitor host the trap ist received by snmptrapd and passed to snmptt. snmptt will process the trap as defined (see Installation and Appendix A. of Readme.txt).
Instead of passing the trapvalues directly via submit_check_result to nagios they are passed to several wrapper scripts. Do this provides several benefits like testing the Nagios construct without the need to send traps, filtering of values/characters and several other things.
There are three types of traps:
- MAJOR, wich will cause a warning in my case (Returncode 1)
- INFO, which will only change the plugin-output but stays green (Returncode 0)
- CRITICAL, which is an actual alarm and causes red (Returncode 2)
The wrapper script will address the host, the service definition , the returncode and the payload (i.e. the information) from the trap.
Doing it this way makes it very easy to use it in Nagios. All major definitions are done in a template (see Appendix B of Readme.txt). For every host you need a service definition (see Appendix C of Readme.txt)
Please modify it to your need.
Seperate it in 3 services has the benefit that you see what happened. If all types of alert will be in one service definition can cause that you will not take notice of a potential problem because every plugin output is replaced with a next.
Reviews (0)
Be the first to review this listing!
