Open bastianeicher opened 2 years ago
Metrics and Traces are independently enabled/disabled in OpenTelemetry.
One good option would be to derive metrics from traces in the collector. (Though this has accuracy/latency implications.)
You could also consider writing your own activity processor for generating these metrics. Record the metric at Activity end
I don't really think that such a feature would conflict with the principle of enabling and disabling metrics and traces independently. Basically my suggestion would just be to consider Activity
s as sources for both:
services.AddOpenTelemetryTracing(builder => builder.AddSource("MyActivitySourceName"));
services.AddOpenTelemetryMetrics(builder => builder.AddActivityDurationHistograms("MyActivitySourceName"));
AFAIK, the term "activity" doesn't have a specific meaning in the OpenTelemetry specification. So while Activity
s can currently be mapped to tracing spans, I feel like it would be a nice addition to also be able to map them to metrics.
@alanwest Thanks for the activity processor suggestion! Another option I wanted to look into is registering my own ActivityListener
. Do you see some significant advantages to either one of these approaches?
This issue was marked stale due to lack of activity and will be closed in 7 days. Commenting will instruct the bot to automatically remove the label. This bot runs once per day.
Feature Request
Oftentimes the same things I would like trace spans for (e.g., database requests) are the things I would also like counters and/or duration histograms for.
To keep the amount of required instrumentation code small, I think it would be great to have metrics automatically generated for
Activity
s.Perhaps configured something like this: