Proxmox VE: Мониторинг Ресурсов и Оповещения (Часть 7)

Зачем серверу глаза и уши

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

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

Сразу оговорюсь: речь пойдёт именно о встроенных инструментах Proxmox. Про Prometheus, Grafana и Netdata я рассказываю в отдельных статьях — там глубже и красивее, но для ежедневного контроля хватает и того, что есть в гипервизоре из коробки. Начинать стоит с малого, иначе можно утонуть в настройках и графиках.

Шаг 21: смотрю на ресурсы

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

Потом я выучил главный индикатор — Load Average. Если коротко: это число показывает, насколько загружен процессор. Если оно больше количества ядер — сервер не справляется. У меня, например, четыре ядра, и когда load average держится выше четырёх, я уже понимаю: пора смотреть, какая виртуалка ест всё. Это как температура у человека: само по себе не диагноз, но повод задуматься.

Дальше я перешёл к разделу Graphs у хоста: там есть графики CPU, памяти и сетевого трафика с выбором периода — час, день, неделя, месяц. Мне больше всего помогли графики по неделе: видно, когда сервер нагружается, а когда спит. Так я, например, заметил, что по ночам кто-то стабильно жрёт процессор — оказалось, это были ночные бекапы. Сначала я подумал, что проблема, а потом понял, что всё закономерно.

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

Мониторинг виртуалок

Сам хост — это половина дела. Вторая половина — виртуалки. Для каждой VM и контейнера в Proxmox тоже есть свои Summary и Graphs: я открываю нужную машину в дереве слева и смотрю её графики. Так я понял, что мой Pi-hole живёт вообще на 2% CPU и 150 МБ памяти — после этого я перестал мучиться, что он «съест» сервер.

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

Кстати, важный нюанс про Task History — вкладку Tasks у хоста. Там записываются все операции: запуск виртуалок, бекапы, обновления. Когда что-то «само сломалось», я всегда начинаю поиски с этой вкладки: сразу видно, кто и что делал в момент проблемы. Часто это помогает быстрее, чем копаться в логах.

Шаг 22: настраиваю email-оповещения

Смотреть на графики — это хорошо, но сидеть и пялиться в монитор круглосуточно я не могу. Мне нужны были оповещения: сервер сам напишет мне, если что-то случится. В Proxmox за это отвечает почта: система шлёт письма на указанный адрес при сбоях, проблемах с бекапами и так далее.

Проблема в том, что по умолчанию письма уходят через локальный Postfix, который ничего не умеет отправлять наружу. Решение, которое я выбрал, — msmtp: лёгкий почтовый клиент, который пересылает письма через обычный SMTP-ящик. Я использовал Gmail (нужен пароль приложения), но подойдёт любой SMTP-сервис.

Установка простая: зашёл на хост по SSH и выполнил

apt update && apt install msmtp

Потом создал конфиг /etc/msmtprc с параметрами ящика:

account default
host smtp.gmail.com
port 587
auth on
user мой_email@gmail.com
password мой_пароль_приложения
tls on
tls_starttls on
aliases /etc/aliases

И настроил переадресацию: в файле /etc/aliases написал, что почта для root должна уходить на мой адрес:

echo "root: мой_email@gmail.com" > /etc/aliases

Проверил отправкой тестового письма:

echo "Test mail from Proxmox" | mail -s "Proxmox Alert Test" root

Письмо пришло за пару секунд. Дальше осталось включить уведомления в задачах: в Datacenter → Backup есть поле Email Notification — я поставил «Always», чтобы приходили и отчёты об успехе, и об ошибках. Теперь каждое утро я вижу письмо о ночном бекапе, а если что-то упадёт — прилетит письмо с ошибкой.

Шаг 23: syslog и логи

Иногда проблема не в ресурсах, а в непонятной ошибке. Тут помогает вкладка Syslog у хоста: это все системные логи Proxmox в одном месте, с поиском и фильтрами. Когда VM странно себя ведёт, в логах видно записи с её ID — например, VM 100.

Мне это спасло один вечер: контейнер внезапно перестал отвечать по сети, а в Syslog нашлась строка про ошибку сетевого интерфейса. Гугл по этой строке сразу дал ответ — оказывается, известная проблема с конкретной версией ядра, лечится обновлением. Без логов я бы потратил часы, а так управился за двадцать минут.

Если вкратце

1. Смотрите Summary и Graphs хоста и каждой VM — там вся картина по CPU, памяти и трафику.
2. Обращайте внимание на Load Average: больше числа ядер — сервер перегружен.
3. Вкладка Tasks покажет, что делалось на сервере в момент проблемы.
4. Поставьте msmtp и настройте email-оповещения о бекапах и сбоях.
5. При странных ошибках ищите в Syslog строки с ID вашей виртуалки.

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

Что я делаю, когда вижу тревожный график

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

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

Почему я не настраиваю всё сразу

Напоследок совет, который я вынес из собственных ошибок: не пытайтесь настроить мониторинг «по максимуму» в первый же вечер. Сначала освоите Summary и Graphs, потом прикрутите почту, через неделю — загляните в Syslog. Каждый инструмент должен прирастать под реальную боль, иначе вы просто соберёте панель с кучей графиков, на которые никто не смотрит.

У меня мониторинг рос вместе с сервером: сервисов стало больше — понадобились оповещения; оповещения начали шуметь — научился их фильтровать. Сейчас настройка занимает минимум, а польза — максимум. Это именно тот случай, когда «меньше, но работающее» лучше, чем «много, но брошенное».

Пара слов о том, чего не видно в веб-интерфейсе

Справедливости ради отмечу: веб-интерфейс Proxmox показывает далеко не всё. Если нужно что-то точечное — например, статистика по конкретному процессу внутри виртуалки или точная история нагрузки за год, — придётся заходить внутрь гостя и смотреть там. Но для 90% задач, с которыми сталкивается владелец домашнего сервера, встроенного мониторинга хватает с запасом.

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

Итог

Подведу черту. Мониторинг в Proxmox — это не отдельная наука, а три простые привычки: смотреть на Summary и Graphs, читать письма об ошибках и бекапах, заглядывать в Syslog при странностях. Всё это доступно прямо в веб-интерфейсе и не требует установки чего-то дополнительного. Я потратил на настройку один вечер, и с тех пор мой сервер сам рассказывает мне о своём состоянии.

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

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

Пробуйте, смотрите на цифры, и они быстро научат вас понимать свой сервер лучше, чем любая инструкция. Я до сих пор иногда открываю Summary просто посмотреть, как ровно работают графики, — и это странное удовольствие стало частью моей рутины.

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