Micrometer: Add a `LoggingMeterRegistry` that summarizes metrics to a logger

Created on 16 May 2018  路  9Comments  路  Source: micrometer-metrics/micrometer

For those cases where we get questions about what metrics are being exported (especially when they don't appear to be showing up in a typical monitoring system).

Most helpful comment

For reference. Here is a dropwizard metric logged output. It's quite readible

2018-07-06 17:00:28,884 [metrics-logger-reporter-thread-1] [INFO] (com.codahale.metrics.Slf4jReporter) type=METER, name=io.dropwizard.jetty.MutableServletContextHandler.async-timeouts, count=0, mean_rate=0.0, m1=0.0, m5=0.0, m15=0.0, rate_unit=events/second

2018-07-06 17:00:28,884 [metrics-logger-reporter-thread-1] [INFO] (com.codahale.metrics.Slf4jReporter) type=TIMER, name=com.impinj.itemsense.agent.TaskRepositoryDao.rawGetNextTaskForReader, count=209, min=145.511, max=7976.1320000000005, mean=858.4775167464114, stddev=1347.4190261974575, median=394.425, p75=594.4985, p95=4190.705, p98=7013.792999999979, p99=7880.0349000000015, 

All 9 comments

Some random thoughts:

  • a log entry per metric or a all in one? (the latter might overwhelm producer and consumer)
  • structured (json?) vs plain text? (think structured log analysis and the presentation of more complex metrics like timers/distributionsummaries)

All good questions :)

  • Unless there is a reason not to, I think a log per metric makes sense?
  • I can imagine that declarative dimensional pre-aggregation that is needed for CloudWatch and JMX is equally useful here along with a whitelist to pare the list down to just a set of things you care about.
  • No idea on format. JSON isn't great for readability, but I suppose benefits structured log analysis? Suggests a configurable format?

I wonder if there is a Splunk person out there that would have an opinion.

No idea on format. JSON isn't great for readability, but I suppose benefits structured log analysis? Suggests a configurable format?

Was just an example. In the golang world most structured loggers seem to go for the key1=value key2=value key3="some whitespace text" style which I tend to find quite readable.

I think a summarized option would be most useful. It could output:

Total Metrics being recorded: 123

or perhaps:

Counters: 50 Timers: 60 LongTaskTimers: 13 Total metrics: 123

I think a details one is also useful, but the summary one could help people answer 'is it working?'

Here's an example of a textual representation of metrics from years past: http://jetm.void.fm/views/monitoring_examples.html

For reference. Here is a dropwizard metric logged output. It's quite readible

2018-07-06 17:00:28,884 [metrics-logger-reporter-thread-1] [INFO] (com.codahale.metrics.Slf4jReporter) type=METER, name=io.dropwizard.jetty.MutableServletContextHandler.async-timeouts, count=0, mean_rate=0.0, m1=0.0, m5=0.0, m15=0.0, rate_unit=events/second

2018-07-06 17:00:28,884 [metrics-logger-reporter-thread-1] [INFO] (com.codahale.metrics.Slf4jReporter) type=TIMER, name=com.impinj.itemsense.agent.TaskRepositoryDao.rawGetNextTaskForReader, count=209, min=145.511, max=7976.1320000000005, mean=858.4775167464114, stddev=1347.4190261974575, median=394.425, p75=594.4985, p95=4190.705, p98=7013.792999999979, p99=7880.0349000000015, 

image

hi @jkschneider , when I use LoggingMetricsExportAutoConfiguration, webMvcMetricsFilter would throw an exception, the detail is
https://github.com/micrometer-metrics/micrometer/issues/1431

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ericsogm picture ericsogm  路  3Comments

Comrada picture Comrada  路  4Comments

samanthacatania picture samanthacatania  路  4Comments

jonatan-ivanov picture jonatan-ivanov  路  3Comments

exploder86 picture exploder86  路  3Comments