Blog
Writing from the trenches
Practitioner-level posts on observability, SRE, platform engineering, and the occasional deep-dive into distributed systems. No fluff.
The Productivity Trap Nobody Talks About: When "Productive" Work Becomes Procrastination
Reinstalling Linux, rebuilding dotfiles, reorganizing repos — it all feels like progress, until you notice the thing you actually needed to learn never got touched. A framework for telling optimization work apart from avoidance.
Prioritization Frameworks for Engineering: Make Decisions That Actually Move the Needle
In on-call engineering cultures, urgency and importance feel identical—until you're weeks into work no one needed. This post combines the Complexity/Effort Matrix with the Eisenhower Decision Matrix into a five-tier execution system, with a ready-made 4×4 template for your Monday backlog triage.
Build Day: Agent Harness & Memory — Key Learnings on Agent Harnesses, Context Engineering, and Memory Systems
Reflections from Build Club & Mem0, Pune (June 2026)
Agent Memory as Infrastructure: The Context Injection Pattern That Replaces Fine-Tuning
Built four production AI specialists off a single LLM using plain markdown files and a 20-line fetch call — no fine-tuning, no frameworks. The real insight is that LLM behavioral specialization is a configuration problem, not a training problem, and applying IaC discipline to memory files gives you diffability, rollback, and CI-gated behavioral regression testing that fine-tuning can never provide. At MAANG scale, this extends to prompt caching economics, governance workflows, distributed session state, and multi-model routing.
Building an SRE Agent: From Playbook to Autonomous Incident Response
What happens when you put an LLM in the incident response loop? We built an SRE Agent on AKS that runs playbooks, queries Grafana, and generates post-mortems. Here's what worked, what didn't, and what we learned about trusting AI in production.
How a 'Consistency Fix' in Program.cs Silently Broke Label Promotion Across Mimir and Loki
Renaming an OTel resource attribute from deployment.environment to deployment_environment in application code looked like the fix for inconsistent labels across Grafana Cloud's three signals. It's backwards: Mimir and Loki both promote and convert dotted attribute names on ingestion, so a pre-converted attribute silently fails to match and drops out of both label sets. The real fix belongs in the Alloy pipeline, scoped to traces only.
Unbounded Cardinality, Zero Alerts, and 14-Second Dashboard Loads: The Structural Limits of the Grafana Azure Monitor Plugin
The Grafana Azure Monitor datasource plugin connects directly to Azure Monitor at query time. On a 12-panel dashboard, that means 12 sequential ARM API calls on every open — 14 seconds before the first chart renders. It cannot feed Mimir alerting rules. It cannot attach environment labels without custom queries per panel. And promoting Azure tags as Prometheus labels explodes cardinality to thousands of series per resource group. This post documents the five structural gaps and the specific design decisions in a push-based exporter that close each one.
How Alloy's Default max_shards Turned a Mimir Blip Into a Production Monitoring Blackout
When Grafana Mimir slowed down, Alloy's default retry configuration — 200 parallel shard workers — consumed the majority of CPU on a shared VM, starving the co-located business process and forcing an engineer to kill the observability agent during an active incident. Here's the exact three-layer fix and why shared-VM deployments require explicit resource budgets at every level.
In FinTech, Your Trace Attributes Are a Compliance Liability
The observability data that makes a payments system debuggable — full request bodies in logs, account numbers on spans, card data in error messages — is the same data that turns your telemetry backend into an unregulated copy of your system of record. Trust in fintech isn't a status page; it's provable reliability plus a guarantee that sensitive data never left the boundary it was supposed to stay inside.
You Don't Get Root on SAP RISE: Observability Inside a Managed Black Box
RISE with SAP hands you a mission-critical ERP landscape and takes away the thing every observability playbook assumes: OS access to put an agent on the host. The workable model is to monitor the contract, not the internals — synthetic business transactions, the interfaces SAP does expose, and the integration layers you still own. Plan to drop Alloy on the app servers and the project stalls at 'we can't get in.'
Bridging OT and IT Observability: You Meet at the Historian, Not the PLC
Manufacturing observability tempts you to instrument the plant floor directly — point a collector at the PLCs, scrape everything. That path runs into a safety boundary, an air gap, and a cardinality wall: an unscoped Windows process collector was already emitting 3,900 series per plant mid-rollout. The integration point that actually works is the process historian, and the fragile link is a service account nobody tested.
On-Prem Observability Breaks Every Assumption Your Cloud Collector Made
The Alloy config that works flawlessly as an AKS DaemonSet becomes a liability on a plant-floor VM. No elastic compute means a retry storm starves the workload it shares a host with. No managed identity means static token rotation. Egress restrictions mean the Grafana Cloud endpoint isn't reachable the way you assume. On-prem isn't cloud with worse latency — it's a different set of constraints.
The Self-Silencing Anti-Pattern: Why Your Observability Stack Goes Blind When You Need It Most
The system effectively silences its own diagnostics during the moment of maximum operational need.
Retrofitting Observability Costs 10x — What 'Day One' Actually Means
We cut service onboarding from three days to thirty minutes, but only for services that adopt the template on day one. The three days is where retrofit lives: reverse-engineering what to instrument, adding correlation IDs to a printf codebase, backfilling resource attributes, and finding cardinality bombs in production. Day one is a concrete checklist, not a good intention.
Self-Service Observability Is a Paved Road, Not an Explore Button
Handing developers an Editor role and an empty Explore tab is not self-service — it's abdication. Real self-service is a paved road: a golden-signal dashboard generated from the service name, an SLO template, and label-based access control that scopes a team to its own data. Without the paving you get hundreds of one-off dashboards, cardinality bombs nobody owns, and every team able to read every other team's telemetry.
The Grafana Terraform Provider Silently Drops LBAC Rules — and the Three-Layer Fix
When we codified Grafana Cloud multi-tenancy as Terraform, label-based access control rules applied cleanly in the plan and silently did nothing at runtime. The provider ignores LBAC config on Terraform-provisioned datasources. This post covers what actually works: a three-layer architecture splitting access control across provider aliases, manually-created datasource UIDs, and Alloy write-time label enforcement.
The Terraform Module That Has No Provider: How a Pure YAML Registry Drives a Multi-Tenant Grafana Platform
We onboard products to two Grafana Cloud stacks — dashboards, alert rules, RBAC, LBAC, contact points, OnCall — by editing one YAML file. No Terraform file changes. The key architectural decision was a provider-free Terraform module that reads the registry and derives everything else. This post covers the pattern, why it works, and where it breaks.
An SLO Without an Error-Budget Policy Is Just a Chart
Most teams that 'do SLOs' have a number in a doc and a Grafana panel showing attainment. What they don't have is the thing that makes an SLO a business instrument: a written policy that changes what the team does when the budget runs out. Without the freeze-or-ship consequence, an SLO is a vanity metric with a burn-rate alert nobody has agreed to obey.
One Un-Instrumented Hop Breaks the Whole Trace
Distributed tracing gives you the illusion of end-to-end visibility right up until a request crosses a message queue, a legacy proxy, or a cron-triggered batch job that doesn't forward the trace context. The span chain snaps, Tempo stores two unrelated fragments, and the 3am question — where did the time go — has no answer. Context propagation is the whole game.
Hybrid Observability Scales on the Label Schema, Not the Collector Count
The hard part of hybrid and multi-cloud observability isn't running collectors in every environment — it's making one query resolve identically whether the data came from AKS, an on-prem plant VM, or SAP RISE. That needs a single enforced label schema, set at the collector layer, with no segment optional. Without it, cross-environment queries become per-source OR branches and the cost dashboard becomes an unattributable blob.
Why Cardinality Kills Observability Platforms (and How to Stop It)
Cardinality is the silent killer of Prometheus-based observability platforms. Here's how it happens, how to detect it early, and the label schema discipline that keeps ingestion costs sane at scale.
Every SRE Practice Is Downstream of Observability — Here's the Dependency Chain
SLOs, error budgets, burn-rate alerting, incident response, blameless postmortems, capacity planning, chaos engineering — each one consumes observability data as input. On a signal layer you can't trust, they degrade to opinion with a dashboard. The Reactive-to-Autonomous journey is really the maturity of that signal layer, and the 80%+ alert-noise cut came from making it trustworthy enough for automation to stand on.
Push vs Pull Was Never the Point — Rethinking Metrics for the OTLP Era
The push-versus-pull debate is settled for application metrics: OTLP push through a collector. The migration that actually matters is what comes with it — resource-attribute promotion instead of relabel configs, exemplars linking metrics to traces, and a deliberate delta-vs-cumulative temporality choice. Lift-and-shift your Prometheus scrape config into OTLP and you keep the mechanics while losing the point.
Learn the Observability Pipeline, Not the Tools — a Map That Survives a Vendor Swap
Beginners drown memorizing Prometheus vs Loki vs Tempo vs Jaeger vs Alloy vs Fluent Bit. The durable model is a six-stage pipeline — instrument, collect, process, store, query, alert — where every tool is a swappable implementation of one stage. When we evaluated four whole observability stacks for the platform I lead, the pipeline shape was identical across all four; only the slots changed.
Monitoring Answers the Questions You Wrote Down. Observability Answers the Ones You Didn't.
A PromQL query grouped by deployment_environment silently returned nothing — no error, no failed scrape, no alert, every dashboard green. Nothing was broken in the way monitoring understands broken; the label had just stopped being promoted. This is the practical line between monitoring (a fixed set of questions frozen at design time) and observability (asking new questions of data you already collected), and what it costs to confuse the two.
The Three Pillars of Observability Are a Storage Detail, Not a Strategy
Metrics, logs, and traces name three storage engines with different index models and cost curves — not three things to instrument separately. Teams that organize around the pillars build three disconnected silos and still can't say why one request was slow. The unit that matters is the correlated event: one trace_id and an exemplar that stitches a histogram bucket to the trace to the logs.