Если о проблеме с сервером вы узнаёте от сотрудников, мониторинга по сути нет. Разбираю, что стоит отслеживать в небольшой компании, как настроить оповещения, чтобы их не игнорировали, и что выбрать: Zabbix или Prometheus.
Типичная картина без мониторинга: утром бухгалтер сообщает, что «база не открывается», и начинается расследование. Выясняется, что ночью закончилось место на диске, резервная копия не сделалась, а база остановилась. Всё это можно было увидеть заранее — место заканчивалось не за одну ночь.
Задача мониторинга — не красивые графики, а своевременное уведомление о том, что требует внимания, до того как это станет аварией.
Не нужно начинать с сотен метрик. Для небольшой инфраструктуры я начинаю с короткого списка, который закрывает большинство реальных проблем:
| Что | Почему важно |
|---|---|
| Свободное место на дисках | Самая частая причина остановки баз данных и почты |
| Доступность ключевых сервисов (HTTP, почта, 1С, VPN) | Сервер может работать, а сервис на нём — нет |
| Результат резервного копирования | Копия, которая не делается, обнаруживается только при попытке восстановиться |
| Срок действия TLS-сертификатов и доменов | Истёкший сертификат «ломает» сайт и почту в один момент |
| Состояние интернет-каналов | Особенно если есть резервный канал — нужно знать, что офис на нём |
| Состояние дисков (SMART) и RAID | Деградация массива часто незаметна до второго отказа |
| Нагрузка: процессор, память | Помогает понять причину «тормозов» и планировать рост |
Главная ошибка — слишком много уведомлений. Если мониторинг каждый день присылает десятки сообщений о кратковременных всплесках нагрузки, через неделю их перестают читать, и важное сообщение тонет в шуме. Несколько правил, которых я придерживаюсь:
Пример правила для Prometheus: уведомить, если на файловой системе меньше 10% свободного места дольше 15 минут.
groups:
- name: base
rules:
- alert: DiskAlmostFull
expr: |
node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}
/ node_filesystem_size_bytes{fstype!~"tmpfs|overlay"} < 0.10
for: 15m
labels:
severity: warning
annotations:
summary: "Мало места на {{ $labels.instance }} ({{ $labels.mountpoint }})"Оба инструмента открытые и бесплатные, оба подходят для бизнеса. Выбор зависит от того, что именно нужно наблюдать:
Для небольшой компании я обычно выбираю что-то одно, чтобы не поддерживать две системы. Иногда к основному мониторингу добавляется простая внешняя проверка доступности сайта — чтобы узнать о проблеме, даже если упал весь офис вместе с сервером мониторинга.
Подключение мониторинга — первый шаг, с которого начинается IT-аутсорсинг, и одна из типовых задач в направлении «Серверы и DevOps».
Опишите, какие серверы и сервисы есть в компании. Я предложу, что и как поставить на мониторинг.
Обсудить задачуПочему копия на соседнем диске - это ещё не бэкап, как применить правило 3-2-1 в небольшой компании и почему резервная копия считается существующей только после проверки восстановления. С примером на restic.
Почему «плоская» сеть, где все устройства видят друг друга, - главный источник проблем в небольшом офисе, и как разделить её на VLAN на MikroTik с RouterOS 7: схема, настройка моста, правила firewall и типичные ошибки.
Как настроить второй интернет-канал так, чтобы офис переключался на него сам и возвращался обратно, когда основной провайдер восстановится. Рекурсивная маршрутизация на MikroTik, проверки доступности и подводные камни.