Checkmk: мониторинг инфраструктуры

Checkmk — система мониторинга, которая объединяет агентский и безагентный опрос, проверки доступности и гибкие правила. В отличие от тяжёлых платформ, её можно поднять на одном сервере и постепенно расширять. Raw Edition полностью открыта и не требует лицензии. Ниже — установка, регистрация агентов, правила, локальные проверки и обслуживание.

Из чего состоит Checkmk

Сервер мониторинга называется сайтом. Внутри сайта работают ядро, веб-интерфейс, планировщик проверок и база RRD с метриками. Пакет check-mk-raw ставит код, а команда omd создаёт из него изолированный экземпляр со своим пользователем, портом и каталогом /omd/sites/<имя>. На одном хосте может жить несколько сайтов, например тестовый и рабочий.

Агент — небольшая программа на наблюдаемом хосте. Она собирает данные и отдаёт их по TCP, а сервер преобразует вывод в сервисы. Для сетевого оборудования и облачных API есть специальные агенты, которые опрашивают SNMP или REST и не требуют установки чего-либо на устройство.

Установка сервера

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

wget https://download.checkmk.com/checkmk/2.4.0p39/check-mk-raw-2.4.0p39_0.bookworm_amd64.deb
sudo apt install ./check-mk-raw-*.deb
sudo omd create monitoring
sudo omd start monitoring

omd create выведет начальный пароль администратора cmkadmin и адрес веб-интерфейса. Дальше сайт доступен по HTTP на порту 80 или через настроенный reverse proxy с TLS. Сразу после входа смените пароль и включите аутентификацию по LDAP или через локальных пользователей с ролями.

sudo omd status monitoring
sudo omd su monitoring
cmk --version

Агент и регистрация

Пакет агента лежит на самом сервере и совпадает с ним по версии; ссылку берут в Setup → Agents → Linux. Агент из репозитория дистрибутива не подойдёт — версии разойдутся.

wget http://cmk.example.net/monitoring/check_mk/agents/check-mk-agent_2.4.0p39-1_all.deb
sudo apt install ./check-mk-agent_2.4.0p39-1_all.deb
sudo systemctl status check-mk-agent.socket --no-pager
sudo cmk-agent-ctl register --hostname web01 --server cmk.example.net:8000 \
  --site monitoring --user cmkadmin

Если регистрация не проходит, проверяют доступность порта 8000, имя в сертификате и часы на обеих машинах: рассинхронизация ломает TLS.

Хосты, правила и сервисы

Хост добавляют в Setup, указывая имя и способ опроса. Дальше работает discover: Checkmk сам предлагает сервисы, которые нашёл у агента, — файловые системы, сетевые интерфейсы, процессы, пакеты. Правила задают пороги и параметры; они наследуются по цепочке от общего правила к папке и конкретному хосту.

sudo omd su monitoring
cmk -II web01
cmk -d web01 | head -40
cmk -R

cmk -II запускает обнаружение сервисов, cmk -d показывает сырой вывод агента, cmk -R перечитывает конфигурацию. Изменения в веб-интерфейсе вступают в силу после активации, иначе они лежат в очереди и не влияют на проверки.

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

Локальные проверки и логи

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

sudo tee /usr/lib/check_mk_agent/local/backup_age <<'EOF'
#!/bin/sh
echo '0 "backup_age" age=3600;7200;10800 OK - последняя копия час назад'
EOF
sudo chmod +x /usr/lib/check_mk_agent/local/backup_age

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

Сеть и оборудование

Для коммутаторов и роутеров используют SNMP. В Setup создают правило опроса, указывают версию протокола и community, а сервер сам определяет модель и набор метрик. Не включайте SNMP v1 в рабочей сети: строки сообщества ходят открытым текстом. Если оборудование поддерживает только v2c, ограничьте доступ по ACL на самом устройстве.

sudo omd su monitoring
cmk --debug -vvn switch01
snmpwalk -v2c -c public 192.168.10.1 sysDescr

Для распределённой схемы на удалённой площадке поднимают второй сайт и добавляют его в настройках основного как отдельную площадку. Локальные проверки продолжат работать при обрыве канала, а результаты догрузятся позже. Это надёжнее, чем опрашивать удалённый сегмент через один медленный туннель. Для старых устройств без SNMP остаётся проверка ICMP и доступности портов. Она не заменяет метрики, но ловит выключенное питание и обрыв кабеля.

Оповещения и обслуживание

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

sudo omd backup monitoring /backup/monitoring-$(date +%F).tar.gz
sudo omd restore monitoring /backup/monitoring-2026-01-01.tar.gz
sudo omd status monitoring
tail -50 /omd/sites/monitoring/var/log/web.log

Бэкап сайта включает конфигурацию и историю; одного дампа базы недостаточно. Раз в квартал проверяйте восстановление на чистом тестовом сайте — непроверенная копия не считается резервной. После обновления пакетов сайт перезапускают через omd restart, а версию пакета и сайта держат в одной ветке.

• Следите за размером каталога var/rrd: история метрик растёт и требует места.
• Старые хосты удаляйте вместе с данными, иначе они остаются в отчётах.
• Пороги пересматривают после изменения нагрузки, иначе ложные срабатывания станут привычкой.

Итог

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