Как проверить VPS-сервер, если API по какой-то причине отвечает дольше, а список процессов не объясняет задержку? Нужно поймать сам симптом и одновременно записать top, vmstat, iostat -x и ss. Эти данные покажут вам, где образовалась очередь: у CPU, памяти, диска или сокета. Такой сбор подходит для первичной диагностики Linux-сервера под прикладной нагрузкой, но без истории метрик и данных приложения не даёт точную причину сбоя. Поэтому проверку VPS-сервера нельзя сводить к одной команде.

Какие четыре команды сначала запустить на медленном сервере?

Для начала запустите top, интервальные vmstat и iostat -x, а ss повторяйте циклом. Начните запись до воспроизведения замедления и сохраните время каждого среза. Команды помогут выбрать между CPU, памятью, диском и сетью, но вывод нужно сопоставить с метриками приложения и проверить повторным запуском.

Сначала зафиксировать, когда и как сервер замедляется

Фраза «сервер тормозит» не скажет, в чем именно проблема. Запишите время, границы эпизода, затронутую операцию, обычную и наблюдаемую задержку, throughput и долю ошибок. Для фоновой задачи подойдут длительность шага, размер очереди и скорость обработки. Также сохраните рядом с системными логами идентификатор запроса или трассировки.

На образе без systemd стоит отдельно проверить службу синхронизации времени.

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

Проверить процессы, CPU и память в одном срезе

Данные интерактивного top пропадут после закрытия терминала, а набор полей зависит от настроек пользователя. Пакетный режим -b печатает срезы обычным текстом, без перерисовки экрана, поэтому вывод можно перенаправить в файл. Ключи описаны в руководстве procps-ng. Два запуска ниже сортируют процессы по CPU и памяти, а системная сводка остаётся в обоих логах.

На вопрос, как проверить скорость VPS, один список процессов не ответит. us показывает время пользовательского кода, sy – работу ядра, wa – простой CPU при незавершённом I/O, st – время, которое гипервизор не предоставил vCPU. Высокий load average не доказывает нехватку CPU, так как Linux учитывает готовые к выполнению задачи и состояние непрерываемого ожидания. Поэтому сопоставляйте загрузку ядер с работающими процессами и состоянием D. Тот же срез закрывает и память: судить о ней по free нельзя, кеш освобождается по мере необходимости.

Увидеть очередь CPU, swap и системную динамику

vmstat сводит в одну строку процессы, память, swap, I/O и CPU. Команда пишет 13 строк с шагом 5 секунд. Первая содержит средние значения с момента загрузки, а текущий эпизод отражают следующие строки.

r показывает готовые к выполнению задачи, b – задачи в непрерываемом ожидании. Очередь r выше числа vCPU вместе с высоким us или sy поддерживает мысль о нехватке CPU. si и so показывают обмен со swap, а не его занятый объём. При включённом swap стабильно ненулевые si/so, дисковая активность и задержка указывают на подкачку. Без swap нулевые значения ни о чём не говорят, здесь нужны MemAvailable, OOM-события и /proc/pressure/memory.

Как отличить проблему CPU, памяти, диска или сети?

Снимайте показатели в одном окне: очередь r и загрузку CPU, обмен со swap, r_await, w_await и очередь диска, повторные передачи и очереди сокетов. Один всплеск не определяет узкое место. Нужны замедление приложения и второй сигнал того же ресурса в соседнем логе.

Проверка скорости VPS-сервера как раз и сводится к поиску этой связи, а не самого большого процента в отчёте.

Проверить очередь и задержку конкретного диска

Расширенный режим iostat снимает статистику по блочным устройствам. Ключ -y пропускает отчёт со средними с момента загрузки, -z скрывает неактивные устройства, -t добавляет время. В Debian и Ubuntu утилита входит в sysstat. Установить пакет лучше до диагностики, а не во время короткого сбоя.

Когда диагностика медленного сервера приводит к дисковой ветке, сначала найдите устройство проблемного пути. r/s и w/s показывают операции, rkB/s и wkB/s – поток данных, aqu-sz – среднюю очередь. По описанию sysstat, r_await и w_await включают очередь и обслуживание запроса. Сравнивайте r_await и w_await с задержкой приложения и профилем нагрузки.

%util, близкий к 100%, показывает насыщение устройства с последовательным обслуживанием. Для NVMe, RAID и других параллельных устройств показатель не показывает предел производительности. На VPS видимый диск может скрывать хранилище хоста. Не суммируйте строки диска, раздела и device mapper: одна операция учитывается на нескольких уровнях.

Найти переполненные очереди, retransmits и состояние сокетов

ss не имеет интервального режима, поэтому скрипт ниже запускает его циклом. -n отключает разрешение имён, -a включает все сокеты, -p показывает процесс, -i – TCP-данные. Без root сведения о чужих процессах могут отсутствовать.

Чтобы понять, как проверить скорость VPS-сервера со стороны сети, различайте слушающие и установленные сокеты. У установленного соединения Recv-Q показывает непрочитанные байты, Send-Q – неподтверждённые данные. У слушающего сокета поля показывают текущую и предельную очередь подключений. Её рост у одного процесса указывает, что он может не успевать принимать соединения.

В TCP-информации ищите retransmits, RTT и RTO. Повторная передача означает, что отправитель не получил пригодное подтверждение вовремя. Причинами могут быть потеря, задержка, переупорядочивание пакетов или ложный тайм-аут. Точную сторону проблемы счётчик не определяет. Много TIME-WAIT не считается ошибкой без исчерпания локальных портов. Ключи описаны в руководстве iproute2.

Пороги для RTT, retransmits и очередей у каждого сервиса свои: эталоном служит ваш же базовый интервал без замедления. Скрипт ниже собирает такой пакет за одно окно, после того как вы опишете нагрузку в LOAD_DESC.

Свести четыре вывода в дерево решений

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

1. CPU: r устойчиво выше числа vCPU, а top показывает занятые ядра. При высоком wa сначала проверьте диск.

2. Память: при включённом swap растут si/so и задержка. Без swap нужны MemAvailable, OOM-события и PSI.

3. Диск: растут r_await, w_await или aqu-sz, а vmstat показывает задачи b либо top – состояние D.

4. Сеть или сокет: одновременно растут RTT, retransmits либо очереди сокетов и ухудшаются latency или error rate.

Смешанная картина не означает несколько разных причин. Медленная запись увеличивает число задач в состоянии D; рабочие процессы перестают принимать запросы, и растёт очередь соединений. В такой последовательности дисковая задержка выглядит первичным сигналом, а очередь сокета – следствием. До проверки это лишь предположение.

Какие данные собрать до проверки приложения?

5. Версию ОС и утилит, часовой пояс, начало симптома и длительность выборки.

6. Полные команды и сырые интервальные логи top, vmstat, iostat -x и ss.

7. Описание нагрузки, endpoint или задачу, latency, throughput, error rate и базовый интервал.

Эти интервалы должны перекрывать один эпизод: разновременные логи в причинную цепочку не сводятся.

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

Системный сигнал нужно связать с сервисом. Сопоставьте по времени p50, p95 и p99 latency, throughput и error rate. Для очереди заданий подойдут время жизни старейшей задачи и скорость обработки. Рост r_await или w_await без прикладной задержки может относиться к другому диску. Если сервис замедлился без ресурсных сигналов, проверяйте блокировки, внешние зависимости и DNS.

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

Гипотеза должна предсказывать результат. Если CPU занят фоновой задачей, её ограничение должно уменьшить r и задержку сервиса. При дисковой очереди уменьшение интенсивности тестовой записи должно снизить w_await. Если прогноз не сбылся, зафиксируйте результат и проверьте другую ветку.

Оформить короткий пакет для следующего шага

Передавайте каталог с логами и коротким README, а не один скриншот top. Укажите автора, дату, конфигурацию VPS, ОС, ядро, команды, нагрузку и границы симптома.

Разделите диагноз на факты, гипотезу и недостающие данные. Факт содержит время и источник, например одновременный рост w_await и p95 одного адреса API. Гипотеза описывает механизм и ожидаемый результат проверки. Термин network latency без маршрута, RTT и стороны измерения остаётся предположением.

Для следующего инженера оставьте одну строку на ветку: симптом, два сигнала, проверка и критерий. Сырые логи храните в основном материале или приложении вместе с командами и контекстом.

Хорошая первичная диагностика заканчивается не определением «виновного» ресурса, а предположением с проверяемым прогнозом. Сохранённые команды, временные метки и описание нагрузки дают другому инженеру возможность повторить ход проверки и оспорить вывод. Если нужно решить, как проверить VPS-сервер, сначала определите границы симптома, затем ищите два согласованных сигнала и меняйте только один фактор. Не совпавший прогноз тоже полезен: он исключает ветку и не даёт принять следствие за причину или случайное совпадение за закономерность.

Я на это наткнулся ровно так, как обычно натыкаются на подобное — не потому что курил мануалы, а потому что два часа дебажил то, что по всем признакам не должно было ломаться. И только на дне этого дебага понял: я вообще не знаю, что происходит между вызовом getaddrinfo() и ответом. Никто, по сути, толком не знает. Все просто верят, что DNS резолвит имена и живут с этим счастливым заблуждением, пока оно их не настигает.

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

DNS — это не резолвинг. DNS — это один из вариантов

Вот с чего стоит начать разгребать: getaddrinfo() — это не функция “спроси DNS”. Это функция “спроси NSS”, а NSS (Name Service Switch) — это диспетчер, который решает, у кого спрашивать: у файла, у mDNS, у DNS, у LDAP, у самого черта, что тебе кто-то подсунул модулем. DNS там просто один из кандидатов, причем необязательно приоритетный.

Вся эта логика описана в одном скромном файле, который почти никто не читает после того, как система его замутила при установке:

$ cat /etc/nsswitch.conf hosts: files mdns4_minimal [NOTFOUND=return] dns

Вроде все просто, сначала спроси /etc/hosts, потом mDNS, потом DNS. Ну да, пока не обращаешь внимание на [NOTFOUND=return] (кому ведь интересно че там в скобках пишут?) — а ведь это уже маленькая бомбочка, о которой мы поговорим отдельно.

Первый источник вранья: /etc/hosts

Самый банальный и самый частый в реальности. Кто-то полгода назад добавил staging.internal в /etc/hosts, чтобы обойти DNS во время какого-то расследования, и забыл убрать. И из-за этого Пинкертона теперь этот хост “резолвится” на машине навсегда независимо от того, что говорит настоящий DNS, независимо от того, что там сейчас в зоне, независимо от того, помнит ли об этом кто-то живой.

files стоит первым в цепочке почти на любом дистрибутиве по умолчанию. И это значит: если имя есть в /etc/hosts — DNS вообще не спросят. Не DNS ответит неправильно, а DNS не спросят вовсе. Для человека, который смотрит на dig и видит правильный ответ, это выглядит как необъяснимая магия. Ведь как это может резолвиться в другое, если DNS говорит правильно? А очень просто — потому что digделает прямой DNS-запрос, а твой процесс до DNS в принципе не доходит.

Ловушка [NOTFOUND=return]

Вот эта конструкция в nsswitch.conf заслуживает отдельного разговора, потому что она реально может испортить тебе в лучшем случае вечер. [NOTFOUND=return] значит: если предыдущий источник явно ответил “такого имени нет” — остановить цепочку прямо здесь и вернуть “ниче не нашел”, не пытаясь спросить следующего.

Казалось бы, разумная оптимизация — mDNS не должен ходить в DNS за именами .local, которых там заведомо не будет. Но на практике это означает, что если что-то в цепочке до DNS решило, что имени не существует, DNS никогда не получит шанс сказать свое слово. Ты можешь идеально настроить зону, ты можешь трижды проверить записи и все равно получить NXDOMAIN на уровне приложения, потому что где-то раньше в цепочке был молчаливый шлагбаум.

Самое неприятное здесь — это происходит тихо. Просто отрицательный ответ, который выглядит абсолютно легитимно.

mDNS и иллюзия .local

Второй пункт в нашей цепочке — mDNS, тот самый multicast DNS, который отвечает за .local-имена в локальной сети. Штука сама по себе рабочая и полезная (Avahi, Bonjour и вот это все), но она добавляет еще один недетерминированный слой: ответ зависит от того, что прямо сейчас есть в сегменте сети, кто отозвался на multicast-запрос за отведенные ей несколько сотен миллисекунд, и повезло ли пакету дойти.

Тут вранья как такового меньше, но неопределенности — выше крыши. Один и тот же .local-хост может резолвиться по-разному в зависимости от того, кто именно ответил первым и насколько загружена сеть в этот момент.

systemd-resolved и обман через 127.0.0.53

А вот это, пожалуй, самый недооцененный источник путаницы на современных дистрибутивах. Открываешь /etc/resolv.conf, видишь:

nameserver 127.0.0.53

и на автомате читаешь это как “вот мой DNS-сервер”. Нет. Это заглушка, локальный прокси systemd-resolved. Реальные нейм-серверы, которые он спрашивает от твоего имени, спрятаны у него внутри в per-link конфиге, до которого обычный resolv.conf не дотягивается вообще. Чтобы узнать кто там реально отвечает за резолвинг, нужно спрашивать не файл, а сам systemd-resolved через D-Bus (org.freedesktop.resolve1.Manager).

Почему это важно? Потому что если ты хочешь сделать независимую проверку и наивно шлешь запрос на 127.0.0.53, ты снова спрашиваешь ту же самую цепочку, только другим путем. Ты сверяешься сам с собой. Ложное чувство независимой проверки, эдакая форма вранья, просто вежливая.

И вот тут есть нюанс, который удивляет: у systemd-resolved DNS-серверы не одни на всю систему, а per-link — свои на каждый сетевой интерфейс. Поднял VPN (тот же Tailscale) — получил отдельный резолвер для его зоны, который живет только на этом линке и в глобальный список серверов не попадает. Если имя относится к такой зоне, а ты сверяешься с глобальными ней серверами — ты гарантированно получишь расхождение, хотя формально все настроено правильно, просто ты спросил не того прохожего.

И тут всплывает со дна еще один источник лжи: gai.conf и сортировка.

DNS в ответе на запрос имени может вернуть сразу оба семейства адресов — и A-записи (IPv4), и AAAA-записи (IPv6). getaddrinfo() получает этот список и не отдает его как есть, а пересортировывает его по правилам RFC 6724, а конкретные веса этих правил живут в /etc/gai.conf. По умолчанию файл почти всегда пустой или отсутствует, что означает “используй дефолты RFC 6724 как есть”, и дефолты там говорят: предпочитай IPv6, если он вообще есть в ответе. Не если он работает. Просто если есть.

И вот тут расходится теория с продакшеном: IPv6 у хоста может быть объявлен в DNS, но реально не маршрутизируется, задроплен на файрволе или тупо висит на мертвом линке. getaddrinfo() про это ничего не знает — он смотрит только на RFC-таблицу приоритетов, а не на реальную доступность адреса. В итоге приложение честно берет “предпочтительный” IPv6-адрес первым, пытается на него достучаться, получает таймаут и только потом падает на IPv4-фолбэк — если он вообще предусмотрен. А dig тем временем как ни в чём не бывало показывает тебе чистый и рабочий IPv4-адрес, потому что dig никого не сортирует и никаких приоритетов не расставляет — он просто печатает, что вернул сервер.

Самое обидное, что это не баг ни у кого. Ни у DNS, ни у приложения, ни у ядра. Это ровно то поведение, которое RFC и просил реализовать. Просто оно молчаливо предполагает мир, где если IPv6-адрес объявлен, то он работает. В 2026 году это предположение все еще сильно оптимистичнее, чем хотелось бы.

Ловушка, о которой почти никто не думает: статический Go-бинарник

И последняя, моя любимая, потому что она рвет шаблон у всех, кто искренне верит, что везде же NSS одна и та же.

Тут стоит сразу закрыть придирку, которая иначе прилетит в комментарии: Go в принципе умеет резолвить и через NSS, если собран с cgo и он доступен на платформе. Но статически слинкованный бинарь — а это ровно то, что обычно льют в прод (CGO_ENABLED=0, никакой libc-зависимости, один файл, копипаст на сервер) этой возможности лишен по построению. Со стандартной статической сборкой Go использует свой собственный, чистый резолвер, написанный на Go, который парсит resolv.conf сам и ходит в DNS сам, минуя NSS, glibc и все, о чем мы говорили выше, целиком.

Это значит следующее: ты можешь идеально настроить nsswitch.conf, добавить нужную запись в /etc/hosts, все перепроверить через getent, но твой Go-сервис все равно этого не увидит, потому что он вообще не спрашивает те источники, которые ты только что поправил. Он живет в своей отдельной реальности резолвинга, которая пересекается с системной только в одной точке — в resolv.conf, да и то не полностью.

Как я до этого докопался

Я это все, честно говоря, не вычитал заранее — я это выковырял руками, комбинацией dig, getent hosts, resolvectl status с легкой злостью. У каждой команды свой кусок правды, ни одна не показывает полную картину, и собрать их вместе в голове каждый раз совсем не кайф, особенно когда уже третий час ищешь глазами несуществующую опечатку. А пресловутый ИИ путается, несет пургу и лишь добавляет сомнений в адекватности происходящего.

В какой-то момент стало проще написать тулзу, которая проходит эту цепочку сама именно так, как ее проходил бы резолвер ОС и параллельно делает независимый DNS-запрос, чтобы явно показать: вот путь, вот его результат, а вот что говорит DNS напрямую, если их спросить в обход всего. Если расходится — вот тебе конкретная причина, а не “попробуй еще раз с флагом -v”.

Так появился gai — от getaddrinfo, а не то, что вы подумали.

$ gai doctor testhost.local

[gai] Simulating name resolution for "testhost.local"... (reality check via 212.227.123.16, 212.227.123.17, systemd-resolved stub: true) RESOLUTION PATH (simulated): 1. Files FOUND 10.0.0.1 DIAGNOSIS:

┌─ ISSUE ──────────────────────────────────────────────────────────────────┐ │ The OS chain and a direct DNS query disagree: 10.0.0.1 vs (none). │ │ Something earlier in the chain (files/mdns) is answering instead of DNS. │ └──────────────────────────────────────────────────────────────────────────┘

Никакого перехвата процессов, никакого LD_PRELOAD, никакого eBPF или ptrace — gai просто читает ту же конфигурацию, что читает сам резолвер ОС (nsswitch.conf, resolv.conf, gai.conf, /etc/hosts, D-Bus-состояние systemd-resolved, одноразовый mDNS-запрос), и честно моделирует путь, которым прошел бы NSS-диспетчер glibc. Отдельно он умеет заметить статический Go-бинарник и прямо сказать, что для этого процесса вся симуляция выше не имеет значения, у него свой резолвер.

Как поставить тулзу и что дальше

Ставится одной строкой, без Rust-тулчейна, без зависимостей вообще — статический бинарник, который просто лежит и работает.

Пойдет в /usr/local/bin/gai с обычными правами 0755 — как любой другой системный бинарник, ничего экзотического. Если хочется собрать самому — cargo install gai-inspector или cargo build --release из исходников, все через crates.io. Никакого рантайма с собой не тащит, ни Python, ни JVM, ни shared-либ, за которые надо переживать при переносе на голый сервер. Скачал, chmod не нужен даже, и можно спрашивать gai doctor <имя> хоть в контейнере, хоть на минимальном Alpine-образе.

Инструмент пока Linux-only и MVP:

• Split-DNS/per-link-роутинг (VPN-зоны вроде Tailscale, о которых я говорил выше) он пока не умеет и честно репортит NOT FOUND вместо того чтобы соврать, но и не резолвит.

• IPv6 mDNS — в процессе.

Репо: github.com/casablanque-code/gai. Там подробнее про возможности и флаги.

Если случится ситуация, где gai тоже наврал — тем более буду рад услышать. Код открыт, пулл реквесты принимаются. Интереснее разобрать баг, чем сделать вид, что такого не бывает.

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

В 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 — в отдельном руководстве.