Re: Proposal: Adding json logging
| От | David Arnold |
|---|---|
| Тема | Re: Proposal: Adding json logging |
| Дата | |
| Msg-id | CAH6vsWJUwj1OSNNZcFan_wuR_6nEZ_Mcva5B=_iC6AmT6zdXYg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Proposal: Adding json logging (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Proposal: Adding json logging
|
| Список | pgsql-hackers |
>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@sss.pgh.pa.us> escribió:
David Fetter <david@fetter.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
В списке pgsql-hackers по дате отправления: