opencensus-specs
opencensus-specs copied to clipboard
census-instrumentation
Trace limits cannot be measures
https://github.com/census-instrumentation/opencensus-specs/pull/141 introduces the concept of tracking the number of dropped entities by using measures.
There are a few problems with this approach:
- For a user who only wants to depend on a tracing backend, there is no good way to upload this data.
- For a user who wants to see how many entities are dropped from a span, there is no way.
These numbers should better be reported as attributes on the span.
/cc @ramonza @bogdandrutu @songy23
Reading the spec again, it suggests measure implementations optionally but it doesn't document what library implementations MUST implement. Rather than suggesting these additional features (which can be implemented at the exporter), why don't we define the core expected behavior first?
I agree that we should support recording them as attributes for backends that don't have dedicated fields for them. Stackdriver, for example, has dedicated fields to track dropped items IIRC.
As for measures, I think tracking dropped items with metrics is almost always the right thing to do. I know it might be tricky in some languages due to dependency issues. I think that is a separate question from the usefulness and it's why I made it optional.
FWIW in Go because of the separation of the recording from view package, depending on just stats will not pull in the whole view package.
So my recommendation is that we do both. I don't think we should implement it in the exporter - that will just mean that each exporter has their own set of metrics which is confusing because what's actually dropping the data is not the exporter but the trace library itself.
As for measures, I think tracking dropped items with metrics is almost always the right thing to do.
What do you mean by this? How many of our users will have dashboards and set alerts to monitor the dropped objects.
that will just mean that each exporter has their own set of metrics
No. We can have an exporter wrapper that provides the views. Any vendor-specific exporter can be wrapped by it if user wants this feature.
My recommendation is not to support limit measures and add this as an additional feature via an exporter wrapper under exporter/exporterutil if necessary.
What do you mean by this? How many of our users will have dashboards and set alerts to monitor the dropped objects.
Not necessarily AOT dashboards but lets say you expect some attribute to be there and it isn't. At that point you can define a view on the measures and check if something is being dropped. That's one of the best features of OpenCensus stats IMO: you don't need to think of every possible thing as a dashboard that you define up-front but you can do exploratory debugging when a problem occurs.
I have a strong opinion on where it's implemented as long as it doesn't have to be implemented by each exporter separately and we specify the measures here in the specs repo.