search

rackerlabs / otter

Rackspace Auto Scale
http://www.rackspace.com/cloud/auto-scale/
Other
53 stars 28 forks source link

Structured formal logging #1107

Open manishtomar opened 9 years ago

manishtomar commented 9 years ago

Each log should have a message type that has corresponding structure associated with it. The structure includes the textual message, related fields along with their type in it. This structure can be used to induce ES mapping. The code logging will give message type and extra fields. The formatter will validate the fields based on type and log with textual message.

radix commented 9 years ago

I would like an API that uses a positional argument as the otter_msg_type, for example:

log.event("the-msg-type", **kwargs)

perhaps for errors we could do something like...

log.err_event(Failure_or_None, "the-msg-type")

manishtomar commented 9 years ago

@radix Yes. That is what I had in mind :)

manishtomar commented 9 years ago

I am having second thoughts about validating message field types. Since I will be partially doing what a JSON schema validator does, why not use that directly? i.e. describe each log type's fields as a JSON schema and validate it using a schema validator. This does seem like a lot of work for every log message.

@radix Any thoughts?

radix commented 9 years ago

@manishtomar I think json-schema is a decent way to specify our schemas, and is preferable to rolling our own schema system.

Here are my thoughts about our logging situation in general, and it mostly comes down to a priority list:

  1. support log.msg('event-key') and log.err(x, 'event-key') which gets converted to otter_msg_type in the output
  2. support structured serialization of exception objects
  3. implement support for strict schemas, where schemas are looked up by the otter_msg_type
  4. define our first schemas for the Cloud Feeds log message types, since those have a pretty strict format
  5. then define schemas for any messages where we're relying on a particular format for ahead-of-time indexing in ElasticSearch
  6. then implement schemas for everything ever

Each of these items should be (at least) a separate PR.