Re: A question regarding postgresql log messages,
| От | AYahorau@ibagroup.eu |
|---|---|
| Тема | Re: A question regarding postgresql log messages, |
| Дата | |
| Msg-id | OF485766D6.5B01D158-ON432583DF.004900B8-432583DF.004A496E@iba.by обсуждение исходный текст |
| Ответ на | Re: A question regarding postgresql log messages, (nunks <nunks.lol@gmail.com>) |
| Список | pgsql-admin |
> Maybe you can use an informative log_line_prefix configuration, like
> the proposed pg_badger one:
> '%t [%p]: [%l-1] user=%u,db=%d,app=%a,client=%h '
> This should give you more information about the real importance of the
> error message to your use case. A FATAL error from user "postgres" or
> "[unknown]" can be potentially more problematic than an error from
> "user1". Also, postmaster messages won't have any of these variables
> set:
> 2019-03-21 12:21:32 -03 [1714]: [17-1] user=,db=,app=,client= LOG:
> checkpoint starting: time
Thank you so much for this suggestion.
I have another question. As far as I know there is a number of tools which collect some statistic concerning some Postgres issues
(connections, disconnections, queries, most frequent events etc.) based on Postgres Log and so on and so forth.
Do you know is there such a tool or a set of some actions which can give a precise final answer whether db server /db is operable or not?
So in this case does not matter how this answer can be got (postgres log parsing or some sql queries).
Thank you in advance,
Andrei Yahorau
From: nunks <nunks.lol@gmail.com>
To: AYahorau@ibagroup.eu,
Cc: pgsql-admin@postgresql.org, MikalaiKeida@ibagroup.eu
Date: 21/03/2019 16:31
Subject: Re: A question regarding postgresql log messages,
I think the error codes are documented mainly to be used in a
development environment, like when writing a function that needs to
listen to abnormal behaviour. If you're doing log based monitoring, I
think it's safe to rely on the severity shown in the log file itself.
The multiple possible severity levels for an error code are probably
due to PostgreSQL's modular architecture: maybe an error is relatively
negligible when raised to a client backend process, but a very severe
one when coming from the postmaster.
On 3/21/19, AYahorau@ibagroup.eu <AYahorau@ibagroup.eu> wrote:
> Hello PostgreSQL Community!
>
> I have a question regarding PostgreSQL log messages.
>
> Operating with PostgreSQL and configuring it we need to understand that
> everything goes well. To do this we monitor PostgreSQL log to be sure
> that database works properly indeed.
> We can do it based on error codes described here:
> https://www.postgresql.org/docs/11/errcodes-appendix.html
> and based on these error codes we can see if something is wrong.
>
> But in my view this is not enough. For example a message
> 53400 configuration_limit_exceeded
> can be represented in log with different severities: PANIC/ERROR/WARNING.
> And there are a number of other similar examples.
>
> So, the problem is that it is not easy to understand if the error is
> really critical for system or not.
>
> As far as I know a number of object-relational database management systems
> provide full list of possible messages and relations between them.
> It helps to understand that some critical error is not active any more and
> the database works properly.
>
> Is there such a list for PostgreSQL which contains all the possible events
> and their error codes. Is there a tool which helps to realize that some
> FATAL/PANIC message is not actual now?
>
> Thank You in advance,
> Andrei Yahorau
--
----------
“Life beats down and crushes the soul and art reminds you that you have one.”
- Stella Adler
> the proposed pg_badger one:
> '%t [%p]: [%l-1] user=%u,db=%d,app=%a,client=%h '
> This should give you more information about the real importance of the
> error message to your use case. A FATAL error from user "postgres" or
> "[unknown]" can be potentially more problematic than an error from
> "user1". Also, postmaster messages won't have any of these variables
> set:
> 2019-03-21 12:21:32 -03 [1714]: [17-1] user=,db=,app=,client= LOG:
> checkpoint starting: time
Thank you so much for this suggestion.
I have another question. As far as I know there is a number of tools which collect some statistic concerning some Postgres issues
(connections, disconnections, queries, most frequent events etc.) based on Postgres Log and so on and so forth.
Do you know is there such a tool or a set of some actions which can give a precise final answer whether db server /db is operable or not?
So in this case does not matter how this answer can be got (postgres log parsing or some sql queries).
Thank you in advance,
Andrei Yahorau
From: nunks <nunks.lol@gmail.com>
To: AYahorau@ibagroup.eu,
Cc: pgsql-admin@postgresql.org, MikalaiKeida@ibagroup.eu
Date: 21/03/2019 16:31
Subject: Re: A question regarding postgresql log messages,
I think the error codes are documented mainly to be used in a
development environment, like when writing a function that needs to
listen to abnormal behaviour. If you're doing log based monitoring, I
think it's safe to rely on the severity shown in the log file itself.
The multiple possible severity levels for an error code are probably
due to PostgreSQL's modular architecture: maybe an error is relatively
negligible when raised to a client backend process, but a very severe
one when coming from the postmaster.
On 3/21/19, AYahorau@ibagroup.eu <AYahorau@ibagroup.eu> wrote:
> Hello PostgreSQL Community!
>
> I have a question regarding PostgreSQL log messages.
>
> Operating with PostgreSQL and configuring it we need to understand that
> everything goes well. To do this we monitor PostgreSQL log to be sure
> that database works properly indeed.
> We can do it based on error codes described here:
> https://www.postgresql.org/docs/11/errcodes-appendix.html
> and based on these error codes we can see if something is wrong.
>
> But in my view this is not enough. For example a message
> 53400 configuration_limit_exceeded
> can be represented in log with different severities: PANIC/ERROR/WARNING.
> And there are a number of other similar examples.
>
> So, the problem is that it is not easy to understand if the error is
> really critical for system or not.
>
> As far as I know a number of object-relational database management systems
> provide full list of possible messages and relations between them.
> It helps to understand that some critical error is not active any more and
> the database works properly.
>
> Is there such a list for PostgreSQL which contains all the possible events
> and their error codes. Is there a tool which helps to realize that some
> FATAL/PANIC message is not actual now?
>
> Thank You in advance,
> Andrei Yahorau
--
----------
“Life beats down and crushes the soul and art reminds you that you have one.”
- Stella Adler
В списке pgsql-admin по дате отправления: