How to Monitor Kompose-Deployed Services with Vigilmon

Kompose converts Docker Compose files into Kubernetes manifests, letting teams migrate workloads from docker-compose.yml to Kubernetes without rewriting everything from scratch. It's a fast path to Kubernetes — but once your converted workloads land on a cluster, you still need external monitoring to know when they're down.

In this tutorial you'll set up end-to-end monitoring for services deployed via Kompose using Vigilmon — free tier, no credit card.

Why Kompose deployments need dedicated monitoring

Kompose-deployed workloads run as Kubernetes Deployments, Services, and ConfigMaps. Kubernetes restarts failing pods and reschedules them — but that resilience can mask real problems:

• CrashLoopBackOff loops — Kubernetes restarts your pod endlessly; it shows as Running briefly but never serves traffic
• Service unreachability — a Service or Ingress misconfiguration means traffic never reaches pods even when pods are healthy
• Liveness/readiness probe failures — Kompose may not translate Compose healthchecks into Kubernetes probes, leaving pods that accept no traffic
• Resource exhaustion — OOMKilled pods that restart silently while memory limits are hit on every request

External HTTP and TCP monitoring fills the gap between Kubernetes self-healing and real user-facing availability.

What you'll need

• A Compose project already converted with Kompose (kompose convert) and deployed to Kubernetes
• A domain or external IP pointing at your Kubernetes Ingress or LoadBalancer
• A free Vigilmon account

Step 1: Add a health endpoint to your service

Before setting up monitoring, ensure your service exposes a /health endpoint that returns HTTP 200 when the pod is ready.

For a Node.js service:

app.get('/health', (req, res) => {
  res.json({ status: 'ok', service: 'my-app', timestamp: new Date().toISOString() });
});

For a Python/FastAPI service:

@app.get("/health")
async def health():
    return {"status": "ok"}

If Kompose didn't translate your Compose healthcheck into Kubernetes probes, add them manually to the generated Deployment:

livenessProbe:
  httpGet:
    path: /health
    port: 3000
  initialDelaySeconds: 15
  periodSeconds: 20
readinessProbe:
  httpGet:
    path: /health
    port: 3000
  initialDelaySeconds: 5
  periodSeconds: 10

Apply the updated manifest:

kubectl apply -f my-app-deployment.yaml

Step 2: Expose your service externally

Kompose typically converts ports entries to a Kubernetes Service of type ClusterIP. To make it reachable for monitoring, you need a LoadBalancer, NodePort, or Ingress.

Check what Kompose generated:

kubectl get services

If your service is ClusterIP-only, patch it to LoadBalancer:

kubectl patch service my-app -p '{"spec": {"type": "LoadBalancer"}}'

Or add an Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  rules:
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app
            port:
              number: 3000

Once external traffic reaches your service, Vigilmon can probe it.

Step 3: Set up HTTP monitoring in Vigilmon

1. Log in to vigilmon.online and go to Monitors → New Monitor
2. Choose HTTP / HTTPS as the type
3. Set the URL to your health endpoint, e.g. https://my-app.example.com/health
4. Set the check interval to 1 minute
5. Under Expected response, set:
   • Status code: 200
   • (Optional) Response body contains: "status":"ok"
6. Save the monitor

Vigilmon will probe your endpoint from multiple regions every minute. If your Ingress misconfigures routing, a pod enters CrashLoopBackOff, or a node goes down — an incident fires within one check interval.

Step 4: Set up TCP port monitoring for non-HTTP services

Kompose often converts stateful services like databases. Monitor their TCP ports directly:

1. In Vigilmon, go to Monitors → New Monitor
2. Choose TCP Port as the type
3. Enter your server hostname and port, e.g. my-app.example.com / 5432
4. Save the monitor

This catches cases where the database pod is scheduled but the Service selector doesn't match pod labels — a common Kompose translation edge case.

Step 5: Configure alerts

1. Go to Alert Channels → Add Channel
2. Choose Webhook (Slack, Discord, PagerDuty) or Email
3. Add your endpoint or address
4. Assign the channel to your monitors

For Kompose workflows, a Slack alert is especially useful because Kubernetes restarts are automatic — without an alert, you might never know a pod was cycling:

{
  "monitor_name": "my-app /health",
  "status": "down",
  "url": "https://my-app.example.com/health",
  "started_at": "2024-01-15T10:23:00Z",
  "duration_seconds": 120
}

Step 6: Create a status page

1. In Vigilmon, go to Status Pages → New Status Page
2. Add your HTTP and TCP monitors
3. Publish the page

Share the status page URL with your team so anyone can check cluster health without kubectl access.

Key metrics to watch

| Metric | What it catches | |--------|----------------| | HTTP response code | Pod crashes, readiness probe failures, Ingress misconfiguration | | HTTP response time | Resource exhaustion, slow Kubernetes scheduling, noisy-neighbor OOM | | TCP port reachability | Service selector mismatches, NodePort binding failures | | Response body | Application-level errors that still return 200 |

Summary

Kompose makes the Docker-to-Kubernetes migration fast, but it doesn't give you observability into the converted workloads. Vigilmon fills that gap with HTTP and TCP checks that verify your services are reachable from the outside, not just scheduled inside the cluster. Set up a monitor in five minutes and know within 60 seconds when a converted workload stops serving traffic.