Skip to content

Fixing EMF output for detailed summary metrics #313

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
May 13, 2025
Merged

Fixing EMF output for detailed summary metrics #313

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion exporter/awsemfexporter/grouped_metric.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -86,7 +86,11 @@ func addToGroupedMetric(
}

// Extra params to use when grouping metrics
metadata.groupedMetricMetadata.batchIndex = i
Copy link

Choose a reason for hiding this comment

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

why remove this? Will we break appsignals since they are the ones who added this?

Copy link
Author

Choose a reason for hiding this comment

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

It wasn't removed, just moved inside the if statement to skip this part for detailed summary metrics (for which the assumptions that were made when this when introduced does not hold).

Copy link

Choose a reason for hiding this comment

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

agree this code is confusing so what's happening is to skip index changing for summary and when detailedMetrics is enabled. Is there any chance that these metrics are sparse in the array meaning keeping the index would cause any unexepcted grouping behavior?

Copy link
Author

Choose a reason for hiding this comment

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

Is there any chance that these metrics are sparse in the array meaning keeping the index would cause any unexepcted grouping behavior

I don't think so. Here is how the array of datapoints is created: https://github.com/amazon-contributing/opentelemetry-collector-contrib/blob/bump-v0.124.1/exporter/awsemfexporter/datapoint.go#L483-L494. There' always two array entries for sum and count metric (that we want grouped) and then one datapoint for each quantile. We want the quantile entries to be separated, but they are already are because of the labels are different.

if !(metadata.groupedMetricMetadata.metricDataType == pmetric.MetricTypeSummary && config.DetailedMetrics) {
// Summary metrics can be split into separate datapoints when using DetailedMetrics, but we still want to group
// them together into one EMF log event, so don't set batchIndex when it's a summary metric
metadata.groupedMetricMetadata.batchIndex = i
}
groupKey := aws.NewKey(metadata.groupedMetricMetadata, labels)
if _, ok := groupedMetrics[groupKey]; ok {
// if MetricName already exists in metrics map, print warning log
Expand Down
57 changes: 57 additions & 0 deletions exporter/awsemfexporter/grouped_metric_test.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -438,6 +438,63 @@ func TestAddToGroupedMetric(t *testing.T) {
idx++
}
})

t.Run("Detailed summary metrics", func(t *testing.T) {
emfCalcs := setupEmfCalculators()
defer require.NoError(t, shutdownEmfCalculators(emfCalcs))
groupedMetrics := make(map[any]*groupedMetric)
generateMetrics := []pmetric.Metrics{
generateTestSummaryMetric("foo"),
}
finalOtelMetrics := generateOtelTestMetrics(generateMetrics...)

rms := finalOtelMetrics.ResourceMetrics()
ilms := rms.At(0).ScopeMetrics()
metrics := ilms.At(0).Metrics()
assert.Equal(t, 2, metrics.Len(), "2 metrics are required to form 1 delta metric")

cfg := createDefaultConfig().(*Config)
cfg.DetailedMetrics = true

for i := 0; i < metrics.Len(); i++ {
err := addToGroupedMetric(metrics.At(i),
groupedMetrics,
generateTestMetricMetadata(namespace, timestamp, logGroup, logStreamName, instrumentationLibName, metrics.At(i).Type()),
true,
nil,
cfg,
emfCalcs,
)
assert.NoError(t, err)
}
assert.Len(t, groupedMetrics, 3) // sum + count, quantile 0, quantile 100 (see generateTestSummaryMetric)
for _, group := range groupedMetrics {
for metricName, metricInfo := range group.metrics {
switch metricName {
case "foo_sum", "foo_count":
assert.Len(t, group.metrics, 2, "sum and count should be grouped together for detailed summary metrics")
assert.Equal(t, "Seconds", metricInfo.unit)
assert.Equal(t, generateTestMetricMetadata(namespace, timestamp, logGroup, logStreamName, instrumentationLibName, pmetric.MetricTypeSummary), group.metadata)
case "foo":
quantileVal, ok := group.labels["quantile"]
assert.True(t, ok)
switch quantileVal {
case "0":
assert.Equal(t, float64(1), metricInfo.value)
case "100":
assert.Equal(t, float64(5), metricInfo.value)
default:
assert.Fail(t, "Unexpected quantile value")
}
assert.Equal(t, generateTestMetricMetadata(namespace, timestamp, logGroup, logStreamName, instrumentationLibName, pmetric.MetricTypeSummary), group.metadata)
default:
assert.Fail(t, fmt.Sprintf("Unhandled metric %s not expected", metricName))
}
// ensure label1:value1 is always present (may not be the only label though)
assert.Equal(t, "value1", group.labels["label1"])
}
}
})
}

func TestAddKubernetesWrapper(t *testing.T) {
Expand Down
Loading