feat(exporter-prometheus): add aggregationSelector option to configure default aggregation

[nissy-dev]

Which problem is this PR solving?

The PrometheusExporter currently hard-codes the default aggregation (AggregationType.DEFAULT) for every instrument kind, so users have no way to override how instruments are aggregated when exporting to Prometheus. This PR adds an optional aggregationSelector to the exporter configuration so users can configure the default aggregation as a function of instrument kind, consistent with the SDK's MetricReader API.

Part of #6605

Short description of the changes

• Add an optional aggregationSelector?: AggregationSelector field to ExporterConfig (src/export/types.ts).
• Wire the configured aggregationSelector through to the underlying MetricReader in PrometheusExporter, falling back to the previous behavior (AggregationType.DEFAULT for all instruments) when it is not provided.
• Add a CHANGELOG entry.

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

• Added a unit test in PrometheusExporter.test.ts verifying that a configured aggregationSelector is respected: with a SUM aggregation selector, a histogram instrument is exported as a single summed counter instead of histogram buckets.
• Ran the exporter-prometheus package test suite locally.

Checklist:

• Followed the style guidelines of this project
• Unit tests have been added
• Documentation has been updated

[github-actions]

Welcome, contributor! Thank you for your contribution to opentelemetry-js.

Important reminders:

• Read our Contributing Guidelines.

• Sign the CLA if you haven't already.

• Follow the OpenTelemetry Generative AI policy: disclose any AI use in your contribution, and communicate (PR descriptions, review replies) in your own words rather than AI-generated text.

• Give reviewers at least a few days before pinging them for feedback.

• If you need help with general setup, development process, or contributor etiquette, ask in #opentelemetry-new-contributors.

• Add an entry describing your change to the appropriate changelog file: Stable packages, Experimental packages, API or Semantic Conventions. Add your entry under the ## Unreleased section.

[pichlermarc]

Having AggreagationSelector be a function was a mistake we made, since it implies that changing the returned values after configuring the MetricReader (in this case PrometheusExporter) would re-configure already-created instruments, which is not the case.

Suggestion: let's implement this feature in a why that there's an aggregationPreference option that people can configure like so.

new PrometheusExporter({
  aggregationPreference: {
     gauge: {
       // this here is an AggregationOption
       type: AggregationType.LAST_VALUE
     },
     // non-specified ones fall back to default
  }
})

Internally, the aggregationPreference is converted to an aggregationSelector and published this way.
This way it's clearer that nothing can be changed once the exporter has been instantiated. :)

[opentelemetry-pr-dashboard]

Pull request dashboard status

Waiting on reviewers · refreshed 2026-07-28 23:30 UTC

Review the latest changes.

Status above doesn't look right?

• Just replied or pushed? Anything around or after the refresh time above may not be picked up yet — give it a few minutes.
• Anything look wrong? Report it with what you expected; it helps us improve the dashboard.

[nissy-dev]

@pichlermarc Thanks for the suggestion! I've updated the PR to use a static aggregationPreference option instead.