> ## Documentation Index
> Fetch the complete documentation index at: https://docs.molesignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Roll out telemetry for a new service

> Start with one critical request path, preserve useful context, and expand collection only after verifying data quality and cost.

For a new checkout service, start with the path from request entry to payment confirmation. Collect enough evidence to explain a failed or slow request before expanding coverage to every component.

## Agree on the questions first

Choose a small set of operational questions: whether requests succeed, where latency accumulates, and which dependency fails. Associate each question with a signal and a responsible team.

| Question | Recommended evidence | Tradeoff |
| - | - | - |
| Are customers completing checkout? | A business outcome metric and a check of the customer path | Infrastructure availability alone does not establish business success. |
| Which operation is slow? | Traces with stable service names and meaningful Span names | Sampling can omit the particular request under investigation. |
| Why did a request fail? | Structured error logs carrying `trace_id` | Raw request bodies increase volume and can expose sensitive data. |

Use stable service and environment values across signals. Keep request identifiers in logs and traces; avoid using a unique request or customer ID as a metric label because each value combination adds a series.

## Start with a controlled cohort

Use a test environment and synthetic customer data first. Send a successful request, a dependency failure, and a slow request through the same path. Verify that timestamps, identifiers, and field types support investigation across signals.

Connect each source with the guide on [Datasource](https://docs.molesignal.com/en-US/intake#datasource-page): it fills in the endpoint and the token, and **Verify data is arriving** tells whether data arrived in the last hour.

Then enable collection for a small production cohort. Expand after reviewing rejected events, ingestion volume, query latency, and coverage of failures. Define the observation period and acceptance limits before rollout; a quiet interval does not exercise a peak-traffic workload.

## Choose stream boundaries deliberately

Separate log streams when retention, schema, or access requirements differ. Prefer fields for service, environment, and release when those requirements are shared. Avoid creating a stream for every instance or deployment version. See [Design streams and fields that stay useful](https://docs.molesignal.com/en-US/best-practices/stream-design.md).

Keep a field's type stable across producers. MoleSignal rejects incompatible field values with a type mismatch. Test transformations against missing fields, unexpected types, and large messages before attaching a pipeline to production traffic.

Remove secrets at the producer or collector before sending data. Preserve `trace_id` through transformations. Use a new version field to distinguish releases rather than changing field meanings in place.

## Balance retention and investigation coverage

Set retention according to the time needed to discover and investigate failures. Keep high-volume diagnostic logs for a shorter period only when the incident response process can work within that window. Retention cleanup cannot be undone by later increasing the retention period. See [Control telemetry volume and cost](https://docs.molesignal.com/en-US/best-practices/volume-and-cost.md).

When reducing trace collection, verify that logs still retain useful error context. A missing trace may reflect collection or sampling gaps; do not interpret it as proof that the request succeeded.

## Acceptance criteria

* A known failed request can be found in logs and correlated with its captured trace.
* Test events preserve types and identifiers after pipeline processing.
* A representative traffic interval stays within the agreed volume and query-latency limits.
* Sensitive test markers are absent from received telemetry.
* The owning team has a rollback plan for collection and transformation changes.

## Related guides

* [Integration guides](https://docs.molesignal.com/en-US/intake/integrations.md)
* [Streams](https://docs.molesignal.com/en-US/streams.md)
* [Pipelines](https://docs.molesignal.com/en-US/pipelines)
* [Cross-signal correlation](https://docs.molesignal.com/en-US/correlation.md)
* [Design streams and fields that stay useful](https://docs.molesignal.com/en-US/best-practices/stream-design.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.