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
Refactor duplication between Traces and Logs #1528
Comments
I'm not sure what we've covered in the Logs SDK and API implementations. Note that the Events API is still "experimental", so we don't want to merge that into the main API gem yet. The rest of the Logs API and SDK specs seem to be stable, so we can start to merge them into the main API and SDK gems. |
@fbogsany - The Logs API implementation on For the Logs SDK, the end-to-end code has been written, but not reviewed. #1517 blocks the other functionality from review. I want to keep the scope of the Logs SDK PRs small and focus on one spec concept at a time. There’s also an OTLP logs exporter and basic instrumentation for Ruby’s |
Update 2023-12-12: During today’s SIG, @robbkidd brought up the rule that you should abstract after you have 3+ of something. With that in mind, this work might begin as part of the Events implementation. |
👋 This issue has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the |
Once the Logs SDK and Logs API implementations are stable and ready to be merged into the main API and SDK gems, let's refactor the code for the Trace SDK and API to reduce duplication between the signals.
The text was updated successfully, but these errors were encountered: