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

Prometheus exporter handles instrumentation scope and prevents collisions #3467

Closed
dashpole opened this issue Dec 2, 2022 · 8 comments
Closed

Comments

@dashpole
Copy link
Contributor

dashpole commented Dec 2, 2022

Now that open-telemetry/opentelemetry-specification#2703 is released, we can update the prometheus exporter to make use of OpenTelemetry scope, particularly for reducing collisions between metrics with the same name.

Describe the solution you'd like

There are a few components:

Note that the exporter SHOULD do the above by default, but may allow disabling the behavior.

Also, note the consideration described in open-telemetry/opentelemetry-python#3072 (comment) around grouping metrics from different scopes together in the exposition.

@mothershipper
Copy link
Contributor

Not sure if this is related or not, but we're hitting an issue with the prometheus exporter and the http instrumentation. I added some debug logging and it looks like the histograms created by the instrumentation-http get created twice?

This results in a serialization error where TYPE, HELP, UNIT get duplicated -- only reason why I think it might not be the same issue as above is that these histograms are created under the same scope:

Debug code:

   for (let metric of metrics.scopeMetrics) {
     console.log(`scope: ${metric.name}`)
      for (const data of metric.metrics) {
        console.log(data.descriptor)
    }

prints:

scope: @opentelemetry/instrumentation-http
{
  name: 'http.server.duration',
  type: 'HISTOGRAM',
  description: 'measures the duration of the inbound HTTP requests',
  unit: 'ms',
  valueType: 1
}
{
  name: 'http.server.duration',
  type: 'HISTOGRAM',
  description: 'measures the duration of the inbound HTTP requests',
  unit: 'ms',
  valueType: 1
}
{
  name: 'http.client.duration',
  type: 'HISTOGRAM',
  description: 'measures the duration of the outbound HTTP requests',
  unit: 'ms',
  valueType: 1
}
{
  name: 'http.client.duration',
  type: 'HISTOGRAM',
  description: 'measures the duration of the outbound HTTP requests',
  unit: 'ms',
  valueType: 1
}

And serializes to:

# HELP http_server_duration measures the duration of the inbound HTTP requests
# UNIT http_server_duration ms
# TYPE http_server_duration histogram
# HELP http_server_duration measures the duration of the inbound HTTP requests
# UNIT http_server_duration ms
# TYPE http_server_duration histogram
# HELP http_client_duration measures the duration of the outbound HTTP requests
# UNIT http_client_duration ms
# TYPE http_client_duration histogram
# HELP http_client_duration measures the duration of the outbound HTTP requests
# UNIT http_client_duration ms
# TYPE http_client_duration histogram

@dashpole
Copy link
Contributor Author

dashpole commented Dec 6, 2022

To me that looks like a related, but different issue. One reason why comments may be duplicated is because the same metric exists in multiple scopes, which this issue was opened to address.

It looks like you've encountered a bug in which each unique set of labels for a metric produces a new set of HELP, UNIT, and TYPE comments, which it should not do.

@mothershipper
Copy link
Contributor

mothershipper commented Dec 6, 2022

I've narrowed it down to the autoloader -- the Instrumentation constructor inits the metrics first, then the call to registerInstrumentation passes in the same meterProvider to enableInstrumentations, triggering the instrumentation to re-create the metrics against the original meter/meterProvider.

Would you like me to create a separate issue?

@dashpole
Copy link
Contributor Author

dashpole commented Dec 7, 2022

I would prefer a separate issue, thanks!

@github-actions
Copy link

github-actions bot commented Feb 6, 2023

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the stale label Feb 6, 2023
@legendecas legendecas removed the stale label Feb 7, 2023
@github-actions
Copy link

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the stale label Apr 10, 2023
@github-actions
Copy link

This issue was closed because it has been stale for 14 days with no activity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 19, 2023
@dashpole
Copy link
Contributor Author

I would appreciate if this was reopened. It is still relevant.

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

No branches or pull requests

3 participants