Centralize OpenTelemetry Constants and Helpers in source/extensions/common/opentelemetry#41011
Centralize OpenTelemetry Constants and Helpers in source/extensions/common/opentelemetry#41011mmorel-35 wants to merge 1 commit intoenvoyproxy:mainfrom
Conversation
df991ee to
0e16d6b
Compare
c5d5878 to
2b2dd1d
Compare
f40288e to
266b436
Compare
9af799f to
7d428c2
Compare
36929e8 to
258e22c
Compare
c7eff05 to
cc6686e
Compare
…ommon/opentelemetry Signed-off-by: Matthieu MOREL <matthieu.morel35@gmail.com>
cc6686e to
6146278
Compare
kyessenov
left a comment
There was a problem hiding this comment.
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/ |
There was a problem hiding this comment.
Please put double backticks around symbols (source/...).
| @@ -0,0 +1,386 @@ | |||
| # OpenTelemetry Alignment Analysis for Envoy | |||
There was a problem hiding this comment.
Is this AI generated? I don't think we should commit this file.
| envoy_extension_package() | ||
|
|
||
| envoy_cc_library( | ||
| name = "opentelemetry_lib", |
There was a problem hiding this comment.
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))) {} |
There was a problem hiding this comment.
You can drop Envoy::Extensions:: I think, since the final string is longer than the original :)
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Why is it unowned? You can put my name and your name.
| @@ -0,0 +1,31 @@ | |||
| # OpenTelemetry OTLP Exporters | |||
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
IMO, these are unnecessary indirections. These protos are v1 so they will not change their location.
| namespace Common { | ||
| namespace OpenTelemetry { | ||
| namespace Sdk { | ||
| namespace Common { |
There was a problem hiding this comment.
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>; |
There was a problem hiding this comment.
why std map? flat_hash_map would be better?
|
/wait |
|
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! |
|
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! |
Commit Message:
Centralizes OpenTelemetry-related constants, helpers, and types into
source/extensions/common/opentelemetryas described in #41010.Additional Description:
source/extensions/common/opentelemetry/.README.md, design artifacts) in the new directory.Risk Level: Low (organizational refactor, covered by existing tests)
Testing:
Docs Changes:
source/extensions/common/opentelemetry/README.mddescribing new organization and conventions.Release Notes:
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!