Open Stack

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 <doug at 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-request at 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