feat: Add support to disable telemetry instrumentation #611
Conversation
…s and xdist configuration to ensure module import tests can be run in the same group
Summary of ChangesHello @vinoo999, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a feature to disable telemetry instrumentation using an environment variable, providing more control over data collection. It also enhances the testing framework by adding Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
| StatusCode = _NoOp() # type: ignore | ||
|
|
||
| SpanKind = _SpanKind | ||
| SpanKind = _SpanKind # type: ignore |
There was a problem hiding this comment.
was receiving unbound linting errors since i moved the assignment to line 132 rather than exception block.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a feature to disable OpenTelemetry instrumentation via the OTEL_A2A_SDK_INSTRUMENTATION_ENABLED environment variable. The implementation is solid, including comprehensive tests that cleverly reload the module to check the environment variable's effect. I've found one bug related to tracer initialization and have a couple of suggestions for improvement. One suggestion is to separate an unrelated dependency change into its own pull request to maintain focus. Overall, this is a great addition.
|
|
||
| # Check if tracing is enabled via environment variable | ||
| env_value = os.getenv(ENABLED_ENV_VAR, 'true') | ||
| otel_enabled = env_value.lower() == 'true' |
There was a problem hiding this comment.
The current implementation for checking the OTEL_A2A_SDK_INSTRUMENTATION_ENABLED environment variable only considers 'true' (case-insensitively) as an enabling value. While this matches the updated documentation, it's common for boolean environment variables to also accept values like '1' or 'yes'. To improve user experience and align with common conventions, consider making the check more flexible. You would also need to update the documentation to reflect this change.
| otel_enabled = env_value.lower() == 'true' | |
| otel_enabled = env_value.lower() in ('true', '1', 'yes') |
src/a2a/utils/telemetry.py
Outdated
| ) | ||
| otel_installed = False | ||
|
|
||
| ENABLED_ENV_VAR = 'OTEL_A2A_SDK_INSTRUMENTATION_ENABLED' |
There was a problem hiding this comment.
| ENABLED_ENV_VAR = 'OTEL_A2A_SDK_INSTRUMENTATION_ENABLED' | |
| ENABLED_ENV_VAR = 'OTEL_INSTRUMENTATION_A2A_SDK_ENABLED' |
Setting this to match other instrumentation env vars within the OTEL community which are prefixed by OTEL_INSTRUMENTATION_.
2 participants
Description
Support disabling OTEL instrumentation via the a2a-sdk using an environment variable
OTEL_A2A_SDK_INSTRUMENTATION_ENABLEDThank you for opening a Pull Request!
Before submitting your PR, there are a few things you can do to make sure it goes smoothly:
CONTRIBUTINGGuide.fix:which represents bug fixes, and correlates to a SemVer patch.feat:represents a new feature, and correlates to a SemVer minor.feat!:, orfix!:,refactor!:, etc., which represent a breaking change (indicated by the!) and will result in a SemVer major.bash scripts/format.shfrom the repository root to format)Fixes #604 🦕