Skip to content

Monitoring

Purpose

What's actually wired up for observability, and what's a documented but currently disabled capability - so you don't assume alerting exists where it doesn't.

Status: disabled by default

# helm/akshayabazaar/values.yaml
monitoring:
  enabled: false
Every environment's values-*.yaml inherits this unless explicitly overridden. No ServiceMonitor/PrometheusRule is deployed, and no Prometheus scrapes anything from this chart, until monitoring.enabled: true is set and a Prometheus Operator (kube-prometheus-stack or equivalent) is actually installed on the target cluster - this chart never installs Prometheus itself.

What exists, when enabled

Resource File Purpose
ServiceMonitor templates/monitoring/servicemonitor.yaml Tells the Prometheus Operator to scrape the backend Service's /metrics on its existing http port
PrometheusRule templates/monitoring/prometheusrule.yaml Three alert groups: akshayabazaar.application (this app's own metrics), akshayabazaar.kubernetes (kube-state-metrics/node-exporter), akshayabazaar.backup (backup CronJob metrics, needs backup.enabled: true too)

No frontend ServiceMonitor - nginx exposes no metrics endpoint of its own; ingress-level request metrics come from Traefik's own Prometheus integration (a K3s cluster-level setting, not something this chart controls).

Single-VM topology: why every rule has an explicit namespace matcher

Staging and production share one Kubernetes cluster (see Architecture → Infrastructure), and the Prometheus Operator merges every namespace's PrometheusRule objects into one cluster-wide Prometheus config. A job="..." matcher alone isn't enough to isolate one environment's alerts from the other's, since both environments' releases produce the same job label value - every rule expression also matches namespace="<release-namespace>".

Alerts (application group)

  • AkshayaBazaarAPIUnavailable - the ServiceMonitor scrape target reports down (up == 0) for 2 minutes+ - not a single failed request, the target itself unreachable long enough that it isn't just a normal rolling deploy (maxUnavailable: 0 means a healthy old pod is always up during a deploy).
  • AkshayaBazaarHighErrorRate - elevated 5xx rate from the backend's own HTTP metrics.

Commands (read-only)

# Confirm whether monitoring is actually enabled for a given release
helm get values akshaya-local -n staging | Select-String "monitoring"

# If a Prometheus Operator is installed, confirm the ServiceMonitor/PrometheusRule exist
kubectl get servicemonitor -n staging
kubectl get prometheusrule -n staging

Without Prometheus: the always-available fallback

Every environment, regardless of monitoring.enabled, still exposes the same health endpoints /health/live and /health/ready - see Operations → Verification and Architecture → Application. verify-staging.ps1 is the practical substitute for a dashboard when Prometheus isn't deployed.