Monitoring Apache Camel K Integrations with Vigilmon

Apache Camel K is a lightweight cloud-native integration platform that runs Apache Camel routes as Kubernetes-native serverless functions. A Camel K operator watches for Integration custom resources, compiles them into container images, and keeps them running on your cluster. When the operator crashes, every integration stops deploying. When a route silently stalls, messages pile up with no visible error. Vigilmon gives you the runtime visibility to catch these failures before they become incidents.

What You'll Set Up

• Camel K operator liveness and readiness monitoring
• Integration pod health and restart-rate alerts
• Camel route exchange throughput and failure-rate checks
• Dead letter channel accumulation alerts
• Camel K image registry and build cache health

Prerequisites

• Apache Camel K installed on a Kubernetes cluster (Camel K 2.x recommended)
• At least one Integration CR deployed and running
• A free Vigilmon account

Why Monitor Apache Camel K?

Camel K's operator-based model introduces a layer of indirection between your integration logic and the running pods. Problems manifest in several non-obvious ways:

• Operator crashes block all new Integration deployments silently — existing pods keep running but nothing new can be deployed or restarted after a failure.
• Route starvation occurs when a Kafka topic or HTTP source goes offline. The integration pod stays up but processes zero messages, which looks healthy to a basic pod check.
• Build failures happen when the Maven/Quarkus build cache is cold or the container registry is unavailable, causing the integration pod to never start.
• Dead letter channel accumulation means messages are silently lost rather than processed — a route is "running" but producing no useful output.

Vigilmon monitors the HTTP endpoints and heartbeats that surface these conditions without requiring a full observability stack.

Key Metrics to Monitor

| Metric | What It Reveals | |---|---| | Operator liveness/readiness | Operator crash blocking all integration lifecycle | | Integration pod count | Pods missing from expected replica count | | Pod restart count | Repeated crashes indicating route failure | | Integration startup duration | Build cache miss or registry issue | | Exchange throughput (exchanges/sec) | Route processing stalled | | Failed exchange rate | Route logic error or upstream connectivity loss | | Kamelet source connectivity | Source starvation causing zero throughput | | Dead letter channel size | Silent message loss | | Image registry push success | Registry unavailability blocking deployments | | Maven/Quarkus build cache hit rate | Extended build times on cache cold start |

Step 1: Monitor the Camel K Operator

The Camel K operator runs as a Deployment in the camel-k namespace (or whichever namespace you installed it into). It exposes health probes that Kubernetes uses internally — expose these via a Service so Vigilmon can reach them.

Expose the Operator Health Port

The Camel K operator health endpoint listens on port 8081 by default. Create a NodePort or LoadBalancer Service if you haven't already:

apiVersion: v1
kind: Service
metadata:
  name: camel-k-operator-health
  namespace: camel-k
spec:
  selector:
    app: camel-k
    name: camel-k-operator
  ports:
    - name: health
      port: 8081
      targetPort: 8081
  type: ClusterIP

Then port-forward or expose via Ingress for external access:

kubectl port-forward -n camel-k svc/camel-k-operator-health 8081:8081

Add the Operator Liveness Monitor in Vigilmon

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter the operator health URL: http://<your-cluster-ingress>/camel-k-operator/healthz (or the port-forwarded URL during setup).
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Click Save.

Add a second monitor for the readiness probe at /readyz using the same steps.

Step 2: Monitor Integration Pod Health via a Synthetic Health Endpoint

Camel K integrations expose JVM metrics via the Prometheus endpoint on port 8080. Add a lightweight health route to your integration that Vigilmon can poll:

# integration-with-health.yaml
apiVersion: camel.apache.org/v1
kind: Integration
metadata:
  name: my-integration
spec:
  flows:
    - from:
        uri: "timer:health?period=60000"
        steps:
          - to: "log:health"

    - from:
        uri: "platform-http:/health"
        steps:
          - setBody:
              constant: '{"status":"ok"}'
          - setHeader:
              name: Content-Type
              constant: application/json

Apply the integration:

kamel run integration-with-health.yaml

Once the integration pod is running, add a Vigilmon HTTP monitor targeting the pod's /health route through your Ingress or Service.

Step 3: Track Route Exchange Throughput with a Heartbeat

For integrations that process messages continuously (Kafka consumers, timer routes, HTTP pollers), configure a heartbeat that fires after each successful processing batch:

# kafka-consumer-with-heartbeat.yaml
apiVersion: camel.apache.org/v1
kind: Integration
metadata:
  name: kafka-processor
spec:
  flows:
    - from:
        uri: "kafka:my-topic?brokers=kafka:9092&groupId=camel-k-group"
        steps:
          - to: "log:kafka-received"
          - to: "http://vigilmon-heartbeat-url/ping"

Replace http://vigilmon-heartbeat-url/ping with the heartbeat URL from your Vigilmon monitor:

1. In Vigilmon, click Add Monitor.
2. Set Type to Heartbeat / Cron.
3. Set Expected interval to match your Kafka consumer's expected processing cadence (e.g., 5 minutes if messages arrive at least every 5 minutes).
4. Copy the ping URL and paste it into your integration route.
5. Click Save.

Vigilmon alerts you if the heartbeat ping stops arriving — meaning the Kafka consumer stalled or the integration pod crashed.

Step 4: Monitor Integration Startup Time

Camel K builds a container image the first time an Integration is applied (or when dependencies change). This build can take several minutes. Add a check that verifies the integration reaches Ready state within a timeout.

Create a simple shell probe you can run from a monitoring host or a Kubernetes CronJob:

#!/bin/bash
INTEGRATION_NAME="my-integration"
NAMESPACE="default"
TIMEOUT=300  # 5 minutes

START=$(date +%s)
while true; do
  PHASE=$(kubectl get integration "$INTEGRATION_NAME" -n "$NAMESPACE" \
    -o jsonpath='{.status.phase}' 2>/dev/null)
  if [ "$PHASE" = "Running" ]; then
    ELAPSED=$(($(date +%s) - START))
    echo "Integration ready in ${ELAPSED}s"
    # ping Vigilmon heartbeat on success
    curl -s "$VIGILMON_HEARTBEAT_URL"
    exit 0
  fi
  if [ $(($(date +%s) - START)) -gt "$TIMEOUT" ]; then
    echo "Integration startup timed out"
    exit 1
  fi
  sleep 10
done

Run this script in a Kubernetes CronJob triggered on Integration CR changes (via a Kubernetes watch or Argo Events trigger).

Step 5: Monitor the Dead Letter Channel

Add DLC route logging to your integration and expose the DLC queue size as a metric endpoint:

apiVersion: camel.apache.org/v1
kind: Integration
metadata:
  name: integration-with-dlc
spec:
  flows:
    - from:
        uri: "kafka:input-topic?brokers=kafka:9092"
        steps:
          - errorHandler:
              deadLetterChannel:
                deadLetterUri: "kafka:dead-letter-topic?brokers=kafka:9092"
                redeliveryPolicy:
                  maximumRedeliveries: 3
                  redeliveryDelay: 1000
          - to: "bean:messageProcessor"

Monitor the dead letter Kafka topic's consumer lag with a separate Vigilmon heartbeat on a consumer that reads from the DLC topic. If the DLC topic starts accumulating messages faster than expected, your primary route is experiencing elevated failures.

Step 6: Monitor Image Registry Health

Camel K pushes built integration images to your container registry. A registry outage blocks all new integration deployments. Monitor the registry's push endpoint:

1. In Vigilmon, click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter your registry's health check URL (e.g., https://registry.example.com/v2/ for a Docker Registry v2 instance).
4. Set Check interval to 5 minutes.
5. Set Expected HTTP status to 200 (Docker Registry v2 returns 200 on /v2/ when authenticated).
6. Click Save.

For public registries like Docker Hub or Quay.io, skip this step — their status pages are publicly monitored.

Step 7: Configure Alert Notifications

In Vigilmon, configure your notification channels:

1. Go to Settings → Notifications.
2. Add a Slack webhook, email, or PagerDuty integration.
3. For each monitor, set alert thresholds:

| Monitor | Alert Condition | |---|---| | Operator liveness | Any non-200 response | | Operator readiness | Any non-200 response | | Integration pod health | Any non-200 response for >2 minutes | | Route throughput heartbeat | Heartbeat missed for >2× expected interval | | DLC consumer heartbeat | Heartbeat missed (DLC growing) | | Image registry | Non-200 for >5 minutes |

Step 8: Test Your Monitoring Setup

Simulate failures to verify alerts fire correctly:

Test Operator Health Alert

# Scale the operator to zero replicas
kubectl scale deployment camel-k-operator -n camel-k --replicas=0

# Verify Vigilmon fires an alert within 2 minutes
# Restore the operator
kubectl scale deployment camel-k-operator -n camel-k --replicas=1

Test Integration Heartbeat Alert

# Pause the Kafka consumer integration
kamel pause kafka-processor

# Verify Vigilmon fires a missed heartbeat alert
# Resume
kamel resume kafka-processor

Test Registry Health Alert

# If using a local registry, stop it temporarily
docker stop registry

# Verify the Vigilmon monitor fires
# Restore
docker start registry

Conclusion

Apache Camel K's operator-managed lifecycle means failures at the operator, build, and route level all look different — and most are invisible without active monitoring. With Vigilmon you get:

• Operator crash detection before integrations start failing silently
• Route stall detection via missed heartbeats on consuming routes
• Build failure detection via startup time monitors
• DLC accumulation alerts catching silent message loss
• Registry outage alerts blocking new integration deployments

Start with the operator health monitor and one heartbeat on your most critical consuming integration. Add coverage as you identify which integrations are customer-facing or handle business-critical data flows.

Sign up for Vigilmon — the first monitor is free.