Привет! Меня зовут Сергей Прутских, я руковожу направлением мониторинга компании «Сбербанк-Технологии». Основная задача нашей организации — разработка и тестирование программных продуктов для Сбербанка. Для этого в компании сосредоточена крупная ИТ-инфраструктура — 15 тысяч серверов разделены примерно на 1500 тестовых сред, которые относятся к более чем 500 автоматизированным системам. Всего с ними работает около 10 тысяч специалистов.
В 2015 году мы начали создавать централизованный сервис мониторинга. Причем все ограничивалось не только внедрением. Нужно было проработать множество регламентов, инструкций, а также взаимоотношения между подразделениями Сбертеха в рамках мониторинга. В этом посте я подробно расскажу, как мы выбирали платформу, по каким принципам все создавали и что в итоге у нас получилось.
Основные цели и идеология проекта
Вот какие цели мы преследовали в проекте:
- Получение достоверных данных о размерах и составе IT-инфраструктуры;
- Оптимизация использования ИТ-мощностей;
- Снижение затрат на поддержку и эксплуатацию IT-инфраструктуры сред разработки и тестирования;
- Поддержка IT-инфраструктуры в готовности к разработке и проведению испытаний;
- Оперативное информирование специалистов о неполадках в работе тестовых сред;
- Аудит соответствия окружений тестовых сред и промышленных АСМ — не очень типичная для нас задача;
- Сбор данных для отчетов по результатам тестирования, обеспечение измерения критических параметров на всех этапах тестирования.
Забегая вперед, могу сказать, что все цели в той или иной степени уже выполнены к настоящему моменту. И некоторые сопутствующие проблемы мониторинг тоже помог решить.
Помимо целей, мы сформулировали принципы, идеологию, которой придерживались по ходу всего проекта:
- Удовлетворенность пользователя — один из главных показателей работы мониторинга. На конференции ITSMf 2017 я рассказывал о мониторинге ИТ-инфраструктуры, и пятое НЕ в том докладе звучит так: «НЕ заставляйте ваших сотрудников работать с системой мониторинга». Смысл в том, чтобы мотивировать, а не обязывать. Достигается это за счет правильно выстроенных KPI. В начале работы сервиса такие KPI могут еще не появиться. Тем не менее, очень важно с первых дней работы мониторинга начать приносить пользу потенциальным заказчикам.
- Минимум времени на доработки. Для этого мы используем элементы Agile. Они помогают максимально быстро предоставлять новые функции и получать от заказчиков обратную связь.
- Открытость системы как для доработок, которая выражается в создании единого бэклога, запросы в который может писать любой сотрудник, так и в плане предоставления информации — наш сервис позволяет получить информацию о конфигурации мониторинга, которая, как правило, скрыта.
- Высокая степень интеграции в повседневную работу. В приоритете у нас стоит реализация функциональности, необходимой пользователям на ежедневной основе. Это помогло в относительно короткие сроки популяризовать сервис мониторинга внутри компании.
Выбор системы мониторинга
Практически во всех проектах, где я участвовал, рано или поздно всплывала таблица со сравнением функциональности различных систем, в которой какой-то конкретной системе отдавалось очевидное преимущество.
На мой взгляд, до непосредственного начала работы с сервисом мониторинга такой сравнительный анализ делать нельзя, и уж тем более не стоит принимать решение о выборе того или иного решения, исходя из этого анализа. До тех пор, пока система в вашей компании не проработает хотя бы на протяжении небольшого промежутка времени, нельзя однозначно судить о том, какие конкретно функции именно в вашей компании будут востребованы. Такие таблицы могут отлично помочь, если вы по каким либо причинам хотите сменить систему мониторинга.
Сравнение с другими инсталляциями Zabbix
Можно много говорить о том, как сравнить размер нескольких инсталляций систем мониторинга, но все выбранные для этого характеристики, на мой взгляд, довольно субъективны. Чтобы у вас появилось более точное представление о размере нашей инсталляции, я решил привести примеры аналогичных сервисов в других компаниях, о которых представители Zabbix рассказывали на конфереции Highload.
Как видите, инстанс Zabbix в Сбертехе не сильно уступает крупнейшим инсталляциям, а по суммарной нагрузке идет вровень с ними.
Преимущества Zabbix
Во второй половине 2017 года мы проводили пилот Zabbix для мониторинга ПРОМ-инфраструктуры. Тогда же мы сформулировали ряд качественных критериев, которые мы относим к безусловным преимуществам Zabbix:
- Open-source. Неограниченные возможности для обработки и кастомизации.
- Открытость механизма и источника сбора метрик. В коммерческих энтерпрайз-решениях многие метрики бывают непонятны — различные боттл-неки, утечки памяти, которые зачастую не может объяснить даже техническая поддержка вендора. У Zabbix такой проблемы нет — всегда можно четко сказать, как он собирает те или иные метрики. Таким образом, доверие к системе со стороны системных администраторов повышается.
- Относительная легкость масштабирования — прежде всего, за счет введения дополнительных прокси-серверов, на которые можно перенести часть нагрузки. В случае достижения предела производительности одного инстанса есть возможность поднять второй и объединить оба под одной системой визуализации (Grafana).
- Классный API — на мой взгляд, это одно из главных преимуществ Zabbix. Качественный, проработанный и понятный API открывает огромные возможности для интеграции со смежными системами, автоматизации и пр.
- Мониторинг динамических объектов — мелочь, а приятно. В Zabbix этот мониторинг прост и интуитивно понятен, позволяет очень быстро добиться хороших результатов. Динамические объекты — это любые объекты, которые появляются и исчезают на серверах в течение срока службы: файловые системы, сетевые интерфейсы, и другие. Поэтому возникает потребность в том, чтобы автоматизировать постановку и снятие этих объектов с мониторинга.
- Сравнительно малое количество компонентов. В коммерческих решениях каждый компонент — это отдельная подсистема с собственной базой, которую нужно отдельно устанавливать. А Zabbix — это единая система, в которой сосредоточены сразу все способы мониторинга: агентский, безагентский, сетевой и другие — всего 14 типов.
- Визуализация данных с Grafana. Интеграция с Grafana дает возможность строить графики и создавать действительно удобные дашборды.
- Наличие мониторинга доступности IT-услуг. В Zabbix есть встроенная подсистема, которая умеет подсчитывать доступность IT-услуг для дальнейшего использования в SLA.
- Гибкость создания метрик и их пороговых значений. Здесь Zabbix имеет широкие возможности для настройки сложных метрик мониторинга:
– прежде всего это создание вычисляемых метрик: на основе нескольких простых метрик вычисляется одна сложная.
– доступна предобработка значения метрик — это когда вы, например, загружаете в Zabbix какой-то большой массив данных, а потом, перед тем как положить в базу конкретную метрику, Zabbix анализирует массив и вытаскивает именно те данные, которые вы хотите сохранить в виде метрики.
– мастер-метрики. Существует возможность собрать массив данных по объекту за один опрос в одну большую метрику, а затем использовать ее как источник данных для других метрик. Это позволяет уменьшить количество запросов и синхронизировать сбор всех метрик по времени. - Возможность внутреннего мониторинга. Zabbix, как open source продукт, имеет проблемы с производительностью. Однако продуманная система внутреннего мониторинга помогает достаточно быстро справляться с этими проблемами.
Недостатки Zabbix
Справедливости ради не могу не упомянуть об основных, на мой взгляд, недостатках Zabbix. Из них тоже можно составить приличный список:
- Низкая степень автоматизации работы с бэкендом. Оговорюсь, что у меня не было возможности поэкспериментировать со всеми вариантами СУБД. В качестве бэкенда Zabbix в нашей компании используется СУБД Oracle. Массовые операции могут занимать более часа — например, обновление или изменение метрик, которое привязано к большому количеству объектов (15 тысяч узлов сети).
- Отсутствие встроенных средств управления агентами мониторинга. В коммерческих продуктах такие средства имеются. В Zabbix этого пока нет. Нет даже обновления инструментария на агентов. Конечно, все можно сделать самостоятельно, но лучше бы получить эти возможности «из коробки».
- Пока что низкая проработка мониторинга доступности IT-услуг. Здорово, что мониторинг есть, но его нужно еще дорабатывать. Сейчас не предусмотрена возможность как-либо ограничить доступ пользователей к каким-либо отдельным частям сервисно-ресурсной модели (далее СРМ). Если дерево СРМ большое, веб-интерфейс начинает тормозить. И возможности для кастомизации вычисления доступности в данной подсистеме пока что низкие.
- Долгие обновления. Последнее обновление базы данных заняло у нас порядка восьми часов. В это время сервис мониторинга был недоступен. Как вариант, можно запросить скрипты в поддержке и провести апдейт отдельно.
- Скромная функциональность встроенной подсистемы визуализации. Grafana решает эту проблему, однако встроенная визуализация пока что оставляет желать лучшего.
- Встроенный мониторинг СУБД (ODBC). Дело в том, что такой мониторинг открывает у Zabbix отдельное подключение при каждом опросе метрики. И если база у вас большая (с большим количеством собираемых метрик), то пул соединений в ней может переполниться и база перестанет отвечать на запросы, в том числе для целевых систем. В Zabbix есть альтернативный инструмент мониторинга (например, DBforBIX), но настраивать его для большого количества объектов — занятие достаточно трудоемкое. Плюс для этого нужно писать отдельную автоматизацию.
- Недостаточная гибкость инвентаризации IT-инфраструктуры. С одной стороны, приятно что она есть. С другой — выглядит она как отдельная вкладка у любого объекта мониторинга, на которой расположен жестко заданный набор полей инвентаризации с жестко заданными именами. Чтобы что-то изменить, нужно уже лезть в исходный код фронтенда. Невозможно также изменить количество этих полей и размеры — есть риск что-то сломать в ходе ближайшего обновления.
- Отсутствие автоматизации построения карт сетей. Для сравнения можно привести HP OpenView Network Node Manager, который отлично умеет строить карты сетевой топологии в автоматическом режиме. В Zabbix все придется строить вручную. Возможно, по этой причине данная функциональность у нас практически не востребована.
- Недостаточная гибкость ролевой модели. В Zabbix предусмотрено всего четыре роли пользователя с жестко фиксированными возможностями. Кроме того, отсутствует возможность «из коробки» ограничить доступ пользователей к API Zabbix. То есть если пользователь имеет доступ к фронтенду, то он автоматически имеет доступ и к API. У нас это приводило к тому, что пользователи неумелыми запросами серьезно нагружали систему. Кроме того, нет возможности дать пользователю доступ, например, к чтению метрик без доступа, к редактированию настроек объекта мониторинга.
Архитектура системы
Теперь несколько слов о количественных показателях и архитектуре нашей системы.
На мониторинге в данный момент находится больше 16 тысяч объектов (в основном, серверов), с которых суммарно собирается почти два с половиной миллиона метрик. Их суммарная нагрузка на систему — около 19 тысяч значений в секунду. Все объекты мониторинга распределены по более чем 1800 группам устройств, подавляющее большинство которых соответствует конкретным тестовым средам. На данный момент в системе зарегистрировано больше 1000 пользователей, которые разделены на 365 функциональных групп.
Как видите, мы уделяем довольно большое внимание распределению устройств и пользователей по группам. Это позволяет значительно увеличить точность оповещений от нашего сервиса.
Всего у нас три инстанса Zabbix. На схеме представлена архитектура самого большого из них, который мониторит основную IT-инфраструктуру разработки и тестирования. Еще один инстанс наблюдает за инфраструктурой мониторинга. И третий инстанс у нас используется для целей разработки и тестирования новых инструментов мониторинга. Вся структура основного инстанса у нас виртуализирована на базе VMWare. Вообще, по возможности лучше не использовать никакую систему виртуализации, потому что искать и решать проблемы производительности в случае виртуальной инфраструктуры на порядок сложнее.
Бэкенд основан на Oracle Active Data Guard и состоит из двух баз — основной и реплики. Фронтенда у нас три:
- Для административных задач — он настроен для выполнения тяжелых, сложных и долговременных операций, которые сильно нагружают сервер;
- Пользовательский — с более жесткими настройками, не позволяющими пользователям слишком сильно перегружать основную систему мониторинга;
- Для отчетности — он смотрит на реплику и был адаптирован, чтобы взаимодействовать с read-only базами. К нему подключается Grafana, обеспечивающая качественную визуализацию данных мониторинга.
Особенности реализации
В этом рассказе я решил не заострять внимание на базовой функциональности, которая реализована практически в любом мониторинге — фиксация аварий, сбор информации о производительности или доступности ИТ-систем. Сосредоточусь на отличительных особенностях нашего сервиса.
К таким особенностям в первую очередь относится высокая степень автоматизации типовых задач. Мы практически не тратим время на постановку серверов на мониторинг, предоставление доступа к результатам мониторинга, а сосредоточены, в основном, на развитии сервиса и добавлении в него новых нестандартных возможностей. В этом нам сильно помогает более 200 скриптов автоматизации, разработанных с момента ввода сервиса мониторинга в опытную эксплуатацию.
Но перед тем, как зарегистрировать агента в Zabbix, его еще нужно поставить. Как я писал выше, одним из недостатков Zabbix я вижу отсутствие инструментов управления агентами мониторинга. Поэтому для установки агентов у нас организован отдельный job в рамках наших DevOps процессов. На рисунке ниже приведена схема установки агента.
У нас есть две основные точки входа. Это либо скрипт на Python — он через REST API передает в job Jenkins информацию о хостах, на которые нужно установить или обновить агента, список дополнительных переменных, а также имя playbook, который нужно запускать на Ansible. Либо дефолтные данные могут идти из Bitbucket. Но в Jenkins они могут быть полностью заменены в соответствии с теми переменными, которые мы передали. И это нам помогает, например, обновлять агенты, которые мониторятся разными прокси-серверами. Особенность нашего процесса в том, что конфиг агента Zabbix формируется практически на лету.
Отчетность
Уже на старте работ по проекту стало ясно, что стандартные средства отчетности, предусмотренные инструментарием Zabbix, не позволят реализовать все наши потребности. В связи с этим на базе микросервисной архитектуры была реализована отдельная подсистема отчетности, которая существенно расширяет возможности базовых отчетов мониторинга. Сейчас у нас функционирует уже больше двадцати отчетов. Вот некоторые примеры вместе с реализуемыми целями:
Оповещения
На протяжении всей работы сервиса у нас эволюционировали почтовые оповещения. Вот как они выглядят на данный момент:
Здесь есть как информация о проблеме и ее статусе, так и об объекте мониторинга. Имеются ссылки на связанные метрики и события, поле для описания проблемы, ссылки на инструкции и форма обратной связи. По более критичным авариям у нас, разумеется, есть еще и рассылка в виде SMS.
Такие информативные оповещения позволили минимизировать общение большей части наших пользователей с самим Zabbix. Достаточно получения этой самой почтовой рассылки. Мы хорошо сгруппировали пользователей — на 1080 человек приходится 365 групп. Поэтому рассылка получается довольно-таки точечной — и, соответственно, не надоедливой. Многие наши пользователи практически забыли, что у нас есть, собственно, Zabbix — они пользуются рассылкой и системой визуализации Grafana.
Интеграция с процессами управления
Проект изначально предполагал интеграцию мониторинга с некоторыми нашими процессами управления IT-инфраструктурами. Если сервис мониторинга зафиксировал аварию, можно создать по ней тикет — для тех команд, которые больше работают с Jira. Для сервисных подразделений существует возможность создавать инциденты в HP Service Manager:
На базе Zabbix также была разработана и автоматизирована методика оптимизации утилизации IT-инфраструктуры. Оптимизируются три основных параметра: объем CPU, оперативной памяти и жестких дисков. Работает эта методика на базе скользящего среднего и 90-процентного перцентиля. На основании этой методики любой объект или сервер входит в одну из трех категорий: недозагруженный, загруженный оптимально, перегруженный.
Выше показано, как эта методика применяется к конкретному серверу. Розовый коридор — значение скользящего среднего. Широкий зеленый коридор — сырые данные. А голубой — это 90-процентный перцентиль.
Интеграция с конфигурационной базой данных позволила автоматизировать большую часть задач, связанных с предоставлением доступа и построением сервисно-ресурсной модели. Благодаря этой интеграции был разработан набор отчетов для аудита соответствия реальной инфраструктуры тому, как она описывается в системах учета. То есть мы можем сравнить, как инфраструктура числится у нас в системах учета, с тем, какой она является на самом деле.
Сервис мониторинга на базе Zabbix выступает у нас также в качестве средства автоматизации и поставщика данных для управления доступностью. В нем отслеживается доступность средств тестирования, а также возможность учета технологических окон.
На базе этой функциональности мы недавно закончили разработку подсистемы, которая отслеживает доступность полигонов тестирования. Мониторинг ведется как в разрезе стендов тестирования, так и в разделе отделов. Вычисляется пока усредненное значение за один день и за семь дней.
Итоги проекта
Как я упоминал раньше, одним из важных критериев функционирования сервиса является удовлетворенность пользователей. С 2017 года мы начали собирать обратную связь:
На этом графике можно увидеть стабильно высокую удовлетворенность сотрудников компании сервисом мониторинга начиная с 2017 года.
В рамках проекта мониторинга была разработана структура и правила наполнения базы знаний по мониторингу, куда входят:
- Регламенты работы с сервисами мониторинга
- Правила составления заявок на доступ
- Инструкции по расширению функционала мониторинга
- Описание возможностей сервиса мониторинга
- Информация об отчетах, которые можно получить
- Описание процессов реагирования на аварии
Чтобы упростить работу с системой мониторинга, недавно мы начали запись видеокурсов. В итоге практически 70% обращений пользователей закрывается отправкой им соответствующих ссылок на статьи или видео из базы знаний. Это существенно снизило нагрузку по консультированию, которая у специалистов по мониторингу, как известно, очень большая.
Одним из побочных эффектов внедрения централизованного сервиса стал массовый отказ подразделений Сбертеха от локальных средств мониторинга в течение 2016 года. Это позволило высвободить небольшую часть ресурсов подразделений. Отмечу, что отказ от локальных систем проходил на добровольной основе и решение подразделениями принималось исходя из преимуществ, которые дает сервис централизованного мониторинга.
С момента начала полноценной работы в 2016 году сервис оказывает большую помощь системным администраторам. Хотя размеры ИТ-инфраструктуры продолжают линейно расти, отдел администрирования пока не нуждается в расширении. И это не в последнюю очередь заслуга системы мониторинга. С ее помощью мы также смогли стабилизировать рост числа заявок, приходящих отделу системного администрирования от смежных подразделений
В результате оптимизации КТС в 2016 году и ее автоматизации на базе сервиса мониторинга, удалось высвободить и распределить в пулы подразделений большое количество неиспользуемых ресурсов: 600 ядер CPU, почти 7,5 терабайт оперативной памяти и порядка 50 терабайт дискового пространства.
Автор: sperr0w
