[metrics/cloudwatch] Feature request: ability to publish a sample of metrics for histograms #980

Activity

1. peterbourgon commented on May 8, 2020

   

   peterbourgon

   on May 8, 2020

   Member

   More actions

   I think this is really pushing the limits on what the Go kit metrics package can or should provide to consumers. It was only ever meant to be a very thin glue layer, a set of minimal adapters, so that the metrics interfaces could abstract over different concrete providers. It's not intended to be a place to implement value-add features like this.
2. jszwedko commented on May 8, 2020

   

   jszwedko

   on May 8, 2020

   Author

   More actions

   Thanks for the response!

   I do realize that it is adding a feature to the cloudwatch exporter, but I'm having a hard time understanding the distinction between the feature I'd like to add, and say, the exporter's current support for configuring histogram percentiles.

   Do you mean to say that this is better done by implementing a new exporter in my repository? I could definitely do that. It would be very nice to take advantage of the internal lv package in this go-kit/metrics though. Would you consider exporting that package so that external metrics exporters could use it? Either within go-kit or as a standalone repo.

   A trade-off of implementing my own exporter that the go-kit metrics exporter "ecosystem" becomes more fragmented. I did like that I could just drop in the cloudwatch exporter in go-kit which is, presumably, already battletested.
3. peterbourgon commented on May 8, 2020

   

   peterbourgon

   on May 8, 2020

   Member

   More actions

   I'm having a hard time understanding the distinction between the feature I'd like to add, and say, the exporter's current support for configuring histogram percentiles.

   It was probably a mistake to accept that "value add" stuff to Go kit.

   Do you mean to say that this is better done by implementing a new exporter in my repository?

   That might be an approach. My primary motivation is avoiding accepting the maintenance burden for features that don't necessarily need to be in the Go kit repository.

   A trade-off of implementing my own exporter that the go-kit metrics exporter "ecosystem" becomes more fragmented.

   It was never the intent that Go kit's package metrics should represent or define any kind of ecosystem. It was only the intent that it should provide the thinnest possible adapter layer, to allow "brown field" migrations from one metrics backend to another.
4. peterbourgon commented on May 8, 2020

   

   peterbourgon

   on May 8, 2020

   Member

   More actions

   It would be very nice to take advantage of the internal lv package in this go-kit/metrics though. Would you consider exporting that package so that external metrics exporters could use it? Either within go-kit or as a standalone repo.

   With the caveat that I don't consider that package particularly good anymore: yes, I can do that. Do you have opinions about where it should live? All else equal I would simply put it somewhere in the main repo, not underneath an internal subdirectory. Would that work?
5. jszwedko commented on May 8, 2020

   

   jszwedko

   on May 8, 2020

   Author

   More actions

   It was probably a mistake to accept that "value add" stuff to Go kit.

   It was never the intent that Go kit's package metrics should represent or define any kind of ecosystem. It was only the intent that it should provide the thinnest possible adapter layer, to allow "brown field" migrations from one metrics backend to another.

   Gotcha, yeah, I think I understand better the distinction you are making for the purpose of go-kit. It seems like the exporters, in general, don't really fit in here, if I'm following correctly.

   With the caveat that I don't consider that package particularly good anymore: yes, I can do that. Do you have opinions about where it should live? All else equal I would simply put it somewhere in the main repo, not underneath an internal subdirectory. Would that work?

   Now I'm curious what you don't like about it 😄 but yes, somewhere in the main repo, not under internal would suffice for my purposes.
6. peterbourgon

   added

   enhancement

   help wanted

   on Jul 17, 2021