Мониторинг: Zabbix рассказывает о проблеме раньше клиента
Обращение обычно приходит от человека: позвонил, написал, пришёл
в кабинет. Но половина работы аутсорсера начинается иначе — упал
сервер, кончилось место, отвалился канал. Об этом раньше всех узнаёт
мониторинг, и если он живёт в отдельном окне, то знание остаётся
у того, кто в это окно смотрит.
Ламантин подключается к вашему Zabbix и показывает его тревоги
рядом с заявками — в разрезе клиентов, а не хостов.
Мониторинг остаётся вашим
Менять ничего не нужно: система только читает. Нужен адрес Zabbix
и токен API на чтение. Мы не подтверждаем события, не гасим триггеры
и ничего не пишем на вашей стороне.
Опрос, а не оповещения: система сама спрашивает Zabbix раз в минуту.
Поэтому её остановка ничего не теряет — связь вернулась, и активные
проблемы снова на экране.
Когда у клиента свой Zabbix
Обычная схема — один ваш Zabbix, в котором лежат хосты всех клиентов.
Но приходит крупный клиент со словами «у нас своя инфраструктура,
нам удобнее отдать вам наш Zabbix, чем заводиться в вашем». Это
нормальный случай, а не исключение: подключений может быть несколько,
и у подключения клиента указывается его фирма — все хосты такого
Zabbix сразу её.
Подключения принадлежат вашей организации: другие компании
на платформе их не видят.
Главная работа — разбор
Первое подключение приносит всё хозяйство разом: сотни хостов,
у которых в имени и группах записано что угодно, кроме «чей это
клиент». Пока хост не отнесён к фирме, его тревоги видны, но
заявок не порождают — система не угадывает, чей это сервер.
Разбор устроен как работа со списком: фильтры, отметки, привязка
пачкой. Основную массу разбирают правила:
- по группе хостов — если группы уже названы по клиентам;
- по маске имени — если у хостов клиента общий префикс;
- по тегу — если разметка в Zabbix уже ведётся.
Правила трогают только неразобранное: то, что вы привязали руками,
остаётся как есть. Смысл в том, чтобы правило сделало девяносто
процентов, а человек — остаток.
Совет из практики: если разметки в Zabbix нет вовсе, дешевле сначала
навести порядок там (группа на клиента), чем разбирать хосты руками
здесь и повторять это при каждом новом сервере.
Хост как рабочее место человека
Сервер принадлежит фирме, а рабочая станция — конкретному человеку.
Хост можно закрепить за сотрудником клиента, и тогда обращение
по его машине сразу знает, кто за ней сидит: инженеру не приходится
выяснять, кому звонить.
«Шторм из прошлого»
В любом живом Zabbix висят тревоги, до которых руки не дошли:
предупреждения о месте на диске, недоступный тестовый стенд,
триггер, о котором все забыли. Их бывают сотни, и некоторым
по несколько месяцев.
Поэтому при подключении система прямо спрашивает: заводить ли
заявки по тому, что уже висит, — и показывает число. По умолчанию
работа начинается с чистого листа: старое видно в разделе, но
в работу не сыпется. Разобрать его можно спокойно, по одной.
Тревога превращается в работу
Достаточно важная тревога, прожившая дольше заданной задержки,
становится заявкой в фирме своего хоста — со сроками и ответственным,
как любое другое обращение. Мелькнувшее работы не создаёт, подавленное
на время регламентных работ — тоже.
Повтор той же беды на том же узле ложится комментарием в открытую
заявку. Это важнее, чем кажется: Zabbix напоминает о проблеме снова
и снова, и без склейки один упавший канал за ночь превратился бы
в десяток одинаковых заявок, которые инженер перестанет читать.
А вот когда заявку закрыли и узел упал снова — это уже новое
обращение, и оно заводится заново.
Закрывает такую заявку всё равно инженер. «Железо снова отвечает»
и «с проблемой разобрались» — разные вещи, и решать это должен человек:
мониторинг видит симптом, а не причину.
Если хост закреплён за сотрудником клиента, он попадает в заявку
как обратившийся — и получает уведомления о ходе работ, хотя сам
ни о чём не просил. Для клиента это выглядит так, как и должно
выглядеть обслуживание: «нам починили раньше, чем мы заметили».