On 6/15/2010 9:04 AM, Whit Blauvelt wrote: > On Tue, Jun 15, 2010 at 03:31:42AM -0700, John Doe wrote: > >> You could just use PNP and a custom script... >> http://docs.pnp4nagios.org/ > > PNP looks like a great project, when it matures. Someday it will be the > obvious answer, once someone writes a Nagios plugin that captures per-core > CPU load rather than just the generic system load, and the PNP crew enhances > their documentation with some working examples, or I learn German so I can > dive into the PNP forum (yes, they'll accept questions in English; but the > existing answers there mostly aren't.) > > I'd probably need to write that Nagios plugin myself, since the standard use > for Nagios is spotting systems in danger, not checking how work distributes > over CPU cores for performance tuning. Looks like it would need to read data > from /proc/stat. Once fed into Nagios, PNP could get it into rrd, and from > there out to graphs. Or would it make better sense to feed the data directly > to rrd and skip the> Nagios> PNP handoffs? > > For watching CPU cores in real time, a bunch of ssh sessions to htop gives > us a nice visual. The immediate question is how to get that the data graph > over time - one where a 16-core system isn't 16 separate graphs, but one > summary one. It does look like that's been solved for Cacti, if I can solve > my Cacti problem, and ignore its security problems. If snmp reports the data you want, you should be able to get either cacti or opennms to graph it. With opennms, if it isn't handled by default, that would involve describing the data collection, storage, and graphing steps in some xml config files. And by the way, opennms can monitor nagios clients - and jmx, wmi and a few other data sources too. -- Les Mikesell lesmikesell at gmail.com