Expert guidance for configuring and deploying the OpenTelemetry Collector. Use when setting up a Collector pipeline, configuring receivers, exporters, or processors, deploying a Collector to Kubernetes or Docker, or forwarding telemetry to Dash0. Triggers on requests involving collector, pipeline, OTLP receiver, exporter, or Dash0 collector setup.
95
93%
Does it follow best practices?
Impact
96%
1.39xAverage score across 12 eval scenarios
Advisory
Suggest reviewing before use
FinPay Ltd. is launching a payment processing API built with Node.js and Express. The service is a CommonJS application that handles credit card payments on behalf of merchants. Before going to production, the engineering team needs to add OpenTelemetry instrumentation so the operations team can monitor request latency, detect errors, and correlate logs to traces during incidents.
The service already has a basic Express app (app.js) and runs behind an OpenTelemetry Collector that listens on gRPC at port 4317. The team wants traces, metrics, and logs all exported via OTLP. The collector endpoint is http://otel-collector:4317. Authentication is handled by a pre-existing environment variable OTEL_AUTH_TOKEN.
Because FinPay processes credit card payments, the team is especially concerned about accidentally leaking sensitive data (card numbers, auth tokens, user emails) into the telemetry pipeline. Request URLs may contain session tokens as query parameters, and log statements must not expose raw authorization headers or card data.
The codebase contains three HTTP routes that need proper instrumentation:
POST /api/payments — initiates a payment; may return 400 (invalid request), 402 (insufficient funds), or 500 (processor unavailable)GET /api/payments/:paymentId — retrieves a payment record; returns 404 if not foundDELETE /api/payments/:paymentId/cancel — cancels a pending paymentThe team also needs proper error handling so that if the Node.js process crashes unexpectedly, any in-flight telemetry is flushed to the backend before the process exits.
Produce the following files in your working directory:
instrumentation.js — OpenTelemetry SDK setup and initialization code that can be loaded before the app.env.local — Environment variable configuration for running the instrumented service locallypayment-handlers.js — Example implementation of the three route handlers above, with correct span status handling, exception recording (using structured log records), sensitive data sanitization, and trace-log correlationpackage.json — Package manifest listing the required OTel dependencies and npm scripts to run the instrumented appThe files should be self-consistent and runnable (or near-runnable) without additional input. Placeholder values are acceptable for the OTLP endpoint and auth token where real values are not available.