Re: [HACKERS] some requests on auditing

[Pavel Stehule]

2016-08-31 16:00 GMT+02:00 David Steele :

> On 8/31/16 9:39 AM, David Steele wrote:
>
>> On 8/30/16 10:12 AM, Pavel Stehule wrote:
>>
>
> #3 is not likely without changes to logging in Postgres.  However, there
>> are plenty of tools for log analysis (e.g. ELK) that might help and a
>> Postgres extension that allows log messages to be directed elsewhere
>> (can't remember the name but Gabrielle or Simon would know).
>>
>
> Here's the extension I was thinking of:
>
> https://github.com/2ndquadrant-it/redislog
>
> This one is more general purpose:
>
> https://github.com/mpihlak/pg_logforward
>

many thanks you for these informations - I'll check it.

Regards

Pavel


> --
> -David
> da...@pgmasters.net
>

Re: [HACKERS] some requests on auditing

[David Steele]

On 8/31/16 9:39 AM, David Steele wrote:

On 8/30/16 10:12 AM, Pavel Stehule wrote:



#3 is not likely without changes to logging in Postgres.  However, there
are plenty of tools for log analysis (e.g. ELK) that might help and a
Postgres extension that allows log messages to be directed elsewhere
(can't remember the name but Gabrielle or Simon would know).


Here's the extension I was thinking of:

https://github.com/2ndquadrant-it/redislog

This one is more general purpose:

https://github.com/mpihlak/pg_logforward

--
-David
da...@pgmasters.net


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] some requests on auditing

[David Steele]

On 8/30/16 10:12 AM, Pavel Stehule wrote:


I am working on pgaudit customization for one my customer.

There are few requests:

1. flat format without complex types, without nesting - CSV is ideal.
2. all important attributes should be separated - is not possible to
search in original queries: table name, database name, role name, rights.
3. if it is possible - own log file
4. one statement can have more rows (flat format is required), but it
should be logged only once success/failed
5. any activity should be logged


You may want to take a look at pgaudit_analyze which I think addresses 
#1, #2, and #4:


https://github.com/pgaudit/pgaudit/tree/master/analyze

#3 is not likely without changes to logging in Postgres.  However, there 
are plenty of tools for log analysis (e.g. ELK) that might help and a 
Postgres extension that allows log messages to be directed elsewhere 
(can't remember the name but Gabrielle or Simon would know).


As for #5, which activities aren't being logged?

--
-David
da...@pgmasters.net


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] some requests on auditing

[Pavel Stehule]

Hi

I am working on pgaudit customization for one my customer.

There are few requests:

1. flat format without complex types, without nesting - CSV is ideal.
2. all important attributes should be separated - is not possible to search
in original queries: table name, database name, role name, rights.
3. if it is possible - own log file
4. one statement can have more rows (flat format is required), but it
should be logged only once success/failed
5. any activity should be logged

The point @4 is hard to implement - static audit should be linked with
result together. There is not any top level hook.

Regards

Pavel