Node.js App Logging API: Structured JSON with Pino, Winston, and Request IDs

A developer outlined a practical logging pattern for Node.js AI agent workflows that uses Pino or Winston to emit structured JSON completion events, each tagged with request_id, user_id, trace_id, environment, latency_ms, cost_usd, iterations, and status, then ships them to a central ingest API. The approach treats the completed agent loop as the unit of measurement and the request as the unit of investigation, while keeping raw prompts and article text out of routine logs via redaction. The example includes retry handling with exponential backoff on HTTP 429 responses and recommends placing the ingest call behind a durable shipper or queue in latency-sensitive services.

The useful trade-off is signal quality versus noise. TL;DR: in a Node.js app, use Pino or Winston to produce structured JSON logs, then send each completed AI agent run to a central logging API with a request ID and user ID. This gives a small media team a practical view of latency and cost without pretending that a log backend provides traces, alerts, replay, or an archive. Do less first. For an agent that researches a story, calls a model several times, and writes a draft, logging every prompt fragment and intermediate object creates volume without answering the operating question. The completion event should carry the total duration and total model cost for the loop, plus request id , user id , trace id , environment , outcome, and iteration count. Step events are useful when they explain a slow or failed run, but they need the same identifiers or they become isolated lines that nobody can join. Treat the request as the unit of investigation and the completed agent loop as the unit of measurement. A request ID separates retries and concurrent browser requests. A user ID supports product-level investigation, provided it is an internal identifier rather than an email address. A trace ID joins related log records. An environment field prevents a staging run from polluting production searches. The distinction around tracing matters: trace id and span id can be stored as correlation fields, but that does not create a distributed tracing UI or a queryable span tree. Logs can show that three events share an execution. They cannot reconstruct parent-child timing on their own. For the media workflow, the compact completion event might contain agent run completed , latency ms , cost usd , iterations , and status . Cost should be accumulated from the per-call metadata returned by the model surface rather than estimated later from prompt text. Latency should be measured around the whole loop and, when diagnosis requires it, around individual model calls too. Keep raw article text and full prompts out of routine logs; they add noise and may contain reader or newsroom data. This example uses Pino for local structured output and sends the same completion event to the verified central ingest route. In a latency-sensitive service, put ingestLog behind a durable shipper or queue so a logging delay does not extend the article request. The direct call below keeps the network behavior visible and the example runnable: the key comes from the environment, the method is explicit, rate limits back off, and non-success responses retain their real error body. python import pino from "pino"; import { randomUUID } from "node:crypto"; const apiKey = process.env.INFRAI API KEY; const ingestUrl = process.env.INFRAI LOG INGEST URL; if apiKey || ingestUrl { throw new Error "INFRAI API KEY and INFRAI LOG INGEST URL are required" ; } const logger = pino { level: process.env.LOG LEVEL ?? "info", base: { service: "article-agent", environment: process.env.NODE ENV ?? "development", }, redact: "prompt", "article text", "authorization" , } ; type ModelCall = { costUsd: number; latencyMs: number; }; type AgentResult = { status: "ok" | "failed"; iterations: number; calls: ModelCall ; }; type LogEvent = Record<string, string | number ; async function ingestLog event: LogEvent, attempt = 0 : Promise<void { const response = await fetch ingestUrl, { method: "POST", headers: { Authorization: Bearer ${apiKey} , "Content-Type": "application/json", }, body: JSON.stringify event , } ; if response.status === 429 && attempt < 4 { const retryAfter = Number response.headers.get "retry-after" ; const delayMs = Number.isFinite retryAfter ? retryAfter 1 000 : 500 2 attempt; await new Promise resolve = setTimeout resolve, delayMs ; return ingestLog event, attempt + 1 ; } if response.ok { const body = await response.text ; throw new Error Log ingest failed ${response.status} : ${body} ; } } async function runAgent : Promise<AgentResult { return { status: "ok", iterations: 3, calls: { costUsd: 0.0041, latencyMs: 620 }, { costUsd: 0.0068, latencyMs: 940 }, { costUsd: 0.0032, latencyMs: 510 }, , }; } async function handleArticleRequest userId: string : Promise<void { const requestId = randomUUID ; const traceId = randomUUID ; const startedAt = performance.now ; try { const result = await runAgent ; const costUsd = result.calls.reduce sum, call = sum + call.costUsd, 0 ; const event = { event: "agent run completed", request id: requestId, user id: userId, trace id: traceId, latency ms: Math.round performance.now - startedAt , model latency ms: result.calls.reduce sum, call = sum + call.latencyMs, 0, , cost usd: Number costUsd.toFixed 6 , iterations: result.iterations, status: result.status, }; logger.info event ; await ingestLog event ; } catch error { logger.error { event: "agent run failed", request id: requestId, user id: userId, trace id: traceId, latency ms: Math.round performance.now - startedAt , error name: error instanceof Error ? error.name : "UnknownError", } ; throw error; } } await handleArticleRequest "user 7f3a" ; The three numeric call records are sample input, not a benchmark or a vendor price. Replace runAgent with the real loop and populate each call from returned cost and latency metadata. The final event stays stable even if the loop changes from two model calls to six, which is the point: dashboards and searches should depend on the event contract, not the current control flow. For production delivery, assign the event a stable client-generated ID before queueing it so a retry can be deduplicated by the component that owns delivery; do not generate a fresh identity on every attempt. One event, one purpose. Pino and Winston both fit at the application boundary. Pino makes the direct JSON path compact; Winston is a reasonable choice when an existing Node.js service already relies on its formats and transports. Neither choice supplies centralized retention, search, alerting, or tracing by itself. The logger creates the event. A collector and backend determine what happens next. The basic backend requirement is modest: accept structured JSON and search tested fields such as level, request id , user id , trace id , and environment. Infrai fits that narrow job when a small team values one key and one bill across backend services and wants a plain REST surface rather than another vendor-specific SDK. Its public discovery surface describes capabilities, request schemas, response schemas, billing, and runnable examples. The live snapshot exposes 295 capabilities across 20 modules, so the supporting advantage is practical breadth behind the same credential, not a claim that its log search replaces every observability product. Keep the boundary explicit. Search exists, but its filter parameters are not declared in discovery parameters, so an implementation should rely only on filters it has tested and retain a fallback query. There is no distributed trace query or span tree. There are also no built-in alert or notification routes, synthetic checks, source-map deobfuscation, crash symbolication, Electron minidump parsing, or Session Replay. Those gaps change the comparison more than a feature-count table would: | Option | Best role in this design | Important boundary | |---|---|---| | Pino | Emit compact structured JSON from a Node.js process | It is an application logger, not the central backend | | Winston | Preserve an established format-and-transport setup | Central search and retention still belong elsewhere | | Infrai | Basic centralized ingestion and search under one backend key | Correlated log fields do not become full tracing or alerting | | Sentry | Error investigation where grouping behavior matters | Event grouping solves a different problem than agent cost totals | | Prometheus | Metrics with deliberate names and aggregation semantics | Metrics do not retain the request-level narrative of a log event | | Datadog | A broad managed observability workflow | More surface area and vendor-specific setup than basic log search requires | | Grafana | Explore logs alongside metrics in an established Grafana stack | The team still has to choose and operate the underlying data sources | | Better Stack | Managed log search and incident-oriented workflows | It adds another dedicated service, key, and billing relationship | | Healthchecks | Detect a scheduled job that never ran | It covers heartbeat-style silence, not general log exploration | This is why “one observability tool” is usually the wrong target for a solo builder. A quiet stack can have three narrowly assigned parts: structured logs for request investigation, metrics for aggregate rates and distributions, and a heartbeat monitor for the silent failure of a scheduled publishing job. Add Sentry when error grouping and application error investigation justify another system. Each signal then earns its ingestion volume. The trade-off is deliberate. There is a governance limit as well. The centralized logging capability has no per-user deletion API, bulk export or subscription API, or visible retention and cold-storage controls. A media product with GDPR deletion obligations or long-term archive requirements should send the same sanitized events through a separate pipeline whose deletion, export, and retention behavior is explicit. Do not wait for a deletion request to discover that user id is scattered through an operational store. Start with two saved investigations, even if the backend expresses them differently. One finds a request by request id and returns all events in time order. The other narrows production completion events to a tested user or trace field and looks for high latency or unusual cost. Because search parameters are not declared in discovery, confirm each field filter against real ingested test events before making it an operational dependency. When a filter is unavailable, fall back to the broadest supported query and filter the returned structured records in the application. Avoid turning every field into a dimension. request id and trace id are excellent lookup keys in logs, while aggregate metrics should use bounded labels such as environment, status, or agent version. Prometheus naming guidance is relevant here: metric names should describe the measured quantity and use base units. A log field named latency ms is readable in an event; a metric intended for aggregation should follow the metric system's naming and unit conventions instead of copying the log schema blindly. Sampling needs the same restraint. Keep failures and completed-loop summaries. Sample repetitive step-level success events only after confirming they are not required for billing reconciliation or a support workflow. Never sample by dropping all slow events; that removes the evidence needed to explain the tail. Before release, run one known request in each environment and verify that the same request id finds its start, relevant steps, completion, or failure. Check that the completion event's accumulated cost equals the call metadata and that whole-loop latency is greater than or equal to the time spent in model calls. Trigger a controlled exception and confirm that its event contains identifiers but no prompt, article body, authorization value, or direct personal data. Then test the surrounding systems, not just the happy path. Confirm the log shipper can buffer during a short backend interruption, set an explicit retention policy in the pipeline that owns retention, and exercise the separate heartbeat monitor for scheduled work. Document which searches are verified because undeclared filters should never become tribal knowledge. Short checklist, hard evidence. The decision rule is simple: use centralized structured logs when the question is “what happened to this agent run, how long did it take, and what did its model calls cost?” Add metrics when the question is aggregate behavior, Sentry when grouped application errors are the work queue, and Healthchecks when absence itself is the failure. If the requirement is span-tree analysis, replay, automatic notifications, per-user erasure, or archival export, choose a dedicated system for that requirement rather than stretching basic log search past its boundary.