pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
OT: Munin (was Re: Determining server load from client)
8+ messages / 5 participants
[nested] [flat]

* OT: Munin (was Re: Determining server load from client)
@ 2007-03-21 07:39 Richard Huxton <dev@archonet.com>
  2007-03-21 10:13 ` Re: OT: Munin (was Re: Determining server load from client) Tobias Brox <tobias@nordicbet.com>
  0 siblings, 1 reply; 8+ messages in thread

From: Richard Huxton @ 2007-03-21 07:39 UTC (permalink / raw)
  To: Joe Healy <joe@omc-international.com.au>; +Cc: Dan Harris <fbsd@drivefaster.net>; pgsql-performance

Joe Healy wrote:
> (forgot to send to list)
> Dan Harris wrote:
>> architecture of the server hardware.  It would be very nice if I could 
>> check the load of the server at certain intervals to throttle the 
>> number of concurrent queries and mitigate load problems when other 
>> processes might be already inducing a significant load.

> I have installed munin (http://munin.projects.linpro.no/) on a few 
> systems. This lets you look at graphs of system resources/load etc. I 
> have also added python scripts which do sample queries to let me know if 
> performance/index size is changing dramatically. I have attached an 
> example script.

For general monitoring of a handful of servers, I've been impressed with 
munin. It's very simple to get it running and write your own plugins.

-- 
   Richard Huxton
   Archonet Ltd



^ permalink  raw  reply  [nested|flat] 8+ messages in thread

* Re: OT: Munin (was Re: Determining server load from client)
  2007-03-21 07:39 OT: Munin (was Re: Determining server load from client) Richard Huxton <dev@archonet.com>
@ 2007-03-21 10:13 ` Tobias Brox <tobias@nordicbet.com>
  2007-03-21 10:36   ` Re: OT: Munin (was Re: Determining server load from client) Richard Huxton <dev@archonet.com>
  2007-03-21 14:31   ` Re: OT: Munin (was Re: Determining server load from client) Erik Jones <erik@myemma.com>
  0 siblings, 2 replies; 8+ messages in thread

From: Tobias Brox @ 2007-03-21 10:13 UTC (permalink / raw)
  To: Richard Huxton <dev@archonet.com>; +Cc: Joe Healy <joe@omc-international.com.au>; Dan Harris <fbsd@drivefaster.net>; pgsql-performance

I have my postgres munin monitoring script at
http://oppetid.no/~tobixen/pg_activity.munin.txt (had to suffix it with
.txt to make the local apache happy).

I would like to see what others have done as well.




^ permalink  raw  reply  [nested|flat] 8+ messages in thread

* Re: OT: Munin (was Re: Determining server load from client)
  2007-03-21 07:39 OT: Munin (was Re: Determining server load from client) Richard Huxton <dev@archonet.com>
  2007-03-21 10:13 ` Re: OT: Munin (was Re: Determining server load from client) Tobias Brox <tobias@nordicbet.com>
@ 2007-03-21 10:36   ` Richard Huxton <dev@archonet.com>
  1 sibling, 0 replies; 8+ messages in thread

From: Richard Huxton @ 2007-03-21 10:36 UTC (permalink / raw)
  To: Tobias Brox <tobias@nordicbet.com>; +Cc: Joe Healy <joe@omc-international.com.au>; Dan Harris <fbsd@drivefaster.net>; pgsql-performance

Tobias Brox wrote:
> I have my postgres munin monitoring script at
> http://oppetid.no/~tobixen/pg_activity.munin.txt (had to suffix it with
> .txt to make the local apache happy).
> 
> I would like to see what others have done as well.

Well, I use Perl rather than shell, but that's just me.

The main difference is that although I downloaded a couple of simple 
pg-monitoring scripts from the web, I've concentrated on monitoring the 
application(s) instead. Things like:
  - number of news items posted
  - searches run
  - logins, logouts

The main limitation with it for me is the fixed 5-min time interval. It 
provides a slight irritation that I've got hourly/daily cron jobs that 
are being monitored continually.
-- 
   Richard Huxton
   Archonet Ltd



^ permalink  raw  reply  [nested|flat] 8+ messages in thread

* Re: OT: Munin (was Re: Determining server load from client)
  2007-03-21 07:39 OT: Munin (was Re: Determining server load from client) Richard Huxton <dev@archonet.com>
  2007-03-21 10:13 ` Re: OT: Munin (was Re: Determining server load from client) Tobias Brox <tobias@nordicbet.com>
@ 2007-03-21 14:31   ` Erik Jones <erik@myemma.com>
  2007-03-21 21:13     ` Re: OT: Munin (was Re: Determining server load from client) Tobias Brox <tobias@nordicbet.com>
  1 sibling, 1 reply; 8+ messages in thread

From: Erik Jones @ 2007-03-21 14:31 UTC (permalink / raw)
  To: Tobias Brox <tobias@nordicbet.com>; +Cc: Richard Huxton <dev@archonet.com>; Joe Healy <joe@omc-international.com.au>; Dan Harris <fbsd@drivefaster.net>; pgsql-performance


On Mar 21, 2007, at 5:13 AM, Tobias Brox wrote:

> I have my postgres munin monitoring script at
> http://oppetid.no/~tobixen/pg_activity.munin.txt (had to suffix it  
> with
> .txt to make the local apache happy).
>
> I would like to see what others have done as well.

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):

You basically call the script with the database name and the stat you  
want.  I have the active_queries stat set up as a gauge in cacti and  
the others as counters:

if(!isset($argv[1])) {    echo "DB name argument required!\n";    exit 
();
}

$stats = array('xact_commit', 'xact_rollback', 'blks_read',  
'blks_hit', 'active_queries');
if(!isset($argv[2]) || !in_array($argv[2], $stats)) {    echo  
"Invalid stat arg!: {$argv[2]}";
     exit();
}
require_once('DB.php');

$db_name = $argv[1];
if(DB::isError($db = DB::connect("pgsql://user@host:5432/$db_name"))) {
     exit();
}

if($argv[2] == 'active_queries') {
     $actives_sql = "SELECT COUNT(*)
                     FROM pg_stat_activity
                     WHERE current_query NOT ILIKE '<idle>'
                         AND now() - query_start > '1 second';";
     if(DB::isError($db_stat = $db->getOne($actives_sql))) {
         exit();
     }
     echo "$db_stat\n";
     exit();
}

$db_stat_sql = "SELECT {$argv[2]}
                  FROM pg_stat_database
                  WHERE datname='$db_name';";
if(DB::isError($db_stat = $db->getOne($db_stat_sql))) {
     exit();
}

echo "$db_stat\n";


erik jones <erik@myemma.com>
software developer
615-296-0838
emma(r)

^ permalink  raw  reply  [nested|flat] 8+ messages in thread

* Re: OT: Munin (was Re: Determining server load from client)
  2007-03-21 07:39 OT: Munin (was Re: Determining server load from client) Richard Huxton <dev@archonet.com>
  2007-03-21 10:13 ` Re: OT: Munin (was Re: Determining server load from client) Tobias Brox <tobias@nordicbet.com>
  2007-03-21 14:31   ` Re: OT: Munin (was Re: Determining server load from client) Erik Jones <erik@myemma.com>
@ 2007-03-21 21:13     ` Tobias Brox <tobias@nordicbet.com>
  2007-03-21 22:07       ` Re: OT: Munin (was Re: Determining server load from client) Erik Jones <erik@myemma.com>
  0 siblings, 1 reply; 8+ messages in thread

From: Tobias Brox @ 2007-03-21 21:13 UTC (permalink / raw)
  To: Erik Jones <erik@myemma.com>; +Cc: Tobias Brox <tobias@nordicbet.com>; Richard Huxton <dev@archonet.com>; Joe Healy <joe@omc-international.com.au>; Dan Harris <fbsd@drivefaster.net>; pgsql-performance

[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).




^ permalink  raw  reply  [nested|flat] 8+ messages in thread

* Re: OT: Munin (was Re: Determining server load from client)
  2007-03-21 07:39 OT: Munin (was Re: Determining server load from client) Richard Huxton <dev@archonet.com>
  2007-03-21 10:13 ` Re: OT: Munin (was Re: Determining server load from client) Tobias Brox <tobias@nordicbet.com>
  2007-03-21 14:31   ` Re: OT: Munin (was Re: Determining server load from client) Erik Jones <erik@myemma.com>
  2007-03-21 21:13     ` Re: OT: Munin (was Re: Determining server load from client) Tobias Brox <tobias@nordicbet.com>
@ 2007-03-21 22:07       ` Erik Jones <erik@myemma.com>
  2007-03-25 05:46         ` Re: OT: Munin (was Re: Determining server load from client) CAJ CAJ <pguser@gmail.com>
  0 siblings, 1 reply; 8+ messages in thread

From: Erik Jones @ 2007-03-21 22:07 UTC (permalink / raw)
  To: Tobias Brox <tobias@nordicbet.com>; +Cc: Richard Huxton <dev@archonet.com>; Joe Healy <joe@omc-international.com.au>; Dan Harris <fbsd@drivefaster.net>; pgsql-performance


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.

erik jones <erik@myemma.com>
software developer
615-296-0838
emma(r)

^ permalink  raw  reply  [nested|flat] 8+ messages in thread

* Re: OT: Munin (was Re: Determining server load from client)
  2007-03-21 07:39 OT: Munin (was Re: Determining server load from client) Richard Huxton <dev@archonet.com>
  2007-03-21 10:13 ` Re: OT: Munin (was Re: Determining server load from client) Tobias Brox <tobias@nordicbet.com>
  2007-03-21 14:31   ` Re: OT: Munin (was Re: Determining server load from client) Erik Jones <erik@myemma.com>
  2007-03-21 21:13     ` Re: OT: Munin (was Re: Determining server load from client) Tobias Brox <tobias@nordicbet.com>
  2007-03-21 22:07       ` Re: OT: Munin (was Re: Determining server load from client) Erik Jones <erik@myemma.com>
@ 2007-03-25 05:46         ` CAJ CAJ <pguser@gmail.com>
  2007-03-25 08:12           ` Re: OT: Munin (was Re: Determining server load from client) Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
  0 siblings, 1 reply; 8+ messages in thread

From: CAJ CAJ @ 2007-03-25 05:46 UTC (permalink / raw)
  To: Erik Jones <erik@myemma.com>; +Cc: Tobias Brox <tobias@nordicbet.com>; Richard Huxton <dev@archonet.com>; Joe Healy <joe@omc-international.com.au>; Dan Harris <fbsd@drivefaster.net>; pgsql-performance

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!

^ permalink  raw  reply  [nested|flat] 8+ messages in thread

* Re: OT: Munin (was Re: Determining server load from client)
  2007-03-21 07:39 OT: Munin (was Re: Determining server load from client) Richard Huxton <dev@archonet.com>
  2007-03-21 10:13 ` Re: OT: Munin (was Re: Determining server load from client) Tobias Brox <tobias@nordicbet.com>
  2007-03-21 14:31   ` Re: OT: Munin (was Re: Determining server load from client) Erik Jones <erik@myemma.com>
  2007-03-21 21:13     ` Re: OT: Munin (was Re: Determining server load from client) Tobias Brox <tobias@nordicbet.com>
  2007-03-21 22:07       ` Re: OT: Munin (was Re: Determining server load from client) Erik Jones <erik@myemma.com>
  2007-03-25 05:46         ` Re: OT: Munin (was Re: Determining server load from client) CAJ CAJ <pguser@gmail.com>
@ 2007-03-25 08:12           ` Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
  0 siblings, 0 replies; 8+ messages in thread

From: Stefan Kaltenbrunner @ 2007-03-25 08:12 UTC (permalink / raw)
  To: CAJ CAJ <pguser@gmail.com>; +Cc: Erik Jones <erik@myemma.com>; Tobias Brox <tobias@nordicbet.com>; Richard Huxton <dev@archonet.com>; Joe Healy <joe@omc-international.com.au>; Dan Harris <fbsd@drivefaster.net>; pgsql-performance

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



^ permalink  raw  reply  [nested|flat] 8+ messages in thread


end of thread, other threads:[~2007-03-25 08:12 UTC | newest]

Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2007-03-21 07:39 OT: Munin (was Re: Determining server load from client) Richard Huxton <dev@archonet.com>
2007-03-21 10:13 ` Tobias Brox <tobias@nordicbet.com>
2007-03-21 10:36   ` Richard Huxton <dev@archonet.com>
2007-03-21 14:31   ` Erik Jones <erik@myemma.com>
2007-03-21 21:13     ` Tobias Brox <tobias@nordicbet.com>
2007-03-21 22:07       ` Erik Jones <erik@myemma.com>
2007-03-25 05:46         ` CAJ CAJ <pguser@gmail.com>
2007-03-25 08:12           ` Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox