Chapter 6. Observability

Camel provides some out of the box liveness and readiness checks. To see this working, interrogate the /q/health/live and /q/health/ready endpoints on port 9000:

curl -s localhost:9000/q/health/live

$ curl -s localhost:9000/q/health/live

curl -s localhost:9000/q/health/ready

$ curl -s localhost:9000/q/health/ready

The JSON output will contain a checks for verifying whether the CamelContext and each individual route is in the 'Started' state.

This example project contains a custom liveness check class CustomLivenessCheck and custom readiness check class CustomReadinessCheck which leverage the Camel health API. You’ll see these listed in the health JSON as 'custom-liveness-check' and 'custom-readiness-check'. On every 5th invocation of these checks, the health status of custom-liveness-check will be reported as DOWN.

You can also directly leverage MicroProfile Health APIs to create checks. Class CamelUptimeHealthCheck demonstrates how to register a readiness check.

To enable observability features in Camel Quarkus, you must add additional dependencies to the project’s pom.xml file. The most important ones are camel-quarkus-opentelemetry and quarkus-micrometer-registry-prometheus.

You can create meters for custom metrics in multiple ways:

.to("micrometer:counter:org.acme.observability.greeting-provider?tags=type=events,purpose=example")

.to("micrometer:counter:org.acme.observability.greeting-provider?tags=type=events,purpose=example")

@Inject
MeterRegistry registry;

@Inject
MeterRegistry registry;

void countGreeting(Exchange exchange) {
    registry.counter("org.acme.observability.greeting", "type", "events", "purpose", "example").increment();
}

void countGreeting(Exchange exchange) {
    registry.counter("org.acme.observability.greeting", "type", "events", "purpose", "example").increment();
}

from("platform-http:/greeting")
    .removeHeaders("*")
    .process(this::countGreeting)

from("platform-http:/greeting")
    .removeHeaders("*")
    .process(this::countGreeting)

@ApplicationScoped
@Named("timerCounter")
public class TimerCounter {

    @Counted(value = "org.acme.observability.timer-counter", extraTags = { "purpose", "example" })
    public void count() {
    }
}

@ApplicationScoped
@Named("timerCounter")
public class TimerCounter {

    @Counted(value = "org.acme.observability.timer-counter", extraTags = { "purpose", "example" })
    public void count() {
    }
}

.bean("timerCounter", "count")

.bean("timerCounter", "count")

curl -s localhost:9000/q/metrics

$ curl -s localhost:9000/q/metrics

curl -s localhost:9000/q/metrics | grep -i 'purpose="example"'

$ curl -s localhost:9000/q/metrics | grep -i 'purpose="example"'

To be able to diagnose problems in Camel Quarkus applications, you can start tracing messages. We will use OpenTelemetry standard suited for cloud environments.

All you need is to add the dependencies camel-quarkus-opentelemetry and quarkus-micrometer-registry-prometheus to your project pom.xml:

<dependencies>

    ...

    <dependency>
        <groupId>org.apache.camel.quarkus</groupId>
        <artifactId>camel-quarkus-opentelemetry</artifactId>
    </dependency>
    <dependency>
        <groupId>io.quarkiverse.micrometer.registry</groupId>
        <artifactId>quarkus-micrometer-registry-prometheus</artifactId>
    </dependency>

    ...

</dependencies>

<dependencies>

    ...

    <dependency>
        <groupId>org.apache.camel.quarkus</groupId>
        <artifactId>camel-quarkus-opentelemetry</artifactId>
    </dependency>
    <dependency>
        <groupId>io.quarkiverse.micrometer.registry</groupId>
        <artifactId>quarkus-micrometer-registry-prometheus</artifactId>
    </dependency>

    ...

</dependencies>

Then configure the OpenTelemetry exporter in application.properties:

# We are using a property placeholder to be able to test this example in convenient way in a cloud environment
quarkus.otel.exporter.otlp.traces.endpoint = http://${TELEMETRY_COLLECTOR_COLLECTOR_SERVICE_HOST:localhost}:4317

# We are using a property placeholder to be able to test this example in convenient way in a cloud environment
quarkus.otel.exporter.otlp.traces.endpoint = http://${TELEMETRY_COLLECTOR_COLLECTOR_SERVICE_HOST:localhost}:4317

To view tracing events, start a tracing server. A simple way of doing this is with Docker Compose:

docker-compose up -d

$ docker-compose up -d

With the server running, browse to http://localhost:16686. Then choose 'camel-quarkus-observability' from the 'Service' drop down and click the 'Find Traces' button.

The platform-http consumer route introduces a random delay to simulate latency, hence the overall time of each trace should be different. When viewing a trace, you should see a hierarchy of 6 spans showing the progression of the message exchange through each endpoint.

Once you are done with developing you can package and run the application.

mvn clean package
java -jar target/quarkus-app/quarkus-run.jar
...
[io.quarkus] (main) camel-quarkus-examples-... started in 1.163s. Listening on: http://0.0.0.0:8080

$ mvn clean package
$ java -jar target/quarkus-app/quarkus-run.jar
...
[io.quarkus] (main) camel-quarkus-examples-... started in 1.163s. Listening on: http://0.0.0.0:8080

mvn clean package -Pnative
./target/*-runner
...
[io.quarkus] (main) camel-quarkus-examples-... started in 0.013s. Listening on: http://0.0.0.0:8080
...

$ mvn clean package -Pnative
$ ./target/*-runner
...
[io.quarkus] (main) camel-quarkus-examples-... started in 0.013s. Listening on: http://0.0.0.0:8080
...