HighLoad++, Михаил Макуров, Максим Чернецов (Intersvyaz): Zabbix, 100kNVPS на един сървър

Следващата конференция HighLoad++ ще се проведе на 6 и 7 април 2020 г. в Санкт Петербург. Подробности и билети по ссылке. HighLoad++ Москва 2018. Зала Москва. 9 ноември, 15:00 часа. Резюмета и представяне.

* Мониторинг - онлайн и анализи.
* Основни ограничения на платформата ZABBIX.
* Решение за мащабиране на съхранение на анализи.
* Оптимизация на ZABBIX сървъра.
* Оптимизация на потребителския интерфейс.
* Опит в работата със системата при натоварвания от повече от 40k NVPS.
* Кратки изводи.

Михаил Макуров (по-нататък - ММ): - Здравейте всички!

Максим Чернецов (по-нататък - MCH): - Добър ден!

MM: Нека ви представя Максим. Макс е талантлив инженер, най-добрият мрежов специалист, когото познавам. Максим се занимава с мрежи и услуги, тяхното развитие и експлоатация.

MCH: – И бих искал да ви разкажа за Майкъл. Майкъл е C разработчик. Той написа няколко решения за обработка на трафик с голямо натоварване за нашата компания. Живеем и работим в Урал, в града на силните мъже Челябинск, в компанията Intersvyaz. Нашата компания е доставчик на интернет и кабелна телевизия за един милион души в 16 града.

MM: - Струва си да се каже, че Intersvyaz е много повече от просто доставчик, това е ИТ компания. Повечето от нашите решения са направени от нашия ИТ отдел.

A: от сървъри, обработващи трафик до кол център и мобилно приложение. ИТ отделът сега има около 80 души с много, много разнообразни компетенции.

За Zabbix и неговата архитектура

MCH: - И сега ще се опитам да поставя личен рекорд и след една минута ще кажа какво е Zabbix (наричан по-нататък - "Zabbiks").

Zabbix се позиционира като готова система за мониторинг на корпоративно ниво. Има много функции, които улесняват живота: усъвършенствани правила за ескалация, API за интеграция, групиране и автоматично откриване на хостове и показатели. Zabbix има така наречените инструменти за мащабиране - проксита. Zabbix е система с отворен код.

Накратко за архитектурата. Можем да кажем, че се състои от три компонента:

• сървър. Написано на C. С доста сложна обработка и пренос на информация между нишки. Цялата обработка се извършва в него: от получаване до запис в базата данни.
• Всички данни се съхраняват в базата данни. Zabbix поддържа MySQL, PostreSQL и Oracle.
• Уеб интерфейсът е написан на PHP. В повечето системи идва със сървъра Apache, но работи по-ефективно в комбинация с nginx + php.

Днес бихме искали да разкажем една история, свързана със Zabbix от живота на нашата компания...

История от живота на компанията Intersvyaz. Какво имаме и от какво се нуждаем?

Преди 5 или 6 месеца. Един ден след работа...

MCH: - Миша, здравей! Радвам се, че успях да те хвана - има разговор. Отново имахме проблеми с мониторинга. При голяма авария всичко се забави и нямаше информация за състоянието на мрежата. За съжаление това не се случва за първи път. Трябва ми помощта ти. Нека нашият мониторинг работи при всякакви обстоятелства!

MM: Но нека първо да синхронизираме. Не съм гледал там от няколко години. Доколкото си спомням, изоставихме Nagios и преминахме към Zabbix преди около 8 години. И сега изглежда, че имаме 6 мощни сървъра и около дузина проксита. Бъркам ли нещо?

MCH: - Почти. 15 сървъра, някои от които са виртуални машини. Най-важното е, че не ни спасява в момента, когато имаме най-голяма нужда. Като инцидент - сървърите се бавят и нищо не се вижда. Опитахме се да оптимизираме конфигурацията, но това не дава оптимален тласък на производителността.

MM: - Ясно е. Гледахте ли нещо, изровихте ли вече нещо от диагностиката?

MCH: - Първото нещо, с което трябва да се справите, е просто базата данни. MySQL вече се зарежда постоянно, запазвайки нови показатели и когато Zabbix започне да генерира куп събития, базата данни влиза в себе си буквално за няколко часа. Вече ви казах за оптимизацията на конфигурацията, но буквално тази година те актуализираха хардуера: сървърите имат повече от сто гигабайта памет и дискови масиви на SSD RAID - няма смисъл да го увеличавате линейно. И какво ще правим?

MM: - Ясно е. Като цяло MySQL е LTP база данни. Очевидно вече не е подходящ за съхранение на архив от метрики с нашия размер. Нека да го разберем.

MCH: - Нека да!

Интеграция на Zabbix и Clickhouse в резултат на хакатона

След известно време получихме интересни данни:

По-голямата част от мястото в нашата база данни беше заето от архива на метрики и по-малко от 1% беше използвано за конфигурация, шаблони и настройки. По това време управлявахме решение за големи данни, базирано на Clickhouse повече от година. Посоката на движение за нас беше ясна. На нашия пролетен хакатон написах интеграцията на Zabbix с Clickhouse за сървъра и интерфейса. По това време Zabbix вече имаше поддръжка за ElasticSearch и ние решихме да ги сравним.

Сравнение на Clickhouse и Elasticsearch

MM: - За сравнение, генерирахме натоварването, същото като това, предоставено от Zabbix сървъра, и разгледахме как ще се държат системите. Написахме данни на партиди от 1000 реда, използвайки CURL. Предварително предположихме, че Clickhouse ще бъде по-ефективен за профила на натоварване, който прави Zabbix. Резултатите дори надминаха очакванията ни:

При същите условия на тестване Clickhouse записва три пъти повече данни. В същото време и двете системи консумират много ефективно (малко количество ресурси) при четене на данни. Но Elastics изискваше голямо количество процесор при запис:

Като цяло Clickhouse значително надмина Elastics по отношение на потреблението на процесора и скоростта. В същото време, поради компресирането на данни, Clickhouse използва 11 пъти по-малко на твърдия диск и извършва около 30 пъти по-малко дискови операции:

MCH: - Да, работата на Clickhouse с дисковата подсистема е реализирана много ефективно. Можете да използвате огромни SATA устройства за бази данни и да получите скорости на запис от стотици хиляди редове в секунда. Системата от кутията поддържа шардинг, репликация и е много лесна за настройка. Повече от доволни сме от работата му през годината.

За да оптимизирате ресурсите, можете да инсталирате Clickhouse до съществуващата основна база и по този начин да спестите много време на процесора и дискови операции. Преместихме архива на показателите в съществуващите клъстери на Clickhouse:

Разтоварихме основната база данни MySQL толкова много, че можехме да я комбинираме на една и съща машина със сървъра Zabbix и да изоставим специалния сървър за MySQL.

Как работи гласуването в Zabbix?

Преди 4 месеца

MM: - Е, можете ли да забравите за проблемите с основата?

MCH: - Това е сигурно! Друго предизвикателство, което трябва да разрешим, е бавното събиране на данни. Сега всичките ни 15 прокси сървъра са претоварени с SNMP и процеси на анкетиране. И няма друг начин освен да инсталирате нови и нови сървъри.

MM: - Страхотен. Но първо, как работи гласуването в Zabbix?

MCH: – Накратко, има 20 вида показатели и дузина начина да ги получите. Zabbix може да събира данни или в режим "заявка-отговор", или да чака нови данни чрез "интерфейса на Trapper".

Струва си да се отбележи, че в оригиналния Zabbix този метод (Trapper) е най-бързият.

Има прокси сървъри за балансиране на натоварването:

Прокситата могат да изпълняват същите функции за събиране като Zabbix сървъра, като получават задачи от него и изпращат събраните показатели само през интерфейса на Trapper. Това е официално препоръчителният начин за разпределяне на товара. Прокситата също са полезни за наблюдение на отдалечена инфраструктура, работеща през NAT или бавна връзка:

MM: С архитектурата всичко е ясно. Трябва да погледна източника...

Няколко дни по-късно

Историята за това как nmap fping спечели

MM: „Изглежда, че изрових нещо.

MCH: - Кажи ми!

MM: - Открих, че когато проверява наличността, Zabbix проверява до максимум 128 хоста едновременно. Опитах се да увелича тази цифра до 500 и премахнах интервала между пакетите в техния ping (ping) - това удвои производителността. Но бих искал големи числа.

MCH: - В моята практика понякога трябва да проверя наличността на хиляди хостове и не съм виждал нещо по-бързо от nmap за това. Сигурен съм, че това е най-бързият начин. Да пробваме! Трябва значително да увеличите броя на хостовете в една итерация.

MM: – Проверете повече от петстотин? 600?

MCH: „Поне няколко хиляди.

MM: - ДОБРЕ. Най-важното нещо, което исках да кажа е, че открих, че по-голямата част от гласуването в Zabbix се извършва синхронно. Трябва да го променим на асинхронен режим. Тогава можем драстично да увеличим броя на показателите, събрани от анкетьорите, особено ако увеличим броя на показателите на итерация.

MCH: - Страхотен! И когато?

MM: - Както обикновено, вчера.

MCH: – Сравнихме двете версии на fping и nmap:

На голям брой хостове се очаква nmap да бъде до пет пъти по-ефективен. Тъй като nmap проверява само наличността и времето за реакция, преместихме изчисляването на загубите към тригери и значително намалихме интервалите за проверка на наличността. Установихме, че оптималният брой хостове за nmap е около 4 хиляди на итерация. Nmap ни позволи да намалим цената на процесора за проверки на наличността с фактор три и да намалим интервала от 120 секунди на 10.

Оптимизация на гласуване

MM: „Тогава се заехме с анкети. Интересувахме се главно от SNMP улавяне и агенти. В Zabbix анкетирането се извършва синхронно и се предприемат специални мерки за повишаване на ефективността на системата. В синхронен режим липсата на хостове причинява значително влошаване на анкетата. Има цяла система от състояния, има специални процеси - така наречените unreachable pollers, които работят само с недостъпни хостове:

Това е коментар, който демонстрира матрицата на състоянието, сложността на преходната система, която е необходима, за да може системата да остане ефективна. В допълнение, самото синхронно анкетиране е доста бавно:

Ето защо хиляди полерни нишки на дузина проксита не можаха да съберат необходимото количество данни за нас. Асинхронното внедряване реши не само проблемите с броя на нишките, но също така значително опрости системата за състояние на недостъпни хостове, тъй като за всеки брой, проверен в една итерация на запитване, максималното време за изчакване беше 1 таймаут:

Освен това модифицирахме и подобрихме системата за анкетиране за SNMP заявки. Факт е, че повечето не могат да отговорят на множество SNMP заявки едновременно. Затова направихме хибриден режим, когато SNMP запитването на същия хост се извършва асинхронно:

Това се прави за целия пакет от хостове. Този режим в крайна сметка не е по-бавен от напълно асинхронния, тъй като запитването на сто и половина SNMP стойности все още е много по-бързо от 1 таймаут.

Нашите експерименти показаха, че оптималният брой заявки в една итерация е около 8 хиляди със SNMP запитване. Общо преходът към асинхронен режим ни позволи да ускорим производителността на анкетите с 200 пъти, няколкостотин пъти.

MCH: – Получените оптимизации на гласуването показаха, че можем не само да се отървем от всички прокси сървъри, но и да намалим интервалите за много проверки и повече няма да са необходими прокси сървъри като начин за споделяне на товара.

Преди около три месеца

Променете архитектурата - увеличете натоварването!

MM: - Е, Макс, време е да сме продуктивни? Трябва ми мощен сървър и добър инженер.

MCH: - Добре, нека планираме. Крайно време е да се преместим от мъртвата точка с 5 хиляди метрики в секунда.

Сутрин след ъпгрейд

MCH: – Миша, надстроихме, но се върнахме сутринта… Познай каква скорост успя да постигнеш?

MM: - 20 хиляди максимум.

MCH: - Да, 25! За съжаление сме точно там, откъдето започнахме.

MM: - Защо? Пускахте ли някаква диагностика?

MCH: - Да, разбира се! Ето, например, един интересен връх:

MM: - Да гледаме. Виждам, че опитахме огромен брой нишки за гласуване:

Но в същото време те не можаха да използват системата дори наполовина:

И общата производителност е доста малка, около 4 хиляди показателя в секунда:

Има ли още нещо?

MCH: – Да, следата на един от анкетьорите:

MM: - Тук можете ясно да видите, че процесът на гласуване чака "семафори". Това са ключалките:

MCH: - Неясен.

MM: – Вижте, това е като ситуация, в която куп нишки се опитват да работят с ресурси, с които само един може да работи едновременно. Тогава всичко, което могат да направят, е да разделят този ресурс по време:

И общата производителност на работа с такъв ресурс е ограничена от скоростта на едно ядро:

Има два начина за решаване на този проблем.

Надстройте хардуера на машината, преминете към по-бързи ядра:

Или сменете архитектурата и паралелно - натоварването:

MCH: - Между другото, на тестовата машина ще използваме по-малък брой ядра, отколкото на бойната машина, но те са 1,5 пъти по-бързи по отношение на честотата на ядро!

MM: - Ясно? Необходимо е да погледнете кода на сървъра.

Път на данни в Zabbix сървър

MCH: - За да разберем, ние започнахме да анализираме как данните се предават вътре в Zabbix сървъра:

Готина снимка, нали? Нека го прегледаме стъпка по стъпка, за да изясним повече или по-малко. Има нишки и услуги, отговорни за събирането на данни:

Те предават събраните показатели през сокета към мениджъра на препроцесора, където се съхраняват в опашката:

Мениджърът на препроцесора" предава данните на своите работници, които изпълняват инструкциите за предварителна обработка и ги връщат обратно през същия сокет:

След това мениджърът на препроцесора ги съхранява в кеша на историята:

Оттам те се вземат от потъвачи на история, които изпълняват доста функции: например изчисляване на тригери, попълване на кеша за стойности и, най-важното, запазване на показатели в хранилището на историята. Като цяло процесът е сложен и много объркващ.

MM: - Първото нещо, което видяхме е, че повечето нишки се конкурират за така наречения "конфигурационен кеш" (областта на паметта, където се съхраняват всички сървърни конфигурации). Особено много заключвания се правят от нишките, отговорни за извличането на данни:

…тъй като конфигурацията съхранява не само показатели с техните параметри, но и опашки, от които анкетьорите вземат информация какво да правят по-нататък. Когато има много анкетьори и един блокира конфигурацията, останалите чакат заявки:

Анкетьорите не трябва да влизат в конфликт

Затова първото нещо, което направихме, беше да разделим опашката на 4 части и да позволим на анкетьорите безопасно да блокират тези опашки, тези части едновременно:

Това премахна конкуренцията за конфигурационния кеш и скоростта на анкетите се увеличи значително. Но тогава се сблъскахме с факта, че мениджърът на препроцесора започна да натрупва опашка от задачи:

Мениджърът на препроцесора трябва да може да приоритизира

Това се случва в случаите, когато липсва производителност. Тогава всичко, което можеше да направи, беше да натрупа заявки от процеси за събиране на данни и да добави техния буфер, докато не изяде цялата памет и се срине:

За да разрешим този проблем, добавихме втори сокет, който беше предназначен специално за работници:

По този начин мениджърът на препроцесора получи възможност да приоритизира работата си и в случай на нарастване на буфера задачата е да забави премахването, като дава възможност на работниците да вземат този буфер:

Тогава открихме, че една от причините за забавянето са самите работници, тъй като те се състезаваха за ресурс, който беше напълно маловажен за тяхната работа. Издадохме корекция на грешки за този проблем и той вече е разрешен в новите версии на Zabbix:

Увеличаваме броя на гнездата - получаваме резултата

Освен това самият препроцесор-мениджър се превърна в пречка, тъй като е една нишка. Тя се основава на скоростта на ядрото, като дава максимална скорост от около 70 хиляди метрики в секунда:

Така че направихме четири работници с четири комплекта гнезда:

И това ни позволи да увеличим скоростта до около 130 хиляди показателя:

Нелинейността на растежа се обяснява с факта, че има конкуренция за кеша на историята. За него се състезаваха 4 мениджъра на предпроцесори и потъващи в историята. До този момент получавахме около 130 хиляди метрики в секунда на тестовата машина, използвайки я от около 95% от процесора:

Преди около 2,5 месеца

Отхвърлянето на snmp-общност увеличи NVP с един и половина пъти

MM: Макс, трябва ми нова тестова кола! Вече не се вписваме в сегашния.

MCH: – Какво имаш сега?

MM: - Сега - 130k NVP и шелф процесор.

MCH: - Еха! Готино! Чакай, имам два въпроса. Според моите изчисления нашата нужда е от порядъка на 15-20 хиляди метрики в секунда. Защо се нуждаем от повече?

MM: - Искам да свърша работата. Искам да видя колко можем да изцедим от тази система.

MCH: - Но…

MM: Но е безполезно за бизнеса.

MCH: - Ясно е. И вторият въпрос: ще можем ли да поддържаме това, което имаме сега, сами, без помощта на разработчик?

MM: - Не мисля. Промяната на начина на работа на конфигурационния кеш е проблем. Той се справя с промените в повечето потоци и е доста труден за поддръжка. Най-вероятно ще бъде много трудно да го поддържате.

MCH: — Тогава имаме нужда от алтернатива.

MM: - Има такъв вариант. Можем да преминем към бързи ядра, като изоставим новата система за блокиране. Все пак ще получим производителност от 60-80 хиляди показателя. В този случай можем да оставим останалата част от кода. Clickhouse, асинхронното анкетиране ще работи. И ще се поддържа лесно.

MCH: - Удивително! Предлагам да спрем дотук.

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

Например, отхвърлянето на макроса snmp-community, който често се среща в документацията и примерите, в нашия случай ни позволи допълнително да ускорим NVP с около 1,5 пъти.

След два дни в производство

Премахване на изскачащи прозорци с история на инциденти

MCH: – Миша, използваме системата от два дни и всичко работи. Но само когато всичко работи! Имахме планирана работа с прехвърлянето на доста голям сегмент от мрежата и отново проверихме с ръцете си какво се е повишило и какво не.

MM: - Не може да бъде! Проверихме всичко 10 пъти. Сървърът се справя незабавно дори с пълна недостъпност на мрежата.

MCH: - Да, разбирам всичко: сървър, база данни, топ, austat, регистрационни файлове - всичко е бързо ... Но ние гледаме уеб интерфейса и има процесор "в рафта" на сървъра и това:

MM: - Ясно е. Да гледаме мрежата. Установихме, че в ситуация, в която имаше голям брой активни инциденти, повечето от оперативните уиджети започнаха да работят много бавно:

Причината за това е генерирането на изскачащи прозорци с история на инциденти, които се генерират за всеки елемент в списъка. Затова отказахме да генерираме тези прозорци (коментирахме 5 реда в кода) и това реши проблемите ни.

Времето за зареждане на джаджа, дори когато е напълно недостъпно, е намалено от няколко минути на 10-15 секунди, което е приемливо за нас, и все още можете да гледате историята, като щракнете върху времето:

След работа. преди 2 месеца

MCH: Миша, тръгваш ли си? Трябва да поговорим.

MM: - Не исках. Пак нещо със Zabbix?

MCH: - Не, спокойно! Просто исках да кажа: всичко работи, благодаря! Бира от мен.

Zabbix е ефективен

Zabbix е доста гъвкава и богата система и функция. Може да се използва за малки инсталации от кутията, но с нарастването на нуждите трябва да се оптимизира. За да съхранявате голям архив от показатели, използвайте подходящо хранилище:

• можете да използвате вградените инструменти под формата на интеграция с Elasticsearch или качване на история в текстови файлове (достъпни от четвъртата версия);
• можете да използвате нашия опит и интеграция с Clickhouse.

За да увеличите драстично скоростта на събиране на показатели, съберете ги с помощта на асинхронни методи и ги прехвърлете през интерфейса на trapper към Zabbix сървъра; или можете да използвате корекцията за асинхронни анкети на самия Zabbix.

Zabbix е написан на C и е доста ефективен. Решението на няколко архитектурни пречки позволява допълнително да се увеличи неговата производителност и според нашия опит да се получат повече от 100 XNUMX показателя на еднопроцесорна машина.

Същата корекция на Zabbix

MM: – Искам да добавя няколко точки. Целият текущ отчет, всички тестове, цифри са дадени за конфигурацията, която използваме. Сега вземаме около 20 хиляди метрики в секунда от него. Ако се опитвате да разберете дали ще ви свърши работа - можете да сравните. Това, за което говорихме днес, е публикувано в GitHub като кръпка: github.com/miklert/zabbix

Пачът включва:

• пълна интеграция с Clickhouse (както Zabbix сървър, така и frontend);
• решаване на проблеми с мениджъра на препроцесора;
• асинхронно анкетиране.

Пачът е съвместим с всички версии 4, включително lts. Най-вероятно с минимални промени ще работи на версия 3.4.

Благодаря ви за вниманието.

Въпроси

Въпрос от публиката (по-нататък - А): - Добър ден! Моля, кажете ми, имате ли планове за интензивно взаимодействие с екипа на Zabbix или те имат с вас, така че това да не е корекция, а нормалното поведение на Zabbix?

MM: – Да, определено ще извършим някои от промените. Нещо ще бъде, нещо ще остане в пластира.

A: – Благодаря ви много за страхотния репортаж! Кажете ми, моля, след прилагане на корекцията поддръжката от Zabbix ще остане и как да надстроите до по-високи версии? Ще бъде ли възможно да актуализирате Zabbix след вашата корекция до 4.2, 5.0?

MM: Не мога да говоря за подкрепа. Ако бях на мястото на техническата поддръжка на Zabbix, тогава, очевидно, бих казал не, защото това е код на някой друг. Що се отнася до кодовата база 4.2, нашата позиция е: „Ще вървим с времето и ще се актуализираме със следващата версия.“ Затова за известно време ще качим корекция за актуализирани версии. Вече казах в доклада: броят на промените с версиите все още е доста малък. Мисля, че преходът от 3.4 към 4 ни отне, изглежда, около 15 мин. Нещо се промени там, но не много важно.

A: - Значи планирате да поддържате корекцията си и можете безопасно да я пуснете в производство, като в бъдеще получавате актуализации по някакъв начин?

MM: - Горещо го препоръчваме. Решава много проблеми за нас.

MCH: - Още веднъж искам да подчертая, че промените, които не се отнасят до архитектурата и не касаят ключалки, опашки - те са модулни, те са в отделни модули. Дори сами по себе си с малки промени, те могат да се поддържат доста лесно.

MM: - Ако се интересувате от подробности, тогава Clickhouse използва така наречената историческа библиотека. Не е свързан - това е копие на поддръжката на Elastics, тоест може да се конфигурира. Анкетирането променя само анкетьорите. Вярваме, че това ще работи дълго време.

A: - Благодаря много. И кажете ми има ли документация за направените промени?

MM: – Документацията е кръпка. Очевидно с въвеждането на Clickhouse, с въвеждането на нови видове анкети, се появяват нови опции за конфигурация. Връзката от последния слайд има кратко описание как да го използвате.

Относно замяната на fping с nmap

A: - Как успяхте да го направите? Можете ли да дадете конкретни примери: имате ли страпери и външен скрипт? Какво в крайна сметка проверява толкова много хостове толкова бързо? Как копаете тези хостове? Трябва ли nmap по някакъв начин да ги нахрани, да ги вземе отнякъде, да ги постави, да управлява нещо?..

MM: - Готино. Много правилен въпрос! Въпросът е следният. Модифицирахме библиотеката (ICMP ping, неразделна част от Zabbix) за ICMP проверки, които показват броя на пакетите - един (1), а кодът се опитва да използва nmap. Тоест, това е вътрешната работа на Zabbix, стана вътрешна работа на pinger. Съответно не е необходима синхронизация или използване на трапер. Това е направено умишлено, за да се запази системата непокътната и да не се синхронизират двете базови системи: какво да проверяваме, качваме през анкетата и дали качването ни е повредено?.. Много по-лесно е.

A: – Работи ли и за проксита?

MM: Да, но не сме проверили. Кодът за избиране е един и същ както в Zabbix, така и в сървъра. Трябва да работи. Още веднъж подчертавам: производителността на системата е такава, че не се нуждаем от прокси.

MCH: - Правилният отговор на въпроса е: „Защо имате нужда от прокси с такава система?“ Само заради NAT'a или за наблюдение през бавен канал някои ...

A: - И вие използвате Zabbix като алертор, ако разбирам правилно. Или графиката (където е архивният слой) е отишла в друга система, например Grafana? Или не използвате тази функционалност?

MM: – Още веднъж ще подчертая: направихме пълна интеграция. Изсипваме история в Clickhouse, но в същото време променихме интерфейса на php. Php-frontend отива в Clickhouse и прави всички графики от там. В същото време, честно казано, имаме част, която изгражда данни в други системи за графичен дисплей от същия Clickhouse, от същите Zabbix данни.

MCH: - В "Графана" включително.

Как беше взето решението за разпределяне на ресурсите?

A: – Споделете част от вътрешната кухня. Как се стигна до решението, че трябва да се отделят ресурси за сериозна обработка на продукта? Това са като цяло определени рискове. И моля, кажете ми, в контекста на факта, че ще поддържате нови версии: как това решение е оправдано от управленска гледна точка?

MM: – Явно не сме разказали добре драмата на историята. Озовахме се в ситуация, в която трябваше да се направи нещо, и всъщност отидохме с две паралелни команди:

• Единият участваше в стартирането на система за мониторинг, базирана на нови методи: мониторинг като услуга, стандартен набор от решения с отворен код, които комбинираме и след това се опитваме да променим бизнес процеса, за да работим с новата система за мониторинг.
• Успоредно с това имахме ентусиазиран програмист, който направи това (за себе си). Така се случи, че спечели.

A: – А какъв е размерът на отбора?

MCH: Тя е пред теб.

A: - Тоест, както винаги, е необходим пасионарий?

MM: – Не знам какво е пасионарий.

A: В случая май си ти. Благодаря ви много, вие сте страхотни.

MM: - Благодаря.

Относно пачовете за Zabbix

A: - За система, която използва прокси (например в някои разпределени системи), възможно ли е да се адаптират и заправят, да речем, полери, проксита и частично препроцесора на самия Zabbix; и тяхното взаимодействие? Възможно ли е да се оптимизират съществуващите разработки за система с множество проксита?

MM: - Знам, че сървърът "Zabbix" се сглобява с помощта на прокси (компилира се и се получава кодът). Не сме тествали това в производството. Не съм сигурен за това, но не мисля, че мениджърът на препроцесора се използва в проксито. Задачата на проксито е да вземе набор от показатели от Zabbix, да ги изхвърли (той също така записва конфигурацията, локалната база данни) и да го върне обратно на Zabbix сървъра. След това самият сървър ще извърши предварителната обработка, когато го получи.

Интересът към пълномощниците е обясним. Ще го проверим. Това е интересна тема.

A: – Идеята беше следната: ако можете да кръпвате анкети, можете да ги кръпвате на прокси и да кръпвате взаимодействието със сървъра и да адаптирате препроцесора за тези цели само на сървъра.

MM: - Мисля, че е дори по-лесно. Взимате кода, прилагате кръпка, след което го конфигурирате по начина, по който ви трябва - събирате прокси сървъри (например с ODBC) и разпространявате кръпения код между системите. Където е необходимо - събирайте проксито, където е необходимо - сървъра.

A: - Освен това, най-вероятно няма да се налага да кръпвате прокси трансфера към сървъра?

MCH: Не, стандартно е.

MM: - Всъщност една от идеите не прозвуча. Винаги сме поддържали баланс между експлозията от идеи и броя на промените, лекотата на поддръжка.

Малко реклами 🙂

Благодарим ви, че останахте с нас. Харесвате ли нашите статии? Искате ли да видите още интересно съдържание? Подкрепете ни, като направите поръчка или препоръчате на приятели, облачен VPS за разработчици от $4.99, уникален аналог на сървъри от начално ниво, който беше изобретен от нас за вас: Цялата истина за VPS (KVM) E5-2697 v3 (6 ядра) 10GB DDR4 480GB SSD 1Gbps от $19 или как да споделите сървър? (предлага се с RAID1 и RAID10, до 24 ядра и до 40GB DDR4).

Dell R730xd 2 пъти по-евтин в центъра за данни Equinix Tier IV в Амстердам? Само тук 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV от $199 в Холандия! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - от $99! Прочети за Как да изградим инфраструктура Corp. клас с използване на сървъри Dell R730xd E5-2650 v4 на стойност 9000 евро за стотинка?

Източник: www.habr.com