Github user geomacy commented on the issue:
https://github.com/apache/brooklyn-server/pull/940
Great comments @ahgittin. Some thoughts in response:
> It would seem better to me, rather than always setting a logging
diagnostic context, to deduce that information dynamically when we log, e.g. by
calling to Tasks.current() when we log. Is that possible?
I'm sure it would be possible to do this by writing a custom version of the
appenders we are currently, though we'd need to look into how best to do this
(we're now using Apache log4j2 as the slf4j implementation in Karaf but still
using Logback for tests). On the other hand it seems like it would be quite an
overhead to check `Tasks.current()` and work out task/entity ids for every log
message, don't you think? The beauty of the "context" approach is that you set
it up once, high up in the stack. It doesn't matter too much if that's a
slightly expensive operation, as subsequent logging operations lower in the
stack ignore it (it's only the output layout that takes any notice of the
context).
> Suggest logging without spaces and always including something in the
"diagnostic" column to make it easier to strip fields. And it's nice if columns
mostly align, though with a varying-length list this won't happen.
Good ideas, I'll make those changes.
> Suggest including some task-hierarchy as well. Full task-hierarchy and
entity-hierarchy is rather much though I think. So in light of the above, I'd
go for a pattern like TaskID@EntityID, no ancestors, dropping @EntityID if no
entity, and just doing - if no task.
I think that's good; the one thing it loses is the ability to filter lines
by the ids of any entity in the app, e.g. with a three tier app example with
log `2018-01-23T17:52:27,032 [q62iiw0gil, pvvwi14b2v, zx9u0hwehk]` I can filter
on `zx9u0hwehkz` to get logs for that Tomcat entity, on `pvvwi14b2v` to get
logs for any entity in the web cluster, and on `q62iiw0gil` to see all logs for
that given app. How about adding task id but retaining the full stack of
entity ids (which will rarely be terribly deep)? In any case I'll add task ids.
For transient tasks I'll see if I can add in your point (1). For (2) it's
more complicated, maybe that's something we can look into as a separate step.
> Lastly FYI some of the places where we don't have an entity context I
think are probably things we should fix.
That seems likely. It would be good to identify such points and fix them
up. I'll have a look at this (but again this is something that can be done in a
separate commit).
---
