Delayed Dissection

Delayed Dissection enables full L7 API Dissection functionality on captured traffic. Capture raw packets on production nodes with minimal overhead, then run complete protocol analysis later—on non-production compute, on your schedule.

The result is identical to real-time dissection: full request/response payloads, headers, timing, and Kubernetes context.

Why Delayed Dissection?

Real-time L7 API dissection requires substantial CPU and memory to parse protocols, reconstruct request/response pairs, and maintain state. This creates a trade-off:

ApproachCPU ImpactData Loss RiskWhen to Use
Real-time dissectionHighHigher under loadActive debugging, development
Delayed dissectionMinimalNoneProduction monitoring, forensics

Delayed dissection addresses this by:

  • Capturing everything with minimal CPU usage
  • Analyzing later when resources are available
  • Using non-production compute for heavy processing

How It Works

PRODUCTION                           NON-PRODUCTION
+------------------+                 +------------------+
|                  |                 |                  |
|  Raw Capture     |--- Snapshot --->|  L7 Dissection   |
|  (minimal CPU)   |                 |  (full parsing)  |
|                  |                 |                  |
+------------------+                 +--------+---------+
                                              |
                                              v
                                     +------------------+
                                     |  Dissection DB   |
                                     |  (queryable)     |
                                     +------------------+
  1. Capture: Raw Capture continuously stores L4 traffic with minimal CPU
  2. Snapshot: Create a Traffic Snapshot for the time window of interest
  3. Dissect: Run L7 protocol analysis on the snapshot
  4. Query: Access the dissected data via the Dashboard or MCP

Key Benefits

Production Safe

Raw capture uses minimal CPU—primarily disk I/O. The heavy lifting of protocol parsing happens elsewhere, ensuring production workloads aren’t affected.

No Data Loss

Since capture requires minimal resources, packet loss is eliminated. Every request and response is preserved for later analysis.

Flexible Timing

Run dissection:

  • Immediately after an incident is reported
  • Periodically in the background
  • On-demand when investigation is needed

Complete Context

Delayed dissection produces the same rich data as real-time:

  • Full request/response payloads
  • Headers, status codes, timing
  • Kubernetes identity (pod, service, namespace)
  • Process-level context from eBPF

Workflow

1. Ensure Raw Capture is Enabled

See Configuration for raw capture and snapshot storage settings.

2. Create a Snapshot

When you need to analyze a time window, create a Traffic Snapshot:

  • Select the nodes to include
  • Choose the time window
  • The snapshot becomes immutable

3. Run Delayed Dissection

Start dissection on the snapshot. This can be done via:

4. Query the Results

Once complete, the dissection database contains fully parsed API calls:

  • View in the Dashboard
  • Query via MCP with ?db=<snapshot>/<dissection>
  • Export for further analysis

Comparison with Real-Time Dissection

FeatureReal-TimeDelayed
See traffic liveYesNo
CPU impact on productionHighMinimal
Data loss under loadPossibleNone
Analyze past trafficLimited by retentionYes
Requires snapshotNoYes

Best practice: Use both together—raw capture always on, real-time dissection enabled when actively debugging.

What’s Next