That said, I'm a huge fan of Cloudkick. Their software is ridiculously easy to install and use, and the web application makes it VERY easy to understand what's going on with your services. It's perfect if you're just monitoring one server -- it's free -- but even worth the money if you've got a whole cluster. If I could do it all over again, I'd definitely go with Cloudkick.
I don't get the logic of paying that much for Cloudkick at all. Monitoring tends to be a couple days work (at most) to setup perfectly and then very little on-going. Hardly worth $949 every month IMHO.
If you don't have a full time sys admin it's also one of those things that is very easy to put off or delay or just not keep on top of.
As for the data loss I can't think of a time I've ever wanted to see resource statistics for over a year ago and down times and outages are kept in a problem tracking system.
Scout,Monit,Hoptoad,New Relic, and Pingdom:
http://blog.scoutapp.com/articles/2010/10/19/monitor-rails-c...
For a reasonably priced hosted solution, check out cloudkick.com. It is also very good and let's you monitor ec2, Rackspace cloud servers, and your own boxes with an agent installed.
Also I use Supervisor (http://supervisord.org/) to launch all my processes and it is configured to send me an email if any of them grows beyond a memory threshold and/or crashes (in which case it also attempts to restart it a few times).
I am also using monit for immediate actions like restarting web server or checking some programs.
I manage both via puppet, that means I deploy a new host and the nagios configuration gets adjusted automatically with the corresponding services.
For performance data there are several tools like cacti, munin or collectd.
- Munin has iirc the problem thats it gets slowish as it polls all data from hosts then generate the carts for all hosts. Only a problem if you have many hosts...
- Collectd is a quite nice and fast monitoring solution (supports updates every second) and has advanced features like sending the data to multicast addresses. The only imho major drawback is that there comes no good webui bundled with collectd though many external uis exists.
EDIT: I forgot to mention icigna http://www.icinga.org/ a fork of nagios after some trademark problems iirc.
Monit and nagios are integrated with the ticketing system, e.g. recovery message closes automatically the corresponding ticket.
For monit i am using the monit pattern from[1]. Quite simple but IWFM. Nagios is a little bit more complicated. If you have any questions i added my mailaddresse to my profile.
You need to use exported resources for the nagios part. Therefore you have to enable Stored Configurations on the puppet server [2]. For the server part i use:
package { nagios3: ensure => present }
service{nagios3:
ensure => running,
enable => true,
require => Package[nagios3],
}
exec { "chmod_nagios":
command => "/bin/chmod 644 /etc/nagios3/conf.d/*",
refreshonly => true,
notify => Service["nagios3"]
}
file { "/etc/nagios3/conf.d": ensure => directory }
Nagios_host <<||>> { notify => Exec["chmod_nagios"] }
Nagios_service <<||>> { notify => Exec["chmod_nagios"] }
The client setup is quite easy, im using nagios-nrpe for the check. You have to deploy your own configuration files, i omit them here. package { nagios-nrpe-server: ensure => installed }
service { nagios-nrpe-server:
ensure => running,
require => Package[nagios-nrpe-server],
pattern => "/usr/sbin/nrpe"
}
@@nagios_host { "host_$hostname":
ensure => present,
address => $ipaddress,
host_name => $hostname,
use => "generic-host",
target => "/etc/nagios3/conf.d/host-$hostname.cfg",
}
@@nagios_service { "apt-${hostname}":
ensure => present,
use => "generic-service",
host_name => $hostname,
service_description => "apt check",
target => "/etc/nagios3/conf.d/apt.cfg",
check_command => "check_nrpe_1arg!check_apt"
}
[1] http://projects.puppetlabs.com/projects/1/wiki/Monit_Pattern...[2] http://projects.puppetlabs.com/projects/puppet/wiki/Using_St... You should not use sqlite, use mysql if you want to use the dashboard
[puppetmasterd]
storeconfigs = true
dbadapter = sqlite3
dblocation = /var/lib/puppet/storeconfigs.sqliteAlso working on integrating Splunk for analyzing log files and alerting on a few aspects.
I tried cacti once and god it's bad... It works, but the lack of a simple overview of how it works / how it's supposed to be configured is just too clear.
I'm keeping an eye on http://www.shinken-monitoring.org/ - might be worth checking out in the future if I ever get into large-scale-nagios problems.
alerts through jabber, email, and sms. i setup a monitor and cheapo eeebox to watch the data in realtime for my most important stuff.
All of the plugins are written in Ruby and the interface for reporting data is pretty simple.
I'm using it for everything from monitoring the KB/s that systems are swapping (and alert if it's anything measurable) as well as custom things like job queue depths.
We also use pingdom for external uptime monitoring.
- Newrelic
- Engineyard: http monitor
- Hoptoad for errors
- Some custom daemon scripts that fire emails when background processes aren't working.
I've hacked on both a bit, but they're great starts for small clusters.
It's built on top of Nagios, and makes the entire process very easy and straightforward to setup and run.
Edit: The community version is free, and I haven't run into any limitations on it. The paid version offers a few extra modules.
I use Cacti for graphing. I have some big gripes with it, but I've invested a lot of brain matter in it and it works.
http://www.opmanager.com (slow, unreliable j2ee app with a lot of features and great tech support.)