- PVSM.RU - https://www.pvsm.ru -
Сейчас о мониторинге не пишет только мёртвый тот, у кого его нет. У нас в Тензоре мониторинг есть – это наша собственная система сбора метрик (хотя это далеко не единственное её назначение), тесно интегрированная с Zabbix.
Если вам интересно, как устроен мониторинг 5K серверов в нашей компании, с какими проблемами нам приходилось сталкиваться на пути к 1.5M метрик, 65K значений в секунду и текущему решению и как мы вообще докатились до жизни такой, добро пожаловать под кат.
Давно-давно, еще в 90-х, Тензор разрабатывал не нынешние web-сервисы с миллионами пользователей, а обычное десктоп-приложение – систему для ведения складского и бухгалтерского учета. Это было обычное, максимум с сетевой БД, приложение, которое работало на «железе» клиента. Бухгалтеры готовили в нем отчетность, печатали и носили «ножками» в налоговую.
Из всех «серверных» мощностей у нас самих тогда было всего ничего – пара серверов у программистов для сборки релиза да сервер с корпоративной БД учетной системы. За ними «вполглаза» приглядывали пара «админов», чьим основным занятием был хелпдеск пользователей.
Потом мы смогли избавить своих клиентов-бухгалтеров от походов в госорганы – наше десктопное приложение все так же помогало им готовить отчеты, но посылало их в налоговую уже само – через наш сервер по почтовому протоколу.
Если кто-то считает, что «обмен почтой с налоговой» – это просто пара почтовых серверов, то это сильно не так. Сюда добавляется «горка» проприетарных софтовых и хардварных решений для обеспечения защищенных каналов, своих для каждого госоргана – ФНС, ПФ, Росстат, … много их. И у каждого такого решения свои «заморочки»: требования к ОС, «железу», регламенту обслуживания…
Понятно, что такой принцип работы потребовал роста серверных мощностей на нашей стороне, и «пары админов» перестало хватать на все задачи. В этот момент у нас наметилась специализация «админов», которая сохранилась и по сей день, хоть их и стало уже больше 70 человек:
В этот момент мы поняли, что без какой-то разумной автоматизации мониторинга за всем этим «зоопарком» быстро погрязнем под ворохом проблем.
Собственно, весь мониторинг нужен только для одной задачи – обнаружения аномалий/проблем в наблюдаемой системе. Причем чем раньше – тем лучше, в идеале – еще до того, как проблема случится. А если уж случилась, мы должны иметь возможность проанализировать всю снятую информацию и понять, что же к ней привело.
Фактически, весь цикл разработки мониторинга выглядит так:
Ну, например, бывает, что на сервере кончается память. Технически причины могут быть разными («не отпустил вовремя», «течет приложение», «не сработал GC», …), но симптоматика почти всегда одинаковая – постепенно объем занятой памяти становится все больше и больше.
Многие любят мониторить «свободную память», но это не совсем правильно, – поскольку при активно использующемся pagecache ее может практически не быть даже в нормальных условиях.
[1]
Изображение кликабельно, открывается в текущей вкладке веб-браузера.
Соответственно, если мы проанализируем динамику роста и текущее состояние, то вовремя поймем, в какой момент уже пора переставать надеяться на «само рассосется», и пора поднимать тревогу.
На разных этапах в качестве ядра системы мониторинга мы успели попробовать Nagios, Graphite и остановились на Zabbix, который вполне успешно используем и по сей день для наблюдения за несколькими тысячами серверов. За несколько лет мы накопили немалый опыт его эксплуатации, администрирования и тюнинга. И всё это время он довольно неплохо справлялся со своими задачами.
Тем не менее мы наступили, наверное, на все возможные и невозможные грабли. А это –самый полезный опыт.
Итак, основные проблемы, с которыми мы столкнулись (внимание! далее по тексту присутствует много боли и страданий):
Ну, например, база работает на хосте и «ест» 100% CPU. У «железячников» радость – «железо молодец, не сбоит даже под такой нагрузкой!», а у «прикладников» – паника.
К разным правилам (и шаблонам) мониторинга одних и тех же сущностей в разных отделах начинали добавляться проблемы из-за недостаточной возможности параметризации самого Zabbix.
Например, у нас есть отличный шаблон с красивыми графиками для мониторинга 8-ядерного сервера:
[2]Изображение кликабельно, открывается в текущей вкладке веб-браузера.
И… для 16-ядерного он уже не подходит, нужен новый, с новыми графиками, ведь количество метрик – другое. А ведь у нас есть и 64-ядерные хосты…
В результате у нас была целая куча шаблонов на все случаи жизни. Только для мониторинга дисков их было больше десятка. Не существовало строгих правил, какие из них должны подключаться к хосту и в каких случаях.
У шаблонов не было никакой версионности, кроме пометок вроде “old” и “very_old”. Они привязывались и отвязывались так, как админу велело его сердце. В некоторых случаях метрики заводились просто вручную, без шаблонов. В результате получилась ситуация, когда разные хосты мониторились по-разному.
Если конфигурация сервера менялась, то нужно было не забыть подцепить правильные шаблоны. А ведь ещё нужно было вбить в конфиг хоста макросы с различными настройками, а потом проверить, что всё это работает.
И даже если все собирались, то контрольные триггеры могли оказаться просто случайно отключены – ведь доступ на редактирование в Zabbix имело больше десятка человек!
На каждый отсчет для каждой из множества метрик генерировался запрос, по которому на целевом сервере отрабатывала портянка из разного рода atop, iostat, grep, cut, awk и т.п., и возвращалось единственное значение, затем соединение закрывалось, и инициировался следующий запрос.
Понятно, что это плохо для производительности и для наблюдаемого сервера, и для Zabbix’а. Но еще хуже – отсутствие синхронности в получаемых данных.
Например, если мы замеряем поочередно нагрузку каждого из ядер CPU, получаем нули и… И ничего не понимаем о нагрузке на CPU в целом, поскольку она в момент каждого отдельного замера могла оказываться на других ядрах.
Для сбора метрик мы использовали пассивные zabbix-агенты и внешние скрипты. Для запроса данных с агентов со стороны Zabbix’а форкается указанное фиксированное количество воркеров. Пока воркер ждёт ответа от агента, другие запросы он не обслуживает. Таким образом, нередко возникали ситуации, когда zabbix не успевал обслуживать очередь и на графиках возникали “дыры” – интервалы с отсутствующими данными.
Мониторинг с помощью внешних скриптов тоже ни к чему хорошему не приводил. Большое количество одновременно запущенных различных интерпретаторов быстро приводило к космической загрузке сервера. Мониторинг в это время не работал, мы оставались “без глаз”.
Служба эксплуатации поздно узнавала о проблемах инфраструктуры, а разработчики не имели инструмента для анализа эффективности своих решений. В конечном счёте, всё это, так или иначе сказывалось на эффективности наших решений.
После осознания того факта, что наш мониторинг – это собрание неправильных архитектурных решений (не знаю, можно ли считать отсутствие архитектуры архитектурным решением), мы решили что так больше жить нельзя. И начали думать, как исправить все описанные недостатки, но без радикальных решений, вроде замены Zabbix на что-то другое. Всё-таки, отказываться от накопленного опыта и пытаться искоренить многолетние привычки – наверное, не лучшая затея. Zabbix – это отличный инструмент, если правильно им пользоваться.
Для начала мы определили для себя следующие критерии, что хочется получить:
zabbix-1: cat /proc/meminfo | grep 'MemFree' | awk '{print $2}'
zabbix-2: cat /proc/meminfo | grep 'Shmem' | awk '{print $2}'
sbis-mon: cat /proc/meminfo # все, дальше парсим на приемнике
Поскольку Zabbix оперирует в качестве объекта мониторинга «хостом», а нам нужен был «сервис» (например, конкретный из нескольких развернутых на одной машине экземпляров СУБД), мы зафиксировали определённые правила именования хостов, сервисов, метрик и комплексных экранов так, чтобы они не «ломали» ни логику Zabbix, ни «человекопонятность»:
hostname[.service[.port]][:screen]
К примеру: some-db.pgsql.5433:db.postgres. Если порт дефолтный, то он не указывается для облегчения восприятия.
[3]
Изображение кликабельно, открывается в текущей вкладке веб-браузера.
Мы так и не дали этой системе имя, но внутри компании закрепилось рабочее название “sbis3mon”, а кое-кто с лёгкой руки назвал его “красивый мониторинг”. Почему красивый? Мы постарались сделать его не просто функциональным, но и наглядным.
[4]
Изображение кликабельно, открывается в текущей вкладке веб-браузера.
На данный момент мы уже разработали десятки модулей для мониторинга различного оборудования и сервисов, используемых в Тензоре:
В ближайших планах также стоит мониторинг MySQL, сетевого оборудования и сервисов телефонии (Asterisk).
В качестве платформы мы выбрали Node.js – из-за развитой экосистемы, асинхронности, простоты работы с сетью, легкости масштабирования (модуль cluster) и скорости разработки.
Также мы приняли на вооружение подход Continuous Delivery и стали приделывать крылья самолёту на лету. Благодаря частым релизам, мы быстро получали фидбэк и могли корректировать направление разработки. Система строилась на глазах у основных наших пользователей – сотрудников службы эксплуатации, при этом они продолжали использовать привычную оболочку мониторинга. Постепенно мы заменяли старые методы мониторинга на новые, пока не изжили их совсем.
Система строится на микросервисной архитектуре и состоит из 5 основных частей:
В качестве СУБД мы используем PostgreSQL. Но база тут вторична и не очень интересна – там хранятся настройки хостов и сервисов, обнаруженные сущности, ссылки на ресурсы Zabbix и записи аудитлога, и никакого highload.
[5]
Изображение кликабельно, открывается в текущей вкладке веб-браузера.
Самое интересное – сервисы. Они могут работать как на одном сервере, так и на разных.
Мастер и коллекторы имеют общую кодовую базу – ядро. В зависимости от параметров запуска процесс становится либо мастером, либо коллектором.
Функции мастер-процесса:
Функции коллекторов:
Сейчас наши несколько тысяч хостов и десятки тысяч сервисов на них обслуживаются коллекторами, живущими всего на двух серверах, на 40 и 64 ядра, со средней нагрузкой порядка 20-25% – то есть мы легко выдержим и дальнейший рост нашего серверного парка еще в 3-4 раза.
В следующей части мы расскажем более детально о тех решениях, которые позволили нашему мониторингу выдерживать рост нагрузки и требований пользователей, пока Тензор превращался из оператора по сдаче отчетности в настоящего мультисервисного провайдера услуг с миллионами пользователей онлайн.
Авторы: vadim_ipatov [6] (Вадим Ипатов) и kilor [7] (Кирилл Боровиков)
Автор: tensor_sbis
Источник [8]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/zabbix/255593
Ссылки в тексте:
[1] Image: https://habrastorage.org/web/cf2/1bd/2a4/cf21bd2a468340999b8a8e83b0d61061.png
[2] Image: https://habrastorage.org/web/619/ed2/54c/619ed254c6ff48d5a1e75fcdda373f45.png
[3] Image: https://habrastorage.org/web/78b/484/5e7/78b4845e7f9b44f3ad1b3e7e990c9b4b.png
[4] Image: https://habrastorage.org/web/9c8/a0d/71c/9c8a0d71ce4a4f819e3fc1034a94d3af.png
[5] Image: https://habrastorage.org/web/362/5ff/d7e/3625ffd7ef1d4b7abdbdd33e3d0a9b37.png
[6] vadim_ipatov: https://habrahabr.ru/users/vadim_ipatov/
[7] kilor: https://habrahabr.ru/users/kilor/
[8] Источник: https://habrahabr.ru/post/328920/
Нажмите здесь для печати.