go-neb

Kegan Dougal 14f49f2fde Use a text formatter which logs as key=val instead of JSON We exclusively view logs using `less` and `tail`. These do not read JSON well. Logging as JSON makes it a PITA to read logs and debug problems. We do not appear to make use of JSON logging, and have no good terminal-based structured log viewer either. As a result, I've now removed JSON logging from this project and replaced it with the standard `TextFormatter` (colors off). This still logs in a structured way: ``` time="2016-11-18 16:25:46.787373" level=info msg="Got filter ID" filter=717 syncing=1 user_id="@goneb:localhost" time="2016-11-18 16:25:46.787525" level=info msg="Starting sync" next_batch="s26928_287972_2_1029_26_1_2" syncing=1 user_id="@goneb:localhost" ``` So we can still analyse logs sanely at a later date should we need to. This feels like the best compromise here between pragmatism and ideals.	8 years ago
..
src	GZip logs by default	8 years ago
manifest	GZip logs by default	8 years ago

Kegan Dougal 14f49f2fde Use a text formatter which logs as key=val instead of JSON

We exclusively view logs using `less` and `tail`. These do not read JSON well.
Logging as JSON makes it a PITA to read logs and debug problems. We do not
appear to make use of JSON logging, and have no good terminal-based
structured log viewer either.

As a result, I've now removed JSON logging from this project and replaced it
with the standard `TextFormatter` (colors off). This still logs in a structured
way:

```
time="2016-11-18 16:25:46.787373" level=info msg="Got filter ID" filter=717 syncing=1 user_id="@goneb:localhost"
time="2016-11-18 16:25:46.787525" level=info msg="Starting sync" next_batch="s26928_287972_2_1029_26_1_2" syncing=1 user_id="@goneb:localhost"
```

So we can still analyse logs sanely at a later date should we need to. This
feels like the best compromise here between pragmatism and ideals.

8 years ago

src

GZip logs by default

8 years ago

manifest

GZip logs by default

8 years ago