Is there a way using config options to completely drop the unstructured_log part in the message logged?
tothlac opened this issue · comments
Log looks like this:
1> error_logger:error_msg("helo").
when=2021-05-19T11:57:43.836635+00:00 level=error pid=<0.167.0> at=: unstructured_log=helo
If I delete everything from the configuration I still have:
unstructured_log=helo
Is it possible to disable this word?
I would like to have something like
when=2021-05-19T11:57:43.836635+00:00 level=error pid=<0.167.0> at=: msg=helo
no that would be an unstructured log. To specify the structure of the log you would have to send in something like error_logger:error_msg(#{msg => "helo"}). which would let it specify the msg=helo value.
The problem is that we use our formatters to format all messages coming from third party application, where error_logger:xx_msg(string(), list(term())) calls are used. We want to have the same format for third party and for our messages.
So if I use following options in flatlog
logger:update_handler_config(
default, formatter,
{flatlog, #{
colored => true,
template => [
colored_start,
"message=", msg,
colored_end, "\n"
]
}}),
I would like to see
message=helo
not
message=unstructured_log=helo
In reality, the real reason why we would like to use flatlog is because you have colorized output, and otp guys did not implement it in logger. (in lager it is implemented as far as I remember, using option {color, true}) . As I see there is no option in logger application for supporting colored output.
Flatlog would be really useful for having colorized output, but if we can't completely turn off this unstructured_log part, probably developers would not really like it. What do you think, is it easily possible to turn it off, or is it easier if I create my logger formatter and implement colorization in that module? Actually I already have my formatter, it is just for different things.
That's an interesting question. My main goal for flatlog is to provide structured logging. At the very least I would see putting msg= as a key as counterproductive because it could clash with tool-assisted search when then structured logs encounter unstructured entries.
It could be possible to make it configurable (and you could use 'msg' there) but if what you're after is really color, it's probably not too hard to just lift code that does so based on log level and you would avoid the overhead of trying to parse structure on every line where none is expected.
Yes, that's also a doable solution. Probably I will implement colored output formatter tomorrow in my formatter. We also have special formatters at my company. For instance a log entry can be only one line, even if it comes from a third party application. So the logger formatter I had to implement had to deal with escaping new line characters. It must also convert escape sequences, since our logging format is json. Basically everything is converted to valid json format by the logger. Coloring is only important in console log, but in file logs we don't use it at all. I'm not quite sure about this ticket. You can close it, but I honestly think it would be probably better if people would be able to give a config option, something like:
"message="", msg, """ instead of msg. Then it would be printed as message="........". Anyways the ticket can be closed.