Növbəti HighLoad++ konfransı 6 və 7 aprel 2020-ci il tarixlərində Sankt-Peterburqda keçiriləcək Təfərrüatlar və biletlər . HighLoad++ Moskva 2018. “Moskva” zalı. 9 noyabr, saat 15:00. Tezislər və .
* Monitorinq - onlayn və analitik.
* ZABBIX platformasının əsas məhdudiyyətləri.
* Analitik yaddaşın ölçüsünü artırmaq üçün həll.
* ZABBIX serverinin optimallaşdırılması.
* UI optimallaşdırılması.
* 40k NVPS-dən çox yük altında sistemi idarə etmək təcrübəsi.
* Qısa nəticələr.
Mixail Makurov (bundan sonra – MM): - Hamıya salam!
Maksim Çernetsov (bundan sonra – MCH): - Günortanız Xeyir!
MM: – İcazə verin, Maksimi təqdim edim. Maks istedadlı mühəndisdir, tanıdığım ən yaxşı şəbəkəçidir. Maksim şəbəkələr və xidmətlər, onların inkişafı və istismarı ilə məşğuldur.
MCH: - Mən sizə Mixail haqqında danışmaq istərdim. Mixail C inkişaf etdiricisidir. O, şirkətimiz üçün bir neçə yüksək yüklü trafik emal həlləri yazdı. Biz Uralsda, Çelyabinskdə sərt kişilər şəhərində, İntersvyaz şirkətində yaşayırıq və işləyirik. Şirkətimiz 16 şəhərdə bir milyon insan üçün İnternet və kabel televiziyası xidmətlərinin provayderidir.
MM: – Və deməyə dəyər ki, İntersvyaz sadəcə bir provayder deyil, bir İT şirkətidir. Həlllərimizin əksəriyyəti İT departamentimiz tərəfindən hazırlanır.
A: trafiki emal edən serverlərdən zəng mərkəzinə və mobil proqrama qədər. İndi İT departamentində çox, çox müxtəlif səlahiyyətlərə malik 80-ə yaxın insan var.
Zabbix və onun memarlığı haqqında
MCH: - İndi mən şəxsi rekord vurmağa çalışacağam və bir dəqiqədən sonra Zabbix-in (bundan sonra “Zabbix” adlandırılacaq) nə olduğunu deyəcəyəm.
Zabbix özünü müəssisə səviyyəsində hazır olmayan monitorinq sistemi kimi təqdim edir. Onun həyatı asanlaşdıran bir çox xüsusiyyətləri var: təkmil eskalasiya qaydaları, inteqrasiya üçün API, hostların və ölçülərin qruplaşdırılması və avtomatik aşkarlanması. Zabbix-də sözdə miqyaslı alətlər var - proksilər. Zabbix açıq mənbə sistemidir.
Memarlıq haqqında qısaca. Üç komponentdən ibarət olduğunu söyləyə bilərik:
- Server. C dilində yazılmışdır. İplər arasında məlumatın kifayət qədər mürəkkəb işlənməsi və ötürülməsi ilə. Bütün emal orada baş verir: qəbuldan tutmuş verilənlər bazasına qədər.
- Bütün məlumatlar verilənlər bazasında saxlanılır. Zabbix MySQL, PostreSQL və Oracle-ı dəstəkləyir.
- Veb interfeysi PHP-də yazılmışdır. Əksər sistemlərdə o, Apache serveri ilə gəlir, lakin nginx + php ilə birlikdə daha səmərəli işləyir.
Bu gün şirkətimizin həyatından Zabbix ilə bağlı bir hekayə danışmaq istərdik...
Intersvyaz şirkətinin həyatından bir hekayə. Bizdə nə var və nəyə ehtiyacımız var?
5-6 ay əvvəl. Bir gün işdən sonra...
MCH: - Misha, salam! Səni tutmağı bacardığım üçün şadam - söhbət var. Yenə monitorinqlə bağlı problemlərlə üzləşdik. Böyük qəza zamanı hər şey ləng gedirdi və şəbəkənin vəziyyəti haqqında heç bir məlumat yox idi. Təəssüf ki, bu, ilk dəfə deyil. Köməyinə ehtiyacım var. İstənilən şəraitdə monitorinqimizi işlək edək!
MM: - Amma gəlin əvvəlcə sinxronlaşdıraq. Bir neçə ildir ki, ora baxmıram. Xatırladığım qədər, təxminən 8 il əvvəl Nagiosu tərk edib Zabbixə keçdik. İndi bizim 6 güclü serverimiz və təxminən onlarla proksi var. Mən nəyisə qarışdırıram?
MCH: - Təxminən. 15 server, bəziləri virtual maşınlardır. Ən əsası odur ki, ən çox ehtiyac duyduğumuz anda bizi xilas etmir. Qəza kimi - serverlər yavaşlayır və heç nə görə bilmirsiniz. Konfiqurasiyanı optimallaşdırmağa çalışdıq, lakin bu, optimal performans artımını təmin etmədi.
MM: - Aydındır. Nəyəsə baxdınız, artıq diaqnostikadan nəsə qazdınız?
MCH: – Qarşılaşmalı olduğunuz ilk şey verilənlər bazasıdır. MySQL daim yüklənir, yeni ölçüləri saxlayır və Zabbix bir sıra hadisələr yaratmağa başlayanda verilənlər bazası sözün əsl mənasında bir neçə saat ərzində həddindən artıq yüklənir. Mən sizə konfiqurasiyanın optimallaşdırılması haqqında artıq demişdim, amma sözün əsl mənasında, bu il onlar aparatı yenilədilər: serverlərdə SSD RAID-lərdə yüz giqabaytdan çox yaddaş və disk massivləri var - uzunmüddətli perspektivdə onu xətti şəkildə böyütməyin mənası yoxdur. Biz nə edirik?
MM: - Aydındır. Ümumiyyətlə, MySQL LTP verilənlər bazasıdır. Göründüyü kimi, bizim ölçülərimizin arxivini saxlamaq üçün artıq uyğun deyil. Gəlin bunu anlayaq.
MCH: - Gəlin!
Hackathon nəticəsində Zabbix və Clickhouse-un inteqrasiyası
Bir müddət sonra maraqlı məlumatlar əldə etdik:
Verilənlər bazamızda yerin çox hissəsini ölçü arxivi tuturdu və 1%-dən az hissəsi konfiqurasiya, şablonlar və parametrlər üçün istifadə edilmişdir. O vaxta qədər biz bir ildən artıqdır ki, Clickhouse əsasında Big data həllini işlədirdik. Hərəkət istiqaməti bizə aydın idi. Yaz Hackathonumuzda mən Zabbix-in server və frontend üçün Clickhouse ilə inteqrasiyasını yazdım. O zaman Zabbix artıq ElasticSearch dəstəyinə malik idi və biz onları müqayisə etmək qərarına gəldik.
Clickhouse və Elasticsearch-in müqayisəsi
MM: – Müqayisə üçün, biz Zabbix serverinin təmin etdiyi yükü yaratdıq və sistemlərin necə davranacağına baxdıq. Biz CURL-dən istifadə edərək məlumatları 1000 sətirdən ibarət qruplarda yazdıq. Əvvəlcədən güman edirdik ki, Clickhouse Zabbix-in etdiyi yük profili üçün daha səmərəli olacaq. Nəticələr hətta gözləntilərimizi üstələdi:
Eyni sınaq şərtləri altında, Clickhouse üç dəfə daha çox məlumat yazdı. Eyni zamanda, hər iki sistem məlumatları oxuyarkən çox səmərəli (az miqdarda resurs) istehlak etdi. Ancaq qeyd edərkən Elastics çox miqdarda prosessor tələb etdi:
Ümumilikdə, Clickhouse prosessor istehlakı və sürəti baxımından Elastix-dən xeyli üstün idi. Eyni zamanda, məlumatların sıxılması səbəbindən, Clickhouse sabit diskdə 11 dəfə az istifadə edir və təxminən 30 dəfə daha az disk əməliyyatları həyata keçirir:
MCH: – Bəli, Clickhouse-un disk alt sistemi ilə işi çox səmərəli şəkildə həyata keçirilir. Siz verilənlər bazası üçün nəhəng SATA disklərindən istifadə edə və saniyədə yüz minlərlə sətir yazma sürəti əldə edə bilərsiniz. Qutudan çıxarılan sistem parçalanmağı, təkrarlamağı dəstəkləyir və konfiqurasiya etmək çox asandır. Onun il boyu istifadəsi bizi çox qane edir.
Resursları optimallaşdırmaq üçün mövcud əsas verilənlər bazanızın yanında Clickhouse quraşdıra və bununla da çoxlu CPU vaxtına və disk əməliyyatlarına qənaət edə bilərsiniz. Metriklərin arxivini mövcud Clickhouse klasterlərinə köçürdük:
Əsas MySQL verilənlər bazasını o qədər azad etdik ki, onu Zabbix serveri ilə bir maşında birləşdirə və MySQL üçün ayrılmış serverdən imtina edə bildik.
Zabbix-də səsvermə necə işləyir?
4 il əvvəl
MM: – Yaxşı, baza ilə bağlı problemləri unuda bilərikmi?
MCH: - Bu mütləqdir! Həll etməli olduğumuz digər problem məlumatların yavaş toplanmasıdır. İndi bütün 15 proksi serverimiz SNMP və səsvermə prosesləri ilə həddən artıq yüklənib. Və yeni və yeni serverlər quraşdırmaqdan başqa bir yol yoxdur.
MM: - Əla. Ancaq əvvəlcə bizə deyin ki, Zabbix-də səsvermə necə işləyir?
MCH: – Bir sözlə, 20 növ metrik və onları əldə etməyin onlarla yolu var. Zabbix ya "sorğu-cavab" rejimində məlumat toplaya, ya da "Trapper interfeysi" vasitəsilə yeni məlumatları gözləyə bilər.
Qeyd etmək lazımdır ki, orijinal Zabbix-də bu üsul (Trapper) ən sürətlidir.
Yük paylanması üçün proxy serverlər var:
Proksilər Zabbix serveri ilə eyni toplama funksiyalarını yerinə yetirə bilər, ondan tapşırıqlar alır və toplanmış göstəriciləri Trapper interfeysi vasitəsilə göndərir. Bu, yükü paylamaq üçün rəsmi olaraq tövsiyə olunan yoldur. Proksilər NAT və ya yavaş kanal vasitəsilə işləyən uzaq infrastrukturun monitorinqi üçün də faydalıdır:
MM: – Memarlıqda hər şey aydındır. Mənbələrə baxmaq lazımdır...
Bir neçə gün sonra
Nmap fping-in necə qalib gəldiyinin hekayəsi
MM: "Düşünürəm ki, bir şey qazdım."
MCH: - Mənə de!
MM: – Mən aşkar etdim ki, mövcudluğu yoxlayarkən Zabbix bir anda maksimum 128 hostu yoxlayır. Mən bu rəqəmi 500-ə qədər artırmağa və onların pingində (ping) paketlərarası intervalı silməyə çalışdım - bu, performansı ikiqat artırdı. Amma daha böyük rəqəmlər istərdim.
MCH: – Təcrübəmdə bəzən minlərlə hostun mövcudluğunu yoxlamalı oluram və bunun üçün nmap-dan daha sürətli bir şey görməmişəm. Əminəm ki, bu, ən sürətli yoldur. Gəlin cəhd edək! Hər iterasiya üçün hostların sayını əhəmiyyətli dərəcədə artırmalıyıq.
MM: – Beş yüzdən çox yoxlayın? 600?
MCH: - Ən azı bir neçə min.
MM: - TAMAM. Demək istədiyim ən vacib şey odur ki, Zabbix-də səsvermənin çoxunun sinxron şəkildə aparıldığını gördüm. Biz mütləq onu asinxron rejimə dəyişməliyik. O zaman biz sorğu iştirakçılarının topladığı metriklərin sayını kəskin şəkildə artıra bilərik, xüsusən də hər iterasiya üzrə ölçülərin sayını artırsaq.
MCH: - Əla! Və nə zaman?
MM: - Həmişəki kimi dünən.
MCH: – Biz fping və nmap-ın hər iki versiyasını müqayisə etdik:
Çox sayda hostda nmap-ın beş dəfəyə qədər daha effektiv olacağı gözlənilirdi. Nmap yalnız əlçatanlığı və cavab vaxtını yoxladığından, biz itkilərin hesablanmasını tetikleyicilere köçürdük və mövcudluğu yoxlama intervallarını əhəmiyyətli dərəcədə azaldırıq. Nmap üçün optimal host sayının iterasiya başına təxminən 4 min olduğunu tapdıq. Nmap bizə mövcudluq yoxlamalarının CPU dəyərini üç dəfə azaltmağa və intervalı 120 saniyədən 10-a endirməyə imkan verdi.
Səsvermənin optimallaşdırılması
MM: “Sonra biz sorğu keçirməyə başladıq. Biz əsasən SNMP aşkarlanması və agentləri ilə maraqlandıq. Zabbixdə səsvermə sinxron şəkildə aparılır və sistemin səmərəliliyini artırmaq üçün xüsusi tədbirlər görülüb. Sinxron rejimdə hostun əlçatmazlığı səsvermənin əhəmiyyətli dərəcədə pozulmasına səbəb olur. Bütün dövlətlər sistemi var, xüsusi proseslər var - sözdə əlçatmaz pollerlər, yalnız əlçatmaz hostlarla işləyir:
Bu, vəziyyət matrisini, sistemin effektiv qalması üçün tələb olunan keçid sisteminin bütün mürəkkəbliyini nümayiş etdirən şərhdir. Bundan əlavə, sinxron sorğunun özü olduqca yavaşdır:
Buna görə onlarla proksi üzərində minlərlə sorğu axını bizim üçün lazımi miqdarda məlumat toplaya bilmədi. Asinxron tətbiq yalnız mövzuların sayı ilə bağlı problemləri həll etdi, həm də əlçatmaz hostların dövlət sistemini əhəmiyyətli dərəcədə sadələşdirdi, çünki bir səsvermə iterasiyasında yoxlanılan istənilən nömrə üçün maksimum gözləmə müddəti 1 fasilə idi:
Bundan əlavə, biz SNMP sorğuları üçün sorğu sistemini dəyişdirdik və təkmilləşdirdik. Fakt budur ki, insanların çoxu eyni anda birdən çox SNMP sorğusuna cavab verə bilmir. Buna görə də, eyni hostun SNMP sorğusu asinxron şəkildə aparıldıqda hibrid rejimi yaratdıq:
Bu, bütün host paketi üçün edilir. Bu rejim tamamilə asinxron rejimdən daha yavaş deyil, çünki yüz yarım SNMP dəyərinin sorğulanması hələ də 1 fasilədən daha sürətlidir.
Təcrübələrimiz göstərdi ki, SNMP sorğusu ilə bir iterasiyada optimal sorğu sayı təxminən 8 mindir. Ümumilikdə, asinxron rejimə keçid bizə səsvermə performansını 200 dəfə, bir neçə yüz dəfə sürətləndirməyə imkan verdi.
MCH: – Nəticə etibarilə səsvermənin optimallaşdırılması göstərdi ki, biz nəinki bütün etibarnamələrdən xilas ola bilərik, həm də bir çox yoxlamalar üçün intervalları azalda bilərik və artıq yükü bölüşmək üçün proksilərə ehtiyac olmayacaq.
Təxminən üç ay əvvəl
Memarlığı dəyişdirin - yükü artırın!
MM: - Yaxşı, Maks, məhsuldar olmağın vaxtıdır? Mənə güclü server və yaxşı mühəndis lazımdır.
MCH: -Yaxşı, gəlin bunu planlaşdıraq. Saniyədə 5 min metrik ölü nöqtədən hərəkət etmək vaxtıdır.
Təkmilləşdirmədən sonra səhər
MCH: - Mişa, özümüzü yenilədik, amma səhərə qədər geri döndük... Təxmin et, hansı sürətə çata bildik?
MM: - maksimum 20 min.
MCH: - Bəli, 25! Təəssüf ki, başladığımız yerdəyik.
MM: - Niyə? Hər hansı bir diaqnostika aparmısınız?
MCH: - Bəli əminəm! Budur, məsələn, maraqlı bir üst:
MM: - Gəl baxaq. Görürəm ki, biz çoxlu sayda sorğu mövzusunu sınamışıq:
Ancaq eyni zamanda sistemi yarıya qədər təkrar emal edə bilmədilər:
Və ümumi performans olduqca kiçikdir, saniyədə təxminən 4 min metrik:
Başqa bir şey varmı?
MCH: – Bəli, sorğu iştirakçılarından birinin izi:
MM: – Burada aydın şəkildə görə bilərsiniz ki, səsvermə prosesi “semaforları” gözləyir. Bunlar kilidlərdir:
MCH: - Aydın deyil.
MM: – Baxın, bu, bir dəstə mövzunun eyni anda yalnız birinin işləyə biləcəyi resurslarla işləməyə çalışdığı vəziyyətə bənzəyir. Onda onların edə biləcəyi yeganə şey zamanla bu resursu paylaşmaqdır:
Və belə bir resursla işləməyin ümumi performansı bir nüvənin sürəti ilə məhdudlaşır:
Bu problemi həll etməyin iki yolu var.
Maşının aparatını təkmilləşdirin, daha sürətli nüvələrə keçin:
Və ya arxitekturanı dəyişdirin və eyni zamanda yükü dəyişdirin:
MCH: - Yeri gəlmişkən, sınaq maşınında döyüşdəkindən daha az nüvədən istifadə edəcəyik, lakin hər nüvəyə görə 1,5 dəfə daha sürətlidir!
MM: - Aydındır? Server koduna baxmaq lazımdır.
Zabbix serverində məlumat yolu
MCH: – Bunu anlamaq üçün məlumatların Zabbix server daxilində necə ötürüldüyünü təhlil etməyə başladıq:
Gözəl şəkil, elə deyilmi? Bunu daha az və ya çox aydınlaşdırmaq üçün addım-addım keçək. Məlumatların toplanmasına cavabdeh olan mövzular və xidmətlər var:
Onlar toplanmış ölçüləri priz vasitəsilə Preprocessor menecerinə ötürür, burada onlar növbədə saxlanılır:
“Önprosessor meneceri” məlumatları öz işçilərinə ötürür, onlar əvvəlcədən emal təlimatlarını yerinə yetirir və eyni yuva vasitəsilə onları geri qaytarır:
Bundan sonra, preprosessor meneceri onları tarix keşində saxlayır:
Oradan onlar kifayət qədər çox funksiyaları yerinə yetirən tarixçilər tərəfindən götürülür: məsələn, tetikleyicilərin hesablanması, dəyər önbelleğinin doldurulması və ən əsası tarix yaddaşında ölçülərin saxlanması. Ümumiyyətlə, proses mürəkkəb və çox qarışıqdır.
MM: – Gördüyümüz ilk şey, əksər mövzuların sözdə “konfiqurasiya keşi” (bütün server konfiqurasiyalarının saxlandığı yaddaş sahəsi) üçün yarışması idi. Məlumatların toplanmasına cavabdeh olan mövzular xüsusilə çox bloklayır:
...çünki konfiqurasiya öz parametrləri ilə yalnız metrikləri deyil, həm də sorğu iştirakçılarının bundan sonra nə etməli olduğuna dair məlumatı götürdüyü növbələri saxlayır. Çox sayda sorğuçu olduqda və biri konfiqurasiyanı bloklayırsa, digərləri sorğuları gözləyir:
Səsverənlər münaqişə etməməlidir
Buna görə də, etdiyimiz ilk iş növbəni 4 hissəyə bölmək və sorğu iştirakçılarına eyni zamanda bu növbələri, bu hissələri təhlükəsiz şəraitdə bloklamağa icazə vermək oldu:
Bu, konfiqurasiya önbelleği üçün rəqabəti aradan qaldırdı və sorğuların sürəti əhəmiyyətli dərəcədə artdı. Ancaq sonra prosessor menecerinin iş növbəsini toplamağa başladığı faktı ilə qarşılaşdıq:
Preprocessor meneceri prioritetləşdirməyi bacarmalıdır
Bu, onun performans göstərmədiyi hallarda baş verdi. Sonra onun edə biləcəyi yeganə şey məlumat toplama proseslərindən gələn sorğuları toplamaq və bütün yaddaşı bitirənə və qəzaya uğrayana qədər onların buferini əlavə etmək idi:
Bu problemi həll etmək üçün xüsusi olaraq işçilər üçün ayrılmış ikinci rozetka əlavə etdik:
Beləliklə, preprosessor meneceri öz işini prioritetləşdirmək imkanı əldə etdi və əgər bufer böyüyərsə, vəzifə işçilərə bu buferi götürmək imkanı verməklə çıxarılmasını yavaşlatmaqdır:
Sonra biz ləngimənin səbəblərindən birinin işçilərin özləri olduğunu gördük, çünki onlar işlərinə görə tamamilə əhəmiyyətsiz bir resurs üçün rəqabət aparırdılar. Biz bu problemi bir səhv həlli kimi sənədləşdirdik və o, Zabbix-in yeni versiyalarında artıq həll olunub:
Soketlərin sayını artırırıq - nəticəni alırıq
Bundan əlavə, preprosessor menecerinin özü darboğaza çevrildi, çünki o, bir mövzudur. O, saniyədə təxminən 70 min metrik maksimum sürət verən əsas sürətə söykənirdi:
Buna görə də, dörd dəst rozetka ilə dörd işçi etdik:
Və bu, sürəti təxminən 130 min metrə çatdırmağa imkan verdi:
Artımın qeyri-xəttiliyi tarix önbelleği üçün rəqabətin meydana çıxması ilə izah olunur. Bunun üçün 4 preprosessor meneceri və tarixçimiz yarışdı. Bu nöqtədə, biz prosessorun təxminən 130%-i istifadə edərək, sınaq maşınında saniyədə təxminən 95 min metrik alırdıq:
Təxminən 2,5 ay əvvəl
Snmp icmasından imtina NVP-ləri bir yarım dəfə artırdı
MM: – Maks, mənə yeni sınaq maşını lazımdır! Biz artıq indiki ilə uyğunlaşmırıq.
MCH: - İndi nəyin var?
MM: – İndi – 130k NVP və rafa hazır prosessor.
MCH: - Heyrət! Vay! Əla! Gözləyin, mənim iki sualım var. Hesablamalarıma görə, bizim ehtiyacımız saniyədə 15-20 min metr civarındadır. Niyə daha çox ehtiyacımız var?
MM: "Mən işi bitirmək istəyirəm." Mən bu sistemdən nə qədər sıxışdıra biləcəyimizi görmək istərdim.
MCH: - Amma…
MM: "Ancaq bu, biznes üçün faydasızdır."
MCH: - Aydındır. Və ikinci sual: indi əlimizdə olanı bir tərtibatçının köməyi olmadan özümüz dəstəkləyə bilərikmi?
MM: - Düşünmürəm. Konfiqurasiya keşinin necə işlədiyini dəyişmək problemdir. Bu, əksər iplərdəki dəyişikliklərə təsir edir və onu saxlamaq olduqca çətindir. Çox güman ki, onu saxlamaq çox çətin olacaq.
MCH: "O zaman bizə bir növ alternativ lazımdır."
MM: - Belə bir variant var. Yeni kilidləmə sistemindən imtina edərək sürətli nüvələrə keçə bilərik. Biz hələ də 60-80 min metrik performans alacağıq. Eyni zamanda, kodun bütün qalan hissəsini tərk edə bilərik. Clickhouse və asinxron sorğu işləyəcək. Və ona qulluq etmək asan olacaq.
MCH: - Möhtəşəm! Mən burada dayanmağı təklif edirəm.
Server tərəfini optimallaşdırdıqdan sonra nəhayət yeni kodu istehsala başlaya bildik. Sürətli nüvələri olan maşına keçmək və kod dəyişikliklərinin sayını minimuma endirmək üçün bəzi dəyişikliklərdən imtina etdik. Biz həmçinin konfiqurasiyanı sadələşdirmişik və mümkün olduqda məlumat elementlərindəki makroları aradan qaldırmışıq, çünki onlar əlavə kilidləmə tətbiq edir.
Məsələn, sənədlərdə və nümunələrdə tez-tez rast gəlinən snmp-icma makrosundan imtina bizim vəziyyətimizdə NVP-ləri təxminən 1,5 dəfə daha da sürətləndirməyə imkan verdi.
İki gün istehsaldan sonra
Hadisə tarixçəsi pop-uplarının silinməsi
MCH: – Mişa, iki gündür sistemdən istifadə edirik və hər şey işləyir. Ancaq hər şey işlədikdə! Şəbəkənin kifayət qədər böyük bir seqmentinin ötürülməsi ilə işləməyi planlaşdırdıq və nəyin yüksəldiyini və nəyin olmadığını yenidən əllərimizlə yoxladıq.
MM: - Ola bilməz! Hər şeyi 10 dəfə yoxladıq. Server hətta tam şəbəkə əlçatmazlığını dərhal idarə edir.
MCH: - Bəli, mən hər şeyi başa düşürəm: server, verilənlər bazası, top, austat, jurnallar - hər şey sürətlidir... Amma biz veb-interfeysə baxırıq və serverdə “rəfdə” prosessor var və bu:
MM: - Aydındır. İnternetə baxaq. Çoxlu sayda aktiv insidentlərin olduğu bir vəziyyətdə əksər canlı vidjetlərin çox yavaş işləməyə başladığını gördük:
Bunun səbəbi siyahıdakı hər bir element üçün yaradılan hadisə tarixçəsi pop-uplarının yaradılması idi. Buna görə də, biz bu pəncərələrin yaradılmasından imtina etdik (kodda 5 sətir şərh etdik) və bu, problemlərimizi həll etdi.
Vidcetlərin yükləmə müddəti, hətta tamamilə əlçatan olmadıqda belə, bir neçə dəqiqədən bizim üçün məqbul olan 10-15 saniyəyə endirilib və tarixə hələ də vaxta klikləməklə baxmaq olar:
İşdən sonra. 2 ay əvvəl
MCH: - Mişa, gedirsən? Danışmalıyıq.
MM: - niyyətim yox idi. Yenə Zabbix ilə bir şey?
MCH: - Yox, rahatla! Sadəcə demək istədim: hər şey işləyir, təşəkkür edirəm! Məndə pivə var.
Zabbix effektivdir
Zabbix kifayət qədər universal və zəngin sistem və funksiyadır. O, qutudan kənar kiçik quraşdırmalar üçün istifadə edilə bilər, lakin ehtiyaclar artdıqca optimallaşdırılmalıdır. Böyük ölçü arxivini saxlamaq üçün uyğun yaddaşdan istifadə edin:
- Elasticsearch ilə inteqrasiya və ya tarixçəni mətn fayllarına yükləmək şəklində daxili alətlərdən istifadə edə bilərsiniz (versiya 4-dən mövcuddur);
- Siz Clickhouse ilə təcrübəmizdən və inteqrasiyamızdan yararlana bilərsiniz.
Metriklərin toplanması sürətini kəskin şəkildə artırmaq üçün onları asinxron metodlardan istifadə edərək toplayın və onları trapper interfeysi vasitəsilə Zabbix serverinə ötürün; və ya Zabbix pollerlərini asinxron etmək üçün yamaqdan istifadə edə bilərsiniz.
Zabbix C dilində yazılmışdır və olduqca səmərəlidir. Bir neçə memarlıq darboğazının həlli onun işini daha da artırmağa və təcrübəmizə görə, tək prosessorlu maşında 100 mindən çox göstərici əldə etməyə imkan verir.
Eyni Zabbix yaması
MM: - Mən bir neçə məqam əlavə etmək istəyirəm. Bütün cari hesabat, bütün testlər, nömrələr istifadə etdiyimiz konfiqurasiya üçün verilir. İndi ondan saniyədə təxminən 20 min metrik alırıq. Bunun sizin üçün işləyəcəyini anlamağa çalışırsınızsa, müqayisə edə bilərsiniz. Bu gün müzakirə edilənlər yamaq şəklində GitHub-da yerləşdirilib:
Yama daxildir:
- Clickhouse ilə tam inteqrasiya (həm Zabbix server, həm də frontend);
- preprocessor meneceri ilə problemlərin həlli;
- asinxron sorğu.
Yamaq lts daxil olmaqla bütün versiya 4 ilə uyğun gəlir. Çox güman ki, minimal dəyişikliklərlə 3.4 versiyasında işləyəcək.
Diqqətinizə görə təşəkkür edirik.
Suallar
Tamaşaçıların sualı (bundan sonra – A): – Axşamınız xeyir! Zəhmət olmasa deyin, Zabbix komandası ilə və ya onlarla sizinlə intensiv qarşılıqlı əlaqə planlarınız varmı ki, bu yamaq deyil, Zabbixin normal davranışı olsun?
MM: – Bəli, bəzi dəyişiklikləri mütləq edəcəyik. Nəsə olacaq, yamaqda nəsə qalacaq.
A: - Əla hesabata görə çox sağ olun! Zəhmət olmasa deyin, yamağı tətbiq etdikdən sonra Zabbix-dən dəstək qalacaq və daha yüksək versiyalara yeniləməyə necə davam etmək olar? Yamadan sonra Zabbix-i 4.2, 5.0-a yeniləmək mümkün olacaqmı?
MM: - Dəstəklə bağlı heç nə deyə bilmərəm. Zabbix texniki dəstəyi olsaydım, yəqin ki, yox deyərdim, çünki bu başqasının kodudur. 4.2 kod bazasına gəlincə, bizim mövqeyimiz belədir: "Biz zamanla hərəkət edəcəyik və növbəti versiyada özümüzü yeniləyəcəyik." Buna görə də bir müddət biz yenilənmiş versiyalar üçün yamaq yerləşdirəcəyik. Hesabatda artıq dedim: versiyalarla edilən dəyişikliklərin sayı hələ də kifayət qədər azdır. Məncə 3.4-dən 4-ə keçid təxminən 15 dəqiqə çəkdi.Orada nəsə dəyişdi, amma çox da vacib deyil.
A: – Beləliklə, siz yamağı dəstəkləməyi planlaşdırırsınız və onu istehsalda təhlükəsiz şəkildə quraşdıra və gələcəkdə hansısa şəkildə yeniləmələr ala bilərsiniz?
MM: - Biz bunu şiddətlə tövsiyə edirik. Bu, bizim üçün bir çox problemləri həll edir.
MCH: – Bir daha diqqəti cəlb etmək istərdim ki, arxitekturaya aidiyyatı olmayan, bloklanmaya və ya növbələrə aidiyyatı olmayan dəyişikliklər modul xarakter daşıyır, ayrı-ayrı modullardadır. Kiçik dəyişikliklərlə belə, onları çox asanlıqla saxlaya bilərsiniz.
MM: – Əgər təfərrüatlarla maraqlanırsınızsa, o zaman “Clickhouse” tarix kitabxanası adlanan kitabxanadan istifadə edir. Açıldı - bu, Elastics dəstəyinin bir nüsxəsidir, yəni konfiqurasiya edilə bilər. Səsvermə yalnız sorğu verənləri dəyişir. Bunun uzun müddət işləyəcəyinə inanırıq.
A: - Çox sağ olun. Mənə deyin, edilən dəyişikliklərin sənədi varmı?
MM: – Sənədləşmə yamaqdır. Aydındır ki, Clickhouse-un tətbiqi ilə, yeni növ sorğulayıcıların tətbiqi ilə yeni konfiqurasiya variantları yaranır. Son slayddakı linkdə ondan necə istifadə olunacağına dair qısa təsvir var.
Fping-in nmap ilə əvəz edilməsi haqqında
A: - Nəhayət bunu necə həyata keçirdiniz? Konkret misallar verə bilərsinizmi: sizin strappers və xarici ssenariniz varmı? Bu qədər çox sayda hostu bu qədər tez yoxlamaq nə ilə nəticələnir? Bu hostları necə mənimsəyirsiniz? Onları birtəhər nmap etmək üçün qidalandırmaq, haradansa almaq, yerləşdirmək, bir şey işlətmək lazımdır?..
MM: - Sərin. Çox düzgün sual! Məsələ bundadır. Paketlərin sayını göstərən ICMP yoxlamaları üçün kitabxananı (ICMP ping, Zabbix hissəsi) dəyişdirdik - bir (1) və kod nmap-dən istifadə etməyə çalışır. Yəni bu, pingerin daxili işinə çevrilmiş Zabbixin daxili işidir. Müvafiq olaraq, heç bir sinxronizasiya və ya trapper istifadəsi tələb olunmur. Bu, sistemi toxunulmaz qoymaq və iki verilənlər bazası sisteminin sinxronizasiyası ilə məşğul olmamaq üçün qəsdən edilib: nəyi yoxlamaq, poller vasitəsilə yükləmək və yükləməmiz pozulub?.. Bu, daha sadədir.
A: – Proksilər üçün də işləyir?
MM: - Bəli, amma yoxlamamışıq. Səsvermə kodu həm Zabbixdə, həm də serverdə eynidir. İşləməlidir. Bir daha qeyd edim: sistemin performansı elədir ki, bizim proxy-yə ehtiyacımız yoxdur.
MCH: – Sualın düzgün cavabı belədir: “Niyə sizə belə bir sistemlə proxy lazımdır?” Yalnız NAT və ya bir növ yavaş kanal vasitəsilə monitorinq səbəbiylə...
A: – Düzgün başa düşdümsə, Zabbix-dən allertor kimi istifadə edirsiniz. Yoxsa qrafikləriniz (arxiv qatının olduğu yerdə) Grafana kimi başqa sistemə köçürülüb? Yoxsa bu funksiyadan istifadə etmirsiniz?
MM: – Bir daha vurğulayacağam: biz tam inteqrasiyaya nail olmuşuq. Biz tarixçəni Clickhouse-a tökürük, lakin eyni zamanda php frontendini dəyişdik. Php cəbhəsi Clickhouse-a gedir və bütün qrafikləri oradan edir. Eyni zamanda, düzünü desəm, eyni Clickhouse-dan, eyni Zabbix məlumatlarından digər qrafik ekran sistemlərində məlumat quran bir hissəmiz var.
MCH: – “Qrafan”da da.
Resursların bölüşdürülməsi ilə bağlı qərarlar necə qəbul edildi?
A: - Daxili mətbəxinizdən bir az paylaşın. Məhsulun ciddi şəkildə emalı üçün vəsait ayırmağın zəruriliyi barədə qərar necə qəbul edildi? Bunlar, ümumiyyətlə, müəyyən risklərdir. Və zəhmət olmasa, yeni versiyaları dəstəkləyəcəyiniz kontekstdə deyin: bu qərar idarəetmə baxımından necə əsaslandırılır?
MM: – Görünür, biz tarixin dramını çox yaxşı izah etməmişik. Biz nəyinsə edilməli olduğu bir vəziyyətdə tapdıq və iki paralel komanda ilə getdik:
- Biri yeni metodlardan istifadə edərək monitorinq sistemini işə salırdı: xidmət kimi monitorinq, birləşdirdiyimiz açıq mənbə həllərin standart dəsti və sonra yeni monitorinq sistemi ilə işləmək üçün iş prosesini dəyişdirməyə çalışırıq.
- Eyni zamanda, bunu edən (özü haqqında) həvəsli bir proqramçımız var idi. Elə oldu ki, o, qalib gəldi.
A: - Bəs komandanın sayı nə qədərdir?
MCH: - Qarşınızdadır.
A: – Deməli, həmişə olduğu kimi, sizə ehtiras lazımdır?
MM: - Ehtirasın nə olduğunu bilmirəm.
A: - Bu halda, görünür, siz. Çox sağ olun, siz möhtəşəmsiniz.
MM: - Təşəkkür edirəm.
Zabbix üçün yamalar haqqında
A: – Proksilərdən (məsələn, bəzi paylanmış sistemlərdə) istifadə edən sistem üçün, məsələn, pollerləri, proksiləri və qismən Zabbix-in özünün preprosessorunu uyğunlaşdırmaq və yamaqlamaq mümkündürmü; və onların qarşılıqlı əlaqəsi? Çox sayda proksi olan bir sistem üçün mövcud inkişafları optimallaşdırmaq mümkündürmü?
MM: – Mən bilirəm ki, Zabbix serveri proksi vasitəsilə yığılır (kod tərtib edilir və alınır). Biz bunu istehsalda sınaqdan keçirməmişik. Mən bu barədə əmin deyiləm, lakin məncə, proksidə preprosessor meneceri istifadə edilmir. Proksinin vəzifəsi Zabbix-dən bir sıra ölçülər götürmək, onları birləşdirmək (konfiqurasiyanı, yerli verilənlər bazasını da qeyd edir) və onu Zabbix serverinə qaytarmaqdır. Daha sonra server onu qəbul edəndə əvvəlcədən emal edəcək.
Proksilərə maraq başa düşüləndir. Biz yoxlayacağıq. Bu maraqlı mövzudur.
A: – İdeya belə idi: əgər siz sorğuçuları yamaq edə bilsəniz, onları proksidə yamaq və serverlə qarşılıqlı əlaqəni yamaq və preprosessoru bu məqsədlər üçün yalnız serverdə uyğunlaşdıra bilərsiniz.
MM: - Məncə, daha sadədir. Siz kodu götürürsünüz, yamaq tətbiq edirsiniz, sonra onu sizə lazım olan şəkildə konfiqurasiya edirsiniz - proksi serverləri toplayın (məsələn, ODBC ilə) və yamaqlanmış kodu sistemlər arasında paylayın. Lazım olduqda - bir proksi toplayın, lazım olduqda - server.
A: – Çox güman ki, serverə proxy ötürülməsini əlavə olaraq yamaq məcburiyyətində olmayacaqsınız?
MCH: - Yox, standartdır.
MM: – Əslində, ideyalardan biri səslənmədi. Biz həmişə ideyaların partlaması ilə dəyişikliklərin miqdarı və dəstəyin asanlığı arasında balans saxlamışıq.
Bəzi reklamlar 🙂
Bizimlə qaldığınız üçün təşəkkür edirik. Məqalələrimiz xoşunuza gəlirmi? Daha maraqlı məzmun görmək istəyirsiniz? Sifariş verməklə və ya dostlarınıza tövsiyə etməklə bizə dəstək olun, , Sizin üçün bizim tərəfimizdən icad edilmiş giriş səviyyəli serverlərin unikal analoqu: (RAID1 və RAID10, 24 nüvəyə qədər və 40 GB DDR4 ilə mövcuddur).
Dell R730xd Amsterdamdakı Equinix Tier IV məlumat mərkəzində 2 dəfə ucuzdur? Yalnız burada Hollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! haqqında oxuyun
Mənbə: www.habr.com