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.

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

Jump to bottom

Determine the structure for Metrics instrumentation #1127

Open
kaylareopelle opened this issue Aug 19, 2024 · 3 comments · May be fixed by #1129 or #1213
Open

Determine the structure for Metrics instrumentation #1127

kaylareopelle opened this issue Aug 19, 2024 · 3 comments · May be fixed by #1129 or #1213
Assignees
@kaylareopelle
Labels
keep Ensures stale-bot keeps this issue/PR open

Comments

@kaylareopelle
Copy link
Contributor

Metrics are still veryyy experimental, but, for those willing to take the risk, I'd like to start building instrumentation that can emit metrics.

Before we can do that, we need to decide how to keep the stable traces code safe from experimental metrics.

Current ideas:

  • More than one condition needs to be true to turn on metrics (show that you really really want this)
    • First requirement: The presence of the Metrics API is detected
    • Second requirement: The configuration enables metrics
  • Only emit HTTP metrics that

Potential approaches:

  • Similar to the ConfigurationPatch that allows the Metrics SDK to use the Configurator, create a separate module that only gets loaded if the conditions to enable metrics are met
  • Put conditionals everywhere to check to see if metrics should be generated
  • Create separate libraries to emit metrics (not a huge fan on this one)
@kaylareopelle kaylareopelle self-assigned this Aug 19, 2024
@kaylareopelle
Copy link
Contributor Author

Some ideas:
#1128 - Puts conditions all over the place to check for the right conditions to send metrics
#1129 - Load the metrics-related code only if certain conditions are met

@github-actions GitHub Actions
Copy link
Contributor

👋 This issue has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the keep label to hold stale off permanently, or do nothing. If you do nothing this issue will be closed eventually by the stale bot.

@github-actions github-actions bot added the stale Marks an issue/PR stale label Sep 19, 2024
@kaylareopelle kaylareopelle added keep Ensures stale-bot keeps this issue/PR open and removed stale Marks an issue/PR stale labels Sep 20, 2024
@kaylareopelle kaylareopelle linked a pull request Sep 20, 2024 that will close this issue
feat: 🦠 Metrics prototype for Rack instrumentation #1129
Open
@kaylareopelle kaylareopelle linked a pull request Sep 20, 2024 that will close this issue
Open
@kaylareopelle
Copy link
Contributor Author

Todo:

  • Refactor so that metrics duration, attributes are not directly copied off the span
  • Create a separate handler for metrics
  • Prototype the meter configurator to control sending metrics/traces

@kaylareopelle kaylareopelle linked a pull request Oct 24, 2024 that will close this issue
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@kaylareopelle kaylareopelle

Labels
keep Ensures stale-bot keeps this issue/PR open
Projects
None yet
Milestone
No milestone
1 participant
@kaylareopelle