p99 fsync против пиковых IOPS сравнивать бессмысленно, поскольку показатели снимают в разных режимах работы накопителя. Для WAL важна хвостовая задержка fsync при подтверждённой записи, тогда как пиковые IOPS обычно получают с глубокой очередью. Вывод действует только для указанной конфигурации: устройства, файловой системы, кэша, sync-метода и нагрузки.

Почему p99 fsync полезнее пиковых IOPS?

p99 fsync показывает границу, ниже которой уложились 99% синхронизаций в прогоне. Пиковые IOPS показывают пропускную способность при заданной очереди и ничего не говорят об одном flush WAL. Но и p99 оценивают только вместе с числом операций, длительностью теста и конфигурацией конкретного хранилища.

Показать, где WAL ждёт подтверждения записи

При COMMIT процесс добавляет запись о завершении транзакции в WAL и вызывает XLogFlush до нужного LSN. PostgreSQL сбрасывает WAL-буферы в файл, затем просит ОС синхронизировать его. При synchronous_commit=on клиент получает подтверждение после локального flush. Если настроена синхронная репликация, время ответа также зависит от ожидания standby и выбранного режима.

Способ синхронизации WAL задаёт wal_sync_method. На Linux по умолчанию используется fdatasync: PostgreSQL пишет WAL через файловый кэш, затем вызывает fdatasync(). Варианты open_datasync и open_sync открывают файл с другими флагами. Семантика каждого варианта разобрана в документации PostgreSQL, а скорость проверяют на файловой системе будущего pg_wal.

Завершённый write() ещё не говорит о сохранности после потери питания, поскольку данные могли остаться в памяти ядра или энергозависимом кэше контроллера. Поэтому хвостовая задержка fsync включает работу ядра, файловой системы и контроллера, а не только запись блока. Перед тестом фиксируют устройство, LVM или RAID, mount options, политику кэша и наличие power-loss protection.

Почему пик операций не предсказывает транзакционную задержку

IOPS измеряют числом завершённых операций за секунду. Высокий результат часто получают с десятками запросов в очереди, чтобы контроллер использовал параллелизм NAND. При одиночном COMMIT это преимущество исчезает, так как транзакция ждёт конкретный flush.

Средняя latency тоже скрывает паузы. Если 9900 синхронизаций заняли 0,2 мс, а 100 заняли 20 мс, среднее составит около 0,4 мс, хотя у 1% транзакций задержка будет около 20 мс. Заявленная p99 задержка хранилища требует единиц, числа выборок и периода. Без них доля медленных операций неизвестна.

Глубину очереди меняют отдельной серией. QD=1 показывает задержку без очереди, а QD=8 или 32 проверяет параллелизм. При синхронном psync значение iodepth выше единицы не создаёт настоящую очередь, поэтому нужен асинхронный engine с direct=1. Полученную пропускную способность нельзя выдавать за задержку WAL и тем более сравнивать с рекламным read IOPS.

Читать p50, p95 и p99 как форму риска

Перцентили относятся к одному распределению. p50 делит выборку пополам, выше p95 остаются 5% операций, выше p99 остаётся 1%. Для 100 000 операций этот хвост даёт около тысячи наблюдений, а для 1000 – только десять, поэтому маленькая выборка сильнее реагирует на шум.

Как измерять fsync при реалистичной нагрузке?

Воспроизведите условия реального WAL: размер синхронной записи, конкурентность, глубину очереди, sync-метод и файловую систему. Измеряйте после прогрева устройства. Затем сохраните полное распределение, число операций и временной ряд вместе с политикой кэша. После микротеста проверьте вывод транзакционной нагрузкой при тех же гарантиях сохранности данных.

Показатели p50/p95/p99 дополняют гистограммой: по ней видно, образует ли хвост один пик или несколько режимов. На графике, где IOPS отложены против задержки, подпишите block size, queue depth, jobs и длительность. Максимум сохраняют отдельно, так как выброс мог совпасть с checkpoint, discard или работой гипервизора.

По временному ряду видно, распределены ли редкие паузы по всему тесту или хвост создал один провал. Всплески сопоставляют с выводом iostat -x 1, телеметрией NVMe и checkpoint.

Повторить размер записи, очередь и конкурентность WAL

Как правило, сначала фиксируют версию PostgreSQL, wal_sync_method, synchronous_commit, объём WAL за секунду и число одновременно завершающихся транзакций. Скорость генерации WAL считают по разнице показаний pg_stat_wal, а конкурентность берут из журналов и метрик за тот же период. Размер синхронной записи берут из реального профиля, а при его отсутствии помечают как допущение. При конкуренции PostgreSQL может подтвердить несколько транзакций одним flush, поэтому число синхронизаций окажется меньше числа COMMIT.

Сначала моделируют одиночную синхронизацию с выбранным размером блока, например 8 KiB: один job, QD=1, тот же каталог и sync-метод. Затем повышают число jobs. Асинхронный QD-тест идёт отдельно, иначе невозможно понять, что дало прирост: конкурентность приложения или внутренняя очередь устройства.

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

Согласовать pg_test_fsync, fio и транзакционный прогон

pg_test_fsync сравнивает способы синхронизации и выводит среднее время операции. По документации PostgreSQL файл размещают на той же файловой системе, где будет pg_wal. Утилита помогает выбрать wal_sync_method, но не показывает хвост распределения и не предсказывает пропускную способность базы.

В прогоне, опубликованном 27 мая 2025 года, использовались PostgreSQL 16, Samsung 990 Pro, XFS и write-back-кэш. Фрагмент сырого вывода:

На том же сервере, но на Micron 7400 с PLP среднее время fdatasync составило 24 мкс. Полный вывод и топология стенда есть в исходном отчёте, но из-за разной конфигурации это сравнение классов накопителей, а не моделей.

Чтобы получить распределение, используют fio job, в котором заданы engine, block size, QD и длительность. Укажите отдельный тестовый файл: fio перезапишет его и потребует не менее 32 GiB свободного места.

Команда fio wal-fsync.fio --output=wal-fsync.txt --output-format=normal сохраняет отчёт, а percentile_list задаёт перцентили. Для WAL смотрите раздел fsync/fdatasync/sync_file_range. Отдельная асинхронная серия покажет, как меняется задержка NVMe при разной глубине очереди. Затем подтвердите результат в pgbench с -l или прикладном сценарии при тех же гарантиях сохранности данных.

Поймать cache exhaustion, flush и фоновые паузы

Короткий запуск может закончиться до исчерпания быстрого кэша SSD. Поэтому файл предварительно заполняют, устройство прогревают, а тест ведут до устойчивого режима. По временному ряду видно, как после исчерпания SLC-кэша падает пропускная способность или растёт задержка. Там же видны фоновые паузы. Один итоговый p99 смешивает быстрый старт с установившимся режимом.

Перед серией фиксируют write cache, PLP, температуру, прошивку, заполнение, discard и фоновые операции. Что из этого списка недоступно на виртуальном диске, также отмечают в отчёте. Кэш не отключают, поскольку тест повторяет рабочую конфигурацию, а потерю питания проверяют отдельно.

Какой p99 допустим для транзакционной нагрузки?

1. Универсального порога нет: вычтите из SLO время сети, блокировок, CPU и других синхронных шагов.

2. Определите, какую часть остатка можно отдать ожиданию WAL с учётом group commit.

3. Задайте запас и долю нарушений, затем подтвердите порог транзакционным тестом.

p99 fsync 5 мс уже больше, чем весь SLO в 4 мс. При SLO 100 мс такая задержка может поместиться в бюджет только после учёта остальных ожиданий. Результат проверяют после прогрева и при рабочем заполнении диска, а критерий пересматривают при смене прошивки, миграции VM или росте нагрузки.

Связать хвост fsync с SLO транзакций

p99 fsync нельзя напрямую приравнивать к p99 транзакции. В критический путь транзакции входят блокировки, вычисления, сеть, репликация и иногда несколько flush. Group commit объединяет синхронизации, а synchronous_commit=off убирает ожидание локального диска. Поэтому перед сравнением выясняют, какие этапы идут последовательно, а какие перекрываются.

Затем сопоставляются временные ряды. Если пики commit latency совпадают с ростом времени WAL fsync, await и длины очереди, накопитель становится основной гипотезой. Если метрики хранения остаются ровными, задержку ищут в блокировках, CPU или ожидании реплики. Причину подтверждают изменением одного фактора: устройства, sync-метода или профиля нагрузки.

В SLO записывайте порог, долю нарушений, окно и минимальное число операций. Вместе с результатами транзакционного теста нужно сохранить latency histogram, указав границы бакетов и число наблюдений. Размер запаса задаётся до серии. При росте конкурентности тест лучше повторить: очередь и group commit меняют связь между одним flush и числом завершённых транзакций.

Сделать результат проверяемым на другом стенде

К job-файлу и сырому выводу обычно добавляют дату, версии fio, PostgreSQL и ядра, файловую систему и mount options, модель и прошивку диска, RAID/LVM, кэш и PLP, размер файла, block size, QD, jobs, длительность и прогрев. Для VM также указывают контроллер и неизвестные свойства хранилища.

В папку результата положите fio.job, fio.txt, вывод pg_test_fsync, журналы pgbench, iostat, NVMe log и CSV временного ряда. Рядом с графиком приведите перцентили и число операций. Без исходных файлов нельзя проверить единицы, фильтрацию и границы интервала.

У steady-state workload должен быть критерий: например, 10 минут после 5-минутного прогрева или остановка fio по условию steady state. Выбор зафиксируйте в job-файле. В краткой версии публикации оставьте график p99 и ссылку на полную методику.

Хранилище для WAL выбирают по повторяемой задержке подтверждённой записи и по тому, укладывается ли транзакция в свой SLO. Сначала проверьте sync-метод на файловой системе pg_wal, затем снимите распределение задержек в fio и подтвердите вывод транзакционным тестом. Сырой вывод нужен, чтобы не спутать смену накопителя с изменением нагрузки. После такой проверки p99 fsync против пиковых IOPS перестаёт быть выбором между двумя цифрами: для планирования берут p99, измеренный при нужных гарантиях записи и сопоставленный с SLO.

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

В IncidentRelay 2.0 мы добавили Event Orchestration. В этой статье разберём одну из основных частей новой функции — Global Orchestration: зачем она нужна, где находится в потоке обработки, как устроены правила и почему мы не ограничились обычным rule engine с кнопкой «Включить».

Какую задачу решает Global Orchestration

Global Orchestration — это набор упорядоченных правил, принадлежащий группе IncidentRelay. Он обрабатывает нормализованное событие до того, как будет окончательно выбран сервис и запущен обычный жизненный цикл алерта.

Упрощённо поток выглядит так:

Payload интеграции ↓ Аутентификация и нормализация ↓ Global Orchestration группы ↓ Оркестрация выбранного сервиса, если он известен ↓ Обычный жизненный цикл IncidentRelay ↓ Группа алертов, дочерний алерт, эскалация и уведомления

На глобальном уровне можно:

• выбрать команду, маршрут и сервис;

• нормализовать severity, title и другие поля события;

• назначить приоритет и политики;

• добавить или удалить метки;

• настроить group_key и dedup_key;

• подавить уведомления;

• отложить создание алерта;

• полностью отбросить событие;

• поставить безопасный асинхронный webhook в очередь.

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

Иными словами, мы добавили не второй жизненный цикл алерта, а слой принятия решений перед ним.

Почему global и service — разные области

В IncidentRelay есть две области оркестрации:

Область

Когда запускать

Типичные задачи

global

Владелец события ещё неизвестен или правило относится к нескольким сервисам

Нормализация, выбор команды и сервиса, общие правила подавления

service

Сервис уже выбран

Политики конкретного сервиса, локальное обогащение, задержка известного сигнала, запуск диагностики

Разделение оказалось важным. Без него глобальное определение быстро превращается в огромный файл со знаниями обо всех особенностях всех сервисов.

Хорошая граница ответственности выглядит так:

Global Orchestration: Кому принадлежит событие? В какой общий формат его привести? Service Orchestration: Как именно этот сервис хочет его обработать?

Глобальное правило может выбрать сервис. После этого IncidentRelay запускает оркестрацию, прикреплённую к выбранному сервису.

Если service orchestration передаёт событие другому сервису, runtime защищает цепочку от циклов и чрезмерного количества переходов. Потому что бесконечная маршрутизация — это тоже вид мониторинга, только уже за состоянием CPU.

Так общие соглашения хранятся в одном месте, а знания о конкретном сервисе остаются рядом с самим сервисом.

Пример: один Alertmanager и несколько команд

Представим, что общий Alertmanager принимает алерты всей production-платформы.

В IncidentRelay приходит нормализованное событие:

{ "source": "alertmanager", "title": "High error rate", "message": "Error rate is above 20%", "severity": "fatal", "status": "firing", "dedup_key": "checkout-db-2:high-error-rate", "labels": { "environment": "production", "application": "checkout", "component": "database", "instance": "checkout-db-2", "customer_impacting": true } }

Из payload уже понятно почти всё необходимое. Но статический маршрут не знает, какую комбинацию решений следует принять.

Глобальная оркестрация может выполнить такую последовательность:

1. Преобразовать fatal в каноническое значение critical.

2. По application=checkout выбрать команду Payments.

3. По component=database выбрать сервис Checkout Database.

4. Для критического события с customer_impacting=true задать приоритет P1.

5. Построить стабильные ключи группировки и дедупликации.

6. Остановить дальнейшие глобальные правила маршрутизации.

7. Передать результат в оркестрацию сервиса и обычный lifecycle.

Почему правила выполняются последовательно

Мы рассматривали вариант, при котором все правила получают один неизменяемый исходный контекст, а затем результаты как-то объединяются.

На бумаге это выглядит функционально и аккуратно. На практике быстро возникает вопрос: что делать, если два правила выбрали разные сервисы или установили разные значения priority?

В текущей модели правила выполняются сверху вниз, а действия внутри совпавшего правила — в указанном порядке. Последующие правила видят изменения предыдущих.

Например:

Правило 1: IF event.severity equals disaster THEN set_severity critical AFTER continue Правило 2: IF event.severity equals critical AND labels.customer_impacting is_true THEN set_priority P1

Второе правило уже увидит critical.

Это позволяет строить определение как понятный конвейер:

Нормализовать значения разных интеграций Добавить общие метки Выбрать владельца Выбрать priority и policies Настроить grouping и deduplication Принять решение suppress / pause / drop Поставить автоматизацию в очередь

Минус у подхода тоже есть: порядок становится частью логики.

Поэтому в execution trace сохраняются совпавшие условия, выполненные действия и значения до и после каждого изменения.

Условия: безопасные пути вместо произвольного кода

В условиях используются dotted paths к разрешённым частям контекста:

event.severity event.status labels.environment labels.application raw.alerts.0.labels.namespace variables.service route.id service.id team.id integration.source result.disposition

Движок читает JSON-объекты и индексы массивов, но не выполняет методы или произвольные выражения.

Основные операторы:

equals not_equals contains not_contains starts_with ends_with regex not_regex in not_in exists not_exists greater_than less_than greater_or_equal less_or_equal is_true is_false

Для логики доступны вложенные группы:

• ALL — AND;

• ANY — OR;

• NONE — NOT.

Пример:

ALL ├── labels.environment equals production └── ANY ├── event.severity equals critical └── labels.priority equals p1

То есть:

production AND (critical OR p1)

Шаблоны тоже ограничены

Текстовые действия используют подстановки вида:

{{ labels.service | upper }}: {{ event.title | trim }}

Поддерживается небольшой набор детерминированных фильтров:

lower upper trim default replace truncate

Например:

{{ labels.cluster | default("unknown") | trim | lower }}

Если необязательное поле может отсутствовать, это следует явно обработать через default.

В противном случае ошибка шаблона попадёт в трассировку и будет обработана согласно on_failure действия.

У каждого действия есть одна из трёх стратегий ошибки:

Значение

Поведение

continue

Записать ошибку и перейти к следующему действию

stop_rule

Остановить действия текущего правила

stop_orchestration

Остановить всю оркестрацию

Для необязательного обогащения подходит continue.

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

Валидация выбранных сущностей

Недостаточно просто получить из правила числовой service_id. Во время выполнения IncidentRelay проверяет согласованность выбранных объектов.

Например, будут отклонены случаи, когда:

• маршрут принадлежит другой группе;

• route source равен sentry, а источник события — alertmanager;

• выбранный сервис принадлежит другой команде, чем маршрут;

• escalation policy или notification policy принадлежит другой команде;

• выбранный объект был отключён или удалён после публикации версии.

Поведение после такой ошибки зависит от compatibility mode.

Два переключателя режима — и это не одно и то же

У определения есть runtime mode и compatibility mode. Поначалу их легко перепутать.

Runtime mode

Он отвечает на вопрос: влияет ли опубликованная версия на реальные события?

Режим

Что происходит

disabled

Production-события не вычисляются; доступны редактирование, validation и simulation

shadow

Опубликованная версия вычисляется и записывается, но её решения не меняют production

active

Допустимые решения применяются к реальной обработке

Для shadow и active нужна опубликованная версия.

Compatibility mode

Он отвечает на другой вопрос: как оркестрация делит ответственность с существующим lifecycle?

Режим

Что происходит

legacy

Существующая логика остаётся главным источником решений

hybrid

Явные решения оркестрации сохраняются, а старый lifecycle заполняет оставшиеся значения

orchestration

Оркестрация становится главным источником маршрутизации; требуется валидный route

Например, в hybrid:

Оркестрация явно установила priority=P1 → priority policy не заменяет это значение Оркестрация не выбрала notification policy → обычный механизм выбора policy продолжает работать

Если комбинация выбранных сущностей оказалась невалидной, hybrid может отклонить кандидата и продолжить legacy-обработку.

В режиме orchestration аналогичная ошибка блокирует дальнейшую обработку вместо fallback.

Для первого production-внедрения мы рекомендуем hybrid.

Отдельный крайний случай: конфигурация active + legacy не применяет решения оркестрации к production. Слово active здесь относится к runtime mode, но compatibility mode всё ещё оставляет старый lifecycle главным.

Название немного обманчивое, зато конфигурация безопасная. Иногда программное обеспечение шутит само, даже если разработчики не просили.

Simulator: проверить не только счастливый payload

Simulator вычисляет текущий draft изолированно.

Он не:

• создаёт алерты;

• отправляет уведомления;

• вызывает webhooks;

• меняет режим выполнения;

• публикует версию;

• изменяет production-данные.

Можно передать уже нормализованное событие или сырой payload поддерживаемой интеграции.

Во втором случае payload проходит через тот же зарегистрированный normalizer, который используется при production ingestion.

Для каждого важного правила стоит проверить минимум такие события:

1. Точное совпадение.

2. Почти совпадающее событие, которое не должно пройти.

3. Другое окружение.

4. Другой source.

5. Отсутствие необязательной метки.

6. Статус resolved.

7. Повторное событие, которое должно получить тот же dedup_key.

Результат симуляции содержит:

• исходное нормализованное событие;

• совпавшие правила;

• condition trace;

• значения до и после каждого действия;

• итоговый контекст;

• выбранные сущности;

• disposition;

• разницу между draft и active version.

Успешная симуляция доказывает, что движок смог выполнить определение. Она не доказывает, что бизнес-решение правильное.

Зелёный HTTP 200 вполне способен сообщить, что вы очень успешно направили все production-алерты команде стажёров.

Grouping и deduplication — тоже часть маршрутизации

Правильный владелец не спасает ситуацию, если каждый повтор создаёт новый алерт.

Для группы однотипных событий можно задать:

group_key: {{ labels.alertname }}: {{ labels.environment }} dedup_key: {{ labels.alertname }}: {{ labels.instance }} window_seconds: 900

Так события с одним alert name в одном окружении попадут в общую группу, а каждый instance сохранит собственный дочерний алерт. Повторный сигнал обновит нужный child alert.

Ключи должны быть стабильными.

Временная метка в dedup_key формально допустима, но фактически означает «создавай новый алерт при каждом запросе». Очень удобно, если ваша цель — нагрузочно протестировать дежурного инженера.

suppress, pause и drop — три разных решения

Эти действия легко объединить в голове как «не уведомлять», но последствия отличаются принципиально.

Действие

Результат

suppress

Алерт создаётся и остаётся видимым, но уведомления и эскалация подавляются

pause

Событие хранится как pending и активируется после задержки, если раньше не пришёл resolve

drop

Алерт и группа вообще не создаются

suppress подходит для событий, которые нужно сохранить для поиска или корреляции.

pause полезен для кратковременных сбоев. Например, можно подождать пять минут и отменить создание алерта, если за это время пришёл совпадающий resolve.

drop следует использовать только для сигналов без операционной ценности — например, точно определённого тестового heartbeat.

Пустое условие совпадает со всеми событиями. Поэтому catch-all вместе с drop, suppress, pause или обязательной маршрутизацией требует особенно осторожной проверки.

Catch-all с drop — очень эффективное средство против alert fatigue, примерно как демонтаж пожарной сигнализации против писка разряженной батарейки.

Асинхронные webhooks вместо произвольного кода

Если после совпадения правила нужно запросить диагностику, создать тикет или вызвать внутреннюю автоматизацию, используется переиспользуемое действие enqueue_webhook.

HTTP-запрос не выполняется внутри ingestion request. IncidentRelay ставит выполнение в очередь, а scheduler доставляет его асинхронно с timeout, retry и ограничениями безопасности.

Секретные заголовки хранятся зашифрованными и не возвращаются API. URL проверяются против SSRF, redirects повторно валидируются, а private network targets запрещаются или ограничиваются allowlist согласно конфигурации.

В simulation и shadow mode webhook не отправляется.

Иначе проверка нового правила могла бы создать несколько сотен вполне настоящих задач с заголовком TEST PLEASE IGNORE.

Что получилось в итоге

Global Orchestration дала нам единое место, где разнородные факты мониторинга превращаются в объяснимое операционное решение до начала paging:

• интеграции могут сохранять собственные форматы payload;

• общие правила нормализации не дублируются по сервисам;

• ownership выбирается по содержимому события;

• локальная логика остаётся в service orchestration;

• каждое решение можно проверить в trace;

• draft не влияет на production;

• опубликованные версии неизменяемы;

• simulation и shadow mode позволяют внедрять изменения без ставки на удачу.

IncidentRelay — open-source и self-hosted. Исходный код доступен на GitHub.

Подробное руководство по условиям, действиям, Simulator и shadow mode находится в документации Event Orchestration, а API — в отдельном руководстве.

В логах пусто, CPU в норме, но приложение тормозит. Часто виновата метрика, которую игнорируют: cpu steal time, или %st. Она показывает, сколько времени VPS провёл в ожидании физического процессора.

Что такое CPU Steal и откуда он берётся?

На гипервизоре несколько VM делят физические ядра. Когда vCPU готов работать, но планировщик отдал ядро соседней машине, ожидание засчитывается в steal. Так устроен Cloud VPS с общими ресурсами: несколько виртуальных машин конкурируют за физические ядра одного хоста. Steal может расти из-за высокой загрузки гипервизора, оверселлинга, особенностей планировщика виртуализации или кратковременной конкуренции за CPU.

Как измерить steal time

Быстрее всего – строка CPU в выводе top:

%Cpu(s):  8.0 us,  2.0 sy,  0.0 ni, 85.0 id,  3.0 wa,  0.0 hi,  0.0 si,  2.0 st

Для наблюдения в динамике – vmstat 1: колонка st показывает steal за каждую секунду. Разбивку по ядрам даёт mpstat -P ALL 1. Для минутного замера с усреднением – sar -u 1 60.

Какие значения считать нормой

На стабильной ноде steal обычно близок к нулю, но универсальной нормы нет: многое зависит от типа нагрузки и платформы виртуализации. Практические ориентиры:

•  0–1% – обычно не вызывает проблем

•  3–5% – повод проверить динамику и сопоставить её с задержками приложения

•  >10% – часто заметно влияет на производительность, особенно у чувствительных к задержкам сервисов

Смотрите на устойчивое значение за 10–15 минут, а не на пиковый выброс.

Что делать, если steal стабильно высокий

Сначала подтвердите устойчивость: sar -u 1 600 даст картину за 10 минут. Если steal держится выше 5%, стоит обратиться в поддержку провайдера: причина может быть в конкретной ноде, тарифе или особенностях инфраструктуры. Иногда помогает миграция на другой хост, но сначала лучше подтвердить проблему вместе с поддержкой. Если ситуация повторяется, рассмотрите тарифы с выделенными CPU-ядрами или смену провайдера.

Быстрый мониторинг VPS: чек-лист

•  Запустите top, найдите строку %Cpu и проверьте %st

•  Понаблюдайте за vmstat 1 в течение 30–60 секунд

•  Сравните пики steal с замедлениями приложения

•  Если steal стабильно выше 5%, зафиксируйте замеры и передайте их в поддержку

• Рассмотрите тариф с выделенными ядрами, если проблема системная

Запустите диагностику прямо сейчас хватит одной команды. Если steal стабильно высокий и совпадает с замедлениями приложения, сначала проверьте инфраструктуру, а уже потом ищите проблему в коде.

Что умеет:

- принимать алерты из разных систем мониторинга;
- маршрутизировать их по командам и сервисам;
- понимать, кто сейчас дежурит;
- слать уведомления в Mattermost, Slack, Telegram, email, browser push, webhook и даже voice call;
- делать ACK/Resolve;
- напоминать и эскалировать;
- учитывать maintenance windows;
- глушить шумные алерты через silences;
- показывать календарь дежурств;
- делать CalDAV/ICS-подписки;
- группировать похожие алерты;
- показывать Explain Trace: почему система решила именно так;
- отслеживать сервисы, зависимости и impact;
- проверять Heartbeats, когда задача должна была прислать “я жива”, но решила уйти в молчание.

За 5 месяцев от первой версии до 1.1 проект оброс довольно большим количеством функций. Начиналось всё с базового alert flow, Telegram-действий и фильтров. Потом понеслось: ротации стали многоуровневыми, появились escalation policies, сервисный каталог, SLI/SLO, Business Services, heartbeats и отдельная логика impact.

Самым сложным неожиданно оказался не “принять webhook и отправить сообщение”. Это как раз весёлая часть. Сложным оказалось понять, как правильно считать влияние сервисов друг на друга.

Вот есть сервис A, от него зависит B, от B зависит C, у C алерт, у A degraded, у B maintenance, где-то P2, где-то critical, а бизнес-сервис сверху должен показать понятный статус. И желательно не писать пользователю “всё горит”, если на самом деле горит только маленький угол. Но и не писать “всё нормально”, если этот маленький угол держит половину продукта. Тут начинаются настоящие разговоры с графом зависимостей. Иногда граф смотрит в ответ. Осуждающе.

Отдельно пришлось повозиться с визуализацией графа. Потому что граф сервисов в UI легко превращается в тарелку лапши: линии везде, подписи пересекаются, root cause где-то спрятался, downstream impact убежал за край экрана. Пришлось продумывать расположение, уровни, подсветку и то, как показать пользователю не просто красивую картинку, а полезную информацию.

Ещё одна штука, которой мы довольны, - Explain Trace. Это когда можно открыть алерт и увидеть: какой route сработал, какие matchers совпали, почему алерт сгруппировался, почему уведомление ушло или не ушло. Очень помогает в ситуации “почему меня разбудило в 03:17”, хотя честный ответ иногда всё равно “потому что ты дежурный, прости”.

В релизе 1.1 также есть Heartbeats. Это проверки для задач, которые должны периодически сообщать “я завершилась успешно”. Backup, ETL, watchdog, агент на сервере. Если ping не пришёл - создаётся обычный алерт. Есть multi-instance режим, чтобы один живой сервер не прикрывал пятерых молча умерших товарищей.

Разворачивается через Docker Compose, RPM, systemd или Helm. Маленькие установки могут жить на SQLite, для production лучше PostgreSQL. Лицензия MIT.

GitHub: https://github.com/roxy-wi/IncidentRelay

Сайт: https://incidentrelay.io/

С тех пор проект добрался до v1.0.21-beta. Цепочка стала длиннее, но пользоваться системой стало проще. В отличие от некоторых корпоративных процессов, здесь усложнение действительно пошло на пользу.

Не буду пересказывать весь changelog. Расскажу о нескольких изменениях, которые сильнее всего повлияли на продукт.

Дежурства стали похожи на настоящие

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

Поэтому в IncidentRelay появились многослойные ротации. У каждого слоя могут быть свои:

• участники и приоритет;

• временные ограничения;

• часовой пояс;

• правила передачи смены.

Поверх расписания работают временные замены. Календарь показывает уже итоговый результат после применения всех слоёв и overrides.

Расписание можно подключить к Google Calendar, Outlook, Apple Calendar и другим клиентам через ICS или read-only CalDAV. Пользователи также могут получать уведомления о предстоящих сменах.

Появился On-call Health. Он заранее ищет пустые слои, неактивных участников, разрывы в расписании, маршруты без получателя и проблемы с каналами уведомлений.

Лучше увидеть красный индикатор днём, чем обнаружить ночью, что единственный дежурный существует только в базе данных.

Двадцать алертов теперь могут стать одним инцидентом

Одна проблема редко присылает одно аккуратное сообщение. Обычно сначала жалуется база, потом API, затем очередь, а через минуту к обсуждению присоединяется всё, у чего есть доступ к Alertmanager.

Теперь IncidentRelay умеет группировать связанные события по сервису, окружению, кластеру, имени алерта и другим labels.

Для группы можно:

• задержать первое уведомление;

• настроить периодические обновления;

• выполнить ACK или Resolve сразу для всей группы;

• объединить несколько групп вручную;

• оставить комментарии и сохранить историю расследования.

Исходные алерты при этом не теряются. Дежурный получает одну развивающуюся историю вместо серии сообщений с одинаковым смыслом и разной пунктуацией.

Появилось понимание того, что именно сломалось

Раньше IncidentRelay хорошо отвечал на вопрос «кому отправить алерт», но почти ничего не знал о самом объекте аварии.

Теперь в системе есть каталог сервисов. Для каждого сервиса можно задать владельцев, критичность, окружение, runbooks, ссылки, правила сопоставления с алертами и зависимости от других сервисов.

На основе зависимостей система показывает:

• возможную первопричину;

• затронутые сервисы;

• путь распространения проблемы;

• общий blast radius.

Также появилась аналитика: сгруппированные инциденты, объём сырых алертов, дедупликация, уровень шума и время реакции.

Это не замена observability-платформе. Задача скромнее: избавить дежурного от традиционного ритуала поиска актуального runbook среди wiki, старого чата и ссылки, которая «точно работала в прошлом квартале».

Инцидент больше не заканчивается на ACK

ACK сообщает, что алерт кто-то увидел. К сожалению, он не ремонтирует базу данных. Мы проверяли.

Поэтому в IncidentRelay появились:

• приоритеты от P1 до P5;

• автоматическое повышение приоритета по severity;

• запрос дополнительных responders;

• stakeholders и настройки их уведомлений;

• комментарии и timeline;

• maintenance windows.

Maintenance window можно привязать к группе, команде, сервису или маршруту. Во время работ система может отключить уведомления, не создавать новые инциденты или временно остановить эскалации.

Поддерживаются часовые пояса и повторяющиеся правила RFC 5545. Потому что любое простое окно обслуживания рано или поздно превращается в «каждый второй вторник, кроме праздников и последней недели квартала».

Теперь система объясняет свои решения

Самая заметная новая функция называется Alert Explain Trace.

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

В трассе видно:

1. Был ли принят payload.

2. Какой route совпал.

3. Какой service был найден.

4. В какую группу попал алерт.

5. Сработали ли silence или maintenance window.

6. Как выбрали дежурного.

7. Какие уведомления были отправлены или пропущены.

Интеграция получает trace_id, по которому результат можно открыть в UI или запросить через API.

Для self-hosted продукта прозрачность особенно важна. «Система решила именно так» звучит гораздо убедительнее, когда рядом есть список причин, а не только уверенный зелёный индикатор.

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

За месяц IncidentRelay вырос из маршрутизатора алертов в более связный workflow:

Alert -> Route -> Service -> Group -> Priority -> Escalation -> On-call -> Responders -> Notifications -> Resolution

Проект всё ещё находится в beta и активно развивается. Впереди новые интеграции, улучшение аналитики и более простая установка. Но уже сейчас система умеет не только разбудить дежурного, но и объяснить, почему выбрала именно его. В мире on-call это почти проявление вежливости.

• Сайт

• GitHub

• Документация

• Changelog

Буду рад обратной связи и примерам реальных расписаний. Чем страннее график, тем полезнее тестовый сценарий.