Fryguy
commented
4 years ago The purpose of the [----] was originally supposed to support a message catalog. That is, when an error occurs it's given a pre-defined number, such as [1234]. Then separately a message catalog would be avaliable with the lookup values of all of those numbers. In the end it was never used, but we didn't remove it from the logs themselves because by that time a number of log scrapers had already been written expecting it to be there.
So, we can repurpose, but it would have to stay 4 characters long (and if we used something like the Base64 encoding set, this is 17_043_520 unique values).
ability to customize logging in the evm.log
Making this customizable (i.e. customer changeable) seems overly complicated. It seems more of a development task to write the logs with the proper grouping.
That being said, we'd have to talk out what these groupings would be, and considering there are (super-roughly) 19000 call sites (via grep of .info|warn|error), it seems kind of a monumental task to update all of them to be aware of this grouping.
A common use case, would be to group all tasks that are associated to a parent task (child tasks and grandchild tasks) with a common ID, so that grepping through logs of many appliances would be much faster.
This should already be done with the Q-task-id part of the log message (also called "tracking label") [ref]. Separately in containers, we've broken this out as "request_id" [ref]
Originating BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1605935
Description of request:
Looking for the ability to customize logging in the evm.log to be able to group like tasks together.
For example, the dashes that precede each evm.log line contains this:
[----]
Looking to have the user be able to customize what these dashes could represent, i.e:
[1000]
or
[AAAA]
And these IDs could be linked to similar tasks.
A common use case, would be to group all tasks that are associated to a parent task (child tasks and grandchild tasks) with a common ID, so that grepping through logs of many appliances would be much faster.
Another example would be to use a common ID for any task associated with a provider, or more granular, any refresh task associated with a provider could be given a unique ID.