Skip to content

Conversation

@iamgoeldhruv
Copy link

@iamgoeldhruv iamgoeldhruv commented Jan 9, 2026

Description

Summary

This PR adds support for explicitly disabling OpenTelemetry tracing when no collector
endpoint is configured.

Changes

  • Added an Enabled flag to tracing configuration
  • Short-circuits tracer initialization when tracing is disabled
  • Prevents exporter connection attempts when no collector is present
  • Added unit tests to cover disabled tracing behavior

Why this is needed

Currently, Meshery components attempt to connect to a default OTLP endpoint
even when no collector is configured, resulting in noisy timeout logs.
This change ensures tracing is a no-op unless explicitly enabled.

Related issue

Fixes: #894

###Related PR
This issue is further addressed in meshery/meshery#16908.

Signed commits

  • Yes, I signed my commits.

Signed-off-by: Dhruv Goel <goeldhruv9876@gmail.com>
@welcome
Copy link

welcome bot commented Jan 9, 2026

Yay, your first pull request! 👍 A contributor will be by to give feedback soon. In the meantime, you can find updates in the #github-notifications channel in the community Slack.
Be sure to double-check that you have signed your commits. Here are instructions for making signing an implicit activity while performing a commit.

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @iamgoeldhruv, 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 addresses an issue where Meshery components would attempt to connect to a default OpenTelemetry Protocol (OTLP) endpoint even when no collector was configured, leading to unnecessary and noisy timeout logs. By introducing an explicit 'Enabled' flag in the tracing configuration, the system can now be configured to completely disable tracing, preventing these connection attempts and ensuring that tracing operations are a no-op unless intentionally activated.

Highlights

  • Tracing Configuration: Introduced an Enabled flag within the tracing configuration to allow explicit control over tracing activation.
  • Tracer Initialization: Implemented a short-circuit mechanism in the tracer initialization process, preventing it from proceeding if tracing is explicitly disabled.
  • Exporter Connection Prevention: Ensured that exporter connection attempts are bypassed when no OpenTelemetry collector endpoint is configured, addressing noisy timeout logs.
  • Unit Tests: Added new unit tests to validate the behavior of the tracing system when it is explicitly disabled.
Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request aims to disable OpenTelemetry tracing when no collector endpoint is configured by adding an Enabled flag. While the changes correctly add the flag and a check to disable tracing when Enabled is explicitly false, the implementation is incomplete. It doesn't handle the case where tracing should be disabled by default when an endpoint is missing, which is the core of the issue described. The current code will still error out if an endpoint is not provided and tracing is not explicitly disabled. I've left a critical comment explaining the logical flaw and suggesting a path to a complete fix. I also left a minor comment to improve code documentation.

Comment on lines +49 to +51
if cfg.Enabled != nil && !*cfg.Enabled {
return nil, nil
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

critical

This check correctly handles explicit disabling via the Enabled flag. However, it fails to address the primary goal of the PR, which is to disable tracing when no collector endpoint is configured. If a configuration omits the endpoint but does not explicitly set enabled: false, this function will still proceed and fail at the cfg.Endpoint == "" check on line 56, returning an error. This means the problem of noisy logs for endpoint-less configurations is not solved.

To fix this, the logic should be changed to disable tracing by default when cfg.Endpoint is empty. Since a complete fix requires modifying code outside of this diff hunk (specifically, the check on line 56), a direct code suggestion cannot be applied. Please consider refactoring the validation logic to ensure tracing is a no-op when Endpoint is not set.

Endpoint string `yaml:"endpoint" json:"endpoint"`
// Insecure determines whether to use an insecure connection (no TLS)
Insecure bool `yaml:"insecure" json:"insecure"`
// Adding extra flag to check if tracing is enabled
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

This comment is redundant as the field name Enabled is self-explanatory. In Go, comments are most effective when they clarify non-obvious aspects of the code. A more useful comment would describe the behavior when this field is not set (e.g., how it interacts with the Endpoint configuration).

Suggested change
// Adding extra flag to check if tracing is enabled
// Enabled can be used to explicitly disable tracing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Allow the configuration of distributed tracing to be disabled

1 participant