Choose and implement the right Sentry signal: errors, spans, attributes, logs, or metrics.
---
name: sentry-instrumentation-guide
description: Decide which Sentry signal to reach for when instrumenting code — error, span, span attribute, log, or metric. Use when adding instrumentation and unsure whether something should be a log vs a span vs a metric, when deciding "what to instrument where", when reviewing instrumentation for gaps, or when a coding agent needs a rule for choosing between errors, traces, logs, and metrics. This skill decides WHAT to emit; the sentry-*-sdk skills handle HOW to set each pillar up.
license: Apache-2.0
category: feature-setup
parent: sentry-feature-setup
disable-model-invocation: true
allowed-tools: Read, Grep, Glob
---
> [All Skills](../../SKILL_TREE.md) > [Feature Setup](../sentry-feature-setup/SKILL.md) > Instrumentation Guide
# Sentry Instrumentation Guide: When to Reach for What
Errors, traces, logs, and metrics are the four kinds of telemetry most apps run on, and they
overlap enough that the choice is rarely obvious. You can stuff context into a span attribute
instead of logging it. You can count log lines instead of emitting a metric. You can add a
duration to a log and call it a span.
But each signal exists because it answers a **different question** and feeds a **different
workflow** once it lands. Reaching for the wrong one means the data is technically there but
useless for the job you actually have later. This skill is the decision framework: given a value
or an event in front of you, which signal should carry it, and why.
It decides **what** to emit. For **how** to turn each pillar on for a given stack, hand off to the