metrics by layer

28 views
Skip to first unread message

Omar Hachami

unread,
Nov 20, 2015, 10:13:12 AM11/20/15
to metrics-user
Hello,

I'm wondering, can we -using metrics API- have a visualization by layer and having something like :

the transaction myAppli/createCostumer take 400 ms, by zooming on it i can see more details :

200 ms in JDBC layer
150 ms in JAX-WS layer
50ms in XYZ layer

Is the data structure of permit that kind of things?


Thanks,

Ryan Rupp

unread,
Nov 20, 2015, 7:41:50 PM11/20/15
to metrics-user
Potentially yes but you would have to aggregate timers with the metric name at the layer level + your transaction name. So, you could have dynamic timer metric names like:

<business-transaction-name>.<layer>

The problem there is you probably don't want to create too many different timers (for memory usage reasons although this depends on the Reservoir being used), for instance how many unique business transactions would there be * the number of layers = # of unique timers. Then in Graphite or one of the data store/reporting tools that support wildcards you could plot graphs like "myAppli/createCostume/*" where it returns a time series for each layer under the business transaction.

Personally I've found solutions that focus more on transaction tracing to be better for this, tools like New Relic (paid although there's a free tier), Stagemonitor (open source), or Zipkin (open source but a bit complicated to get up and running). Transaction tracing basically is a form of lightweight profiling, requests are captured with specific details e.g. JDBC calls/jax-ws entry point then persisted in some data store (a bit more involved then then just metrics probably). Then beyond those details usually these tools capture aggregates for the request e.g. this request executing 5 database calls which took 320ms. Then you can slice on metadata about the requests e.g. show me the slowest requests by name (endpoint name), by browser etc. Or just filter on slow requests e.g. anything over Xms and then dig into the call stack details from there. The downside of these then is usually doing it in a manner that has a low amount of overhead e.g. either rate limiting/sampling/selective and smart sampling or simply if you don't have high traffic you can potentially trace all transactions (stagemonitor just traces everything). 
Reply all
Reply to author
Forward
0 new messages