В предыдущем руководстве вы настроили собственную систему резервного копирования Proxmox полностью через панель управления, а именно: запланированное задание, реальный путь восстановления и полноценный запуск vzdump, зафиксированный от начала до конца в собственном журнале задач. Ручной мониторинг этого журнала возможен только тогда, когда кто-то действительно смотрит на экран, поэтому это заключительное руководство замыкает цикл: считывание информации, которую Proxmox уже отслеживает о своих собственных ресурсах, и преобразование определённых событий в уведомления, которые человек действительно увидит.
Ознакомьтесь со встроенными графами ресурсов
Страница «Сводка» каждого узла открывается с блоком данных в режиме реального времени ещё до того, как загрузится хотя бы один график: загрузка ЦП, средняя загрузка системы, использование ОЗУ, свободное место на диске, задержка ввода-вывода, распределение KSM и использование свопа - все эти показатели считываются непосредственно с хоста, а не рассчитываются приблизительно. На этой же странице также чётко указано, на каком именно аппаратном и программном обеспечении работает данная платформа - на это стоит обратить внимание при первом загрузке.
Статус репозитория стоит прочитать, а не пропускать мимо: этот конкретный узел указывает на репозиторий, не готовый к производственной эксплуатации - тот самый бесплатный репозиторий без подписки, на котором выполнялась вся эта лабораторная работа с самого первого руководства; это реальное и правильно отображенное предупреждение, а не просто косметическое напоминание. Графики «Час», «День», «Неделя», «Месяц» и «Год» отображают одни и те же данные по ЦП, памяти, сети и диску с более грубым разрешением по мере увеличения диапазона времени - этого достаточно, чтобы обнаружить медленную утечку памяти или незаметно заполняющийся диск, не прибегая к каким-либо инструментам за пределами самой панели.
Сохраняется ли история этого графика после перезагрузки?
Да. Proxmox сохраняет эти данные на диске в формате RRD - том же формате циклического записывания (round-robin), который Munin и Cacti используют уже много лет, поэтому при перезапуске все ранее записанные данные сохраняются, и система просто продолжает запись в тот же файл.
Направлять реальные события в реальное уведомление
График полезен только тому, кто на него смотрит, поэтому в Proxmox предусмотрена совершенно отдельная система уведомлений: «Центры обработки данных» и «Уведомления» разделены на два списка, которые взаимодействуют друг с другом, а не объединены в одну длинную страницу настроек.
Посмотрите, что уже подключено
В новом узле обе половины уже настроены незаметно, ещё до того, как кто-либо заходит на эту страницу: одна цель и один сопоставитель, причём оба помечены как «Встроенные», а не как добавленные пользователем.
mail-to-root - это целевая запись в sendmail, указывающая на тот адрес, на который фактически разрешается root@pam. default-matcher (сопоставитель) намеренно оставлен неконкретным: он сопоставляет всё и направляет всё на этот единственный объект назначения, что и является причиной того, что для запуска vzdump из предыдущего руководства никогда не требовалась настройка уведомлений, чтобы уже иметь место, куда сообщать о сбоях.
Добавить пункт назначения веб-хука
Электронная почта работает, но операторы редко следят за ней в режиме реального времени, ожидая поступления сообщений, на которые нужно реагировать. На панели инструментов «Цели уведомлений» также доступны опции Gotify, SMTP и Webhook, причем именно Webhook позволяет отправлять уведомления куда угодно: на любой URL-адрес, принимающий запросы POST, с полным контролем над заголовками, телом сообщения и секретными данными.
Ничто в этой форме не предполагает наличия конкретного сервиса на принимающей стороне. Поле «Headers» предназначено для указания ключа API или переопределения типа контента, поле «Body» представляет собой шаблон свободной формы для JSON-данных в том виде, который ожидает принимающая сторона, а поле «Secrets» позволяет хранить токен отдельно от самого поля «Body», чтобы он никогда случайно не попадал в журнал задач или журнал аудита.
Направлять события, связанные с маршрутом, в него
Матчер определяет, какие события фактически поступают в заданный объект назначения; он построен на основе правил, которые по структуре напоминают фильтр поиска. Поле «Field» в рамках правила предлагает ровно пять реальных типов событий, каждый из которых привязан к конкретной части Proxmox, а не к вымышленному уровню серьезности:
- vzdump: уведомления о резервном копировании - именно к этой категории относится неудачное задание из предыдущего руководства.
- репликация: уведомления о заданиях репликации, актуальные с момента присоединения второго узла к данному кластеру.
- ограждение: уведомления об ограждении узлов, связанные с высокой доступностью (HA) и которые стоит направлять в какое-нибудь заметное место, как только будет налажена реальная система переключения при сбое.
- package-updates: простое уведомление о наличии обновлений, по своему характеру больше напоминающее сводку новостей, чем сообщение об инциденте.
- system-mail: всё остальное, что система в ином случае отправила бы по электронной почте локальному пользователю; это скорее общий категорийный термин, а не конкретное событие.
Если назвать этот матчер «backup-alerts» и в настройках «Targets to notify» (Цели для уведомлений) указать «ops-webhook» вместо полной замены «default-matcher», это означает, что оба правила теперь будут работать параллельно: событие vzdump поступает непосредственно в «ops-webhook», в то время как «default-matcher» по-прежнему перехватывает всё, включая уведомления о резервном копировании, и продолжает отправлять письма на адрес root@pam, как и раньше. Наложение нескольких матчеров таким образом является стандартной схемой, когда система оповещения выходит за рамки одного универсального правила.
Прежде чем использовать новый модуль сопоставления в производственной среде, сначала отправьте через него реальное тестовое событие. Функция «Тест» на панели инструментов «Цели уведомлений» немедленно отправляет реальное уведомление на выбранную цель - это самый быстрый способ убедиться, что конечная точка веб-хука действительно получает то, что обещает это диалоговое окно, прежде чем произойдет реальный сбой резервного копирования - это первое, что нужно выяснить.
Показатели экспорта для реальных информационных панелей и пороговых значений оповещений
Встроенные графики хорошо отвечают на вопрос «что произошло» - для тех, кто не забывает на них взглянуть. Однако они не дают ответа на вопрос «отправить кому-нибудь уведомление, как только загрузка ЦП останется выше 90 % в течение пяти минут», поскольку у самой Proxmox нет понятия порогового значения для метрик. Именно для устранения этого пробела и существует Metric Server, расположенный чуть выше в том же меню «Datacenter»: это потоковая передача в реальном времени всех метрик, которые уже собирает эта панель, в систему, созданную специально для этой задачи.
Graphite и InfluxDB - два давно существующих решения, которые уже давно используются в паре с Grafana именно для создания таких информационных панелей; OpenTelemetry - более новое, независимое от поставщиков решение, использующее тот же протокол, на котором уже стандартизируется все больше стеков наблюдаемости, независимо от того, какая база данных лежит в их основе.
Как только показатели попадают в базу данных временных рядов, оповещения о превышении пороговых значений перестают быть ограничением Proxmox: с этого момента дело берут на себя собственные правила оповещения Grafana или любые другие средства, способные запрашивать данные из InfluxDB или Graphite, которые отслеживают именно те же показатели, которые в этом руководстве всё это время просматривались визуально на странице «Сводка».
В заключение
- На страницах сводки по узлам и центрам обработки данных отслеживается история использования ЦП, памяти, сети и дисков за период до одного года; для быстрого просмотра не требуется никаких дополнительных инструментов.
- Система уведомлений разделяет цели (куда направляется оповещение) и модули сопоставления (какие события туда направляются), и оба этих элемента могут накладываться друг на друга.
- Конечный пункт веб-хука может быть любым URL-адресом - будь то Slack, Discord, PagerDuty или внутренняя панель мониторинга.
- Экспорт данных с Metric Server в Graphite, InfluxDB или OpenTelemetry - это именно то, что позволяет настраивать оповещения на основе пороговых значений, выходящие за рамки возможностей встроенных средств мониторинга Proxmox.
Трафик, проходящий через туннель, о котором шла речь ранее в этом руководстве, также имеет свои особенности, на которые стоит обратить внимание; они рассмотрены в статье самого Taipan справочник по измерению пропускной способности.