Implementing dropwizard emitter for druid#7363
Conversation
|
@jihoonson @b-slim: Can you please help with the review here ? |
There was a problem hiding this comment.
this is scary, how much it accumulates is this onheap or offheap? is there a config to bound this ?
There was a problem hiding this comment.
the accumulation does not mean it queues things up, it stores the latest values in the metrics registry, the memory usage depends on the number of metrics and metric types.
Note: We are not handling all individual query metrics here, it's just the metrics defined in the extension config which are counters, gauges and timers. So have minimal impact on heap usage.e.g. for a counter it uses a single AtomicLong, for gauge it gives an instantaneous value and we are caching that in the metrics extensions impl.
https://metrics.dropwizard.io/4.0.0/getting-started.html has more details on the individual event types.
There was a problem hiding this comment.
does this includes host and ports ? or only host?
There was a problem hiding this comment.
host and port both, It is essentially ServiceMetricEvent.getHost() value
There was a problem hiding this comment.
Would you please make the doc more clear that it includes both host and port?
There was a problem hiding this comment.
am trying to understand here, why a used would like to get a metric without dimension name? am not sure am getting this.
There was a problem hiding this comment.
it is mostly a copy of other stats-d emitter extension and left over of that, Agree, It is not much useful for dropwizard, will remove
There was a problem hiding this comment.
is statsD a typo mistake or it is actually called statsD ?
There was a problem hiding this comment.
left over of copy and paste, fixed.
There was a problem hiding this comment.
can we add a link to the default mapping ?
There was a problem hiding this comment.
how about ignored or warning ? seems like error is too much, especially in Druid we add metrics pretty often.
There was a problem hiding this comment.
changed to ignored.
There was a problem hiding this comment.
can you please add docs on how and why this will return null ? plus i see this nullable annotation all over the Druid code, am not sure what is used for?
There was a problem hiding this comment.
added javadoc. null is returned when there is no mapping for a metric.
There was a problem hiding this comment.
reading the signature of this method i can not tell what is actually doing and why a map object is called a builder ?
There was a problem hiding this comment.
changed the builder to filteredDimensions and mentioned it in javadoc.
There was a problem hiding this comment.
can we do this in one get and a null check?
There was a problem hiding this comment.
what is the meaning of null ?
There was a problem hiding this comment.
it means no mapping found for metric
There was a problem hiding this comment.
how about closing the stream on exception ?
There was a problem hiding this comment.
Hmm, why is is not closed on normal exit?
There was a problem hiding this comment.
thought ObjectReader.readValue will close the stream in normal flow
There was a problem hiding this comment.
ObjectReader.readValue(..) doesn't mention closing the InputStream by itself, it might be safer to close it in finally block.
There was a problem hiding this comment.
not sure why we are not guarding this and check for start not set ?
There was a problem hiding this comment.
Hmm, when can it be called twice? It should be managed by the lifecycle.
There was a problem hiding this comment.
yeah, it should be called through lifecycle, It seems other emitter has guards too so i added a it here also.
There was a problem hiding this comment.
LifecycleLock utility is useful for this usecase
There was a problem hiding this comment.
same as for start, shouldn't we check for start is true ?
There was a problem hiding this comment.
can we make sure this is not blocking?
There was a problem hiding this comment.
yes, it is non-blocking, basically a no-op for the current two implementations of reporters.
There was a problem hiding this comment.
we could mention that it must be non blocking in the javadoc of DropwizardReporter.flush(), so that if someone implements another then they know about it.
There was a problem hiding this comment.
can we use native JDK functions/streams and move away from guava.
There was a problem hiding this comment.
nothing to close ? this reporter has not state to clean ?
There was a problem hiding this comment.
not sure why this change is needed ?
|
@nishantmonu51 am very ignorant of this DropWizard stuff, can you please explain where the metrics are buffered ? and how often cleaned ? how we can make sure it does not overflow ? and how the JMX one works do we need some Jvm flags to be set to turn it on can you please document how we can test that ? |
There was a problem hiding this comment.
so if let say we have a metric where the set of the key grows over time eg queryId or something similar, this map will grow without any bound and that can lead to big troubles, how about making the keys weak refs or having an actual limit on the size of this map ?
There was a problem hiding this comment.
looking into it, we can add a limit to the map size.
There was a problem hiding this comment.
added a limit to the size of map.
|
This pull request has been marked as stale due to 60 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that's incorrect or this pull request should instead be reviewed, please simply write any comment. Even if closed, you can still revive the PR at any time or discuss it on the dev@druid.apache.org list. Thank you for your contributions. |
|
This pull request/issue is no longer marked as stale. |
1 similar comment
|
This pull request/issue is no longer marked as stale. |
1c234e0 to
be2b9a0
Compare
|
@jihoonson @b-slim : Updated PR based on review comments, please check. |
There was a problem hiding this comment.
| druid.emitter.dropwizard.reporter={"type":"jmx"} | |
| druid.emitter.dropwizard.reporters=[{"type":"jmx"}] |
There was a problem hiding this comment.
| druid.emitter.dropwizard.reporter={"type":"console","emitIntervalInSecs":30}"} | |
| druid.emitter.dropwizard.reporters=[{"type":"console","emitIntervalInSecs":30}"}] |
There was a problem hiding this comment.
I wonder if it is possible to point this to actual file in the source code because this has the potential to go out of sync
There was a problem hiding this comment.
added a link too. Initially it was a link only but added the file as part of review comments.
There was a problem hiding this comment.
should use string format instead of concatenations here and in all other places as this code is gonna be called many many times.
There was a problem hiding this comment.
null/empty check ? it would be useless to set it up with no reporters and probably a configuration error.
There was a problem hiding this comment.
| private final Map<String, Number> gagues; | |
| private final Map<String, Number> gauges; |
There was a problem hiding this comment.
could we use guava Cache instead of doing our own ?
There was a problem hiding this comment.
done. replaced it use caffeine cache instead.
making metric manager and alert emitters as optional
more improvements improve docs refactrings
review comments review comments
db901a6 to
8775f16
Compare
|
LGTM overall, can you please address |
This is an update for previous PR - #4196
Corresponding issues are
#3927
#1996
This extension integrates Dropwizard metrics library with druid so that dropwizard users can easily absorb druid into their monitoring ecosystem. It accumulates druid metrics as dropwizard metrics, and emits them to various sinks via dropwizard supported reporters.
Currently supported dropwizard metrics types counter, gauge, meter, timer and histogram.
These metrics can be emitted using either Console or JMX reporter.
Support for other reporters can be easily added in future PRs.
Note - I have cherry-picked the commit from previous author to provide him the credit of his work.