Келесі HighLoad++ конференциясы 6 жылдың 7 және 2020 сәуірінде Санкт-Петербургте өтеді. Мәліметтер мен билеттер . HighLoad++ Мәскеу 2018. «Мәскеу» залы. 9 қараша, 15:00. Тезистер және .
* Мониторинг – онлайн және аналитика.
* ZABBIX платформасының негізгі шектеулері.
* Аналитикалық сақтауды масштабтауға арналған шешім.
* ZABBIX серверін оңтайландыру.
* UI оңтайландыруы.
* Жүйені 40к NVPS-тен астам жүктемелермен басқару тәжірибесі.
* Қысқаша қорытындылар.
Михаил Макуров (бұдан әрі – ММ): - Бәріңе сәлем!
Максим Чернецов (бұдан әрі – АӘК): - Қайырлы күн!
MM: – Максимді таныстыруға рұқсат етіңізші. Макс - талантты инженер, мен білетін ең жақсы сетевой. Максим желілер мен қызметтерге, олардың дамуы мен жұмысына қатысады.
MCH: – Ал мен сізге Михаил туралы айтқым келеді. Михаил - C әзірлеушісі. Ол біздің компания үшін жоғары жүктемелі трафикті өңдеудің бірнеше шешімдерін жазды. Біз Оралда, Челябинск қаласында, «Интерсвязь» серіктестігінде тұрып, жұмыс істейміз. Біздің компания 16 қаладағы бір миллион адамға Интернет және кабельдік теледидар қызметтерін жеткізуші болып табылады.
MM: – Айта кету керек, Интерсвязь жай ғана провайдер емес, бұл IT-компания. Біздің шешімдеріміздің көпшілігін біздің IT департаментіміз жасайды.
A: трафикті өңдейтін серверлерден байланыс орталығына және мобильді қосымшаға дейін. Қазіргі уақытта IT бөлімінде өте әр түрлі құзыреттерге ие 80-ге жуық адам бар.
Zabbix және оның архитектурасы туралы
MCH: – Ал енді мен жеке рекорд орнатуға тырысамын және бір минут ішінде Zabbix (бұдан әрі «Zabbix» деп аталады) деген не екенін айтамын.
Zabbix өзін кәсіпорын деңгейіндегі қордан тыс бақылау жүйесі ретінде көрсетеді. Оның өмірді жеңілдететін көптеген мүмкіндіктері бар: кеңейтілген күшейту ережелері, біріктіруге арналған API, хосттар мен көрсеткіштерді топтау және автоматты түрде анықтау. Zabbix-те масштабтау құралдары - прокси-серверлер бар. Zabbix - бұл ашық бастапқы жүйе.
Сәулет туралы қысқаша. Ол үш құрамдас бөліктен тұрады деп айта аламыз:
- Сервер. C тілінде жазылған. Ағындар арасында ақпаратты өте күрделі өңдеу және беру. Онда барлық өңдеу жүзеге асады: қабылдаудан бастап деректер қорына дейін сақтауға.
- Барлық деректер дерекқорда сақталады. Zabbix MySQL, PostreSQL және Oracle-ді қолдайды.
- Веб-интерфейс PHP тілінде жазылған. Көптеген жүйелерде ол Apache серверімен бірге келеді, бірақ nginx + php бірге тиімдірек жұмыс істейді.
Бүгін біз Zabbix-пен байланысты компаниямыздың өмірінен бір оқиғаны айтқымыз келеді...
«Интерсвязь» компаниясының өмірінен оқиға. Бізде не бар және бізге не қажет?
5-6 ай бұрын. Бір күн жұмыстан кейін...
MCH: - Миша, сәлем! Мен сізді ұстап алғаныма қуаныштымын - әңгіме бар. Бізде тағы да бақылауда қиындықтар туындады. Ірі апат кезінде бәрі баяу болды және желінің жағдайы туралы ақпарат болмады. Өкінішке орай, мұндай жағдай бірінші рет болып отырған жоқ. Маған сіздің көмегіңіз керек. Мониторингті кез келген жағдайда жұмыс істейік!
MM: -Бірақ алдымен синхронизация жасайық. Бір-екі жылдан бері ол жаққа қарамадым. Менің есімде, біз Нагиосты тастап, шамамен 8 жыл бұрын Заббикске ауыстық. Ал қазір бізде 6 қуатты сервер және он шақты прокси бар сияқты. Мен бірдеңені шатастырамын ба?
MCH: - Дерлік. 15 сервер, олардың кейбіреулері виртуалды машиналар. Ең бастысы, ол бізге өте қажет сәтте бізді құтқармайды. Жазатайым оқиға сияқты - серверлер баяулайды және сіз ештеңе көре алмайсыз. Біз конфигурацияны оңтайландыруға тырыстық, бірақ бұл оңтайлы өнімділікті арттыруды қамтамасыз етпеді.
MM: - Ол түсінікті. Сіз бір нәрсеге қарадыңыз ба, диагностикадан бірдеңе қазып алдыңыз ба?
MCH: – Ең алдымен, деректер базасымен айналысу керек. MySQL үнемі жүктеледі, жаңа көрсеткіштерді сақтайды және Zabbix көптеген оқиғаларды генерациялай бастағанда, дерекқор бірнеше сағатқа артық жұмыс істейді. Мен сізге конфигурацияны оңтайландыру туралы айтып бердім, бірақ биыл олар аппараттық құралдарды жаңартты: серверлерде жүз гигабайттан астам жады және SSD RAID дискілерінің массивтері бар - оны ұзақ мерзімді перспективада сызықты түрде өсірудің қажеті жоқ. Не істейміз?
MM: - Ол түсінікті. Жалпы MySQL LTP дерекқоры болып табылады. Шамасы, ол бұдан былай біздің өлшемдегі метрика мұрағатын сақтауға жарамсыз. Оны анықтап көрейік.
MCH: -Келейік!
Хакатон нәтижесінде Zabbix және Clickhouse интеграциясы
Біраз уақыттан кейін біз қызықты деректер алдық:
Біздің дерекқордағы кеңістіктің көп бөлігін метрика мұрағаты алып жатты және конфигурация, үлгілер және параметрлер үшін 1%-дан азы пайдаланылды. Ол кезде біз Clickhouse негізіндегі Big data шешімін бір жылдан астам уақыт бойы пайдаландық. Қозғалыс бағыты бізге айқын болды. Біздің көктемгі Hackathon-да мен Zabbix-ті Clickhouse-пен сервер мен фронтенд біріктіруін жаздым. Ол кезде Zabbix-те ElasticSearch қолдауы болды және біз оларды салыстыруды жөн көрдік.
Clickhouse және Elasticsearch салыстыру
MM: – Салыстыру үшін, біз Zabbix сервері беретін жүктемені жасадық және жүйелердің қалай әрекет ететінін қарастырдық. Біз CURL көмегімен деректерді 1000 жолдан тұратын топтамалармен жаздық. Біз Clickhouse Zabbix жасайтын жүктеме профилі үшін тиімдірек болады деп алдын ала болжадық. Нәтижелер біздің күткенімізден де асып түсті:
Сол сынақ жағдайында Clickhouse үш есе көп деректерді жазды. Сонымен қатар, деректерді оқу кезінде екі жүйе де өте тиімді (ресурстардың аз мөлшері) тұтынылады. Бірақ Elastics жазу кезінде процессордың үлкен көлемін қажет етті:
Жалпы алғанда, Clickhouse процессорды тұтыну және жылдамдығы бойынша Elastix-тен айтарлықтай жоғары болды. Сонымен қатар, деректерді қысуға байланысты Clickhouse қатты дискіде 11 есе аз пайдаланады және дискідегі операцияларды шамамен 30 есе аз орындайды:
MCH: – Иә, Clickhouse-дың дискілік ішкі жүйемен жұмысы өте тиімді. Дерекқорлар үшін үлкен SATA дискілерін пайдалана аласыз және секундына жүздеген мың жолдардың жазу жылдамдығын ала аласыз. Шығарылған жүйе бөлшектеуді, репликацияны қолдайды және конфигурациялау өте оңай. Біз оны жыл бойына пайдалануымызға қанағаттанамыз.
Ресурстарды оңтайландыру үшін Clickhouse бағдарламасын бар негізгі дерекқордың жанына орнатуға және сол арқылы процессордың көп уақытын және дискідегі операцияларды үнемдеуге болады. Біз метрика мұрағатын бар Clickhouse кластерлеріне жылжыттық:
Біз негізгі MySQL дерекқорын босатқанымыз сонша, оны бір машинада Zabbix серверімен біріктіріп, MySQL үшін арнайы серверден бас тарта аламыз.
Сауалнама Zabbix-те қалай жұмыс істейді?
4 ай бұрын
MM: – Ал, базаға қатысты мәселелерді ұмыта аламыз ба?
MCH: - Бұл сөзсіз! Біз шешетін тағы бір мәселе - деректерді жинаудың баяу болуы. Қазір біздің барлық 15 прокси серверлеріміз SNMP және сауалнама процестерімен шамадан тыс жүктелген. Жаңа және жаңа серверлерді орнатудан басқа амал жоқ.
MM: - Тамаша. Бірақ алдымен Zabbix-те дауыс беру қалай жұмыс істейтінін айтып беріңізші?
MCH: – Қысқасы, метриканың 20 түрі және оларды алудың ондаған жолы бар. Zabbix деректерді «сұрау-жауап» режимінде жинай алады немесе «Траппер интерфейсі» арқылы жаңа деректерді күте алады.
Айта кету керек, түпнұсқа Zabbix-те бұл әдіс (Trapper) ең жылдам.
Жүктемені тарату үшін прокси серверлер бар:
Прокси-серверлер Zabbix серверімен бірдей жинақ функцияларын орындай алады, одан тапсырмалар алады және жиналған көрсеткіштерді Trapper интерфейсі арқылы жібереді. Бұл жүкті таратудың ресми ұсынылған жолы. Прокси-серверлер NAT немесе баяу арна арқылы жұмыс істейтін қашықтағы инфрақұрылымды бақылау үшін де пайдалы:
MM: – Сәулет өнерімен бәрі түсінікті. Біз дереккөздерді қарауымыз керек ...
Бір-екі күннен кейін
Nmap fping қалай жеңгені туралы әңгіме
MM: «Мен бірдеңе қазып алдым деп ойлаймын».
MCH: - Маған айт!
MM: – Мен қолжетімділікті тексеру кезінде Zabbix бір уақытта ең көбі 128 хостты тексеретінін білдім. Мен бұл санды 500-ге дейін көбейтуге және олардың пингіндегі (пинг) пакетаралық интервалды жоюға тырыстым - бұл өнімділікті екі есе арттырды. Бірақ мен үлкенірек сандарды алғым келеді.
MCH: – Менің тәжірибемде кейде мыңдаған хосттардың қолжетімділігін тексеруге тура келеді, мен бұл үшін nmap-тен жылдамырақ ештеңе көрген емеспін. Мен бұл ең жылдам жол екеніне сенімдімін. Байқап көрейік! Итерациядағы хосттар санын айтарлықтай арттыруымыз керек.
MM: – Бес жүзден астам тексеру керек пе? 600?
MCH: - Кем дегенде екі мың.
MM: - ЖАРАЙДЫ МА. Мен айтқым келген ең маңызды нәрсе - мен Zabbix-те дауыс берудің көпшілігі синхронды түрде жүргізілетінін байқадым. Біз оны асинхронды режимге өзгертуіміз керек. Содан кейін біз сауалнамалар жинайтын көрсеткіштердің санын күрт арттыра аламыз, әсіресе әрбір итерациядағы көрсеткіштер санын көбейтсек.
MCH: - Тамаша! Ал қашан?
MM: – Әдеттегідей кеше.
MCH: – Біз fping және nmap екі нұсқасын салыстырдық:
Көптеген хосттарда nmap бес есе тиімдірек болады деп күтілді. nmap тек қолжетімділік пен жауап беру уақытын тексеретіндіктен, біз шығындарды есептеуді триггерлерге ауыстырдық және қолжетімділікті тексеру аралықтарын айтарлықтай қысқарттық. Біз nmap үшін хосттардың оңтайлы санын итерацияға шамамен 4 мың деп таптық. Nmap бізге қолжетімділікті тексерудің CPU құнын үш есе азайтуға және аралықты 120 секундтан 10-ға дейін азайтуға мүмкіндік берді.
Дауыс беруді оңтайландыру
MM: «Содан кейін біз сауалнама жүргізе бастадық. Бізді негізінен SNMP анықтау және агенттері қызықтырды. Zabbix-те сауалнама синхронды түрде жүргізіледі және жүйенің тиімділігін арттыру үшін арнайы шаралар қабылданды. Синхронды режимде хосттың қолжетімсіздігі сауалнаманы айтарлықтай нашарлатады. Күйлердің тұтас жүйесі бар, арнайы процестер бар - қол жетімсіз сауалнамалар деп аталатын, олар тек қолжетімсіз хосттармен жұмыс істейді:
Бұл жүйенің тиімді болып қалуы үшін қажетті ауысулар жүйесінің барлық күрделілігін, күй матрицасын көрсететін түсініктеме. Сонымен қатар, синхронды сұраудың өзі өте баяу:
Сондықтан ондаған прокси-серверлердегі мыңдаған сауалнамалық ағындар біз үшін қажетті деректер көлемін жинай алмады. Асинхронды іске асыру ағындар санына қатысты мәселелерді шешіп қана қоймай, сонымен қатар қолжетімсіз хосттардың күй жүйесін айтарлықтай жеңілдетті, өйткені бір сұрау итерациясында тексерілген кез келген сан үшін күтудің максималды уақыты 1 күту уақыты болды:
Оған қоса, біз SNMP сұраулары үшін сұрау жүйесін өзгерттік және жетілдірдік. Өйткені, адамдардың көпшілігі бір уақытта бірнеше SNMP сұрауларына жауап бере алмайды. Сондықтан, бір хосттың SNMP сұрауы асинхронды түрде орындалған кезде гибридті режимді жасадық:
Бұл хосттардың бүкіл бумасы үшін жасалады. Бұл режим, сайып келгенде, толық асинхронды режимнен баяу емес, өйткені бір жарым жүз SNMP мәнін сұрау әлі де 1 күту уақытынан әлдеқайда жылдам.
Біздің эксперименттер бір итерациядағы сұраныстардың оңтайлы саны SNMP сауалнамасы арқылы шамамен 8 мың болатынын көрсетті. Жалпы алғанда, асинхронды режимге көшу сауалнама жүргізуді 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 серверінде деректердің қалай тасымалданатынын талдауды бастадық:
Керемет сурет, солай ма? Азды-көпті түсінікті болу үшін оны кезең-кезеңімен қарастырайық. Деректерді жинауға жауапты ағындар мен қызметтер бар:
Олар жиналған көрсеткіштерді розетка арқылы Preprocessor менеджеріне жібереді, онда олар кезекте сақталады:
«Процессор менеджері» өз қызметкерлеріне деректерді жібереді, олар алдын ала өңдеу нұсқауларын орындайды және оларды сол ұяшық арқылы қайтарады:
Осыдан кейін препроцессор менеджері оларды тарих кэшінде сақтайды:
Сол жерден оларды көптеген функцияларды орындайтын тарихты түсірушілер алады: мысалы, триггерлерді есептеу, мән кэшін толтыру және ең бастысы тарих қоймасында көрсеткіштерді сақтау. Жалпы, процесс күрделі және өте түсініксіз.
MM: – Біз көрген бірінші нәрсе, ағындардың көпшілігі «конфигурация кэші» деп аталатын (барлық сервер конфигурациялары сақталатын жад аймағы) үшін бәсекелеседі. Деректерді жинауға жауапты ағындар әсіресе көп блоктауды жасайды:
...өйткені конфигурация тек параметрлері бар көрсеткіштерді ғана емес, сонымен қатар сұраушылар келесі әрекеттер туралы ақпаратты алатын кезектерді сақтайды. Сауалнамашылар көп болса және біреуі конфигурацияны блоктаса, басқалары сұрауларды күтеді:
Сауалнамашылар қақтығыс болмауы керек
Сондықтан, біз бірінші кезекте кезекті 4 бөлікке бөліп, сауалнамашыларға осы кезектерді, осы бөліктерді қауіпсіз жағдайларда бір уақытта блоктауға мүмкіндік бердік:
Бұл конфигурация кэшіне арналған бәсекелестікті алып тастады және сұраушылардың жылдамдығы айтарлықтай өсті. Бірақ содан кейін біз препроцессор менеджерінің жұмыс кезегін жинай бастағанына тап болдық:
Препроцессор менеджері басымдықтарды белгілей алуы керек
Бұл оның өнімділігі жеткіліксіз болған жағдайларда болды. Содан кейін ол тек деректерді жинау процестерінен сұрауларды жинақтау және олардың буферін барлық жадты пайдаланғанша және бұзылғанша қосу болды:
Бұл мәселені шешу үшін біз арнайы жұмысшыларға арналған екінші розетка қостық:
Осылайша, препроцессор менеджері өз жұмысына басымдық беру мүмкіндігіне ие болды және егер буфер өссе, жұмысшыларға осы буферді алу мүмкіндігін бере отырып, жоюды бәсеңдету міндеті тұр:
Содан кейін біз баяулау себептерінің бірі жұмысшылардың өздері екенін анықтадық, өйткені олар өз жұмысы үшін мүлдем маңызды емес ресурс үшін бәсекелесті. Біз бұл мәселені қатені түзету ретінде құжаттадық және ол Zabbix жаңа нұсқаларында шешілді:
Біз розеткалардың санын көбейтеміз - нәтиже аламыз
Әрі қарай, препроцессор менеджерінің өзі тығырықтан шықты, өйткені ол бір жіп. Ол негізгі жылдамдыққа сүйеніп, секундына шамамен 70 мың метрикалық максималды жылдамдықты берді:
Сондықтан біз төрт розеткамен төрт жұмыс жасадық:
Бұл жылдамдықты шамамен 130 мың метрикаға дейін арттыруға мүмкіндік берді:
Өсудің сызықты еместігі тарих кэшіне бәсекелестіктің пайда болуымен түсіндіріледі. Ол үшін 4 препроцессор менеджері мен тарихты сіңірушілер жарысты. Осы кезде біз сынақ машинасында секундына шамамен 130 мың метриканы қабылдадық, оны процессордың шамамен 95% пайдаланады:
Осыдан 2,5 ай бұрын
Snmp-қоғамдастығынан бас тарту NVP-терді бір жарым есеге арттырды
MM: – Макс, маған жаңа сынақ машинасы керек! Біз енді қазіргіге сыймаймыз.
MCH: - Қазір сенде не бар?
MM: – Қазір – 130 мың NVP және сөреге дайын процессор.
MCH: - Мәссаған! Керемет! Күте тұрыңыз, менің екі сұрағым бар. Менің есептеуім бойынша, біздің қажеттілік секундына 15-20 мың метрика шамасында. Неліктен бізге көбірек қажет?
MM: «Мен жұмысты аяқтағым келеді». Мен бұл жүйеден қаншалықты сыға алатынымызды көргім келеді.
MCH: -Бірақ...
MM: «Бірақ бұл бизнес үшін пайдасыз».
MCH: - Ол түсінікті. Ал екінші сұрақ: біз қазір бар нәрсені әзірлеушінің көмегінсіз өз күшімізбен асыра аламыз ба?
MM: - Мен ойламаймын. Конфигурация кэшінің жұмысын өзгерту - мәселе. Ол көптеген ағындардағы өзгерістерге әсер етеді және оны сақтау өте қиын. Сірә, оны сақтау өте қиын болады.
MCH: «Онда бізге қандай да бір балама керек».
MM: – Ондай нұсқа бар. Біз жаңа құлыптау жүйесінен бас тарта отырып, жылдам ядроларға ауыса аламыз. Біз әлі де 60-80 мың метрикалық өнімділікке ие боламыз. Бұл ретте кодтың қалған бөлігін қалдыра аламыз. Clickhouse және асинхронды сұрау жұмыс істейді. Және оған күтім жасау оңай болады.
MCH: - Керемет! Мен осы жерден тоқтауды ұсынамын.
Сервер жағын оңтайландырғаннан кейін біз жаңа кодты өндіріске енгізе алдық. Біз жылдам ядролары бар машинаға ауысу және код өзгерістерінің санын азайту пайдасына кейбір өзгерістерден бас тарттық. Сондай-ақ біз конфигурацияны жеңілдеттік және мүмкіндігінше деректер элементтеріндегі макростарды жойдық, өйткені олар қосымша құлыптауды енгізеді.
Мысалы, құжаттамада және мысалдарда жиі кездесетін snmp-қауымдастық макросынан бас тарту біздің жағдайда NVP-ті шамамен 1,5 есе жылдамдатуға мүмкіндік берді.
Өндірісте екі күннен кейін
Оқиға тарихының қалқымалы терезелерін жою
MCH: – Миша, біз жүйені екі күн бойы қолданып жатырмыз, бәрі жұмыс істейді. Бірақ бәрі жұмыс істегенде ғана! Біз желінің едәуір үлкен сегментін берумен жұмысты жоспарлаған болатынбыз және біз тағы да қолымызбен ненің көтерілгенін және ненің көтерілмегенін тексердік.
MM: - Болуы мүмкін емес! Барлығын 10 рет тексердік. Сервер желінің толық қолжетімсіздігін бірден өңдейді.
MCH: - Иә, мен бәрін түсінемін: сервер, дерекқор, топ, аустат, журналдар - бәрі жылдам... Бірақ біз веб-интерфейске қараймыз, серверде «сөреде» процессор бар және мынау:
MM: - Ол түсінікті. Интернетті көрейік. Белсенді оқиғалардың көп саны болған жағдайда көптеген тікелей виджеттердің өте баяу жұмыс істей бастағанын анықтадық:
Мұның себебі тізімдегі әрбір элемент үшін жасалған оқиға тарихының қалқымалы терезелерін құру болды. Сондықтан, біз осы терезелердің генерациясынан бас тарттық (кодтағы 5 жолды түсіндірдік), бұл біздің мәселелерімізді шешті.
Виджеттерді жүктеу уақыты, тіпті мүлдем қолжетімсіз болса да, бірнеше минуттан біз үшін қолайлы 10-15 секундқа дейін қысқартылды және тарихты әлі де уақытты басу арқылы көруге болады:
Жұмыстан кейін. 2 ай бұрын
MCH: - Миша, кетесің бе? Біз сөйлесуіміз керек.
MM: - Мен ниет еткен жоқпын. Заббикспен тағы бірдеңе болды ма?
MCH: - Жоқ, демалыңыз! Мен жай айтқым келді: бәрі жұмыс істейді, рахмет! Мен сыра алдым.
Zabbix тиімді
Zabbix - бұл әмбебап және бай жүйе мен функция. Оны қораптан тыс шағын қондырғылар үшін пайдалануға болады, бірақ қажеттіліктер өскен сайын оны оңтайландыру керек. Көрсеткіштердің үлкен мұрағатын сақтау үшін қолайлы жадты пайдаланыңыз:
- кірістірілген құралдарды Elasticsearch-пен біріктіру немесе мәтіндік файлдарға тарихты жүктеу түрінде пайдалануға болады (XNUMX-нұсқадан бастап қол жетімді);
- Біздің тәжірибемізді және Clickhouse-пен интеграцияны пайдалана аласыз.
Көрсеткіштерді жинау жылдамдығын күрт арттыру үшін оларды асинхронды әдістер арқылы жинаңыз және оларды Trapper интерфейсі арқылы Zabbix серверіне жіберіңіз; немесе Zabbix сауалнамаларын асинхронды ету үшін патчты пайдалануға болады.
Zabbix C тілінде жазылған және өте тиімді. Бірнеше архитектуралық кедергілерді шешу оның өнімділігін одан әрі арттыруға және біздің тәжірибемізде бір процессорлы машинада 100 мыңнан астам метрика алуға мүмкіндік береді.
Дәл сол Zabbix патч
MM: – Бір-екі ұпай қосқым келеді. Толық ағымдағы есеп, барлық сынақтар, сандар біз қолданатын конфигурация үшін берілген. Қазір біз одан секундына шамамен 20 мың метрика аламыз. Бұл сіз үшін жұмыс істейтінін түсінуге тырыссаңыз, салыстыруға болады. Бүгін талқыланған нәрсе GitHub сайтында патч түрінде жарияланған:
Патч мыналарды қамтиды:
- Clickhouse-мен толық интеграция (Zabbix сервері де, фронтенді де);
- препроцессор менеджерімен есептерді шешу;
- асинхронды сұрау.
Патч lts қоса алғанда барлық 4 нұсқасымен үйлесімді. Ең аз өзгерістермен ол 3.4 нұсқасында жұмыс істейтін болады.
Назарларыңызға рахмет.
Сіздің сұрақтарыңыз
Көрермендер сауалы (бұдан әрі – А): – Қайырлы күн! Айтыңызшы, сізде Zabbix командасымен немесе олармен сізбен қарқынды өзара әрекеттесу жоспарлары бар ма, бұл патч емес, бірақ Zabbix-тің қалыпты мінез-құлқы?
MM: – Иә, біз кейбір өзгерістерді міндетті түрде жасаймыз. Бірдеңе болады, бірдеңе патчта қалады.
A: – Тамаша баяндамаңыз үшін көп рахмет! Маған айтыңызшы, патчты қолданғаннан кейін Zabbix қолдауы қалады және жоғарырақ нұсқаларға жаңартуды қалай жалғастыруға болады? 4.2, 5.0 патчтан кейін Zabbix жаңарту мүмкін бе?
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-тің ішкі жұмысы. Тиісінше, синхрондау немесе трапперді пайдалану қажет емес. Бұл жүйені тұтас қалдыру және екі дерекқор жүйесін синхрондаумен айналыспау үшін әдейі жасалды: нені тексеру керек, сауалнама арқылы жүктеп салу және біздің жүктеуіміз бұзылды ма?.. Бұл әлдеқайда қарапайым.
A: – Бұл прокси үшін де жұмыс істей ме?
MM: – Иә, бірақ тексерген жоқпыз. Сауалнама коды Zabbix-те де, серверде де бірдей. Жұмыс істеу керек. Тағы да атап өтейін: жүйенің өнімділігі сонша, бізге прокси қажет емес.
MCH: – Сұраққа дұрыс жауап: «Мұндай жүйесі бар прокси не үшін қажет?» Тек NAT немесе қандай да бір баяу арна арқылы бақылау себебінен...
A: – Ал сіз Zabbix-ті аллертор ретінде қолданасыз, егер мен дұрыс түсінсем. Немесе графикаңыз (мұрағат қабаты орналасқан жерде) Grafana сияқты басқа жүйеге ауыстырылды ма? Немесе сіз бұл функцияны пайдаланбайсыз ба?
MM: – Тағы да атап өтейін: біз толық интеграцияға қол жеткіздік. Біз Clickhouse-ға тарихты құйып жатырмыз, бірақ сонымен бірге PHP фронтенді өзгерттік. Php фронтенді 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: – Негізінде, бір ойы естілмей қалды. Біз әрқашан идеялардың жарылуы мен өзгерістер көлемі мен қолдаудың қарапайымдылығы арасындағы тепе-теңдікті сақтадық.
Кейбір жарнамалар 🙂
Бізбен бірге болғандарыңызға рахмет. Сізге біздің мақалалар ұнайды ма? Қызықты мазмұнды көргіңіз келе ме? Тапсырыс беру немесе достарыңызға ұсыну арқылы бізге қолдау көрсетіңіз, , Сіз үшін біз ойлап тапқан бастапқы деңгейдегі серверлердің бірегей аналогы: (RAID1 және RAID10, 24 ядроға дейін және 40 ГБ DDR4 дейін қол жетімді).
Dell R730xd Амстердамдағы Equinix Tier IV деректер орталығында 2 есе арзан ба? Тек осында Нидерландыда! Dell R420 - 2x E5-2430 2.2 ГГц 6C 128 ГБ DDR3 2x960 ГБ SSD 1 Гбит/с 100 ТБ - 99 доллардан бастап! туралы оқыңыз
Ақпарат көзі: www.habr.com