This is good to see. I wish structured logging were the norm rather than the exception, and having it be part of the stdlib in Go will hopefully push that “reach for this first” behavior across languages.
libxo is used in a lot of the FreeBSD base system utilities and a few other places and provides XML, JSON, or human-readable plain text or HTML output. It didn’t spawn a load of compatible things, but maybe the Go version will.
The biggest problem I’ve had with libxo is that it doesn’t give me an easy way of exporting a schema and checking for changes. I’d really like to be able to make my CLI tools automatically emit a schema for describing their output and to test multiple versions of this to ensure that I’ve not removed something from the output.
The other thing that I don’t like about libxo is that the JSON/XML/Human output decision is made early and the XML / JSON outputs don’t contain sufficient information to generate the human format. I’d like something like the format strings to be embedded in the structured output so that I can do things like sort by size but then print the size as 4 KiB not 4096.
I think there’s a huge difference of “running software you have downloaded” and “running software you(or your org) have written. I got more of a “in general, overall” vibe from it.
If I control the structure of the log output, I can also easily read it, or at least assuming you’ll not try to sabotage your ops team and change it deliberately all the time.
In my experience at one company we had everything we wrote to log in a certain way, and made that searchable via elasticsearch. Worked quite well, and still good enough for the (few) external things, that were, as described just the message wrapped in json.
There’s a proposal to turn each slog check into a sub-test. Then you can skip the ones that don’t make sense for your handler. That may help with the all-or-nothing property of the current slogtest API.
Thank you for slog and slogtest—as well as all the other material you’ve written to help show people how to customize slog.
There’s a proposal to turn each slog check into a sub-test. Then you can skip the ones that don’t make sense for your handler. That may help with the all-or-nothing property of the current slogtest API.
That sounds terrific. It would almost certainly have made it easier for me to test the two handlers I wrote about. I will edit the post to say that I was wrong (in a good way): the Go maintainers would consider a proposal to adjust slogtest! Thanks again for all your work on slog.
After I put a bunch of work into humane, I thought of an approach like this. It probably would have been easier, but I learned a lot about slog by writing the handler. So, no regrets.
This is good to see. I wish structured logging were the norm rather than the exception, and having it be part of the stdlib in Go will hopefully push that “reach for this first” behavior across languages.
libxo is used in a lot of the FreeBSD base system utilities and a few other places and provides XML, JSON, or human-readable plain text or HTML output. It didn’t spawn a load of compatible things, but maybe the Go version will.
The biggest problem I’ve had with libxo is that it doesn’t give me an easy way of exporting a schema and checking for changes. I’d really like to be able to make my CLI tools automatically emit a schema for describing their output and to test multiple versions of this to ensure that I’ve not removed something from the output.
The other thing that I don’t like about libxo is that the JSON/XML/Human output decision is made early and the XML / JSON outputs don’t contain sufficient information to generate the human format. I’d like something like the format strings to be embedded in the structured output so that I can do things like sort by size but then print the size as 4 KiB not 4096.
What do you think of this recent blog post arguing that logs are too varied for a strict schema? https://utcc.utoronto.ca/~cks/space/blog/programming/LogMessagesManySources
I think there’s a huge difference of “running software you have downloaded” and “running software you(or your org) have written. I got more of a “in general, overall” vibe from it.
If I control the structure of the log output, I can also easily read it, or at least assuming you’ll not try to sabotage your ops team and change it deliberately all the time.
In my experience at one company we had everything we wrote to log in a certain way, and made that searchable via elasticsearch. Worked quite well, and still good enough for the (few) external things, that were, as described just the message wrapped in json.
Thanks for the kind writeup.
There’s a proposal to turn each slog check into a sub-test. Then you can skip the ones that don’t make sense for your handler. That may help with the all-or-nothing property of the current slogtest API.
Thank you for slog and slogtest—as well as all the other material you’ve written to help show people how to customize slog.
That sounds terrific. It would almost certainly have made it easier for me to test the two handlers I wrote about. I will edit the post to say that I was wrong (in a good way): the Go maintainers would consider a proposal to adjust slogtest! Thanks again for all your work on slog.
I made a tinted slogger, but I did it by making an io.Writer that parses the incoming log line and then emitting a new log line to the underlying writer that is formatted with my colors and whatnot. https://github.com/spotlightpa/almanack/blob/master/pkg/almlog/colorize.go
After I put a bunch of work into
humane, I thought of an approach like this. It probably would have been easier, but I learned a lot aboutslogby writing the handler. So, no regrets.Also, thanks for introducing me to
logfmt.