sentry-instrumentation-guide

Match the signal to the question it answers: spans show where time went in a request, logs record the state and reasoning at a decision point, and metrics track rates and trends over time. The skill provides a decision table mapping common questions to the right signal.

Use a span attribute for context about one request's flow that you read inside a trace, and a metric for a standalone value you want to chart, alert on, or slice across all requests. The same value can legitimately be emitted as both.

No. Deriving a rate by counting log lines means storing every line just to compute a number a metric emits directly and cheaply. Emit the metric for the aggregate and the log when you also need to reconstruct individual requests.

No. This skill decides what to emit, not how to configure the SDK. For setup, it hands off to the platform-specific sentry-*-sdk skills such as sentry-python-sdk or sentry-nextjs-sdk, which cover init flags and API signatures.

Traces are sampled because a representative slice is enough to understand where time goes. Logs are filtered rather than sampled because their purpose is finding the one rare request that went wrong, which sampling could discard.