[Erik Jones - Wed at 09:31:48AM -0500]
> I use cacti (http://cacti.net) which does the same thing that munin
> does but in php instead. Here's what I use to db stats to it (again,
> php):

I haven't tried cacti, but our sysadm has done a little bit of research
and concluded "cacti is better". Maybe some day we'll move over.

Munin is generating all the graphs statically every fifth minute, while
cacti generates them on demand as far as I've understood. The munin
approach is pretty bloat, since one usually would watch the graphs much
more seldom than what they are generated (at least, we do). That's not
really an argument since CPU is cheap nowadays - but a real argument is
that the munin approach is less flexible. One would like to adjust the
graph (like, min/max values for both axis) while watching quite some
times.

> $actives_sql = "SELECT COUNT(*)
> FROM pg_stat_activity
> WHERE current_query NOT ILIKE '<idle>'
> AND now() - query_start > '1 second';";

So this one is quite similar to mine ...

> $db_stat_sql = "SELECT {$argv[2]}
> FROM pg_stat_database
> WHERE datname='$db_name';";

I was not aware of this view - it can probably be useful for us. I will
add this one when I get the time ... (I'm at vacation now).


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On 3/21/07, Erik Jones <erik@myemma.com> wrote:
>
>
> On Mar 21, 2007, at 4:13 PM, Tobias Brox wrote:
>
> [Erik Jones - Wed at 09:31:48AM -0500]
>
> I use cacti (http://cacti.net) which does the same thing that munin
> does but in php instead. Here's what I use to db stats to it (again,
> php):
>
>
> I haven't tried cacti, but our sysadm has done a little bit of research
> and concluded "cacti is better". Maybe some day we'll move over.
>
> Munin is generating all the graphs statically every fifth minute, while
> cacti generates them on demand as far as I've understood. The munin
> approach is pretty bloat, since one usually would watch the graphs much
> more seldom than what they are generated (at least, we do). That's not
> really an argument since CPU is cheap nowadays - but a real argument is
> that the munin approach is less flexible. One would like to adjust the
> graph (like, min/max values for both axis) while watching quite some
> times.
>
>
> Well, by "default", Cacti polls all of the data sources you've set up
> every five minutes as well as that's how the docs instruct you to set up the
> cron job for the poller. However, with a little understanding of how the
> rrdtool rras work, you could definitely poll more often and simply edit the
> existing rras and datasources to expect that or create new ones. And, yes,
> the graph customization is pretty cool although for the most part the just
> map what's available from the rrdtool graph functionality. If you do decide
> to set up Cacti I suggest you go straight to the faq section of the manual
> and read the part about going from a simple script to a graph. The main
> manual is almost entirely centered on the built-in networking (e.g. snmp)
> data sources and, as such, doesn't do much for explaining how to set up
> other data sources.
>


Has anyone had experience setting up something similar with Nagios? We
monitor servers using nagios and not having to install additional software
(cacti/munin) for postgres resource usage monitoring would be great.

Thanks in advance!

CAJ CAJ wrote:
>
>
> On 3/21/07, *Erik Jones* <erik@myemma.com <mailto:erik@myemma.com>> wrote:
>
>
> On Mar 21, 2007, at 4:13 PM, Tobias Brox wrote:
>
>> [Erik Jones - Wed at 09:31:48AM -0500]
>>> I use cacti (http://cacti.net) which does the same thing that
>>> munin
>>> does but in php instead. Here's what I use to db stats to it
>>> (again,
>>> php):
>>
>> I haven't tried cacti, but our sysadm has done a little bit of
>> research
>> and concluded "cacti is better". Maybe some day we'll move over.
>>
>> Munin is generating all the graphs statically every fifth minute,
>> while
>> cacti generates them on demand as far as I've understood. The munin
>> approach is pretty bloat, since one usually would watch the graphs
>> much
>> more seldom than what they are generated (at least, we do).
>> That's not
>> really an argument since CPU is cheap nowadays - but a real
>> argument is
>> that the munin approach is less flexible. One would like to
>> adjust the
>> graph (like, min/max values for both axis) while watching quite some
>> times.
>
> Well, by "default", Cacti polls all of the data sources you've set
> up every five minutes as well as that's how the docs instruct you to
> set up the cron job for the poller. However, with a little
> understanding of how the rrdtool rras work, you could definitely
> poll more often and simply edit the existing rras and datasources to
> expect that or create new ones. And, yes, the graph customization
> is pretty cool although for the most part the just map what's
> available from the rrdtool graph functionality. If you do decide to
> set up Cacti I suggest you go straight to the faq section of the
> manual and read the part about going from a simple script to a
> graph. The main manual is almost entirely centered on the built-in
> networking ( e.g. snmp) data sources and, as such, doesn't do much
> for explaining how to set up other data sources.
>
>
>
> Has anyone had experience setting up something similar with Nagios? We
> monitor servers using nagios and not having to install additional
> software (cacti/munin) for postgres resource usage monitoring would be
> great.

a lot of nagios plugins can supply performance data in addition to the
OK/WARNING/CRITICAL state information - there are a number of solutions
out there that can take that information and graph it on a per
hosts/server base automatically - examples for such addons are
nagiosgrapher and n2rrd(or look at www.nagiosexchange.org it has a large
number of addons listed).


Stefan

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly