Knot.x Metrics

[tomaszmichalak]

Knot.x has a modular micro-service architecture so we can scale all its modules (Knots, Adapters) independently. However we need a right monitoring dashboard to visualize all its internal metrics (CPU / memory / time units). Example data we need:

• service response time (we have two Knots which are responsible for a communication with external services: ActionKnot and ServiceKnot, in the future we expect more; we need to collect metrics from all of them)
• template processing time (handlebars or other templating tool, metrics per template path; it can help with templates optimisations)
• Knots / Adapters processing time (useful for auto-scaling features)
• Knot.x request processing time (per template path)

All data should contain historical values. We should be able to narrow values to time frames.

[rkarwacki]

1. Dropwizard metrics for Vert.X provide plenty of data, but the timing of method execution "per parameter" is not one of them. You can view statistical data, histograms and min/max values, which is not really what we want since we need to know which template or service is slow. This solution, however, enables you to easily view the desired metrics via a web interface - using Jolokia and Hawtio tools. Historical values in this scenario are limited to a single session and are lost after restarting Hawtio. I'm also not sure if this solution allows you to narrow down timeframes.

2. Dropwizard core library contains a @Timed annotation, but to use it, we would have to use this AspectJ library. Also, turning this feature off periodically could be problematic. I'm also not sure how the data could be exposed in this scenario, possibly this would require writing our own module or web interface.

3. We could also use profiling tools like and view method execution times "per parameter", which is possible in e.g. JProfiler (method splitting). I was able to successfully profile execution time of processing requests, based on the requested path. Of course, this only shows the total time spent in that method, not an average execution time. I will spend some more time in JProfiler and see if it's possible to retrieve average execution time.

4. Another solution could be to write our own code for measuring execution time, and plug it in into the critical parts, like Knots or Adapters. This could be easily adapted to use our own configuration to turn the measurements on or off, depending on our needs. However, a custom way of retrieving and storing the data must also be implemented.

[malaskowski]

Implemented, see the Knot.x dashboard extension.