Backend / Observability / 01_sentry.md

Sentry

Updated 5 interview angles 4 min read source
On this page8
  1. Grouping, and how to break it
  2. Releases are what make it actionable
  3. Context beats verbosity
  4. PII: on by default in the ways that matter
  5. Sampling and cost
  6. What it is not
  7. Related
  8. Interview angle

Sentry

Error tracking. It captures an exception with its stack trace, request context and release, then groups repeated occurrences into one issue you can prioritise by frequency and users affected.

That grouping is the product. Without it you have a log of a million tracebacks; with it you have twelve issues ranked by impact.

python 
import sentry_sdk

sentry_sdk.init(
    dsn=os.environ["SENTRY_DSN"],
    environment=os.environ["ENV"],
    release=os.environ["GIT_SHA"],
    traces_sample_rate=0.1,
    send_default_pii=False,
)

The integrations do the wiring — Django, FastAPI, Celery and friends hook themselves in, so unhandled exceptions arrive with the request, the user and the transaction already attached.

Grouping, and how to break it

Sentry fingerprints an event from the stack trace and exception type. Events with the same fingerprint become one issue.

It goes wrong when a dynamic value ends up in the message:

python 
# Every user id makes a new issue
raise ValueError(f"No account for {user_id}")

# One issue, with the id as searchable context
sentry_sdk.set_context("account", {"user_id": user_id})
raise ValueError("No account for user")

The symptom is thousands of issues with one event each, which nobody triages. When the default is wrong you can set the fingerprint explicitly:

python 
sentry_sdk.set_tag("provider", name)
scope.fingerprint = ["{{ default }}", name]

Grouping too coarsely is the opposite failure — three unrelated bugs under one issue, where fixing one closes it and hides the others.

Releases are what make it actionable

python 
release=os.environ["GIT_SHA"]

With a release set, Sentry tells you which deploy introduced an error and marks it regressed if it comes back. Without one, every error is undated and “is this new?” becomes a manual investigation.

Upload source maps for JavaScript and debug symbols for compiled languages in CI, tagged with the same release, or the stack traces are minified noise.

Context beats verbosity

Mechanism Use for Searchable
Tags low-cardinality facets yes, indexed
Context structured detail no
Breadcrumbs what happened before no
User who hit it yes

Tags are for things you filter by — provider, plan, region. The same cardinality discipline as metrics applies: a tag per user id is not a facet, it is a leak.

Breadcrumbs are the underused one. They are the trail of events leading to the error — queries, HTTP calls, log lines — and they usually answer “what was this request doing” faster than the stack trace does.

PII: on by default in the ways that matter

Error trackers accumulate personal data fast. Request bodies, headers, querystrings and local variables all routinely contain it.

  • send_default_pii=False — do not attach user IP and cookies automatically.
  • before_send — scrub or drop events in code, which is the only reliable place to strip a bespoke field.
  • Server-side scrubbing as a second layer, because a client can be misconfigured.
python 
def before_send(event, hint):
    req = event.get("request", {})
    req.pop("cookies", None)
    if "data" in req:
        req["data"] = "[redacted]"
    return event

Under GDPR the retention window is also a decision, not a default.

Sampling and cost

Errors are usually captured at 100% — you want all of them. Traces are not: traces_sample_rate=1.0 in production is a large bill and a large amount of noise. Start at 0.1 and use a sampler function to keep 100% of errors and slow requests while sampling the rest.

What it is not

Not a metrics platform and not a log store, despite overlapping with both. Ask it “how many 500s per second” and you are using the wrong tool — that is Prometheus. Sentry answers “which exception, in which release, hitting how many users, with what stack”.

Interview angle 5

  • “What is Sentry for, and what isn’t it?” - error tracking: aggregating exceptions with stack traces, request context and release information so you can prioritise by impact. It’s not a metrics or logging platform, though it now overlaps with tracing.
  • “Why does grouping matter?” - it turns thousands of events into a handful of issues ranked by frequency and users affected. Bad grouping - usually from dynamic values in the message - produces noise nobody triages.
  • “How do you avoid leaking PII?” - scrub sensitive fields before send, disable default PII capture, and be deliberate about request bodies and headers. Error trackers accumulate personal data quickly if left on defaults.
  • “Why set a release?” - it ties an error to the deploy that introduced it and lets Sentry mark regressions. Without it every error is undated, and source maps have nothing to attach to, so JavaScript traces stay minified.
  • “Would you sample?” - errors no, traces yes. Full trace sampling in production is expensive and noisy; a sampler that keeps every error and every slow request while sampling the rest gets the signal at a fraction of the cost.