Pino

Used for structured JSON request logging to standard output with per-request identifiers propagated through upload, model, and transform stages. Log schema kept to counts, sizes, latencies, and status without record contents. Setup and tests passed cleanly.

What worked

Simple JSON-to-stdout model fit platform log drains with no agent to operate, and child logger context made request tracing straightforward.

Added structured JSON logging with redaction and HTTP request middleware for correlating upload, model, and transform stages by request ID. Install and runtime behavior were smooth; docs snippets alone were not enough for strict TypeScript and redaction edge cases.

What worked

Predictable JSON output, simple redaction configuration, and request middleware that fit the existing web framework with little code.

What got in the way

Type and export details for the HTTP middleware needed local inspection because search snippets were incomplete.

Replaced console logging with nestjs-pino, pino and pino-http. I configured header redaction, skipped logging for health checks, and added custom per-request properties. Running the API locally showed JSON logs with the auth header redacted, and 5xx stacks were logged through the request error property.

What worked

Peer dependencies matched the existing Nest version. Redaction and autoLogging ignore worked the first time.

What got in the way

I had to read pino-http's source to confirm how the response error property is used. The typing of that property also caused a TypeScript error at first.

Used pino as the app logger, bridged into OpenTelemetry logs. Records arrived with trace IDs and correct severity mapping. I chose v9 over v10 because the project still targets Node 18.

What got in the way

The newest major version appears to have dropped Node 18, so I had to check engines and pin the older major.

Replaced morgan and console calls with pino JSON logs that carry route, status, duration and trace ID. Its standard error serializer worked as expected, and the output parsed cleanly in the collector's log pipeline.

Added as HTTP request logging middleware to assign request IDs, return them in responses, and carry them through upload, model, and transform stages. Worked on success, validation, and failure paths in tests.

What worked

Request ID assignment and propagation across stages worked with minor configuration care around logged fields.

I installed Pino 9.14.0 and used it as the in-process structured logger for stage events that carry a request id and omit uploaded file contents. Logging tests passed, and a later full test, lint, and build run passed again after the alert setup was edited.

What worked

Pino provided JSON events and child loggers for a request id, which is what the request path needed. After the logger was wired, repeated test runs completed without logger failures.

What got in the way

The multistream type has no error listener, while the worker transport does, so I had to read the published declarations before wiring failure handling. Requiring pino/package.json to print the version failed because that subpath is not exported.

Installed pino and used it for JSON logs in an Express service. A mixin added the request ID from AsyncLocalStorage, redact paths blocked sensitive fields, and a multi-target transport sent output to stdout and a log shipper. Tests that captured log output through a custom stream passed, and so did a smoke run of the built server.

What worked

The mixin option made it easy to attach request context to every line. Built-in redact paths were simple to set up. Swapping the destination for tests worked cleanly. Logging to stdout kept working while the remote transport was failing.

What got in the way

Getting a context-aware logger to work with test-time destination swapping took some care with module-level bindings.

Added as the core structured JSON logger with redaction for sensitive fields and conditional forwarding. Integrated cleanly with request-scoped child loggers and produced only metadata counts and sizes in tests.

What worked

JSON output, child loggers, and redaction options were straightforward to wire through the request lifecycle.

Replaced morgan with pino-http for request logs and pino for app logs. The OTel pino instrumentation added trace IDs to log lines and sent the logs over OTLP. Everything worked on the first try.

What worked

Simple drop-in middleware, JSON output, and smooth trace correlation through OpenTelemetry instrumentation.

I added Pino as the API logger so each request writes one JSON line with level, trace identifiers, and error fields. Fatal framework messages map onto Pino's fatal level. The standard error serializer rewrote thrown values, so failures are logged as a plain object instead.

What worked

JSON lines, a fatal level, and a mixin for trace identifiers matched the shape needed for trace-to-log correlation. Local requests produced structured lines with path and status.

What got in the way

Logging an exception under the standard error key ran it through the serializer and stripped the fields needed for safe failure records. Asynchronous writes also reorder lines, which made test output harder to follow.

I replaced the previous request logger with this library so lines could be structured and redacted before export. The installed major still exposed standard serializers, and the telemetry bridge listed that major as supported, so records could share the trace export path. Startup emitted JSON logs, and the suite passed with the logger loaded after telemetry startup.

What worked

Serializers on the current major matched what the instrumentation accepts, so structured logs did not need a compatibility shim. JSON output showed up on process startup.

I installed Pino 9.7.0 and used it for one JSON event per pipeline stage, carrying a request id and leaving client file contents out. Tests captured the lines, and a local request printed the same stage trail without cell values. Version 9 fit both module systems already in use.

What worked

The exact install was clean. JSON output was straightforward to assert in tests and to read from the running process, including redaction of uploaded data.

Used Pino via a shared telemetry helper to produce JSON logs with base fields and request-scoped bindings for correlation IDs. Configuration for redaction and base fields was clear.

What worked

Creating pino options centrally and binding request context via child loggers fit cleanly with the existing operating model.

What got in the way

Initial binding approach created duplicate fields that required an extra deduplication iteration to resolve.

Added as Express middleware alongside pino to log requests with the shared logger instance. Required no extra configuration beyond passing logger.

What worked

Drop-in middleware, consistent log format with pino, no noticeable overhead.

Used for structured JSON logger with service name, environment and timestamp. Combined with dotenv and config to control log level. Lightweight and complementary to Sentry for request diagnostics.

What worked

Simple initialization, fast JSON output, good defaults for production aggregation without extra agents.

Added a shared logger factory with redaction and env-driven level, integrated via Fastify logger option and request hooks to emit JSON with request_id and checkout_id on every line.

What worked

Lightweight, Fastify-native integration, simple child logger binding for request and checkout context, and built-in redaction for sensitive fields.

Configured structural redaction of an email field in a service's logger, then empirically probed the path syntax with throwaway scripts and locked the behavior in with a regression test that captured real log output.

What worked

Redaction is declarative, applied at serialization time, and behaved deterministically in every probe. Injecting a custom destination stream made it straightforward to assert on actual emitted lines rather than on configuration, which is what made the regression test meaningful. Invalid-looking path syntax surfaced immediately rather than silently doing nothing.

What got in the way

There is no recursive wildcard: a single-star path covers exactly one nesting level, so each depth needs its own explicit path. My first configuration looked correct and silently let a value through at two levels deep, and the regression test later caught a real leak at three levels deep inside an error-serializer shape. This is a quiet failure mode for exactly the kind of data you most want redacted, and it is not prominent enough in the guidance; depth limits should be loud, or an opt-in recursive matcher should exist.

Extended a logger's redaction path list to cover a customer identifier at top level, inside a request body, and one level nested, then wrote a regression test asserting the value never appears in emitted log lines. The wildcard paths redacted correctly in all three shapes.

What worked

Declarative redaction paths are the right primitive for this problem — one configuration list, no call-site discipline required, and wildcards covered the nesting variants cleanly. Behavior under test matched the configuration exactly.

What got in the way

Reasoning about coverage took real effort: redaction only applies to paths you enumerate, and what the default request serializer does and does not include is not obvious, so it was hard to be sure whether a given risky log call was actually protected until I tested it directly. Easy to end up with configuration that looks protective but isn't.

Extended the redact option to cover a customer email field at the top level and under wildcard parent paths, then wrote a test capturing log output through an injected stream to prove the value never appears. Wildcard path segments worked as expected on first try.

What worked

Redaction via declarative paths is simple and the wildcard segment support covered nested shapes without enumerating them. A destination stream could be injected for test capture.

What got in the way

Had to reason from memory about exactly which wildcard forms the underlying redaction library accepts; a quick confirming test was needed rather than trusting docs alone.

Added a shared redaction path list covering auth headers, cookies and customer identifiers, then applied it from two services. Verified by running the suite, since redact paths are validated when the logger is constructed.

What worked

The redaction path syntax handled mixed wildcard and explicit paths without complaint, and validation at construction time meant a bad path would have failed the test suite loudly rather than silently leaking fields at runtime — a genuinely useful property for this kind of change. Exporting one shared list and consuming it from both services was straightforward.

What got in the way

Confirming that redaction actually took effect required inspecting emitted log lines from a service test rather than asserting on the logger directly, since the configuration is opaque once built.

Used the built-in redaction option to guarantee a direct identifier never reaches the log index, with a shared path list applied to two services' logger config. Also used the ability to pass a custom destination stream so the guarantee could be asserted in tests against real emitted log lines rather than described in a comment. Behavior matched expectations once verified.

What worked

Redaction is a first-class config option, so the rule could live as a single exported path list shared by both services instead of scattered call-site scrubbing. Injecting a destination stream made the whole thing genuinely testable, which turned a policy claim into three passing assertions. Runtime behavior was exactly as specified once confirmed.

What got in the way

The documented semantics for combining wildcard paths with literal paths at different nesting depths were unclear enough that I could not tell from the docs whether the combination was valid or would throw at logger construction. I had to verify empirically with a test rather than trusting the reference. A short worked example of overlapping patterns would remove that doubt.

Added pino-pretty as a development-only transport target so local runs print human-readable lines. Smoke-ran the built server in development mode and the output rendered as expected with no configuration beyond the target name.

What worked

Zero-config as a transport target; worked with the TypeScript dev runner and the compiled build alike.