1 of 1 people found this helpful
Well, I have a bit of experience with this and I will attempt to summarize it...
We have a fairly large network with a lot of syslogs and we send a good deal of these into Orion.
- Large quantities of syslogs coming into Orion don't seem to cause a huge performance hit except for database I/O.
- Poorly structured syslog alerts combined with large quantities of syslogs will cause huge performance problems for the system processing the alerts (the destination syslog server)
- Large quantities of syslog alert rules combined with large quantities of syslogs will cause performance problems on the system processing the alerts (the destination syslog server)
- Storing large quantities of syslogs in the database will cause performance problems for your entire Orion implementation because it's impacting the database
My ultimate conclusions are as follows...
- Only use Orion for alerting on the syslogs you need alerts for
- Don't use Orion for a syslog archive, set it for short retention of syslogs only; Orion isn't designed for syslog archiving, consider other applications for this such as Kiwi Syslog
- Be careful on how you structure your syslog alert rules
- Your first few rules should be to stop processing and delete any syslogs that you don't need (ie. Informational level logs assuming you send those to Orion)
- Have logs be processed against as few alert rules as possible to keep load down
- Rules are processed in the order in which they appear so keep this in mind when setting up your rules
These are my experiences and the conclusions that I have come to.
Hope this helps!
great info byrona...I've been fighting this for a while. I have all of my polling on "additional engines" and use the main NPM for SNMP traps and syslog, as well as all the other inherent stuff that comes with being the main engine. I will try to switch it around so syslogging is on another engine and see if that helps. thanks!