Question on opencensus-ext-azure metrics

[jdvor]

Context: I've been using Azure Application Insights / Monitor practically on daily basis in last few years. As of recently this was from C# .NET based apps and services using TelemetryClient and for the metrics specifically there is a dead simple method
TrackMetric(string name, double value, IDictionary<string, string> properties = null).
Now I have to do the same from python and discovered opencensus.

Question: In opencesus; specifically opencensus-ext-azure and examples such as this one; publishing metrics seems to be much more complex enterprise. There seems to 7-9 moving parts such as measure, measure_map, view, view_manager, starts_recorder, exporter, etc. These have to be orchestrated together and they seem to have different lifetimes / existence scopes and call dependencies (such as MeasurementMap.measure_*_put and MeasurementMap.record). So my question is, why is there such complexity?

And please do not take this question as some critique of the API. I'm genuinely interested.

[lzchen]

@jdvor
Hey thanks for taking an interesting in Opencensus. And also GREAT question by the way. Metrics for opencensus-ext-azure is built off of Opencensus stats model which utilizes all of these moving parts that you have mentioned. This design is aimed towards optimizing pre-aggregation of metrics and filtering/grouping by tags (which are like custom_dimensions in appinsights). I agree the api surface is quite complicated but the tradeoff allows for some great features related to metrics (custom aggregation types per metric, aggregation on the client, stateless/stateful metrics). We are planning on improving the api surface to make it easier for the simple use cases (like trackmetric) in Opentelemetry, which is still in beta.

[jdvor]

@lzchen Thanks for the answer.