Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Logging roadmap #100

Open
spacekitteh opened this issue Sep 27, 2023 · 0 comments
Open

Logging roadmap #100

spacekitteh opened this issue Sep 27, 2023 · 0 comments

Comments

@spacekitteh
Copy link

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:

  1. Refactor the TracerProvider and Tracer classes to be implemented in terms of generic SignallerProvider and Signaller types, which are parameterised by the signal output type (e.g. ImmutableSpan or Log), 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.
  2. Implement LoggerProvider and Logger in terms of SignallerProvider and Signaller
  3. Implement the Logs Bridge API (that is, implement the emit function; should be trivial given the prior two steps)
  4. Implement the remainder of the Logs SDK (most of this logic should already be in the SignallerProvider and Signaller implementations)
  5. Refactor the two SDK processors (Simple and Batch) to be parameterised by signal type. I don't think either of them actually depend on ImmutableSpans at the moment, other than overly-strict type annotations?
  6. Refactor the existing OTLP exporter code to be generic over the signal type.
  7. 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant