Növbəti HighLoad++ konfransı 2020-ci il aprelin 6 və 7-də Sankt-Peterburqda keçiriləcək. Ətraflı məlumat və biletlər . HighLoad++ Moskva 2018. "Moskva" zalı. 9 noyabr, 15:00. Tezis və .
* Monitorinq — onlayn və analitika.
* ZABBIX platformasının əsas məhdudiyyətləri.
* Analitika saxlama həllinin miqyaslandırılması.
* ZABBIX serverinin optimallaşdırılması.
* UI optimallaşdırılması.
* Yük altında 40k NVPS-dən çox sistemin istismarı təcrübəsi.
* Qısa nəticələr.
Mihail Makurov (daha sonra – MM): – Hamıya salam!
Maksim Çernecov (daha sonra – MÇ): – Günaydın!
MM: – Maksimi təqdim etməyə icazə verin. Maks – tanınmış mühəndis, tanıdığım ən yaxşı şəbəkəçi. Maksim şəbəkə və xidmətlərlə, onların inkişafı və istismarı ilə məşğuldur.
MÇ: – Mən isə Mihail haqqında danışmaq istəyirəm. Mihail – C dilində proqramçı. O, şirkətimiz üçün trafik emalı üzrə bir neçə yüksək yüklü həllər yazıb. Biz Uralda, sərt insanların şəhəri Çelyabinskdə yaşayırıq və işləyirik, "İntersvyaz" şirkətindəyik. Şirkətimiz 16 şəhərdə bir milyondan çox insan üçün internet və kabel televiziyası xidmətləri təqdim edir.
MM: – Və demək lazımdır ki, "İntersvyaz" - sadəcə bir provayder deyil, bu, bir IT şirkətidir. Çoxtanlılarımızın əksəriyyəti IT şöbəmiz tərəfindən qurulub.
A: trafik emalı edən serverlərdən, çağrı mərkəzindən və mobil tətbiqdən ibarətdir. IT şöbəsində hazırda müxtəlif kompetensiyalara sahib təxminən 80 nəfər var.
Zabbix və onun arxitekturası
MÇ: – İndi mən şəxsi rekordu qoymağa çalışacağam və bir dəqiqə ərzində Zabbix-in (daha sonra – "Zabbix") nə olduğunu deməyə çalışacağam.
"Zabbix" özünü "çatıdan" işgüzar səviyyəli monitorinq sistemi kimi təqdim edir. O, həyatımızı asanlaşdıran bir çox funksiyalara malikdir: inkişaf etmiş eskalasiya qaydaları, inteqrasiya üçün API, ev sahibi və metriklərin qruplaşdırılması və avtomatik aşkar edilməsi. "Zabbix"-də belə adlanan miqyaslandırma vasitələri var – proksi. "Zabbix" açıq mənbəli bir sistemdir.
Arxitekturadan qısa. Demək olar ki, o, üç komponentdən ibarətdir:
- Server. C dilində yazılıb. Yetərincə mürəkkəb informasiya emalı və axınlar arasında məlumat ötürməsi ilə. Bütün emal burada baş verir: alınmadan, verilənlərin bazada saxlanmasına qədər.
- Bütün məlumatlar bazada saxlanılır. "Zabbix" MySQL, PostreSQL və Oracle dəstəkləyir.
- Veb-interfeys PHP dilində yazılıb. Çoxsaylı sistemlərdə Apache serveri ilə birlikdə verilir, lakin daha effektiv nginx + php birliyində işləyir.
Bu gün biz şirkətimizdən "Zabbix" ilə bağlı bir hekayə təqdim etmək istəyirik...
"İntersvyaz" şirkətinin həyatından bir hekayə. Nəyi var və nəyə ehtiyac var?
5 ya da 6 ay əvvəl. Bir gün işdən sonra...
MÇ: – Misha, salam! Səni tutduğuma şadam – bir söhbətimiz var. Yenə monitorinqdə problemlərimiz oldu. Böyük bir qəza zamanı hər şey ləngidi və şəbəkənin vəziyyəti haqqında heç bir məlumat yox idi. Təəssüf ki, bu artıq birinci dəfə deyil. Sənin köməyinə ehtiyacım var. Gəlin elə edək ki, monitorinqimiz hər vəziyyətdə işləsin!
MM: – Amma əvvəlcə sinxronlaşaq. Oraya artıq iki il baxmamışam. Yadıma düşdüyü qədər, biz Nagios-dan imtina edib 8 il bundan əvvəl «Zabbix»-ə keçmişdik. İndi isə bizdə, göründüyü kimi, 6 güclü server və təxminən on proxy var. Heç nəyi qarışdırmıram?
MÇ: – Demək olar ki. 15 server var, onların bəziləri virtual maşınlardır. Ən əsası, bu, bizi ən çox ehtiyac duyduğumuz anda xilas etmir. Qəza zamanı serverlər ləngiyir və heç nə görünmür. Konfiqurasiyanı optimallaşdırmağa çalışdıq, amma bu, optimal performans artımı vermir.
MM: – Aydın. Nələrə baxmısan, diagnostikadan nələr tapmısan?
MÇ: – İlk növbədə, qarşılaşdığımız məsələ MDB-dir. MySQL onsuz da daim yüklüdür, yeni metrikləri saxlayır, «Zabbix» bir sürü hadisə yaratmağa başlayanda – baza özünə tamamilə bir neçə saatla çəkilir. Konfiqurasiyanı optimallaşdırmaqdan artıq özünü danışdım, amma bu ildən biz avadanlığı yenilədik: serverlərdə yüzdən çox GB yaddaş var və SSD RAID-lə disk massivləri – daha da xətti artırmaq mənasızdır. Nə edəcəyik?
MM: – Aydındır. Ümumiyyətlə, MySQL LTP bazasıdır. Görünür, bizim ölçüdə metrik arxivini saxlamaq üçün artıq uyğun deyil. Gəlin problemi həll edək.
MÇ: – Gəlin!
Zabbix və Clickhouse inteqrasiyası hackathonun nəticəsi
Bir müddət sonra maraqlı verilənlər əldə etdik:
Baza yerimizin böyük hissəsi metrik arxivi tərəfindən tutulmuşdu və 1%-dən azı konfiqurasiya, şablonlar və ayarlar üçün istifadə edilirdi. O müddət ərzində artıq bir ildən çoxdur ki, Clickhouse-a əsaslanan Big data həllini işlədirdik. İrəliləmə istiqamətimiz aydın idi. Yazda keçirilən “Hackathon”da «Zabbix» ilə «Clickhouse» arasında server və frontend üçün inteqrasiya yazdım. O vaxt «Zabbix»də ElasticSearch dəstəyi artıq var idi, biz də onları müqayisə etməyə qərar verdik.
Clickhouse və Elasticsearch müqayisəsi
MM: – Müqayisə üçün, «Zabbix»-serverin təmin etdiyi yüklənməyə bənzər bir yük yaradırdıq və sistemlərin necə davrandığını izləyirdik. Məlumatları 1000 sətirdən ibarət dəstlərdə yazırdıq, CURL istifadə edirdik. Əvvəlcədən «Clickhouse»-un «Zabbix»in etdiyinə uyğun yük profilində daha səmərəli olacağını düşünürdük. Nəticələr gözləmələrimizi aşdı:
Eynitərəfli şəraitdə «Clickhouse» üç dəfə daha çox məlumat yazırdı. Həmçinin, hər iki sistem (az resurs istehlak edərkən) verilənləri oxumaqda çox səmərəli idi. Lakin «Elastic» üçün yazma zamanı böyük miqdarda prosessor tələb olunurdu:
Ümumilikdə, «ClickHouse» prosessor istehlakı və sürət baxımından «Elasticsearch»-dan əhəmiyyətli dərəcədə üstündür. Məlumatların sıxılması sayəsində «ClickHouse» sərt diskdə 11 dəfə az yer istifadə edir və təxminən 30 dəfə daha az disk əməliyyatı həyata keçirir:
MÇ: – Bəli, «ClickHouse»-un disk alt sisteminə dair işləri çox effektivdir. Verilənlər bazası üçün böyük SATA disklərdən istifadə edilərək saniyədə yüz minlərlə sətir yazma sürətinə nail olmaq mümkündür. Sistem «qutudan çıxan» şəkildə şarding və replikasiyanı dəstəkləyir, quraşdırması çox sadədir. Biz onun bir il ərzində istifadəsindən çox məmnun qalmışıq.
Resursları optimallaşdırmaq üçün «ClickHouse»-u mövcud əsas verilənlər bazasının yanında quraşdırmaq mümkündür və bu, çoxsaylı prosessor vaxtını və disk əməliyyatlarını saxlamağa kömək edir. Biz metriklərin arxivini artıq mövcud «ClickHouse» klasterlərinə çıxardıq:
Biz əsas MySQL verilənlər bazasını o qədər yüklədik ki, onu «Zabbix» serveri ilə eyni maşında birləşdirə bildik və MySQL üçün ayrılmış serverdən imtina etdik.
Zabbix-də polling necə işləyir?
4 ay əvvəl
MM: – Yaxşı, verilənlər bazası ilə bağlı problemləri unuda bilərikmi?
MÇ: – Tam olaraq! İndi həll etməli olduğumuz başqa bir məsələmiz var – məlumatların yığılmasının yavaşlığı. İndi bütün 15 proxy serverimiz SNMP və polling prosesləri ilə yüklənib. Yalnız yeni serverlər əlavə etməkdən başqa yolumuz yoxdur.
MM: – Əla. Amma əvvəlcə, «Zabbix»-də polling necə təşkil edildiyini anlat.
MÇ: – Qısa desək, 20 növ metrik və onların toplanması üçün onlarla üsul var. «Zabbix» ya «sorğu - cavab» rejimində məlumat toplayır, ya da «Trapper Interface» vasitəsilə yeni məlumatlar gözləyir.
Diqqətəlayiqdir ki, orijinal «Zabbix»-də bu üsul (Trapper) ən sürətlidır.
Yük balansını bölüşdürmək üçün proxy serverləri mövcuddur:
Proxy-lər, eyni zamanda, «Zabbix» serveri tərəfindən tapşırıqları alır və toplanmış metrikləri dəqiq Trapper interfeysi vasitəsilə göndərərək eyni yığma funksiyalarını həyata keçirə bilər. Bu, yük balansını bölüşdürmək üçün rəsmi tövsiyə olunan üsuldur. Həmçinin, proxy-lər NAT və ya yavaş kanaldan işləyən uzaq infrastrukturu izləmək üçün faydalıdır:
MM: – Arxitektura ilə hər şey aydındır. Mənbə kodlarına baxmaq lazımdır...
Bir neçə gün sonra
Nmap fping-in qələbəsindən bəhs edən dastan
MM: – Görünür, bir şey tapmışam.
MÇ: – Danış!
MM: – Mən aşkar etdim ki, «Zabbix» aktivlik yoxlamaları zamanı maksimum 128 hostu eyni anda yoxlayır. Bu rəqəmi 500-ə qaldırmağa çalışdım və pinglərdə paket aralığını aradan qaldırdım – bu performansı iki dəfə artırdı. Ancaq daha böyük rəqəmlər istəyirəm.
MÇ: – Mənim praktikamda bəzən minlərlə hostun aktivliyini yoxlamaq lazımdır, və mən indiyə qədər bunun üçün nmap-dan daha sürətli bir şey tapmamışam. Mən əminəm ki, bu, ən sürətli üsuldur. Gəlin bunu sınaqdan keçirək! Bir iterasiyada host sayını əhəmiyyətli dərəcədə artırmalıyıq.
MM: – 500-dən çox yoxlayırıq? 600?
MÇ: – Ən azı bir neçə min.
MM: – Yaxşı. Əsas odur ki, demək istədiyim budur: "Zabbix"-də əksər polinqin sinxron aparıldığıdır. Biz mütləq bunu asinxron rejimə keçirməliyik. O zaman polerlərlə toplayacağımız metrikin sayını əhəmiyyətli dərəcədə artıra biləcəyik, xüsusilə də bir iterasiyada toplayacağımız metrikin sayını artırsaq.
MÇ: – Əla! Və nə vaxt?
MM: – Adətən olduğu kimi, dünən.
MÇ: – Həm fping, həm də nmap-in hər iki versiyasını müqayisə etdik:
Çox sayda hostda nmap gözlənildiyi kimi beş dəfə effektli oldu. Nmap yalnız əlçatanlıq və cavab vaxtını yoxlayır, itkiləri hesablamağı isə trigerlərə köçürdük və əlçatanlıq yoxlamalarının intervallarını əhəmiyyətli dərəcədə azaltdıq. Nmap üçün optimal host sayı iterasiyada 4 min civarında tapdıq. Nmap sayəsində CPU sərfiyatını əlçatanlığı yoxlamaqda üç dəfəyə endirə və intervalı 120 saniyədən 10-a endirə bildik.
Polinqin optimallaşdırılması
MM: – Sonra polerlərlə məşğul olduq. Əsasən SNMP çəkilişi və agentlər bizi maraqlandırırdı. "Zabbix"-də polinq sinxron şəkildə həyata keçirilir və sistemin səmərəliliyini artırmaq üçün xüsusi tədbirlər görülüb. Sinxron rejimdə hostların əlçatmazlığı polinqin əhəmiyyətli dərəcədə zəifləyişinə səbəb olur. Tələsiklərə ayrılmış bir neçə sinif var – "unreachable"-polerlər adlanan xüsusi proseslər yalnız əlçatmaz olan hostlarla işləyir:
Bu, sistemin effektiv qalması üçün tələb olunan vəziyyətlər matrisasını, keçidlərin bütün mürəkkəbliyini nümayiş etdirən şərhdir. Bundan başqa, özü də sinxron polinq olduqca yavaşdır:
Buna görə minlərlə poler ipindən bir neçə proxy üzərində istədiyimiz məlumatları toplaya bilmədi. Asinxron həyata keçirilməsi yalnız ip axınının sayını artırma problemi deyil, həm də əlçatmaz hostların vəziyyətlər sistemini əhəmiyyətli dərəcədə asanlaşdırdı, çünki polinqin hər bir iterasiyasında maksimum gözləmə vaxtı 1 zaman aşma idi:
Əlavə olaraq, SNMP sorğuları üçün polinq sistemini modifikasiya etdik. İş burasındadır ki, əksəriyyəti eyni anda bir neçə SNMP sorğusuna cavab verə bilmir. Buna görə də, SNMP polinqin eyni hostda asinxron həyata keçirildiyi hibrid rejimi yaratdıq:
Bu, bütün host xəttləri üçün həyata keçirilir. Nəticə etibarilə bu rejim tamamilə asinxron olmağı ilə eyni sürətli deyil, çünki yarım yüzdə bir SNMP dəyərinin yoxlanması yenə də 1 zaman aşmasından daha sürətlidir.
Eksperimentlərimiz göstərdi ki, bir iterasiyada optimal sorğu sayı təxminən 8 min SNMP polinqindədir. Asinxron rejimə keçmək polinqin işini 200 dəfə sürətləndirdi, bir neçə yüz dəfə.
MÇ: – Alınan polling optimizasyonları gösterdi ki, yalnızca tüm proxylerden kurtulmakla kalmayıp, birçok kontrol için interval sürelerini de kısaltabiliriz; proxyler yük dengesin sağlamak için gereksiz hale geliyor.
Yaklaşık üç ay önce
Mimariyi değiştir – yükü artır!
MM: – Şimdi Max, üretime geçme zamanı mı? Bana güçlü bir sunucu ve iyi bir mühendis lazım.
MÇ: – Tamam, planlayalım. 5.000 metrik/saniye noktasından çıkmanın zamanı geldi.
Yükseltme sonrası sabah
MÇ: – Misha, güncellendik ama sabaha geri döndük... Tahmin et, hangi hıza ulaştık?
MM: – En fazla 20 bin.
MÇ: – Aha, 25! Ne yazık ki, başladığımız noktadayız.
MM: – Neden böyle oldu? Herhangi bir tanılama yaptınız mı?
MÇ: – Evet, tabii ki! İşte ilginç bir top örneği:
MM: – Hadi bakalım. Görüyorum ki, çok sayıda polling akışı denemişiz:
Ama buna rağmen sistemi bile yarı yarıya kullanılmaya başladık:
Ve genel verimlilik oldukça düşük, yaklaşık 4.000 metrik/saniye:
Başka bir şey var mı?
MÇ: – Evet, bir polletten bir strace:
MM: – Burada oldukça net bir şekilde görülüyor ki, polling süreci "semaforları" bekliyor. Bunlar bloke olmaktır:
MÇ: – Anlaşılır değil.
MM: – Bak, bu, birçok akışın aynı anda yalnızca bir kişinin işlem yapabileceği bir kaynak üzerinde çalışmaya çalıştığı duruma benziyor. O zaman yapabilecekleri tek şey, bu kaynağı zamana göre bölmektir:
Ve böyle bir kaynakla çalışmanın toplam performansı bir çekirdek hızına bağlıdır:
Bu tür bir sorunu iki şekilde çözmek mümkündür.
Makinenin donanımını yükseltip, daha hızlı çekirdeklere geçmek:
Ya da mimariyi değiştirip, aynı anda yükü artırmak:
MÇ: – Bu arada, test makinesinde, üretim makinesine göre daha az çekirdek kullanacağız, ama bu çekirdekler çekirdek başına 1.5 kat daha hızlı olacak!
MM: – Anlaşıldı mı? Sunucu kodunu kontrol etmemiz lazım.
Zabbix sunucusundaki veri akışı
MÇ: – Anlamak için, 'Zabbix' sunucusunun içinde verilerin nasıl iletildiğini analiz etmeye başladık:
Güzel bir resim, değil mi? Hadi adım adım geçelim, böylece biraz daha netleşsin. Veri toplama ile sorumlu akışlar ve servisler var:
Toplanan metrikleri, Preprocessor yöneticisine soket üzerinden iletip, orada sıraya kaydediyorlar:
Preprocessor yöneticisi, verileri ön işleme talimatlarını uygulayan işçilere iletir ve bunları aynı soket üzerinden geri alır:
Bundan sonra, ön işlem yöneticisi onları geçmişin ön belleğine kaydeder:
Oradan, birçok fonksiyonu yerine getiren tarih senkronizasyonları alır: örneğin, tetikleyicileri hesaplayarak, değerlerin ön belleğini doldurarak ve en önemlisi, metrikleri geçmiş depolamaya kaydederek. Genel olarak, süreç karmaşık ve oldukça kafa karıştırıcı.
MM: – İlk olaraq gördüyümüz şey, əksər axınların "konfiqurasiya keşi" üçün mübarizə aparmasıdır (server konfiqurasiyalarının saxlandığı yaddaş sahəsi). Xüsusilə məlumatların alınmasında məsul axınlar tərəfindən çoxlu bloklamalar edilir:
…çünki konfiqurasiyada yalnız metrikalar və onların parametrləri yox, eyni zamanda pollerlərin gələcəkdə nə etməsi haqqında məlumat aldığı növbələr də saxlanılır. Pollerlərin sayı çox olanda, biri konfiqurasiyanı bloklayanda, digərləri sorğuların gözləməsi lazım olur:
Pollerlər mübahisə etməməlidir
Buna görə də etdiyimiz ilk iş, növbəni 4 hissəyə ayırmaq və pollerlərə bu növbələri təhlükəsiz şəraitdə eyni zamanda bloklamağa icazə vermək oldu:
Bu, konfiqurasiya keşi üçün mübarizəni aradan qaldırdı və pollerlərin iş sürəti əhəmiyyətli dərəcədə artdı. Amma sonra üzləşdiyimiz problem, preprocesser menecerinin tapşırıqların növbəsini yığmağa başlaması oldu:
Preprocessor meneceri prioritetləri düzgün müəyyənləşdirməlidir
Bu, onun performansının çatışmadığı hallar baş verdikdə olurdu. Onda onun edə biləcəyi yeganə şey, məlumat toplama proseslərindən gələn sorğuları yığmaq və bu sorğuları yığınca qədər yığmaq olurdu, bu da onun bütün yaddaşı tutmasına və çöküşə səbəb olurdu:
Bu problemi həll etmək üçün, işçilər üçün xüsusi ayrılmış ikinci socket əlavə etdik:
Bununla, preprocesser meneceri işini prioritetləşdirmək imkanı qazandı və buffer genişlənərkən, tapşırığı pozaraq işçilərə bu bufferi götürmək imkanı verdi:
Sonra müəyyən etdik ki, ləngimənin səbəblərindən biri, işçilərin özlərinin işləmələri üçün tamamilə əhəmiyyətli olmayan resurs üçün mübarizə aparmasıdır. Bu problemi bug-fix olaraq həll etdik və "Zabbix"-in yeni versiyalarında artıq bu məsələlər düzəldilib:
Socketlərin sayını artırırıq – nəticə alırıq
Sonra preprocesser meneceri dar bir yerdə oldu, çünki bu – tək bir axındır. O, maksimum sürətini təxminən saniyədə 70 min metrik ilə məhdudlaşdırırdı:
Buna görə də 4 işçi və 4 socket dəstləri yaratdıq:
Bu, sürəti təxminən 130 min metrikə artırmağı mümkün etdi:
Artımın qeyri-xətti olması, tarix keşi üçün mübarizə yaranmasından qaynaqlanır. Bu, 4 preprocesser menecerinin və tarix sinklərin mübarizə apardığı bir məsələ idi. Bu anda test maşınımızda təxminən saniyədə 130 min metrik alırdıq, prosessoru təxminən 95% istifadə edirdik:
Təxminən 2.5 ay əvvəl
snmp-communitidən imtina NVP-ləri 1.5 dəfə artırdı
MM: – Max, mənə yeni test maşını lazımdır! Hal-hazırda içəri sığmırıq.
MÇ: – İndiki nədir?
MM: – Hazırda – 130k NVP-lər və prosessor "rafda".
MÇ: – Vay! Möhtəşəmdir! Gözlə, mənim iki sualım var. Hesablamalarıma görə, bizim ehtiyacımız təxminən 15-20 min metrik saniyədədir. Nəyə görə daha çox etməliyik?
MM: – İşləri sona çatdırmaq istəyirəm. Bu sistemdən nə qədər fayda götürə biləcəyimizi görmək istəyirəm.
MÇ: – Amma…
MM: – Amma iş üçün yararsızdır.
MÇ: – Aydındır. İkinci sual: hazırda olanı özümüz, inkişaf etdiricinin köməyi olmadan dəstəkləyə bilərikmi?
MM: – Düşünmürəm. Konfiqurasiya önbelleyi ilə işin dəyişdirilməsi bir problemdir. Bu, əksər axınlara təsir edir və dəstəklənməsi olduqca çətindir. Yəqin ki, onu dəstəkləmək çox çətin olacaq.
MÇ: – Onda alternativ bir şey lazımdır.
MM: – Belə bir variant var. Biz yeni bloklama sistemindən imtina edərək sürətli nüvələrə keçə bilərik. Hələ də 60-80 min metrik performans əldə edəcəyik. Bununla birlikdə, qalan kodu saxlaya bilərik. "ClickHouse", asinxron polling işləyəcək. Və bu, asanlıqla dəstəklənəcək.
MÇ: – Mükəmməl! Bunu dayandırmağı təklif edirəm.
Server tərəfinin optimallaşdırılmasından sonra, nəhayət yeni kodu istehsalata buraxa bildik. Kodda dəyişikliklərin sayını minimuma endirmək və sürətli nüvəli maşına keçid üstündə bəzi dəyişikliklərdən imtina etdik. Konfiqurasiyanı da sadələşdirdik və mümkün olduqca verilənlər elementlərində makrolardan imtina etdik, çünki onlar əlavə bloklamaların mənbəyidirlər.
Məsələn, sənədlərdə və nümunələrdə tez-tez rast gəlinən snmp-community makrosundan imtina etməyimiz NVP-ləri təxminən 1,5 dəfə sürətləndirməyə imkan tanıdı.
İstehsalda iki gündən sonra
Hadisə tarixi üçün pop-up pəncərələri silirik.
MÇ: – Mişa, biz iki gündür sistemdən istifadə edirik, və hər şey yaxşı işləyir. Amma yalnız hər şey işləyən zaman! Biz lazımi işlər yürütmüşdük və kifayət qədər böyük bir şəbəkə seqmentini köçürmüşdük, və yenidən əllə yoxlayırdıq, nə yüksəldi, nə – yox.
MM: – İnanılmaz! Biz hər şeyi 10 dəfə yoxlamışdıq. Server, şəbəkənin tam əlçatan olmamasını dərhal işləyə bilir.
MÇ: – Düşünürəm, hər şeyi başa düşürəm: server, bazası, top, austat, loqlar – hər şey sürətlidir… Amma biz web-interfeysi izləyirik, orada isə serverdə "əyləncə" prosessoru var və bu:
MM: – Aydındır. Gəlin web’u yoxlayaq. Biz aşkar etdik ki, aktiv hadisələrin sayı çox olduğunda, əksər operativ vidjetlər çox yavaş işləməyə başlayır:
Bunun səbəbi, siyahıdakı hər bir element üçün yaradılan hadisə tarixi ilə bağlı pop-up pəncərələrinin yaradılması idi. Buna görə biz bu pəncərələrin yaradılmasından imtina etdik (kodda 5 sətiri şərh etdik) və bu, problemlərimizi həll etdi.
Vidjetlərin yüklənmə vaxtı tam əlçatanlıq şəraitində bir neçə dəqiqədən bizim üçün qəbul edilən 10-15 saniyəyə endi, tarixi hələ də vaxtı klikləməklə görə bilərsiniz:
İşdən sonra. 2 ay əvvəl
MÇ: – Mişa, çıxırsan? Danışmağa ehtiyac var.
MM: – Çıxmağı planlamamışdım. Yenidən "Zabbix"-lə bağlı bir şeymi var?
MÇ: – Yox, rahat ol! Mən sadəcə demək istəyirdim: hər şey işləyir, təşəkkür edirəm! İçki məndən.
Zabbix effektlidir
«Zabbix» kifayət qədər universal və zəngin sistemdir. Onu kiçik quraşdırmalar üçün "qutudan" istifadə etmək mümkündür, amma tələblərin artması ilə onu optimallaşdırmaq lazım gəlir. Böyük metrik arxivlər saxlamaq üçün uyğun bir saxlama yerindən istifadə edin:
- «Elasticsearch» ilə inteqrasiya edən daxil edilmiş vasitələrdən və ya tarixçəni mətn fayllarına ixrac etməkdən (dördüncü versiyadan başlayaraq) faydalana bilərsiniz;
- bizim təcrübəmizdən və «ClickHouse» ilə inteqrasiyadan istifadə edə bilərsiniz.
Metriklərin yığılma sürətini əhəmiyyətli dərəcədə artırmaq üçün onları asinxron metodlarla yığın və «Zabbix» serverinə trapez interfeysi ilə ötürün; ya da «Zabbix»-in öz pollerinin asinxronluğu üçün patchdən istifadə edə bilərsiniz.
«Zabbix» C dilində yazılıb və kifayət qədər effektivdir. Bir neçə dar memarlıq yeri onun istehsalını daha da artırmağa imkan tanıyır və bizim təcrübəmizə görə, bir prosessorlu maşında 100 min metrikdən çox əldə etmək mümkündür.
O həmin Zabbix patchidir
MM: – Mən bir neçə məqam əlavə etmək istəyirəm. Bütün cari hesabat, bütün testlər, təqdim olunan rəqəmlər bizim istifadə etdiyimiz konfiqurasiyaya əsaslanır. Bu konfiqurasiyadan hər saniyə təxminən 20 min metrik yığırıq. Əgər siz bunu özünüzdə olacaq mıdı olduğunu başa düşməyə çalışırsınızsa – müqayisə edə bilərsiniz. Bugün danışdığımız şeylər GitHub-da patch şəklində mövcuddur:
Patch aşağıdakılardan ibarətdir:
- «ClickHouse» ilə tam inteqrasiya (həm «Zabbix» serveri, həm də frontend üçün);
- preprocessor meneceri ilə bağlı problemlərin həlli;
- asinxron polling.
Patch 4-cü versiya ilə uyğun gəlir, o cümlədən lts ilə. Ən azı minimal dəyişikliklərlə 3.4 versiyasında işləməsi ehtimal olunur.
Diqqətinizə görə təşəkkür edirəm.
Suallar
İştirakçılardan sual (növbəti – A): – Salam! Zabbix komandası ilə intensiv əməkdaşlıq planlarınız varmı, ya da onların sizinlə, bunun bir patch olmamasını, normal «Zabbix» davranışını təmin etməyiniz?
MM: – Bəli, bəzi dəyişiklikləri mütləq commiti edəcəyik. Nəsə isə, nəsə patchdə qalacaq.
A: – Möhtəşəm çıxışınız üçün təşəkkür edirəm! Zabbix patchini tətbiq etdikdən sonra Zabbix tərəfindən dəstək qalacaq mı? Yüksək versiyalara necə yenilənmək olacaq? Patchdən sonra Zabbix-in 4.2, 5.0 versiyalarına yüksəldilməsi mümkündürmü?
MM: – Dəstək haqqında bir şey deyə bilmirəm. Başqa bir tərəfdaş olmaq istəsəydim, yəqin ki, yox deyərdim, çünki bu, başqalarının kodudur. 4.2 versiyası üçün bizim mövqeyimiz belədir: "Biz zamanla irəliləyəcəyik və növbəti versiyaya keçəcəyik". Bu səbəbdən bir müddətimiz var ki, yenilənmiş versiyalara patç təqdim edəcəyik. Mən daha əvvəl tədbirdə dedim: versiyalar arasında dəyişikliklərin sayı hələ də kifayət qədər azdır. Düşünürəm ki, 3.4-dən 4-ə keçidimiz təxminən 15 dəqiqə çəkdi. Orada bir şeylər dəyişdi, amma çox vacib bir şey deyil.
A: – Yəni, siz patçınızı dəstəkləməyi planlaşdırırsınız və onu istehsal mühitinə təhlükəsiz qoya bilərsiniz; sonradan bir şəkildə yenilənmələr alacaqsınız?
MM: – Biz bunu şiddətlə tövsiyə edirik. Bu, bir çox problemlərimizi həll edir.
MÇ: – Bir daha vurğulamaq istəyirəm ki, arxitekturaya və bloklamalara, növbələrə aid olmayan dəyişikliklər moduldur, ayrı modullara bölünmüşdür. Hətta kiçik dəyişikliklər belə asanlıqla təmin edilə bilər.
MM: – Əgər detallar sizə maraqlıdırsa, "ClickHouse" adlanan bir tarix kitabxanasını istifadə edir. Bu, ayrılmışdır - "Elastics"-in dəstəyi üçün bir nüsxədir, yəni konfiqurasiya edilə bilən. Polling yalnız pollerləri dəyişdirir. Biz bu sistemin uzun müddət işləyəcəyini düşünürük.
A: – Çox sağ olun. Bəs daxil edilmiş dəyişikliklərə dair bir sənəd varmı?
MM: – Sənəd – bu, patçdır. Aydındır ki, "ClickHouse"-un tətbiqi ilə yeni polling tiplərinin tətbiqi ilə yeni konfiqurasiya variantları meydana çıxır. Son slayddakı linkdə bunun necə istifadə olunacağına dair qısa bir təsvir var.
fping-i nmap ilə əvəz etmə haqqında
A: – Siz bunu necə həyata keçirdiniz? Konkret nümunələrdə: bunlar strappers və xarici skriptlərdir? Nəticədə bu qədər çox hostu nə tez yoxlayır? Siz bu hostları necə əldə edirsiniz? Nmap-a onları necə yedizdirmək lazımdır, haradan əldə edilməlidir, harasa yerləşdirilməlidir, bir şey işə salınmalıdır?..
MM: – Mükəmməl. Çox doğru sual! Məsələ belədir. Biz "Zabbix"-in bir hissəsi olan kitabxananı ICMP ping üçün modifikasiya etdik, burada paketlərin sayı – bir (1) olaraq təyin edilir və kod nmap-dan istifadə etməyə çalışır. Yəni, bu "Zabbix"-in daxili işidir, bu, pingerin daxili işinə çevrildi. Buna görə heç bir sinkronizasiya və ya trap görə ıılarından istifadə edilməsinə ehtiyac yoxdur. Bu mütləq qərarlı bir şəkildə edildi ki, sistemi tam tutaq və iki sistem bazası arasında sinkronizasiya ilə məşğul olmayaq: nəyi yoxlayacağıq, pollerdən necə yükləyəcəyik, bizim yüklememiz məhv olmadı?.. Bu, çox asandır.
A: – Proxy üçün də işləyir?
MM: – Bəli, amma biz bunu yoxlamadıq. Polling kodu həm "Zabbix"-də, həm də serverdə birdir. İşləməlidir. Bir daha vurğulayıram: sistemin performansı belədir ki, bizə proxy lazım deyil.
MÇ: – Suallarınıza düzgün cavab belədir: "Bu qədər proksi sistemi ilə sizə nə lazımdır? Yalnız NAT səbəbindən, yoxsa ləng bir kanaldan monitorinq etmək üçün...?"
A: – Siz, anladım ki, "Zabbix"-i xəbərdarlıq sistemi kimi istifadə edirsiniz. Yoxsa qrafiklər (arxiv təbəqəsi) digər bir sistemə, məsələn, Grafana-ya keçib? Yoxsa bu funksionallığı istifadə etmirsiniz?
MM: – Yenidən vurğulayıram: Biz tam bir inteqrasiya etdik. Tarixçəni "Clickhouse"-a göndəririk, amma php-frontendi dəyişdirdik. Php-frontendi "Clickhouse"-a gedir və bütün qrafikləri oradan hazırlayır. Bu arada, dürüst olmalıyıq, qeydə alınmış "Clickhouse"-dan, eyni "Zabbix"-dan məlumatları digər qrafik göstərmə sistemlərində yaratmaq üçün bir hissəmiz var.
MÇ: – O cümlədən "Grafana".
Resursların ayrılması necə qərara alındı?
A: – Biraz daxili mətbəxlə paylaşın. Məhsulu ciddi şəkildə yenidən işləməyə resurs ayırmaq qərarı necə alındı? Bu, əslində müəyyən risklərdir. Və xahiş edirəm, yeni versiyaları dəstəkləməyi planladığınız kontekstində bu qərarın idarəetmə istiqamətindən necə əsaslandırıldığını deyin.
MM: – Görünür, tariximizin dramını yaxşı izah edə bilmədik. Biz, nəsə etməli olduğumuz bir vəziyyətə düşdük, və iki paralel komanda ilə irəlilədik:
- Birisi yeni metodlarla monitorinq sisteminin işə salınması ilə məşğul oldu: xidmət kimi monitorinq, kombinasiya etdiyimiz standart açıq mənbəli həllərin toplusu və sonra yeni monitorinq sistemi ilə işləmək üçün biznes prosesini dəyişməyə çalışdıq.
- Eyni zamanda, bu işlə məşğul olan bir proqramçı həvəsli biri vardı (özü haqqında). Belə oldu ki, o, mübarizədə qalib gəldi.
A: – Komandanın ölçüsü nə qədərdir?
MÇ: – O, qarşınızdadır.
A: – Yəni həmişə bir pasioner lazımdır?
MM: – Pasioner nədir, bilmirəm.
A: – Bu halda, görünür, sizsiniz. Çox sağ olun, siz – fantastiksiniz.
MM: – Təşəkkür edirəm.
Zabbix üçün patchlar haqqında
A: – Proksi istifadə edən bir sistem üçün (məsələn, bəzi paylanmış sistemlərdə), sizin həllinizin, məsələn, popper-ləri, proksi və Zabbix-in öz preprosessorunun patch edilmiş olmasını, onların qarşılıqlı təsirini uyğunlaşdırmaq mümkünüdürmü? Var olan inkişafları bir neçə proksi ilə sistemə optimallaşdırmaq mümkündürmü?
MM: – Bilirəm ki, "Zabbix"-server proksi vasitəsilə toplanır (kompilə edilir və kod yaranır). Biz bunu istehsalda yoxlamamışıq. Bununla bağlı əmin deyiləm, amma, yəqin ki, preprocessor meneceri proksi istifadə edilmir. Proksinin işi – "Zabbix"-dan metriklər toplayıb, onları qeyd etmək (həmçinin konfiqurasiyanı, lokal bazanı qeyd edir) və geri "Zabbix"-serverə verməkdir. Preprosesi isə sonra server özü həyata keçirəcəkdir.
Proksi ilə maraq anlaşılandır. Biz bunu yoxlayacağıq. Maraqlı bir mövzudur.
A: – İdeya belə idi: əgər pollerləri patch edə bilsək, onları proxy-yə patch edə bilərik və serverlə əlaqəni bu məqsədlər üçün yalnız serverdə uyğunlaşdırmalıyıq.
MM: – Düşünürəm ki, hər şey daha asandır. Siz kodu götürürsünüz, patch-layırsınız, sonra onu istədiyiniz kimi konfiqurasiya edirsiniz – proxy-serverlər (məsələn, ODBC ilə) yaradırsınız və patch-lənmiş kodu sistemlər arasında paylayırsınız. Harada lazım olsa – proxy-yə, harada lazım olsa – serverə yığa bilərsiniz.
A: – Əlavə olaraq, proxy-nin serverə ötürülməsini patch etməyə ehtiyac olmayacaq, düzdür?
MÇ: – Yox, bu standartdır.
MM: – Əslində bir ideya heç səslənmədi. Biz həmişə ideyaların partlaması ilə dəyişikliklərin sayını, dəstəklənmənin asanlığını tarazlaşdırmağı qoruyuruq.
Bir az reklam 🙂
Bizimlə qaldığınız üçün təşəkkür edirik. Bizim məqalələrimizi bəyənirsiniz? Daha maraqlı materiallar görmək istəyirsiniz? Bizi dəstəkləyin, sifariş verərək və ya tanışlarınıza tövsiyə edərək. , Sizin üçün icad etdiyimiz bənzərsiz entry-level serverlərin analoqu: (RAID1 və RAID10 ilə variantlar, 24 nüvəyə qədər və 40GB DDR4-a qədər mövcuddur).
Dell R730xd, Amsterdamdakı Equinix Tier IV data mərkəzində iki dəfə ucuz? Yalnız bizdə Niderlandda! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — 99 $-dan! Bunun haqqında oxuyun
Mənbə: habr.com
