These are chat archives for spring-cloud/spring-cloud

6th
Apr 2015
Chris Phillipson
@fastnsilver
Apr 06 2015 19:34
wanted to sync up on my efforts. i opted to go all in with io.dropwizard.metrics and some extensions. the result is this gist: https://gist.github.com/fastnsilver/bf3bd2dd3d7b00662c7e. the concern again is that i might not get certain spring boot metrics (shipped to graphite, stated, and/or cloud watch). had tried to declare an exporter that read from inmemorymetricsrepository and writes with dropwizardwriter, but was getting illegal argumentexceptions on counter metrics.
Dave Syer
@dsyer
Apr 06 2015 20:10
Sounds wrong
You don't need an exporter to go to dropwizard (it just happens if the MetricRegistry bean gets created)
You want dropwizard because they have a native exporter for cloud watch?
(Didn't understand the "concern" above)
Chris Phillipson
@fastnsilver
Apr 06 2015 21:12
i just wanted to make sure that spring boot metrics (too) are written through to cloudwatch and graphite. the cloudwatch and graphite configs are dependent on extensions as in gist.
Dave Syer
@dsyer
Apr 06 2015 21:25
Is it common to use both graphite and cloud watch?
I see from the gist that you are able to support both
Chris Phillipson
@fastnsilver
Apr 06 2015 21:26
can’t say it’s common, just that there’s a need until there’s a transition
Dave Syer
@dsyer
Apr 06 2015 21:26
But only if the user wants to include dropwizard
Chris Phillipson
@fastnsilver
Apr 06 2015 21:26
yes
Dave Syer
@dsyer
Apr 06 2015 21:26
So I guess in your user base that's not a big deal
I'm asking because I'm looking at metrics for Boot 1.3 to see what we can improve
Chris Phillipson
@fastnsilver
Apr 06 2015 21:27
concerns?
Dave Syer
@dsyer
Apr 06 2015 21:27
Performance will be a big thing
Chris Phillipson
@fastnsilver
Apr 06 2015 21:28
well, there’s a big push to aws where i am working currently. i imagine many others are too. haveing cloudwatch integration via spring without the dependency on dropwizard would be pretty cool.
Dave Syer
@dsyer
Apr 06 2015 21:28
I also don't always want to say that you have to use dropwizard if you want to do exports.L
Chris Phillipson
@fastnsilver
Apr 06 2015 21:28
batching metrics on a separate thread?
Dave Syer
@dsyer
Apr 06 2015 21:29
Batching exports is key
Chris Phillipson
@fastnsilver
Apr 06 2015 21:29
it’s nice that you wrote the exporter to be open for such use cases
Dave Syer
@dsyer
Apr 06 2015 21:30
Treating dropwizard as an export might be an option
It works for vanilla counter and gauge use cases
Not sure about others
Chris Phillipson
@fastnsilver
Apr 06 2015 21:31
dimensions and units are another area where metric is lacking
and tags
Dave Syer
@dsyer
Apr 06 2015 21:31
My simple observation is this (as far as performance goes) you can write really fast if you know that reading is batched and all from a single thread
The gold standard (or lowest common denominator) is graphite
IMO it's probably not worth getting more fancy than that with metadata
It will probably kill performance of nothing else (if you get more fancy)
So tags and units are more of a post processing thing. You can't ingest that kind of information fast enough
And it doesn't change from measurement to measurement
(Which is not to say that we couldnt support more of that in Boot)
It just means the primary interfaces are solid (I believe). We would have to add more.
Chris Phillipson
@fastnsilver
Apr 06 2015 21:41
i suppose one can find meaning from the name and deduce the unit and/or dimension; but it’d be nice to see that in json export or jmx; but yes, performance would take a hit. however in aws api i see dimension and unit in com.amazonaws.services.cloudwatch.model.MetricDatum