Konferenca e ardhshme HighLoad++ do të zhvillohet më 6 dhe 7 prill 2020 në Shën Petersburg. Detajet dhe biletat . HighLoad++ Moskë 2018. Salla 'Moskva'. 9 nëntor, 15:00. Tezat dhe .
* Monitorimi â online dhe analiza.
* Kufizimet kryesore të platformës ZABBIX.
* Zgjidhja për zgjerimin e magazinës së analizave.
* Optimizimi i serverit ZABBIX.
* Optimizimi i UI.
* Eksperienca e përdorimit të sistemit nën ngarkesa mbi 40k NVPS.
* Përmbledhje e shkurtër.
Mikhail Makurov (pĂ«r mĂ« shumĂ« â MM): â PĂ«rshĂ«ndetje tĂ« gjithĂ«ve!
Maksim Chernetsov (pĂ«r mĂ« shumĂ« â MĂ): â MirĂ«mĂ«ngjesi!
MM: â Lejojeni tĂ« paraqes Maksimin. Maks ishte inxhinier i talentuar, specialisti mĂ« i mirĂ« nĂ« rrjet, qĂ« njoh. Maksim merret me rrjetet dhe shĂ«rbimet, zhvillimin dhe funksionimin e tyre.
MĂ: â UnĂ« do tĂ« doja tĂ« flas pĂ«r Mikhail. Mikhail Ă«shtĂ« njĂ« zhvillues nĂ« C. Ai ka shkruar disa zgjidhje me ngarkesĂ« tĂ« lartĂ« pĂ«r pĂ«rpunimin e trafikut pĂ«r kompaninĂ« tonĂ«. Ne jetojmĂ« dhe punojmĂ« nĂ« Urale, nĂ« qytetin e burrave tĂ« fortĂ« Ăeljabinsk, nĂ« kompaninĂ« 'Intereskat'. Kompania jonĂ« Ă«shtĂ« njĂ« ofrues shĂ«rbimesh interneti dhe televizioni kabllor pĂ«r njĂ« milion njerĂ«z nĂ« 16 qytete.
MM: â Dhe duhet tĂ« theksoj se 'Intereskat' Ă«shtĂ« shumĂ« mĂ« shumĂ« se njĂ« provajder, Ă«shtĂ« njĂ« kompani IT. E shumta e zgjidhjeve tona janĂ« bĂ«rĂ« nga departamenti ynĂ« IT.
A: nga serverët që përpunojnë trafikun, deri te qendra e thirrjeve dhe aplikacioni mobil. Në departamentin IT aktualisht ka rreth 80 persona me kompetenca shumë të larmishme.
Rreth Zabbix dhe arkitekturës së tij
MĂ: â Tani do tĂ« pĂ«rpiqem tĂ« vendos rekord personal dhe nĂ« njĂ« minutĂ« tĂ« them se çfarĂ« Ă«shtĂ« Zabbix (pĂ«r mĂ« shumĂ« â 'Zabbix').
'Zabbix' pozicionohet si njĂ« sistem monitorimi 'nga kutia' i nivelit tĂ« sipĂ«rm. Ka shumĂ« funksione pĂ«r tĂ« lehtĂ«suar jetĂ«n: rregulla tĂ« zhvilluara tĂ« eskalimit, API pĂ«r integrim, grupimin dhe auto-zbulimin e mysafirĂ«ve dhe metrikeve. 'Zabbix' ka ashtuquajturat mjete pĂ«r zgjerim â proksi. 'Zabbix' Ă«shtĂ« njĂ« sistem me kod tĂ« hapur.
Përmbledhje e shkurtër mbi arkitekturën. Mund të thuhet se përbëhet nga tre komponentë:
- Serveri. I shkruar në C. Me përpunim dhe transmetim të mjaftueshëm të komplikuar të informacionit midis proceseve. Të gjitha përpunimet ndodhin aty: nga marrja deri te ruajtja në bazë.
- Të dhënat e gjitha ruhet në bazë. 'Zabbix' mbështet MySQL, PostgreSQL dhe Oracle.
- Ndërfaqja web është e shkruar në PHP. Në shumicën e sistemeve ofrohet me serverin Apache, por punon më efektivisht në lidhje me nginx + php.
Sot do të doja të ndaja një histori nga jeta e kompanisë sonë që lidhet me 'Zabbix'...
NjĂ« histori nga jeta e kompanisĂ« 'Intereskat'. ĂfarĂ« kemi dhe çfarĂ« na nevojitet?
5 ose 6 muaj më parë. Një herë pas pune...
MĂ: â Misha, pĂ«rshĂ«ndetje! Jam i lumtur qĂ« arrita tĂ« tĂ« kap, kemi njĂ« bisedĂ«. PĂ«rsĂ«ri kishim probleme me monitorimin. GjatĂ« njĂ« aksidenti tĂ« madh, gjithçka u ngadalĂ«sua, dhe nuk kishte informacione pĂ«r gjendjen e rrjetit. FatkeqĂ«sisht, kjo po pĂ«rsĂ«ritet pĂ«r herĂ« tĂ« parĂ«. Kam nevojĂ« pĂ«r ndihmĂ«n tĂ«nde. Le tĂ« bĂ«jmĂ« qĂ« monitorimi ynĂ« tĂ« funksionojĂ« nĂ« çdo rrethanĂ«!
MM: â Por le tĂ« fillojmĂ« duke e sinkronizuar veten. Nuk kam shikuar atje pĂ«r disa vjet. Sa e mbaj mend, ne u shkĂ«putĂ«m nga Nagios dhe kaluam nĂ« 'Zabbix' rreth 8 vjet mĂ« parĂ«. Dhe tani kemi, duket, 6 servera tĂ« fuqishĂ«m dhe rreth njĂ« duzinĂ« proksi. Nuk po e pĂ«rziej asgjĂ«?
MĂ: â Pothuajse. 15 servera, disa prej tĂ« cilĂ«ve janĂ« makina virtuale. E rĂ«ndĂ«sishmja Ă«shtĂ« se kjo nuk na shpĂ«ton nĂ« momentin kur kemi mĂ« nevojĂ«. Siç ndodhi aksidenti â serverĂ«t ngadalĂ«sohen dhe nuk shihet asgjĂ«. Provuar kemi tĂ« optimizojmĂ« konfigurimin, por nuk na jep rritje optimale tĂ« performancĂ«s.
MM: â E kuptoj. A keni parĂ« diçka, a keni mbledhur ndonjĂ« informacion nga diagnostika?
MĂ: â E para me tĂ« cilin duhet tĂ« merremi â Ă«shtĂ« baza e tĂ« dhĂ«nave. MySQL Ă«shtĂ« gjithmonĂ« e ngarkuar, duke ruajtur metrikat e reja, dhe kur 'Zabbix' fillon tĂ« gjenerojĂ« shumĂ« ngjarje â baza futet nĂ« vete pĂ«r disa orĂ«. PĂ«r optimizimin e konfigurimit tĂ« tĂ« dhĂ«nave tĂ« gabuara, teksa vetĂ«m kĂ«tĂ« vit kemi rinovuar harduerin: nĂ« serverĂ«t ka mĂ« shumĂ« se njĂ«qind giga memorie dhe sisteme disku nĂ« SSD RAID â rritja lineare nuk ka kuptim. ĂfarĂ« do tĂ« bĂ«jmĂ«?
MM: â E kuptoj. NĂ« pĂ«rgjithĂ«si, MySQL Ă«shtĂ« njĂ« bazĂ« e LTP. Duket se nuk Ă«shtĂ« mĂ« e pĂ«rshtatshme pĂ«r ruajtjen e arkivave tĂ« metrikave qĂ« kemi. Le tĂ« fillojmĂ« tĂ« kuptojmĂ«.
MĂ: â Le tĂ« shkojmĂ«!
Integrimi i Zabbix me Clickhouse si përfundim i hackathon-it
Pas pak kohe, morëm të dhëna interesante:
Shumica e hapĂ«sirĂ«s nĂ« bazĂ«n tonĂ« u zgjidh nga arkivi i metrikeve dhe mĂ« pak se 1% u pĂ«rdor pĂ«r konfigurimin, shabllonat dhe parametrat. NĂ« atĂ« kohĂ«, ne kishim pĂ«rdorur zgjidhjen Big data mbi Clickhouse pĂ«r mĂ« shumĂ« se njĂ« vit. Drejtimi i lĂ«vizjes pĂ«r ne ishte i qartĂ«. NĂ« âHackathonâ-in tonĂ« tĂ« pranverĂ«s, shkrova njĂ« integrim tĂ« âZabbixâ me âClickhouseâ pĂ«r serverin dhe front-end. NĂ« atĂ« moment, âZabbixâ kishte tashmĂ« mbĂ«shtetje pĂ«r ElasticSearch dhe vendosĂ«m ta krahasonim.
Krahasimi Clickhouse dhe Elasticsearch
MM: â PĂ«r krahasim, ne gjeneruam ngarkesĂ«n e njejtĂ« si ajo qĂ« siguron serveri âZabbixâ dhe shikuam se si do tĂ« silleshin sistemet. Ne shkruam tĂ« dhĂ«nat nĂ« grupe nga 1000 rreshta, duke pĂ«rdorur CURL. Ne parashikuan qĂ« âClickhouseâ do tĂ« ishte mĂ« efikas pĂ«r profilin e ngarkesĂ«s qĂ« bĂ«n âZabbixâ. Rezultatet e kaluan edhe pritjet tona:
NĂ« kushte tĂ« njĂ«jta nĂ« testet, âClickhouseâ shkruante tri herĂ« mĂ« shumĂ« tĂ« dhĂ«na. TĂ« dy sistemet konsumonin shumĂ« efikasitet (mĂ« pak burime), duke lexuar tĂ« dhĂ«nat. Por âElasticSearchâ kĂ«rkonte shumĂ« procesor gjatĂ« shkrimit:
NĂ« total, âClickhouseâ e tejkaloi ndjeshĂ«m âElasticâ nĂ« konsumimin e procesorit dhe shpejtĂ«sinĂ«. Duke pĂ«rdorur kompresimin e tĂ« dhĂ«nave, âClickhouseâ pĂ«rdor 11 herĂ« mĂ« pak nĂ« disk dhe bĂ«n rreth 30 herĂ« mĂ« pak operacione nĂ« disk:
MĂ: â Po, puna me sistemin e diskut nĂ« âClickhouseâ Ă«shtĂ« realizuar shumĂ« efikas. PĂ«r bazat mund tĂ« pĂ«rdoren disqet e mĂ«dha SATA dhe tĂ« arrihet shpejtĂ«sia e shkrimit nĂ« qindra mijĂ«ra rreshta nĂ« sekondĂ«. Sistemi ânga kutiaâ mbĂ«shtet sharding, replikimin, dhe Ă«shtĂ« shumĂ« e lehtĂ« pĂ«r t'u konfiguruar. Ne jemi mĂ« shumĂ« se tĂ« kĂ«naqur me pĂ«rdorimin e saj pĂ«r njĂ« vit.
PĂ«r optimizimin e burimeve, mund tĂ« instaloni âClickhouseâ pranĂ« bazĂ«s ekzistuese kryesore dhe kĂ«shtu tĂ« kurseni shumĂ« kohĂ« procesori dhe operacione nĂ« disk. Ne e transferuam arkivin e metrikeve nĂ« klasteret âClickhouseâ tĂ« ekzistuara:
Ne e kemi shkarkuar aq shumĂ« bazĂ«n tonĂ« MySQL, saqĂ« mund ta bashkojmĂ« atĂ« nĂ« njĂ« makinĂ« me serverin âZabbixâ dhe tĂ« heqim qeverinĂ« e veçantĂ« pĂ«r MySQL.
Si funksionon polling në Zabbix?
4 muaj më parë
MM: â E gjithĂ« kjo, mund tĂ« harrojmĂ« pĂ«r problemet me bazĂ«n?
MĂ: â Definitivisht! NjĂ« tjetĂ«r detyrĂ« qĂ« duhet tĂ« zgjidhim Ă«shtĂ« grumbullimi i ngadalshĂ«m tĂ« tĂ« dhĂ«nave. Tani tĂ« gjithĂ« 15 serverĂ«t tanĂ« proxy janĂ« tĂ« ngarkuar me proceset SNMP dhe polling. Dhe sâka asnjĂ« zgjidhje tjetĂ«r veçse tĂ« vendosim serverĂ« tĂ« rinj.
MM: â Super! Por mĂ« thuaj fillimisht se si funksionon polling nĂ« âZabbixâ?
MĂ: â NĂ«se duam ta shkurtojmĂ«, ekzistojnĂ« 20 lloje metrike dhe disa mĂ«nyra tĂ« grumbullimit tĂ« tyre. âZabbixâ mund tĂ« grumbullojĂ« tĂ« dhĂ«na ose nĂ« modalitetin âkĂ«rkesĂ« â pĂ«rgjigjeâ, ose tĂ« presĂ« pĂ«r tĂ« dhĂ«na tĂ« reja pĂ«rmes âInterface Trapâ.
Duhet tĂ« theksohet se nĂ« versionin origjinal tĂ« âZabbixâ, ky metodĂ« (Trapper) Ă«shtĂ« mĂ« e shpejtĂ«.
Ekzistojnë proxy për shpërndarjen e ngarkesës:
Proxy-t mund tĂ« kryejnĂ« tĂ« njĂ«jtat funksione tĂ« grumbullimit, si serveri âZabbixâ, duke marrĂ« detyra nga ai dhe dĂ«rguar metrike tĂ« grumbulluara pĂ«rmes interfesĂ«s Trapper. Ky Ă«shtĂ« mĂ«nyra zyrtare e rekomanduar pĂ«r shpĂ«rndarjen e ngarkesĂ«s. Gjithashtu, proxy-t janĂ« tĂ« dobishĂ«m pĂ«r monitorimin e infrastrukturĂ«s tĂ« largĂ«t qĂ« punon pĂ«rmes NAT ose kanaleve tĂ« ngadalta:
MM: â Po, me arkitekturĂ«n Ă«shtĂ« e qartĂ«. Duhet tĂ« shohim gjĂ«rat burimore...
Disa ditë më vonë
Tregimi për atë si nmap fping fitoi
MM: â MĂ« duket se kam gjetur diçka.
MĂ: â Tregoji!
MM: â Kam zbuluar se gjatĂ« kontrollit tĂ« qasshmĂ«risĂ«, âZabbixâ bĂ«het kontrolli maksimal deri nĂ« 128 host-e njĂ«kohĂ«sisht. Kam provuar ta rris kĂ«tĂ« numĂ«r deri nĂ« 500 dhe hequr intervalin midis paketave nĂ« ping (ping) â kjo rriti performancĂ«n dyfish. Por do tĂ« doja mĂ« shumĂ« numra.
MĂ: â NĂ« praktikĂ«n time, ndonjĂ«herĂ« mĂ« duhet tĂ« kontrolloj qasshmĂ«rinĂ« e mijĂ«ra host-eve, dhe asgjĂ« mĂ« shpejt se nmap nuk kam hasur. Jam i sigurt se kjo Ă«shtĂ« mĂ«nyra mĂ« e shpejtĂ«. Le tĂ« provonim atĂ«! Duhet tĂ« rrisim ndjeshĂ«m numrin e host-eve pĂ«r çdo iteracion.
MM: â TĂ« kontrollojmĂ« mĂ« shumĂ« se pesĂ«qind? 600?
MĂ: â Si minimum disa mijĂ«.
MM: â Ok. GjĂ«ja mĂ« e rĂ«ndĂ«sishme qĂ« doja tĂ« thoja Ă«shtĂ« se kam gjetur se shumica e polling nĂ« âZabbixâ Ă«shtĂ« realizuar nĂ« mĂ«nyrĂ« sinkrone. Ne patjetĂ«r duhet ta pĂ«rmirĂ«sojmĂ« atĂ« nĂ« njĂ« modalitet asinkron. AtĂ«herĂ« do tĂ« jemi nĂ« gjendje tĂ« rrisim ndjeshĂ«m numrin e metrikeve tĂ« grumbulluara nga pollerĂ«t, veçanĂ«risht nĂ«se rrisim numrin e metrikeve pĂ«r njĂ« iteracion.
MĂ: â Super! Dhe kur?
MM: â Si zakonisht, dje.
MĂ: â Ne krahasuam tĂ« dy versionet fping dhe nmap:
Në një numër të madh hostesh, nmap kishte pritur të ishte deri në pesë herë më efikas. Duke qenë se nmap kontrollon vetëm faktin e aksesit dhe kohën e përgjigjes, ne e transferuam numërimin e humbjeve në trigere dhe ndjeshëm e zvogëluam intervalin e kontrollit të aksesit. Numri optimal i hosteve për nmap e gjetëm rreth 4 mijë për një iteracion. Nmap na lejoi të ulnim shpenzimet e CPU për kontrollin e aksesit në tre herë dhe të zvogëlONIM intervalin nga 120 sekonda në 10.
Optimizimi i polling
MM: â MĂ« pas u angazhuam me pollerĂ«t. Kryesisht na interesonte marrja e SNMP-sĂ« dhe agjentĂ«t. NĂ« "Zabbix" polling Ă«shtĂ« i realizuar nĂ« mĂ«nyrĂ« sinkrone dhe janĂ« marrĂ« masa speciale pĂ«r tĂ« rritur efikasitetin e sistemit. NĂ« modalitetin sinkron, çaktivizimi i hosteve shkakton njĂ« degradim tĂ« dukshĂ«m tĂ« pollingut. Ekziston njĂ« sistem i tĂ«rĂ« gjendjesh, ekzistojnĂ« procese speciale â tĂ« ashtuquajturit unreachable-pollers, tĂ« cilĂ«t punojnĂ« vetĂ«m me hostet e paqashtueshĂ«m:
Ky është një koment që tregon matricën e gjendjeve, tërë kompleksitetin e sistemeve të kalimeve që kërkohen për të qëndruar efikase sistemi. Për më tepër, vetë polling i sinkronizuar është mjaft i ngadaltë:
Pikërisht për këtë arsye, mijëra rrjedha pollerësh në një duzinë proxy nuk mundën të mbledhin për ne numrin e nevojshëm të të dhënave. Realizimi asinkron zgjidhi jo vetëm problemet me numrin e rrjedhave, por gjithashtu e thjeshtoi ndjeshëm sistemin e gjendjeve të hosteve të paqashtueshëm, sepse në çdo numër që kontrollohet në një iteracion të pollingut, koha maksimale e pritjes ishte një timeout:
PĂ«r mĂ« tepĂ«r, ne modifikuam dhe pĂ«rmirĂ«suam sistemin e pollingut pĂ«r kĂ«rkesat SNMP. ĂĂ«shtja Ă«shtĂ« se shumica nuk mund tĂ« pĂ«rgjigjen nĂ« disa kĂ«rkesa SNMP njĂ«kohĂ«sisht. Prandaj ne krijuam njĂ« modalitet hibrid, kur polling SNMP i tĂ« njĂ«jtit host bĂ«het asinkron:
Kjo bëhet për të gjithë grupin e hosteve. Ky modalitet më në fund nuk është më i ngadalshëm se sa plotësisht asinkroni, pasi pyetja e njëqind e pesëdhjetë vlerave SNMP gjithsesi është shumë më e shpejtë se një timeout.
Eksperimentet tona treguan se numri optimal i kërkesave në një iteracion është rreth 8 mijë gjatë pollingut SNMP. Në total, kalimi në modalitetin asinkron lejoj që performanca e pollingut të përshpejtohet 200 herë, në disa qindra herë.
MĂ: Optimizimet e marra nga polling treguan se ne jo vetĂ«m qĂ« mund tĂ« eliminojmĂ« tĂ« gjitha proxy-t, por gjithashtu tĂ« shkurtomĂ« intervalet pĂ«r shumĂ« kontrolle, dhe proxy do tĂ« bĂ«hen tĂ« panevojshme si njĂ« mĂ«nyrĂ« pĂ«r tĂ« ndarĂ« ngarkesĂ«n.
Rreth tri muajve më parë
Ndrysho arkitekturĂ«n â rrit ngarkesĂ«n!
MM: - Eja, Max, a është koha për prodhim? Më nevojitet një server i fuqishëm dhe një inxhinier i mirë.
MĂ: - MirĂ«, do ta planifikojmĂ«. Eshte koha tĂ« lĂ«vizim nga pika e vdekur me 5 mijĂ« metrika nĂ« sekondĂ«.
Mëngjesi pas përmirësimit
MĂ: - Misha, u pĂ«rmirĂ«suam, por deri nĂ« mĂ«ngjes u kthyem prapa... Mund ta gjesh se cila shpejtĂ«si arritĂ«m?
MM: - Maksimumi 20 mijë.
MĂ: - Po, 25! FatkeqĂ«sisht, jemi aty ku filluam.
MM: - Pse kështu? A ndonjë diagnostikim e kemi bërë?
MĂ: - Po, sigurisht! Ja, pĂ«r shembull, njĂ« top interesant:
MM: - Le të shohim. Shikoj se kemi provuar një numër të madh rrjedhash të polling-ut:
Por megjithatë nuk arritëm të shfrytëzojmë sistemin as në gjysmë:
Dhe performanca totale është mjaft e vogël, rreth 4 mijë metrika në sekondë:
Ka diçka tjetër?
MĂ: - Po, strace e njĂ«rit nga poleruesit:
MM: - Këtu duket qartë se procesi i polling-ut po pret "semaforë". Këto janë bllokime:
MĂ: - E paqartĂ«.
MM: - Shiko, kjo duket si një situatë ku një grup rrjedhash përpiqet të punojë me një burim, me të cilin mund të punojë vetëm një në të njëjtën kohë. Atëherë, gjithçka që ata mund të bëjnë është të ndajnë këtë burim përmes kohës:
Dhe performanca totale e punës me një burim të tillë është e kufizuar nga shpejtësia e një brendi:
Kjo lloj problemi mund të zgjidhet në dy mënyra.
Të përmirësojmë harduerin e makinës, të kalojmë në bërthama më të shpejta:
Ose të ndryshojmë arkitekturën dhe ngarkesën për të përputhur:
MĂ: - Nga ana tjetĂ«r, nĂ« makinĂ«n testuese do tĂ« lĂ«shojmĂ« njĂ« numĂ«r mĂ« tĂ« vogĂ«l bĂ«rthamash se nĂ« atĂ« tĂ« prodhimit, por ato janĂ« rreth 1.5 herĂ« mĂ« tĂ« shpejtĂ« nĂ« frekuencĂ«n e bĂ«rthamĂ«s!
MM: - A është e qartë? Duhet të shohim kodin e serverit.
Rrjedha e të dhënave në serverin Zabbix
MĂ: - PĂ«r tĂ« kuptuar, filluam tĂ« analizojmĂ« mĂ«nyrĂ«n se si tĂ« dhĂ«nat kalojnĂ« brenda serverit "Zabbix":
Imazhi i shkëlqyer, apo jo? Le të kalojmë përmes tij hapat hap pas hapi, në mënyrë që të qartësojmë disi. Ka rrjedha dhe shërbime që janë përgjegjëse për mbledhjen e të dhënave:
Metricat e mbledhura ato i dërgojnë përmes një socket në Menaxherin e Parapërpunuesve, ku ruhen në një radhë:
Menaxheri i parapërpunuesve dërgon të dhënat tek punëtorët e tij, të cilët kryejnë udhëzimet e parapërpunimit dhe i kthejnë mbrapsht përmes të njëjtit socket:
Pas kësaj, menaxheri i parapërpunimit i ruan ato në cache të historisë:
Atyre merren nga history-syncers, të cilët kryejnë shumë funksione: për shembull, llogaritjet e triggers, mbushja e caches së vlerave dhe, më e rëndësishmja, ruajtja e metrikave në depojnë e historisë. Në përgjithësi, procesi është i komplikuar dhe mjaft i ngatërruar.
MM: â E para qĂ« ne pamĂ« ishte se shumica e thread-eve janĂ« nĂ« garĂ« pĂ«r atĂ« qĂ« quhet 'cache' konfigurations (zona e memories ku ruhen tĂ« gjitha konfigurimet e serverit). VeçanĂ«risht shumĂ« bllokime janĂ« bĂ«rĂ« nga thread-et pĂ«rgjegjĂ«se pĂ«r tĂ«rheqjen e tĂ« dhĂ«nave:
âŠsepse nĂ« konfigurim ruhen jo vetĂ«m metrikat me parametrat e tyre, por edhe radhĂ«t nga tĂ« cilat collector-Ă«t marrin informacionin se çfarĂ« duhet tĂ« bĂ«jnĂ« mĂ« pas. Kur ka shumĂ« collector-e dhe njĂ« bllokon konfigurimin, tĂ« tjerĂ«t presin kĂ«rkesat:
Collector-ët nuk duhet të konkurrojnë
Prandaj, e para që ne bëmë ishte të ndanim radhën në 4 pjesë dhe të lejonim collector-ët të blokonin këto radhë në kushte të sigurta, këto pjesë njëkohësisht:
Kjo eliminoi konkurrencën për cache-në e konfigurimeve dhe shpejtësia e punës së collector-ëve u rrit ndjeshëm. Por pastaj u ndeshëm me faktin se menaxheri i preprocessorit filloi të grumbullojë radhën e detyrave:
Menaxheri i preprocessorit duhet të jetë në gjendje të vendosë prioritete
Kjo ndodhte në rastet kur i mungonte performanca. Pastaj, gjithçka që mund të bënte ishte të grumbullonte kërkesat nga proceset e grumbullimit të të dhënave dhe t'i ruante ato në një tampon derisa të mbushte gjithë memorjen dhe të binte:
Për të zgjidhur këtë problem, ne shtuam një socket të dytë, i cili ishte i dedikuar veçanërisht për punonjësit:
Kështu, menaxheri i preprocessorit fitoi mundësinë të priorizojë punën e tij dhe në rast të rritjes së tamponit, detyra është të ngadalësojë grumbullimin, duke i dhënë punonjësve mundësinë për të marrë këtë tampon:
Pastaj e zbuluam se një nga arsyet e ngadalësimit ishin vetë punonjësit, pasi ata konkurronin për një burim që nuk ishte aspak i rëndësishëm për punën e tyre. Këtë problem e formuluam si një bug-fix dhe në versionet e reja të 'Zabbix'-it, ai është tashmë zgjidhur:
Rritja e numrit tĂ« socket-eve â na jep rezultat
Më pas vetë menaxheri i preprocessorit u bë nyja e ngushtë, pasi ishte një thread. Ai kishte limit të shpejtësisë së kernel-it, duke dhënë maksimumin e shpejtësisë prej rreth 70,000 metrikave në sekondë:
Prandaj ne bëmë katër, me katër grupe socket-esh, punonjës:
Dhe kjo e mundësoi rritjen e shpejtësisë deri në rreth 130,000 metrika:
Jo-lineariteti i rritjes shpjegohet me faktin se pati konkurrencë për cache-në e historisë. Për të, ishin në garë 4 menaxherë përpara- përpunues dhe history-syncers. Në këtë pikë, ne po marrim rreth 130,000 metrika në sekondë në makinen testuese, duke e shfrytëzuar atë afërsisht në 95% të CPU-së:
Rreth 2,5 muaj më parë
Dorëheqja nga snmp-community rriti NVP-të një herë e gjysmë
MM: â Max, mĂ« duhet njĂ« makinĂ« e re testuese! NĂ« tĂ« tanishmen nuk po pĂ«rfshiemi mĂ«.
MĂ: â ĂfarĂ« ka tani?
MM: â Tani â 130k NVP dhe CPU-ja Ă«shtĂ« 'nĂ« raft'.
MĂ: â Wow! Mrekulli! Prit, kam dy pyetje. Sipas llogarive tĂ« mia, ne kemi nevojĂ« rreth 15-20,000 metrikash nĂ« sekondĂ«. Pse na nevojitet mĂ« shumĂ«?
MM: â Dua tĂ« pĂ«rfundoj punĂ«n deri nĂ« fund. Dua tĂ« shoh se sa mund tĂ« nxjerrim nga ky sistem.
MĂ: â PorâŠ
MM: â Por pĂ«r biznesin Ă«shtĂ« e padobishme.
MĂ: â E kuptoj. Dhe pyetja e dytĂ«: a do tĂ« jemi nĂ« gjendje ta mbajmĂ« atĂ« qĂ« kemi tani vetĂ«, pa ndihmĂ«n e zhvilluesit?
MM: â Nuk mendoj. Ndryshimi i punĂ«s me cache-nĂ« e konfigurimit Ă«shtĂ« njĂ« problem. Ai lidhet me ndryshimet nĂ« shumicĂ«n e thread-eve dhe Ă«shtĂ« mjaft i komplikuar pĂ«r mbĂ«shtetje. Sapo ka shumĂ« tĂ« ngjarĂ«, do tĂ« jetĂ« shumĂ« e vĂ«shtirĂ« ta mbash.
MĂ: â AtĂ«herĂ« na nevojitet njĂ« alternativĂ«.
MM: â Ka njĂ« variant tĂ« tillĂ«. Mund tĂ« kalojmĂ« nĂ« kernel tĂ« shpejtĂ«, duke hequr dorĂ« nga sistemi i ri i bllokimit. Ne do tĂ« marrim akoma performancĂ« tĂ« 60-80,000 metrikave. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, ne mund tĂ« lĂ«mĂ« gjithĂ« kodin tjetĂ«r. 'ClickHouse', polling-u asinkron do tĂ« funksionojĂ«. Dhe do tĂ« jetĂ« e lehtĂ« pĂ«r mbĂ«shtetje.
MĂ: â Fantastic! Propozoj tĂ« ndalemi kĂ«tu.
Pas optimizimit të pjesës server, më në fund munda të nis kodin e ri në prodhim. Ne u dorëzuam nga disa ndryshime në favor të kalimit në një makinë me kernel të shpejtë dhe minimizimin e numrit të ndryshimeve në kod. Ne gjithashtu e thjeshtuam konfigurimin dhe, sa më shumë të jetë e mundur, heqëm dorë nga makro-t në elementët e të dhënave, pasi ato janë burim i bllokimeve të tjera.
Për shembull, heqja dorë nga makro-i i snmp-community, i cili është shpesh i pranishëm në dokumentacion dhe shembuj, në rastin tonë ndihmoi për të përshpejtuar NVP-të me rreth 1,5 herë.
Pas dy ditëve në prodhim
Heqim dritaret e daljes së historisë së incidenteve
MĂ: â Misha, ne kemi dy ditĂ« qĂ« po pĂ«rdorim sistemin, dhe gjithçka po funksionon. Por vetĂ«m kur gjithçka punon! Kishim disa punĂ« tĂ« planifikuara me transferimin e njĂ« segmenti tĂ« madh tĂ« rrjetit, dhe ne kontrolluam pĂ«rsĂ«ri manualisht çfarĂ« u ngrit, çfarĂ« nuk u ngrit.
MM: â Nuk mund tĂ« jetĂ«! Ne e kontrolluam gjithçka 10 herĂ«. Serveri pĂ«rpunon madje edhe mungesĂ«n totale tĂ« rrjetit menjĂ«herĂ«.
MĂ: â Po e kuptoj gjithçka: serveri, baza, top, austat, loget â gjithçka shpejt⊠Por ne shohim ndĂ«rfaqen nĂ« web, dhe aty â procesori «nĂ« raft» nĂ« server dhe kjo:
MM: â E kuptoj. Le tĂ« shikojmĂ« nĂ« web. Zbulua se nĂ« situatĂ«n kur kishte numĂ«r tĂ« madh tĂ« incidenteve aktive, shumica e widgeteve operative fillonin tĂ« punonin shumĂ« ngadalĂ«:
Arsyeja për këtë ishte gjenerimi i dritareve të daljes me historitë e incidenteve, të cilat gjeneroheshin për çdo element në listë. Prandaj, ne u dorëzuam nga gjenerimi i këtyre dritareve (komentuam 5 rreshta në kod), dhe kjo zgjidhi problemet tona.
Koha e ngarkesës së widgeteve, edhe në mungesë totale, u ul nga disa minuta në 10-15 sekonda të pranueshme për ne, dhe historia vazhdon të shikohet me një klikim në kohë:
Pas punës. 2 muaj më parë
MĂ: â Misha, po shkon? Kam njĂ« bisedĂ«.
MM: â Nuk kisha ndĂ«rmend. PĂ«rsĂ«ri diçka me «Zabbix»-in?
MĂ: â Jo, relaksohu! Thjesht doja tĂ« thoja: gjithçka funksionon, faleminderit! Pija Ă«shtĂ« nga unĂ«.
Zabbix është efektiv
«Zabbix» është një sistem dhe funksion mjaft universale dhe i pasur. Mund të përdoret lehtësisht për instalime të vogla «nga kutia», por me rritjen e nevojave duhet optimizuar. Për ruajtjen e një arkivi të madh metrikash, përdorni një depo të përshtatshme:
- mund të përdorni mjetet e integruara si integrimi me «Elasticsearch» ose nxjerrja e historisë në skedarë tekstualë (e disponueshme që nga versioni katër);
- mund të shfrytëzoni përvojën tonë dhe integrimin me «ClickHouse».
Për të rritur ndjeshëm shpejtësinë e mbledhjes së metrikave, mbledhni ato në mënyra asnjanëse dhe dërgoni përmes ndërfaqes së trapper në serverin «Zabbix»; ose mund të përdorni një patch për asnjanësinë e pollerëve të «Zabbix»-it.
«Zabbix» është shkruar në C dhe është mjaft efektiv. Zgjidhja e disa pikave arkitekturore të ngushta lejon gjithashtu rritjen e performancës së tij dhe, sipas përvojës sonë, marrim më shumë se 100,000 metrika në një makinë me një procesor.
Ai patch Zabbix
MM: â Dua tĂ« shtoj disa pika. I gjithĂ« raporti aktual, tĂ« gjitha testet, numrat e dhĂ«nave janĂ« pĂ«r atĂ« konfigurim qĂ« pĂ«rdorim ne. Ne tani po nxjerrim rreth 20,000 metrika nĂ« sekondĂ«. NĂ«se po pĂ«rpiqeni tĂ« kuptoni nĂ«se do tĂ« funksionojĂ« pĂ«r ju â mund ta krahasoni. Ajo qĂ« u tregua sot Ă«shtĂ« publikuar nĂ« GitHub nĂ« formĂ«n e njĂ« patch:
Patch përfshin:
- integrimin e plotë me «ClickHouse» (si për serverin, ashtu edhe për frontend-in e «Zabbix»);
- zgjidhjen e problemeve me menaxherin e parapërpunuesve;
- polling asnjanës.
Patch është i përputhshëm me të gjitha versionet 4, përfshirë lts. Shumë të mundshëm, me ndryshime minimale do të funksionojë në versionin 3.4.
Faleminderit për vëmendjen.
Pyetje
Pyetje nga audienca (pĂ«rshĂ«ndetje â A): â MirĂ«mĂ«ngjes! MĂ« thuaj, a keni plane pĂ«r bashkĂ«punim intensiv me ekipin e Zabbix ose ata me ju, qĂ« kjo tĂ« mos jetĂ« njĂ« patch, por njĂ« sjellje normale e «Zabbix»?
MM: â Po, disa ndryshime ne do t'i angazhojmĂ« sigurisht. Disa do tĂ« mbeten nĂ« patch.
A: â Faleminderit shumĂ« pĂ«r raportin e shkĂ«lqyer! MĂ« tregoni, pas aplikimit tĂ« patch-it do tĂ« mbetet mbĂ«shtetje nga «Zabbix»-i dhe si mund tĂ« pĂ«rditĂ«sohemi nĂ« versione mĂ« tĂ« larta? A do tĂ« ketĂ« mundĂ«si tĂ« pĂ«rditĂ«sojmĂ« «Zabbix» pas patch-it tuaj nĂ« 4.2, 5.0?
MM: â PĂ«r mbĂ«shtetje nuk mund tĂ« them. Sikur tĂ« isha mbĂ«shtetje teknike e «Zabbix», do tĂ« thosha ndoshta jo, sepse Ă«shtĂ« kod i huaj. Sa i pĂ«rket kodit tĂ« bazĂ«s 4.2, pozita jonĂ« Ă«shtĂ« kĂ«shtu: «Do tĂ« shkojmĂ« me kohĂ«n, dhe vetĂ« do tĂ« pĂ«rditĂ«sohemi nĂ« versionin e ardhshĂ«m». Prandaj pĂ«r njĂ« periudhĂ«, ne do tĂ« publikojmĂ« patch-in pĂ«r versionet e pĂ«rditĂ«suara. Already, siç e theksova nĂ« raport: numri i ndryshimeve me versionet Ă«shtĂ« ende mjaft e vogĂ«l. Mendoj se kalimi nga 3.4 nĂ« 4 na zuri, duket, rreth 15 minuta. Disa gjĂ«ra ndĂ«rruan, por jo shumĂ« tĂ« rĂ«ndĂ«sishme.
A: â Pra, ju planifikoni tĂ« mbani patch-in tuaj dhe mund tĂ« jeni tĂ« sigurt pĂ«r ta vendosur nĂ« prodhim, duke marrĂ« mĂ« vonĂ« pĂ«rditĂ«sime ndonjĂ«herĂ«?
MM: â Ne e rekomandojmĂ« kategorikisht. Kjo zgjidh probleme shumĂ« tĂ« mĂ«dha pĂ«r ne.
MĂ: â Duhet tĂ« theksoj se ndryshimet qĂ« nuk lidhen me arkitekturĂ«n dhe nuk lidhen me bllokadat, radhĂ«t â ato janĂ« modulare, ato janĂ« nĂ« modula tĂ« veçantĂ«. Edhe vetĂ«, me ndryshime tĂ« vogla, ato mund tĂ« mbahen mjaft lehtĂ«.
MM: â NĂ«se jeni tĂ« interesuar pĂ«r detajet, "Clickhouse" pĂ«rdor bibliotekĂ«n e histori. Ajo Ă«shtĂ« e çliruar â Ă«shtĂ« njĂ« kopje mbĂ«shtetje e "Elastiks", domethĂ«nĂ« mund tĂ« ndryshohet konfiguroti. Polling ndryshon vetĂ«m pollers. Ne besojmĂ« se kjo do tĂ« funksionojĂ« pĂ«r njĂ« kohĂ« tĂ« gjatĂ«.
A: â Faleminderit shumĂ«. A mund tĂ« mĂ« thoni nĂ«se ekziston ndonjĂ« dokumentacion pĂ«r ndryshimet e bĂ«ra?
MM: â Dokumentacioni Ă«shtĂ« patch. ĂshtĂ« e qartĂ«, me hyrjen e "Clickhouse", me hyrjen e llojeve tĂ« reja pollers, lindin mundĂ«si tĂ« reja konfiguruese. NĂ« lidhjen nga slidi i fundit ka njĂ« pĂ«rshkrim tĂ« shkurtĂ«r se si ta pĂ«rdorni kĂ«tĂ«.
Rreth zëvendësimit të fping me nmap
A: â Si e realizuat atĂ« pĂ«rfundimisht? Mund tĂ« jepni shembuj konkretĂ«: a keni strappers dhe skript tĂ« jashtĂ«m? ĂfarĂ« kontrollon kaq shpejt njĂ« numĂ«r kaq tĂ« madh hostesh? Si i merrni kĂ«ta hoste? Nmap-i duhet tĂ« ushqehet me ta, t'i marrĂ« nga diku, t'i vendosĂ«, tĂ« nisĂ« diçka ...?
MM: â ShumĂ« mirĂ«. Pyetje shumĂ« e rĂ«ndĂ«sishme! Esenca Ă«shtĂ« kĂ«shtu. Ne modifikuam bibliotekĂ«n (ICMP ping, njĂ« pĂ«rbĂ«rĂ«s i "Zabbix") pĂ«r ICMP kontroll, ku Ă«shtĂ« e specifikuar numri i paketave â njĂ«si (1), dhe kodi pĂ«rpiqet tĂ« pĂ«rdorĂ« nmap. Pra, kjo Ă«shtĂ« puna e brendshme e "Zabbix", dhe u bĂ« puna e brendshme e pingera. PĂ«r pasojĂ«, nuk ka nevojĂ« pĂ«r ndonjĂ« sinkronizim ose pĂ«rdorim tĂ« trapper-it. Kjo u bĂ« qĂ«llimisht, pĂ«r tĂ« mbajtur sistemin tĂ« paprekur dhe pĂ«r tĂ« mos u angazhuar nĂ« sinkronizimin e dy sistemeve tĂ« bazĂ«s: çfarĂ« tĂ« kontrollohet, sa tĂ« ngarkohet pĂ«rmes poller-it, dhe a nuk Ă«shtĂ« thyer ngarkesa jonĂ« ...? Kjo Ă«shtĂ« shumĂ« mĂ« e thjeshtĂ«.
A: â A funksionon dhe pĂ«r proxy?
MM: â Po, por ne nuk e kemi testuar. Kodi i pollingut Ă«shtĂ« i njĂ«llojtĂ« si nĂ« "Zabbix", ashtu edhe nĂ« server. Duhet tĂ« funksionojĂ«. PĂ«rsĂ«ri, e theksoj: performanca e sistemit Ă«shtĂ« e tillĂ« sa qĂ« nuk na nevojitet proxy.
MĂ: â PĂ«rgjigja e saktĂ« pĂ«r pyetjen Ă«shtĂ«: "Pse ju nevojitet proxy nĂ« njĂ« sistem tĂ« tillĂ«?" VetĂ«m pĂ«r shkak tĂ« NAT-it ose pĂ«r tĂ« monitoruar pĂ«rmes ndonjĂ« kanali tĂ« ngadalshĂ«m ...
A: â A e pĂ«rdorni "Zabbix" si alarĂ«m, nĂ«se e kuptova saktĂ«. Ose grafikat (ku Ă«shtĂ« shtresa arkiv) i keni dĂ«rguar nĂ« njĂ« sistem tjetĂ«r, si Grafana? Apo nuk e pĂ«rdorni kĂ«tĂ« funksionalitet?
MM: â E theksoj edhe njĂ« herĂ«: ne kemi bĂ«rĂ« njĂ« integrim tĂ« plotĂ«. Ne derdhim historinĂ« nĂ« "Clickhouse", por nĂ« tĂ« njĂ«jtĂ«n kohĂ« kemi ndryshuar frontend-in PHP. Frontendi PHP shkon nĂ« "Clickhouse" dhe krijon tĂ« gjitha grafikat nga aty. Po ashtu, nĂ«se jemi tĂ« sinqertĂ«, kemi njĂ« pjesĂ« qĂ« krijon nga i njĂ«jti "Clickhouse", nga tĂ« dhĂ«nat e "Zabbix" tĂ« dhĂ«na nĂ« sisteme tĂ« tjera pĂ«rpara grafike.
MĂ: â NĂ« "Grafana" gjithashtu.
Si u mor vendimi për ndarjen e burimeve?
A: â Ndani pak nga kuzhina juaj e brendshme. Si Ă«shtĂ« marrĂ« vendimi qĂ« tĂ« ndahen burime pĂ«r njĂ« rikonstruksion tĂ« rĂ«ndĂ«sishĂ«m tĂ« produktit? Kjo, nĂ« fakt, sjell disa rreziqe. Dhe ju lutem, nĂ« kontekstin e asaj qĂ« jeni duke planifikuar tĂ« mbani versione tĂ« reja: si justifikohet ky vendim nga pikĂ«pamja e menaxhimit?
MM: â DukshĂ«m, dramen e historisĂ« ne nuk e treguam shumĂ« mirĂ«. Ne u gjendĂ«m nĂ« njĂ« situatĂ« ku duhej tĂ« bĂ«hej diçka dhe shkuam nĂ« thelb me dy ekipe paralele:
- Njëra merrej me nisjen e sistemit të monitorimit me metoda të reja: monitorimi si shërbim, një grup standard i zgjidhjeve open-source që ne i kombinojmë dhe pastaj përpiqemi të ndryshojmë procesin e biznesit për të punuar me sistemin e ri të monitorimit.
- Përkundër kësaj, kishim një programues entuziast që merrej me këtë (rreth vetes). Doli që ai fitoi.
A: â Cila Ă«shtĂ« madhĂ«sia e ekipit?
MĂ: â Ai Ă«shtĂ« para jush.
A: â Pra, si gjithmonĂ« nevojitet njĂ« pasionar?
MM: â Nuk e di se çfarĂ« Ă«shtĂ« njĂ« pasionar.
A: â NĂ« kĂ«tĂ« rast, dukshĂ«m, jeni ju. Faleminderit shumĂ«, ju jeni tĂ« shkĂ«lqyer.
MM: â Faleminderit.
Rreth patches për Zabbix
A: â PĂ«r sistemin qĂ« pĂ«rdor proxy (pĂ«r shembull, nĂ« disa sisteme tĂ« shpĂ«rndara), a Ă«shtĂ« e mundur tĂ« pĂ«rshtatet zgjidhja juaj dhe tĂ« patch-ohen, pĂ«r shembull, pollers, proxy dhe pjesĂ«risht para-procesor i vetĂ« "Zabbix"; dhe ndĂ«rveprimi i tyre? A Ă«shtĂ« e mundur tĂ« optimizohen punimet ekzistuese pĂ«r njĂ« sistem me disa proxy?
MM: â UnĂ« e di qĂ« serveri "Zabbix" grumbullohet me ndihmĂ«n e proxy (kompilohet dhe merr kodin). Ne nuk e kemi testuar kĂ«tĂ« nĂ« prodhim. Nuk jam i sigurt pĂ«r kĂ«tĂ«, por, sipas mendimit tim, menaxheri i para-procesorit nuk pĂ«rdoret nĂ« proxy. Detyra e proxy Ă«shtĂ« tĂ« marrĂ« njĂ« grup metrike nga "Zabbix", t'i pollojĂ« ato (ai gjithashtu regjistron konfigurimin, bazĂ«n lokale) dhe t'ia kthejĂ« serverit tĂ« "Zabbix". Para-procesimi do tĂ« bĂ«het mĂ« vonĂ« nga vetĂ« serveri, kur ta marrĂ«.
Interesi pĂ«r proxy Ă«shtĂ« i kuptueshĂ«m. Ne do ta kontrollojmĂ« kĂ«tĂ«. ĂshtĂ« njĂ« temĂ« interesante.
A: â Ideja ishte kĂ«shtu: nĂ«se Ă«shtĂ« e mundur tĂ« patch-ohen pollers, Ă«shtĂ« e mundur tĂ« patch-ohen edhe nĂ« proxy dhe tĂ« patch-ohen ndĂ«rveprimin me serverin, dhe para-procesorin pĂ«r kĂ«to arsyet tĂ« pĂ«rshtatet vetĂ«m nĂ« server.
MM: â Mendova, Ă«shtĂ« akoma mĂ« e thjeshtĂ«. Merrni kodin, aplikoni patch-in, pastaj konfiguroni ashtu siç e dĂ«shironi â krijoni serverĂ« proxy (p.sh., me ODBC) dhe shpĂ«rndani kodin e patch-uar nĂ« sisteme. Atje ku Ă«shtĂ« e nevojshme â krijoni proxy, atje ku Ă«shtĂ« e nevojshme â server.
A: â SidoqoftĂ«, a nuk do tĂ« jetĂ« e nevojshme tĂ« patch-oni transmetimin e proxy-sĂ« nĂ« server, ndoshta?
MĂ: â Jo, ai Ă«shtĂ« standard.
MM: â NĂ« tĂ« vĂ«rtetĂ«, kjo ishte njĂ« nga idetĂ« qĂ« nuk u diskutua. Ne gjithmonĂ« kemi ruajtur njĂ« balancĂ« mes shpĂ«rthimit tĂ« ideve dhe sasisĂ« sĂ« ndryshimeve, lehtĂ«sisĂ« sĂ« mbĂ«shtetjes.
Pak reklamĂ« đ
Faleminderit që qëndroni me ne. Ju pëlqejnë artikujt tanë? Dëshironi të shihni më shumë materiale interesante? Na mbështetni duke bërë një porosi ose duke na rekomanduar njohurive tuaj, , një analog unik i serverëve entry-level, i ndërtuar për ju: (disponohen variante me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4).
Dell R730xd dyfish mĂ« i lirĂ« nĂ« qendrĂ«n e tĂ« dhĂ«nave Equinix Tier IV nĂ« Amsterdam? VetĂ«m kĂ«tu nĂ« HolandĂ«! Dell R420 â 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB â nga $99! Lexoni rreth
Burimi: habr.com
