When AgentSight traces go missing: truncation, event loss, and evidence limits

Direct answer: distinguish missing bytes from missing events

In the released Linux TLS tracer, len records the length returned by an SSL read/write operation, while buf_size records the bytes copied into the BPF event. A positive difference sets truncated=true and bytes_lost: a prefix exists. By contrast, a failed bpf_ringbuf_reserve cannot create an event; it increments a tracer-wide ringbuf_reserve_failures counter instead.

These are different failure domains. Per-operation truncation has a byte count but no missing event; a reservation failure has a failed-reservation count but no reconstructable payload or connection. A parser may also decline to correlate otherwise visible fragments when their framing or identity is no longer reliable.

This analysis is pinned to AgentSight v1.0.35, product commit c1574366122a90c451bca6a84713e28813ab95e2, reviewed 30 October 2026. It uses first-party source and synthetic unit tests, not a newly performed host-capture benchmark.

Why the two loss counters cannot be combined

The TLS probe reserves a fixed-size BPF event, with a 256 KiB plaintext buffer and a 16 MiB ring buffer in this version. An oversized SSL operation can emit its first 256 KiB with a truncation marker. If the reservation itself fails, however, the event never enters the ring. Successful events carry a snapshot of the cumulative failed-reservation counter. On graceful SIGINT or SIGTERM shutdown, the tracer reads that counter again and emits a minimal CAPTURE_LOSS record if failures occurred since the last reported snapshot. Abrupt termination cannot use that final reporting path.

Importantly, CAPTURE_LOSS is a tracer-wide cumulative signal, not a missing HTTP-request counter. A rise from two to five means three additional failed reservations in the observed interval; it does not tell which TLS handle, model request, or agent thread generated them. The capture_seq field orders emitted JSONL records in userspace, not kernel execution, and should not be treated as a lost-event oracle.

Ten situations and the safest inference

What you observe	What the implementation does	What you can conclude
TLS event has len=600000, buf_size=262144 and truncated=true	One SSL operation emitted a retained prefix bounded by the 256 KiB probe buffer.	There are 337856 missing bytes from this operation, but an event was emitted.
A later TLS event raises ringbuf_reserve_failures from 2 to 5	The tracer-wide cumulative ring-buffer reservation-failure counter increased.	Three reservations failed in that interval; no per-connection payload attribution is possible.
CAPTURE_LOSS appears during graceful shutdown	The tracer reports an increased cumulative counter after draining the ring buffer.	Whole events were missed; the record does not identify their contents or connections.
No final CAPTURE_LOSS after SIGKILL or host failure	Abrupt termination bypasses the graceful final-counter reporting path.	Absence of a final record is not proof that the preceding capture was lossless.
capture_bytes_lost=10 and ringbuf_reserve_failures_delta=3	The first value sums clipped bytes in observed fragments; the second compares tracer-wide snapshots.	Different units and scopes: do not add them or call three missing HTTP responses.
capture_truncated=null or capture_metadata_complete=false	Older or incomplete fragments lack required provenance or length fields.	Unknown is not false. Do not advertise a complete transport observation.
capture_identity_consistent=false	Contributing fragments disagree on transport/process/library identity.	The derived identity fields are cleared; do not attribute the exchange to a single TLS handle.
capture_tids_truncated=true	The analyzer lists at most 64 distinct contributing thread IDs.	The thread list is not exhaustive even if capture_tid_count is greater than 64.
HTTP correlation terminates after loss-counter movement	The parser invalidates pending state for all active connections rather than guessing byte order.	An unlinked response can reflect defensive matching, not a confirmed missing model call.
FILE_OPEN_LOST with count=4	The separate process tracer reports a delta of lost file-open probe events/recursion misses.	This is not TLS CAPTURE_LOSS and reveals no missed paths or exact file-open frequencies.

The matrix is a versioned interpretation reference. It is not an empirical distribution of loss causes or a guarantee that every probe attachment succeeds.

A source-tested example: ten clipped bytes versus three failed reservations

The source-level CaptureMetadataAccumulator test deliberately combines two synthetic TLS fragments. The first has len=100, buf_size=90, truncated=true, bytes_lost=10, and a failure-counter snapshot of two. The second has len=50, buf_size=50, no truncation, and a failure-counter snapshot of five.

Its asserted aggregate is capture_fragment_count=2, capture_original_len=150, capture_captured_len=140, capture_bytes_lost=10, and ringbuf_reserve_failures_delta=3. The 10 is clipped plaintext bytes in the two observed fragments. The three is a difference between tracer-wide cumulative reservation counts. Neither proves that three messages or three requests were missing from this particular exchange.

The same source tests demonstrate two other defensive behaviors. Conflicting TLS identities clear the derived handle, process discriminator and library rather than silently choosing one. Missing lengths cause nullable aggregate totals and capture_metadata_complete=false; legacy fragments remain readable but do not gain invented completeness. A separate test supplies 70 thread IDs and confirms the serialized list is capped at 64 while retaining the larger count and a truncation flag.

Why a captured HTTP response can still become unlinked

A truncated TLS record can leave AgentSight with a usable HTTP/1.1 header and body prefix but not the full declared body. The parser emits a marked record with body_truncated, body_truncation_reason, and body_captured_bytes rather than pretending it saw the entire response. When a declared Content-Length and the missing byte count permit exact skipping, the parser can attempt to resume at a later message. Unknown or chunked framing and some oversize losses make that realignment unsafe.

A changed global ring-buffer failure counter invalidates pending parser state for all active HTTP connections, deliberately sacrificing matching coverage instead of guessing HTTP/1.1 FIFO position or HTTP/2 compression state. A resulting unlinked exchange is therefore not evidence that its peer failed to send a response. The separate HTTP correlation study explains connection identity and stream matching; this page explains how to assess whether the underlying observation is complete enough to rely on.

File-open drops are a third, independent signal

AgentSight's Linux process tracer reports FILE_OPEN_LOSTfrom a per-CPU dropped-event counter and, where available, BPF program recursion misses. Its JSON count is the increase since the last report, not the cumulative TLS reservation counter. It contains no missing pathname. The ordinary FILE_OPEN stream is also deduplicated by process, file identity, access and overlay layer: fewer rows do not imply a matching number of missing open syscalls.

Keep this distinction when comparing model traffic and file effects. A clean TLS capture does not certify complete file tracing, and a file-drop warning does not establish missing TLS content. See the file-open evidence reference for resolved-path hooks, older syscall fallbacks, and duplicate suppression.

Reproduce the counter interpretation without recording private traffic

The pinned repository contains synthetic Rust unit tests for fragment lengths, counter snapshots, conflicting identity, thread-list limits, and legacy fields. To inspect this behavior without live model prompts or packet capture, check out that exact product commit and run the relevant unit tests:

git clone https://github.com/eunomia-bpf/agentsight.git
cd agentsight
git checkout c1574366122a90c451bca6a84713e28813ab95e2
cargo test --manifest-path ext/analysis/Cargo.toml capture_metadata

This is a proposed source-only reproduction, not a test run executed for this publication. Passing it would establish the tested analyzer contracts in that build environment, not event-capture completeness under a particular kernel, TLS implementation, ring-buffer load, or process scope.

A practical incident-review checklist and its limits

First identify the capture mode, target process scope and TLS attachment path; no capture counter detects a library that was never attached. Next inspect raw len, buf_size, and truncated on observed records; then examine cumulative ringbuf_reserve_failuressnapshots and any final CAPTURE_LOSS. For derived records, preserve nullable capture_truncated, capture_metadata_complete, identity-consistency and fragment metadata. Finally, distinguish HTTP parser quarantine from an actual absent model call and independently checkFILE_OPEN_LOST if file evidence matters.

A zero observed loss delta does not establish that an entire session was recorded. Unsupported or unattached TLS paths, filters, process exits, missing legacy fields, abrupt termination, scheduling delays, and sampling can all leave gaps not reconstructed by these counters. Raw captures can contain prompts, responses, headers, paths, and endpoints; use synthetic examples or appropriately redacted internal evidence rather than uploading private traces publicly. For row-level lineage from native sessions versus live capture, consult the audit provenance reference.

Primary implementation references

Every asserted implementation detail above is pinned to the stated release. The canonical AgentSight documentationowns current installation and command details; this article focuses on evidence interpretation and explicitly does not claim an end-to-end measurement.