Self-hosted Sentry на VPS: ресурсы полного стека и срок хранения событий

Полный Sentry на собственном сервере — это не один обработчик ошибок, а несколько взаимодействующих служб: базы данных, брокеры сообщений, воркеры, веб-часть и всё, что связывает их между собой. Поэтому вопрос «какой VPS нужен для Sentry» нельзя решить, посмотрев на размер одного процесса. Считать приходится весь стек целиком, а вместе с ним — срок, в течение которого вы готовы хранить события. Именно эти две величины и определяют, будет ли сервер спокойно работать или начнёт задыхаться через пару недель.

Разберём это на примере одного события: проследим его путь от приложения до строки в поиске, посмотрим, где оно оставляет следы, и затем перейдём к арифметике памяти и диска.

Путь одного исключения

Допустим, в вашем сервисе выбросилось необработанное исключение. SDK, встроенный в приложение, перехватывает его, собирает стек вызовов, окружение, теги, возможно, хлебные крошки и отправляет на адрес вашего Sentry. С этого момента событие перестаёт быть вашим «маленьким JSON» и становится нагрузкой для целой цепочки.

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

Дальше событие ждёт в брокере. Очередь нужна именно для того, чтобы пик ошибок не обрушил обработку: если после неудачного релиза за минуту прилетело в сотню раз больше событий, чем обычно, они накапливаются в очереди и разбираются в том темпе, в каком справляются воркеры. Это буфер, и память под него тоже нужна.

Затем воркеры разбирают событие: нормализуют данные, группируют похожие ошибки в одну проблему (по отпечатку стека), при необходимости применяют карты исходного кода, чтобы превратить минифицированный стек в читаемый. Эта стадия — самая вычислительная: именно здесь расходуются процессорные ядра и оперативная память.

Наконец, событие записывается в хранилища. Метаданные проблемы, счётчики, пользователи и проекты живут в реляционной базе, а сами события и данные для быстрого поиска и агрегаций — в аналитическом хранилище. Когда вы открываете интерфейс и фильтруете ошибки по тегу или версии релиза, запрос идёт именно туда. Плюс существует кэш, который ускоряет повторяющиеся обращения.

Итог такой: одно исключение за доли секунды проходит приём, очередь, обработку и запись в несколько мест. Каждое звено — отдельная служба со своим аппетитом к памяти и диску. Сложите их — и станет понятно, почему официальные требования выглядят совсем не так, как требования к простому веб-приложению.

Цена соседей: зачем стеку столько памяти

Документация Sentry для self-hosted установки называет минимум: 4 ядра процессора, 16 ГБ оперативной памяти плюс 16 ГБ swap и 20 ГБ свободного места на диске. Рекомендуемый объём памяти — 32 ГБ (Sentry: Self-hosted). Обратите внимание на формулировку: это минимум, при котором установка запускается и работает, а не расчёт ёмкости для боевой нагрузки. Между «поднялось» и «выдерживает наш поток ошибок» лежит дистанция, которую придётся измерить самому.

Почему так много? Потому что память здесь делится между службами, которые почти никогда не простаивают одновременно. Базы данных держат в памяти рабочие наборы и кэши, брокеры — очереди, воркеры — разбираемые события и загруженные карты исходного кода, веб-часть — свои процессы. Ни одна из служб в отдельности не требует чудовищных ресурсов, но все вместе они образуют заметный фундамент ещё до того, как первое реальное событие пришло с боевого приложения.

Отсюда практическое следствие: серверы с 1–4 ГБ памяти, на которых привычно живёт небольшой сайт или бот, для полного Sentry не подходят. Не стоит пытаться «ужать» конфигурацию ниже официального минимума и надеяться, что просто будет работать медленнее. Нехватка памяти в многослужебном стеке проявляется не плавным замедлением, а перезапусками отдельных компонентов, потерей части событий в очереди и непонятными ошибками в интерфейсе — такие симптомы потом долго искать.

Про swap стоит сказать отдельно. Требование 16 ГБ подкачки нужно понимать как страховку от коротких пиков при запуске и обработке, а не как способ заменить оперативную память. Если стек постоянно живёт в swap, вы платите задержками каждой операции. Подкачка помогает пережить всплеск, но не должна становиться рабочим режимом.

Диск: не только объём, но и скорость

Та же документация отмечает, что полный стек использует базы, брокеры и другие службы и потому заметно зависит от дискового ввода-вывода. Это принципиальный момент. 20 ГБ свободного места — граница для установки, но каждая служба постоянно пишет и читает: журналы транзакций базы, сегменты очереди, данные аналитического хранилища, фоновые слияния. На медленном диске всё это превращается в очередь ожидания записи, а за ней растёт и очередь необработанных событий.

Поэтому при выборе VPS для такой задачи важны не только гигабайты, но и тип накопителя. NVMe с его низкой задержкой и высокой пропускной способностью здесь не маркетинговое украшение, а практичное условие: он напрямую влияет на то, как быстро события из очереди становятся доступными для поиска. У VPS MAATRIX накопители именно NVMe, а процессоры — AMD EPYC, и root-доступ позволяет настроить систему под нужды стека. Но сами по себе эти характеристики ёмкость не гарантируют: сначала нужно измерить, сколько нужно вам.

Как срок хранения превращает поток в диск

Теперь о второй величине, которая решает почти всё. Sentry хранит события не вечно: есть параметр срока хранения, в self-hosted установке он задаётся переменной SENTRY_EVENT_RETENTION_DAYS. Уменьшение этого значения сокращает срок, в течение которого события лежат в системе, и может снизить потребность в диске (Sentry: Self-hosted). Слово «может» здесь стоит не для красоты: освобождение места не мгновенно, и работает это не как нажатие кнопки «очистить». Старые данные удаляются фоновыми задачами, а в аналитическом хранилище физическое место возвращается по мере очистки и слияния частей данных. Не рассчитывайте, что сегодня вы поменяли число, а завтра диск опустел.

Чтобы почувствовать масштаб, нужна простая арифметика. Ниже — учебный расчёт с условными числами: это не измерения и не типичные значения, а способ показать, как устроена зависимость. Подставьте свои цифры, когда они у вас появятся.

Допустим, средний размер одного события вместе со всеми индексами и служебными записями занимает 20 КБ, а приложение отправляет 50 000 событий в сутки. Тогда за день накапливается 50 000 × 20 КБ = 1 000 000 КБ, то есть около 1 ГБ. Никакого сжатия мы не предполагаем: реальный коэффициент зависит от данных и версии, и закладывать выдуманную экономию нельзя.

Видно, что срок хранения умножает поток линейно. Если вы вдвое увеличите срок, вдвое вырастет и установившийся объём данных. И если вы снизите ожидания по времени — скажем, согласитесь хранить 14 дней вместо 90 — потребность в диске падает пропорционально. Это самый дешёвый рычаг во всей конструкции, и он находится в ваших руках.

Но это только данные событий. К ним добавляются установленные образы служб, журналы контейнеров, служебные таблицы баз, место для обновлений (при обновлении старые и новые данные временно сосуществуют) и запас на непредвиденное. Поэтому итоговый диск всегда заметно больше, чем простое произведение потока на срок. Запас в разы — не перестраховка, а нормальная практика для хранилища, которое постоянно переписывает собственные данные.

Шторм после плохого релиза

Среднесуточный поток обманчив. Реальная нагрузка неравномерна: один неудачный релиз или упавшая зависимость способны за час выдать столько же ошибок, сколько обычно приходит за неделю. Если приложение зациклилось и бросает исключение на каждый запрос, поток становится в десятки раз выше среднего. В этот момент очередь растёт, воркеры и диск работают на пределе, а срок хранения вдруг начинает съедать место с непривычной скоростью.

Защита здесь прикладная, а не серверная: выборка событий на стороне SDK, ограничение частоты для шумных проектов, фильтрация заведомо бесполезных ошибок (например, от ботов или устаревших браузеров). Каждое событие, которое вы не отправили, не нужно ни принять, ни обработать, ни хранить. Это самое эффективное «увеличение ресурсов», и оно ничего не стоит.

Вложения и всё, что тяжелее стека вызовов

Текстовое событие — относительно скромный объект. Совсем иначе выглядит картина, когда вы начинаете хранить вместе с ошибкой дополнительные материалы: файлы-вложения, дампы, снимки состояния, а также данные, которые сопровождают события, например карты исходного кода для расшифровки минифицированных стеков. Один дамп способен весить больше, чем тысячи обычных событий.

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

Есть и вопрос данных, который не про диск, а про ответственность. Вложения и контекст событий могут содержать персональные данные пользователей или секреты из переменных окружения. Чем дольше срок хранения, тем дольше эти данные лежат на вашем сервере. Короткий retention — это и экономия диска, и сокращение риска: хранить меньше и недолго проще, чем потом объяснять, почему ошибка трёхмесячной давности всё ещё содержит чей-то адрес электронной почты.

Пилот: от учебной таблицы к своим замерам

Расчёт по условным цифрам хорош для оценки порядка величины, но решение о тарифе лучше принимать по измерениям. План такого пилота укладывается в несколько шагов.

1. Поднимите полный стек на сервере не меньше официального минимума и направьте на него ограниченный, но реальный поток: один-два проекта с типичным трафиком, а не синтетический генератор ошибок.
2. Дайте системе прогреться. Первые часы показывают не рабочее состояние: кэши ещё пусты, а ряд фоновых процессов только набирает ход. Берите замеры через несколько дней, а лучше после недели.
3. Снимите три группы показателей: занятую память вместе с использованием swap по службам, свободное место на диске и его суточный прирост, а также задержку обработки — сколько проходит времени от отправки события до его появления в поиске.
4. Посчитайте суточный прирост диска и умножьте на выбранный срок хранения, затем добавьте запас на обновления, журналы и всплески.
5. Отдельно проверьте поведение при искусственном всплеске: временно увеличьте поток и посмотрите, растёт ли очередь и как быстро она рассасывается.

Важно понимать, как читать результаты. Если swap постоянно используется, а задержка поиска растёт, вы упёрлись в память или диск — и это сигнал увеличивать ресурсы, а не рисковать. Если же память стабильна, а суточный прирост диска укладывается в расчёт с запасом, можно оставлять конфигурацию и корректировать только срок хранения.

Сопоставляем с тарифной сеткой

Теперь можно переложить требования на реальные конфигурации VPS. В линейке MAATRIX есть тарифы Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe), Uab (2 vCPU, 4 ГБ, 80 ГБ), Heka (4 vCPU, 8 ГБ, 160 ГБ), Maat (8 vCPU, 16 ГБ, 240 ГБ) и Djed (16 vCPU, 32 ГБ, 320 ГБ). Это сухие характеристики, а не обещание ёмкости, и сопоставлять их нужно с требованиями Sentry честно.

Вывод из таблицы простой, и ради рекламы его смягчать не нужно: младшие тарифы подходят для множества задач, но не для полного Sentry. Две-восемь гигабайт памяти — это ниже документированного минимума, и пытаться уместить в них весь стек не стоит. Отправная точка для пилота — Maat, а если нужен запас по памяти для заметного потока, ближе к рекомендации подходит Djed. Но и это лишь исходные позиции для замера: подойдёт ли выбранный тариф вашей нагрузке, покажут именно ваши измерения, а не строка в каталоге.

Отдельная приятная деталь для пилота: сервер создаётся автоматически через пару минут после оплаты, а root-доступ позволяет настроить swap, мониторинг и параметры системы. Это удобно, когда нужно быстро проверить гипотезу, а затем, если тариф оказался мал или велик, перейти на другой. Об установке самого стека подробнее рассказано в материале Как установить и настроить Sentry (self-hosted) на VPS.

Когда собственный Sentry оправдывает сопровождение

Цена self-hosted решения — не только строка про сервер. Это обновления, которые нужно применять и проверять, диск, за которым нужно следить, резервные копии, которые нужно настроить самостоятельно, и время человека, который всё это поддерживает. Автоматических резервных копий мы не предполагаем: любые копии баз и конфигурации — ваша задача.

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

Практичный критерий можно сформулировать через вопросы:

• Есть ли у вас человек, который готов раз в несколько недель обновлять стек и смотреть на графики памяти и диска?
• Сколько проектов и какой суммарный поток реально нужно принимать — а не «на вырост»?
• Нужно ли хранить данные именно у себя по требованиям к их размещению?
• Готовы ли вы к тому, что при нехватке ресурсов придётся либо расти по тарифу, либо сокращать срок хранения и объём событий?

Если на большую часть ответ «да», собственный Sentry себя оправдает. Если же поток мал, а сопровождать некому, возможно, честнее остаться на облачном решении или ограничиться лёгкими инструментами, чем держать стек, которому нужен сервер в разы мощнее, чем само приложение.

Сколько наблюдать — вопрос не только ёмкости

Есть соблазн настроить всё «с запасом»: принимать все события, хранить их три месяца, прикладывать к каждой ошибке дамп. Сервер это переживёт, если ему дать нужные ресурсы, но ценность такого архива обычно невелика. Ошибка, которую никто не открыл за две недели, вряд ли понадобится на девяностый день. Большинство разборов происходит в первые сутки после релиза, а исторический контекст чаще нужен в виде агрегатов — сколько было ошибок, как менялась тенденция, — чем в виде полных событий.

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

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