[openstack-dev] [oslo] About app-agnostic-logging-parameters
doug at doughellmann.com
Fri Jun 26 12:42:49 UTC 2015
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
> [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?
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.
More information about the OpenStack-dev