Всем привет! Меня зовут Серёга Леонов, я инфраструктурный инженер в Тинькофф. Недавно наша команда внедрила и приспособила уже привычный всем инструмент Zabbix под что-то новое — мониторинг и сбор инвентарных данных на всех компьютерах компании. Расскажу, как мы это сделали и какую пользу это принесло отделам, работающим с внутренними пользователями.
Первоначальная цель
У нас в Тинькофф больше 15 тысяч пользовательских машин. В основном это устройства на Windows и MacOS — есть как ноутбуки, так и стационарные компьютеры. Летом мы пришли к мысли, что это добро нужно хоть как-то, но мониторить. Причин было несколько:
Обращения в Helpdesk. Если у пользователя возникают проблемы, он оставляет заявку на внутреннем портале. Ребятам нужен удобный инструмент для диагностики, чтобы видеть, что происходит на машине и что могло вызвать сбой.
Сбор инвентарных данных. Тут можно собирать практически что угодно: версию ОС, модель ноутбука — любую информацию, которую способна выдавать ОС. Например, мы хотели видеть, на каких рабочих местах используются мониторы, а на каких простаивают без пользы. Плюс у нас была система учета оборудования, которую приходилось заполнять вручную. Мы же хотели добавлять в нее информацию автоматически.
Статистика по потреблению ресурсов внутренними приложениями банка. На наших компьютерах много разного ПО, в том числе внутренних разработок. После обновления какой-нибудь из программ может возникнуть memory leak и аномальная загрузка системы. Поэтому нам нужен централизованный инструмент сбора статистики, который может показать, сколько CPU и RAM потребляет каждая программа.
Мониторинг пользовательских устройств и пользовательского опыта — важная и нужная тема. К сожалению, в отличие от, например, DLP (систем для предотвращения утечек информации), она развита слабо и решений из коробки для этого нет.
В идеале под наши задачи нужно было написать собственный софт с кастомным веб-интерфейсом и нужными нам полями шаблонов. Но это дело долгое и трудозатратное, а интересную нам статистику надо было собирать еще вчера. Поэтому мы решили кастомизировать под себя один из существующих инструментов для мониторинга серверной инфраструктуры — Zabbix.
Zabbix мы выбрали из-за нескольких важных факторов:
Zabbix-агент спокойно раскатывается на всех трех имеющихся в компании ОС: Windows, MacOS и Linux. Его можно кастомизировать и написать дополнительные метрики — понятно, что не все наши хотелки будут поддерживаться из коробки.
Есть возможность поддержки push-модели сбора данных и авторегистрации агентов. Заводить в мониторинг 15 тысяч хостов вручную слишком долго и трудозатратно.
Перед стартом проекта и у нас, и у коллег из других отделов было много опасений, что все не заведется или не будет работать как надо. Опасались взрывного роста БД, тормозов на компьютерах пользователей, невозможности собирать какую-то информацию с компьютеров, предела, после которого Zabbix перестанет работать корректно. И боялись, что вся эта система устарела и ничего не будет работать.
Спустя полгода можно заявить, что ни одно опасение не подтвердилось. Конечно, возникали небольшие проблемы, которые приходилось оперативно решать. Больше всего пришлось повозиться с БД, но комбинация PostgreSQL + TimeScaleDB позволяет уверенно контролировать размер БД.
Архитектура проекта
Даже в инструкции на сайте Zabbix предлагают разворачивать сервер, БД и веб на одном сервере. Это нормально в рамках маленьких инсталляций, но в рамках крупных систем не работает. Поэтому изначально мы решили отделять все, что можно, друг от друга и максимально кластеризовать. В результате даже при падении одного из компонентов все продолжит работать. Плюс довольно быстро вся эта инфра обросла своими сервисами. NTP, Ansible, бэкапы, мониторинг — из-за того, что мы хостимся как отдельный проект в выделенном сегменте, все это пришлось поднимать с нуля.
По итогу сейчас на наш балансировщик приходит около 6 млн запросов в день и все работает корректно. Учитывая размер инсталляции, конечно, в процессе настройки системы у нас периодически возникали разные инфраструктурные проблемы:
Агенты слишком часто отправляли на сервер информацию, и в результате Nginx плохо справлялся с нагрузкой и выдавал 500-е. К счастью, конфиг Zabbix-агента позволяет уменьшить количество лишнего спама, да и директивы и лимиты на Nginx можно подправить.
Прокси начинали плохо справляться с нагрузкой. Решилось поднятием дополнительных. По опыту, где-то 1000 клиентов на прокси вполне норм.
БД начала расти как не в себя: на пике у нас было +60 гигов в день. Очень помог TimescaleDB, который сжал уже существующую базу в 4 раза и регулярно сжимает данные старше двух недель.
В результате сейчас у нас около 6 млн запросов на Nginx и все работает как надо.
Одна из наших главных задач — максимально автоматизировать цикл жизни машин внутри мониторинга.
Сначала срабатывает автоматическая регистрация агента — очень важная и полезная функция Zabbix, которая позволяет избежать ненужной ручной работы и при этом защититься от незваных гостей. При ее настройке с шифрованием и параметрами агента придется повозиться, но лучше повозиться, чем видеть в своем мониторинге сотни китайских имен или добавлять тысячи хостов руками.
Также мы написали ряд скриптов, взаимодействующих с API, которые переносят неактивные больше месяца машины в специальные архивные группы и возвращают их обратно в случае появления на хостах признаков жизни. Например если Helpdesk перезалил ноут уволившегося сотрудника, который долго лежал на складе. Очень полезная и интересная вещь для актуализации статистики, которую мы активно используем.
С помощью MDM-систем для MacOS и Windows мы довольно быстро покрыли почти весь парк имеющихся в банке машин. Сейчас все выглядит так:
Helpdesk заливает новую тачку.
С помощью MDM-системы на нее прилетает Zabbix-агент и сразу же получает актуальный конфиг.
Агент автоматически регистрируется на Zabbix-сервере.
Машина регулярно отправляет нам актуальные данные.
Если машина не отправляет данные больше месяца, она автоматически переносится в архивные группы.
Многих нужных нам метрик, конечно, нет в Zabbix из коробки. Но есть поддержка такой важной функции, как UserParameters, — небольших скриптов, встраиваемых в конфиг агента и позволяющих собирать любую доступную информацию с машин. Возможно, в плане настройки и раскатки это дольше, но в сто раз безопаснее, чем тот же system.run — встроенная в Zabbix-агент возможность удаленно запустить любую команду на хосте с агентом.
Сейчас большинство метрик, которые мы собираем, — это как раз юзер-параметры. К сожалению, в стандартных шаблонах из коробки нет многой нужной нам информации, поэтому, например, в нашем шаблоне для Windows почти все метрики из коробки мы заменили на наши кастомные.
С настройкой клиента под Windows нам пришлось повозиться больше всего. Наши юзерпараметры изначально были написаны на PowerShell. После массовой раскатки выяснилось, что на некоторых компьютерах наш антивирус не всегда адекватно реагирует на такой сбор информации и запускает бесконечные циклы проверок, очень сильно нагружая железо.
В исключения антивируса весь PowerShell вносить совершенно небезопасно, поэтому на проблемных хостах мы стали проводить разные эксперименты с настройками антивируса и даже меняли один антивирус на другой. Улучшения были заметны, но комплексно проблему это не решало. В итоге мы переписали все наши кастомные скрипты на Rust и сделали специальный клиент для запуска. Так мы смогли добавить клиент в исключения антивируса и избавиться от бесконечного цикла проверки.
С инвентори тоже все оказалось не так просто. Из практики я знаю, что мало кто собирает инвентарку с помощью Zabbix: его трудно использовать как полноценную IT Asset Management System. Но с помощью кастомных метрик у нас получается собирать почти все детали о системе: модель тачки, количество ОЗУ и CPU, подключенные мониторы, текущего активного пользователя и так далее.
Это полезно и для Helpdesk (когда поступает жалоба, удобно сразу смотреть на аппаратные характеристики), и для основных систем инвентаризации, с которыми мы синхронизируем наш Zabbix.
Единственная сложность в том, что Zabbix по неведомым причинам не поддерживает редактирование уже имеющихся полей в инвентори. Приходится править через редактирование сорсов — не очень удобно, но с этим можно смириться.
Практическое применение
Основной заказчик системы — отдел технической поддержки пользователей. Надо сказать, что ребятам система очень понравилась. Уже во время первых тестов они просили поставить на мониторинг тачки, по которым были сложные кейсы, и наша система помогала их решать.
Расскажу об одном из первых случаев. Дизайнер пожаловался в поддержку на необъяснимые тормоза. Ребята сразу посмотрели на мониторинг, увидели высокую температуру ЦП и высокий уровень троттлинга при выполнении рутинных операций типа запуска Zoom и оперативно решили проблему. Конечно, это можно определить и без Zabbix, но у тормозов может быть много причин. Благодаря Zabbix у ребят появляется много дополнительной информации и проводить диагностику становится проще.
Первая линия Helpdesk активно смотрит в Zabbix общую информацию о хосте. Во время обращения уже не нужны дополнительные вопросы и рутинные разговоры в духе:
— Посмотрите, пожалуйста, имя вашего компьютера.
— А как это сделать?
— Нажмите значок Windows в левом нижнем углу → «Система» → «О программе» и посмотрите на верхний пункт.
— А у меня Макбук.
Такие разговоры бесконечно утомляют и ребят с первой линии поддержки, и тех, кто к ним обращается. Теперь достаточно вбить логин пользователя и увидеть, за каким устройством он работает, какая у него ОС, сколько RAM, какой CPU и какие мониторы подключены. Так работать удобнее.
Вторая линия получила хороший инструмент для диагностики и сбора логов. Если раньше приходилось лезть в логи системы, которые не всегда понятны и наглядны, или верить пользователю на слово, то теперь у них появился удобный инструмент для анализа и диагностики.
Для руководства, админов приложений и третьей линии поддержки появился новый интересный инструмент аналитики. Практически сразу мы добавили в мониторинг метрики по потреблению CPU и RAM некоторыми приложениями, которые используются по всей компании. Думаю, в проде часто встречается ситуация, когда ПО при обновлении начинает задействовать ресурсы как не в себя. Теперь мы можем это оперативно отслеживать и в случае серьезных проблем откатывать обновления.
Заключение
Конечно, мы продолжаем все дорабатывать и развивать, делая упор на увеличение автоматизации, интеграции с другими системами компании и удобство конечного пользователя. В планах у нас:
Максимально интегрировать Zabbix и нашу систему учета оборудования. У нас уже реализована синхронизация между ними: данные по железу, которые отдает Zabbix, автоматически попадают в ITAM для сравнения и обработки. В будущем мы планируем дополнить эту интеграцию. Например, сделав автоматическое удаление неактуальных или выведенных навсегда из эксплуатации машин из Zabbix.
Добавить связь Zabbix и Service Desk. Думаю, у многих была ситуация, когда комп подтормаживает. Это напрягает, но работы слишком много и времени написать о проблеме в Service Desk банально нет. Тут нам и поможет Zabbix. Ребятам из технической поддержки будет автоматически прилетать задача о серьезных проблемах на том или ином хосте, и они уже будут проактивно связываться с пользователем и смотреть, что пошло не так.
Анализировать собранную Zabbix информацию с помощью DWH. Информации, которую нам отдает Zabbix, очень много, и она крайне полезна. С помощью этой информации можно построить важную для компании аналитику. Например, на основе метрик по загрузке RAM и CPU понять, насколько та или иная модель ноутбука подходит для работы разных отделов и по ситуации увеличить или уменьшить объем ее закупки. Или, например, узнать, сколько человек в среднем работают за той или иной стационарной машиной в офисе. Простор для аналитики тут действительно очень широкий.
Проект был довольно необычным и рисковым, а сроки реализации очень маленькими. Тем не менее продукт получился по-настоящему классным и удобным для отделов, работающих с внутренними пользователями. И мы, и заказчики системы очень довольны получившимся результатом и пользой для бизнеса, которую приносит наша система мониторинга.
С появлением новых инструментов мониторинга Zabbix стал считаться системой отчасти устаревшей. Почти все воспринимают его как инструмент сбора данных по серверам и сетевым устройствам. Но немного поводив по нему напильником, вполне реально сделать инструмент для мониторинга пользовательских устройств.
