La propera conferència HighLoad++ se celebrarà els dies 6 i 7 d'abril de 2020 a Sant Petersburg Detalls i entrades . HighLoad++ Moscou 2018. Sala “Moscou”. 9 de novembre, 15:00 h. Tesis i .
* Monitorització - en línia i anàlisi.
* Limitacions bàsiques de la plataforma ZABBIX.
* Solució per escalar l'emmagatzematge analític.
* Optimització del servidor ZABBIX.
* Optimització de la interfície d'usuari.
* Experiència operant el sistema amb càrregues de més de 40k NVPS.
* Breus conclusions.
Mikhail Makurov (d'ara endavant – MM): - Hola a tots!
Maxim Chernetsov (d'ara endavant - MCH): - Bona tarda!
MM: - Deixa'm presentar-me a Maxim. Max és un enginyer amb talent, el millor networker que conec. Maxim està involucrat en xarxes i serveis, el seu desenvolupament i funcionament.
MCH: – I m'agradaria parlar-te de Mikhail. Mikhail és un desenvolupador C. Va escriure diverses solucions de processament de trànsit d'alta càrrega per a la nostra empresa. Vivim i treballem als Urals, a la ciutat dels homes durs Chelyabinsk, a l'empresa Intersvyaz. La nostra empresa és un proveïdor de serveis d'Internet i televisió per cable per a un milió de persones en 16 ciutats.
MM: – I val la pena dir que Intersvyaz és molt més que un proveïdor, és una empresa informàtica. La majoria de les nostres solucions les fa el nostre departament d'informàtica.
R: des de servidors que processen trànsit fins a un centre de trucades i aplicació mòbil. El departament informàtic compta ara amb unes 80 persones amb competències molt i molt diverses.
Sobre Zabbix i la seva arquitectura
MCH: – I ara intentaré establir un rècord personal i dir en un minut què és Zabbix (d'ara endavant "Zabbix").
Zabbix es posiciona com un sistema de monitorització precoç a nivell empresarial. Té moltes funcions que faciliten la vida: regles d'escalada avançades, API per a la integració, agrupació i detecció automàtica d'amfitrions i mètriques. Zabbix té les anomenades eines d'escala: proxies. Zabbix és un sistema de codi obert.
Breument sobre arquitectura. Podem dir que consta de tres components:
- Servidor. Escrit en C. Amb un processament bastant complex i transferència d'informació entre fils. S'hi realitza tot el processament: des de la recepció fins al desament a la base de dades.
- Totes les dades s'emmagatzemen a la base de dades. Zabbix és compatible amb MySQL, PostreSQL i Oracle.
- La interfície web està escrita en PHP. A la majoria de sistemes ve amb un servidor Apache, però funciona de manera més eficient en combinació amb nginx + php.
Avui ens agradaria explicar una història de la vida de la nostra empresa relacionada amb Zabbix...
Una història de la vida de l'empresa Intersvyaz. Què tenim i què necessitem?
Fa 5 o 6 mesos. Un dia després de la feina...
MCH: - Misha, hola! M'alegro d'haver aconseguit atrapar-te, hi ha una conversa. Vam tornar a tenir problemes amb el seguiment. Durant un accident important, tot va anar lent i no hi havia informació sobre l'estat de la xarxa. Malauradament, aquesta no és la primera vegada que passa això. Necessito la teva ajuda. Fem que el nostre seguiment funcioni sota qualsevol circumstància!
MM: - Però primer sincronitzem. Fa un parell d'anys que no hi busco. Pel que recordo, vam abandonar Nagios i vam canviar a Zabbix fa uns 8 anys. I ara sembla que tenim 6 servidors potents i una dotzena de servidors intermediaris. Estic confonent alguna cosa?
MCH: - Gairebé. 15 servidors, alguns dels quals són màquines virtuals. El més important és que no ens salva en el moment que més ho necessitem. Com un accident: els servidors s'alenteixen i no es veu res. Hem intentat optimitzar la configuració, però això no va proporcionar l'augment de rendiment òptim.
MM: - Està clar. Has mirat alguna cosa, ja has descobert alguna cosa del diagnòstic?
MCH: – El primer que has de tractar és la base de dades. MySQL es carrega constantment, emmagatzemant noves mètriques i, quan Zabbix comença a generar un munt d'esdeveniments, la base de dades s'encarrega literalment unes quantes hores. Ja us he parlat de l'optimització de la configuració, però literalment aquest any han actualitzat el maquinari: els servidors tenen més de cent gigabytes de memòria i matrius de discs en SSD RAID, no té sentit fer-ho créixer de manera lineal a llarg termini. Què fem?
MM: - Està clar. En general, MySQL és una base de dades LTP. Pel que sembla, ja no és adequat per emmagatzemar un arxiu de mètriques de la nostra mida. Anem a esbrinar-ho.
MCH: - Anem!
Integració de Zabbix i Clickhouse com a resultat del hackathon
Al cap d'un temps vam rebre dades interessants:
La major part de l'espai de la nostra base de dades estava ocupada per l'arxiu de mètriques i menys de l'1% es va utilitzar per a la configuració, les plantilles i la configuració. En aquell moment, havíem estat operant la solució de Big Data basada en Clickhouse durant més d'un any. La direcció del moviment era evident per a nosaltres. A la nostra Hackathon de primavera, vaig escriure la integració de Zabbix amb Clickhouse per al servidor i la interfície. En aquell moment, Zabbix ja tenia suport per a ElasticSearch i vam decidir comparar-los.
Comparació de Clickhouse i Elasticsearch
MM: – Per comparar, vam generar la mateixa càrrega que proporciona el servidor Zabbix i vam mirar com es comportarien els sistemes. Vam escriure dades en lots de 1000 línies, utilitzant CURL. Vam suposar per endavant que Clickhouse seria més eficient per al perfil de càrrega que fa Zabbix. Els resultats fins i tot van superar les nostres expectatives:
En les mateixes condicions de prova, Clickhouse va escriure tres vegades més dades. Al mateix temps, ambdós sistemes consumien de manera molt eficient (una petita quantitat de recursos) en llegir les dades. Però Elastics va requerir una gran quantitat de processador a l'hora de gravar:
En total, Clickhouse va ser significativament superior a Elastix pel que fa a consum de processador i velocitat. Al mateix temps, a causa de la compressió de dades, Clickhouse utilitza 11 vegades menys al disc dur i realitza aproximadament 30 vegades menys operacions de disc:
MCH: – Sí, el treball de Clickhouse amb el subsistema de disc s'implementa de manera molt eficient. Podeu utilitzar grans discos SATA per a bases de dades i obtenir velocitats d'escriptura de centenars de milers de línies per segon. El sistema predefinit admet fragmentació, rèplica i és molt fàcil de configurar. Estem més que satisfets amb el seu ús durant tot l'any.
Per optimitzar els recursos, podeu instal·lar Clickhouse al costat de la vostra base de dades principal existent i, per tant, estalviar molt temps de CPU i operacions de disc. Hem traslladat l'arxiu de mètriques als clústers de Clickhouse existents:
Vam alleujar tant la base de dades MySQL principal que podríem combinar-la en una màquina amb el servidor Zabbix i abandonar el servidor dedicat per a MySQL.
Com funcionen les enquestes a Zabbix?
Fa 4 mesos
MM: – Bé, ens podem oblidar dels problemes amb la base?
MCH: - Això és segur! Un altre problema que hem de resoldre és la recollida lenta de dades. Ara tots els nostres 15 servidors intermediaris estan sobrecarregats amb SNMP i processos de votació. I no hi ha altra manera que instal·lar servidors nous i nous.
MM: - Genial. Però primer, digueu-nos com funcionen les enquestes a Zabbix?
MCH: – En resum, hi ha 20 tipus de mètriques i una dotzena de maneres d'obtenir-les. Zabbix pot recollir dades en el mode "sol·licitud-resposta" o esperar dades noves mitjançant la "Interfície Trapper".
Val la pena assenyalar que al Zabbix original aquest mètode (Trapper) és el més ràpid.
Hi ha servidors proxy per a la distribució de càrrega:
Els servidors intermediaris poden realitzar les mateixes funcions de recollida que el servidor Zabbix, rebent tasques d'aquest i enviant les mètriques recopilades a través de la interfície Trapper. Aquesta és la forma recomanada oficialment de distribuir la càrrega. Els servidors intermediaris també són útils per supervisar la infraestructura remota que funciona mitjançant NAT o un canal lent:
MM: – Tot és clar amb l'arquitectura. Hem de mirar les fonts...
Un parell de dies després
La història de com nmap fping va guanyar
MM: "Crec que he desenterrat alguna cosa".
MCH: - Digues-me!
MM: – Vaig descobrir que en comprovar la disponibilitat, Zabbix comprova un màxim de 128 amfitrions alhora. Vaig provar d'augmentar aquest nombre a 500 i eliminar l'interval entre paquets del seu ping (ping), això va duplicar el rendiment. Però m'agradaria un nombre més gran.
MCH: – A la meva pràctica, de vegades he de comprovar la disponibilitat de milers d'amfitrions, i mai he vist res més ràpid que nmap per a això. Estic segur que aquesta és la manera més ràpida. Anem a provar-ho! Hem d'augmentar significativament el nombre d'amfitrions per iteració.
MM: – Comprovar més de cinc-cents? 600?
MCH: - Almenys un parell de milers.
MM: - D'ACORD. El més important que volia dir és que vaig trobar que la majoria de les enquestes a Zabbix es fan de manera sincrònica. Definitivament hem de canviar-lo al mode asíncron. Aleshores podem augmentar dràsticament el nombre de mètriques recollides pels enquestadors, sobretot si augmentem el nombre de mètriques per iteració.
MCH: - Genial! I quan?
MM: – Com sempre, ahir.
MCH: – Hem comparat les dues versions de fping i nmap:
En un gran nombre d'amfitrions, s'esperava que nmap fos fins a cinc vegades més efectiu. Com que nmap només comprova la disponibilitat i el temps de resposta, vam traslladar el càlcul de les pèrdues als activadors i vam reduir significativament els intervals de comprovació de la disponibilitat. Hem trobat que el nombre òptim d'amfitrions per a nmap és d'uns 4 mil per iteració. Nmap ens va permetre reduir el cost de la CPU de les comprovacions de disponibilitat en tres vegades i reduir l'interval de 120 segons a 10.
Optimització de la votació
MM: “Després vam començar a fer enquestes. Ens interessava principalment la detecció i els agents SNMP. A Zabbix, les votacions es fan de manera sincrònica i s'han pres mesures especials per augmentar l'eficiència del sistema. En mode síncron, la indisponibilitat de l'amfitrió provoca una degradació important de l'enquesta. Hi ha tot un sistema d'estats, hi ha processos especials: els anomenats enquestadors inabastables, que només funcionen amb amfitrions inabastables:
Aquest és un comentari que demostra la matriu d'estats, tota la complexitat del sistema de transicions que es requereix perquè el sistema segueixi sent efectiu. A més, l'enquesta síncrona és bastant lenta:
És per això que milers de fluxos d'enquestadors de desenes de servidors intermediaris no van poder recollir la quantitat de dades necessària per a nosaltres. La implementació asíncrona no només va resoldre els problemes amb el nombre de fils, sinó que també va simplificar significativament el sistema d'estat dels amfitrions no disponibles, perquè per a qualsevol nombre comprovat en una iteració d'enquesta, el temps d'espera màxim era d'1 temps d'espera:
A més, hem modificat i millorat el sistema de votació per a les sol·licituds SNMP. El fet és que la majoria de la gent no pot respondre a diverses sol·licituds SNMP alhora. Per tant, vam fer un mode híbrid, quan l'enquesta SNMP del mateix host es fa de manera asíncrona:
Això es fa per a tot el paquet d'amfitrions. En última instància, aquest mode no és més lent que un de completament asíncron, ja que l'enquesta d'un centenar i mig de valors SNMP encara és molt més ràpid que 1 temps d'espera.
Els nostres experiments han demostrat que el nombre òptim de sol·licituds en una iteració és d'aproximadament 8 mil amb l'enquesta SNMP. En total, la transició al mode asíncron ens va permetre accelerar el rendiment de les enquestes en 200 vegades, diversos centenars de vegades.
MCH: – Les optimitzacions de sondeig resultants van demostrar que no només podem desfer-nos de tots els proxies, sinó que també podem reduir els intervals de moltes comprovacions i que els proxys ja no seran necessaris com a forma de compartir la càrrega.
Fa uns tres mesos
Canvia l'arquitectura - augmenta la càrrega!
MM: - Bé, Max, és hora de ser productiu? Necessito un servidor potent i un bon enginyer.
MCH: - D'acord, planifiquem-ho. Ja és hora de passar del punt mort de 5 mil mètriques per segon.
Al matí després de l'actualització
MCH: - Misha, ens hem actualitzat, però al matí hem fet marxa enrere... Endevineu quina velocitat hem aconseguit?
MM: – 20 mil màxim.
MCH: - Sí, 25! Malauradament, estem just on vam començar.
MM: - Per què? Has fet algun diagnòstic?
MCH: - Si, es clar! Aquí, per exemple, hi ha un top interessant:
MM: - Anem a mirar. Veig que hem provat un gran nombre de fils d'enquesta:
Però al mateix temps no van poder reciclar el sistema ni a la meitat:
I el rendiment general és bastant petit, unes 4 mil mètriques per segon:
Hi ha alguna cosa més?
MCH: – Sí, traça d'un dels enquestadors:
MM: – Aquí podeu veure clarament que el procés de votació està esperant “semàfors”. Aquests són els panys:
MCH: - Poc clar.
MM: – Mira, això és semblant a una situació en què un munt de fils intenten treballar amb recursos amb els quals només un pot treballar alhora. Aleshores, tot el que poden fer és compartir aquest recurs al llarg del temps:
I el rendiment total de treballar amb aquest recurs està limitat per la velocitat d'un nucli:
Hi ha dues maneres de resoldre aquest problema.
Actualitzeu el maquinari de la màquina, canvieu a nuclis més ràpids:
O canvieu l'arquitectura i al mateix temps canvieu la càrrega:
MCH: – Per cert, a la màquina de prova utilitzarem menys nuclis que a la de combat, però són 1,5 vegades més ràpids en freqüència per nucli!
MM: - Clar? Heu de mirar el codi del servidor.
Camí de dades al servidor Zabbix
MCH: – Per esbrinar-ho, vam començar a analitzar com es transfereixen les dades dins del servidor Zabbix:
Una imatge fantàstica, oi? Repassem-ho pas a pas per deixar-ho més o menys clar. Hi ha fils i serveis responsables de la recollida de dades:
Transmeten les mètriques recollides mitjançant un sòcol al gestor del preprocessador, on es guarden en una cua:
El "gestor del preprocessador" transmet dades als seus treballadors, que executen instruccions de preprocessament i les retornen a través del mateix sòcol:
Després d'això, el gestor del preprocessador els emmagatzema a la memòria cau de l'historial:
A partir d'aquí, els prenen els sinkers de l'historial, que fan un munt de funcions: per exemple, calcular activadors, omplir la memòria cau de valors i, el més important, desar mètriques a l'emmagatzematge de l'historial. En general, el procés és complex i molt confús.
MM: – El primer que vam veure va ser que la majoria de fils competeixen per l'anomenada “caché de configuració” (l'àrea de memòria on s'emmagatzemen totes les configuracions del servidor). Els fils responsables de la recopilació de dades fan especialment un gran bloqueig:
...ja que la configuració no només emmagatzema mètriques amb els seus paràmetres, sinó també cues de les quals els enquestadors prenen informació sobre què fer a continuació. Quan hi ha molts enquestadors i un bloqueja la configuració, els altres esperen les peticions:
Els enquestadors no haurien de entrar en conflicte
Per tant, el primer que vam fer va ser dividir la cua en 4 parts i permetre als enquestadors bloquejar aquestes cues, aquestes parts al mateix temps, en condicions de seguretat:
Això va eliminar la competència per a la memòria cau de configuració i la velocitat dels enquestadors va augmentar significativament. Però aleshores ens vam trobar amb el fet que el gestor del preprocessador va començar a acumular una cua de treballs:
El gestor del preprocessador ha de poder prioritzar
Això passava en els casos en què li faltava rendiment. Aleshores, tot el que podia fer era acumular sol·licituds dels processos de recollida de dades i sumar-ne el buffer fins que consumís tota la memòria i s'estavellava:
Per solucionar aquest problema, hem afegit un segon sòcol dedicat específicament als treballadors:
Així, el responsable del preprocessador va tenir l'oportunitat de prioritzar el seu treball i, si el buffer creix, la tasca és frenar l'eliminació, donant l'oportunitat als treballadors d'agafar aquest buffer:
Aleshores vam descobrir que un dels motius de la desacceleració eren els mateixos treballadors, ja que competien per un recurs que no tenia importància per a la seva feina. Hem documentat aquest problema com a correcció d'errors i ja s'ha resolt a les noves versions de Zabbix:
Augmentem el nombre de sòcols: obtenim el resultat
A més, el mateix gestor del preprocessador es va convertir en un coll d'ampolla, ja que és un fil. Es basava en la velocitat del nucli, donant una velocitat màxima d'uns 70 mil mètriques per segon:
Per tant, vam fer quatre treballadors, amb quatre jocs d'endolls:
I això ens va permetre augmentar la velocitat a aproximadament 130 mil mètriques:
La no linealitat del creixement s'explica pel fet que ha aparegut la competència per la memòria cau de la història. 4 gestors de preprocessadors i sinkers de la història van competir per això. En aquest moment, estàvem rebent aproximadament 130 mil mètriques per segon a la màquina de prova, utilitzant-la aproximadament el 95% del processador:
Fa uns 2,5 mesos
La negativa de la comunitat snmp va augmentar les NVP una vegada i mitja
MM: – Max, necessito un cotxe de prova nou! Ja no encaixem en l'actual.
MCH: - Què tens ara?
MM: – Ara: 130 NVP i un processador preparat per a la prestatgeria.
MCH: - Vaja! Guai! Espera, tinc dues preguntes. Segons els meus càlculs, la nostra necessitat és d'uns 15-20 mil mètriques per segon. Per què necessitem més?
MM: "Vull acabar la feina". M'agradaria veure quant podem treure d'aquest sistema.
MCH: - Però…
MM: "Però és inútil per als negocis".
MCH: - Està clar. I la segona pregunta: podem donar suport al que tenim ara sols, sense l'ajuda d'un desenvolupador?
MM: - No crec. Canviar com funciona la memòria cau de configuració és un problema. Afecta els canvis en la majoria de fils i és bastant difícil de mantenir. Molt probablement, serà molt difícil mantenir-lo.
MCH: "Llavors necessitem algun tipus d'alternativa".
MM: - Hi ha una opció així. Podem canviar a nuclis ràpids, mentre abandonem el nou sistema de bloqueig. Encara tindrem un rendiment de 60-80 mil mètriques. Al mateix temps, podem deixar tota la resta del codi. Clickhouse i l'enquesta asíncrona funcionaran. I serà fàcil de mantenir.
MCH: - Increïble! Suggereixo que ens aturem aquí.
Després d'optimitzar el costat del servidor, finalment vam poder llançar el nou codi en producció. Vam abandonar alguns dels canvis a favor de canviar a una màquina amb nuclis ràpids i minimitzar el nombre de canvis de codi. També hem simplificat la configuració i hem eliminat les macros dels elements de dades quan és possible, ja que introdueixen un bloqueig addicional.
Per exemple, l'abandonament de la macro snmp-community, que es troba sovint a la documentació i als exemples, en el nostre cas va permetre accelerar encara més els NVP aproximadament 1,5 vegades.
Després de dos dies en producció
Eliminació de finestres emergents de l'historial d'incidències
MCH: – Misha, portem dos dies utilitzant el sistema i tot funciona. Però només quan tot funciona! Teníem previst treballar amb la transferència d'un segment força gran de la xarxa, i vam tornar a comprovar amb les mans què passava i què no.
MM: - No pot ser! Ho vam comprovar tot 10 vegades. El servidor gestiona fins i tot la indisponibilitat total de la xarxa a l'instant.
MCH: - Sí, ho entenc tot: servidor, base de dades, top, austat, registres - tot és ràpid... Però mirem la interfície web, i hi ha un processador "al prestatge" al servidor i això:
MM: - Està clar. Mirem la web. Hem trobat que en una situació en què hi havia un gran nombre d'incidents actius, la majoria dels ginys en directe van començar a funcionar molt lentament:
El motiu d'això va ser la generació de finestres emergents d'historial d'incidències que es generen per a cada element de la llista. Per tant, vam abandonar la generació d'aquestes finestres (comentades 5 línies al codi), i això va resoldre els nostres problemes.
El temps de càrrega dels ginys, fins i tot quan no estan completament disponibles, s'ha reduït de diversos minuts als 10-15 segons acceptables per a nosaltres, i l'historial encara es pot veure fent clic a l'hora:
Després de la feina. 2 mesos enrere
MCH: - Misha, te'n vas? Hem de parlar.
MM: - No tenia intenció. Alguna cosa amb Zabbix de nou?
MCH: - No, relaxa't! Només volia dir: tot funciona, gràcies! Tinc una cervesa.
Zabbix és eficient
Zabbix és un sistema i una funció força universals i rics. Es pot utilitzar per a petites instal·lacions fora de la caixa, però a mesura que creixen les necessitats, s'ha d'optimitzar. Per emmagatzemar un gran arxiu de mètriques, utilitzeu un emmagatzematge adequat:
- podeu utilitzar eines integrades en forma d'integració amb Elasticsearch o de càrrega de l'historial a fitxers de text (disponible a partir de la versió XNUMX);
- Pots aprofitar la nostra experiència i integració amb Clickhouse.
Per augmentar dràsticament la velocitat de recollida de mètriques, recolliu-les mitjançant mètodes asíncrons i transmeteu-les a través de la interfície del trapper al servidor Zabbix; o podeu utilitzar un pedaç per fer que els enquestadors de Zabbix siguin asíncrons.
Zabbix està escrit en C i és bastant eficient. La resolució de diversos colls d'ampolla arquitectònics permet augmentar encara més el seu rendiment i, segons la nostra experiència, obtenir més de 100 mil mètriques en una màquina d'un sol processador.
El mateix pegat de Zabbix
MM: – Vull afegir un parell de punts. Tot l'informe actual, totes les proves i números es donen per a la configuració que fem servir. Ara estem agafant aproximadament 20 mil mètriques per segon. Si esteu intentant entendre si això us funcionarà, podeu comparar. El que s'ha comentat avui es publica a GitHub en forma de pedaç:
El pegat inclou:
- integració completa amb Clickhouse (tant el servidor Zabbix com la interfície);
- resoldre problemes amb el gestor del preprocessador;
- enquesta asíncrona.
El pegat és compatible amb totes les versions 4, inclòs lts. El més probable és que amb canvis mínims funcionarà a la versió 3.4.
Gràcies per la seva atenció.
Les vostres preguntes
Pregunta del públic (d'ara endavant – A): – Bona tarda! Si us plau, digueu-me, teniu plans per a una interacció intensa amb l'equip de Zabbix o amb ells amb vosaltres, perquè això no sigui un pedaç, sinó un comportament normal de Zabbix?
MM: – Sí, segur que cometrem alguns dels canvis. Alguna cosa passarà, alguna cosa romandrà al pegat.
R: – Moltes gràcies per l'excel·lent informe! Si us plau, digueu-me, després d'aplicar el pedaç, el suport de Zabbix es mantindrà i com continuar amb l'actualització a versions superiors? Serà possible actualitzar Zabbix després del pedaç a 4.2, 5.0?
MM: - No puc dir res del suport. Si jo fos el suport tècnic de Zabbix, probablement diria que no, perquè aquest és el codi d'una altra persona. Pel que fa a la base de codi 4.2, la nostra posició és: "Ens mourem amb el temps i ens actualitzarem a la propera versió". Per tant, durant algun temps publicarem un pedaç per a les versions actualitzades. Ja ho vaig dir a l'informe: el nombre de canvis amb versions encara és força petit. Crec que la transició del 3.4 al 4 ens ha portat uns 15 minuts, hi ha alguna cosa que ha canviat, però poc important.
R: – Per tant, teniu previst donar suport al vostre pedaç i podeu instal·lar-lo de manera segura en producció i rebre actualitzacions d'alguna manera en el futur?
MM: - Ho recomanem fortament. Això ens resol molts problemes.
MCH: – Un cop més, voldria cridar l'atenció sobre el fet que els canvis que no afecten l'arquitectura i no afecten al bloqueig o a les cues són modulars, es troben en mòduls separats. Fins i tot amb canvis menors, podeu mantenir-los amb força facilitat.
MM: – Si esteu interessats en els detalls, aleshores "Clickhouse" utilitza l'anomenada biblioteca d'història. Està deslligat: és una còpia del suport Elastics, és a dir, és configurable. Les enquestes només canvien els enquestadors. Creiem que això funcionarà durant molt de temps.
R: - Moltes gràcies. Digueu-me, hi ha documentació dels canvis fets?
MM: – La documentació és un pedaç. Evidentment, amb la introducció de Clickhouse, amb la introducció de nous tipus de pollers, sorgeixen noves opcions de configuració. L'enllaç de l'última diapositiva té una breu descripció de com utilitzar-lo.
Sobre la substitució de fping per nmap
R: – Com ho vas implementar finalment? Pots posar exemples concrets: tens corretges i un guió extern? Què acaba comprovant un nombre tan gran d'amfitrions tan ràpidament? Com mines aquests amfitrions? Hem d'alimentar-los per nmap d'alguna manera, treure'ls d'algun lloc, posar-los, executar alguna cosa?...
MM: - Guai. Una pregunta molt correcta! La qüestió és aquesta. Hem modificat la biblioteca (ping ICMP, part de Zabbix) per a les comprovacions ICMP, que indiquen el nombre de paquets: un (1), i el codi intenta utilitzar nmap. És a dir, aquest és el treball intern de Zabbix, que s'ha convertit en el treball intern del pinger. En conseqüència, no cal sincronitzar ni utilitzar un trapper. Això s'ha fet deliberadament per tal de deixar el sistema intacte i no haver de fer front a la sincronització de dos sistemes de bases de dades: què hem de comprovar, carregar a través de l'enquestador, i la nostra càrrega està trencada?... Això és molt més senzill.
R: – També funciona per als proxys?
MM: – Sí, però no ho vam comprovar. El codi de votació és el mateix tant a Zabbix com al servidor. Hauria de funcionar. Permeteu-me insistir una vegada més: el rendiment del sistema és tal que no necessitem un proxy.
MCH: – La resposta correcta a la pregunta és: "Per què necessiteu un proxy amb aquest sistema?" Només per NAT o monitorització a través d'algun tipus de canal lent...
R: – I fas servir Zabbix com al·lertor, si ho entenc bé. O els vostres gràfics (on hi ha la capa d'arxiu) s'han mogut a un altre sistema, com ara Grafana? O no feu servir aquesta funcionalitat?
MM: – Remarcaré una vegada més: hem aconseguit una integració completa. Estem abocant la història a Clickhouse, però al mateix temps hem canviat la interfície php. La interfície Php va a Clickhouse i fa tots els gràfics des d'allà. Al mateix temps, per ser sincers, tenim una part que construeix dades en altres sistemes de visualització gràfica des del mateix Clickhouse, a partir de les mateixes dades de Zabbix.
MCH: – A “Grafan” també.
Com es van prendre les decisions sobre l'assignació de recursos?
R: – Comparteix una mica de la teva cuina interior. Com es va decidir que calia destinar recursos per a un processament seriós del producte? Aquests són, en general, certs riscos. I si us plau, digueu-me, en el context del fet que donareu suport a noves versions: com es justifica aquesta decisió des del punt de vista de la gestió?
MM: – Pel que sembla, no vam explicar molt bé el drama de la història. Ens vam trobar en una situació en què calia fer alguna cosa i, bàsicament, vam anar amb dos equips paral·lels:
- Un va ser llançar un sistema de monitorització amb nous mètodes: monitoring as a service, un conjunt estàndard de solucions de codi obert que combinem i després intentem canviar el procés de negoci per tal de treballar amb el nou sistema de monitoratge.
- Al mateix temps, teníem un programador entusiasta que estava fent això (sobre ell mateix). Va passar que va guanyar.
R: – I quina és la mida de l'equip?
MCH: - Ella està davant teu.
R: – Aleshores, com sempre, necessites un apassionat?
MM: – No sé què és un apassionat.
R: - En aquest cas, pel que sembla, tu. Moltes gràcies, ets genial.
MM: - Gràcies.
Sobre els pedaços per a Zabbix
R: – Per a un sistema que utilitza proxies (per exemple, en alguns sistemes distribuïts), és possible adaptar i pedaçar, per exemple, pollers, proxies i parcialment el preprocessador del mateix Zabbix? i la seva interacció? És possible optimitzar els desenvolupaments existents per a un sistema amb múltiples servidors intermediaris?
MM: – Sé que el servidor Zabbix es munta mitjançant un proxy (el codi es compila i s'obté). No hem provat això en producció. No estic segur d'això, però crec que el gestor del preprocessador no s'utilitza al proxy. La tasca del proxy és agafar un conjunt de mètriques de Zabbix, combinar-les (també registra la configuració, la base de dades local) i tornar-les al servidor Zabbix. El propi servidor farà el preprocessament quan el rebi.
L'interès pels proxies és comprensible. Ho comprovarem. Aquest és un tema interessant.
R: – La idea era aquesta: si podeu pedaxar els enquestadors, podeu pegar-los al servidor intermediari i la interacció amb el servidor, i adaptar el preprocessador per a aquests propòsits només al servidor.
MM: - Crec que és encara més senzill. Agafeu el codi, apliqueu un pedaç i, a continuació, el configureu de la manera que necessiteu: recopilau servidors intermediaris (per exemple, amb ODBC) i distribuïu el codi pegat entre els sistemes. Quan sigui necessari, recolliu un proxy, quan sigui necessari, un servidor.
R: – El més probable és que no haureu de pegar la transmissió del proxy al servidor addicionalment?
MCH: - No, és estàndard.
MM: – De fet, una de les idees no va sonar. Sempre hem mantingut un equilibri entre l'explosió d'idees i la quantitat de canvis i la facilitat de suport.
Alguns anuncis 🙂
Gràcies per quedar-te amb nosaltres. T'agraden els nostres articles? Vols veure més contingut interessant? Doneu-nos suport fent una comanda o recomanant als amics, , un anàleg únic dels servidors d'entrada, que vam inventar per a vosaltres: (disponible amb RAID1 i RAID10, fins a 24 nuclis i fins a 40 GB DDR4).
Dell R730xd 2 vegades més barat al centre de dades Equinix Tier IV a Amsterdam? Només aquí als Països Baixos! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB - a partir de 99 $! Llegeix sobre
Font: www.habr.com