Полезные оповещения мониторинга: условия, восстановление и доставка в Fleetd

Общая панель для серверов и маршрутизаторов удобна, но мониторинг выполнен лишь наполовину, если для обнаружения проблемы её приходится открывать каждый день. Добавить оповещения о CPU, диске и пропавшем устройстве просто. Сложнее сделать уведомления полезными.

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

Пятая статья посвящена Fleetd v0.3.0. После установки агента на Linux и OpenWrt проследим путь от отчёта к событию, уведомлению и закрытию проблемы.

Что именно означает предупреждение

Fleetd проверяет отсутствие отчётов, CPU, память, место на диске, inode, отказавшие службы, проблемные контейнеры и давность рукопожатия WireGuard. Изменение адреса подключения — отдельное разовое событие.

Сигналы различаются по смыслу. Заполненный диск может остановить запись, высокая CPU — быть запланированной сборкой, старое рукопожатие — следствием отсутствия трафика. Превышение порога само по себе не доказывает отказ приложения.

Сначала уведомление должно назвать машину, объект и сработавшее условие. Диагностика зависит от назначения машины. Fleetd предоставляет конкретные проверки, а не автоматический поиск первопричины, и не перезапускает службы только из-за высокой CPU.

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

По умолчанию пороги CPU и памяти — 90%, окно — пять минут:

alerts:
  offline: 40s
  cpu_percent: 90
  mem_percent: 90
  sustain: 5m
  disk_percent: 90
  inode_percent: 90
  wg_handshake: 5m

Это значения v0.3.0, не универсальный рецепт. Они задаются для сервера целиком; отдельных порогов по машинам в этой конфигурации нет.

Представим короткую задачу с CPU 98%, после которой нагрузка падает, и машину с длительной перегрузкой. Это иллюстрация, не измеренные инциденты. Окно отсекает первый случай и помогает обратить внимание на очередь, процесс или ожидаемую работу во втором.

Fleetd берёт минимум значений CPU и памяти в недавнем окне. Если минимум выше порога, выше него все полученные выборки. Это не среднее значение и не счётчик отдельных превышений. Ровно 90% не считается превышением 90%.

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

Использование памяти вычисляется как общий объём минус MemAvailable, делённое на общий объём. Весь Linux-кэш не объявляется недоступным автоматически, а предупреждение не является диагнозом утечки памяти.

Офлайн означает отсутствие отчётов

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

Причиной могут быть остановка агента, питание, маршрутизатор, DNS или путь к серверу. Само уведомление их не различает. Несколько пропущенных отчётов допускаются; планирование, БД и почта влияют на задержку. Письмо ровно через сорок секунд не гарантируется.

Одобренная машина, которая ещё ни разу не отчиталась, не считается произошедшим отказом. После старта сервера новые офлайн-оповещения ждут offline + 15s: по умолчанию около пятидесяти пяти секунд для переподключения.

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

Потеря связи не должна закрывать прежний сбой

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

Fleetd сохраняет открытые предупреждения офлайн-машины, не создаёт и не закрывает другие состояния по её устаревшим данным и добавляет офлайн, когда позволяет стартовый льготный период.

После возврата отчётов оценка продолжается. Офлайн может закрыться, а диск остаться проблемным. Восстановившаяся связь не освобождает место.

Медленные сборщики работают в другом масштабе времени

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

Проверка	Текущее условие
Диск	Занятый процент точки монтирования выше порога
inode	Процент занятых inode выше порога
Службы	Получен отказавший юнит systemd
Контейнеры	Restarting, unhealthy или ненулевой выход
WireGuard	Давность рукопожатия ранее связанного пира выше порога

Диски и inode не используют пятиминутное окно CPU: проверяется последний сохранённый медленный отчёт. Inode важны отдельно, поскольку свободные байты ещё не гарантируют возможность создать новые файлы.

Контейнеры с кодом выхода 0 игнорируются: нормальное завершение одноразовой задачи не обязательно является сбоем. Ненулевой выход, unhealthy и состояние restarting учитываются. Число перезапусков за минуту здесь не подсчитывается. И running не доказывает исправность прикладного API.

WireGuard проверяет только пиры с прошлым рукопожатием, пропуская никогда не соединявшиеся. Возраст вычисляется относительно времени отчёта агента, без смешивания с часами сервера. Это признак, не полноценный тест доступности. Для нерегулярно активных пиров нужно понимать трафик и keepalive. wg_handshake: 0 отключает правило глобально; исключений по отдельным пирам здесь нет.

Закрытие означает прекращение действия правила

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

На онлайн-машине одна выборка CPU или памяти на уровне порога либо ниже нарушает условие «все выше». Отдельного нижнего порога восстановления или ожидания ещё двух минут стабильности нет. Длительное условие открытия не означает такое же условие закрытия.

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

Реализация не полностью различает «успешно проверено и исправно» и «проверка недоступна». Закрытая запись не является независимым доказательством восстановления приложения. Как обсуждалось ранее, сбор отказавших служб опирается на systemd, а не на полноценную проверку procd в OpenWrt.

Устранение повторов не гарантирует доставку

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

Дополнительного многоминутного окна агрегации и периодических напоминаний о незакрытой проблеме нет. Разовые события вроде смены адреса отправляются отдельно и не обязательно объединяются с периодической проверкой.

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

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

Почта — лишь один выход

SMTP отправляет изменения заданным получателям. Если нет хоста или адресатов, уведомления попадают в журнал, а состояние остаётся доступным в панели. language: zh задаёт китайский для серверных сообщений и почты; язык веб-интерфейса выбирается отдельно в браузере.

Метрики хранятся семь дней, закрытые предупреждения — девяносто, с периодической очисткой. Старое событие может сохраниться без подробных графиков. Для длительных расследований нужна отдельная политика хранения.

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

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

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

Сценарий	Что наблюдать
Короткий пик CPU	Одна высокая выборка не создаёт устойчивое предупреждение
Длительные высокие тестовые данные	Одно открытие после покрытия окна, без повторных открытий
Отчёты прекращаются при сбое	Прежний сбой остаётся, офлайн добавляется по условиям
Отчёты возвращаются, сбой остаётся	Офлайн закрывается, исходная проблема сохраняется
SMTP недоступен	Запись и ошибка отправки, без ожидания автоповтора
Сборщик недоступен	Проверить влияние отсутствующих данных на закрытие

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

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

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