Add public constructors for metric data types
Hello everyone,
The ResourceMetrics struct and its child structs lack any public constructor, preventing users from using PushMetricExporter::export. SpanData has public fields, and SdkLogRecord has public trait setters, allowing users to use their corresponding exporters. Metrics is the only signal where external construction is blocked, preventing users from using a trait that is part of the public API.
Is there a specific reason for this inconsistency?
If this is to avoid breaking encapsulation, adding a public constructor or a builder would not expose any implementation details.
In my project I would like to call that trait, but not having this feature forces me to bypass the SDK entirely and reimplement the export path using opentelemetry-proto directly.
I am offering to implement this change. My idea is to implement this with a builder pattern, something like:
let data_point = GaugeDataPoint::new(42.0)
.with_attributes(vec![KeyValue::new("host", "localhost")]);
let gauge = Gauge::new(vec![data_point]);
let metric = Metric::new("my_metric", MetricData::Gauge(gauge))
.with_description("A custom gauge")
.with_unit("ms");
let scope_metrics = ScopeMetrics::new(InstrumentationScope::builder("my.library").build())
.with_metrics(vec![metric]);
let resource_metrics = ResourceMetrics::new(Resource::builder().build())
.with_scope_metrics(vec![scope_metrics]);
exporter.export(&resource_metrics).await?;
Add public constructors for metric data types
Hello everyone,
The
ResourceMetricsstruct and its child structs lack any public constructor, preventing users from usingPushMetricExporter::export.SpanDatahas public fields, andSdkLogRecordhas public trait setters, allowing users to use their corresponding exporters. Metrics is the only signal where external construction is blocked, preventing users from using a trait that is part of the public API.Is there a specific reason for this inconsistency?
If this is to avoid breaking encapsulation, adding a public constructor or a builder would not expose any implementation details.
In my project I would like to call that trait, but not having this feature forces me to bypass the SDK entirely and reimplement the export path using
opentelemetry-protodirectly.I am offering to implement this change. My idea is to implement this with a builder pattern, something like: