Узнаём об аварии от пользователей: закрыть мониторинг доступности и backup

Короткий ответ

Минимум мониторинга Contoso: доступность критичных сервисов и успех backup. Не начинайте с сотен метрик и красивых дашбордов. Сначала: ICMP/TCP до DC, файлов, SQL/1С, VPN, шлюза; проверка, что job копирования не failed/не завис; куда уходит алерт (дежурный, не общая простыня). Инструмент — Zabbix, Prometheus+Alertmanager, даже скрипт+почта на старте. Главное — реакция по P1.

Пинг не доказывает LDAP и SMB. Для DC проверяйте порт 389, для файлов 445, для HTTPS — 443 на нужном имени.

Симптомы и как отличить

Типичная картина:

• пользователи: «уже два часа нет 1С»;
• backup красный с пятницы, увидели в понедельник;
• 400 алертов «disk 80%» которые никто не смотрит;
• мониторинг стоит, но шлёт на admin@, который не читают ночью.

Отличия:

Возможные причины

1. «И так звонят».
2. Поставили продукт, не настроили action.
3. Шум, отключили всё.
4. Нет списка критичных из CMDB.
5. Backup-консоль в другой вселенной, не в том же алертинге.
6. Редко: мониторинг в той же VM, что DC — падает вместе.

Диагностика

1. Что критично

Из Services: всё с P1/P2 при полном падении. Узлы из инвентаря.

2. Есть ли вообще проверка

С jump:

foreach ($n in @('DC01.contoso.example','FILE01.contoso.example','10.0.10.1')) {
  Test-NetConnection $n -Port 389 -WarningAction SilentlyContinue |
    Select-Object ComputerName, RemotePort, TcpTestSucceeded
}
Test-NetConnection FILE01.contoso.example -Port 445

nmap -Pn -p 22,389,445,443 10.0.10.10 10.0.10.20   # только свои адреса
curl -fsS https://zabbix.contoso.example/ | head

Если nmap для инвентаря вы уже делаете, мониторинг — то же, но непрерывно и с алертом.

3. Backup

Есть ли письмо/трап на fail? Кто последний раз открывал? Дата. Если «смотрим глазами раз в неделю» — это не мониторинг.

4. Куда алерт

Проверьте реальный ящик/SMS/мессенджер дежурного. Тестовый алерт в рабочий день. Ночной — если обещан SLA 24/7.

Решение

Слой A. Доступность (неделя 1)

Список checks:

Два DC: падение одного — P2 (деградация), обоих — P1. Зафиксируйте.

Слой B. Backup (та же неделя)

Fail job, нет успешного цикла за 26 ч при ночном расписании, репозиторий недоступен. Не «диск 95%» в первый день, если это заглушит важное. Место репозитория — второй этап.

Слой C. Хост Linux/Windows

# Ubuntu: node exporter или zabbix-agent в mgmt
systemctl is-active zabbix-agent2 nginx

Диск 100% на DC — P1. На тестовой VM — P3.

Куда ставить сервер мониторинга

Не только на том же HV01 без второй копии. Хотя бы экспорт алертов наружу (почта в облаке, SMS). Иначе DRP «мониторинг умер вместе с площадкой».

Шум

Каждый алерт без действия за неделю — кандидат на порог/исключение. Иначе через месяц отключат всё.

Тестовый алерт и эскалация молчания

После настройки checks: остановите агент на некритичном тесте или закройте порт 445 файрволом на 5 минут в согласованное окно на RESTORE01, не на FILE01. Должны прийти письмо/SMS и (если так задумано) тикет. Замерьте минуты. Нет сигнала — чините action, не добавляйте новые метрики.

Эскалация: если P1 не ack за время SLA, звонок Ивану Петрову. Запишите это в том же месте, что SLA. Мониторинг без эскалации — радио, которое никто не слушает.

Не кладите сервер мониторинга только на HV01 без второго канала (хотя бы внешняя почта). Иначе сценарий DRP «умер хост» вы узнаете от охраны, не от системы.

Отдельно повесьте check «успех Daily-VMs / restic за 26 часов». Backup fail ночью при обнаружении утром — уже нарушение, если SLA ночное; если покрытие 08–18, честно начните рабочий день с очереди fail.

Как проверить, что проблема устранена

• Учебное выключение (в окне) ping-check: алерт пришёл за время реакции P1.
• Учебный fail backup (на тесте) или остановка агента: P2 создан.
• Список checks ⊆ критичные сервисы, лишнего шума мало.
• Дежурный знает, куда смотреть, без Ивана Петрова.

Список checks храните в CMDB или в git рядом с инвентарём узлов: сняли VM — сняли check в том же CHG. Иначе мониторинг орёт по кладбищу и приучает игнорировать P1. Раз в месяц удаляйте checks на выведенные узлы так же дисциплинированно, как заводите новые.

Если не помогло

• Почта режет алерты как спам: белый список, другой канал.
• Пользовательский VPN закрывает доступ к Zabbix: вынесите алерт, не требуйте GUI ночью.
• Слишком умный AI-мониторинг без простого TCP: вернитесь к портам.

Профилактика

• Новый сервис P1 не анонсируют без check.
• Разбор: «почему узнали от людей» — дефект мониторинга.
• Ревизия правил раз в квартал.
• Связка с CMDB узлов: сняли сервер — сняли check.

FAQ

Хватает ли ping?

Как первый слой — да. Для AD/SMB/HTTPS — добавьте порт или синтетическую транзакцию.

Zabbix обязателен?

Нет. Обязателен алерт до человека. Zabbix/Prometheus/PRTG — средства.

Нужно ли мониторить принтеры?

Не в минимуме, если не этикетки склада. Иначе очередь засорится.

Агент или agentless?

Agentless TCP с mgmt-хоста быстрее стартует. Агент даёт диск/CPU. Начните agentless на P1-портах.

Что с ложными срабатываниями ночью из-за бэкапа?

Окна maintenance в системе мониторинга на время job, не глобальный mute.

Мониторинг сам по себе P1 при падении?

Если вы обещаете ночной SLA — да, падение алертинга = слепота, эскалация Ивану Петрову.