How to Monitor Fission Kubernetes-native Serverless Functions with Vigilmon

Fission is a Kubernetes-native serverless framework that runs functions directly on your existing cluster — no Lambda, no managed cloud required. Functions are language-agnostic, warm pools eliminate cold starts, and the router maps HTTP triggers to function executions in milliseconds. But this tight Kubernetes integration creates infrastructure dependencies that are easy to overlook: the router pod that processes every HTTP trigger, the executor that manages function pod lifecycles, the storage service for package management, and the controller that synchronizes desired state from the Fission CRDs.

This tutorial explains how to set up comprehensive external monitoring for Fission clusters with Vigilmon, so you catch router failures and function execution breakdowns before your users do.

Why Fission needs external monitoring

Fission's architecture separates concerns across multiple pods, and each component can fail independently:

• The router fails — every function invocation fails, but the Kubernetes pod may restart so quickly that cluster-internal health checks report green within seconds
• The executor can't schedule function pods — the router accepts requests, but function invocations timeout waiting for a pod that never becomes ready
• Function packages are corrupt or unreachable — the storage service is up, but a specific package fetch fails silently, causing functions to return 500s intermittently
• Controller can't reconcile CRDs — new function deployments fail while existing functions work normally, masking a control plane issue
• Warm pool exhaustion — if the pool executor runs out of warm pods, requests queue and eventually timeout; Kubernetes metrics don't capture the user-visible latency spike

External monitoring from Vigilmon checks whether function invocations succeed from outside the cluster — the same perspective your users have.

What you'll need

• A Fission installation on Kubernetes (deployed via Helm or the Fission CLI)
• The Fission router accessible on a reachable URL (via Ingress, LoadBalancer, or NodePort)
• One or more deployed functions to test
• A free Vigilmon account

Step 1: Identify your Fission router endpoint

The Fission router is the entry point for all function HTTP triggers. Find it:

# Check the router service
kubectl get svc -n fission router
# NAME     TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
# router   LoadBalancer   10.96.145.200   203.0.113.10    80:31234/TCP   14d

# Or check via ingress
kubectl get ingress -n fission

Test the router is responding:

curl -o /dev/null -s -w "%{http_code}" http://203.0.113.10/
# 404 (expected — no routes matched, but router is alive)

A 404 on the router root is normal and confirms the router is alive.

Step 2: Deploy a canary health-check function

Deploy a minimal function that returns a known response. This is the function you'll monitor continuously:

# health.py
def main():
    return "ok", 200, {"Content-Type": "text/plain"}

Create and deploy it:

# Create the environment (Python 3.9)
fission env create --name python --image fission/python-env:latest

# Create the function
fission fn create --name health-check \
  --env python \
  --code health.py

# Create an HTTP trigger
fission httptrigger create --url /health-check \
  --function health-check \
  --method GET \
  --name health-trigger

# Verify it works
curl http://203.0.113.10/health-check
# ok

Using a dedicated health-check function has two advantages over monitoring a production function:

1. It stays deployed even when you roll production functions
2. It never returns business-logic errors that could cause false alerts

Step 3: Monitor the health-check function with Vigilmon

1. Log in to vigilmon.online and go to Monitors → New Monitor
2. Choose HTTP / HTTPS
3. Set the URL to http://your-router-ip/health-check
4. Set the check interval to 1 minute
5. Under Expected response:
   • Status code: 200
   • Response body contains: ok
6. Save the monitor

This single monitor validates the entire Fission execution path: router routing, executor scheduling, function execution, and response delivery.

Monitor a production function endpoint

Add a second monitor for each critical production function:

1. URL: http://your-router-ip/your-production-function
2. Expected status code: 200 (or 201, 204 as appropriate)
3. Check interval: 2 minutes

If this monitor fails while the health-check monitor passes, the problem is specific to that function (bad package, broken dependencies) rather than the platform.

Step 4: Monitor the Fission router TCP port

Add a TCP monitor for the router port to catch port-level failures:

1. In Vigilmon, go to Monitors → New Monitor
2. Choose TCP Port
3. Enter your router host and port (80 for HTTP or 443 for HTTPS)
4. Save the monitor

TCP monitoring is a faster, lower-overhead check that runs alongside HTTP monitoring. A TCP failure that coincides with an HTTP failure confirms the router process itself is down, not just returning error responses.

Step 5: Create a canary function that validates executor health

For deeper coverage, deploy a function that explicitly checks whether the Fission executor can schedule new pods:

# executor-check.py
import requests
import os

def main():
    # This function's existence and invocation proves the executor is working
    # Add any internal checks relevant to your environment here
    fission_router = os.environ.get("FISSION_ROUTER", "http://router.fission")
    
    try:
        r = requests.get(f"{fission_router}/health-check", timeout=5)
        if r.status_code == 200:
            return f"executor:ok,router:ok", 200, {"Content-Type": "text/plain"}
        else:
            return f"router:degraded:{r.status_code}", 503, {"Content-Type": "text/plain"}
    except Exception as e:
        return f"router:unreachable:{str(e)}", 503, {"Content-Type": "text/plain"}

Deploy this as a separate function with an HTTP trigger at /executor-check. Monitor it with Vigilmon at 5 minute intervals.

Step 6: Monitor with the newdeploy executor strategy

Fission supports two executor types: poolmgr (warm pool) and newdeploy (Kubernetes Deployment per function). If you use newdeploy, the executor creates and manages Deployments:

# Create a function with newdeploy executor
fission fn create --name api-function \
  --env python \
  --code api.py \
  --executortype newdeploy \
  --minscale 1 \
  --maxscale 5

# Verify the deployment exists
kubectl get deploy -n fission-function

For newdeploy functions, add a separate Vigilmon monitor with a longer interval (5 minutes) since cold starts can take 10-30 seconds for the initial pod to become ready. Set the Response timeout in Vigilmon to 45 seconds to avoid false alerts on warm-up.

Step 7: Configure alert channels

Fission outages affect every API call routing through your functions, so fast alerting is critical.

Email alerts

1. In Vigilmon, go to Alert Channels → Add Channel → Email
2. Add your platform team email
3. Assign to all Fission monitors

Slack webhook

1. Go to Alert Channels → Add Channel → Webhook
2. Paste your Slack incoming webhook URL
3. Assign to your monitors

Vigilmon sends structured alert payloads:

{
  "monitor_name": "Fission Health Check Function",
  "status": "down",
  "url": "http://your-router-ip/health-check",
  "started_at": "2026-07-02T11:30:00Z",
  "duration_seconds": 121
}

Step 8: Diagnose Fission failures

When Vigilmon alerts fire, work through this checklist:

# 1. Check all Fission pods
kubectl get pods -n fission
# Look for pods in CrashLoopBackOff or Error state

# 2. Check router logs
kubectl logs -n fission deploy/router --tail=50

# 3. Check executor logs
kubectl logs -n fission deploy/executor --tail=50

# 4. Check controller logs
kubectl logs -n fission deploy/controller --tail=30

# 5. Check function pod status
kubectl get pods -n fission-function

# 6. Check storage service
kubectl logs -n fission deploy/storagesvc --tail=30

# 7. List function packages and check their status
fission pkg list
# Look for packages in "failed" state

# 8. Check httptriggers are still bound
fission httptrigger list

Common failure patterns

| Symptom | Likely cause | Fix | |---------|-------------|-----| | Router returns 404 for known function | HTTP trigger missing | Re-create httptrigger | | Router returns 500 | Executor can't schedule pod | Check executor and node capacity | | Router returns 503 | No warm pods available | Scale up pool, check poolmgr | | Function returns 500 | Package fetch failed | Rebuild and redeploy function package | | Cold start timeout | Image pull slow | Pre-pull images on nodes, use warm pool | | Router TCP port unreachable | Router pod crashed | Check OOM events, restart router |

Step 9: Create a status page

If external teams or services call your Fission-hosted APIs, expose cluster health via a Vigilmon status page:

1. In Vigilmon, go to Status Pages → New Status Page
2. Name it "API Platform Status"
3. Add monitors:
   • Fission Router (TCP)
   • Health Check Function (HTTP)
   • [Your production functions]
4. Publish and share the URL

Teams can check API availability without needing kubectl access or Fission credentials.

Recommended monitoring setup

| Monitor | Type | Interval | What it catches | |---------|------|----------|-----------------| | http://router/health-check | HTTP | 1 min | Full execution path broken | | http://router/production-api | HTTP | 2 min | Production function broken | | router-host:80 | TCP | 1 min | Router process down | | http://router/executor-check | HTTP | 5 min | Executor scheduling broken |

What's next

With Vigilmon monitoring your Fission cluster, you catch router failures and execution breakdowns the moment they happen. Next steps:

• Canary deployments: deploy updated functions alongside their monitors — if the Vigilmon check fails after deployment, roll back immediately
• Warm pool sizing: track cold-start warnings in router logs and correlate with Vigilmon response time data to right-size your pool
• Multi-environment coverage: run the same monitoring setup in staging and production; differences in alert patterns between environments often reveal configuration drift

External monitoring complements Kubernetes-internal health checks by validating what users actually experience — not what the cluster thinks is happening.

Start monitoring your Fission functions in under 2 minutes at vigilmon.online — free tier, no credit card required.