Yay, I knew I couldnt stay away from traps forever here!
I need to start dealing with traps and want to do it properly from the start. I should install a new server to install NSTI on it alone, right? NSTI will then fwd the traps over to my NagiosXI server, right?
Secondly, how much space should I give this server?
SNMP traps
SNMP traps
2 of XI5.6.14 Prod/DR/DEV - Nagios LogServer 2 Nodes
See my projects on the Exchange at BanditBBS - Also check out my Nagios stuff on my personal page at Bandit's Home and at github
See my projects on the Exchange at BanditBBS - Also check out my Nagios stuff on my personal page at Bandit's Home and at github
-
sreinhardt
- -fno-stack-protector
- Posts: 4366
- Joined: Mon Nov 19, 2012 12:10 pm
Re: SNMP traps
You only need NSTI if you wish to view more than the most recent trap per service. If that's that case, than NSTI is great for this use and you have a couple deployment options.
1) NSTI and XI on separate servers: This is great if you know that a ton of traps will be coming in, and the load might be a bit much for XI to handle as well. You would use NSTI to receive them, use the internal alerting and integration system to send alerts to XI when a specific filter is met. Both systems know whats going on, you have an easy way to see old and new traps, and it gives you a bit more filtering than just "Hey a trap came in!"
2) NSTI and XI on the same server, with NSTI forwarding via NRDP. Personally, this is a bit excessive and if you want the addition of NSTI filtering and alerting, I'd really suggest the separate servers route instead. If you insist on going this way, it should work fine, they will communicate over a local apache connection. One main point, is that snmptt.conf and other processed mibs should NOT have any exec lines that would send traps to XI, this should be entirely handled through nrdp.
3) Same as 2, except that nsti is ONLY used for viewing, and the standard snmptt to XI integration applies. In this case, traps come in to the server and are processed by snmptt and snmptrapd. Snmptt logs the traps in a database for NSTI to use, but DOES have exec lines in the config files, thus it directly sends to nagios.cmd instead of having NSTI do it through nrdp. This has the advantage of being a little quicker to XI, being a bit more native to how XI handles it by default, but does limit your ability to filter out traps that you don't care about or really care about.
With all that, how do you think you will want to go? There are definitely advantages and disadvantages to both. One thing I would note, is that NSTI is one of the products that aside from load, I would not worry about adding to an XI system as most if not all of those process are running already!
1) NSTI and XI on separate servers: This is great if you know that a ton of traps will be coming in, and the load might be a bit much for XI to handle as well. You would use NSTI to receive them, use the internal alerting and integration system to send alerts to XI when a specific filter is met. Both systems know whats going on, you have an easy way to see old and new traps, and it gives you a bit more filtering than just "Hey a trap came in!"
2) NSTI and XI on the same server, with NSTI forwarding via NRDP. Personally, this is a bit excessive and if you want the addition of NSTI filtering and alerting, I'd really suggest the separate servers route instead. If you insist on going this way, it should work fine, they will communicate over a local apache connection. One main point, is that snmptt.conf and other processed mibs should NOT have any exec lines that would send traps to XI, this should be entirely handled through nrdp.
3) Same as 2, except that nsti is ONLY used for viewing, and the standard snmptt to XI integration applies. In this case, traps come in to the server and are processed by snmptt and snmptrapd. Snmptt logs the traps in a database for NSTI to use, but DOES have exec lines in the config files, thus it directly sends to nagios.cmd instead of having NSTI do it through nrdp. This has the advantage of being a little quicker to XI, being a bit more native to how XI handles it by default, but does limit your ability to filter out traps that you don't care about or really care about.
With all that, how do you think you will want to go? There are definitely advantages and disadvantages to both. One thing I would note, is that NSTI is one of the products that aside from load, I would not worry about adding to an XI system as most if not all of those process are running already!
Nagios-Plugins maintainer exclusively, unless you have other C language bugs with open-source nagios projects, then I am happy to help! Please pm or use other communication to alert me to issues as I no longer track the forum.
Re: SNMP traps
#1 for sure. At AE I did #3 and it worked well, but I really wish I had NSTI for searching old alerts and stuff.
So, I'm going to request a VM tomorrow, any hint on how much space I should request? I can always expand I guess. And what about specs, if its just doing NSTI and nothing else, 2 vCPU and 8GB ram?
So, I'm going to request a VM tomorrow, any hint on how much space I should request? I can always expand I guess. And what about specs, if its just doing NSTI and nothing else, 2 vCPU and 8GB ram?
2 of XI5.6.14 Prod/DR/DEV - Nagios LogServer 2 Nodes
See my projects on the Exchange at BanditBBS - Also check out my Nagios stuff on my personal page at Bandit's Home and at github
See my projects on the Exchange at BanditBBS - Also check out my Nagios stuff on my personal page at Bandit's Home and at github
-
sreinhardt
- -fno-stack-protector
- Posts: 4366
- Joined: Mon Nov 19, 2012 12:10 pm
Re: SNMP traps
Any idea of how many traps per [insert time interval]? The whole process is pretty small, if you were to disable flat file logging and keep it to mysql only, 40-80GB should last a long time with traps. We are talking a few hundred bytes to a few kb per trap in most cases.
Nagios-Plugins maintainer exclusively, unless you have other C language bugs with open-source nagios projects, then I am happy to help! Please pm or use other communication to alert me to issues as I no longer track the forum.