I read a lot, that's clearly not the problem -- although sometimes I wish it was fewer technical documents and more fiction...
It somewhat surprised me when I was contacted out of the blue by someone from Packt Publishing to ask me to review a new book on Cacti: Cacti 0.8 Network Monitoring, by Dinanhkur Kundu and S. M. Ibrahim Lavlu (ISBN 13: 978-1-847195-96-8).
I love Cacti, it's clearly one of those network monitoring tools that are both easy to implement and easy to configure, and does a terrific job at aggregating historical information on what happened on machines. I had it implemented on roughly 200 systems with sometimes easily 40 graphs per system (switches, firewalls, etc), and although speed can be an issue, it is one that can be easily solved with Spine.
Back to the book: at first glance, it looks well written. I can't speak for its physical aspect since Packt won't ship to Canada, but it seems clear and to the point, with a good amount of background information on SNMP, which is often just what someone will be lacking when first trying out monitoring and Cacti. I'll write of my final opinion after reading the book in full though ;)
If there's at least one very good point: anyone could start with just this and a Ubuntu or Debian system and very quickly get rolling, since it mentions all the prerequisites of a Cacti install and the basic tricks on how to deal with installing, patching, and upgrading Cacti.
Expect my full report on it in a later post!
Update: I forgot to mention you can also check out this free chapter excerpt: http://www.packtpub.com/files/5968-cacti-sample-chapter-4-creating-and-using-templates.pdf
Showing posts with label monitoring. Show all posts
Showing posts with label monitoring. Show all posts
Thursday, 10 December 2009
Friday, 7 August 2009
Process Accounting data
I've been working since yesterday on a very interesting project: dealing with process accounting data, in the context of PCI-DSS compliance.
Process accounting is quite interesting because of how it's done. Here's a gross over-simplification, so sorry if I'm explaining it all wrong: the kernel, if it has "BSD Process accounting" enabled (and/or "version 3", as it is in Ubuntu, or at least on my Karmic system), waits for a special signal for userland to turn on process accounting and start writing binary data to a file on the filesystem.
But let's back up a little. What is this process accounting stuff?
Process accounting is a feature that allows you to track every command ever run on a system by any user. As the name says, it helps to "account" for all actions on a system and potentially know about actions that should not have occurred (say, a system that was compromised), or a command that caused an outage and it must be tracked down to who was responsible for an evil evil intervention on a production system without advising anybody... it requires both a kernel piece and a userland piece.
By default, on most systems, the kernel will already have everything enabled to support process accounting. You will only need to install the userland software.
On Ubuntu, you can achieve this with the command:
On Fedora system, you can get the same result with this command:
Once that is done, you will run 'sudo /etc/init.d/acct start' on Ubuntu, or 'service psacct start' on Fedora to start the process accounting (give the go to the kernel to write in the data file).
This is where things get complicated. I've searched a little for newer, more versatile tools to handle the binary data spewed out by my systems. It turns out that while acct (or psacct), in other words the GNU Accounting Utilities are great, they tend to be the only option for dealing with the kernel's data, and pretty much also force you to physically connect to a system in order to search for the information you want. Needless to say, this can tend to be problematic (say the system is now completely broken... what can you do?). It also brings up the issue that in the event of a compromise of the system, you can no longer trust the system, or the files it contains -- not even the accounting data. Backups are an option, so is rsync, but we were looking for something better. Something that would send to syslog for example, to be integrated into Splunk or some alerting utilities, to both centralize and potentially render the data as read-only as it could get.
That's where my scripts come in.
I've been busy writing a replacement for the lastcomm command as well as something to grab the data from the binary file and feed it into syslog. I've called it acct2syslog.pl.
This is still very early and experimental work, but I already have a Bazaar branch for it. Check it the Launchpad page! If you're interested in helping out, feel free to send me an email or message on IRC.
Obviously, I can't account for performance at this time. I just don't know how well it will deal with a system if there are thousands of commands running really fast. :)
Process accounting is quite interesting because of how it's done. Here's a gross over-simplification, so sorry if I'm explaining it all wrong: the kernel, if it has "BSD Process accounting" enabled (and/or "version 3", as it is in Ubuntu, or at least on my Karmic system), waits for a special signal for userland to turn on process accounting and start writing binary data to a file on the filesystem.
But let's back up a little. What is this process accounting stuff?
Process accounting is a feature that allows you to track every command ever run on a system by any user. As the name says, it helps to "account" for all actions on a system and potentially know about actions that should not have occurred (say, a system that was compromised), or a command that caused an outage and it must be tracked down to who was responsible for an evil evil intervention on a production system without advising anybody... it requires both a kernel piece and a userland piece.
By default, on most systems, the kernel will already have everything enabled to support process accounting. You will only need to install the userland software.
On Ubuntu, you can achieve this with the command:
sudo apt-get install acct
On Fedora system, you can get the same result with this command:
yum install psacct
Once that is done, you will run 'sudo /etc/init.d/acct start' on Ubuntu, or 'service psacct start' on Fedora to start the process accounting (give the go to the kernel to write in the data file).
This is where things get complicated. I've searched a little for newer, more versatile tools to handle the binary data spewed out by my systems. It turns out that while acct (or psacct), in other words the GNU Accounting Utilities are great, they tend to be the only option for dealing with the kernel's data, and pretty much also force you to physically connect to a system in order to search for the information you want. Needless to say, this can tend to be problematic (say the system is now completely broken... what can you do?). It also brings up the issue that in the event of a compromise of the system, you can no longer trust the system, or the files it contains -- not even the accounting data. Backups are an option, so is rsync, but we were looking for something better. Something that would send to syslog for example, to be integrated into Splunk or some alerting utilities, to both centralize and potentially render the data as read-only as it could get.
That's where my scripts come in.
I've been busy writing a replacement for the lastcomm command as well as something to grab the data from the binary file and feed it into syslog. I've called it acct2syslog.pl.
This is still very early and experimental work, but I already have a Bazaar branch for it. Check it the Launchpad page! If you're interested in helping out, feel free to send me an email or message on IRC.
Obviously, I can't account for performance at this time. I just don't know how well it will deal with a system if there are thousands of commands running really fast. :)
Sunday, 7 September 2008
More network-related tools: Network Discovery
I've found out about this other really nifty tool for networks. It's called NeDi (for NEtwork DIscovery), and is used to inventory devices connected to a network, the ports available on network devices, routes, modules, and other kinds of details that are just fun to have, or really useful to refer to from a central repository. It's nice too because it installs extremely well on Ubuntu; a wiki entry even exists to give a quick how-to on the installation and configuration process: https://help.ubuntu.com/community/NediHowTo.
Once you've gone through the steps described in the wiki entry, and run your first nedi.pl -cob (and waited the a minutes if you've happily asked it to map your whole corporate networks (oops!)), you can access the web interface and view all the information that was gathered, such as devices routes, firmware versions, models, serial numbers, and what end-user devices are connected where.
NeDi is also apparently part of the GroundWork OpenSource products, which is a pretty interesting suite of software if you want to roll out systems monitoring in your location.
Once you've gone through the steps described in the wiki entry, and run your first nedi.pl -cob (and waited the a minutes if you've happily asked it to map your whole corporate networks (oops!)), you can access the web interface and view all the information that was gathered, such as devices routes, firmware versions, models, serial numbers, and what end-user devices are connected where.
NeDi is also apparently part of the GroundWork OpenSource products, which is a pretty interesting suite of software if you want to roll out systems monitoring in your location.
Subscribe to:
Posts (Atom)