jbonofre's blog

Apache Karaf Decanter 2.4.0 will be released soon and include a set of new collectors. Oshi Collector The oshi collector harvest a bunch of data about the hardware and the operating system. It’s a scheduled collector, executed periodically (every minute by default). You can have all details about the machine thanks to this collector: motherboard, cpu, sensors, disks, etc, etc. By default, the oshi collector retrieves all details, but you can filter what you want to harvest in the etc/org.apache.karaf.decanter.collector.oshi.cfg configuration file. It means now we have the system collector that allows you to periodically execute scripts and shell commands, and the oshi collector that harvests all details about the system. ConfigAdmin Collector The ConfigAdmin collector is a event driven collector. It “listens” for any change on the Karaf configuration and send an event for each change. Prometheus Collector Karaf Decanter 2.3.0 introduced the Prometheus appender to expose metrics on a P

Up to Apache Karaf Decanter 2.3.0, the collection workflow was pretty simple: collect and append. In Karaf Decanter 2.4.0, we introduced a new optional layer in between: the processing. It means that the workflow can be now collect, process, and append. A processor get data from the collectors and do a logic processing before sending the event in the Decanter dispatcher in destination of the appenders. The purpose is to be able to apply any kind of processing before storing/sending the collected data. To use and enable this workflow, you just have to install a processor and change the appenders to listen data from the processor. Example of aggregate processor A first processor is available in Karaf Decanter 2.4.0: the timed aggregator. By default, each data collected by collectors is sent directly to the appenders. For instance, it means that the JMX collectors will send one event per MBean every minute by default. If the appender used is a REST appender, it means that we will call the

Recently, I had the question several times: how can I have metrics (number of requests, request time, …) of the SOAP and REST services deployed in Apache Karaf or Apache Unomi (also running on Karaf). SOAP and REST services are often implemented with Apache CXF (either directly using CXF or using Aries JAXRS whiteboard which uses CXF behind the hood). Apache Karaf provides examples how to deploy SOAP/REST services, using different approaches (depending the one you prefer): https://github.com/apache/karaf/tree/master/examples/karaf-soap-example https://github.com/apache/karaf/tree/master/examples/karaf-rest-example CXF Bus Metrics feature Apache CXF provides a metrics feature that collect the metrics we need. Behind the hood it uses dropwizard library and the metrics are exposed as JMX MBeans thanks to the JmxExporter . Let’s take a simple REST service. For this example, I’m using blueprint, but it also works with CXF programmatically or using SCR. I have a very simple JAXRS class looki