Следующая конференция HighLoad++ пройдет 6 и 7 апреля 2020 года в Санкт-Петербурге.
Подробности и билеты связь .
HighLoad++ Москва 2018. Зал «Москва».
9 ноября, 15:00. Тезисы и презентация .
* Мониторинг - онлайн и аналитика.
* Основные ограничения платформы ZABBIX. * Решение для масштабирования хранилища аналитики.
* Оптимизация сервера ЗАББИКС.
* Оптимизация пользовательского интерфейса.
* Опыт работы системы под нагрузками более 40к NVPS. * Краткие выводы.
Михаил Макуров (далее – ММ): - Всем привет! Максим Чернецов (далее – МЧ): - Добрый день! ММ: – Позвольте представить Максима.
Макс — талантливый инженер, лучший сетевик, которого я знаю.
Максим занимается сетями и сервисами, их развитием и эксплуатацией.
МЧ: – И мне хотелось бы рассказать вам о Михаиле.
Михаил — разработчик C. Он написал для нашей компании несколько высоконагруженных решений по обработке трафика.
Мы живем и работаем на Урале, в городе крутых мужчин Челябинске, в компании Интерсвязь.
Наша компания является поставщиком услуг Интернета и кабельного телевидения для миллиона человек в 16 городах.
ММ: – И стоит сказать, что «Интерсвязь» – это гораздо больше, чем просто провайдер, это IT-компания.
Большинство наших решений разрабатываются нашим ИТ-отделом.
А: от серверов обработки трафика до колл-центра и мобильного приложения.
В ИТ-отделе сейчас работает около 80 человек с очень и очень разнообразными компетенциями.
О Zabbix и его архитектуре
МЧ: — А теперь я попробую установить личный рекорд и за одну минуту сказать, что такое Zabbix (далее «Заббикс»).Zabbix позиционирует себя как готовую систему мониторинга корпоративного уровня.
Он имеет множество функций, упрощающих жизнь: расширенные правила эскалации, API для интеграции, группировки и автоматического определения хостов и метрик.
В Zabbix есть так называемые инструменты масштабирования — прокси.
Zabbix — это система с открытым исходным кодом.
Коротко об архитектуре.
Можно сказать, что он состоит из трех компонентов: 
- Сервер.
Написан на C. С достаточно сложной обработкой и передачей информации между потоками.
В нем происходит вся обработка: от получения до сохранения в базу данных.
- Все данные хранятся в базе данных.
Zabbix поддерживает MySQL, PostgreSQL и Oracle.
- Веб-интерфейс написан на PHP. В большинстве систем он поставляется с сервером Apache, но более эффективно работает в сочетании с nginx + php.
История из жизни компании Интерсвязь.
Что у нас есть и что нам нужно? 
5 или 6 месяцев назад. Однажды после работы.
МЧ: - Миша, здравствуй! Я рад, что мне удалось тебя поймать - разговор есть.
У нас снова возникли проблемы с мониторингом.
Во время крупной аварии все работало медленно и не было никакой информации о состоянии сети.
К сожалению, это происходит не в первый раз.
Мне нужна ваша помощь.
Давайте сделаем так, чтобы наш мониторинг работал при любых обстоятельствах! ММ: - Но давайте сначала синхронизируемся.
Я не заглядывал туда уже пару лет. Насколько я помню, мы отказались от Nagios и перешли на Zabbix около 8 лет назад. И сейчас у нас вроде бы 6 мощных серверов и около десятка прокси.
Я что-то путаю? МЧ: - Почти.
15 серверов, часть из которых виртуальные машины.
Самое главное, что оно не спасает нас в тот момент, когда мы больше всего в этом нуждаемся.
Как случайность — сервера тормозят и ничего не видно.
Мы попытались оптимизировать конфигурацию, но это не обеспечило оптимального прироста производительности.
ММ: - Ясно.
Вы что-то смотрели, уже что-то накопали из диагностики? МЧ: – Первое, с чем вам придется иметь дело, – это база данных.
MySQL постоянно загружается, сохраняя новые метрики, а когда Zabbix начинает генерировать кучу событий, база данных переходит в перегрузку буквально на несколько часов.
Про оптимизацию конфигурации я уже рассказывал, но буквально в этом году обновили железо: на серверах больше ста гигабайт памяти и дисковых массивов на SSD RAID — линейно наращивать в долгосрочной перспективе смысла нет. Что мы делаем? ММ: - Ясно.
В общем, MySQL — это база данных LTP. Видимо, для хранения архива метрик нашего размера он уже не подходит. Давайте разберемся.
МЧ: - Давайте!
Интеграция Zabbix и Clickhouse по итогам хакатона
Через некоторое время мы получили интересные данные:
Большую часть места в нашей базе занимал архив метрик и менее 1% использовалось для конфигурации, шаблонов и настроек.
К тому моменту мы уже больше года эксплуатировали решение Big Data на базе Clickhouse. Направление движения было для нас очевидно.
На нашем весеннем хакатоне я писал интеграцию Zabbix с Clickhouse для сервера и фронтенда.
На тот момент в Zabbix уже была поддержка ElasticSearch, и мы решили их сравнить.
Сравнение Clickhouse и Elasticsearch
ММ: — Для сравнения мы генерировали ту же нагрузку, которую обеспечивает Zabbix-сервер, и смотрели, как будут вести себя системы.
Мы записывали данные пакетами по 1000 строк, используя CURL. Мы заранее предполагали, что Clickhouse будет более эффективен для того профиля нагрузки, который делает Zabbix. Результаты даже превзошли наши ожидания: 
При тех же условиях тестирования Clickhouse записал в три раза больше данных.
При этом обе системы очень эффективно потребляли (небольшое количество ресурсов) при чтении данных.
Но «Эlastix» требовал большого количества процессора при записи:
В целом Clickhouse значительно превосходил Lastix по потреблению процессора и скорости.
При этом за счет сжатия данных Clickhouse использует в 11 раз меньше жесткого диска и выполняет примерно в 30 раз меньше дисковых операций: 
МЧ: — Да, работа Clickhouse с дисковой подсистемой реализована очень эффективно.
Вы можете использовать огромные диски SATA для баз данных и получать скорость записи в сотни тысяч строк в секунду.
Готовая система поддерживает шардинг, репликацию и очень проста в настройке.
Мы более чем довольны его использованием на протяжении всего года.
Чтобы оптимизировать ресурсы, вы можете установить Clickhouse рядом с существующей основной базой данных и тем самым сэкономить много процессорного времени и дисковых операций.
Мы перенесли архив метрик в существующие кластеры Clickhouse: 
Мы настолько разгрузили основную базу данных MySQL, что смогли объединить ее на одной машине с сервером Zabbix и отказаться от выделенного сервера для MySQL.
Как работает опрос в Zabbix?
4 месяца назад ММ: – Ну что, можем забыть о проблемах с базой? МЧ: - Это точно! Еще одна проблема, которую нам нужно решить, — это медленный сбор данных.Теперь все наши 15 прокси-серверов перегружены процессами SNMP и опроса.
И нет другого выхода, кроме как устанавливать новые и новые сервера.
ММ: - Большой.
Но сначала расскажите, как работает опрос в Zabbix? МЧ: — Короче говоря, есть 20 типов метрик и десяток способов их получения.
Zabbix может собирать данные либо в режиме «запрос-ответ», либо ждать новых данных через «Интерфейс Траппера».
Стоит отметить, что в оригинальном Zabbix этот метод (Trapper) является самым быстрым.
Для распределения нагрузки имеются прокси-серверы: 
Прокси могут выполнять те же функции сбора, что и Zabbix-сервер, получая от него задачи и отправляя собранные метрики через интерфейс Trapper. Это официально рекомендуемый способ распределения нагрузки.
Прокси также полезны для мониторинга удаленной инфраструктуры, работающей через NAT или медленный канал: 
ММ: – С архитектурой все понятно.
Надо смотреть источники.
Пару дней спустя
История о том, как победил nmap fping
ММ: — Кажется, я что-то откопал.МЧ: - Скажи мне! ММ: — Я обнаружил, что Zabbix при проверке доступности проверяет максимум 128 хостов одновременно.
Я попробовал увеличить это число до 500 и убрать межпакетный интервал в их пинге (пинге) - это увеличило производительность вдвое.
Но хотелось бы большего количества.
МЧ: — В моей практике мне иногда приходится проверять доступность тысяч хостов, и я никогда не видел для этого ничего быстрее, чем nmap. Я уверен, что это самый быстрый способ.
Давай попробуем! Нам нужно значительно увеличить количество хостов на итерацию.
ММ: – Чек больше пятисот? 600? МЧ: - Хотя бы пару тысяч.
ММ: - ХОРОШО.
Самое главное, что я хотел сказать, это то, что я обнаружил, что большая часть опросов в Zabbix выполняется синхронно.
Нам обязательно нужно перевести его в асинхронный режим.
Тогда мы сможем резко увеличить количество метрик, собираемых поллерами, особенно если увеличить количество метрик на итерацию.
МЧ: - Большой! И когда? ММ: – Как обычно, вчера.
МЧ: – Мы сравнили обе версии fping и nmap: 
Ожидалось, что на большом количестве хостов nmap будет в пять раз эффективнее.
Поскольку nmap проверяет только доступность и время ответа, мы перенесли расчет потерь на триггеры и существенно сократили интервалы проверки доступности.
Мы обнаружили, что оптимальное количество хостов для nmap составляет около 4 тысяч на итерацию.
Nmap позволил нам в три раза снизить затраты процессора на проверки доступности и сократить интервал со 120 секунд до 10.
Оптимизация опроса
ММ: «Затем мы начали проводить опросы.Нас в основном интересовали обнаружение и агенты SNMP. В Zabbix опрос выполняется синхронно и приняты специальные меры для повышения эффективности системы.
В синхронном режиме недоступность хоста приводит к значительному ухудшению опроса.
Есть целая система состояний, есть специальные процессы — так называемые недостижимые поллеры, которые работают только с недоступными хостами: 
Это комментарий, демонстрирующий матрицу состояний, всю сложность системы переходов, которые необходимы для того, чтобы система оставалась эффективной.
Кроме того, сам синхронный опрос довольно медленный: 
Именно поэтому тысячи потоков поллера на десятках прокси не смогли собрать необходимый для нас объём данных.
Асинхронная реализация решила не только проблемы с количеством потоков, но и существенно упростила систему состояний недоступных хостов, поскольку для любого числа, проверенного за одну итерацию опроса, максимальное время ожидания составляло 1 таймаут: 
Дополнительно мы модифицировали и улучшили систему опроса SNMP-запросов.
Дело в том, что большинство людей не могут одновременно отвечать на несколько запросов SNMP. Поэтому мы сделали гибридный режим, когда SNMP-опрос одного и того же хоста происходит асинхронно: 
Это делается для всей пачки хостов.
Этот режим в конечном счете не медленнее полностью асинхронного, поскольку опрос полутора сотен значений SNMP все равно происходит гораздо быстрее, чем 1 таймаут. Наши эксперименты показали, что оптимальное количество запросов за одну итерацию составляет примерно 8 тысяч при SNMP-опросе.
В общей сложности переход в асинхронный режим позволил ускорить производительность опроса в 200 раз, в несколько сотен раз.
МЧ: — Полученные оптимизации опросов показали, что мы можем не только избавиться от всех прокси, но и сократить интервалы многих проверок, и прокси больше не понадобятся как способ разделения нагрузки.
Около трех месяцев назад
Меняйте архитектуру – увеличивайте нагрузку!
ММ: - Ну что, Макс, пора заняться делом? Мне нужен мощный сервер и хороший инженер.МЧ: - Хорошо, давай спланируем это.
Пора сдвинуться с мертвой точки в 5 тысяч метрик в секунду.
Утро после обновления МЧ: - Миша, мы обновились, но к утру откатились.
Угадай, какой скорости удалось достичь? ММ: – 20 тысяч максимум.
МЧ: - Да, 25! К сожалению, мы находимся там, где начали.
ММ: - Почему? Вы делали какую-нибудь диагностику? МЧ: - Да, конечно! Вот, например, интересный топ: 
ММ: - Давай посмотрим.
Я вижу, что мы перепробовали огромное количество потоков опросов: 
Но при этом переработать систему не смогли даже наполовину: 
Да и общая производительность совсем небольшая, около 4 тысяч метрик в секунду: 
Есть ли еще что-нибудь? МЧ: — Да, след одного из опросчиков: 
ММ: — Здесь хорошо видно, что процесс опроса ожидает «семафоры».
Это замки: 
МЧ: - Не понятно.
ММ: — Посмотрите, это похоже на ситуацию, когда куча потоков пытается работать с ресурсами, с которыми одновременно может работать только один.
Тогда все, что они смогут сделать, это поделиться этим ресурсом с течением времени: 
А общая производительность работы с таким ресурсом ограничена скоростью одного ядра: 
Есть два способа решить эту проблему.
Обновите аппаратную часть машины, переключитесь на более быстрые ядра: 
Либо менять архитектуру и заодно менять нагрузку: 
МЧ: — Кстати, на тестовой машине мы будем использовать меньше ядер, чем на боевой, но по частоте на одно ядро они в 1,5 раза быстрее! ММ: - Прозрачный? Вам нужно посмотреть код сервера.
Путь к данным на сервере Zabbix
МЧ: — Чтобы разобраться, мы начали анализировать, как передаются данные внутри Zabbix-сервера:
Классная картинка, правда? Давайте пройдемся по шагам, чтобы было более-менее понятно.
За сбор данных отвечают потоки и сервисы: 
Собранные метрики они передают через сокет менеджеру препроцессора, где они сохраняются в очередь: 
«Менеджер препроцессора» передает данные своим воркерам, которые выполняют инструкции предварительной обработки и возвращают их обратно через тот же сокет: 
После этого менеджер препроцессора сохраняет их в кэше истории: 
Оттуда их забирают сборщики истории, которые выполняют довольно много функций: например, расчет триггеров, заполнение кэша значений и самое главное сохранение метрик в хранилище истории.
В общем, процесс сложный и очень запутанный.
ММ: — Первое, что мы увидели, это то, что большинство потоков конкурируют за так называемый «кеш конфигурации» (область памяти, где хранятся все конфигурации сервера).
Особенно много блокировок выполняют потоки, отвечающие за сбор данных: 
.
так как в конфигурации хранятся не только метрики с их параметрами, но и очереди, из которых поллеры берут информацию о том, что делать дальше.
Когда опросщиков много и один блокирует конфигурацию, остальные ждут запросов: 
Опросники не должны конфликтовать
Поэтому первое, что мы сделали — разделили очередь на 4 части и разрешили поллерам блокировать эти очереди, эти части одновременно, в безопасных условиях:
Это устранило конкуренцию за кэш конфигурации, а скорость опросов значительно возросла.
Но тут мы столкнулись с тем, что менеджер препроцессора начал накапливать очередь заданий: 
Менеджер препроцессора должен уметь расставлять приоритеты
Это происходило в тех случаях, когда ему не хватало работоспособности.
Тогда все, что он мог сделать, — это аккумулировать запросы от процессов сбора данных и складывать их буфер до тех пор, пока он не съест всю память и не упадет: 
Чтобы решить эту проблему, мы добавили второй сокет, специально предназначенный для воркеров: 
Таким образом, у менеджера препроцессора появилась возможность расставить приоритеты в своей работе и в случае роста буфера задача — замедлить удаление, предоставив воркерам возможность забрать этот буфер: 
Потом мы обнаружили, что одной из причин замедления были сами рабочие, поскольку они боролись за совершенно неважный для их работы ресурс.
Мы задокументировали эту проблему как исправление ошибки, и она уже решена в новых версиях Zabbix: 
Увеличиваем количество розеток — получаем результат
Далее узким местом стал сам менеджер препроцессора, так как он один поток.
Он упирался в скорость ядра, давая максимальную скорость около 70 тысяч метрик в секунду: 
Поэтому мы сделали четыре, с четырьмя комплектами розеток, рабочие:
И это позволило нам увеличить скорость примерно до 130 тысяч метрик: 
Нелинейность роста объясняется тем, что появилась конкуренция за кэш истории.
За него соревновались 4 менеджера препроцессора и сборщики истории.
На данный момент мы получали примерно 130 тысяч метрик в секунду на тестовой машине, используя примерно 95% процессора: 
Около 2,5 месяцев назад
Отказ от snmp-сообщества увеличил НВП в полтора раза
ММ: – Макс, мне нужна новая тестовая машина! Мы уже не вписываемся в нынешнюю.МЧ: - Что у тебя есть сейчас? ММ: – Сейчас – 130 тысяч NVP и готовый процессор.
МЧ: - Ух ты! Прохладный! Подождите, у меня два вопроса.
По моим расчетам, наша потребность составляет около 15-20 тысяч метрик в секунду.
Почему нам нужно больше? ММ: «Я хочу закончить работу».
Хотелось бы посмотреть, сколько мы сможем выжать из этой системы.
МЧ: - Но… ММ: «Но для бизнеса это бесполезно».
МЧ: - Ясно.
И второй вопрос: можем ли мы поддерживать то, что имеем сейчас, самостоятельно, без помощи разработчика? ММ: - Я не думаю.
Изменение способа работы кэша конфигурации является проблемой.
Он влияет на изменения в большинстве потоков и его довольно сложно поддерживать.
Скорее всего, поддерживать его будет очень сложно.
МЧ: «Тогда нам нужна какая-то альтернатива».
ММ: - Есть такой вариант. Мы можем перейти на быстрые ядра, отказавшись при этом от новой системы блокировки.
Мы все равно получим производительность в 60-80 тысяч метрик.
При этом весь остальной код мы можем оставить.
Clickhouse и асинхронный опрос будут работать.
И его будет легко поддерживать.
МЧ: - Удивительный! Предлагаю остановиться здесь.
После оптимизации серверной части мы наконец смогли запустить новый код в производство.
Мы отказались от части изменений в пользу перехода на машину с быстрыми ядрами и минимизации количества изменений кода.
Мы также упростили настройку и исключили макросы из элементов данных, где это возможно, поскольку они вводят дополнительную блокировку.
Например, отказ от макроса snmp-community, который часто встречается в документации и примерах, в нашем случае позволил дополнительно ускорить NVP примерно в 1,5 раза.
Спустя два дня производства
Удаление всплывающих окон с историей инцидентов
МЧ: – Миша, пользуемся системой уже два дня, все работает. Но только тогда, когда все работает! У нас были запланированы работы по переносу достаточно большого сегмента сети, и мы еще раз проверили руками, что поднялось, а что нет. ММ: - Не может быть! Мы проверили все 10 раз.Сервер мгновенно обрабатывает даже полную недоступность сети.
МЧ: - Да я все понимаю: сервер, база данных, топ, аустат, логи - все быстро.
Но смотрим веб-интерфейс, а там на сервере "в полке" стоит процессор и вот это: 
ММ: - Ясно.
Давайте посмотрим Интернет. Мы обнаружили, что в ситуации, когда было большое количество активных инцидентов, большинство живых виджетов начинали работать очень медленно: 
Причиной этого стало создание всплывающих окон с историей инцидентов, которые генерируются для каждого элемента списка.
Поэтому мы отказались от генерации этих окон (закомментировали 5 строк в коде), и это решило наши проблемы.
Время загрузки виджетов, даже когда они полностью недоступны, сократилось с нескольких минут до приемлемых для нас 10-15 секунд, а историю по-прежнему можно просмотреть, нажав на время: 
После работы.
2 месяца назад МЧ: - Миша, ты уходишь? Нам надо поговорить.
ММ: - Я не собирался.
Опять что-то с Zabbix? МЧ: - Нет, расслабься! Просто хотел сказать: все работает, спасибо! У меня есть пиво.
Zabbix эффективен
Zabbix — достаточно универсальная и богатая система и функции.Его можно использовать для небольших установок прямо из коробки, но по мере роста потребностей его необходимо оптимизировать.
Для хранения большого архива метрик используйте подходящее хранилище:
- можно использовать встроенные инструменты в виде интеграции с «Эlastiksearch» или выгрузки истории в текстовые файлы (доступно с четвертой версии);
- Вы можете воспользоваться нашим опытом и интеграцией с Clickhouse.
Zabbix написан на C и достаточно эффективен.
Решение нескольких узких мест архитектуры позволяет еще больше повысить его производительность и, по нашему опыту, получить более 100 тысяч метрик на однопроцессорной машине.
Теги: #it-инфраструктура #Системное администрирование #Администрирование серверов #Конференции #zabbix
-
Срочные Задачи. Пусть Придет Спаситель
19 Oct, 24 -
Что Такое 100G?
19 Oct, 24 -
Доступ К Диагностической Консоли Iphone
19 Oct, 24
