OTLP log exporter

[alanwest]

This is a first cut at an OTLP log exporter. It was relatively simple to do a proof-of-concept for this. Much of the code is nearly the same as the trace exporter. As such, there's definitely an opportunity to abstract out common functionality between traces and logs (likely benefitting metrics as well). I'll work on this.

Code duplication aside, I wanted to put this PR out there beginning a discussion of how we might ship this functionality. Currently, I have the implementation in the OpenTelemetry.Exporter.OpenTelemetryProtocol project. However, this cannot ship as a regular release until logs are deemed stable.

There's a couple options:

• Leave the code in this project and ship a prerelease version of the package.
• Move the code to a separate project - e.g., OpenTelemetry.Exporter.OpenTelemetryProtocol.Logs - and ship this as a prerelease.

[codecov]

Codecov Report

Merging #1964 (5f169b5) into main (a2daad1) will decrease coverage by 0.82%.
The diff coverage is 2.32%.

@@            Coverage Diff             @@
##             main    #1964      +/-   ##
==========================================
- Coverage   80.11%   79.29%   -0.83%     
==========================================
  Files         251      254       +3     
  Lines        8289     8375      +86     
==========================================
  Hits         6641     6641              
- Misses       1648     1734      +86     

Impacted Files	Coverage Δ
...ementation/ExportClient/OtlpGrpcLogExportClient.cs	0.00% <0.00%> (ø)
...etryProtocol/Implementation/LogRecordExtensions.cs	0.00% <0.00%> (ø)
....Exporter.OpenTelemetryProtocol/OtlpLogExporter.cs	0.00% <0.00%> (ø)
...OpenTelemetry/Metrics/BaseExportingMetricReader.cs	89.28% <ø> (ø)
...Telemetry/Metrics/PeriodicExportingMetricReader.cs	0.00% <0.00%> (ø)
...tation/OpenTelemetryProtocolExporterEventSource.cs	61.29% <100.00%> (+2.66%)	⬆️
...Zipkin/Implementation/ZipkinExporterEventSource.cs	63.63% <0.00%> (-9.10%)	⬇️
...emetry.Api/Internal/OpenTelemetryApiEventSource.cs	73.52% <0.00%> (-5.89%)	⬇️
...nTelemetry/Internal/OpenTelemetrySdkEventSource.cs	74.28% <0.00%> (+0.95%)	⬆️

[gillg]

Any news about that ?
About remaining Todo have you some ideas ? On our side we made a custom implementation and we faced with some issues related to Microsoft logger because it only support 5 log level constants which is not really compatible with OTEL.

Does anyone know if this lib should be changed il the future ? Else we just need a static mapping in this PR.

[edisonpaul4]

Hi guys! Great job! any update on this?

[jgarces21]

Hi all!
This is a great first step towards implementing the Log exporter on .Net
Can @cijothomas take a look at this PR?

Cheers!

[alanwest]

It may not take too much to get this into a usable state. However, currently folks are primarily focused on supporting metrics, so it may be difficult get an eye on further logs support in the near term.

[jubenavides]

Hi, any update about this?

[ia-cefernan]

Hi everyone!, any updates on this?

[ia-jccontre]

It may not take too much to get this into a usable state. However, currently folks are primarily focused on supporting metrics, so it may be difficult get an eye on further logs support in the near term.

Is there any update on the log exporter?

[rodroxrom]

Hi all, can help us with this improvement?
Thanks!

[alanwest]

I've retargeted this PR to a feature branch and set it ready to review. We could consider doing a pre-release version with the this functionality.

Another option we discussed a couple months back in the SIG meeting was the idea of hosting this exporter in the OpenTelemetry.Contrib.Preview package - but I liked this idea less after giving it a try. It required copying too many internal dependencies from the OpenTelemetry.Exporter.OpenTelemetryProtocol project to make work.

Also, when #2316 lands, it will require a little refactor to the log exporter and also some work to make it work with http/protobuf transport. If we land this to a feature branch these things could be a follow up.

[cijothomas]

We discussed this in todays SIG, and agreed to make this a separate package (pre-release tag), agreeing to the original idea below:

Move the code to a separate project - e.g., OpenTelemetry.Exporter.OpenTelemetryProtocol.Logs - and ship this as a prerelease.

[reyang]

We discussed this in todays SIG, and agreed to make this a separate package (pre-release tag), agreeing to the original idea below:

Move the code to a separate project - e.g., OpenTelemetry.Exporter.OpenTelemetryProtocol.Logs - and ship this as a prerelease.

Maybe a quick & small topic that I want to get some ideas: are we thinking about having a single TCP connection that we can export logs/traces/metrics to OpenTelemetry Collector?

Put the question in a different way - if I use logs/metrics/traces and I don't want to have 3 OTLP exporters each managing their own connection / authz, what do I do?

[alanwest]

Put the question in a different way - if I use logs/metrics/traces and I don't want to have 3 OTLP exporters each managing their own connection / authz, what do I do?

Good question, I've had this thought in the back of my mind as well. Opened an issue (#2426) and shared some initial brainstorming.

[cijothomas]

do we need this conditional at all?

[cijothomas]

LGTM. Left a comment about the need for conditional targetting.