Re: PostgreSQL Required Monitoring

From: Andrew Kerber <andrew(dot)kerber(at)gmail(dot)com>
To: John R Pierce <pierce(at)hogranch(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: PostgreSQL Required Monitoring
Date: 2017-04-28 16:21:33
Message-ID: CAJvnOJYD-1eXkJFTOusU_FHVU=+sgViCHmjUTpOXDqdrDRUAag@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

yes, replication monitoring is high on the oracle list also, just forgot to
mention it. I ran into a similar transaction issue in Oracle when they
were running queries across database links and not committing. Its a
little known fact that any oracle query that runs across a database link
starts a transaction even without any Insert/update/delete command, so I
had to explain that to my developers.

On Fri, Apr 28, 2017 at 11:04 AM, John R Pierce <pierce(at)hogranch(dot)com> wrote:

> On 4/28/2017 7:39 AM, Andrew Kerber wrote:
>
>> I am a fairly experienced Oracle DBA, and we are starting to move in to
>> the PostgreSQL world. I would expect the standard monitoring items are
>> required for mission critical postgres apps, Ie, disk space, wal log space,
>> log monitoring, process counts,software running, connection available on
>> the correct port, CPU usage.
>>
>
> the nagios project has a rather handy monitoring script, check_postgres,
> this is a perl script that can be invoked from most any configurable
> monitoring framework, and has options to do 100s of different sorts of
> things, returning simple terse text output that can be parsed by said
> monitoring framework.
>
>
> Are there additional PostgreSQL specific items that need to be monitored?
>> if so, what items?
>>
>
>
> its always a good idea to watch for stale 'idle in transaction'
> connections, as they gum up the important VACUUM processing. you can make
> a simple query against pg_stat_activity to find the oldest 'idle in
> transaction', and if there are any more than, say, 1 hour old, its worth
> tracking down why they are happening and hammering the developers to fix
> it. oracle developers working in java seem to generate a lot of these
> (speaking from experience) if they aren't careful to avoid it. Postgres
> JDBC starts a transaction on a simple SELECT, and if the app then just sits
> there doing nothing, that transaction stays open indefinitely. I had a
> lot of pushback from developers insisting that SELECT's should not need
> commit.
>
> the one big thing I don't see mentioned in your list above is monitoring
> replication
>
> --
> john r pierce, recycling bits in santa cruz
>
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

--
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Igor Neyman 2017-04-28 16:53:07 Re: PostgreSQL Required Monitoring
Previous Message John R Pierce 2017-04-28 16:04:59 Re: PostgreSQL Required Monitoring