Skip to content

Centralize OpenTelemetry Constants and Helpers in source/extensions/common/opentelemetry#41011

Closed
mmorel-35 wants to merge 1 commit intoenvoyproxy:mainfrom
mmorel-35:common/opentelemetry
Closed

Centralize OpenTelemetry Constants and Helpers in source/extensions/common/opentelemetry#41011
mmorel-35 wants to merge 1 commit intoenvoyproxy:mainfrom
mmorel-35:common/opentelemetry

Conversation

@mmorel-35
Copy link
Copy Markdown
Contributor

@mmorel-35 mmorel-35 commented Sep 7, 2025

Commit Message:
Centralizes OpenTelemetry-related constants, helpers, and types into source/extensions/common/opentelemetry as described in #41010.

Additional Description:

  • Moves duplicated OpenTelemetry constants and utility functions from tracing and propagator extensions into a shared directory: source/extensions/common/opentelemetry/.
  • Updates or adds documentation (README.md, design artifacts) in the new directory.

Risk Level: Low (organizational refactor, covered by existing tests)

Testing:

  • Ran existing unit and integration tests for tracing extensions.
  • Verified build and linting (buildifier, clang-format) passes.

Docs Changes:

  • Added/updated source/extensions/common/opentelemetry/README.md describing new organization and conventions.
  • Moved the mutualization plan to this directory.

Release Notes:

  • area: tracing
    change: |
    Moved all OpenTelemetry extension source and tests to source/extensions/common/opentelemetry/
    and test/extensions/common/opentelemetry/ for better reuse and organization across different
    extension types (tracers, access loggers, stat sinks). Updated OpenTelemetry Logs SDK to use
    the new Common namespace structure for consistency.

Related to #41010


Please review and provide feedback!

@mmorel-35 mmorel-35 force-pushed the common/opentelemetry branch 9 times, most recently from df991ee to 0e16d6b Compare September 7, 2025 13:46
@mmorel-35 mmorel-35 marked this pull request as ready for review September 7, 2025 13:54
@mmorel-35 mmorel-35 marked this pull request as draft September 7, 2025 19:32
@mmorel-35 mmorel-35 force-pushed the common/opentelemetry branch 4 times, most recently from c5d5878 to 2b2dd1d Compare September 8, 2025 15:36
@mmorel-35 mmorel-35 changed the title Centralize OpenTelemetry Constants and Helpers in source/common/opentelemetry Centralize OpenTelemetry Constants and Helpers in source/extensions/opentelemetry Sep 8, 2025
@mmorel-35 mmorel-35 force-pushed the common/opentelemetry branch 12 times, most recently from f40288e to 266b436 Compare September 8, 2025 20:29
@mmorel-35 mmorel-35 force-pushed the common/opentelemetry branch 4 times, most recently from 9af799f to 7d428c2 Compare September 8, 2025 23:00
@mmorel-35 mmorel-35 changed the title Centralize OpenTelemetry Constants and Helpers in source/extensions/opentelemetry Centralize OpenTelemetry Constants and Helpers in source/extensions/common/opentelemetry Sep 9, 2025
@mmorel-35 mmorel-35 force-pushed the common/opentelemetry branch 7 times, most recently from 36929e8 to 258e22c Compare September 9, 2025 07:59
@mmorel-35 mmorel-35 marked this pull request as ready for review September 9, 2025 08:40
@mmorel-35 mmorel-35 force-pushed the common/opentelemetry branch 2 times, most recently from c7eff05 to cc6686e Compare September 9, 2025 15:36
@mmorel-35 mmorel-35 requested a review from kyessenov September 9, 2025 15:39
…ommon/opentelemetry

Signed-off-by: Matthieu MOREL <matthieu.morel35@gmail.com>
Copy link
Copy Markdown
Contributor

@kyessenov kyessenov left a comment

Choose a reason for hiding this comment

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

I have a general question about the direction. What do we gain by creating an internal SDK for OTEL? It seems that there's only few usages of it, and it would be hard to enforce that all usages use the SDK since they are mostly constants.

I agree we can organize some code (e.g. resource detectors should be common), and maybe attribute handling code is duplicated somewhere. But I don't understand the value of moving the constants when it's only used once.

new_features:
- area: tracing
change: |
Moved all OpenTelemetry extension source and tests to source/extensions/common/opentelemetry/
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Please put double backticks around symbols (source/...).

@@ -0,0 +1,386 @@
# OpenTelemetry Alignment Analysis for Envoy
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is this AI generated? I don't think we should commit this file.

envoy_extension_package()

envoy_cc_library(
name = "opentelemetry_lib",
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This is unnecessary, please use the direct deps instead.

service_method_(*Protobuf::DescriptorPool::generated_pool()->FindMethodByName(
"opentelemetry.proto.collector.metrics.v1.MetricsService.Export")) {}
std::string(Envoy::Extensions::Common::OpenTelemetry::Sdk::Metrics::Constants::
METRICS_SERVICE_EXPORT_METHOD))) {}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

You can drop Envoy::Extensions:: I think, since the final string is longer than the original :)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Also, are you sure you need std::string(? I think gRPC takes string_views these days.

/*/source/extensions/listener_managers/validation_listener_manager @adisuissa @ggreenway
/*/source/extensions/config_subscription/ @adisuissa @UNOWNED
/*/source/extensions/config_subscription/grpc @adisuissa @UNOWNED
/*/extensions/common/opentelemetry @UNOWNED @UNOWNED
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Why is it unowned? You can put my name and your name.

@@ -0,0 +1,31 @@
# OpenTelemetry OTLP Exporters
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Thanks for adding these, but I think we don't need this level of details since it will get out of sync with the code. I think the top-level README is probably enough.

using OTelSpanKind = ::opentelemetry::proto::trace::v1::Span::SpanKind;

// OTLP export request/response types for traces (from OTLP protocol)
using ExportRequest = ::opentelemetry::proto::collector::trace::v1::ExportTraceServiceRequest;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

My general feeling is that we only gain benefits from a constant is when there is more than one usage. For these RPC stubs, there's really only one place they are used, which is the various sinks.

/**
* @brief Aggregation temporality for metrics (from OpenTelemetry specification)
*/
using AggregationTemporality = ::opentelemetry::proto::metrics::v1::AggregationTemporality;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

IMO, these are unnecessary indirections. These protos are v1 so they will not change their location.

namespace Common {
namespace OpenTelemetry {
namespace Sdk {
namespace Common {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'd focus on these instead - these seem to be reused a lot. I'd recommend flattening the namespace, to just OpenTelemetry or Otel.

/**
* @brief Container holding Open-telemetry Attributes (Envoy extension)
*/
using OTelAttributes = std::map<std::string, OTelAttribute>;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

why std map? flat_hash_map would be better?

@kyessenov
Copy link
Copy Markdown
Contributor

/wait

@github-actions
Copy link
Copy Markdown

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

@github-actions github-actions bot added the stale stalebot believes this issue/PR has not been touched recently label Oct 18, 2025
@github-actions
Copy link
Copy Markdown

This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

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

Labels

stale stalebot believes this issue/PR has not been touched recently waiting

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants