Re: [GENERAL] monitoring PostgreSQL

On 24/07/17 15:01, PAWAN SHARMA wrote: > > > > On Mon, Jul 24, 2017 at 7:28 PM, Tim Clarke > wrote: > > > > On 24/07/17 14:47, PAWAN SHARMA wrote: > > > > Hi Tim, > > > > Facing below issue > > > > [abc@test:/home/psharm89/nrpe-2.15]# >

Re: [GENERAL] monitoring PostgreSQL

On Mon, Jul 24, 2017 at 7:28 PM, Tim Clarke wrote: > > > On 24/07/17 14:47, PAWAN SHARMA wrote: > > > > Hi Tim, > > > > Facing below issue > > > > [abc@test:/home/psharm89/nrpe-2.15]# > > Redirecting to /bin/systemctl restart xinetd.service > > Failed to restart xinetd.service: Unit xinetd.servi

Re: [GENERAL] monitoring PostgreSQL

On 24/07/17 14:47, PAWAN SHARMA wrote: > > Hi Tim, > > Facing below issue > > [abc@test:/home/psharm89/nrpe-2.15]# > Redirecting to /bin/systemctl restart xinetd.service > Failed to restart xinetd.service: Unit xinetd.service failed to load: > No such file or directory. > [abc@test:/home/psharm8

Re: [GENERAL] monitoring PostgreSQL

On Mon, Jul 24, 2017 at 5:50 PM, PAWAN SHARMA wrote: > > On Mon, Jul 24, 2017 at 5:20 PM, Tim Clarke > wrote: > >> We use nagios for all alerting, it'll do what you need. >> >> Tim Clarke >> >> >> On 24/07/17 12:38, Achilleas Mantzios wrote: >> > pgbadger is a very nice reporting tool, overall,

Re: [GENERAL] monitoring PostgreSQL

On Mon, Jul 24, 2017 at 5:20 PM, Tim Clarke wrote: > We use nagios for all alerting, it'll do what you need. > > Tim Clarke > > > On 24/07/17 12:38, Achilleas Mantzios wrote: > > pgbadger is a very nice reporting tool, overall, albeit not exactly at > > the system side, but more to the DBA side.

Re: [GENERAL] monitoring PostgreSQL

We use nagios for all alerting, it'll do what you need. Tim Clarke On 24/07/17 12:38, Achilleas Mantzios wrote: > pgbadger is a very nice reporting tool, overall, albeit not exactly at > the system side, but more to the DBA side. > For system level monitoring maybe take a look here : > https://

Re: [GENERAL] monitoring PostgreSQL

pgbadger is a very nice reporting tool, overall, albeit not exactly at the system side, but more to the DBA side. For system level monitoring maybe take a look here : https://wiki.postgresql.org/wiki/Monitoring#check_postgres . Also you might want to write a script that parses logs for FATAL and

Re: [GENERAL] monitoring PostgreSQL

okmeter.io is good (though it's cloud-based and costs some money), I'm using it and definitely can recommend. There much more tools, see: https://wiki.postgresql.org/wiki/Monitoring On Mon, Jul 24, 2017 at 4:27 AM, PAWAN SHARMA wrote: > Hi All, > > > Please provide me a list of tools which we c

[GENERAL] monitoring PostgreSQL

Hi All, Please provide me a list of tools which we can use for monitoring PostgreSQL. -Monitor all the services and health of server -Able to send critical and warning alert on mail. OS: Redhat-7 PostgreSQL Version: 9.5.7 -Pawan

[GENERAL] Monitoring PostgreSQL with BMC Patrol and Sentry Monitoring Studio

Hi, I plan to use PostgreSQL on RHEL for one of our customers. They are already using BMC Patrol for monitoring various applications and databases (Oracle and SQL Server). They would like to continue using the same tool for Postgres too. It looks like Postgres is not supported out of box for BMC

[GENERAL] monitoring postgresql with Munin

I'm using munin to monitor a postgresql server, using the standard munin postgres methods, it gives me quite a comprehensive set of graphs. but, I can't figure out how to use this to monitor more than one postgres instance on the same server... I have 4 instances (on 4 different ports) on a

Re: [GENERAL] Monitoring PostgreSQL connections using cricket and

On 1/5/06, Steve Crawford <[EMAIL PROTECTED]> wrote: > > Resting Connections - connections that have no query information. I > > suspect these are connections starting up or shutting down, but feel > > free to clue me in. > > OK, this appears to be version-dependent but it can mean that > stats_que

Re: [GENERAL] Monitoring PostgreSQL connections using cricket and

Resting Connections - connections that have no query information. I suspect these are connections starting up or shutting down, but feel free to clue me in. OK, this appears to be version-dependent but it can mean that stats_query_string is false or that the user you are connecting as has no p