honeycomb: incorporate into observation package and improve `internal/honey` API
Created by: Strum355
Why
- Previously,
internal/honey
was a very raw and low-level wrapping aroundlibhoney-go
. Handling of honeycomb being not enabled was not transparent, with nil checks being required before adding extra fields to an event that may not have been created. - To continue Erics dream of
internal/observation
being the central package for all things observability, and to avoid duplicated effort of usinginternal/observation
and honeycomb at the application logic level, honeycomb had to be transparently incorporated into it.
How
This PR reworks internal/honey
and internal/observation
in a multitude of ways:
- Creates an interface around a *libhoney.Event with extras, implemented as:
- A wrapper around a basic *libhoney.Event
- A noop event which should reduce
if event != nil
usage
- Incorporates honeycomb on a opt-in basis to
internal/observation.Context
, adding the log fields as data along with some extra meta like op name, num goroutines, mem usage, version etc - A
Dataset
type as a convenience/typed approach to specifying the dataset name, example https://github.com/sourcegraph/sourcegraph/pull/27964/files#diff-e53a07f3674b9472217df0b8970dd39a67f4f884b3f1e61e2e7a01ee77aaf526R78
Honeycomb keys are exported as snake case. This is a matter of preference and Im open to removing this being non-customizable, although the trend so far leans towards that in both our codebase and what's "suggested" by Honeycomb.
Example fields from precise-code-intel-worker
, available @ https://github.com/sourcegraph/sourcegraph/pull/28040