Replies: 1 comment
-
Hello @dmathieu, I thought about that, but unfortunately there are limitations about the SDK go (cannot depend on proto) which makes things a bit harder. I think a small library "to/from otel-go representation" is a good starting point. Also the collector wants to develop the internal representation in a way that will be as performant as possible for cases where otlp is received and exported, which means we will at one point add capabilities like lazy unmarshaling, etc. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hey,
I'm not opening this as an issue, as it may have been covered elsewhere, and I feel I'm missing something regarding the reason this isn't the case.
It would be very convenient to be able to use the same exporter in both a non-collector project, and one transmitting its data to a collector.
So, have you considered matching the exporters' interfaces to match exporters from opentelemetry-go SDK?
Beta Was this translation helpful? Give feedback.
All reactions