Logging and Observability

Logs record events, metrics aggregate behavior, and traces connect operations across request boundaries. Structured logs with timestamp, severity, event name, and request identifier are easier to filter than random console strings. Do not log passwords or tokens; monitoring also needs meaningful error rates and latency measurements.

The logger emits a structured JSON record that could be ingested by a log collector. A production implementation would add an actual timestamp and safely filter sensitive properties.

An HTTP 200 status does not tell you if a service is healthy under load; combine logs with metrics, traces, and alert thresholds.

This source was compiled using TypeScript 5.8.3 with strict checking, then executed with Node.js 22.16.0. Its stdout below is the actual captured output. The core logic is runnable without a framework or a remote API; integration-specific examples appear in a separate lab when needed.

TypeScript source

type LogEvent = { level: "info" | "error"; event: string; requestId: string; durationMs: number };
function log(event: LogEvent): string { return JSON.stringify(event); }
console.log(log({ level: "info", event: "task.created", requestId: "req-42", durationMs: 18 }));

Verified output

{"level":"info","event":"task.created","requestId":"req-42","durationMs":18}

Compile: npx tsc --strict --target es2022 --module commonjs logging-observability.ts; run: node logging-observability.js. For examples importing node: modules, install @types/node as a development dependency; for browser or React projects use the separate lab setup.

The logger emits a structured JSON record that could be ingested by a log collector. A production implementation would add an actual timestamp and safely filter sensitive properties.

Before editing the code, predict what the output will be for one changed input. Run it and compare your prediction with the actual result.

An HTTP 200 status does not tell you if a service is healthy under load; combine logs with metrics, traces, and alert thresholds.

Determine whether the issue belongs to the type system, a trust boundary, or actual runtime behavior before choosing a correction.

Add a field describing a success or failure outcome; write a rule that excludes secrets from logging.

Record expected success and failure outcomes, run the code, and compare the observed behavior. Keep the exercise compatible with strict type checking.

The logger emits a structured JSON record that could be ingested by a log collector. A production implementation would add an actual timestamp and safely filter sensitive properties.

Apply the same reasoning to the practice task, then integrate it into a real app only when the runtime and dependency setup are ready.