Structured logging/event creation

[nfisher]

Not sure whether people feels this is a fit but I was reading through the Honeycomb docs and noticed they have the concept of an "Event"[1] and provides the following interface;

  ev := libhoney.NewEvent()
  ev.Add(map[string]interface{}{
    "method": "get",
    "hostname": "appserver15",
    "payload_length": 27,
  }))
  ev.AddField("duration_ms", 153.12)
  defer ev.Send()

Looking at it sideways it seems a good fit for a standard structured logging interface when used with a printer. For services like honeycomb that have the concept of an "event" it could be shipped directly. If the spans context were submitted as part of the NewEvent() I could see it automatically tagging the event with related span info like parent, root, etc. In turn this would make the stackdriver trace console (see below) automagically pick-up related log lines without me having to manually tag them.

1 - https://docs.honeycomb.io/sdk/go/#building-and-sending-events

[codefromthecrypt]

meta comment: we discussed originally that census would add features that have at least one oss implementation. I dont know the landscape to know if there is an open source honeycomb

…

On Wed, 10 Oct 2018, 21:25 Nathan Fisher, ***@***.***> wrote: Not sure whether people feels this is a fit but I was reading through the Honeycomb docs and noticed they have the concept of an "Event"[1] and provides the following interface; ev := libhoney.NewEvent() ev.Add(map[string]interface{}{ "method": "get", "hostname": "appserver15", "payload_length": 27, })) ev.AddField("duration_ms", 153.12) defer ev.Send() Looking at it sideways it seems a good fit for a standard structured logging interface when used with a printer. For services like honeycomb that have the concept of an "event" it could be shipped directly. If the spans context were submitted as part of the NewEvent() I could see it automatically tagging the event with related span info like parent, root, etc. In turn this would make the stackdriver trace console (see below) automagically pick-up related log lines without me having to manually tag them. [image: screen shot 2018-10-10 at 10 21 59] <https://user-images.githubusercontent.com/18616/46739348-b7ffc500-cc76-11e8-8dc6-7156bbe0c4c7.png> 1 - https://docs.honeycomb.io/sdk/go/#building-and-sending-events — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#197>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD61yd3TQ_rt3wFLUiBTiM7YF8JYZgtks5ujfVfgaJpZM4XVVTm> .

[nfisher]

Thanks @adriancole!

Using a "printer" implementation (similar to the trace console printer) I would see it as a structured log interface that could be shipped to the ELK Stack or similar systems.

Essentially a log line and event are more or less synonymous. I guess I kind of look to OpenCensus as being a library for "observability" and events/logging is the one thing that's absent. I could see getting the root span ID in OpenZipkin/Jaegar and then using it to search for related "events" in ELK.

Feel free to close if it's out of scope.

[sebright]

#130 is related.

[nfisher]

Will close as #130 is related and I’ll look at adding anything under this that’s missing there.