opencensus-specs
opencensus-specs copied to clipboard
census-instrumentation
Decide the scope of data collection
Currently, we don't recommend any policy about the scope of data collection. For example, the Go stats package only provides data collection via the global mechanism. Once turned on, it will collect data from all OC-instrumented code in the process. Users cannot specially target and collect data from a component or library.
The spec should address this problem by either suggesting OpenCensus implementations to provide non-global mechanism or document that the global collection is an expected behavior.
/cc @dinooliva @sebright @bogdandrutu
Defining a non global option sgtm. When you cant control your runtime, or need to do things like unload classes, it is often the default choice. In Brave (java library similar to census tracing) we actually discourage globals.
My expectation was that data export would be conditioned on registering views on specific measures, and most/all measures would be component/library-specific. Even if a library registers views on its own measures, they could be specifically unregistered without interfering with other stats collection.
My question is whether we want exporter-specific registration, assuming the user has control of which views to export in aggregate.
My question is whether we want exporter-specific registration, assuming the user has control of which views to export in aggregate.
This issue came up in opencensus-java. We wanted to allow gRPC to register views for RPC stats and also make it easy for users to export all gRPC views with the StackDriver exporter. The current solution is to automatically export all registered cumulative views to all exporters (https://github.com/census-instrumentation/opencensus-java/pull/803), but it would be nice to give users more control in a later version.
This issue came up in opencensus-java. We wanted to allow gRPC to register views for RPC stats and also make it easy for users to export all gRPC views with the StackDriver exporter.
The Go client's behavior here is slightly different. We register the views to claim the name but expecting users to subscribe to them to enable data collection. Subscription can be done per exporter. I am happy to revise this after the initial release.
The subscription approach is single consumer or multiple? Sounds nice to only aggregate when someone is subscribed..
On 22 Nov 2017 2:55 am, "JBD" [email protected] wrote:
This issue came up in opencensus-java. We wanted to allow gRPC to register views for RPC stats and also make it easy for users to export all gRPC views with the StackDriver exporter.
The Go client's behavior here is slightly different. We register the views to claim the name but expecting users to subscribe to them to enable data collection. Subscription can be done per exporter. I am happy to revise this after the initial release.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/census-instrumentation/opencensus-specs/issues/26#issuecomment-346125657, or mute the thread https://github.com/notifications/unsubscribe-auth/AAD615f4qGQ3mZxNH8SUK-H7AAQu-lGxks5s4xydgaJpZM4Qd8Wz .
@adriancole, it is a single consumer model. When a view is subscribed to, the global aggregation enables collection of data from that view and the aggregated data is exported via the registered exporters.
@rakyll
Subscription can be done per exporter.
Was this how it worked before? I really like this but seems like it doesn't work like that any more.
