Hi Alex When i built sirona I started this way: counters, gauges, validations (healthcheck).
It works not bad and enables distributed aggregations but when you think about it, it is a very limited set of what you want as a user. Quickly you will want exceptions and audit event etc.. This all lead to event driven monitoring, including the use cases of counters, gauges, .... Then you aggregate them as needed but you dont make them specific. This is a way more efficient and extensible "for real life" design than hardcoding metrics as being numbers of very specific types. Just my 2cts ;) Le 26 avr. 2018 01:13, "Alex Amato" <ajam...@google.com> a écrit : > Hello, > > I have been researching a design for sending metrics across the Beam FN > API. I just wanted to ask everyone in the Beam community about which > Dropwizard features that you use most and would like to see supported with > beam. > > *Which of these features > <https://metrics.dropwizard.io/3.1.0/getting-started/> are most relevant?* > *Gauges, Counters, Histogram, Timers, Health Checks, Other?* > > One problem which I am curious about this because Histograms/Distribution > metrics vary a bit across different metrics collection systems, and if its > possible to use a common approach for this. > > Appreciate the information about this, > Thanks > Alex >
