| From: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Streaming replication status |
| Date: | 2010-01-15 17:30:27 |
| Message-ID: | 4B50A633.4060706@kaltenbrunner.cc |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Kevin Grittner wrote:
> Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
>
>> In many of the more secure environments I've worked in (finance,
>> defense), there is *no* access to the database server beyond what
>> comes out of port 5432 without getting a whole separate team of
>> people involved. If the DBA can write a simple monitoring program
>> themselves that presents data via the one port that is exposed,
>> that makes life easier for them.
>
> Right, we don't want to give the monitoring software an OS login for
> the database servers, for security reasons.
depending on what you exactly mean by that I do have to wonder how you
monitor more complex stuff (or stuff that require elevated privs) - say
raid health, multipath configuration, status of OS level updates, "are
certain processes running or not" as well as basic parameters like CPU
or IO load. as in stuff you cannot know usless you have it exported
through "some" port.
Stefan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2010-01-15 17:30:41 | Re: Streaming replication, loose ends |
| Previous Message | Heikki Linnakangas | 2010-01-15 17:29:36 | Re: Streaming replication, loose ends |