Следващата конференция HighLoad++ ще се проведе на 6 и 7 април 2020 година в Санкт Петербург. Подробности и билети. . HighLoad++ Москва 2018. Зала «Москва». 9 ноември, 15:00. Тезиси и .
* Мониторинг — онлайн и аналитика.
* Основни ограничения на платформата ZABBIX.
* Решение за мащабиране на хранилището за аналитика.
* Оптимизация на сървъра ZABBIX.
* Оптимизация на UI.
* Опит в експлоатацията на системата при натоварвания над 40k NVPS.
* Кратки заключения.
Михаил Макуров (по-нататък – ММ): – Всичко приветствам!
Максим Чернецов (по-нататък – МЧ): – Добър ден!
ММ: – Позволете ми да представя Максима. Макс е талантлив инженер, най-добрият мрежовик, когото познавам. Максим се занимава със мрежи и услуги, тяхното развитие и експлоатация.
МЧ: – А аз бих искал да разкажа за Михаил. Михаил е разработчик на C. Той е написал няколко решения с високо натоварване за обработка на трафик за нашата компания. Живеем и работим в Урал, в града на суровите мъже Челябинск, в компания „Интерсвяизн“. Нашата компания е доставчик на интернет услуги и кабелна телевизия за един милион души в 16 града.
ММ: – И заслужава да се каже, че „Интерсвяизн“ е много повече от просто доставчик, това е ИТ компания. Повечето от нашите решения са направени от нашия ИТ отдел.
А: от сървъри, обработващи трафик, до кол център и мобилно приложение. В ИТ отдела в момента има около 80 души с много и много разнообразни компетенции.
За Zabbix и неговата архитектура
МЧ: – А сега ще опитам да поставя личен рекорд и за една минута да кажа какво представлява Zabbix (по-нататък – „Заббикс“).
„Заббикс“ се позиционира като система за мониторинг „извън кутията“ на ниво предприятие. В него има много функции, които улесняват живота: развити правила за ескалация, API за интеграция, групиране и авторазкриване на хостове и метрики. „Заббикс“ разполага с така наречените средства за мащабиране – прокси. „Заббикс“ е система с отворен код.
Кратко за архитектурата. Може да се каже, че тя се състои от три компонента:
- Сървър. Написан на C. С доста сложна обработка и предаване на информация между потоци. Цялата обработка става в него: от получаване до запазване в база.
- Всички данни се съхраняват в база. „Заббикс“ поддържа MySQL, PostgreSQL и Oracle.
- Уеб интерфейсът е написан на PHP. В повечето системи идва с Apache сървър, но работи по-ефективно в комбинация с nginx + php.
Днес искаме да разкажем една история от живота на нашата компания, свързана с «Zabbix»…
История от живота на компанията «Интерсвязь». Какво имаме и какво ни трябва?
Преди 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“ записваше три пъти повече данни. И двете системи обаче изключително ефективно консумираха (малко ресурси) при четене на данни. Но на „Elasticsearch“ му беше необходим голямо количество процесорна мощност при запис:
Общо „Clickhouse“ значително надминава „Elasticsearch“ по потребление на процесора и по скорост. В същото време благодарение на компресията на данните „Clickhouse“ използва 11 пъти по-малко място на твърдия диск и извършва приблизително 30 пъти по-малко дискови операции:
МЧ: – Да, работата с дисковата подсистема в „Clickhouse“ е реализирана много ефективно. За базите може да се използват огромни SATA дискове и да се получи скорост на запис в стотици хиляди реда в секунда. Системата „извън кутията“ поддържа шардване, репликация и е изключително лесна за настройка. Ние сме повече от доволни от експлоатацията ѝ през последната година.
За оптимизация на ресурсите може да се инсталира „Clickhouse“ до съществуващата основна база, спестявайки много процесорно време и дискови операции. Архивът на метриките прехвърлихме на вече наличните кластери на „Clickhouse“:
Ние толкова разтоварихме основната MySQL база, че можехме да я обединим на една машина с „Zabbix“ сървъра и да се откажем от отделен сървър за MySQL.
Как е устроен polling в Zabbix?
Преди 4 месеца
ММ: – Ну, проблемите с базата вече могат да бъдат забравени?
МЧ: – Това е точно! Другата задача, която трябва да решим, е бавният сбор на данни. Сега всички нашите 15 прокси-сървъра са претоварени с процесите на SNMP и поллинга. И няма какво друго да направим, освен да инсталираме нови и нови сървъри.
ММ: – Отлично. Но първо ми разкажи как е организиран поллингът в „Zabbix“?
МЧ: – Накратко, съществуват 20 типа метрики и десетки начини за тяхното получаване. „Zabbix“ може да събира данни или в режим на „запитване – отговор“, или да чака нови данни чрез „Trap Interface“.
Трябва да се отбележи, че в оригиналния „Zabbix“ този метод (Trapper) е най-бързият.
Съществуват прокси-сървъри за разпределение на натоварването:
Прокситата могат да извършват същите функции за събиране, каквито прави „Zabbix“ сървърът, получавайки задания от него и изпращайки събраните метрики точно през Trapper интерфейса. Това е официално препоръчаният начин за разпределение на натоварването. Освен това прокситата са полезни за мониторинг на отдалечената инфраструктура, работеща през NAT или бавна връзка:
ММ: – С архитектурата всичко е ясно. Трябва да проследим изходния код...
Няколко дни по-късно
Приказка за това как nmap fping победи
ММ: – Изглежда, че съм намерил нещо.
МЧ: – Разкажи!
ММ: – Открих, че при проверките за наличност „Zabbix“ проверява максимум до 128 хоста едновременно. Опитах се да увелича това число до 500 и отстраних междупакетния интервал в техния пинг – това увеличи производителността два пъти. Но ми се искаше да имам по-големи числа.
МЧ: – В практиката си понякога ми се налага да проверявам наличността на хиляди хостове и нищо по-бързо от nmap не съм срещал. Сигурен съм, че това е най-бързият начин. Нека го опитаме! Трябва значително да увеличим броя хостове на итерация.
ММ: – Да проверяваме повече от петстотин? 600?
МЧ: – Най-малко няколко хиляди.
ММ: – Окей. Най-важното, което исках да кажа: открих, че повечето от поллингите в „Zabbix“ са направени синхронно. Задължително трябва да го пренапишем на асинхронен режим. Тогава ще можем рязко да увеличим броя на метриките, събирани от поллерите, особено ако увеличим броя на метриките на итерация.
МЧ: – Страхотно! И кога?
ММ: – Както обикновено, вчера.
МЧ: – Сравнихме двете версии fping и nmap:
На много хостове nmap беше очаквано до пет пъти по-ефективен. Тъй като nmap проверява единствено наличността и времето за отговор, прехвърлихме броенето на загубите в тригери и значително намалихме интервалите за проверка на наличността. Оптималното количество хостове за nmap открихме в диапазона на 4 хиляди за една итерация. Nmap ни позволи да намалим разходите за CPU за проверки на наличността три пъти и да съкратим интервала от 120 секунди на 10 секунди.
Оптимизация на поллинга
ММ: – След това се захванахме с поллерите. Основно ни интересуваше извличането на данни чрез SNMP и агенти. В „Zabbix“ поллингът е реализиран синхронно и са приети специални мерки за увеличаване на ефективността на системата. В синхронен режим недостъпността на хостовете предизвиква значително влошаване на поллинга. Съществува цяла система от състояния, има специални процеси – така наречените unreachable-поллери, които работят само с недостъпни хостове:
Това е коментар, който демонстрира матрицата на състоянията, цялата сложност на системата на преходи, необходима за поддържане на ефективността на системата. Освен това, самият синхронен поллинг е достатъчно бавен:
Точно затова хиляди потоци поллери на десетки прокси не можаха да съберат необходимото количество данни за нас. Асинхронната реализация реши не само проблемите с количеството на потоките, но и значително опрости системата на състоянията на недостъпните хостове, тъй като при всяко количество, проверявано в една итерация на поллинга, максималното време на изчакване беше 1 тайм-аут:
Допълнително модифицирахме и усъвършенствахме системата за поллинг на SNMP заявки. Работата е там, че повечето не могат да отговарят на няколко SNMP заявки едновременно. Затова създадохме хибриден режим, в който SNMP поллингът на един и същ хост се извършва асинхронно:
Това се прави за цяла партида хостове. Такъв режим в крайна сметка не е по-бавен от напълно асинхронния, тъй като анкетата на около 150 SNMP стойности все пак е много по-бърза от 1 тайм-аут.
Нашите експерименти показаха, че оптималното количество заявки в една итерация е приблизително 8 хиляди при SNMP поллинг. Общото преминаване към асинхронен режим позволи да се ускори производителността на поллинга 200 пъти, в хиляди пъти.
МЧ: – Получените оптимизации полинг показаха, че не само можем да се отървем от всички проксита, но и да съкратим интервалите за много проверки, а прокситата ще станат ненужни като метод за разпределение на натоварването.
Около три месеца назад
Промени архитектурата – увеличи натоварването!
ММ: – Well, Max, is it time to go productive? I need a powerful server and a good engineer.
МЧ: – Добре, да го планираме. Време е да се преместим от мъртвата точка на 5000 метрики в секунда.
Сутринта след ъпгрейда
МЧ: – Миша, обновихме се, но до сутринта се върнахме обратно… Познай колко скорост успяхме да постигнем?
ММ: – Около 20000 максимално.
МЧ: – Ага, 25! За съжаление, сме на същото ниво, от което започнахме.
ММ: – Защо така? Направихте ли някаква диагностика?
МЧ: – Да, разбира се! Например, интересен top:
ММ: – Нека да видим. Виждам, че сме опитвали огромно количество потоци за полинг:
Но в същото време не успяхме да утилизируем системата дори наполовина:
Общата производителност е доста малка, около 4000 метрики в секунда:
Има ли нещо друго?
МЧ: – Да, strace на един от поллерите:
ММ: – Тук ясно се вижда, че процесът на полинг изчаква "семафори". Това са блокировки:
МЧ: – Непонятно.
ММ: – Виж, това изглежда като ситуация, в която куп потоци се опитват да работят с ресурса, с който може да работи само един. Тогава всичко, което могат да правят, е да разделят този ресурс по време:
И общата производителност при работа с такъв ресурс е ограничена до скоростта на едно ядро:
Този проблем може да се реши по два начина.
Да ъпгрейднете машината, да преминете към по-бързи ядра:
Или да промените архитектурата и паралелно – натоварването:
МЧ: – Между другото, на тестовата машина ще пуснем по-малко ядра, отколкото на производствената, но те ще бъдат с 1.5 по-бързи по честота на ядро!
ММ: – Ясно ли е? Трябва да се погледне кода на сървъра.
Пътят на данните в сървъра Zabbix
МЧ: – За да разберем, започнахме да анализираме как данните се предават вътре в сървъра на "Заббикс":
Страхотна картинка, нали? Нека преминем през нея стъпка по стъпка, за да проясним малко. Има потоци и услуги, отговорни за събиране на данни:
Събраните метрики те предават през сокет на Preprocessor manager, където се запазват в опашка:
"Препроцесор-мениджър" предава данните на своите работници, които изпълняват инструкциите за предварителна обработка и ги връщат обратно през същия сокет:
След това предварителят на процесора ги запазва в кеша на историята:
Оттам ги вземат история-синхронизатори, които изпълняват доста много функции: например, изчисляване на тригери, попълване на кеша с стойности и, най-важното, запазване на метриките в хранилището на история. Общо взето, процесът е сложен и доста заплетен.
ММ: – Първото, което видяхме – е, че повечето потоци съперничат за така нареченото „конфигурационно кеш“ (област памет, където се съхраняват всички конфигурации на сървъра). Особено много блокирания правят потоковете, отговорни за събиране на данни:
…тъй като в конфигурацията се съхраняват не само метрики с техните параметри, но и опашки, от които поллерите получават информация за това какво да правят след това. Когато поллерите са много и един блокира конфигурацията, другите чакат заявки:
Поллерите не трябва да конфликтират
Затова първото, което направихме – е да разделим опашката на 4 части и да разрешим на поллерите в безопасни условия да блокират тези опашки, тези части едновременно:
Това премахна конкуренцията за конфигурационния кеш и скоростта на работа на поллерите значително нарасна. Но след това се сблъскахме с факта, че предварителят на процесора започна да натрупва опашка от задания:
Предварителят на процесора трябва да умее да приоритизира
Това се случваше в случаите, когато му липсваше производителност. Тогава всичко, което можеше да направи – е да натрупва заявки от процесите за събиране на данни и да ги слага в буфер, докато не запълни цялата памет и не падне:
За да решим този проблем, добавихме втори сокет, който бе отделен специално за работниците:
По този начин, предварителят на процесора получи възможността да приоритизира работата си и в случай на увеличаване на буфера задачата да забави събирането, давайки на работниците възможност да вземат този буфер:
След това открихме, че една от причините за забавянето бяха самите работници, тъй като те съперничеха за съвсем ненужен ресурс за тяхната работа. Този проблем оформяхме с bug-fix и в новите версии на „Zabbix“ той вече е решен:
Увеличаваме броя на сокетите – получаваме резултат
След това самият предварител на процесора стана тесен момент, тъй като това е един поток. Той се упираше в скоростта на ядрото, давайки максимална скорост около 70 хиляди метрики в секунда:
Затова направихме четири, с четири комплекта сокети, работници:
И това позволи да увеличим скоростта до около 130 хиляди метрики:
Нелинейността на растежа се обяснява с появата на конкуренция за кеша на историята. За него се конкурираха 4 мениджъра на предварителни обработватели и синхронизатори на историята. Към този момент получавахме на тестовата машина около 130 хиляди метрики в секунда, използвайки я около 95% по процесора:
Около 2.5 месеца назад
Отказът от snmp-community увеличи NVPs с 1.5 пъти
ММ: – Макс, нужна ми е нова тестова машина! В текущата не се побираме вече.
МЧ: – А какво имаме сега?
ММ: – Сега – 130k NVPs и процесор "в рафта".
МЧ: – Ух, страхотно! Изчакай, имам два въпроса. Според моите изчисления, нашата нужда е около 15-20 хиляди метрики в секунда. Защо ни е повече?
ММ: – Искам да завърша нещата до край. Искам да видя колко можем да извлечем от тази система.
МЧ: – Но...
ММ: – Но за бизнеса е безполезно.
МЧ: – Разбирам. И вторият въпрос: могат ли да поддържаме сегашното без помощ от разработчика?
ММ: – Не мисля. Промените в работата с конфигурационния кеш са проблем. Те засягат промените в повечето потоци и са достатъчно сложни за поддръжка. Вероятно ще бъде много трудно да се поддържа.
МЧ: – Тогава трябва да се помисли за някаква алтернатива.
ММ: – Има такъв вариант. Можем да преминем на бързи ядра, отказвайки се от новата система за блокиране. Ще получим производителност от 60-80 хиляди метрики. В същото време можем да запазим целия останал код. "ClickHouse", асинхронният polling ще работят. И това ще бъде лесно за поддръжка.
МЧ: – Чудесно! Предлагам да спрем тук.
След оптимизация на сървърната част най-накрая успяхме да пуснем новия код в продуктив. Отказахме се от част от промените в полза на преминаването на машина с бързи ядра и минимизиране на количеството промени в кода. Също така опростихме конфигурацията и, където е възможно, се отказахме от макросите в елементите на данните, тъй като те са източник на допълнителни блокировки.
Например, отказът от често срещания в документацията и примерите макрос snmp-community в нашия случай позволи допълнително да ускори NVPs с около 1.5 пъти.
След два дни в продуктив
Премахваме изскачащите прозорци на историята на инцидентите
МЧ: – Миша, използваме системата от два дни и всичко работи. Но само когато всичко функционира! Имахме планирани работи с прехвърляне на голям сегмент от мрежата, и отново проверявахме на ръка какво работи и какво – не.
ММ: – Не може да бъде! Проверихме всичко 10 пъти. Сървърът обработва дори пълната недостъпност на мрежата моментално.
МЧ: – Разбирам всичко: сървър, база, top, austat, логове – всичко е бързо… Но гледаме уеб интерфейса, а там – процесорът е "в полка" на сървъра и това:
ММ: – Ясно. Нека да погледнем уеб интерфейса. Открихме, че в ситуации, когато има голямо количество активни инциденти, повечето оперативни уиджети започват да работят много бавно:
Причината беше генерирането на изскачащи прозорци с история на инцидентите, които се генерират за всеки елемент в списъка. Затова отказахме да генерираме тези прозорци (коментирахме 5 реда в кода) и това реши нашите проблеми.
Времето за зареждане на уиджетите дори при пълна недостъпност намаля от няколко минути до допустимите за нас 10-15 секунди, а историята все още може да се вижда с кликване по времето:
След работата. 2 месеца назад.
МЧ: – Миша, тръгваш ли? Имам нещо за казване.
ММ: – Не съм планирал. Отново нещо с "Заббикс"?
МЧ: – Не, успокой се! Просто исках да кажа: всичко работи, благодаря! От мен бира.
Zabbix е ефективен.
"Заббикс" е достатъчно универсална и богата система и функция. Може да се използва за малки инсталации "извън кутията", но с увеличаването на нуждите трябва да се оптимизира. За съхранение на голям архив от метрики използвайте подходящо хранилище:
- можете да използвате вградените средства под формата на интеграция с "Еластиксърч" или експортиране на историята в текстови файлове (достъпно от четвъртата версия);
- можете да използвате нашия опит и интеграцията с "Кликхаус".
За основно увеличаване на скоростта на събиране на метрики, събирайте ги асинхронни методи и ги предавайте през траппер интерфейса в "Заббикс" сървъра; или можете да използвате пач за асинхронността на поллерите на самия "Заббикс".
Zabbix е написан на C и е достатъчно ефективен. Някои архитектурни подобрения позволяват допълнително увеличаване на производителността му и, според нашия опит, позволяват да се получат повече от 100 хиляди метрики на еднопроцесорна машина.
Този патч Zabbix
ММ: – Искам да добавя няколко момента. Цялото текущо представяне, всички тестове, цифрите, представени тук, касаят конкретната конфигурация, която използваме. От нея в момента извличаме около 20 хиляди метрики в секунда. Ако се опитвате да разберете дали това ще работи при вас – можете да сравните. Това, което споделихме днес, е публикувано в GitHub под формата на патч:
Патчът включва:
- пълна интеграция с ClickHouse (как на сървърите на Zabbix, така и на фронтенда);
- решаване на проблеми с мениджъра на предварителната обработка;
- асинхронно polling.
Патчът е съвместим с всичките версии 4, включително и lts. Най-вероятно, с минимални промени, той ще работи и на версия 3.4.
Благодаря ви за вниманието.
Въпроси
Въпрос от публиката (по-долу – В): – Добър ден! Кажете, моля, имате ли планове за активно взаимодействие с екипа на Zabbix или те с вас, така че това да не е патч, а нормално поведение на Zabbix?
ММ: – Да, част от промените определено ще бъдат комитнати. Нещо от тях ще остане в патча.
А: – Благодаря ви много за отличната презентация! Кажете, моля, след прилагането на патча, поддръжката от страна на Zabbix ще остане ли и как ще можем да обновим до по-високи версии? Ще имаме ли възможност да обновим Zabbix след вашия патч до 4.2, 5.0?
ММ: – За поддръжката не мога да кажа. Ако бях техническа поддръжка на Zabbix, вероятно бих казал не, защото това е чужд код. Що се отнася до кодовата база 4.2, нашата позиция е следната: "Ние ще вървим с времето и сами ще се обновяваме до следващата версия". Следователно, за известно време ще публикуваме патчи за обновените версии. Както вече казах в презентацията: количеството на промените с версиите е все още достатъчно малко. Мисля, че преминаването от 3.4 на 4 ни отне около 15 минути. Имаше някои промени, но неособено важни.
А: – Тоест планирате да поддържате своя патч и можем смело да го инсталираме на продукция, получавайки обновления по някакъв начин в бъдеще?
ММ: – Категорично препоръчваме. Това решава много проблеми за нас.
МЧ: Искам отново да акцентирам, че промените, които не засягат архитектурата и не касаят блокировките или опашките, са модулни и са в отделни модули. Дори при незначителни промени, те могат да се поддържат относително лесно.
ММ: Ако ви интересуват детайлите, „Кликхаус“ използва така наречената библиотека за история. Тя е независима – това е копие на поддръжката на „Еластикс“, тоест е конфигурационно променлива. Поллингът променя само поллерите. Считаме, че това ще работи дълго.
А: Много благодаря. И можете ли да ми кажете дали има документация за направените промени?
ММ: Документацията е пач. Очевидно, с въвеждането на „Кликхаус“ и новите типове поллери се появяват нови конфигурационни опции. На линка от последния слайд има кратко описание как да се ползва.
За смяната на fping с nmap
А: Как в крайна сметка реализирахте това? Можете ли с конкретни примери: имате страппери и външен скрипт? Как проверявате толкова бързо огромно количество хостове? Как извличате тези хостове? Трябва ли да се нахрани nmap с тях, да ги получите отнякъде, да ги поставите и да стартирате нещо?
ММ: Страхотно. Много уместен въпрос! Същността е следната. Ние модифицирахме библиотеката (ICMP пинг, част от „Заббикс“) за ICMP проверки, в които е зададено количеството на пакетите – единица (1), а кодът се опитва да използва nmap. Тоест, това е вътрешна работа на „Заббикс“, стана вътрешна работа на пингера. Следователно, не се изисква никаква синхронизация или използване на траппер. Това беше направено съзнателно, за да се запази системата цялостна и да не се занимаваме със синхронизация на две бази – какво да проверяваме, да се качва чрез поллер, без да се счупи ли качването?
А: Работи ли и за прокси?
ММ: Да, но не проверихме. Кодът за поллинг и в „Заббикс“, и на сървера е единен. Трябва да работи. Още веднъж подчертавам: производителността на системата е такава, че не се нуждаем от прокси.
МЧ: Правилният отговор на въпроса е: „А защо ви е прокси при такава система?“ Само заради NAT или за мониторинг през някакъв бавен канал...
А: А вие използвате „Заббикс“ като алартор, ако съм разбрал правилно. Или графиките (където е архивният слой) са преминали в друга система, като Grafana? Или не използвате тази функционалност?
ММ: – Подчертавам отново: ние направихме пълна интеграция. Изпращаме историята в "Кликхаус", но променихме php фронтенда. Php фронтенд изтегля данни от "Кликхаус" и генерира всички графики от там. Ако трябва да бъда честен, имаме част, която черпи данни от същия "Кликхаус", от данните на "Заббикс", за да генерира данни в други системи за графично отображение.
МЧ: – В "Графана", включително.
Как беше взето решението и заделени ли са ресурсите?
А: – Споделете малко вътрешната кухня. Как беше взето решението, че е необходимо да бъдат заделени ресурси за сериозно преосмисляне на продукта? Това е, всъщност, определен риск. И моля, кажете, в контекста на това, че планирате да поддържате нови версии: как обосновавате това решение от гледна точка на управлението?
ММ: – Явно, драматургията на историята не беше много добре представена. Попаднахме в ситуация, в която трябваше да действаме, и следвахме по същество две паралелни направления:
- Едното се занимаваше с внедряването на система за мониторинг с нови методи: мониторинг като услуга, стандартен набор от опенсорсни решения, които комбинираме и след това се опитваме да променим бизнес процесите, за да работим с новата система за мониторинг.
- Паралелно с това, имаме ентусиаст-програмист, който се занимаваше с това (говорейки за себе си). Така се случи, че той победи.
А: – И какъв е размерът на екипа?
МЧ: – Той е пред вас.
А: – Тоест, както винаги, нужен е пасионарий?
ММ: – Не знам какво е пасионарий.
А: – В този случай, вероятно, вие. Много благодаря, вие сте страхотни.
ММ: – Благодаря.
За патчовете за Zabbix
А: – За система, която използва прокси (например в разпределени системи), възможно ли е вашето решение да бъде адаптирано и патчирано, да кажем, за поллерите, проксита и частично предобработвача на самия "Заббикс"; и тяхното взаимодействие? Възможно ли е съществуващите разработки да бъдат оптимизирани за система с няколко прокси?
ММ: – Знам, че "Заббикс"-сървърът се изгражда с помощта на прокси (компилира се и получаваме код). Ние не сме го тествали в продукция. Не съм сигурен в това, но според мен, предобработвача-мениджър не се използва в прокси. Задачата на проксито е да вземе набор от метрики от "Заббикс", да ги сподели (той също така записва конфигурацията, локалната база) и да ги върне обратно на "Заббикс"-сървъра. Предобработката ще бъде извършена впоследствие от самия сървър, когато я получи.
Интересът към проксита е разбираем. Ще го проверим. Темата е интересна.
А: – Идеята беше: ако можете да патчвате поллерите, можете да патчвате и прокситата и да адаптирате взаимодействието със сървъра, а препроцесорът да бъде приспособен само на сървъра за тези цели.
ММ: – Мисля, че е дори по-просто. Вземате кода, налагате патч, след това го конфигурирате по начина, по който ви е нужно – изграждате прокси-сервери (например, с ODBC) и разпространявате патчвания код из системите. Където е необходимо – изграждате прокси, където е необходимо – сървър.
А: – Допълнително патчване на предаването на проксито към сървъра вероятно няма да е нужно?
МЧ: – Не, то е стандартно.
ММ: – Всъщност не се чу някоя от идеите. Винаги сме спазвали баланс между изблиците на идеи и количеството изменения, лекотата на поддръжка.
Малко реклама 🙂
Благодарим ви, че оставате с нас. Харесвате ли нашите статии? Искате ли да виждате повече интересни материали? Подкрепете ни, като направите поръчка или препоръчате на познати, , уникален аналог на entry-level сървъри, който е създаден от нас за вас: (с налични опции за RAID1 и RAID10, до 24 ядра и до 40GB DDR4).
Dell R730xd на половин цена в дата центъра Equinix Tier IV в Амстердам? Всичко това само при нас в Нидерландия! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от 99 $! Чете се за това
Източник: habr.com
