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

Feature request: Allow reading structable attributes #110

Open
nhawkes opened this issue Feb 4, 2023 · 0 comments
Open

Feature request: Allow reading structable attributes #110

nhawkes opened this issue Feb 4, 2023 · 0 comments

Comments

@nhawkes
Copy link

nhawkes commented Feb 4, 2023

At the moment tracing-opentelemetry does a somewhat of a hack to know what fields are metrics. It requires the field name to be prefixed

To publish a new metric, add a key-value pair to your tracing::Event that contains following prefixes:

  • monotonic_counter. (non-negative numbers): Used when the counter should only ever increase
  • counter.: Used when the counter can go up or down
  • value.: Used for discrete data points (i.e., summing them does not make semantic sense)
async fn current_example() { 
     tracing::info!(histogram.racecar.speed = 80_f64);
}

Instead if attributes were exposed it would be possible to do something like this:

/// How fast the racecar is going
#[derive(Valuable)]
#[histogram(key="racecar.speed", unit="mph")]
struct RacecarSpeed(f64);

#[tokio::test]
async fn proposed_example() {
    tracing::info!("Going at {}mph", speed=RacecarSpeed(777.0012_f64));
}

I think there's two approaches here: expose the attributes directly, or expose the typeid and require subscribers to map that typeid to the attribute

@nhawkes nhawkes changed the title [Feature request] Allow reading structable attributes Feature request: Allow reading structable attributes Feb 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant