java - Appropiate Design Pattern to track metrics with Dropwizard -

i researching dropwizard metrics, goal measure counters , histograms in real time, sending them elasticsearch instance.

even have found easy make work @ development stage, wonder if there way add metrics code project grows while keeping clean.

is there commonly used design pattern when tracking metrics? mean, implementation let mantain our code decoupled, business metrics.

the possible approaches have been considering are:

a) aop: clean, still code in business classes.

b) http proxy , forward requests specific microservice/api, camel or similar tool. maybe sophisticated, , afraid add latency.

thanks!

this rather confusing question. i'll try it:

by sound of it. doing things in weird way. metrics has it's own best practise , since measuring business logic, if want have in detail, don't see how can not put code in business class. e.g., need submit metrics anyway, this:

try (context time = metrics.timer(send_time).time()) {      // business operations , send  } 

so, way "maybe" around it, using interceptors. they'll wrap business method calls metric , that's that. believe, using guice, can intercept each , every method call make, recording everything.

that of course make lose details. can measure methods, not in methods. of course, can split methods in smaller methods , record more details - make code cleaner?

the typical use of metrics, way see it, have 1 registry holds metrics, , inject registry classes want measure using metrics. approach fine in opinion.

the issue comes reporting. want in real time? means, want each metric submit request es instance index whatever measured.

that approach has 2 problems:

1. if make request every single metric measure, kill application. can make request asynchronous, since don't want loose anything, you'll still have worry outages, dos, retries etc etc etc. you'll busy spanning threads tracking metrics, won't have left logic want measure in first place. sounds bad idea.

2. you use reporter. work asynchronously, don't much, don't use resources etc. not real time anymore. reporters typically run every minute or so, you'll have delay. , yes, can run reporter every 10 seconds, every 1 second etc. - you'll not real time. , once small enough, depending on implementation, have problem 1 again application trying talk elastic search.

in case need reporter: https://github.com/elastic/elasticsearch-metrics-reporter-java

so essentially, confused approach, again never had real time reporting.

we use near-realtime reporting, means, have maximum delay of 1 minute fine , our customers. how can shift data application reporting hosts without compromising application performance.

i reading can use es client impl, talks directly cluster rather using http requests index data. might give more performance, believe 1 , 2 still hold.

i hope helps,

artur