so far my searching around forums and poking with zabbix way of handling snmp traps seems to indicate it might (with some light manual scripting) work fine for cases when a trap only requires a single action performed and we don't care about state - but has a bunch of problems whenever we care about state, make triggers and so on.
basically, there is no notion of both enabling/disabling triggers on trap basis. there has been a suggestion to use a trigger that timeouts and is enabled on each matching trap - but this has a bunch of problems.
1. network load is somewhat increased as repetitive traps have to be sent;
2. according to information available on forums, during a timeout period further matching traps would be missed and would not extend trigger state;
3. it is possible (well, almost granted) that trigger would first switch off after a timeout period and only then receive a repeated trap. this defeats "sound an alarm when service is unavailable for 5 minutes".
4. it is not always possible to enable repetitive traps, only traps on state change.
using this approach has so many flaws that it is basically unfeasible.
now, it sould either be solved in zabbix itself, or by some workarounds (probably invloving more scripting).
in zabbix, there could be a notion of traps being able to enable and disable particular triggers (or, naming it differently, an ability for triggers to both go on and off upon specific triggers).
this seems to be nontrivial and probably not in-the-near-future possibility (though seeing it in updated 1.4 roadmap would be cool
).
another possibility would be making snmptrap.sh make some stuff up that can be queried by zabbix_agentd (the simplest example - creating and destroying files based on traps). this introduces more overhead, has some problems (fast state changes would be missed if state changes twice between two checks), but would provide much better overall functionality and eliminate the need to send repetitive traps.
or maybe i have missed a functionality in zabbix that allows this already ?
so, is there something that can be used for on/off traps in zabbix, what are the chances of something like that being implemented ?
has anybody deployed workarounds for on/off traps ? how well did they perform, what problems have arised ?
thanks.
basically, there is no notion of both enabling/disabling triggers on trap basis. there has been a suggestion to use a trigger that timeouts and is enabled on each matching trap - but this has a bunch of problems.
1. network load is somewhat increased as repetitive traps have to be sent;
2. according to information available on forums, during a timeout period further matching traps would be missed and would not extend trigger state;
3. it is possible (well, almost granted) that trigger would first switch off after a timeout period and only then receive a repeated trap. this defeats "sound an alarm when service is unavailable for 5 minutes".
4. it is not always possible to enable repetitive traps, only traps on state change.
using this approach has so many flaws that it is basically unfeasible.
now, it sould either be solved in zabbix itself, or by some workarounds (probably invloving more scripting).
in zabbix, there could be a notion of traps being able to enable and disable particular triggers (or, naming it differently, an ability for triggers to both go on and off upon specific triggers).
this seems to be nontrivial and probably not in-the-near-future possibility (though seeing it in updated 1.4 roadmap would be cool
).another possibility would be making snmptrap.sh make some stuff up that can be queried by zabbix_agentd (the simplest example - creating and destroying files based on traps). this introduces more overhead, has some problems (fast state changes would be missed if state changes twice between two checks), but would provide much better overall functionality and eliminate the need to send repetitive traps.
or maybe i have missed a functionality in zabbix that allows this already ?
so, is there something that can be used for on/off traps in zabbix, what are the chances of something like that being implemented ?
has anybody deployed workarounds for on/off traps ? how well did they perform, what problems have arised ?
thanks.
Comment