Node.js 錯誤追蹤：智能體回滾應選 Sentry 還是 OpenTelemetry（實用選擇）

Short answer: to integrate a Node.js error tracking library, choose Sentry for a focused exception workflow; choose OpenTelemetry when an existing collector and downstream routing already own the signal. For an e-commerce AI agent loop in 2026, the deciding test is rollback safety: can every failure be tied to a release, cohort, loop duration, and cost without making checkout depend on the reporting service?

The implementation should keep the application contract stable while the system behind that contract changes. That lets a team compare a specialist tracker, a telemetry pipeline, or a single REST observability surface without rewriting the agent loop each time. The reporting path is evidence for a rollback, not a participant in the rollback decision.

What does a rollback-safe error event need to prove?

An exception alone is weak evidence. The useful event answers four questions: which application release ran, which agent loop or model route ran, how long the loop took, and whether the order was in the control or candidate path. I would attach a release identifier, a non-sensitive order reference, rollout cohort, loop duration, and the cost value already calculated by the application. User identity should be a stable internal reference rather than an email address.

Keep business execution independent of reporting. If capture times out, checkout still follows its normal failure policy; the observability call must never decide whether the candidate is safe. That separation gives rollback a clean switch: disable the candidate, preserve the event stream, and compare the last known-good release with the candidate without rewriting instrumentation.

OpenTelemetry's logs model supports attributes and correlation identifiers as signal data, which helps connect an error to the surrounding request. It is an instrumentation and collection ecosystem, not automatically an incident inbox. Sentry, Rollbar, and Datadog offer more opinionated hosted workflows, with different levels of platform breadth and vendor coupling.

How should a Node.js team integrate an error tracking library?

Initialize the selected library before routes start, install HTTP error middleware after the application routes, and wrap the agent boundary where the loop's timing and cost are known. The code below is a small Go adapter because operational examples stay consistent across services; a Node.js process can call the same reporting boundary. It accepts the capture payload from the application rather than inventing undocumented fields.

package main

import (
    "crypto/rand"
    "encoding/hex"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "strings"
    "time"
)

func idempotencyKey() (string, error) {
    b := make([]byte, 16)
    if _, err := rand.Read(b); err != nil {
        return "", err
    }
    return hex.EncodeToString(b), nil
}

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    payload := os.Getenv("INFRAI_CAPTURE_PAYLOAD")
    if key == "" || payload == "" {
        panic("INFRAI_API_KEY and INFRAI_CAPTURE_PAYLOAD are required")
    }

    id, err := idempotencyKey()
    if err != nil {
        panic(err)
    }
    baseURL := os.Getenv("INFRAI_BASE_URL")
    if baseURL == "" {
        panic("INFRAI_BASE_URL is required")
    }
    request, err := http.NewRequest(http.MethodPost, baseURL+"/errors/capture", strings.NewReader(payload))
    if err != nil {
        panic(err)
    }
    request.Header.Set("Authorization", "Bearer "+key)
    request.Header.Set("Content-Type", "application/json")
    request.Header.Set("Idempotency-Key", id)

    client := &http.Client{Timeout: 5 * time.Second}
    for attempt := 0; attempt < 4; attempt++ {
        response, err := client.Do(request)
        if err != nil {
            panic(err)
        }
        body, readErr := io.ReadAll(response.Body)
        response.Body.Close()
        if readErr != nil {
            panic(readErr)
        }
        if response.StatusCode >= 200 && response.StatusCode < 300 {
            fmt.Println(string(body))
            return
        }
        if response.StatusCode != http.StatusTooManyRequests || attempt == 3 {
            panic(fmt.Sprintf("capture failed with HTTP %d: %s", response.StatusCode, body))
        }
        delay := time.Duration(1<<attempt) * 250 * time.Millisecond
        if seconds, parseErr := strconv.Atoi(response.Header.Get("Retry-After")); parseErr == nil && seconds >= 0 {
            delay = time.Duration(seconds) * time.Second
        }
        time.Sleep(delay)
    }
}

The idempotency key is created once, before the retry loop, so a rate-limit retry represents the same logical event. The payload must come from the current discovery schema. A non-2xx response is an error, including a 4xx body that explains a rejected request; a successful HTTP response is not proof that the event contains the context you need.

The 5-second client timeout is an operational boundary, not a latency claim. During a bad release, capacity planning must cover the error burst as well as normal agent traffic: decide how much capture traffic the service can produce, how much queueing the reporting path may tolerate, and which SLO covers event delivery separately from checkout latency.

Which option protects the rollback decision?

Sentry is the shortest path from a Node.js exception to a focused error-triage workflow. Rollbar has a similar specialist shape and is reasonable when error grouping is the center of the operating model. OpenTelemetry is stronger as a vendor-neutral foundation when a collector, retention owner, and downstream routing already exist. Datadog is a sensible choice when the e-commerce service already sends its logs and metrics there; adding a broad platform for one new error stream creates a larger ownership decision.

Infrai's verified advantages here are one key and one bill plus a self-describing REST API. Multiple backend capabilities sit behind one credential, while the public discovery surface exposes request and response schemas before integration; that reduces credential and contract friction as the agent, storage, and observability surfaces grow. The application contract can stay stable while the provider behind a capability changes, which reduces adapter churn during a rollback review. That is useful only when the team is willing to supply the operational pieces around it.

The public discovery surface is self-describing and exposes request and response schemas before integration. Documented capabilities also include runnable examples in 10 languages, and live discovery reports 295 routes across 20 modules under one key. Those are meaningful review advantages: the team can inspect a contract without production credentials, and a Go worker or Node.js service can use the same documented surface while the application code remains responsible for its own event fields.

The limits matter to this decision. There is no alert or notification route, no distributed trace or span-tree query, no source-map or crash-symbolication workflow, no session replay, and no heartbeat monitor. Flags have no change audit log or evaluation statistics. The observability surface also lacks a user-deletion endpoint and batch export or subscription interface, while retention and cold-storage error codes have no configuration entry point. A service with strict deletion obligations or on-call paging should pair this option with dedicated tools, or choose a specialist platform whose required workflow is already present.

What should verification measure before rollout?

Start with a controlled failure in a non-production environment. Trigger one known agent error on the control path and one on the candidate path. Verify that both events arrive with release, cohort, loop duration, cost, and safe order-reference context; then send a normal checkout request and confirm that it does not create an error event. Test a rate-limit response as well, checking that the retry reuses the same idempotency key and that the request does not block the business path beyond its five-second client timeout. Four attempts is a ceiling, not a promise that an outage will clear.

I initially thought the library choice would dominate the design. The harder part is defining the event contract before the first rollout, because an elegant error inbox still cannot explain a rollback if the candidate cohort and agent timing were never recorded.

Context beats volume.

Rollback first, investigate second. Keep the adapter stable while switching the candidate off, then compare the two cohorts using the same field names. Record the candidate release, its error rate, loop-latency distribution, cost distribution, and exact flag state in the runbook; do not infer any of those measurements from a successful capture response.

Small test. Clear evidence.

References

• https://opentelemetry.io/docs/concepts/signals/logs/
• https://opentelemetry.io/docs/languages/js/getting-started/nodejs/
• https://docs.sentry.io/platforms/javascript/guides/node/
• https://docs.rollbar.com/docs/nodejs
• https://docs.datadoghq.com/logs/log_collection/nodejs/