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

Add default_histogram_aggregation configuration option to prometheus exporter #4124

Conversation

jack-berg
Copy link
Member

Similar to how its possible to specify that base2 exponential histogram should be the default histogram aggregation for the otlp metric exporter, it should be possible to do so for the prometheus exporter.

This adds a new optional config option to the prometheus exporter called default_histogram_aggregation, with the same mechanics as the OTLP-exporter equivalent.

The motivation is that there is a PR to extend the file configuration schema with this option, and we have a rule that all portions of the file configuration schema should be explicitly defined or implied by language in the spec, since we don't want to add configuration options which could potentially contradict the spec.

cc @open-telemetry/configuration-maintainers, @open-telemetry/wg-prometheus, @Abhishekkr3003

Copy link
Member

@reyang reyang left a comment

Choose a reason for hiding this comment

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

LGTM with a changelog entry.

@carlosalberto
Copy link
Contributor

cc @dashpole

Copy link
Contributor

@dashpole dashpole left a comment

Choose a reason for hiding this comment

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

I'm OK with this, as it is a MAY. Would this make more sense in a (similar to OTLP) "Additional Config" section using environment variables?

histogram aggregation. The option MAY be named `default_histogram_aggregation`,
and MUST support the following values:

* `explicit_bucket_histogram`: Use [Explicit Bucket Histogram Aggregation](../sdk.md#explicit-bucket-histogram-aggregation).
Copy link
Contributor

Choose a reason for hiding this comment

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

This structure makes sense for environment-variable-based config, where we expect string constants, but maybe not so much for SDK exporter config? E.g. Go allows users to provide an AggregationSelector, which I don't think would comply with this.

@arminru arminru added spec:metrics Related to the specification/metrics directory area:sdk Related to the SDK area:configuration Related to configuring the SDK labels Jul 8, 2024
@jack-berg
Copy link
Member Author

@dashpole your comments made me realize that we have a more general problem to solve here. I've opened up #4142 to address, which supersedes this.

@jack-berg jack-berg closed this Jul 11, 2024
jack-berg added a commit that referenced this pull request Jul 24, 2024
… default aggregation (#4142)

Reviewing @dashpole's
[comments](#4124 (review))
on #4124, I realize that a key clarification is missing for the contract
between readers and exporters, and for the configuration of built-in
exporters.

We [state
that](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#metricreader)
MetricReaders should be constructed with:
- "The default output aggregation (optional), a function of instrument
kind. If not configured, the [default
aggregation](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#default-aggregation)
SHOULD be used."
- "The default output temporality (optional), a function of instrument
kind. If not configured, the Cumulative temporality SHOULD be used."

And for MetricExporters, we [state
that](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#metricexporter)
"The aggregation and temporality properties used by the OpenTelemetry
Metric SDK are determined when registering Metric Exporters through
their associated MetricReader."

But we don't connect the dots that the `aggregation` and `temporality`
options for the MetricReader should be obtained from a MetricExporter. I
think this is understood, since the whole reason these are configurable
at the MetricReader level is that MetricExporters and their associated
backends have different requirements around temporality and default
aggregation (especially in the case of base2 exponential histogram).

This PR clarifies that the MetricReader `aggregation` and `temporality`
options SHOULD come from the associated MetricExporter, NOT from the
caller.

Furthermore, because these are now clearly spelled out as preferences of
MetricExporter, I've updated all the built-in metric exporter
definitions to make expectations clear around what defaults and
configuration of `aggregation` and `temporality` should be supported.
This achieves the goals of #4124 in a more generic way.

| Exporter | default `aggregation` | `temporality` |
|---|---|---|
| Prometheus | configurable | always cumulative |
| OTLP | configurable | configurable |
| Standard Output | configurable | configurable |
| InMemory | configurable | configurable |
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:configuration Related to configuring the SDK area:sdk Related to the SDK spec:metrics Related to the specification/metrics directory
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants