Хабрахабр

Zabbix на стероидах: как устроена единая платформа мониторинга Сбертеха

Привет, Хабр! Меня зовут Сергей Прутских, я руковожу направлением мониторинга компании «Сбербанк-Технологии». Основная задача нашей организации — разработка и тестирование программных продуктов для Сбербанка. Для этого в компании сосредоточена крупная ИТ-инфраструктура — 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. У нас это приводило к тому, что пользователи неумелыми запросами серьезно нагружали систему. Кроме того, нет возможности дать пользователю доступ, например, к чтению метрик без доступа, к редактированию настроек объекта мониторинга.

Архитектура системы

Теперь несколько слов о количественных показателях и архитектуре нашей системы.

Их суммарная нагрузка на систему — около 19 тысяч значений в секунду. На мониторинге в данный момент находится больше 16 тысяч объектов (в основном, серверов), с которых суммарно собирается почти два с половиной миллиона метрик. На данный момент в системе зарегистрировано больше 1000 пользователей, которые разделены на 365 функциональных групп. Все объекты мониторинга распределены по более чем 1800 группам устройств, подавляющее большинство которых соответствует конкретным тестовым средам.

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

На схеме представлена архитектура самого большого из них, который мониторит основную IT-инфраструктуру разработки и тестирования. Всего у нас три инстанса Zabbix. И третий инстанс у нас используется для целей разработки и тестирования новых инструментов мониторинга. Еще один инстанс наблюдает за инфраструктурой мониторинга. Вообще, по возможности лучше не использовать никакую систему виртуализации, потому что искать и решать проблемы производительности в случае виртуальной инфраструктуры на порядок сложнее. Вся структура основного инстанса у нас виртуализирована на базе VMWare.

Фронтенда у нас три: Бэкенд основан на Oracle Active Data Guard и состоит из двух баз — основной и реплики.

  • Для административных задач — он настроен для выполнения тяжелых, сложных и долговременных операций, которые сильно нагружают сервер;
  • Пользовательский — с более жесткими настройками, не позволяющими пользователям слишком сильно перегружать основную систему мониторинга;
  • Для отчетности — он смотрит на реплику и был адаптирован, чтобы взаимодействовать с read-only базами. К нему подключается Grafana, обеспечивающая качественную визуализацию данных мониторинга.

Особенности реализации

В этом рассказе я решил не заострять внимание на базовой функциональности, которая реализована практически в любом мониторинге — фиксация аварий, сбор информации о производительности или доступности ИТ-систем. Сосредоточусь на отличительных особенностях нашего сервиса.

Мы практически не тратим время на постановку серверов на мониторинг, предоставление доступа к результатам мониторинга, а сосредоточены, в основном, на развитии сервиса и добавлении в него новых нестандартных возможностей. К таким особенностям в первую очередь относится высокая степень автоматизации типовых задач. В этом нам сильно помогает более 200 скриптов автоматизации, разработанных с момента ввода сервиса мониторинга в опытную эксплуатацию.

Как я писал выше, одним из недостатков Zabbix я вижу отсутствие инструментов управления агентами мониторинга. Но перед тем, как зарегистрировать агента в Zabbix, его еще нужно поставить. На рисунке ниже приведена схема установки агента. Поэтому для установки агентов у нас организован отдельный job в рамках наших DevOps процессов.

Это либо скрипт на Python — он через REST API передает в job Jenkins информацию о хостах, на которые нужно установить или обновить агента, список дополнительных переменных, а также имя playbook, который нужно запускать на Ansible. У нас есть две основные точки входа. Но в Jenkins они могут быть полностью заменены в соответствии с теми переменными, которые мы передали. Либо дефолтные данные могут идти из Bitbucket. Особенность нашего процесса в том, что конфиг агента Zabbix формируется практически на лету. И это нам помогает, например, обновлять агенты, которые мониторятся разными прокси-серверами.

Отчетность

Уже на старте работ по проекту стало ясно, что стандартные средства отчетности, предусмотренные инструментарием Zabbix, не позволят реализовать все наши потребности. В связи с этим на базе микросервисной архитектуры была реализована отдельная подсистема отчетности, которая существенно расширяет возможности базовых отчетов мониторинга. Сейчас у нас функционирует уже больше двадцати отчетов. Вот некоторые примеры вместе с реализуемыми целями:

Оповещения

На протяжении всей работы сервиса у нас эволюционировали почтовые оповещения. Вот как они выглядят на данный момент:

Имеются ссылки на связанные метрики и события, поле для описания проблемы, ссылки на инструкции и форма обратной связи. Здесь есть как информация о проблеме и ее статусе, так и об объекте мониторинга. По более критичным авариям у нас, разумеется, есть еще и рассылка в виде SMS.

Достаточно получения этой самой почтовой рассылки. Такие информативные оповещения позволили минимизировать общение большей части наших пользователей с самим Zabbix. Поэтому рассылка получается довольно-таки точечной — и, соответственно, не надоедливой. Мы хорошо сгруппировали пользователей — на 1080 человек приходится 365 групп. Многие наши пользователи практически забыли, что у нас есть, собственно, Zabbix — они пользуются рассылкой и системой визуализации Grafana.

Интеграция с процессами управления

Проект изначально предполагал интеграцию мониторинга с некоторыми нашими процессами управления IT-инфраструктурами. Если сервис мониторинга зафиксировал аварию, можно создать по ней тикет — для тех команд, которые больше работают с Jira. Для сервисных подразделений существует возможность создавать инциденты в HP Service Manager:

Оптимизируются три основных параметра: объем CPU, оперативной памяти и жестких дисков. На базе Zabbix также была разработана и автоматизирована методика оптимизации утилизации IT-инфраструктуры. На основании этой методики любой объект или сервер входит в одну из трех категорий: недозагруженный, загруженный оптимально, перегруженный. Работает эта методика на базе скользящего среднего и 90-процентного перцентиля.

Розовый коридор — значение скользящего среднего. Выше показано, как эта методика применяется к конкретному серверу. А голубой — это 90-процентный перцентиль. Широкий зеленый коридор — сырые данные.

Благодаря этой интеграции был разработан набор отчетов для аудита соответствия реальной инфраструктуры тому, как она описывается в системах учета. Интеграция с конфигурационной базой данных позволила автоматизировать большую часть задач, связанных с предоставлением доступа и построением сервисно-ресурсной модели. То есть мы можем сравнить, как инфраструктура числится у нас в системах учета, с тем, какой она является на самом деле.

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

Мониторинг ведется как в разрезе стендов тестирования, так и в разделе отделов. На базе этой функциональности мы недавно закончили разработку подсистемы, которая отслеживает доступность полигонов тестирования. Вычисляется пока усредненное значение за один день и за семь дней.

Итоги проекта

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

На этом графике можно увидеть стабильно высокую удовлетворенность сотрудников компании сервисом мониторинга начиная с 2017 года.

В рамках проекта мониторинга была разработана структура и правила наполнения базы знаний по мониторингу, куда входят:

  • Регламенты работы с сервисами мониторинга
  • Правила составления заявок на доступ
  • Инструкции по расширению функционала мониторинга
  • Описание возможностей сервиса мониторинга
  • Информация об отчетах, которые можно получить
  • Описание процессов реагирования на аварии

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

Это позволило высвободить небольшую часть ресурсов подразделений. Одним из побочных эффектов внедрения централизованного сервиса стал массовый отказ подразделений Сбертеха от локальных средств мониторинга в течение 2016 года. Отмечу, что отказ от локальных систем проходил на добровольной основе и решение подразделениями принималось исходя из преимуществ, которые дает сервис централизованного мониторинга.

Хотя размеры ИТ-инфраструктуры продолжают линейно расти, отдел администрирования пока не нуждается в расширении. С момента начала полноценной работы в 2016 году сервис оказывает большую помощь системным администраторам. С ее помощью мы также смогли стабилизировать рост числа заявок, приходящих отделу системного администрирования от смежных подразделений И это не в последнюю очередь заслуга системы мониторинга.

В результате оптимизации КТС в 2016 году и ее автоматизации на базе сервиса мониторинга, удалось высвободить и распределить в пулы подразделений большое количество неиспользуемых ресурсов: 600 ядер CPU, почти 7,5 терабайт оперативной памяти и порядка 50 терабайт дискового пространства.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть