ABSIA - Causal Intelligence for Distributed Systems
I built ABSIA because most observability tools still leave operators doing the hardest part manually - figuring out what actually caused the incident.
Modern systems generate huge amounts of metrics, logs, and traces, but during failures teams still spend hours jumping between dashboards trying to understand what triggered the problem and whether an automated fix is even safe.
I wanted to experiment with a different idea. What if an observability system could reason about infrastructure behavior instead of only visualizing it?
That became ABSIA.
ABSIA is a causal observability control plane for distributed systems. It watches infrastructure telemetry, builds relationships between services, tries to identify likely root causes, explains the reasoning path, and only recommends actions when confidence is high enough.
One of the biggest design decisions was making the system capable of saying:
UNKNOWN
instead of pretending it knows the answer.
A lot of products aggressively claim certainty even when the evidence is weak. I wanted ABSIA to behave more like a cautious operator than a hallucinating chatbot.
The project was built primarily in Go with a fully containerized architecture using Docker Compose. Prometheus is used for telemetry collection, while cAdvisor and node-exporter provide infrastructure metrics. The UI is embedded directly into the Go binary, so the entire control plane can run as a single deployable service.
The internal architecture is split into five stages:
- signal physics
- pattern intelligence
- causal inference
- explanation
- policy and safety
The signal layer converts telemetry into queueing-style metrics like arrival rate, service rate, queue pressure, and load behavior.
The pattern layer detects spikes, drift, and instability.
The causal layer tries to determine which services are actually driving failures instead of only reporting symptoms.
The explanation layer generates interpretable evidence, and the final policy layer blocks unsafe automated actions when confidence is too low.
One of the hardest parts of the project was making the system behave realistically instead of becoming a fake dashboard with random AI labels.
I spent a lot of time debugging:
- real-time metric ingestion
- Prometheus integration
- Docker networking
- frontend pipeline synchronization
- causal graph propagation
- confidence scoring
Another challenge was building the UI around live infrastructure behavior. The dashboard only becomes interesting once the system starts receiving real telemetry and enough samples exist for the pipeline to reason about node behavior.
This project taught me a lot about distributed systems, observability engineering, queueing theory, causal reasoning, and how difficult safe automation actually is.
ABSIA is still experimental, but the goal is to push observability beyond monitoring and toward real-time infrastructure intelligence.
Built With
- cadvisor
- causal
- compose
- distributed
- docker
- engineering
- go
- html
- inference
- infrastructure
- node-exporter
- observability
- processing
- prometheus
- queueing
- real-time
- systems
- theory
Log in or sign up for Devpost to join the conversation.