Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/940
Cool.
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?
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.
Now turning our attention to _what_ we log:
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. So maybe (this is all pseudocode, I
haven't compared with actual code):
2018-01-23 11:52:20,118 INFO - Hello from something completely
outside Brooklyn
2018-01-23 11:52:20,118 INFO abcd1111 REST call from [email protected]
POST 0b to /v1/application/i6hk2jll5n/entity/z2scr3kcz/effector/sayHello
2018-01-23 11:52:20,118 INFO abcd1234@z2scr3kczj Hello from the
entity z2scr3kczj (effector sayHello, current task abcd1234)
And recording parent-child relationships at the time of child (entity and
task) creation, IE something like:
2018-01-23 11:52:20,118 DEBUG abcd0000 Task abcd0000 created: REST
call from [email protected] POST 780b to /v1/application
2018-01-23 11:52:20,118 DEBUG abcd0000 Creating new application
i6hk2jll5n
2018-01-23 11:52:20,118 DEBUG abcd0001@i6hk2jll5n Task abcd0001
created: initializing entity i6hk2jll5n, the root of an application
2018-01-23 11:52:20,118 DEBUG abcd0001@i6hk2jll5n Blah blah setting
up app i6hk2jll5n
2018-01-23 11:52:20,118 DEBUG abcd0001@i6hk2jll5n Creating new
entity z2scr3kczj "Tomcat Cluster" as child of i6hk2jll5n
2018-01-23 11:52:20,118 DEBUG abcd0002@i6hk2jll5n Task abcd0002
created: initializing entity z2scr3kczj "Tomcat Cluster", child of i6hk2jll5n
2018-01-23 11:52:20,118 DEBUG abcd0002@z2scr3kczj Blah blah blah
setting up entity z2scr3kczj
General principle is: we always know the entity and the task for any line,
to filter on either of those, and we always know (earlier in the log) the
location of the task and entity in the corresponding hierarchy.
However we might want exceptions for transient tasks, don't normally log
them, as otherwise we'll log lots of task creation for tiny tasks. But then we
get the counter-counter-example of a transient task that logs a message, for
that we _do_ want to know its hierarchy. So I'd say we only want to log the
`Task xxx created: <task title>` line for (1) non-transient tasks, and (2)
those tasks that log something. Doing (1) should be pretty easy. For (2) it
would be something like caching if we've logged the creation message, and if a
task tries to log something else, but hasn't yet logged the creation message,
we do that lazily (and probably include the start time in the log message as
the log timestamp will be out of sequence).
Lastly FYI some of the places where we don't have an entity context I think
are probably things we should fix. EG SSH log messages I suspect are coming
from an `SshMachineLocation` and I suspect _are_ using tasks nicely but are
_not_ using the entity's `ExecutionContext` to launch meaning the context
entity isn't being set. The context entity might be available on an ancestor
`Task` so that would be one option to "fix", at time of logging / inferring
context, walk the task `submittedBy` hierarchy. Maybe a better option would be
to see whether the `submit` call done by the `SshMachineLocation` can set the
entity context.
---
