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 alex@1.2.3.4 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 alex@1.2.3.4 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.
---