tutorial

Monitoring Otomi with Vigilmon: Kubernetes PaaS Health, Developer Portal Availability, and Ingress Checks

How to monitor Otomi with Vigilmon — platform API health, developer portal availability, Keycloak SSO checks, Drone CI connectivity, and SSL certificate alerts.

Otomi is a self-hosted Kubernetes PaaS that bundles an integrated developer platform on top of any Kubernetes cluster — including Keycloak for SSO, Drone CI for pipelines, Harbor for container images, Gitea for source control, Prometheus and Grafana for metrics, and a developer self-service portal for teams to deploy workloads without Kubernetes expertise. Platform engineering teams rely on Otomi to abstract Kubernetes complexity and let developers focus on application delivery. When the Otomi console is unreachable, self-service deploys stop. When Keycloak is down, no one can authenticate. When Harbor is unavailable, image pulls fail across the cluster. Vigilmon gives you external visibility into every surface of the Otomi platform that your developers and automation pipelines depend on.

What You'll Build

  • An HTTP monitor on the Otomi console to detect platform UI failures
  • A Keycloak SSO availability check to catch authentication failures before users do
  • A Harbor container registry probe to detect image pull disruptions
  • TCP and SSL certificate monitors for Otomi ingress endpoints
  • An alerting matrix that separates each Otomi component's failure impact

Prerequisites

  • A running Otomi installation on a Kubernetes cluster (v1.0+)
  • HTTPS configured for the Otomi ingress (wildcard cert or per-service certs)
  • Your Otomi platform URL (e.g., https://otomi.example.com) and component URLs
  • A free account at vigilmon.online

Step 1: Understand Otomi's Component Architecture

Otomi deploys and manages a suite of platform components through its Helm-based GitOps engine. Each component has its own ingress route under the platform domain:

  • Otomi Console: https://otomi.example.com — the developer self-service portal
  • Keycloak: https://keycloak.example.com — SSO and OIDC provider for all Otomi components
  • Harbor: https://harbor.example.com — container image registry
  • Gitea: https://gitea.example.com — source control
  • Drone CI: https://drone.example.com — CI/CD pipelines
  • Grafana: https://grafana.example.com — observability dashboards

Each component is served through the cluster's ingress controller (typically NGINX or Traefik managed by Otomi). A single Vigilmon monitor per component gives you targeted failure isolation rather than a single "platform is down" alert.

Step 2: Monitor the Otomi Console

The Otomi console is the primary interface developers use to create namespaces, deploy workloads, configure network policies, and manage secrets. If the console is unavailable, self-service operations stop for your entire developer organization:

curl https://otomi.example.com
# Returns HTML with "Otomi" in the page title
  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://otomi.example.com.
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: Otomi (present in the console HTML).
  7. Label: Otomi Console.
  8. Click Save.

This monitor catches:

  • Otomi console pod crashes or OOM kills
  • Ingress controller failures blocking platform access
  • Kubernetes node scheduling failures that prevent the console pod from running
  • Otomi platform upgrades that leave the console in a broken state

Alert sensitivity: Trigger after 1 consecutive failure. Every developer who needs to modify their workload configuration is blocked when the console is down.

Step 3: Monitor Keycloak SSO

Keycloak is the authentication backbone of Otomi. All Otomi component logins — console, Grafana, Harbor, Gitea, Drone CI — route through Keycloak OIDC. A Keycloak failure locks every user out of every platform component simultaneously:

curl https://keycloak.example.com/realms/master/.well-known/openid-configuration
# Returns JSON with "issuer", "authorization_endpoint", etc.
  1. Add Monitor → HTTP.
  2. URL: https://keycloak.example.com/realms/master/.well-known/openid-configuration.
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: issuer (present in all OIDC configuration responses).
  7. Label: Keycloak OIDC endpoint.
  8. Click Save.

When the Keycloak monitor fires while individual component monitors are green, it means the components are technically up but no one can log in. This is often the highest-priority alert: a Keycloak failure affects 100% of your Otomi users simultaneously, while a single component failure affects only users of that component.

Step 4: Monitor Harbor Container Registry

Harbor is the container image registry for workloads running on your Otomi cluster. When Harbor is unavailable, Kubernetes image pull operations fail — new pod starts, deployments, and scaling events all stall with ImagePullBackOff. Harbor exposes a health endpoint:

curl https://harbor.example.com/api/v2.0/health
# Returns: {"status":"healthy","components":[...]}
  1. Add Monitor → HTTP.
  2. URL: https://harbor.example.com/api/v2.0/health.
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: healthy.
  7. Label: Harbor registry health.
  8. Click Save.

A Harbor health failure is a silent cluster killer — existing running pods are unaffected, but any new pod start (auto-scaling, node failure recovery, deployments) will fail with ImagePullBackOff. The faster you catch this, the less likely it is that a cluster node failure turns into cascading unavailability.

Step 5: Monitor Drone CI

Drone CI runs your Otomi-integrated CI/CD pipelines. When Drone is down, no pipeline runs trigger — pushes to Gitea that would normally kick off builds are silently lost:

curl https://drone.example.com/healthz
# Returns: OK
  1. Add Monitor → HTTP.
  2. URL: https://drone.example.com/healthz.
  3. Check interval: 2 minutes.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: OK.
  7. Label: Drone CI health.
  8. Click Save.

Step 6: Monitor Gitea

Gitea is the source control system bundled with Otomi. If Gitea is unavailable, developers can't push code or trigger pipeline runs, and Otomi's own GitOps engine (which stores configuration in a Gitea repository) can't reconcile platform state:

curl https://gitea.example.com/api/v1/version
# Returns: {"version":"1.x.y"}
  1. Add Monitor → HTTP.
  2. URL: https://gitea.example.com/api/v1/version.
  3. Check interval: 2 minutes.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: version.
  7. Label: Gitea API.
  8. Click Save.

Otomi stores its own platform configuration in a Gitea repository and reconciles changes through a GitOps loop. A Gitea failure doesn't just block developers from pushing code — it also blocks Otomi platform configuration changes from being applied. This makes Gitea a critical infrastructure dependency for the Otomi control plane itself.

Step 7: Monitor SSL Certificates

Otomi manages TLS certificates for all its component ingress routes, typically via cert-manager with Let's Encrypt or a custom CA. A certificate renewal failure affects all Otomi components simultaneously since they share the wildcard cert:

openssl s_client -connect otomi.example.com:443 2>/dev/null | openssl x509 -noout -dates
  1. Add Monitor → SSL Certificate.
  2. Domain: otomi.example.com.
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

Add a separate SSL monitor for harbor.example.com and keycloak.example.com if they use separate certificates.

Otomi's cert-manager configuration is managed as part of the platform GitOps repository in Gitea. If the cert-manager Helm values change during an Otomi upgrade, the ClusterIssuer configuration can become invalid and certificate renewals silently fail. A 30-day Vigilmon alert catches this before expiry.

Step 8: Configure Alerting

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Blast radius | Action | |---|---|---|---| | Otomi Console | Non-200 or keyword missing | Developer self-service blocked | Check console pod: kubectl get pods -n otomi | | Keycloak OIDC | Non-200 or issuer missing | ALL users locked out of ALL components | Check Keycloak pod; restore from backup if DB corrupted | | Harbor health | Non-200 or healthy missing | New pod starts failing with ImagePullBackOff | Check Harbor pods; inspect database and Redis status | | Drone CI health | Non-200 or keyword missing | CI/CD pipelines stop triggering | Check Drone pod; Gitea webhooks still queue | | Gitea API | Non-200 or keyword missing | Code pushes and Otomi GitOps reconciliation blocked | Check Gitea pod and PostgreSQL backend | | SSL certificate | < 30 days to expiry | Platform-wide TLS failure if unaddressed | Check cert-manager; verify ClusterIssuer and DNS validation |

Alert after: 1 consecutive failure for Keycloak (total auth lockout) and Harbor (cluster-wide image pull impact). 2 consecutive failures for Console, Drone, and Gitea.

Common Otomi Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Keycloak pod OOM killed | Keycloak OIDC monitor fires; all user logins fail | | Harbor PostgreSQL database failure | Harbor health API returns unhealthy; image pulls fail | | Ingress controller crash | All monitors fire simultaneously | | cert-manager fails to renew wildcard cert | SSL monitor alerts at 30-day threshold | | Otomi platform upgrade corrupts Gitea config | Gitea API monitor fires; GitOps reconciliation stops | | Drone runner pods evicted by node pressure | Drone health green; pipelines fail silently — check runner logs | | Node failure causes pod rescheduling storm | Multiple monitors may fire temporarily during rescheduling | | Otomi version upgrade breaks console UI | Console keyword monitor catches broken HTML or missing content | | Harbor chart repository disk full | Harbor returns degraded health status; push operations fail |

Otomi is the platform layer that lets your developers deploy cloud-native workloads without becoming Kubernetes experts. But Otomi itself is a complex system with multiple interdependent components — Keycloak, Harbor, Gitea, Drone CI, and the console UI — any of which can fail independently. Vigilmon gives you external, continuous visibility into every Otomi component your developers and automation pipelines depend on, so you catch failures the moment they occur and restore platform availability before productivity grinds to a halt.

Start monitoring Otomi in under 5 minutes — register free at vigilmon.online.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles