Package io.mats3.intercept.micrometer

Class MatsMicrometerInterceptor

java.lang.Object
io.mats3.intercept.micrometer.MatsMicrometerInterceptor
All Implemented Interfaces:
MatsInitiateInterceptor, MatsInterceptable.MatsMetricsInterceptor, MatsStageInterceptor
public class MatsMicrometerInterceptor extends Object implements MatsInterceptable.MatsMetricsInterceptor, MatsInitiateInterceptor, MatsStageInterceptor
An interceptor that instruments a MatsFactory with metrics using the (Spring) Micrometer framework. If you provide a MeterRegistry, it will employ this to create the metrics on, otherwise it employs the Metrics.globalRegistry.

Note: This interceptor (Micrometer Metrics) has special support in JmsMatsFactory: If present on the classpath, it is automatically installed using the install(MatsInterceptableMatsFactory) install method. This implies that it employs the Micrometer 'globalRegistry' - and 'includeAllTags' will be false. If you rather want to supply a specific registry, then install a different instance using the install(MatsInterceptableMatsFactory, MeterRegistry, boolean) method - the JmsMatsFactory will then remove the automatically installed, since it implements the special marker-interface MatsInterceptable.MatsMetricsInterceptor of which there can only be one instance installed. (In a Spring context where the MatsFactory is created for you using an annotation, you are still able to do this during early phases of Spring initialization: E.g. inject a reference to the MatsInterceptable (the MatsFactory) and just install the new instance. This is possible since the Micrometer meters are lazily created when initiations are performed and Mats Stages receives messages. The decision of which tags are in use is therefore not needed until right before the service becomes operational, that is, performs inits and receives messages.)

Note the argument 'includeAllTags' on the second install(..) method: If this is true, then tags will be added to the meters which will give higher semantic resolution and more information, but which might result in a quite substantial number of time series - if you have a popular Mats endpoint with many stages targeted by many other services (thus getting many differing 'from', 'initiatingAppName' and 'initiatorId'), you may get a "cardinality explosion", in particular if you also configure histograms. It is thus false by default, i.e. when using the first install(..) method.
Which extra tags are omitted in which situations when 'includeAllTags' is false:

  • Received (incoming message): "from" (from which stage) for initial stage, "initiatingAppName" and "initiatorId".
  • Stage execution: "initiatingAppName" and "initiatorId".
  • Stage outgoing messages: "to" (to which stage) for REPLY-messages (as that will have same cardinality as 'from'), "initiatingAppName" and "initiatorId".
You may set 'includeAllTags' to true, and then use a MeterFilter to tweak the tags with more precision than this all-or-nothing approach, e.g. include "initiatingAppName" and "initiatorId" for specific endpoints or stages.

Notice the class MatsMicrometerInterceptor.SuggestedTimingHistogramsMeterFilter, which configures the timing-specific metrics with hopefully relevant histograms. You may apply this as such:
Metrics.globalRegistry.config().meterFilter(new SuggestedTimingHistogramsMeterFilter());
.. or you may apply any other distribution or histogram configuration using the MeterFilter logic of Micrometer.

See Also: