I'm very new to sawmill, but i have installed it and tested it against some data from our pix firewall. It is a nice tool.

We send our pix messages to a linux syslog server. My question is in regard to recommended setup. Would you please outline the pros/cons of setting up sawmill directly on the syslog server vs setting it up on another server and rsync'ing the logs over to that server via cron ?? I am trying to understand the advantages/disadvantages to running the software on a machine other than the syslog server where the original logfile is stored.

Thanks in advance,

Steve

The disadvantage of running Sawmill on another server in the example you've described is mostly with using more disk space (possibly 10s of gigabytes) and of course the additional hardware. If you are using rsync it's a very reliable way to deal with shuffling the log files from one server to another and will only move what's new and can be 'restarted' if there's a failure, however the process introduces an extra step of, some sort of monitoring that the logs have been moved 'successfully'. Sawmill will continue to process new logs as they appear so from Sawmill's standpoint when ever the logs arrive, they will be processed & added. From a user standpoint this could be an issue if 'up-to-date' stats are not readily available. If there's a period where the syslog server 'rolls' logs off the server and a rsync has not occurred it's also possible you'll experience data loss as a result of the files never being available on the server running Sawmill. Theses are pretty much common sense 'concerns' but also could be considered disadvantages depending upon the processes you'd need to add and how critical the data and analysis is.

The advantages of running Sawmill on another server are having a dedicated box & potentially a large amount of CPU/processing power dedicated to handling the processing of the logs, reporting and analysis. You'll have separated out the 'function' of the syslog server & the analysis so that might be what you want if you are trying to keep a period of historical data (> 30-90 days), additionally you'll have a backup of the raw logs on a separate server. The other part that's advantageous here is that you'll have the raw power to really deal well with the logs without compromising whatever primary functions exist on the server that's 'catching' syslog messages via the syslog server.

Ultimately this is a question of how much data you are looking to process and how much data you want to keep historically. PIX firewalls are generally very verbose and (depending on configuration) are known to generate large amounts of data daily based on traffic (~ 1GB/day or more). It's recommended that you consider 64-bit hardware depending upon the amount of historical data you are interested in keeping.

If you have other system configuration information you are after or best practice questions you can also refer those to support or our professional services department. We'd be happy to give you specific recommendations or work with you to give you a best practice for your environment based on your requirements.