Sentry. 20 минут даунтайма из-за отсутствия error tracking, РФ-аналоги, 152-ФЗ, санкции и связь с Service Desk

Что случилось

3 мая 2026, 09:14 по Москве. Я делал тюнинг Valkey на собственном VPS. Добавил io-threads=2 в valkey.conf, перезапустил сервис. Через 30 секунд 77 из 82 публичных страниц сайта возвращали 500 Internal Server Error. Узнал я об этом через 10 минут, когда открыл сайт сам, чтобы проверить, что всё штатно.

Если бы у меня стояло error tracking, я узнал бы за 30 секунд. Алерт бы пришёл в Telegram до того, как первый клиент успел увидеть 500-ю. Это RCA не про Valkey. Это про то, почему я ставлю error tracking в первый деплой, а не в третий.

Пост для CIO и CTO, которые откладывают наблюдение «до реального трафика». Внутри живой ход событий, цифры стоимости простоя, сравнение Sentry с альтернативами (российский Hawk от CodeX, OSS-GlitchTip и SigNoz), разбор 152-ФЗ и санкций, рецепт установки на 10 минут и связка с Service Desk по ITIL.

Контекст

VPS Timeweb, Debian 13, multi-tenant. WordPress + Roundcube webmail + несколько вспомогательных сервисов на одном сервере. Я веду его сам. Держу руку на пульсе и обкатываю на нём всё, что потом несу клиентам.

Стек кэширования двухслойный. Первый слой это WP Super Cache, он складывает готовый HTML в файлы и отдаёт через nginx минуя PHP. Второй слой это WP Redis Object Cache, встраиваемый модуль ядра (drop-in) wp-content/object-cache.php от Till Krüss. Он хранит результаты get_option() и SQL-запросов в Valkey, чтобы PHP не дёргал MariaDB на каждом хите.

Drop-in при старте читает state из Valkey. Если Valkey пустой или недоступен, drop-in кидает fatal в PHP. WordPress без drop-in отдал бы 500 на ВСЕХ страницах. Но WP Super Cache независимо от PHP отдавал HTML-файлы пяти страниц, которые были закэшированы за минуту до restart (главная, /uslugi/, /o-kompanii/, /contacts/ и одна посадочная). Поэтому 5 работали, 77 нет.

Эта деталь важна для понимания, почему я не заметил инцидент сразу. Главная отдавала 200, я открыл её для быстрой проверки после restart Valkey, увидел нормальный ответ и пошёл дальше. RCA ниже про это.

Реальный timeline без error tracking

Что Sentry показал бы за 30 секунд

Перепроиграю timeline в альтернативной вселенной, где Sentry (или GlitchTip, что для этого сценария идентично) стоит и подключён.

Это та же информация, что я собирал руками 9 минут. Читал логи, пробивал URL, прогонял curl-цикл. Sentry даёт это в один клик.

Почему я не поставил Sentry заранее

У меня было три отговорки. Все рационализации, не причины.

Отговорка 1. «Pre-launch, нет трафика». На этом сайте трафик небольшой (50–200 посетителей/день), и я решил, что error tracking нужен «когда станет больше». На деле стоимость одного клиента в B2B-нише с чеком 30–100 тыс ₽ оправдывает наблюдение за каждой 500-й даже на пяти посетителях в день.

Отговорка 2. «Тяжёлый по ресурсам, нагрузит сервер». Я думал, что Sentry требует много памяти. Это правда для полного Sentry self-host. Официальные требования репозитория getsentry/self-hosted это 4 ядра CPU, 16 ГБ RAM плюс 16 ГБ swap, рекомендовано 32 ГБ. Но GlitchTip требует 256 МБ. Это совместимая замена под те же Sentry SDK, код приложения не меняется. На любом VPS от 1500 ₽/мес он помещается рядом с приложением без боли.

Отговорка 3. «Сложно настроить». Установка GlitchTip через docker compose занимает 10 минут. Подключение к Next.js это 7 строк. Подключение к PHP 4 строки. Это меньше, чем я потратил на recovery.

Все три отговорки это классическая ловушка приоритезации. Я ставил «как удобно», а должен был ставить «как надёжно». Наблюдение стоит пары часов и пары сотен МБ RAM. Отсутствие наблюдения стоит потерянных посетителей и подорванного доверия.

Альтернативы Sentry. Таблица

В 2026 году Sentry SaaS для российских компаний практически закрыт. Серверы Sentry в США и Европе нарушают локализацию 152-ФЗ (см. секцию ниже). Stripe не принимает российские карты, а оплата через зарубежное юрлицо это серая зона. Sentry self-host технически работает, но лицензия FSL 1.1 не FOSS, а source-available.

Поэтому я разделил решения на два сегмента, для малой команды и для среднего/крупного бизнеса. Сравнение собрано из research-отчёта 21 мая 2026 с проверкой по официальным репозиториям. Цены актуальны на момент публикации.

Сегмент SMB (1–50 разработчиков, до 1М events/день)

Сегмент Mid/Large (50+ разработчиков, миллионы events/день)

Поправка про Sentry лицензию. До 2024 года Sentry был на BSL (Business Source License), что часто называли «не FOSS, нельзя трогать». С 2024 Sentry перешёл на Functional Source License 1.1, где каждая версия через 2 года автоматически становится Apache 2.0. Self-host для внутреннего использования разрешён. Запрещено только предлагать конкурентный SaaS на их коде. Источник смотрите в LICENSE.md в репозитории.

152-ФЗ и где хранятся данные

Sentry собирает по умолчанию больше данных, чем кажется. В типичный event попадает IP-адрес посетителя, user-id (если вы передаёте), цепочка последних действий пользователя (breadcrumbs), заголовки запроса, query-параметры URL, иногда тело запроса. Всё это персональные данные по 152-ФЗ.

Ключевую норму задаёт статья 18 часть 5 закона 152-ФЗ. Она требует, чтобы при сборе ПДн граждан РФ запись, систематизация, накопление, хранение, уточнение и извлечение этих данных проводились с использованием баз данных, находящихся на территории РФ. Полный текст закона лежит на consultant.ru, нужный пункт ищите в статье 18 части 5.

Sentry SaaS хранит данные в США (us.sentry.io) или Германии (de.sentry.io). Для приложения с российскими пользователями это формальное нарушение. Self-hosted Sentry или GlitchTip в РФ-датацентре закрывает требование. У CodeX есть российский лендинг hawk-tracker.ru, на нём прямо заявлено хранение данных в РФ («храним данные в РФ, не передаём за рубеж») и соответствие 152-ФЗ. Для оператора ПДн это рабочий вариант без выноса данных за рубеж. Перед прод-выбором запросите у вендора письменное подтверждение локализации и договор-поручение на обработку по ст. 6 ч. 3 152-ФЗ.

Дополнительно с 30 мая 2025 действует ФЗ-420 от 30 ноября 2024 года, который ужесточил ст. 13.11 КоАП. Важно не валить разные составы в одну строку, суммы у них сильно отличаются. Для юрлица актуальные размеры такие.

• 100–300 тыс ₽ за неуведомление Роскомнадзора о начале обработки ПДн (ч. 10 ст. 13.11).
• 300–700 тыс ₽ за обработку без письменного согласия субъекта (ч. 2), при повторном нарушении 1–1,5 млн ₽ (ч. 2.1).
• 1–6 млн ₽ за нарушение локализации, то есть хранение ПДн граждан РФ вне РФ (ч. 8), а при повторе 6–18 млн ₽ (ч. 9). Это и есть тот самый состав, под который попадает дефолтный SaaS Sentry в США или Германии.
• 1–3 млн ₽ за несообщение об утечке (ч. 11), а за саму утечку штрафы доходят до миллионов с оборотными составами при повторе. Отдельная тема, error tracking сюда попадает только если из него утекут собранные ПДн.

Источники по составам и суммам это КонсультантПлюс и текст ст. 13.11 КоАП.

Практический вывод. Если вы внедряете error tracking как оператор ПДн в РФ, нужно (1) уведомлением в РКН отразить обработку через Sentry/GlitchTip/Hawk как отдельный процесс, (2) выбрать self-host в РФ или российский SaaS с локализацией в РФ (Hawk через hawk-tracker.ru заявляет такое хранение), (3) настроить чистку персональных данных в коде. Это разовая работа на 1–2 дня, экономия штрафов до миллионов рублей.

Санкции и план Б

Sentry Inc. это компания из Сан-Франциско. На середину 2026 года она формально не отказала российским клиентам, но риск блокировки актуален. Atlassian (Jira, Confluence), Datadog, NewRelic, Slack уже закрыли доступ для российских клиентов в 2022–2024 годах. Sentry в любой момент может присоединиться.

Второй риск. Оплата. Sentry SaaS принимает оплату через Stripe. Stripe не работает с российскими картами с 2022 года. Обход через зарубежное юрлицо технически возможен, но это серая зона.

Третий риск. Docker images. Были прецеденты частичных блокировок Docker Hub для российских IP в 2022–2023 (правда, быстро откатили). Для self-host Sentry это значит, что download образов в один прекрасный день может перестать работать.

Российские облака как полный аналог Sentry на 2026 год не выработались. Yandex Cloud Monitoring предлагает Traces, Logs и Metrics как отдельные продукты, но интерфейса для группировки ошибок по stack-trace на уровне Sentry там нет. VK Cloud и Selectel предлагают только базовые metrics+logs. Hawk от CodeX ближе всего к Sentry-аналогу и не зависит от санкций. Российский лендинг hawk-tracker.ru заявляет хранение данных в РФ, есть и self-host (BSL 1.1, source-available).

GlitchTip за 10 минут на том же VPS

Это рабочий рецепт для SMB. Я использую его на новых клиентских проектах. По официальному пути надо взять их compose.sample.yml из документации. Ниже мой обрезанный вариант для одного VPS, его проще читать в посте. Допущения. Один VPS с Debian/Ubuntu, Docker и Docker Compose установлены, домен errors.example.ruнаправлен на этот VPS, nginx с Let's Encrypt уже настроен.

bash
# Шаг 1. Создать рабочую директорию
mkdir -p /opt/glitchtip && cd /opt/glitchtip

# Шаг 2. Сгенерировать секреты
SECRET_KEY=$(openssl rand -hex 50)
DB_PASS=$(openssl rand -hex 24)

# Шаг 3. docker-compose.yml — минимальная all-in-one конфигурация
cat > docker-compose.yml <<EOF
services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_USER: glitchtip
      POSTGRES_PASSWORD: ${DB_PASS}
      POSTGRES_DB: glitchtip
    volumes: [pgdata:/var/lib/postgresql/data]
    restart: unless-stopped

  redis:
    image: valkey/valkey:8.0-alpine
    restart: unless-stopped

  web:
    image: glitchtip/glitchtip:latest
    depends_on: [postgres, redis]
    environment:
      DATABASE_URL: postgres://glitchtip:${DB_PASS}@postgres:5432/glitchtip
      SECRET_KEY: ${SECRET_KEY}
      EMAIL_URL: smtp://localhost:25
      GLITCHTIP_DOMAIN: https://errors.example.ru
      DEFAULT_FROM_EMAIL: errors@example.ru
    ports: ["8000:8000"]
    restart: unless-stopped

  worker:
    image: glitchtip/glitchtip:latest
    depends_on: [postgres, redis]
    environment:
      DATABASE_URL: postgres://glitchtip:${DB_PASS}@postgres:5432/glitchtip
      SECRET_KEY: ${SECRET_KEY}
    command: ./bin/run-celery-with-beat.sh
    restart: unless-stopped

volumes:
  pgdata:
EOF

# Шаг 4. Запустить
docker compose up -d

# Шаг 5. Создать первого админа
docker compose exec web ./manage.py createsuperuser

После шага 5 открываете https://errors.example.ru в браузере, логинитесь, создаёте проект, копируете DSN из настроек проекта и сохраняете его в переменную окружения приложения как SENTRY_DSN. Готово.

Расход ресурсов на проде. На моём VPS GlitchTip all-in-one занимает 280 МБ RAM в покое и до 450 МБ под нагрузкой в 100 events/мин. CPU держится в пределах 1-3% на 4 ядрах. Диск PostgreSQL под GlitchTip растёт примерно 50 МБ на 100 тыс events. Для личного проекта этого хватает с запасом на годы.

Подключение Next.js, FastAPI, PHP, 1С

Дальше я покажу, как подключить error tracking к четырём типичным стекам. Везде используется DSN от GlitchTip (формально это SENTRY_DSN, обратная совместимость с Sentry полная).

Next.js (App Router, версия 15+)

bash
pnpm add @sentry/nextjs

# Запустить интерактивный wizard, который создаст sentry.client.config.ts,
# sentry.server.config.ts, sentry.edge.config.ts и обновит next.config.ts:
npx @sentry/wizard@latest -i nextjs

Wizard просит DSN, имя проекта, разрешение на загрузку source-maps. После него в коде ничего не нужно. Ошибки на сервере и в клиенте отправляются автоматически. Для ручной отправки события:

typescript
import * as Sentry from "@sentry/nextjs";

try {
  await chargeCustomer(input);
} catch (error) {
  Sentry.captureException(error, {
    tags: { feature: "billing", env: "prod" },
    user: { id: session.userId },
  });
  throw error;
}

Ключевая фича для Next.js это source-maps. Без них stack-trace в проде показывает минифицированный код. Wizard включает их по умолчанию через withSentryConfig в next.config.ts. Проверьте, что в CI на каждый deploy уплывает release-тэг это позволяет фильтровать события по версии и быстро локализовать регрессию.

FastAPI (Python 3.11+)

bash
pip install sentry-sdk[fastapi]

python
# app/main.py
import sentry_sdk
from sentry_sdk.integrations.fastapi import FastApiIntegration
from sentry_sdk.integrations.starlette import StarletteIntegration

sentry_sdk.init(
    dsn=os.environ["SENTRY_DSN"],
    environment=os.environ.get("APP_ENV", "dev"),
    release=os.environ.get("GIT_SHA", "unknown"),
    integrations=[
        StarletteIntegration(),
        FastApiIntegration(),
    ],
    traces_sample_rate=0.1,  # 10% запросов в performance traces
    send_default_pii=False,  # 152-ФЗ minimization
    before_send=lambda event, hint: scrub_pii(event),
)

def scrub_pii(event):
    # Маскирует cookies и Authorization в request.headers
    if "request" in event and "headers" in event["request"]:
        for key in ["cookie", "authorization", "x-csrf-token"]:
            event["request"]["headers"].pop(key, None)
    return event

PHP (Laravel/Symfony/чистый PHP)

bash
composer require sentry/sentry

php
<?php
\Sentry\init([
    'dsn' => $_ENV['SENTRY_DSN'],
    'environment' => $_ENV['APP_ENV'] ?? 'dev',
    'release' => $_ENV['GIT_SHA'] ?? 'unknown',
    'send_default_pii' => false,
    'before_send' => function (\Sentry\Event $event): ?\Sentry\Event {
        $request = $event->getRequest();
        unset($request['cookies']);
        unset($request['headers']['cookie']);
        $event->setRequest($request);
        return $event;
    },
]);

Для WordPress есть плагин WP Sentry от Stayallive. Он оборачивает wp-config.php и ловит fatal errors, warnings и notices. Я поставил его после инцидента. Установка занимает 5 минут.

1С (через HTTP-сервис)

Нативного Sentry SDK для 1С нет, но есть рабочая схема через HTTP-сервис, опубликованный на Apache + 1С Web-сервер. В серверном коде 1С ловите исключения и шлёте POST на envelope endpoint. Важная деталь, на которой спотыкаются. Свежий GlitchTip принимает события только в формате Sentry envelopes на URL /api/<project>/envelope/, а не на старый /store/. Конверт начинается с JSON-заголовка, затем идут элементы, разделённые переводом строки. Заголовок конверта с event_id и dsn, заголовок элемента {"type":"event"}, затем сам JSON события. Для простого события с одним элементом это фактически три строки. Формально это не строгий NDJSON. Полезная нагрузка не обязана быть однострочной, см. спецификацию по ссылке. Content-Type здесь application/x-sentry-envelope.

bsl
Процедура ОтправитьОшибкуВSentry(ИнформацияОбОшибке) Экспорт
    DSN = ПолучитьDSNИзНастроек(); // https://<key>@errors.example.ru/<project>
    EventId = СтрЗаменить(Строка(Новый УникальныйИдентификатор), "-", "");

    // Сам объект события
    Событие = Новый Структура;
    Событие.Вставить("event_id", EventId);
    Событие.Вставить("timestamp", Формат(ТекущаяУниверсальнаяДата(), "ДФ='yyyy-MM-ddTHH:mm:ssZ'"));
    Событие.Вставить("level", "error");
    Событие.Вставить("platform", "other");
    Событие.Вставить("environment", "prod");
    Событие.Вставить("release", "1c-erp-2.5.26.110");
    Событие.Вставить("message", ПодробноеПредставлениеОшибки(ИнформацияОбОшибке));
    Событие.Вставить("tags", Новый Структура("source", "1c"));

    // Собираем конверт: для простого события это 3 строки
    ЗаголовокКонверта = Новый Структура("event_id, dsn", EventId, DSN);
    ЗаголовокItem = Новый Структура("type", "event");

    Тело = ВСтрокуJSON(ЗаголовокКонверта) + Символы.ПС
        + ВСтрокуJSON(ЗаголовокItem) + Символы.ПС
        + ВСтрокуJSON(Событие);

    Заголовки = Новый Соответствие;
    Заголовки.Вставить("Content-Type", "application/x-sentry-envelope");
    Заголовки.Вставить("X-Sentry-Auth", СформироватьSentryAuth(DSN));

    HTTPЗапрос = Новый HTTPЗапрос("/api/<project>/envelope/", Заголовки);
    HTTPЗапрос.УстановитьТелоИзСтроки(Тело);
    Соединение = Новый HTTPСоединение(ИзвлечьХост(DSN), 443, , , , Истина);
    Соединение.ОтправитьДляОбработки(HTTPЗапрос);
КонецПроцедуры

Здесь ВСтрокуJSON работает обёрткой над ЗаписьJSON, которая сериализует структуру в одну строку. Код пишется один раз и кладётся в общий модуль с глобальной обёрткой Попытка ... Исключение на критичных операциях (проведение документов, начисления, обмен). После этого фактические сбои 1С попадают в тот же Sentry/GlitchTip, что и веб, и видны на одном экране CIO. Точный формат конверта и поля аутентификации сверяйте по ссылке выше, схема живая и иногда меняется.

Связь с Service Desk по ITIL

Алерт в Telegram это полумера. Алерт пришёл, инженер увидел, инженер починил. След от инцидента остался только в чате (через неделю не найти) и в логах Sentry (можно найти, но неудобно). Для зрелого ИТ-процесса этого мало. По ITIL incident это запись в Service Desk с категорией, приоритетом, назначенным владельцем и SLA-таймером.

Sentry умеет вебхуки. На каждое срабатывание правила (новая группа ошибок, всплеск, повторное появление после фикса) он отправляет POST на ваш URL. Этот URL может быть Service Desk напрямую (если он принимает вебхуки) или сервис-посредник, который преобразует данные Sentry в формат тикета.

Severity mapping

Сначала договариваемся, как уровень в Sentry превращается в приоритет инцидента ITIL.

Service Desk платформы, актуальные для РФ 2026

Atlassian (Jira Service Management) и ServiceNow в 2022–2023 закрыли продажи в РФ. Я использую следующие альтернативы у клиентов.

• Naumen Service Desk. Российский enterprise ITSM, ITIL-сертифицирован, есть API для приёма тикетов через REST. Сильный игрок в крупном бизнесе.
• ITSM 365. Облачный SaaS на платформе Naumen, для среднего бизнеса. Есть API.
• Yandex Tracker. Формально task tracker, но умеет работать как Service Desk при правильной настройке очередей и SLA. API нормальный, доступ для РФ открыт.
• 1С:Документооборот 3.0. Если бизнес уже на 1С, можно вести инциденты в нём. Не идеально по UX, но данные остаются в одном контуре.
• OTRS / Zammad / GLPI. Open-source ITSM (AGPL/MIT), self-host. Я ставлю их у клиентов с малым бюджетом, у кого нет лицензий на Naumen.

Middleware-сервис между Sentry и Service Desk

Прямой вебхук от Sentry в Service Desk почти никогда не работает. Нужен сервис-посредник, который делает 4 вещи. Обогащает данные (добавляет окружение, версию, число затронутых пользователей, ссылку на запись сессии и на runbook). Дедуплицирует (одна группа ошибок, один тикет, а не 1000). Ограничивает частоту (не больше 1 тикета в минуту на правило). Назначает дежурного по расписанию.

python
# middleware.py — FastAPI-микросервис между Sentry и Naumen SD
from fastapi import FastAPI, HTTPException
from datetime import datetime, timedelta
import httpx
import redis

app = FastAPI()
r = redis.Redis(host="localhost")
NAUMEN_API = "https://sd.example.ru/api/v1/incidents"
SENTRY_SECRET = os.environ["SENTRY_WEBHOOK_SECRET"]

LEVEL_TO_PRIORITY = {
    "fatal": "P1",
    "error": "P2",  # Дальше — корректируется по spike/regression
    "warning": "P4",
}

@app.post("/webhook/sentry")
async def receive(payload: dict, x_sentry_signature: str | None = None):
    if x_sentry_signature != SENTRY_SECRET:
        raise HTTPException(401, "bad signature")

    issue_id = payload["data"]["issue"]["id"]
    level = payload["data"]["issue"]["level"]

    # Дедупликация — один тикет на issue в течение часа
    if r.exists(f"sd:incident:{issue_id}"):
        return {"status": "dedup"}

    r.setex(f"sd:incident:{issue_id}", 3600, "1")

    priority = LEVEL_TO_PRIORITY.get(level, "P3")
    if "spike" in payload["data"].get("action", ""):
        priority = "P2"
    if "regression" in payload["data"].get("action", ""):
        priority = "P1"

    # Назначение по on-call rotation (упрощённо)
    assignee = get_oncall_engineer(datetime.now())

    body = {
        "title": f"[Sentry {priority}] {payload['data']['issue']['title']}",
        "description": render_description(payload),
        "priority": priority,
        "assignee": assignee,
        "category": "Software Error",
        "source": "Sentry",
        "external_id": issue_id,
        "sla_response_seconds": SLA[priority],
    }

    async with httpx.AsyncClient() as client:
        resp = await client.post(NAUMEN_API, json=body, headers=AUTH)
        resp.raise_for_status()

    return {"status": "ticket_created", "id": resp.json()["id"]}

Этот микросервис у меня живёт на том же VPS, что и GlitchTip, под FastAPI и systemd-юнитом. Расход ресурсов 30-50 МБ RAM. Поднимается за 20 минут.

Когда Sentry не поможет

Error tracking ловит только то, что само приложение успело сообщить. Есть классы инцидентов, для которых Sentry молчит.

Infrastructure-down. Apt purge dovecot из прошлого RCA положил dovecot полностью. Приложение даже не запустилось, Sentry молчал бы. Для такого нужен external uptime check (UptimeRobot, BetterStack, Healthchecks.io self-host).

Silent data corruption. Если ваш код спокойно записал в БД мусор без exception, Sentry не увидит. Для такого нужны runtime assertions (на критичных операциях), domain-валидация в БД (CHECK constraints, foreign keys), и ручной аудит данных раз в N дней.

Performance degradation без exceptions. Sentry умеет performance traces, но они дороже по storage. На SMB обычно выключены. Если API вместо 200 мс стал отвечать 5 секунд, и при этом ничего не упало, Sentry не показывает. Для такого нужен APM (SigNoz, Datadog, ваш Grafana-стек).

Сетевые проблемы между микросервисами. Service A ушёл к Service B, Service B упал, Service A обработал ответ как «empty result» вместо exception. Для такого нужен distributed tracing с context propagation (OTel + Jaeger/Tempo).

Поэтому Sentry не серебряная пуля. Это базовая страховка от одного класса проблем (необработанные исключения). В зрелом observability-стеке у вас есть ещё три уровня. External uptime checks, APM с performance traces, log aggregation с поиском. Я ставлю всё это поэтапно. Sentry первым, остальное по мере роста.

Цифры для CFO

Если вы как CIO защищаете бюджет на error tracking перед владельцем, ниже считалка. Считаем на трёх условных сценариях.

Сценарий 1. SMB с трафиком 50–200 посетителей/день

Один инцидент типа моего Valkey restart дал 11 потерянных посетителей, по грубой прикидке 0.3–0.5 заявки и порядка 2–10 тыс ₽ упущенной выручки. Допустим, такое случается 4 раза в год (раз в квартал что-то ломаю при тюнинге). Годовая упущенная выручка от инцидентов получается порядка 8–40 тыс ₽.

Стоимость error tracking. GlitchTip self-host на том же VPS стоит 0 ₽. Час моего времени на установку стоит 5–8 тыс ₽ альтернативная стоимость. Час на правила scrubbing PII и интеграцию ещё 5–8 тыс ₽. Итого инвестиция 10–16 тыс ₽, возврат за полгода-год.

Сценарий 2. Средний B2B с 500 посетителей/час

Один инцидент 20 минут даунтайма даёт 150 потерянных посетителей, 5–10 заявок, чек 50–200 тыс ₽, итого 250 тыс – 2 млн ₽ упущенной выручки за один случай. Допустим, 2 таких случая в год это 0.5–4 млн ₽.

Стоимость. GlitchTip self-host на отдельной VM с резервной копией PostgreSQL стоит около 1500–3000 ₽/мес инфраструктуры и 10– 20 ч/мес инженерного времени на сопровождение (20–50 тыс ₽/мес). Итого 250–650 тыс ₽/год. Окупаемость с первого предотвращённого инцидента.

Сценарий 3. Enterprise 20+ микросервисов

SigNoz self-host + OTel-инструментация. Один инцидент в цепочке микросервисов без observability стоит 4–8 часов на RCA с участием нескольких команд, 0.5–2 млн ₽ упущенной выручки плюс репутационный ущерб. Sentry/SigNoz сокращают RCA до 15– 30 минут.

Стоимость. Кластер из 3 VM под SigNoz + ClickHouse: 30–60 тыс ₽/мес инфраструктуры. Команда на сопровождение 0.5 FTE DevOps, 80–150 тыс ₽/мес. Лицензий нет (MIT). Итого 1.3–2.5 млн ₽/год. Окупаемость на 2–3 предотвращённых инцидентах.

TL;DR

1. Error tracking ставится в первый деплой. Не «когда станет больше трафика». Один потерянный B2B-клиент окупает год наблюдения.
2. Для российских компаний в 2026 Sentry SaaS закрыт (152-ФЗ + санкции + Stripe). Self-host или совместимая замена.
3. Малая команда до запуска → GlitchTip self-host рядом с приложением. MIT, 256 МБ RAM, те же Sentry SDK без правки кода. 10 минут установка.
4. Среднее предприятие 20–50 разработчиков → SigNoz + OTel. Один observability-стек для traces, metrics, logs, errors. Нет vendor lock.
5. Сразу настроить scrubbing PII (152-ФЗ ст. 5 ч. 1) и отразить обработку в уведомлении РКН.
6. План Б на случай санкционной блокировки. Совместимая замена через смену DSN. Код не меняется. Страховка 256 МБ RAM.
7. Связь с Service Desk через сервис-посредник обязательна при зрелом ITIL-процессе. Без него алерты теряются в мессенджерах.
8. Sentry не поможет с infrastructure-down, silent data corruption, performance degradation. Это базовый уровень, не вся observability.

Если вы CIO и думаете, какой инструмент выбрать под ваш сценарий, пишите. Я веду три тарифа консультаций и подбираю стек под бюджет и команду. Если хотите больше практических разборов, посмотрите остальные записи журнала, в частности «9 правил работы с AI-кодером» и «ITIL для 50–500 человек».