TraceGraph AI 如何利用 FalkorDB 串連事故調查線索

TraceGraph AI: Using FalkorDB to Connect the Dots in Incident Investigation

How graph-powered reasoning can help engineers investigate incidents with evidence, relationships, and persistent memory.

The Problem: Investigating Incidents Is More Than Finding Logs

When a software system experiences an incident, engineers need to answer several questions quickly:

• Which services are affected?
• What dependencies connect those services?
• Did a deployment occur before the incident?
• Have we experienced a similar incident before?
• What did we learn from previous investigations?

The challenge is that operational information is interconnected. An incident may affect one service, that service may depend on another, and a historical incident may contain a resolution worth investigating.

Looking at individual records is not always enough. Engineers need to understand how these pieces of evidence relate to each other.

That motivated me to build TraceGraph AI, a graph-powered incident investigation application built with FalkorDB.

Introducing TraceGraph AI

TraceGraph AI helps Site Reliability Engineers (SREs), DevOps engineers, and incident response teams investigate software incidents through connected operational evidence.

The application connects incidents, services, dependencies, deployments, historical incidents, resolutions, runbooks, and investigation memory in a graph.

The project includes:

• An overview dashboard for incidents and connected services.
• A Graph Explorer for inspecting nodes and relationships.
• An investigation workflow that retrieves evidence and ranks potential causes.
• Historical incident context and recorded resolutions.
• Persistent investigation reports and agent memory.
• Runbooks and service ownership information.

The goal is not to claim that a graph automatically discovers the true root cause. Instead, TraceGraph AI makes relevant evidence and relationships easier to explore, helping engineers investigate more systematically.

Why I Chose FalkorDB

The central design decision was to treat relationships as first-class data.

Consider a simplified example:

INC-1001 → AFFECTS → Checkout API

The Checkout API may depend on another service. A historical incident may have affected the same service, and that earlier investigation may have recorded a resolution.

A graph allows the application to traverse these relationships and retrieve connected context rather than relying only on isolated incident records.

FalkorDB serves as the graph database behind TraceGraph AI. It stores the connected operational entities and supports the graph queries used by the investigation workflow.

This makes the graph more than a visualization. It is part of the application's retrieval and reasoning process.

How the Investigation Workflow Works

TraceGraph AI follows an evidence-first approach.

1. Retrieve connected evidence

The application queries FalkorDB for the incident, affected services, dependencies, historical incidents, resolutions, and related operational context.

2. Explore potential explanations

The investigation engine evaluates the retrieved evidence and counter-evidence to rank potential causes. For example, a deployment preceding an incident may be relevant, but timing alone does not prove causation.

3. Preserve provenance

The application presents evidence identifiers and relationship paths so users can inspect where an investigation finding came from.

4. Save investigation knowledge

Completed investigations can be stored as reports with episodic memory. The application also supports sourced semantic and procedural memories, including review and archive controls.

5. Use memory carefully

Relevant reviewed procedural knowledge can inform checks in a later investigation. However, previously stored information is context to evaluate, not automatic proof that the same explanation applies again.

This design aims to make investigation results more explainable and useful over time.

Agent Memory and Coordination

Another important part of TraceGraph AI is persistent investigation memory.

An investigation should not necessarily end when the current incident is closed. Its evidence, decisions, and lessons may help with future incidents.

TraceGraph AI supports persistent episodic, semantic, and procedural memory in the graph. Users can inspect and review stored knowledge rather than treating every past conclusion as unquestionably correct.

The project explores a practical form of coordination between automated investigation workflows and human review. It does not claim that the current version implements a network of autonomous agents negotiating with one another.

Technology Stack

TraceGraph AI combines:

• FalkorDB for graph storage and relationship traversal.
• React and TypeScript for the user interface.
• Node.js, Express, and TypeScript for the backend API.
• Cypher graph queries for retrieving connected operational context.
• Railway for the live demonstration deployment.

The investigation engine can operate deterministically without requiring a paid language-model API key. Optional model-assisted ranking is constrained to reordering existing hypothesis identifiers, with a deterministic fallback.

The demonstration uses synthetic incident data rather than real production telemetry.

Challenges and Lessons Learned

1. Relationships must be useful, not merely visible

Drawing connected nodes is not enough. The relationships must support meaningful retrieval and help answer investigation questions.

2. Correlation is not causation

A deployment may precede an incident without causing it. A historical resolution may be relevant without being the correct fix for the current problem.

This distinction influenced the project's evidence-first design and its treatment of uncertainty.

3. Persistent memory needs provenance and review

Saving previous findings can improve continuity, but outdated or incorrect knowledge can also mislead future investigations. Sources, review controls, and the ability to archive memory are therefore important.

4. A working demo requires more than a database

A useful graph-powered application needs a reliable API, a clear interface, meaningful queries, error handling, and a deployment that can be tested by other people.

Building and deploying TraceGraph AI helped bring these pieces together in a complete demonstration.

What I Would Build Next

There are several opportunities to extend the project:

• Integrate real observability platforms and incident-management systems.
• Add timestamps and freshness checks to improve the quality of retrieved evidence.
• Strengthen authentication, authorization, and access controls.
• Improve evaluation using incident datasets with known outcomes.
• Expand memory retrieval and contradiction handling.
• Explore richer coordination between specialized investigation agents.

These improvements would move the project closer to a production-ready incident investigation platform.

Try TraceGraph AI

The live application and source code are available here:

• Live demo: https://tracegraphai.up.railway.app/
• GitHub repository: https://github.com/shubham-coder-ship-it/TraceGraph-AI
• Video demonstration: https://youtu.be/1-G7alMillY

Final Thoughts

Building TraceGraph AI reinforced an important idea: incident investigation is fundamentally about connecting evidence.

FalkorDB provides a graph-based foundation for retrieving those connections, exploring historical context, and retaining investigation knowledge. By combining graph queries, explainable evidence paths, cautious hypothesis ranking, and persistent memory, TraceGraph AI demonstrates how connected data can support a more systematic incident response workflow.

The larger lesson is that useful AI-assisted investigation should not only suggest an answer. It should help engineers understand the evidence behind that answer, recognize uncertainty, and make better-informed decisions.

Built for the FalkorDB Graph Hacks hackathon.