Разворачиваем систему мониторинга

Про мониторинг вообще и Zabbix в частности написана куча статей, гайдов и HowTo: как установить сервер, подключить агент, настроить SNMP и добавить первый триггер.

Поэтому здесь не будем ещё раз разбирать установку Zabbix по шагам.

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

Исходные данные

Средняя компания.

Как обычно, со временем образовался некоторый зоопарк:

• физические серверы;
• виртуальные машины;
• сетевое оборудование;
• Windows и Linux;
• 1С;
• базы данных;
• сетевые сервисы;
• климатическая система серверного помещения;
• оборудование от разных производителей и разного возраста.

В идеале хочется видеть практически всё:

оборудование
    ↓
операционная система
    ↓
сервис
    ↓
прикладная система

Но пытаться сразу мониторить вообще каждую метрику — плохая идея.

Очень быстро получится несколько тысяч элементов данных, сотни триггеров и огромное количество событий, на которые никто не обращает внимания.

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

Сначала — железо

Первым делом начали с оборудования, на котором непосредственно работают сервисы.

Минимальный набор:

• доступность по сети;
• состояние дисков;
• заполнение дисков;
• температура;
• аппаратные ошибки;
• доступность основных интерфейсов.

Самая простая проверка:

сервер вообще отвечает?

полезна, но этого недостаточно.

Сервер вполне может отвечать на ICMP и при этом иметь:

деградировавший RAID
диск с ошибками SMART
100% заполненный раздел
перегретый CPU
неработающий сервис

Поэтому следующий слой мониторинга — состояние самого оборудования.

Для серверов с аппаратным RAID имеет смысл получать состояние контроллера и массивов. Для ZFS — состояние пула:

zpool status

В нормальном состоянии ожидаем:

state: ONLINE

Если появляется:

DEGRADED
FAULTED
UNAVAIL

это уже повод для события в Zabbix.

То же самое относится к SMART для отдельных накопителей.

Диски

Свободное место — одна из самых банальных, но при этом самых полезных метрик.

Проблема обычно выглядит так:

диск постепенно заполняется
        ↓
никто этого не замечает
        ↓
остается несколько мегабайт
        ↓
останавливается БД / логирование / сервис

Поэтому мы контролируем не только состояние накопителей, но и заполнение файловых систем.

Причём одного порога недостаточно.

Удобнее сделать, например:

свободно < 20%
→ warning

свободно < 10%
→ high

Для больших хранилищ абсолютный объём тоже имеет смысл учитывать: 10% от диска в 20 ТБ — это совсем не то же самое, что 10% от системного SSD на 120 ГБ.

Потом — критичные сервисы

Следующий уровень — уже не сама машина, а то, ради чего эта машина вообще существует.

Здесь универсального рецепта нет.

Для файлового сервера интересуют одни показатели, для PostgreSQL — другие, для 1С — третьи.

Например, для сервера 1С мы контролируем:

• состояние службы сервера 1С;
• доступность сервера;
• свободное место;
• состояние сопутствующей СУБД;
• количество используемых лицензий.

Проверка только службы:

srv1cv8 = running

ещё не означает, что система полностью работоспособна, но это хороший базовый сигнал.

Дополнительно мы подключили контроль лицензий 1С.

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

То есть:

лицензий: 100
занято:   91

→ alert

Это позволяет узнать о проблеме до того, как следующий пользователь получит сообщение об отсутствии свободной лицензии.

Именно такие прикладные метрики обычно оказываются значительно полезнее десятков стандартных графиков CPU.

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

Для MikroTik и другого сетевого оборудования базовые показатели получаем через SNMP.

Но здесь опять важно не пытаться мониторить каждый порт одинаково.

Например, падение свободного Ethernet-порта:

ether17 → down

может вообще никого не интересовать.

А вот:

uplink → down

или:

sfp-to-core → down

уже требует немедленной реакции.

Поэтому критичные интерфейсы помечаются отдельно.

Контролируем:

• состояние uplink;
• состояние SFP/SFP+;
• ошибки интерфейсов;
• загрузку каналов;
• при необходимости уровень оптического сигнала.

Например постепенный рост:

FCS errors
RX errors
drops

может предупредить о проблеме с линией задолго до полного падения линка.

Логи тоже надо мониторить

Следующий полезный источник — системные журналы.

Сам по себе факт появления записи в log ещё не должен создавать событие.

Но некоторые события действительно интересны.

Например:

authentication failure
brute force
RAID error
filesystem error
service crash
OOM

Для внешних сервисов особенно полезно отслеживать массовые попытки авторизации.

Типичный сценарий:

SSH / VPN / Web
      ↓
много неудачных авторизаций
      ↓
Zabbix
      ↓
warning / alert

Это не полноценная SIEM и не должно её изображать.

Но как дополнительный источник событий для небольшой инфраструктуры работает хорошо.

Мониторинг серверного помещения

Отдельно добавили совсем простой контроль серверного помещения.

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

Использовали:

Raspberry Pi
     │
     ├── датчик температуры
     │
     └── dry contact
          климатической системы

Raspberry Pi передаёт в Zabbix:

температуру
состояние аварийного контакта

Получается два простых параметра:

temperature = 23.4 °C

climate.contact = OK

При превышении заданного порога температуры:

temperature > threshold
→ alert

При срабатывании аварийного выхода кондиционера:

climate.contact = ALARM
→ alert

Причём второй параметр особенно полезен.

Температура помещения обладает определённой инерцией. После остановки кондиционера она ещё некоторое время может оставаться нормальной.

А аварийный контакт позволяет узнать о проблеме практически сразу:

кондиционер остановился
        ↓
контакт аварии
        ↓
Zabbix
        ↓
уведомление

ещё до того, как серверная успела нагреться.

Уведомления

Сам мониторинг бесполезен, если событие никто не увидел.

Поэтому мы используем два независимых канала.

Первый — обычная электронная почта.

Второй — специальный чат в Битрикс24.

Схема:

                    ┌── Email
Zabbix → Trigger ───┤
                    └── Bitrix24 API → чат мониторинга

Битрикс24 подключён через REST API.

В результате критичное событие появляется непосредственно там, где сотрудники и так работают в течение дня.

Например:

[HIGH]

siv-server-01

Недостаточно свободного места на /var

Свободно: 7.4%

При этом email остаётся независимым резервным каналом.

Это принципиально.

Если использовать только один способ доставки:

Zabbix
  ↓
Bitrix24

то при проблемах с Битрикс24 мы можем одновременно потерять и сервис, и уведомления о том, что с ним что-то произошло.

Поэтому:

Email
+
Bitrix24

дают два независимых маршрута доставки.

Сам Zabbix тоже может упасть

И здесь возникает один из самых важных моментов.

Если система мониторинга находится в том же инфраструктурном контуре, который она должна контролировать, можно получить неприятную ситуацию:

основная инфраструктура
        ↓
авария
        ↓
Zabbix тоже недоступен
        ↓
уведомлений нет

Например:

кластер виртуализации упал
        ↓
VM с Zabbix лежит на этом же кластере
        ↓
Zabbix тоже упал

С точки зрения мониторинга всё прошло идеально:

никто ничего не сообщил.

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

Не обязательно строить для него отдельный ЦОД.

Но если основная инфраструктура находится на одном кластере виртуализации, сервер мониторинга имеет смысл разместить:

• на отдельном физическом сервере;
• на другом кластере;
• в другой площадке;
• либо во внешнем VPS.

Схема становится такой:

        ОСНОВНАЯ ИНФРАСТРУКТУРА
        ┌─────────────────────┐
        │ Proxmox             │
        │ 1С                  │
        │ PostgreSQL          │
        │ MikroTik            │
        │ сервисы             │
        └──────────┬──────────┘
                   │
                   │ monitoring
                   ▼
        ┌─────────────────────┐
        │ Zabbix              │
        │ отдельный контур    │
        └──────────┬──────────┘
                   │
             ┌─────┴─────┐
             ▼           ▼
           Email      Bitrix24

Это уже намного надёжнее.

Что в итоге

Мы не пытались сразу собрать все возможные метрики.

Начали с того, что действительно может привести к простою:

оборудование
↓
диски
↓
сеть
↓
критичные сервисы
↓
прикладные показатели
↓
помещение
↓
логи

А затем добавили два независимых канала доставки уведомлений.

Главный принцип здесь довольно простой:

> Хороший мониторинг — это не максимальное количество графиков. Это минимальное количество действительно важных событий, о которых мы узнаём раньше пользователей.

Zabbix в этой схеме оказался просто удобным инструментом.

Основная работа была не в том, чтобы его установить, а в том, чтобы решить:

что именно для нашей инфраструктуры считается проблемой и когда об этом нужно сообщать.