Trace Generated Microservices with OpenTelemetry

Start services and their telemetry infrastructure

Use the generated Compose environment and the observability settings in its configuration. The endpoint URLs and exposed ports are defined by your project. Confirm that tracing is enabled before sending a request.

Open the trace backend and Grafana addresses listed in the generated README. The dashboard provisioning guide explains how service dashboards are mounted.

make docker-up

Send a sampled request

Use the endpoint schema for the request body. A sampled W3C traceparent supplies a distributed parent; the Service Architect x-trace marker can explicitly request tracing. Generate a fresh trace identity for each investigation rather than reusing one trace ID across unrelated requests.

Keep request IDs, graph correlation IDs and distributed trace IDs distinct. Use the actual response or trace backend to identify the request you sent.

Follow the causal path through the graph

Find the HTTP input, Inventory RPC boundary, graph transformations and any error or timeout branch. Match service ownership and parent-child relationships. Concurrent branches can appear in different timestamp orders while preserving the required causal order.

A disabled or unsampled trace does not become observable merely because the graph exists. Check sampling, exporter configuration and backend reachability before interpreting missing spans as missing execution.

Use Grafana to explain pressure and latency

Use HTTP server metrics for traffic, gRPC client metrics for outbound calls and task pool metrics for queue pressure.

For Rust, Tokio runtime monitoring describes the generated scheduler metrics. For Node.js, use the TypeScript runtime dashboard. Metric availability depends on the selected runtime and enabled backend.

Next steps

Request → trace identity → service and operator spans → metrics → graph node

Related documentation