Camel K Monitoring

The Camel K monitoring architecture relies on Prometheus and the eponymous operator.

The Prometheus Operator serves to make running Prometheus on top of Kubernetes as easy as possible, while preserving Kubernetes-native configuration options.


To take fully advantage of the Camel K monitoring capabilities, it is recommended to have a Prometheus Operator instance, that can be configured to integrate Camel K integrations.


You can deploy the Prometheus operator by running:

$ kubectl apply -f
Beware this installs the operator in the default namespace. You must download the file locally and replace the namespace fields to deploy the resources into another namespace.

Then, you can create a Prometheus resource, that the operator will use as configuration to deploy a managed Prometheus instance:

$ cat <<EOF | kubectl apply -f -
kind: Prometheus
  name: prometheus
      - key:
        operator: Exists

By default, the Prometheus instance discovers applications to be monitored in the same namespace. You can use the serviceMonitorNamespaceSelector field from the Prometheus resource to enable cross-namespace monitoring. You may also need to specify a ServiceAccount with the serviceAccountName field, that’s bound to a Role with the necessary permissions.


Starting OpenShift 4.3, the Prometheus Operator, that’s already deployed as part of the monitoring stack, can be used to monitor application services. This needs to be enabled by following these instructions:

  1. Check whether the cluster-monitoring-config ConfigMap object exists in the openshift-monitoring project:

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  2. If it does not exist, create it:

    $ oc -n openshift-monitoring create configmap cluster-monitoring-config
  3. Start editing the cluster-monitoring-config ConfigMap:

    $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
  4. Set the techPreviewUserWorkload setting to true under data/config.yaml:

    apiVersion: v1
    kind: ConfigMap
      name: cluster-monitoring-config
      namespace: openshift-monitoring
      config.yaml: |
          enabled: true

On OpenShift versions prior to 4.3, or if you do not want to change your cluster monitoring stack configuration, you can refer to the Kubernetes section in order to deploy a separate Prometheus Operator instance.


The Prometheus trait automates the configuration of integration pods to expose a metrics endpoint, that can be discovered and scrapped by a Prometheus server.

The Prometheus trait can be enabled when running an integration, e.g.:

$ kamel run -t prometheus.enabled=true ...

Alternatively, the Prometheus trait can be enabled globally once, by updating the integration platform, e.g.:

$ kubectl patch ip camel-k --type=merge -p '{"spec":{"traits":{"prometheus":{"configuration":{"enabled":"true"}}}}}'

The underlying instrumentation mechanism depends on the configured integration runtime. As a result, the set of registered metrics, as well as the naming convention they follow, also depends on it.


When the default, a.k.a. main, runtime is configured for the integration, the JMX exporter is responsible for collecting and exposing metrics from JMX mBeans.

A custom configuration for the JMX exporter can be used by setting the prometheus.configmap parameter from the Prometheus trait with the name of a ConfigMap containing a prometheus-jmx-exporter.yaml key, e.g.:

$ kamel run -t prometheus.enabled=true -t prometheus.configmap=<jmx_exporter_config>...

Otherwise, the Prometheus trait uses a default configuration.


When the Quarkus runtime is configured for the integration, the Camel Quarkus MicroProfile Metrics extension is responsible for collecting and exposing metrics in the OpenMetrics text format.

The MicroProfile Metrics extension registers and exposes the following metrics out-of-the-box:

It is possible to extend this set of metrics by using either, or both:


The Prometheus trait automatically configures the resources necessary for the Prometheus Operator to reconcile, so that the managed Prometheus instance can scrape the integration metrics endpoint.

By default, the Prometheus trait creates a ServiceMonitor resource, with the label, which must match the serviceMonitorSelector field from the Prometheus resource. Additional labels can be specified with the service-monitor-labels parameter from the Prometheus trait, e.g.:

$ kamel run -t prometheus.service-monitor-labels="label_to_be_match_by=prometheus_selector" ...

The creation of the ServiceMonitor resource can be disabled using the service-monitor parameter, e.g.:

$ kamel run -t prometheus.service-monitor=false ...

More information can be found in the Prometheus trait documentation.

The Prometheus Operator getting started guide documents the discovery mechanism, as well as the relationship between the operator resources.

In case your integration metrics are not discovered, you may want to rely on Troubleshooting ServiceMonitor changes.


The Prometheus Operator declares the AlertManager resource that can be used to configure Alertmanager instances, along with Prometheus instances.

Assuming an AlertManager resource already exists in your cluster, you can register a PrometheusRule resource that is used by Prometheus to trigger alerts, e.g.:

$ cat <<EOF | kubectl apply -f -
kind: PrometheusRule
    prometheus: example
    role: alert-rules
  name: prometheus-rules
  - name: camel-k.rules
    - alert: CamelKAlert
      expr: application_camel_context_exchanges_failed_total > 0

More information can be found in the Prometheus Operator Alerting user guide. You can also find more details in Creating alerting rules from the OpenShift documentation.


Integration metrics can be exported for horizontal pod autoscaling (HPA), using the custom metrics Prometheus adapter. If you have an OpenShift cluster, you can follow Exposing custom application metrics for autoscaling to set it up.

Assuming you have the Prometheus adapter up and running, you can create a HorizontalPodAutoscaler resource, e.g.:

$ cat <<EOF | kubectl apply -f -
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
  name: camel-k-autoscaler
    kind: Integration
    name: example
  minReplicas: 1
  maxReplicas: 10
  - type: Pods
        name: application_camel_context_exchanges_inflight_count
        type: AverageValue
        averageValue: 1k

More information can be found in Horizontal Pod Autoscaler from the Kubernetes documentation.