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.'
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 |