Skip to content

Sentry.md

Latest commit

 

History

History
96 lines (66 loc) · 7.96 KB

Sentry.md

File metadata and controls

96 lines (66 loc) · 7.96 KB
Raw

← Оглавление

Sentry

Sentry — сервис отслеживания ошибок: перехватывает необработанные исключения в работающем приложении и присылает их разработчику вместе со стектрейсом, значениями переменных, данными запроса и пользователем, у которого это случилось.

Разница с логами принципиальна. Лог — это поток строк, в котором ошибку надо найти. Sentry сам ловит исключение, группирует одинаковые в одну проблему со счётчиком, показывает, когда она появилась и сколько людей задела. Вместо «пользователь пишет, что не работает» — «KeyError: 'email' в checkout.py:88, 412 раз за час, началось после релиза 2.3.1».

Что именно он даёт

  • Ошибки — необработанные исключения с полным стектрейсом и локальными переменными на каждом кадре.
  • Группировка — тысяча одинаковых падений сворачивается в одну запись (issue) со счётчиком и списком затронутых пользователей.
  • Контекст — URL и параметры запроса, версия релиза, окружение, id пользователя, «хлебные крошки» (что происходило до падения).
  • Трейсинг — распределённые трассировки и время шагов запроса: похоже на APM, дополняет трейсы.
  • Регрессии — если закрытая проблема появилась снова, Sentry заведёт её заново и пометит как регрессию.

Подключение

pip install "sentry-sdk"

Инициализация — как можно раньше при старте приложения:

import sentry_sdk

sentry_sdk.init(
    dsn="https://<ключ>@<организация>.ingest.sentry.io/<проект>",
    environment="production",     # разделить прод и стейдж
    release="myapp@2.3.1",        # привязать ошибку к версии
    traces_sample_rate=0.1,       # доля запросов под трейсинг: 0.1 = 10%
    send_default_pii=False,       # НЕ слать IP и заголовки пользователя
)
  • dsn — адрес проекта в Sentry, единственный обязательный параметр. Живёт в переменных окружения, не в коде.
  • environment — иначе ошибки со стейджа смешаются с боевыми.
  • release — без него не будет ответа на главный вопрос «после какого релиза началось».
  • traces_sample_rate — 1.0 на проде дорого и шумно; берут 0.05–0.2.
  • send_default_pii — включает сбор персональных данных (IP, заголовки, тело запроса). По умолчанию выключен, и включать его надо осознанно.

Фреймворки подхватываются автоматически: Django, FastAPI, Flask, Starlette, Celery и другие — SDK сам находит установленную библиотеку и вешает свои обработчики. Отдельно настраивать перехват исключений во view не нужно.

Ручная работа

Иногда ошибку хочется отправить самому — например, поймал исключение, обработал, но знать о нём всё равно надо:

import sentry_sdk

try:
    списать_деньги(order)
except PlatformError as e:
    order.status = "retry"
    sentry_sdk.capture_exception(e)      # обработали, но зафиксировали

sentry_sdk.capture_message("странный формат ответа банка", level="warning")

sentry_sdk.set_user({"id": user.id})     # кто это был
sentry_sdk.set_tag("тариф", "premium")   # по чему потом фильтровать

Для своих измерений времени — sentry_sdk.start_transaction() и sentry_sdk.start_span().

Ловушки

Шум убивает пользу. Если в Sentry летит всё подряд, на уведомления перестают смотреть, и настоящая авария теряется. Ожидаемые ошибки (валидация формы, 404) надо отфильтровывать через ignore_errors или before_send.

Утечка персональных данных. В стектрейс попадают локальные переменные — а там пароль из формы, токен, номер карты. Чувствительные значения вычищают в before_send, а send_default_pii оставляют выключенным. Это ещё и требование закона о персональных данных.

Sentry не заменяет метрики. Он показывает факт падения, но не расскажет, что сервис отвечает за 3 секунды, не падая. Для этого нужны метрики. Здоровая связка: метрики — «что-то не так», трейсы — «на каком шаге», логи и Sentry — «почему именно».

Место в наблюдаемости

Метрики (Prometheus)  →  «латентность выросла в 3 раза в 14:20»
Трейсы                →  «медленный шаг — запрос к платёжному сервису»
Sentry / логи         →  «TimeoutError в payments.py:64, 812 раз»

Связи

Источники