Dinesh Sai ← All projects

Case study · ObservabilityLive at microguard.dineshsai.com

MicroGuard: find the change that broke production.

A Kubernetes observability and incident platform. It watches the cluster for changes such as deploys, image swaps, scaling events and OOM kills, scores how likely each one caused an anomaly, and turns the result into an incident with a causal chain, suggested fixes and an AI explanation.

  • Solo build: product, backend, frontend, infra
  • Go · React · PostgreSQL
  • MIT licence
backend/rca/correlation_engine.go
// scoreCorrelation: how likely did this change
// cause this anomaly? (0–100)
if timeDelta < 2*time.Minute { score += 30 }
if change.Namespace == namespace { score += 20 }
switch change.EventType {
case "image_change", "deploy": score += 25
case "oom_kill", "config_change": score += 20
}
if isMetricRelatedToEvent(metric, ev) { score += 15 }
if nameMatches { score += 10 }
Condensed from the repository. Every point added also records a line of evidence.
26klines of Go
16klines of React
5signals in causal scoring
4ways to install

Counted from the repository in October 2026.

The problem

Dashboards show that something broke. Not why.

In most incidents the first question is "what changed?" Usually the answer is a deploy, a config edit or a scaling event from a few minutes earlier. Standard monitoring stacks show the symptom (CPU spikes, pods restart, latency climbs), but connecting it to the cause means an engineer has to scroll through events, deploy logs and Slack history by hand.

MicroGuard records every meaningful change in the cluster and, when an anomaly appears, ranks those changes as candidate root causes with the evidence for each, before a person starts digging.

Design goals

  • Root-cause suggestions you can explain, not a black-box score.
  • AI is optional: the causal engine works with no API key.
  • One binary and one database, installable in minutes.
  • Enterprise basics built in: RBAC, audit log, multi-tenancy.

What's in the box

  • Live cluster dashboard over WebSockets, plus custom dashboards.
  • Causal RCA, AI explanations and one-click kubectl remediation.
  • Incidents with MTTR, SLO and error-budget tracking.
  • Alert rules with multi-level escalation to Slack, PagerDuty, Teams, webhooks and email.
  • CIS, SOC 2, HIPAA and PCI-DSS benchmark scanning.

How it works

From cluster change to explained incident.

  1. Collect changes

    A change collector snapshots deployments, pods and events every 30 seconds and diffs each snapshot against the last. Differences become typed change events: deploy, image change, scale, restart, config change, OOM kill, node pressure. Each runs in a goroutine with panic recovery, so a bad snapshot can't take the backend down.

  2. Detect anomalies

    Metrics come from the Kubernetes API and metrics-server through client-go. A separate Python service runs an Isolation Forest model to flag anomalous values, and a background scanner checks for new anomalies on a schedule.

  3. Correlate

    For each anomaly, every change in the preceding window is scored from 0 to 100 on five signals: time proximity, namespace match, how often that change type causes failures, whether the metric relates to the event (memory ↔ OOM kill), and resource-name overlap. Each point comes with a line of evidence, so the ranking explains itself.

  4. Map the impact

    A dependency graph of services and resources shows how far the failure can spread, and the incident is created with its causal chain attached.

  5. Explain and fix

    If a Claude or OpenAI key is configured (customer-provided and stored encrypted), an LLM gets the change events, dependency graph, anomalies and logs, and writes a root-cause analysis. Remediation suggestions are generated as concrete kubectl commands and can be run from the UI, with each action recorded.

  6. Learn

    When an incident is resolved, a pattern-learning step stores its signature. Future incidents are matched against known patterns, so a repeat failure arrives with the previous fix attached.

Platform engineering

Built to be installed by someone else.

Delivery pipeline (GitHub Actions)

  • Backend: go vet, build, and go test -race with coverage.
  • Frontend: clean install and production build.
  • Trivy filesystem scan, then image build and push to Docker Hub.
  • Trivy scan of the built image.
  • Deploy to Amazon EKS and wait for the rollout to finish.
  • A separate security workflow runs gosec, Bandit and Trivy. They currently report findings rather than block a release.

Runtime and packaging

  • Install with Docker Compose, a one-line script, a Helm chart, or a plain kubectl manifest.
  • The Helm chart ships RBAC, a PodDisruptionBudget, ingress, a PVC and secrets.
  • /health, /healthz (deep check of DB, Kubernetes and cache latency) and /readyz for probes.
  • OpenTelemetry instrumentation and structured logging with slog.

Security

  • JWT auth with bcrypt-hashed passwords.
  • Role-based middleware: admin, editor and viewer.
  • Per-IP rate limiting, with a stricter limit on AI endpoints.
  • An immutable audit log of every create, update and delete.

Data

  • PostgreSQL with versioned SQL migrations.
  • Configurable retention for metrics, logs, traces and events, with automated cleanup.
  • CSV and JSON export for logs, metrics, costs, incidents and audit data.
  • Multi-tenancy with organisations, teams and resource quotas.

Engineering decisions

Trade-offs worth explaining.

Why a rule-based causal score before the LLM?

On-call engineers need to trust a suggestion before acting on it. A transparent score, such as "deployed 90 seconds before the spike, same namespace, image change", can be checked at a glance and works without an API key or network access. The LLM sits on top as an explainer, not as the source of truth.

Why Go for the backend?

client-go is the native Kubernetes client, goroutines suit the many background loops (change collector, anomaly scanner, alert evaluator), and a single static binary keeps the container small and the install simple.

Why bring-your-own AI keys?

Cluster data is sensitive. Customers choose their provider (Claude or OpenAI), keys are stored encrypted, and all AI features are optional, so a security-conscious team can run MicroGuard with no outbound LLM traffic at all.

Why four install paths?

Evaluators want docker compose up, platform teams want a Helm chart, and some clusters only allow reviewed manifests. Meeting each audience where they are removes the biggest barrier to trying an observability tool.

Stack

Built with

See it running

The product site has documentation, screenshots and install guides. The source is in a private repository, and I'm happy to walk through it.

Open microguard.dineshsai.com Ask for a walkthrough