De volgende HighLoad++ conferentie vindt plaats op 6 en 7 april 2020 in St. Petersburg. Details en tickets . HighLoad++ Moskou 2018. Zaal “Moskou”. 9 november, 15:00 uur. Scripties en .
* Monitoring - online en analyses.
* Basisbeperkingen van het ZABBIX-platform.
* Oplossing voor het schalen van analytische opslag.
* Optimalisatie van de ZABBIX-server.
* UI-optimalisatie.
* Ervaar het bedienen van het systeem onder een belasting van meer dan 40k NVPS.
* Korte conclusies.
Michail Makurov (hierna – MM): - Dag Allemaal!
Maxim Chernetsov (hierna – MCH): - Goedemiddag!
MM: – Laat mij Maxim even voorstellen. Max is een getalenteerde ingenieur, de beste netwerker die ik ken. Maxim houdt zich bezig met netwerken en diensten, de ontwikkeling en exploitatie ervan.
MCH: – En ik wil je graag over Mikhail vertellen. Mikhail is een C-ontwikkelaar. Hij schreef verschillende oplossingen voor de verwerking van zwaar verkeer voor ons bedrijf. We wonen en werken in de Oeral, in de stad van de stoere mannen Tsjeljabinsk, in het bedrijf Intersvyaz. Ons bedrijf is een aanbieder van internet- en kabeltelevisiediensten voor een miljoen mensen in 16 steden.
MM: – En het is de moeite waard om te zeggen dat Intersvyaz veel meer is dan alleen een provider, het is een IT-bedrijf. De meeste van onze oplossingen worden gemaakt door onze IT-afdeling.
A: van servers die verkeer verwerken tot een callcenter en mobiele applicatie. De IT-afdeling telt nu ongeveer 80 mensen met zeer uiteenlopende competenties.
Over Zabbix en zijn architectuur
MCH: – En nu zal ik proberen een persoonlijk record te vestigen en in één minuut te zeggen wat Zabbix is (hierna “Zabbix” genoemd).
Zabbix positioneert zichzelf als een out-of-the-box monitoringsysteem op ondernemingsniveau. Het heeft veel functies die het leven gemakkelijker maken: geavanceerde escalatieregels, API voor integratie, groepering en automatische detectie van hosts en statistieken. Zabbix heeft zogenaamde schalingstools: proxy's. Zabbix is een open source-systeem.
Kort over architectuur. We kunnen zeggen dat het uit drie componenten bestaat:
- Server. Geschreven in C. Met vrij complexe verwerking en overdracht van informatie tussen threads. Alle verwerking vindt daarin plaats: van ontvangen tot opslaan in de database.
- Alle gegevens worden opgeslagen in de database. Zabbix ondersteunt MySQL, PostreSQL en Oracle.
- De webinterface is geschreven in PHP. Op de meeste systemen wordt het geleverd met een Apache-server, maar werkt efficiënter in combinatie met nginx + php.
Vandaag willen we één verhaal vertellen uit het leven van ons bedrijf met betrekking tot Zabbix...
Een verhaal uit het leven van het bedrijf Intersvyaz. Wat hebben we en wat hebben we nodig?
5 of 6 maanden geleden. Eén dag na het werk...
MCH: - Misha, hallo! Ik ben blij dat ik je heb kunnen betrappen - er is een gesprek. Opnieuw hadden we problemen met de monitoring. Tijdens een zwaar ongeval verliep alles traag en was er geen informatie over de toestand van het netwerk. Helaas is dit niet de eerste keer dat dit gebeurt. Ik heb je hulp nodig. Laten we ervoor zorgen dat onze monitoring onder alle omstandigheden werkt!
MM: - Maar laten we eerst synchroniseren. Ik heb daar al een paar jaar niet meer gekeken. Voor zover ik me herinner, hebben we Nagios ongeveer 8 jaar geleden verlaten en zijn we overgestapt op Zabbix. En nu lijken we zes krachtige servers en een tiental proxy's te hebben. Verwar ik iets?
MCH: - Bijna. 15 servers, waarvan sommige virtuele machines. Het belangrijkste is dat het ons niet redt op het moment dat we het het meest nodig hebben. Als een ongeluk: de servers vertragen en je kunt niets zien. We hebben geprobeerd de configuratie te optimaliseren, maar dit leverde niet de optimale prestatieverbetering op.
MM: - Het is duidelijk. Heb je iets bekeken, heb je al iets uit de diagnostiek opgegraven?
MCH: – Het eerste waar u mee te maken krijgt, is de database. MySQL wordt voortdurend geladen en slaat nieuwe statistieken op, en wanneer Zabbix een aantal gebeurtenissen begint te genereren, gaat de database letterlijk een paar uur overdrive. Ik heb je al verteld over het optimaliseren van de configuratie, maar dit jaar hebben ze letterlijk de hardware bijgewerkt: de servers hebben meer dan honderd gigabyte aan geheugen en schijfarrays op SSD RAID's - het heeft geen zin om dit op de lange termijn lineair te laten groeien. Wat doen we?
MM: - Het is duidelijk. Over het algemeen is MySQL een LTP-database. Blijkbaar is het niet langer geschikt voor het opslaan van een archief met statistieken van onze omvang. Laten we het uitzoeken.
MCH: - Laten we!
Integratie van Zabbix en Clickhouse als resultaat van de hackathon
Na enige tijd ontvingen we interessante gegevens:
Het grootste deel van de ruimte in onze database werd ingenomen door het metrische archief en minder dan 1% werd gebruikt voor configuratie, sjablonen en instellingen. Tegen die tijd hadden we de Big data-oplossing op basis van Clickhouse al ruim een jaar in gebruik. De bewegingsrichting was voor ons duidelijk. Tijdens onze voorjaarshackathon schreef ik de integratie van Zabbix met Clickhouse voor de server en frontend. Op dat moment had Zabbix al ondersteuning voor ElasticSearch en we besloten ze te vergelijken.
Vergelijking van Clickhouse en Elasticsearch
MM: – Ter vergelijking hebben we dezelfde belasting gegenereerd als de Zabbix-server biedt en gekeken hoe de systemen zich zouden gedragen. We schreven gegevens in batches van 1000 regels met behulp van CURL. We gingen er vooraf van uit dat Clickhouse efficiënter zou zijn voor het laadprofiel dat Zabbix doet. De resultaten overtroffen zelfs onze verwachtingen:
Onder dezelfde testomstandigheden schreef Clickhouse drie keer meer gegevens. Tegelijkertijd verbruikten beide systemen zeer efficiënt (een kleine hoeveelheid bronnen) bij het lezen van gegevens. Maar Elastics had bij het opnemen een grote hoeveelheid processor nodig:
In totaal was Clickhouse aanzienlijk superieur aan Elastix wat betreft processorverbruik en snelheid. Tegelijkertijd gebruikt Clickhouse dankzij datacompressie 11 keer minder op de harde schijf en voert het ongeveer 30 keer minder schijfbewerkingen uit:
MCH: – Ja, het werk van Clickhouse met het schijfsubsysteem is zeer efficiënt geïmplementeerd. U kunt enorme SATA-schijven gebruiken voor databases en schrijfsnelheden bereiken van honderdduizenden regels per seconde. Het kant-en-klare systeem ondersteunt sharding, replicatie en is zeer eenvoudig te configureren. Wij zijn meer dan tevreden over het gebruik ervan, het hele jaar door.
Om de bronnen te optimaliseren, kunt u Clickhouse naast uw bestaande hoofddatabase installeren en daardoor veel CPU-tijd en schijfbewerkingen besparen. We hebben het archief met statistieken verplaatst naar bestaande Clickhouse-clusters:
We hebben de belangrijkste MySQL-database zo ontlast dat we deze op één machine konden combineren met de Zabbix-server en de speciale server voor MySQL konden verlaten.
Hoe werkt pollen in Zabbix?
4 maanden geleden
MM: – Kunnen we de problemen met de basis vergeten?
MCH: - Dat is zeker! Een ander probleem dat we moeten oplossen is de trage gegevensverzameling. Nu zijn al onze 15 proxyservers overbelast met SNMP- en pollingprocessen. En er is geen andere manier dan nieuwe en nieuwe servers te installeren.
MM: - Geweldig. Maar vertel ons eerst hoe polling werkt in Zabbix?
MCH: – Kortom, er zijn twintig soorten statistieken en een tiental manieren om deze te verkrijgen. Zabbix kan gegevens verzamelen in de “request-response” -modus, of wachten op nieuwe gegevens via de “Trapper Interface”.
Het is vermeldenswaard dat in de originele Zabbix deze methode (Trapper) de snelste is.
Er zijn proxyservers voor belastingverdeling:
Proxy's kunnen dezelfde verzamelfuncties uitvoeren als de Zabbix-server, taken ervan ontvangen en de verzamelde statistieken via de Trapper-interface verzenden. Dit is de officieel aanbevolen manier om de belasting te verdelen. Proxy's zijn ook handig voor het monitoren van externe infrastructuur die via NAT of een langzaam kanaal werkt:
MM: – Alles is duidelijk met architectuur. We moeten naar de bronnen kijken...
Een paar dagen later
Het verhaal van hoe nmap fping won
MM: ‘Ik denk dat ik iets heb opgegraven.’
MCH: - Zeg eens!
MM: – Ik ontdekte dat Zabbix bij het controleren van de beschikbaarheid maximaal 128 hosts tegelijk controleert. Ik heb geprobeerd dit aantal te verhogen naar 500 en het interval tussen pakketten in hun ping (ping) te verwijderen - dit verdubbelde de prestaties. Maar ik zou graag grotere aantallen willen.
MCH: – In mijn praktijk moet ik soms de beschikbaarheid van duizenden hosts controleren, en ik heb hiervoor nog nooit iets sneller gezien dan nmap. Ik weet zeker dat dit de snelste manier is. Laten we het proberen! We moeten het aantal hosts per iteratie aanzienlijk vergroten.
MM: – Meer dan vijfhonderd controleren? 600?
MCH: - Minstens een paar duizend.
MM: - OK. Het belangrijkste dat ik wilde zeggen is dat ik ontdekte dat de meeste peilingen in Zabbix synchroon plaatsvinden. We moeten het zeker veranderen naar de asynchrone modus. Dan kunnen we het aantal statistieken dat door opiniepeilers wordt verzameld dramatisch vergroten, vooral als we het aantal statistieken per iteratie verhogen.
MCH: - Geweldig! En wanneer?
MM: – Zoals gewoonlijk, gisteren.
MCH: – We vergeleken beide versies van fping en nmap:
Op een groot aantal hosts werd verwacht dat nmap tot vijf keer effectiever zou zijn. Omdat nmap alleen de beschikbaarheid en responstijd controleert, hebben we de berekening van verliezen verplaatst naar triggers en hebben we de intervallen voor beschikbaarheidscontrole aanzienlijk verkort. We vonden dat het optimale aantal hosts voor nmap ongeveer 4 per iteratie was. Met Nmap konden we de CPU-kosten van beschikbaarheidscontroles drie keer verlagen en het interval verkorten van 120 seconden naar 10.
Optimalisatie van opiniepeilingen
MM: “Toen zijn we begonnen met opiniepeilingen. We waren vooral geïnteresseerd in SNMP-detectie en agenten. In Zabbix gebeurt het pollen synchroon en zijn er speciale maatregelen genomen om de efficiëntie van het systeem te vergroten. In de synchrone modus veroorzaakt het niet beschikbaar zijn van de host een aanzienlijke verslechtering van de polling. Er is een heel systeem van staten, er zijn speciale processen - de zogenaamde onbereikbare opiniepeilers, die alleen werken met onbereikbare hosts:
Dit is een commentaar dat de toestandsmatrix demonstreert, alle complexiteit van het systeem van transities die nodig zijn om het systeem effectief te laten blijven. Bovendien is synchrone polling zelf vrij traag:
Dat is de reden waarom duizenden pollerstreams op tientallen proxy’s niet de vereiste hoeveelheid gegevens voor ons konden verzamelen. De asynchrone implementatie loste niet alleen de problemen met het aantal threads op, maar vereenvoudigde ook aanzienlijk het statussysteem van niet-beschikbare hosts, omdat voor elk aantal dat in één polling-iteratie werd gecontroleerd, de maximale wachttijd 1 time-out was:
Daarnaast hebben we het pollingsysteem voor SNMP-verzoeken aangepast en verbeterd. Feit is dat de meeste mensen niet tegelijkertijd op meerdere SNMP-verzoeken kunnen reageren. Daarom hebben we een hybride modus gemaakt, wanneer SNMP-polling van dezelfde host asynchroon wordt uitgevoerd:
Dit wordt gedaan voor het hele pakket hosts. Deze modus is uiteindelijk niet langzamer dan een volledig asynchroon, aangezien het opvragen van anderhalfhonderd SNMP-waarden nog steeds veel sneller is dan 1 time-out.
Onze experimenten hebben aangetoond dat het optimale aantal verzoeken in één iteratie ongeveer 8 bedraagt met SNMP-polling. In totaal heeft de overgang naar de asynchrone modus ons in staat gesteld de pollingprestaties 200 keer, honderden keren, te versnellen.
MCH: – De resulterende polling-optimalisaties hebben aangetoond dat we niet alleen alle proxy’s kunnen verwijderen, maar ook de intervallen voor veel controles kunnen verkorten, en dat proxy’s niet langer nodig zullen zijn als een manier om de last te verdelen.
Ongeveer drie maanden geleden
Verander de architectuur - verhoog de belasting!
MM: - Nou, Max, is het tijd om productief te worden? Ik heb een krachtige server en een goede ingenieur nodig.
MCH: - Oké, laten we het plannen. Het is de hoogste tijd om het dode punt van 5 metrieken per seconde te verlaten.
Ochtend na de upgrade
MCH: - Misha, we hebben onszelf bijgewerkt, maar tegen de ochtend zijn we teruggedraaid... Raad eens welke snelheid we hebben weten te bereiken?
MM: – Maximaal 20 duizend.
MCH: - Ja, 25! Helaas zijn we precies waar we begonnen.
MM: - Waarom? Heb je een diagnose uitgevoerd?
MCH: - Ja tuurlijk! Hier is bijvoorbeeld een interessante top:
MM: - Laten we kijken. Ik zie dat we een groot aantal pollingthreads hebben geprobeerd:
Maar tegelijkertijd konden ze het systeem niet eens voor de helft recyclen:
En de algehele prestaties zijn vrij klein, ongeveer 4 statistieken per seconde:
Is er nog iets anders?
MCH: – Ja, spoor van een van de stemmers:
MM: – Hier kun je duidelijk zien dat het stemproces wacht op “semaforen”. Dit zijn de sloten:
MCH: - Niet helder.
MM: – Kijk, dit is vergelijkbaar met een situatie waarin een aantal threads proberen te werken met bronnen waar slechts één tegelijk mee kan werken. Het enige wat ze dan kunnen doen is deze bron in de loop van de tijd delen:
En de totale prestaties van het werken met een dergelijke hulpbron worden beperkt door de snelheid van één kern:
Er zijn twee manieren om dit probleem op te lossen.
Upgrade de hardware van de machine, schakel over naar snellere cores:
Of verander de architectuur en verander tegelijkertijd de belasting:
MCH: – Trouwens, op de testmachine zullen we minder cores gebruiken dan op de gevechtsmachine, maar ze zijn 1,5 keer sneller in frequentie per core!
MM: - Duidelijk? Je moet naar de servercode kijken.
Gegevenspad in Zabbix-server
MCH: – Om dit uit te zoeken, zijn we begonnen te analyseren hoe gegevens worden overgedragen binnen de Zabbix-server:
Coole foto, toch? Laten we het stap voor stap doornemen om het min of meer duidelijk te maken. Er zijn threads en services die verantwoordelijk zijn voor het verzamelen van gegevens:
Ze verzenden de verzamelde statistieken via een socket naar de Preprocessor-manager, waar ze in een wachtrij worden opgeslagen:
De “preprocessormanager” verzendt gegevens naar zijn werknemers, die voorverwerkingsinstructies uitvoeren en deze terugsturen via dezelfde socket:
Hierna slaat de preprocessormanager ze op in de geschiedeniscache:
Van daaruit worden ze overgenomen door geschiedenis-zinkers, die heel wat functies vervullen: bijvoorbeeld het berekenen van triggers, het vullen van de waardecache en, belangrijker nog, het opslaan van statistieken in de geschiedenisopslag. Over het algemeen is het proces complex en zeer verwarrend.
MM: – Het eerste wat we zagen was dat de meeste threads strijden om de zogenaamde “configuratiecache” (het geheugengebied waar alle serverconfiguraties worden opgeslagen). Threads die verantwoordelijk zijn voor het verzamelen van gegevens doen vooral veel aan blokkering:
...aangezien de configuratie niet alleen statistieken met hun parameters opslaat, maar ook wachtrijen waaruit pollers informatie halen over wat ze vervolgens moeten doen. Als er veel pollers zijn en één de configuratie blokkeert, wachten de anderen op verzoeken:
Pollers mogen niet met elkaar in conflict komen
Daarom hebben we als eerste de wachtrij in vier delen verdeeld en de opiniepeilers deze wachtrijen, deze delen tegelijkertijd, onder veilige omstandigheden laten blokkeren:
Hierdoor werd de concurrentie om de configuratiecache weggenomen en nam de snelheid van de pollers aanzienlijk toe. Maar toen kwamen we het feit tegen dat de preprocessormanager een wachtrij met taken begon op te bouwen:
Preprocessormanager moet prioriteiten kunnen stellen
Dit gebeurde in gevallen waarin hij niet presteerde. Het enige wat hij vervolgens kon doen, was verzoeken van gegevensverzamelingsprocessen verzamelen en hun buffer optellen totdat het al het geheugen in beslag nam en crashte:
Om dit probleem op te lossen, hebben we een tweede socket toegevoegd die specifiek bedoeld was voor werknemers:
De preprocessormanager had dus de mogelijkheid om zijn werk te prioriteren en als de buffer groeit, is het de taak om de verwijdering te vertragen, waardoor werknemers de kans krijgen om deze buffer te gebruiken:
Toen ontdekten we dat een van de redenen voor de vertraging bij de arbeiders zelf lag, aangezien zij concurreerden om een hulpbron die volkomen onbelangrijk was voor hun werk. We hebben dit probleem gedocumenteerd als een bugfix en het is al opgelost in nieuwe versies van Zabbix:
We verhogen het aantal stopcontacten - we krijgen het resultaat
Verder werd de preprocessormanager zelf een knelpunt, omdat het één thread is. Het berustte op de kernsnelheid, wat een maximale snelheid opleverde van ongeveer 70 metrieken per seconde:
Daarom hebben we er vier gemaakt, met vier sets stopcontacten, werkers:
En hierdoor konden we de snelheid verhogen tot ongeveer 130 statistieken:
De niet-lineariteit van de groei wordt verklaard door het feit dat er concurrentie om de geschiedeniscache is ontstaan. Vier preprocessormanagers en geschiedenisverzinkers streden erom. Op dit moment ontvingen we ongeveer 4 meetgegevens per seconde op de testmachine, waarbij ongeveer 130% van de processor deze gebruikte:
Ongeveer 2,5 maanden geleden
Weigering van de snmp-gemeenschap verhoogde de NVP's met anderhalf keer
MM: – Max, ik heb een nieuwe testauto nodig! Wij passen niet meer in het huidige.
MCH: - Wat heb je nu?
MM: – Nu – 130 NVP's en een processor die klaar is voor gebruik.
MCH: - Wauw! Koel! Wacht, ik heb twee vragen. Volgens mijn berekeningen hebben we ongeveer 15-20 meetgegevens per seconde nodig. Waarom hebben we meer nodig?
MM: “Ik wil de klus afmaken.” Ik zou graag willen zien hoeveel we uit dit systeem kunnen halen.
MCH: - Maar…
MM: “Maar het is nutteloos voor het bedrijfsleven.”
MCH: - Het is duidelijk. En de tweede vraag: kunnen we wat we nu hebben zelf ondersteunen, zonder hulp van een ontwikkelaar?
MM: - Ik denk het niet. Het wijzigen van de manier waarop de configuratiecache werkt, is een probleem. Het beïnvloedt veranderingen in de meeste threads en is vrij moeilijk te onderhouden. Hoogstwaarschijnlijk zal het erg moeilijk zijn om het te onderhouden.
MCH: “Dan hebben we een alternatief nodig.”
MM: - Er is zo'n optie. We kunnen overstappen op snelle kernen, terwijl we het nieuwe sluitsysteem achterwege laten. We krijgen nog steeds een prestatie van 60-80 duizend statistieken. Tegelijkertijd kunnen we de rest van de code achterlaten. Clickhouse en asynchrone polling zullen werken. En het zal gemakkelijk te onderhouden zijn.
MCH: - Verbazingwekkend! Ik stel voor dat we hier stoppen.
Na het optimaliseren van de serverkant konden we eindelijk de nieuwe code in productie nemen. We hebben een aantal veranderingen opgegeven ten gunste van het overstappen naar een machine met snelle cores en het minimaliseren van het aantal codewijzigingen. We hebben ook de configuratie vereenvoudigd en waar mogelijk macro's in gegevensitems geëlimineerd, omdat ze extra vergrendeling introduceren.
Door bijvoorbeeld de snmp-community-macro, die vaak in documentatie en voorbeelden wordt aangetroffen, achterwege te laten, werd het in ons geval mogelijk om NVP's met ongeveer 1,5 keer verder te versnellen.
Na twee dagen in productie
Pop-ups van de incidentgeschiedenis verwijderen
MCH: – Misha, we gebruiken het systeem nu twee dagen en alles werkt. Maar alleen als alles werkt! We hadden gepland werk met de overdracht van een vrij groot deel van het netwerk, en we hebben opnieuw met onze handen gecontroleerd wat er wel en niet ging.
MM: - Dat kan niet! We hebben alles 10 keer gecontroleerd. De server verwerkt zelfs volledige netwerkonbeschikbaarheid onmiddellijk.
MCH: - Ja, ik begrijp alles: server, database, top, austat, logs - alles is snel... Maar we kijken naar de webinterface, en er staat een processor “in de plank” op de server en dit:
MM: - Het is duidelijk. Laten we naar het internet kijken. We ontdekten dat in een situatie waarin er een groot aantal actieve incidenten waren, de meeste live-widgets erg langzaam begonnen te werken:
De reden hiervoor was het genereren van pop-ups met incidentgeschiedenis die voor elk item in de lijst worden gegenereerd. Daarom hebben we het genereren van deze vensters stopgezet (met commentaar op 5 regels in de code), en dit loste onze problemen op.
De laadtijd voor widgets, zelfs als ze volledig niet beschikbaar zijn, is teruggebracht van enkele minuten naar de voor ons acceptabele 10-15 seconden, en de geschiedenis kan nog steeds worden bekeken door op de tijd te klikken:
Na het werk. 2 maanden geleden
MCH: - Misha, ga je weg? We moeten praten.
MM: - Dat was ik niet van plan. Weer iets met Zabbix?
MCH: - Nee, ontspan! Ik wilde alleen maar zeggen: alles werkt, bedankt! Ik heb een biertje.
Zabbix is efficiënt
Zabbix is een redelijk universeel en rijk systeem en functie. Het kan kant-en-klaar worden gebruikt voor kleine installaties, maar naarmate de behoeften toenemen, moet het worden geoptimaliseerd. Als u een groot archief met statistieken wilt opslaan, gebruikt u een geschikte opslag:
- je kunt gebruik maken van ingebouwde tools in de vorm van integratie met Elasticsearch of het uploaden van geschiedenis naar tekstbestanden (beschikbaar vanaf versie 4);
- U kunt profiteren van onze ervaring en integratie met Clickhouse.
Om de snelheid van het verzamelen van statistieken dramatisch te verhogen, verzamelt u ze met behulp van asynchrone methoden en verzendt u ze via de trapper-interface naar de Zabbix-server; of je kunt een patch gebruiken om Zabbix-pollers asynchroon te maken.
Zabbix is geschreven in C en is behoorlijk efficiënt. Door verschillende architecturale knelpunten op te lossen, kunt u de prestaties verder verbeteren en, naar onze ervaring, meer dan 100 meetgegevens verkrijgen op een machine met één processor.
Dezelfde Zabbix-patch
MM: – Ik wil een paar punten toevoegen. Het volledige huidige rapport, alle tests, cijfers worden gegeven voor de configuratie die we gebruiken. We halen er nu ongeveer 20 meetgegevens per seconde uit. Als u probeert te begrijpen of dit voor u werkt, kunt u vergelijken. Wat vandaag werd besproken, wordt in de vorm van een patch op GitHub geplaatst:
De pleister bevat:
- volledige integratie met Clickhouse (zowel Zabbix-server als frontend);
- het oplossen van problemen met de preprocessormanager;
- asynchrone polling.
De patch is compatibel met alle versie 4, inclusief lts. Hoogstwaarschijnlijk zal het met minimale wijzigingen werken op versie 3.4.
Dank u voor uw aandacht.
vragen
Vraag uit het publiek (hierna – A): – Goedemiddag! Vertel me alsjeblieft, heb je plannen voor intensieve interactie met het Zabbix-team of met hen met jou, zodat dit geen patch is, maar normaal gedrag van Zabbix?
MM: – Ja, we zullen zeker een aantal van de veranderingen doorvoeren. Er zal iets gebeuren, er zal iets in de patch blijven.
A: – Hartelijk dank voor het uitstekende rapport! Vertel me alstublieft dat na het toepassen van de patch de ondersteuning van Zabbix blijft bestaan en hoe ik kan blijven updaten naar hogere versies? Is het mogelijk om Zabbix na uw patch te updaten naar 4.2, 5.0?
MM: – Ik kan niets zeggen over ondersteuning. Als ik de technische ondersteuning van Zabbix was, zou ik waarschijnlijk nee zeggen, omdat dit de code van iemand anders is. Wat de codebase 4.2 betreft, is ons standpunt: “We zullen met de tijd meegaan en we zullen onszelf updaten met de volgende versie.” Daarom zullen we enige tijd een patch voor bijgewerkte versies publiceren. Ik zei al in het rapport: het aantal wijzigingen bij versies is nog steeds vrij klein. Ik denk dat de overgang van 3.4 naar 4 ons ongeveer 15 minuten heeft gekost, daar is iets veranderd, maar niet heel belangrijk.
A: – Dus u bent van plan uw patch te ondersteunen en deze veilig in productie te installeren en in de toekomst op een of andere manier updates te ontvangen?
MM: – Wij raden het ten zeerste aan. Dit lost voor ons veel problemen op.
MCH: – Ik wil nogmaals de aandacht vestigen op het feit dat de veranderingen die geen betrekking hebben op de architectuur en die geen betrekking hebben op blokkeringen of wachtrijen modulair zijn, ze bevinden zich in afzonderlijke modules. Zelfs met kleine wijzigingen kun je ze vrij eenvoudig onderhouden.
MM: – Bent u geïnteresseerd in de details, dan maakt “Clickhouse” gebruik van de zogenaamde geschiedenisbibliotheek. Het is ongebonden - het is een kopie van de Elastics-ondersteuning, dat wil zeggen dat het configureerbaar is. Polling verandert alleen opiniepeilers. Wij geloven dat dit voor een lange tijd zal werken.
A: - Hartelijk bedankt. Vertel me eens: is er documentatie over de aangebrachte wijzigingen?
MM: – Documentatie is een patch. Het is duidelijk dat er met de introductie van Clickhouse, met de introductie van nieuwe soorten pollers, nieuwe configuratiemogelijkheden ontstaan. De link van de laatste dia bevat een korte beschrijving van hoe u deze kunt gebruiken.
Over het vervangen van fping door nmap
A: – Hoe heb je dit uiteindelijk geïmplementeerd? Kun je concrete voorbeelden geven: heb je strappers en een extern script? Wat zorgt ervoor dat zo’n groot aantal hosts zo snel wordt gecontroleerd? Hoe mineer je deze hosts? Moeten we ze op de een of andere manier naar nmap voeren, ze ergens vandaan halen, erin stoppen, iets uitvoeren?
MM: - Koel. Een zeer correcte vraag! Het punt is dit. We hebben de bibliotheek (ICMP-ping, onderdeel van Zabbix) aangepast voor ICMP-controles, die het aantal pakketten aangeven - één (1), en de code probeert nmap te gebruiken. Dat wil zeggen, dit is het interne werk van Zabbix, dat het interne werk van de pinger is geworden. Dienovereenkomstig is er geen synchronisatie of gebruik van een trapper vereist. Dit is bewust gedaan om het systeem intact te laten en niet te maken te krijgen met de synchronisatie van twee databasesystemen: wat te controleren, uploaden via de poller, en is onze upload kapot?.. Dit is veel eenvoudiger.
A: – Werkt het ook voor proxy's?
MM: – Ja, maar dat hebben we niet gecontroleerd. De pollingcode is hetzelfde in zowel Zabbix als de server. Zou moeten werken. Laat ik nogmaals benadrukken: de prestaties van het systeem zijn zodanig dat we geen proxy nodig hebben.
MCH: – Het juiste antwoord op de vraag is: “Waarom heb je bij zo’n systeem een proxy nodig?” Alleen vanwege NAT of monitoring via een langzaam kanaal...
A: – En je gebruikt Zabbix als allortor, als ik het goed begrijp. Of uw graphics (waar de archieflaag op zit) laten verhuizen naar een ander systeem, zoals Grafana? Of maakt u geen gebruik van deze functionaliteit?
MM: – Ik wil nogmaals benadrukken: we hebben volledige integratie bereikt. We gieten geschiedenis in Clickhouse, maar tegelijkertijd hebben we de php-frontend veranderd. De Php-frontend gaat naar Clickhouse en doet vanaf daar alle grafische afbeeldingen. Tegelijkertijd hebben we, om eerlijk te zijn, een onderdeel dat gegevens bouwt in andere grafische weergavesystemen uit hetzelfde Clickhouse, uit dezelfde Zabbix-gegevens.
MCH: – Ook in “Grafan”.
Hoe werden beslissingen genomen over de toewijzing van middelen?
A: – Deel een stukje van je innerlijke keuken. Hoe werd besloten dat het nodig was om middelen toe te wijzen voor een serieuze verwerking van het product? Dit zijn over het algemeen bepaalde risico's. En vertel mij alstublieft, in de context van het feit dat u nieuwe versies gaat steunen: hoe rechtvaardigt deze beslissing vanuit managementoogpunt?
MM: – Blijkbaar hebben we het drama van de geschiedenis niet zo goed verteld. We bevonden ons in een situatie waarin er iets moest gebeuren, en we werkten feitelijk met twee parallelle teams:
- Eén daarvan was het lanceren van een monitoringsysteem met nieuwe methoden: monitoring as a service, een standaardset van open source-oplossingen die we combineren en vervolgens proberen het bedrijfsproces te veranderen om met het nieuwe monitoringsysteem te kunnen werken.
- Tegelijkertijd hadden we een enthousiaste programmeur die dit deed (over zichzelf). Het gebeurde zo dat hij won.
A: – En hoe groot is het team?
MCH: - Ze staat voor je.
A: – Dus, zoals altijd, heb je een passioneel nodig?
MM: – Ik weet niet wat een passioneel is.
A: - In dit geval blijkbaar jij. Heel erg bedankt, je bent geweldig.
MM: - Bedankt.
Over patches voor Zabbix
A: – Is het voor een systeem dat proxy's gebruikt (bijvoorbeeld in sommige gedistribueerde systemen) mogelijk om bijvoorbeeld pollers, proxy's en gedeeltelijk de preprocessor van Zabbix zelf aan te passen en te patchen; en hun interactie? Is het mogelijk om bestaande ontwikkelingen te optimaliseren voor een systeem met meerdere proxy's?
MM: – Ik weet dat de Zabbix-server is samengesteld met behulp van een proxy (de code is gecompileerd en verkregen). We hebben dit niet in productie getest. Ik ben hier niet zeker van, maar ik denk dat de preprocessormanager niet in de proxy wordt gebruikt. De taak van de proxy is om een reeks statistieken van Zabbix te halen, deze samen te voegen (deze registreert ook de configuratie, de lokale database) en deze terug te geven aan de Zabbix-server. De server zal dan zelf de voorbewerking uitvoeren wanneer hij deze ontvangt.
De belangstelling voor proxy's is begrijpelijk. We zullen het bekijken. Dit is een interessant onderwerp.
A: – Het idee was dit: als je pollers kunt patchen, kun je ze op de proxy patchen en de interactie met de server patchen, en de preprocessor alleen voor deze doeleinden op de server aanpassen.
MM: – Ik denk dat het nog eenvoudiger is. U neemt de code, past een patch toe en configureert deze vervolgens zoals u dat wilt: verzamel proxyservers (bijvoorbeeld met ODBC) en distribueer de gepatchte code over systemen. Waar nodig - verzamel een proxy, waar nodig - een server.
A: – Hoogstwaarschijnlijk hoeft u de proxy-overdracht naar de server niet extra te patchen?
MCH: - Nee, het is standaard.
MM: – In feite klonk een van de ideeën niet. We hebben altijd een evenwicht weten te bewaren tussen de explosie aan ideeën en de hoeveelheid veranderingen en het gemak van ondersteuning.
Sommige advertenties 🙂
Bedankt dat je bij ons bent gebleven. Vind je onze artikelen leuk? Wil je meer interessante inhoud zien? Steun ons door een bestelling te plaatsen of door vrienden aan te bevelen, , een unieke analoog van servers op instapniveau, die door ons voor u is uitgevonden: (beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV datacenter in Amsterdam? Alleen hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees over
Bron: www.habr.com