Is it possible to collect metrics like it's done in histograms but with different aggregation?

[Karakean]

Hello, I'm working on a project which uses opentelemetry and I'm working on sending metrics via its' instruments. Up to now I've done most of metrics with histograms and everything seemed fine, I didn't notice back then that values are changed artificially to match bucket boundaries, so when I was sending value equal 2137 I received 1000 at the backend which is great underestimation. Is there any workaround? Let's say I would like to measure time of task execution in gradle build. I thought about gauge but as I want every task to have different attributes (f.e. task name or project) I assume it is impossible to use gauge as gauge has attributes declared during building instrument (correct me if I'm wrong)? What instrument should I use in this case?

[jkwatson]

You can customize the aggregations used by a particular instrument today by using a View. If you wish to update your histogram bucket boundaries, that is also possible by using a View with a custom histogram configuration. Currently, this option is pre-stable, so we've put it in our internal package space, but you can use it and try it out, as long as you're willing to accept that we'll be moving it and changing it in the future.

[jack-berg]

Actually, changing the explicit histogram bucket boundaries via views is part of the stable API today. Here's an example that switches the bucket boundaries for an instrument called foo to [5.0, 10.0, 20.0]:

      SdkMeterProvider.builder()
          .registerView(
              InstrumentSelector.builder().setName("foo").build(),
              View.builder()
                  .setAggregation(
                      Aggregation.explicitBucketHistogram(Arrays.asList(5.0, 10.0, 20.0)))
                  .build())

If using autoconfigure, there's an incubator feature which allows view configuration via yaml files. If interested, check out the docs for that here.

[jkwatson]

thanks for the correction. You are absolutely correct.

[jianwu]

Thanks @jack-berg to dig out the information. While it's possible registerView to supply custom bucket, it's not possible for auto-configure as MeterProvider was pre-created and seems it's not mutable to adjust the configuration. And to use a yaml file seems a bit of overhead and also not a right place for the metrics specific configuration. As bucket configuration is deeply coupled with the particular metrics. If we externalize the configuration from the metrics logic itself, it will creates lots of problem when we use the metrics logic.

Library Dependency Problem: For example, if we define a metrics in a library B, when A use it, it has to know all the necessary metrics configuration in library B and all the transitive dependencies and configure all of them in a top level yaml.

Is there a better way to let us specify the bucket close the where the metrics is defined programmatically. Similar to what OpenCensus did: io.opencensus.stats.Stats.getViewManager().registerView()

[jack-berg]

@jianwu this is being actively discussed as an addition to the API here. If you agree with the proposal or have feedback, please comment!