What debugging agents need from observability SDKs

TL;DR

Most observability SDKs record enough data to show that a request was slow or failed. Debugging agents need the evidence that explains why, so Foam’s packages capture richer request and response context, redact it before export, and make it available through standard OpenTelemetry signals.

The question

Foam publishes OpenTelemetry distributions for Node.js and Ruby. They install automatic instrumentation, configure traces, metrics, and logs, and export those signals to Foam.

That description sounds similar to many observability agents. Datadog and New Relic ship mature language agents. Sentry collects errors and increasingly rich tracing data. Honeycomb recommends the OpenTelemetry SDK. OpenTelemetry itself already supplies automatic instrumentation for common frameworks and libraries.

The useful comparison is therefore not whether a package creates spans. That is now table stakes. The useful questions are:

How much debugging evidence does the package collect?
What happens to sensitive data before it leaves the process?
Can the package coexist with an OpenTelemetry setup that is already there?
Can an operator tell whether instrumentation and export are actually working?

This note compares the public Foam package implementations with current first-party documentation from OpenTelemetry, Sentry, Datadog, New Relic, and Honeycomb. It compares collection libraries, not the vendors’ complete hosted products.

Automatic instrumentation is the baseline

The official OpenTelemetry Node.js distribution can automatically instrument popular libraries and frameworks with no application-code changes. OpenTelemetry currently classifies JavaScript traces and metrics as stable, while logs remain in development. For Ruby, traces are stable while metrics and logs remain in development.

Datadog, New Relic, Sentry, and Honeycomb all support OpenTelemetry to different degrees. Some accept telemetry from the standard SDK. Others implement OpenTelemetry APIs inside their own agents. Sentry’s Node SDK is itself built around OpenTelemetry components.

Foam does not differentiate merely by bundling instrumentation. Its packages use the official OpenTelemetry APIs, SDKs, instrumentations, propagation, and OTLP exporters, then add collection and safety behavior intended for debugging agents.

The largest difference is the depth of HTTP context

The OpenTelemetry HTTP semantic conventions now define development-stage attributes for request and response body content. The standard Node and Ruby HTTP instrumentations reviewed here do not automatically populate those attributes with complete body streams, so applications still need custom capture logic.

That boundary makes sense for general-purpose telemetry. Bodies can be large and sensitive. It also leaves out the exact evidence that often explains an application failure: the arguments sent to another service, the response it returned, or the difference between the value a user submitted and the value the application processed.

Foam’s default basic network capture stays conservative. It records only selected content headers in addition to normal OpenTelemetry HTTP data. The opt-in advanced mode goes further:

The Node package observes request and response bodies at the node:http, https, and Fetch/Undici transport layers. This covers clients built on those transports, including Axios, Got, node-fetch, Ky, and Superagent.
The Ruby package observes Rack server traffic and supported clients including Net::HTTP, Faraday, Excon, and HTTPClient.
Captured body data is attached to the relevant span and emitted as correlated foam.http.body.chunk log records.
Capture is bounded. Each body is limited to 1 MiB, chunk records are limited to 64 KiB, and the packages record whether capture was truncated or incomplete.
Compressed textual bodies are decoded where supported. Binary or unsupported content is handled more conservatively.

This produces a more useful investigation record than standard HTTP spans alone. An agent can connect a failure to the payload that triggered it without starting a second, incident-specific logging project.

Body capture is not unique by itself

Current Sentry JavaScript and Ruby SDKs are the closest comparison. Their dataCollection settings can collect incoming and outgoing request and response bodies, and their send hooks can modify or drop telemetry before it is sent. It would be inaccurate to claim that Foam is the only SDK that captures HTTP bodies.

The distinction is the package design around that data. Foam treats body capture as part of a multi-signal OpenTelemetry pipeline, correlates chunk records with spans, applies the same redaction policy across signals, and exposes processors and readers that can add Foam as another destination to an existing OpenTelemetry SDK.

In the official documentation reviewed for this note, Datadog documents payload extraction for AWS SDK calls rather than general HTTP request and response bodies. New Relic documents request parameters and custom attributes rather than automatic capture of general HTTP body streams. Honeycomb has retired its Node and Ruby OpenTelemetry distributions and now recommends the upstream SDK, which does not provide turnkey body-stream capture.

These statements describe the documented package behavior reviewed here. They are not proof that no undocumented integration or separately licensed product can collect similar data.

Richer capture requires stronger safety boundaries

Collecting more context without a clear data policy would create a larger security problem. Foam’s packages make redaction part of the export path rather than an optional cleanup step after collection.

Both packages mask built-in credential and personal-data keys and accept application-specific secret and PII keys. Matching normalizes case and common separators, so forms such as apiKey, api-key, and API_KEY are treated consistently.

The policy applies to:

span, span-event, and span-link attributes;
log bodies and attributes;
metric data-point attributes;
resource attributes;
URLs and supported captured HTTP bodies.

Redaction runs on the copy exported to Foam, including data sent through Foam’s ingest helpers. It does not mutate the application’s telemetry objects or the copies sent to other exporters. Applications can also use beforeSend to edit or drop spans and logs before Foam exports them.

Sentry also provides built-in sensitive-key scrubbing and signal-specific beforeSend hooks. The OpenTelemetry Collector provides attribute, filter, redaction, and transform processors that can protect data centrally. Honeycomb documents these Collector processors and its own telemetry-pipeline redaction processor.

The trade-off is location. Collector-side controls are powerful and vendor-neutral, but data must reach the Collector before those controls run. Foam’s package-level redaction runs inside the application process before Foam export. Teams with strict requirements should still keep advanced capture opt-in, add their own keys, and test representative payloads.

Coexistence matters more than a clean-sheet install

Production applications often already have an OpenTelemetry provider or another vendor’s SDK. A useful package needs an adoption path that does not require replacing the existing telemetry stack in one migration.

Foam supports two modes:

init lets Foam configure the process-wide OpenTelemetry providers and automatic instrumentation.
Ingest factories create a Foam span processor, log record processor, or metric reader that an application can attach to providers it already owns.

The second mode gives Foam a copy without taking over the global provider. Redaction and beforeSend still apply to Foam’s copy, while the original telemetry and other exporters remain unchanged.

This capability is not exclusive to Foam. Sentry documents adding its span processor to an existing Node OpenTelemetry provider, though a complete custom setup also requires Sentry’s sampler, propagator, and context manager. New Relic’s Node Hybrid Agent supports OpenTelemetry traces, metrics, and logs, while its Ruby OpenTelemetry API support is currently trace-only. Datadog supports OpenTelemetry APIs and instrumentations through its SDKs, but its compatibility guidance generally warns against mixing independent Datadog and OpenTelemetry SDKs; its Ruby integration does not support standard OpenTelemetry span processors or exporters.

The important distinction is not “OpenTelemetry compatible” as a binary label. It is whether a package can join the application’s existing signal pipelines with ordinary OpenTelemetry components and preserve the behavior of other destinations.

Raw payloads are not the same as agent semantics

HTTP payload capture is useful forensic evidence, but it does not automatically describe an agent trajectory. A debugging system also benefits from explicit concepts such as agents, handoffs, tools, retrieval, guardrails, prompts, and model responses.

OpenInference is stronger in this narrower semantic layer. Its JavaScript packages define span kinds for agents, chains, tools, retrievers, rerankers, embeddings, guardrails, and evaluators, with instrumentations for major model and agent frameworks. It is trace-focused and does not currently provide an official Ruby implementation.

OpenLLMetry is a closer cross-language alternative for LLM and agent tracing. Its Node package automatically instruments a broad set of providers and frameworks, while its Ruby SDK remains beta and requires more manual recording.

The official OpenTelemetry GenAI conventions are also adding development-stage agent, workflow, and tool semantics. This means semantic agent tracing is becoming a shared standard rather than a durable proprietary moat.

Foam’s package-level strength is different: it combines ordinary application telemetry, logs, metrics, and bounded transport payloads in one runtime distribution. The most credible open alternative is not one package; it is upstream OpenTelemetry plus Collector governance and an AI semantic layer such as OpenInference.

The packages report their own health

An instrumentation package can initialize without crashing and still capture nothing. A library may load too late to be patched, a provider slot may already belong to another SDK, or an instrumentation may not support the installed framework version.

Foam exposes this state directly. The Node getState() and Ruby state APIs report whether initialization completed, which instrumentations installed, and whether traces, metrics, logs, and baggage have a global, ingest, local, or absent Foam path. Initialization also reports its outcome to Foam when a token is available.

The packages are designed not to take down the host application. Node init() does not throw, Ruby init does not raise, and capture hooks run behind safety boundaries. Invalid sensitive-data configuration leaves the SDK disabled rather than silently exporting unredacted data.

This is less visible than body capture, but it is important for agents. Missing telemetry can look like evidence that nothing happened. Explicit instrumentation state lets the platform distinguish “the system emitted no signal” from “the SDK never observed this part of the system.”

Node and Ruby share a model, not identical mechanics

The two packages aim for the same public model: one initialization call, OpenTelemetry signals, automatic instrumentation, optional advanced network capture, export-time redaction, ingest components, lifecycle controls, and diagnostic state.

Their implementations follow each runtime:

Node must initialize before instrumented imports. It patches the HTTP and Undici transport layers and integrates with Bunyan, Pino, Winston, and console.
Ruby initializes after application gems load but before the app runs. It uses Rack and Rails middleware, patches supported HTTP clients, integrates with Ruby Logger, and flushes telemetry around AWS Lambda invocations.

The coverage is not complete. Node advanced capture does not yet cover WebSockets, HTTP/2, gRPC payloads, database results, or messaging payloads. Ruby does not capture bodies for every HTTP client or several streaming paths and has no database-result capture. Neither package currently provides OpenTelemetry profiling.

Those limits matter. “More data” should mean known, testable coverage—not a promise that every byte crossing every runtime boundary is already visible.

Current implementation risks

Both repositories describe prerelease software. Node is published as 0.1.0-alpha, and Ruby main is 3.0.0.alpha. The source also exposes risks that a production evaluation should test directly:

Node current main can export unknown or binary bodies as bytes, where key-based redaction cannot inspect their contents. Open pull requests are changing capture and redaction behavior.
Ruby has an open performance change addressing high temporary allocation and request-thread cost in current redaction paths.
Advanced body capture requires a sampled span and a Foam-capable log pipeline. It can be skipped when the trace is unsampled, the concurrent-capture limit is reached, or another SDK owns logs without Foam’s processor attached.
Coexistence is provider-aware, not automatically conflict-free. Constructing an ingest processor changes reported state, but cannot prove that the application actually attached it.
Crash delivery is incomplete. Node’s automatic lifecycle hook does not cover process crashes or deployment signals; Ruby’s normal-exit handling still cannot save the final batch after KILL, exit!, or a native crash.
Ruby’s README includes a stale pre-fork TODO even though current main installs a fork hook. Source and documentation can temporarily disagree while these packages are moving quickly.

These caveats do not erase the design differences. They narrow the claim from “complete and safe capture” to “an unusually explicit architecture for richer capture, with important prerelease boundaries.”

What is defensible

The strongest claim supported by the packages is narrower and more useful than “Foam has instrumentation.”

Foam’s Node and Ruby packages are OpenTelemetry distributions designed to create agent-ready debugging context. They combine broad automatic instrumentation with bounded HTTP payload capture, process-local redaction across signals, additive export into existing OpenTelemetry providers, and explicit diagnostics about what is actually connected.

The market is moving in this direction. Sentry’s current data-collection model shows that richer request context is becoming part of mainstream SDK design. New Relic and Datadog are both expanding OpenTelemetry interoperability. OpenInference, OpenLLMetry, and the OpenTelemetry GenAI conventions are making agent semantics portable. The open standard and the Collector provide increasingly capable transformation and governance primitives.

Foam’s bet is that debugging agents need these pieces as one collection contract: capture enough evidence to explain behavior, protect that evidence before export, preserve the customer’s existing telemetry pipeline, and make coverage gaps observable.