Re: Proposal: Adding json logging

>More specifically, JSON logging does seem to be a solution in search of a
problem. PostgreSQL's CSV logs are very easy to machine-parse, and if
there are corrupt lines being emitted there, the first step should be to
fix those, rather than introduce a new "this time, for sure" logging method.

>It's a matter of a few lines of code to convert CSV logs to a JSON format,
if you need JSON format for something else.

In the light of the specific use case / problem for this thread to be born,
what exactly would you suggest?

If it is fixing csv logs to guarantee to emit *one line per event,* then
this is equally a solution to the problem.

- It would be preferable under the light of "minimal code change"
- It would probably break some downstream parsers already in place.
- It would not try to solve this problem:
https://brandur.org/logfmt (machine
AND human)
- I don't know a lot of libraries that concluded csv logging is the best
way to move forward. (They could be all wrong, though)
- No off-the-shelve parser exists (you *need* to write code, as small as
it might be, it becomes a component in your stack and therefore a SPOF)

First point is definitely a strong one. Did I miss any additional arguments?

El dom., 15 abr. 2018 a las 12:24, Christophe Pettus (<xof(at)thebuild(dot)com>)
escribió:

>
> > On Apr 15, 2018, at 10:07, Christophe Pettus <xof(at)thebuild(dot)com> wrote:
> >
> >
> >> On Apr 15, 2018, at 09:51, David Arnold <dar(at)xoe(dot)solutions> wrote:
> >>
> >> 1. Throughout this vivid discussion a good portion of support has
> already been manifested for the need of a more structured (machine
> readable) logging format. There has been no substantial objection to this
> need.
> >
> > I'm afraid I don't see that. While it's true that as a standard, CSV is
> relatively ill-defined, as a practical matter in PostgreSQL it is very easy
> to write code that parses .csv format.
>
> More specifically, JSON logging does seem to be a solution in search of a
> problem. PostgreSQL's CSV logs are very easy to machine-parse, and if
> there are corrupt lines being emitted there, the first step should be to
> fix those, rather than introduce a new "this time, for sure" logging method.
>
> It's a matter of a few lines of code to convert CSV logs to a JSON format,
> if you need JSON format for something else.
>
> Remember, also, that every new logging format introduces a burden on
> downstream tools to support it. This is (still) an issue with JSON format
> plans, which had a much more compelling advantage over standard-format
> plans than JSON logs do over CSV.
>
> --
> -- Christophe Pettus
> xof(at)thebuild(dot)com
>
> --
[image: XOE Solutions] <http://xoe.solutions/> DAVID ARNOLD
Gerente General
xoe.solutions
dar(at)xoe(dot)solutions
+57 (315) 304 13 68
*Confidentiality Note: * This email may contain confidential and/or private
information. If you received this email in error please delete and notify
sender.
*Environmental Consideration: * Please avoid printing this email on paper,
unless really necessary.