Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Exporter.Geneva] Update GenevaMetricExporter to export Exemplars #1069

Conversation

utpilla
Copy link
Contributor

@utpilla utpilla commented Mar 10, 2023

Changes

  • Update GenevaMetricExporter serialization
  • Export exemplars
  • GenevaExporter to depend on 1.5.0-alpha.1 version of OpenTelemetry SDK

TODO:

  • Cleanup code
  • Update unit tests
  • Update benchmark

Please provide a brief description of the changes here.

For significant contributions please make sure you have completed the following items:

  • Appropriate CHANGELOG.md updated for non-trivial changes

@utpilla utpilla requested a review from a team March 10, 2023 19:41
@utpilla utpilla added the comp:exporter.geneva Things related to OpenTelemetry.Exporter.Geneva label Mar 10, 2023
}

var bodyLength = this.SerializeHistogramMetric(
_ = metricPoint.TryGetHistogramMinMaxValues(out double min, out double max);
Copy link
Member

Choose a reason for hiding this comment

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

if min max is not available, dont we need ulongZero to be written?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, it would serialize them as zero. If TryGetHistogramMinMaxValues returns false, min and max would be set to zero.

Copy link
Member

Choose a reason for hiding this comment

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

mm.. Is that a contract or relying on the internal implementation details on OTel sdk? I think its wrong to rely on the min, max if TryGet fails.

Copy link
Contributor Author

@utpilla utpilla Mar 10, 2023

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

I am not sure if that is the case. Once it returned false, callers should not be relying on the values on the out parameters.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I can explicitly set them to zero if the method returns false, but I do think the SDK should not change the behavior of this public API when it returns false. Also, it doesn't make sense for the SDK to assign to them any value other than the default value of zero when it returns false.

payloadTypeStartIndex = bufferIndex;
bufferIndex += 2;

MetricSerializer.SerializeByte(this.buffer, ref bufferIndex, 0); // version
Copy link
Member

Choose a reason for hiding this comment

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

nit: consider moving these to a const elsewhere.

MetricSerializer.SerializeByte(this.buffer, ref bufferIndex, 0); // version

var exemplarsCount = 0;
foreach (var exemplar in exemplars)
Copy link
Member

Choose a reason for hiding this comment

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

lets add a TODO to avoid this dual iteration, and instead backfill the count

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think we can avoid it. The count field doesn't have a predefined size. It could be anywhere from 1 to 9 bytes. So we need to know the count beforehand.

bool hasLabels = exemplar.FilteredTags != null && exemplar.FilteredTags.Count > 0;
byte numberOfLabels = 0;

var unixNanoSeconds = DateTime.FromFileTimeUtc(exemplar.Timestamp.ToFileTime())
Copy link
Member

Choose a reason for hiding this comment

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

good to extract to a helper method.

Copy link
Contributor Author

@utpilla utpilla Mar 10, 2023

Choose a reason for hiding this comment

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

This is the only method that needs it 😄. This helper method could be a comment.

@codecov
Copy link

codecov bot commented Mar 11, 2023

Codecov Report

❗ No coverage uploaded for pull request base (main@c83fb4a). Click here to learn what that means.
The diff coverage is 16.78%.

❗ Current head ed76eca differs from pull request most recent head 48521b1. Consider uploading reports for the commit 48521b1 to get more accurate results

Additional details and impacted files

Impacted file tree graph

@@           Coverage Diff           @@
##             main    #1069   +/-   ##
=======================================
  Coverage        ?   68.54%           
=======================================
  Files           ?      210           
  Lines           ?     8113           
  Branches        ?        0           
=======================================
  Hits            ?     5561           
  Misses          ?     2552           
  Partials        ?        0           
Impacted Files Coverage Δ
...emetry.Exporter.Geneva/Metrics/MetricSerializer.cs 42.30% <0.00%> (ø)
...Geneva/Metrics/Transport/MetricEtwDataTransport.cs 69.23% <0.00%> (ø)
...ry.Exporter.Geneva/Metrics/GenevaMetricExporter.cs 46.47% <21.39%> (ø)

@utpilla utpilla merged commit 3af3665 into open-telemetry:main Mar 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
comp:exporter.geneva Things related to OpenTelemetry.Exporter.Geneva
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants