- PVSM.RU - https://www.pvsm.ru -
Привет! Меня зовут Сергей Прутских, я руковожу направлением мониторинга компании «Сбербанк-Технологии». Основная задача нашей организации — разработка и тестирование программных продуктов для Сбербанка. Для этого в компании сосредоточена крупная ИТ-инфраструктура — 15 тысяч серверов разделены примерно на 1500 тестовых сред, которые относятся к более чем 500 автоматизированным системам. Всего с ними работает около 10 тысяч специалистов.
В 2015 году мы начали создавать централизованный сервис мониторинга. Причем все ограничивалось не только внедрением. Нужно было проработать множество регламентов, инструкций, а также взаимоотношения между подразделениями Сбертеха в рамках мониторинга. В этом посте я подробно расскажу, как мы выбирали платформу, по каким принципам все создавали и что в итоге у нас получилось.
Вот какие цели мы преследовали в проекте:
Забегая вперед, могу сказать, что все цели в той или иной степени уже выполнены к настоящему моменту. И некоторые сопутствующие проблемы мониторинг тоже помог решить.
Помимо целей, мы сформулировали принципы, идеологию, которой придерживались по ходу всего проекта:
Практически во всех проектах, где я участвовал, рано или поздно всплывала таблица со сравнением функциональности различных систем, в которой какой-то конкретной системе отдавалось очевидное преимущество.
На мой взгляд, до непосредственного начала работы с сервисом мониторинга такой сравнительный анализ делать нельзя, и уж тем более не стоит принимать решение о выборе того или иного решения, исходя из этого анализа. До тех пор, пока система в вашей компании не проработает хотя бы на протяжении небольшого промежутка времени, нельзя однозначно судить о том, какие конкретно функции именно в вашей компании будут востребованы. Такие таблицы могут отлично помочь, если вы по каким либо причинам хотите сменить систему мониторинга.
Можно много говорить о том, как сравнить размер нескольких инсталляций систем мониторинга, но все выбранные для этого характеристики, на мой взгляд, довольно субъективны. Чтобы у вас появилось более точное представление о размере нашей инсталляции, я решил привести примеры аналогичных сервисов в других компаниях, о которых представители Zabbix рассказывали на конфереции Highload.
Как видите, инстанс Zabbix в Сбертехе не сильно уступает крупнейшим инсталляциям, а по суммарной нагрузке идет вровень с ними.
Во второй половине 2017 года мы проводили пилот Zabbix для мониторинга ПРОМ-инфраструктуры. Тогда же мы сформулировали ряд качественных критериев, которые мы относим к безусловным преимуществам Zabbix:
Справедливости ради не могу не упомянуть об основных, на мой взгляд, недостатках Zabbix. Из них тоже можно составить приличный список:
Теперь несколько слов о количественных показателях и архитектуре нашей системы.
На мониторинге в данный момент находится больше 16 тысяч объектов (в основном, серверов), с которых суммарно собирается почти два с половиной миллиона метрик. Их суммарная нагрузка на систему — около 19 тысяч значений в секунду. Все объекты мониторинга распределены по более чем 1800 группам устройств, подавляющее большинство которых соответствует конкретным тестовым средам. На данный момент в системе зарегистрировано больше 1000 пользователей, которые разделены на 365 функциональных групп.
Как видите, мы уделяем довольно большое внимание распределению устройств и пользователей по группам. Это позволяет значительно увеличить точность оповещений от нашего сервиса.
Всего у нас три инстанса Zabbix. На схеме представлена архитектура самого большого из них, который мониторит основную IT-инфраструктуру разработки и тестирования. Еще один инстанс наблюдает за инфраструктурой мониторинга. И третий инстанс у нас используется для целей разработки и тестирования новых инструментов мониторинга. Вся структура основного инстанса у нас виртуализирована на базе VMWare. Вообще, по возможности лучше не использовать никакую систему виртуализации, потому что искать и решать проблемы производительности в случае виртуальной инфраструктуры на порядок сложнее.
Бэкенд основан на Oracle Active Data Guard и состоит из двух баз — основной и реплики. Фронтенда у нас три:
В этом рассказе я решил не заострять внимание на базовой функциональности, которая реализована практически в любом мониторинге — фиксация аварий, сбор информации о производительности или доступности ИТ-систем. Сосредоточусь на отличительных особенностях нашего сервиса.
К таким особенностям в первую очередь относится высокая степень автоматизации типовых задач. Мы практически не тратим время на постановку серверов на мониторинг, предоставление доступа к результатам мониторинга, а сосредоточены, в основном, на развитии сервиса и добавлении в него новых нестандартных возможностей. В этом нам сильно помогает более 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
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/open-source/289949
Ссылки в тексте:
[1] Источник: https://habr.com/post/420731/?utm_campaign=420731
Нажмите здесь для печати.