Re: Proposal: Adding json logging

>As to logfmt in particular, the fact that it's not standardized is probably a
show-stopper.
>Let's go with JSON.

I Agree. Though I don't want to deprecate the idea of logfmt enterly, yet.
In container infrastructure it's a defacto standard and it solves a real
problem. But I'm in favor to step back with that idea in favour of
prioritizing JSON.

El sáb., 14 abr. 2018, 11:03 a.m., David Arnold <dar(at)xoe(dot)solutions>
escribió:

> >I'm dubious that JSON is "easier on machines" than CSV.
>
> Under common paradigms you are right, but if we talk of line-by-line
> streaming with subsequent processing, then it's a show stopper. Of course,
> some log aggregators have buffers for that and can do Multiline parsing on
> that buffer, but
> 1. Not all log aggregators support it
> 2. Building a parser which reliably detects Multiline logs AND is easy on
> resources is probably not something a normal person can achieve quickly.
>
> So normally CSV is fine but for log streaming it's not the best, nor the
> most standard compliant way.
>
> El sáb., 14 abr. 2018, 10:51 a.m., Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> escribió:
>
>> David Fetter <david(at)fetter(dot)org> writes:
>> > I think a suite of json_to_* utilities would be a good bit more
>> > helpful in this regard than changing our human-eye-consumable logs. We
>> > already have human-eye-consumable logs by default. What we don't
>> > have, and increasingly do want, is a log format that's really easy on
>> > machines.
>>
>> I'm dubious that JSON is "easier on machines" than CSV.
>>
>> regards, tom lane
>>
>