Replies: 1 comment 1 reply
-
I think this is largely covered by #666 (which hasn't been resolved yet). You might also be interested in #679. In short, the existing Micrometer metrics reporter is pretty terrible. I wrote it before I had any significant exposure to Micrometer and really understood what it was doing with tags or naming and made some bad assumptions about names plugging into a deeper hierarchy (which is the case with Dropwizard metrics). I've been mostly deferring work on this until #540 is done because I think that will drastically change the "shape" of metrics reporting (for the better!). I promise I'm still chipping away at that, even though world events have slowed me down a bit lately. I recognize that's not a super satisfying answer, but I hope it sheds some light on the situation! I think the criticism of the existing implementation is completely valid, and I agree that it needs to change. |
Beta Was this translation helpful? Give feedback.
-
Hi !
I am looking at the metric names in MicrometerApnsClientMetricsListener and they look a little too generic:
connections.failed
ornotifications.accepted
doesn't look very APNS-specific at all. Tags is not really an option as the metric is very different from other kind of "connections" or "notifications" I may have in my app (maybe push, maybe other kind of stuff).it'd be nice to be able to add a prefix to the metric names so that they can be "namespaced" in "apns". Is there an easy way to achieve it? I'm thinking in wrapping the MeterRegistry I pass to pushy, but it'd be better probably if the library allowed it directly.
Beta Was this translation helpful? Give feedback.
All reactions