Status of OpenTelemetry.Extensions.EventSource #6047
Replies: 1 comment
-
The answer is: C) I don't have the bandwidth to work on it 🤣 I was discussing this recently with @pellared. Anyone is free to pick up the effort! Personally what I would like to see done... There are two prototypes in the Those should be moved over to the contrib repo, updated (the Logger aka Log Bridge API changed after those were done but it is close), and released experimentally with a dependency on the pre-release SDK. So we can gather feedback about the API/design from customers. Once we have that feedback, assuming it is positive, we can promote the SDK APIs to stable and then promote the packages in contrib to stable. It is going to be a long process and there are some tough things to hash out because the SDK Log Bridge API is based on the SDK LogRecord which was shipped stable before the spec and it has some issues/gaps. |
Beta Was this translation helpful? Give feedback.
-
I really need the ability to capture existing EventSource instrumentation to push out via OTLP.
The OpenTelemetry.Extensions.EventSource library in the main-logs branch seems to be exactly what I need. I've read the PRs and Issues around the creation, naming debates, and moving over to main-logs because it wasn't making it into the next release, but after that - nothing. My question is, was this project abandoned because:
A) Lack of interest in the feature, mismatch with specs, etc.
or
B) A daunting technical or performance issue arose and solving it would be too expensive
My assumption is that A) is the cause and I'll use that code, but I'm doing due diligence in case it was B).
Any background info is appreciated.
Beta Was this translation helpful? Give feedback.
All reactions