We already explained how to take monitor your Integrations in the previous blog post about monitoring operations on Camel K. The good news is there are only a few changes with the move to Micrometer Metrics.
From Microprofile to Micrometer
Camel K 2.0 was the occasion to move from one technology (Microprofile) to another (Micrometer) for the Prometheus trait configuration implementation.
The reason is the deprecation notice from Quarkus Microprile’s implementation in favor of using Micrometer Metrics. This decision follows a long period of transition from Quarkus project.
This change brings some powerful improvments for your monitoring. Micrometer delivers more advanced features such as hierarchical meters and dimensional data models, while MicroProfile Metrics provides a simpler API with basic metric types such as counters and gauges. Additionaly, Micrometer provides a simple facade over the instrumentation clients for the most popular monitoring systems, letting any library provides its own metrics through it.
Camel framework changes expected in Micrometer
Metrics are generated by two types of sources:
- the libraries powered by Camel components
- the Micrometer Camel component
Since Micrometer provides a facade, the changes in the default metrics from the libraries powered by camel components will depend on what they expose.
Before Camel K 2.0, the default camel metrics where provided by the camel Microprofile Metrics component. Now they default camel metrics are provided by the Micrometer Component. As you can see in the documentations, there are some changes in the naming and the metrics.
NOTE: There has been some recent change in the Micrometer Camel component on naming conventions so depending on your camel version you can expect ‘CamelExchangesTotal’ to change to ‘camel.exchanges.total’ starting from Camel 4. Please refer to the compatibility matrix to know which version of Camel is used.
One of the most important change concerns the notions of route and context in the metrics:
# Microprofile metrics
# HELP application_camel_context_exchanges_total The total number of exchanges for a route or Camel Context
# TYPE application_camel_context_exchanges_total counter
application_camel_context_exchanges_total{camelContext="camel-1"} 0.0
# HELP application_camel_route_exchanges_total The total number of exchanges for a route or Camel Context
# TYPE application_camel_route_exchanges_total counter
application_camel_route_exchanges_total{camelContext="camel-1",routeId="route1"} 0.0
application_camel_route_exchanges_total{camelContext="camel-1",routeId="route2"} 0.0
# Micrometer metrics
# TYPE CamelExchangesTotal counter
# HELP CamelExchangesTotal Total number of processed exchanges
CamelExchangesTotal_total{camelContext="camel-1",routeId="route2",serviceName="MicrometerRoutePolicyService"} 0.0
CamelExchangesTotal_total{camelContext="camel-1",routeId="route1",serviceName="MicrometerRoutePolicyService"} 0.0
The best way to anticipate the changes you should expect is to verify the exposed metrics accessing to /q/metrics endpoint of your integrations as explained in the blog post about monitoring.
Conclusion
As Metric is one of the pillar of Observability, this blog gave a better understanding on how to embrace the changes introduced in Camel K 2.0.
If you have any feedback, ideas or find a new issue, please create a new issue report in GitHub!