- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 44
Open
Description
While implementing metrics will presumably be more challenging, implementing logging looks much easier in the meantime.
The basic OpenTelemetry.Logging.Core.Log
type is there (although the tracingDetails
field should be broken up as you can have a TraceID
without a SpanID
, and visa versa; likewise for the TraceFlags
), and the protos are there (for the OTLP protocol, anyway). It looks like it should be straightforward enough to:
- Refactor the
TracerProvider
andTracer
classes to be implemented in terms of genericSignallerProvider
andSignaller
types, which are parameterised by the signal output type (e.g.ImmutableSpan
orLog
), signal-specific extra data and hooks. Much of existing logic for these types is generic. This is probably the step with the most effort, but it shouldn't be difficult. - Implement
LoggerProvider
andLogger
in terms ofSignallerProvider
andSignaller
- Implement the Logs Bridge API (that is, implement the
emit
function; should be trivial given the prior two steps) - Implement the remainder of the Logs SDK (most of this logic should already be in the
SignallerProvider
andSignaller
implementations) - Refactor the two SDK processors (
Simple
andBatch
) to be parameterised by signal type. I don't think either of them actually depend onImmutableSpan
s at the moment, other than overly-strict type annotations? - Refactor the existing OTLP exporter code to be generic over the signal type.
- Implement the construction of the Log PDUs for the request. Should be trivial.
The first step will be the biggest change, and probably the only one which might break existing code (unless appropriate type aliases and possibly pattern synonyms are introduced); after that, each step can be implemented gradually in point releases if necessary.
Am I missing anything?
tonyalaribe, solomon-b and jmatsushita
Activity
hs-opentelemetry
PostgREST/postgrest#3140