Skip to content

Conversation

@hannahhaering
Copy link
Contributor

@hannahhaering hannahhaering commented Oct 27, 2025

Implements #4109

Changes

Added low memory temporality as an option in the OTLP metrics exporter, following the specification

Merge requirement checklist

  • CONTRIBUTING guidelines followed (license requirements, nullable enabled, static analysis, etc.)
  • Unit tests added/updated
  • Appropriate CHANGELOG.md files updated for non-trivial changes
  • Changes in public API reviewed (if applicable)

@github-actions github-actions bot added pkg:OpenTelemetry Issues related to OpenTelemetry NuGet package pkg:OpenTelemetry.Exporter.OpenTelemetryProtocol Issues related to OpenTelemetry.Exporter.OpenTelemetryProtocol NuGet package labels Oct 27, 2025
@codecov
Copy link

codecov bot commented Oct 27, 2025

Codecov Report

❌ Patch coverage is 93.33333% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 86.72%. Comparing base (7072855) to head (b10b549).
✅ All tests successful. No failed tests found.

Files with missing lines Patch % Lines
src/OpenTelemetry/Metrics/Reader/MetricReader.cs 93.33% 1 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #6648      +/-   ##
==========================================
- Coverage   86.76%   86.72%   -0.04%     
==========================================
  Files         258      258              
  Lines       11958    11973      +15     
==========================================
+ Hits        10375    10384       +9     
- Misses       1583     1589       +6     
Flag Coverage Δ
unittests-Project-Experimental 86.66% <93.33%> (+0.22%) ⬆️
unittests-Project-Stable 86.46% <93.33%> (-0.30%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
src/OpenTelemetry/Metrics/Reader/MetricReader.cs 89.39% <93.33%> (+0.50%) ⬆️

... and 2 files with indirect coverage changes

Comment on lines +40 to +53
private static readonly Func<Type, AggregationTemporality> LowMemoryTemporalityPreferenceFunc = (instrumentType) =>
{
return instrumentType.GetGenericTypeDefinition() switch
{
var type when type == typeof(Counter<>) => AggregationTemporality.Delta,
var type when type == typeof(Histogram<>) => AggregationTemporality.Delta,

var type when type == typeof(UpDownCounter<>) => AggregationTemporality.Cumulative,
var type when type == typeof(ObservableCounter<>) => AggregationTemporality.Cumulative,
var type when type == typeof(ObservableUpDownCounter<>) => AggregationTemporality.Cumulative,

_ => AggregationTemporality.Cumulative,
};
};
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if using TypeHandle property would be more performant here.

Copy link
Member

Choose a reason for hiding this comment

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

Unless there's a huge benefit, I think it's better to make the code obvious by using ==. It's also not obvious from the source code what that property does differently as it just throws an exception.

@hannahhaering hannahhaering marked this pull request as ready for review October 29, 2025 01:57
@hannahhaering hannahhaering requested a review from a team as a code owner October 29, 2025 01:57
/// ObservableUpDownCounter instruments. This mode reduces SDK memory usage by avoiding
/// the need to store both cumulative and delta states for temporality conversion.
/// </summary>
LowMemory = 3,
Copy link
Member

Choose a reason for hiding this comment

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

Technically, all these 3 options are defined only for OTLP exporter https://github.com/open-telemetry/opentelemetry-specification/blob/7f6d35f758bb5d92e354460d040974665a29ba32/specification/metrics/sdk_exporters/otlp.md?plain=1#L55 and it shouldn't be part of the SDK.

Based on current design, I do not see any better option to put in the current class design.
@alanwest, do you remember any historical reasons for keeping it here?

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

Labels

pkg:OpenTelemetry.Exporter.OpenTelemetryProtocol Issues related to OpenTelemetry.Exporter.OpenTelemetryProtocol NuGet package pkg:OpenTelemetry Issues related to OpenTelemetry NuGet package

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants