Excerpts from Lingxian Kong's message of 2015-06-26 12:14:57 +0800: > On Fri, Jun 26, 2015 at 12:03 AM, Doug Hellmann <d...@doughellmann.com> wrote: > > > > > The goal is to set up the default log format string to be the same in > > all projects, and have the context class provide application-specific > > values. So nova might set an instance as the resource but neutron might > > set a network or port as the resource. The deployer would still be able > > to rearrange the format string as they want, and always use the name > > "resource" in the location where they want the UUID of the thing being > > operated on. > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > Hi, Doug, > > We(Mistral team) have a need to log more resources at the same time, I > am thinking about how to solve it with oslo.log module without > duplicate effort, let me explain: > > In Mistral, there will be a workflow, consists of many tasks in it, > when the workflow is executed, we need to track the workflow and all > its tasks status in logs. So, we need to print workflow-id and task-id > in one line of log, e.g. > > 2015-06-26 04:09:50.326 19492 INFO > [c79b656f-f57f-4761-a270-138ee2417e54] > [c7635974-f57f-4761-a270-138ee241qefd] Task 'my_task' status change > [WAITING -> RUNNING] > > the first is workflow-id, the other is task-id. > > So, Doug, any suggestion?
A couple: 1. You could save a custom value to the resource id saved in the context. That might break things that parse the logs and expect the resource to be a single UUID. 2. You could use the workflow as the resource and include the task id in the messages explicitly in your code, as needed, using a prefix like "task-id:" so they are easy to find with a regex in a log parser. 3. We could add another common field for the "resource chain" and you could populate that. It would likely be empty for everyone else, though, and that would make the logs a little weird. 4. You could do #3, but in an application-specific way by overriding the default for the log format. This means deployers need to know about your special settings if they want to change their log format. I like option 2 best myself, with option 3 a distant second and the others not really seeming workable. Doug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
