Veurem com funciona Zabbix amb la base de dades TimescaleDB com a backend. Us mostrarem com començar des de zero i com migrar des de PostgreSQL. També oferirem proves comparatives de rendiment de les dues configuracions.
HighLoad++ Siberia 2019. Sala Tomsk. 24 de juny, 16:00 h. Tesis i . La propera conferència HighLoad++ se celebrarà els dies 6 i 7 d'abril de 2020 a Sant Petersburg. Detalls i entrades .
Andrey Gushchin (d'ara endavant - AG): – Sóc enginyer de suport tècnic de ZABBIX (d'ara endavant "Zabbix"), un formador. Fa més de 6 anys que treballo en suport tècnic i tinc experiència directa amb el rendiment. Avui parlaré del rendiment que pot proporcionar TimescaleDB en comparació amb PostgreSQL 10 normal. A més, una part introductòria sobre com funciona en general.
Els principals reptes de productivitat: des de la recollida de dades fins a la neteja de dades
Per començar, hi ha certs reptes de rendiment als quals s'enfronta tots els sistemes de monitorització. El primer repte de productivitat és recollir i processar dades ràpidament.
Un bon sistema de seguiment hauria de rebre totes les dades de manera ràpida i oportuna, processar-les segons expressions disparadores, és a dir, processar-les segons uns criteris (això és diferent en diferents sistemes) i guardar-les en una base de dades per poder utilitzar aquestes dades en el futur.
El segon repte de rendiment és l'emmagatzematge de l'historial. Emmagatzemeu sovint en una base de dades i tingueu accés ràpid i còmode a aquestes mètriques que es van recopilar durant un període de temps. El més important és que aquestes dades siguin còmodes d'obtenir, utilitzar-les en informes, gràfics, activadors, en alguns valors de llindar, per a alertes, etc.
El tercer repte de rendiment és esborrar l'historial, és a dir, quan arribeu al punt en què no necessiteu emmagatzemar cap mètrica detallada que s'hagi recollit durant 5 anys (fins i tot mesos o dos mesos). S'han suprimit alguns nodes de xarxa o alguns amfitrions, les mètriques ja no són necessàries perquè ja estan obsoletes i ja no es recullen. Tot això s'ha de netejar perquè la vostra base de dades no creixi massa. En general, esborrar l'historial és més sovint una prova seriosa per a l'emmagatzematge; sovint té un impacte molt fort en el rendiment.
Com resoldre problemes de memòria cau?
Ara parlaré específicament de Zabbix. A Zabbix, la primera i la segona trucada es resolen mitjançant la memòria cau.
Recollida i processament de dades - Utilitzem la memòria RAM per emmagatzemar totes aquestes dades. Aquestes dades es parlaran ara amb més detall.
També al costat de la base de dades hi ha una mica de memòria cau per a les seleccions principals, per a gràfics i altres coses.
Emmagatzematge en memòria cau al costat del propi servidor Zabbix: tenim ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Què és això?
ConfigurationCache és la memòria cau principal en la qual emmagatzemem mètriques, amfitrions, elements de dades, activadors; tot el que necessiteu per processar el preprocessament, recopilar dades, de quins amfitrions recollir, amb quina freqüència. Tot això s'emmagatzema a ConfigurationCache per no anar a la base de dades i crear consultes innecessàries. Després que el servidor s'iniciï, actualitzem aquesta memòria cau (la creem) i l'actualitzem periòdicament (segons els paràmetres de configuració).
Emmagatzematge a la memòria cau a Zabbix. Recopilació de dades
Aquí el diagrama és força gran:
Els principals de l'esquema són aquests col·leccionistes:
Aquests són els propis processos de muntatge, diversos “pollers” que s'encarreguen de diferents tipus de muntatges. Recopilen dades mitjançant icmp, ipmi i diversos protocols i les transfereixen tot al preprocessament.
Caché d'historial de preprocessament
A més, si tenim elements de dades calculats (els que estan familiaritzats amb Zabbix ho saben), és a dir, elements de dades d'agregació calculats, els traiem directament de ValueCache. Més endavant us explicaré com s'omple. Tots aquests col·leccionistes utilitzen ConfigurationCache per rebre els seus treballs i després passar-los al preprocessament.
El preprocessament també utilitza ConfigurationCache per obtenir passos de preprocessament i processa aquestes dades de diverses maneres. A partir de la versió 4.2, l'hem traslladat a un servidor intermediari. Això és molt convenient, perquè el preprocessament en si és una operació força difícil. I si teniu un Zabbix molt gran, amb un gran nombre d'elements de dades i una alta freqüència de recollida, això simplifica molt la feina.
En conseqüència, després d'haver processat aquestes dades d'alguna manera mitjançant el preprocessament, les desem a HistoryCache per processar-les més. Això conclou la recollida de dades. Passem al procés principal.
Treball de sincronització d'història
El procés principal a Zabbix (ja que és una arquitectura monolítica) és History syncer. Aquest és el procés principal que tracta específicament del processament atòmic de cada element de dades, és a dir, de cada valor:
- el valor ve (l'agafa de HistoryCache);
- comprova a Configuration syncer: si hi ha activadors per al càlcul: els calcula;
si n'hi ha - crea esdeveniments, crea escalada per tal de crear una alerta, si és necessari segons la configuració; - registres desencadenants per al processament posterior, l'agregació; si sumeu durant l'última hora i així successivament, ValueCache recorda aquest valor per no anar a la taula de l'historial; Així, el ValueCache s'omple amb les dades necessàries que són necessàries per calcular activadors, elements calculats, etc.;
- aleshores History Syncer escriu totes les dades a la base de dades;
- la base de dades els escriu al disc, aquí és on acaba el procés de processament.
Base de dades. Emmagatzematge a la memòria cau
Al costat de la base de dades, quan voleu veure gràfics o alguns informes sobre esdeveniments, hi ha diversos cachés. Però en aquest reportatge no en parlaré.
Per a MySQL hi ha Innodb_buffer_pool i un munt de memòria cau diferents que també es poden configurar.
Però aquests són els principals:
- buffers_compartits;
- mida_cache_efectiva;
- pool_compartit.
Per a totes les bases de dades, he dit que hi ha determinades memòria cau que permeten emmagatzemar a la memòria RAM les dades que sovint es necessiten per a les consultes. Tenen les seves pròpies tecnologies per a això.
Sobre el rendiment de la base de dades
En conseqüència, hi ha un entorn competitiu, és a dir, el servidor Zabbix recull dades i les registra. Quan es reinicia, també llegeix l'historial per omplir el ValueCache, etc. Aquí podeu tenir scripts i informes que utilitzen l'API Zabbix, que es basa en una interfície web. Zabbix API entra a la base de dades i rep les dades necessàries per obtenir gràfics, informes o algun tipus de llista d'esdeveniments, problemes recents.
També una solució de visualització molt popular és Grafana, que utilitzen els nostres usuaris. Capaç d'iniciar sessió directament tant a través de l'API Zabbix com a través de la base de dades. També crea una certa competència per a l'obtenció de dades: cal un ajustament més fi i millor de la base de dades per complir amb l'entrega ràpida de resultats i proves.
Esborrar l'historial. Zabbix té mestressa
La tercera trucada que s'utilitza a Zabbix és esborrar l'historial mitjançant Housekeeper. La mestressa segueix tots els paràmetres, és a dir, els nostres elements de dades indiquen quant de temps emmagatzemar (en dies), quant de temps emmagatzemar les tendències i la dinàmica dels canvis.
No he parlat de TrendCache, que calculem sobre la marxa: arriben les dades, les agreguem durant una hora (la majoria són números de l'última hora), la quantitat és mitjana/mínima i la registrem un cop per hora a la taula de la dinàmica de canvis (“Tendències”). "Housekeeper" inicia i elimina dades de la base de dades mitjançant seleccions habituals, cosa que no sempre és efectiva.
Com entendre que és ineficaç? Podeu veure la imatge següent als gràfics de rendiment dels processos interns:
El vostre sincronitzador d'historial està constantment ocupat (gràfic vermell). I el gràfic "vermell" que va a dalt. Es tracta d'un "Housekeeper" que s'inicia i espera que la base de dades esborri totes les files que ha especificat.
Prenem una mica d'identificador d'element: heu d'esborrar els darrers 5 mil; és clar, per índexs. Però normalment el conjunt de dades és bastant gran: la base de dades encara el llegeix del disc i el posa a la memòria cau, i aquesta és una operació molt cara per a la base de dades. Depenent de la seva mida, això pot provocar certs problemes de rendiment.
Podeu desactivar el servei de mestressa d'una manera senzilla: tenim una interfície web familiar. Configuració a l'Administració general (configuració per a "Agent de casa") desactivem la neteja interna per a la història i les tendències internes. En conseqüència, la mestressa ja no controla això:
Què pots fer després? L'has apagat, els teus gràfics s'han anivellat... Quins problemes més podrien sorgir en aquest cas? Què pot ajudar?
Particions (seccionament)
Normalment, això es configura d'una manera diferent a cada base de dades relacional que he enumerat. MySQL té la seva pròpia tecnologia. Però en general són molt similars quan es tracta de PostgreSQL 10 i MySQL. Per descomptat, hi ha moltes diferències internes en com s'implementa i com afecta tot el rendiment. Però, en general, la creació d'una nova partició sovint també comporta certs problemes.
Depenent de la vostra configuració (quantes dades creeu en un dia), solen establir el mínim: això és 1 dia / lot, i per a "tendències", dinàmiques de canvis: 1 mes / lot nou. Això pot canviar si teniu una configuració molt gran.
Diguem de seguida sobre la mida de la configuració: fins a 5 mil nous valors per segon (els anomenats nvps) - això es considerarà una petita "configuració". Mitjana: de 5 a 25 mil valors per segon. Tot el que hi ha a dalt ja són instal·lacions grans i molt grans que requereixen una configuració molt acurada de la base de dades.
En instal·lacions molt grans, 1 dia pot no ser òptim. Personalment, he vist particions a MySQL de 40 gigabytes per dia (i potser n'hi ha més). Es tracta d'una quantitat molt gran de dades, que pot provocar alguns problemes. Cal reduir-lo.
Per què necessiteu particions?
El que proporciona el particionament, crec que tothom ho sap, és el particionament de taules. Sovint, aquests són fitxers separats al disc i sol·licituds d'abast. Selecciona una partició de manera més òptima si forma part de la partició normal.
Per a Zabbix, en particular, s'utilitza per rang, per rang, és a dir, fem servir una marca de temps (un nombre normal, temps des del començament de l'època). Especifiqueu l'inici del dia/final del dia, i aquesta és la partició. En conseqüència, si demaneu dades que tenen dos dies d'antiguitat, tot es recupera de la base de dades més ràpidament, perquè només cal carregar un fitxer a la memòria cau i tornar-lo (en lloc d'una taula gran).
Moltes bases de dades també acceleren la inserció (inserció en una taula fill). De moment parlo de manera abstracta, però això també és possible. La partició sovint ajuda.
Elasticsearch per a NoSQL
Recentment, a la 3.4, hem implementat una solució NoSQL. S'ha afegit la possibilitat d'escriure a Elasticsearch. Podeu escriure certs tipus: escolliu - o bé escriu números o alguns signes; tenim text de cadena, podeu escriure registres a Elasticsearch... En conseqüència, la interfície web també accedirà a Elasticsearch. Això funciona molt bé en alguns casos, però de moment es pot utilitzar.
Escala de temps DB. Hipertaules
Per a la 4.4.2 vam prestar atenció a una cosa com TimescaleDB. Què és això? Aquesta és una extensió per a PostgreSQL, és a dir, té una interfície nativa de PostgreSQL. A més, aquesta extensió us permet treballar de manera molt més eficient amb dades de sèries temporals i tenir particions automàtices. Com es veu:
Això és hipertaula: hi ha aquest concepte a Timecale. Aquesta és una hipertaula que creeu i conté trossos. Els trossos són particions, aquestes són taules fills, si no m'equivoco. És realment efectiu.
TimescaleDB i PostgreSQL
Com asseguren els fabricants de TimescaleDB, utilitzen un algorisme més correcte per processar consultes, en particular insercions, que els permet tenir un rendiment aproximadament constant amb una mida creixent de la inserció del conjunt de dades. És a dir, després de 200 milions de files de Postgres, l'habitual comença a caure molt i perd el rendiment literalment a zero, mentre que l'escala de temps permet inserir insercions de la manera més eficient possible amb qualsevol quantitat de dades.
Com instal·lar TimescaleDB? És fàcil!
Està a la documentació, està descrit: podeu instal·lar-lo des de paquets per a qualsevol... Depèn dels paquets oficials de Postgres. Es pot compilar manualment. Va passar que vaig haver de compilar per a la base de dades.
A Zabbix simplement activem l'extensió. Crec que els que van utilitzar Extention a Postgres... Simplement activeu Extention, la creeu per a la base de dades Zabbix que esteu utilitzant.
I l'últim pas...
Escala de temps DB. Migració de taules històriques
Heu de crear una hipertaula. Hi ha una funció especial per a això: crear hipertaula. En ell, el primer paràmetre és la taula que es necessita en aquesta base de dades (per a la qual cal crear una hipertaula).
El camp pel qual s'ha de crear i chunk_time_interval (aquest és l'interval de blocs (particions que s'han d'utilitzar). 86 és un dia.
Paràmetre Migrate_data: si inseriu a true, això migrarà totes les dades actuals a fragments pre-creats.
Jo mateix he utilitzat migrate_data: triga una bona quantitat de temps, depenent de la mida de la vostra base de dades. Vaig tenir més d'un terabyte: vaig trigar més d'una hora a crear-lo. En alguns casos, durant les proves, vaig suprimir les dades històriques per al text (history_text) i la cadena (history_str) per no transferir-les; no m'interessen realment.
I fem l'última actualització a la nostra db_extention: instal·lem timescaledb perquè la base de dades i, en particular, el nostre Zabbix entengui que hi ha db_extention. L'activa i utilitza la sintaxi i les consultes correctes a la base de dades, utilitzant aquelles "característiques" que són necessàries per a TimescaleDB.
Configuració del servidor
Vaig utilitzar dos servidors. El primer servidor és una màquina virtual força petita, 20 processadors, 16 gigabytes de RAM. Hi vaig configurar Postgres 10.8:
El sistema operatiu era Debian, el sistema de fitxers era xfs. Vaig fer una configuració mínima per utilitzar aquesta base de dades en particular, menys el que utilitzarà Zabbix. A la mateixa màquina hi havia un servidor Zabbix, PostgreSQL i agents de càrrega.
He utilitzat 50 agents actius que utilitzen LoadableModule per generar diferents resultats ràpidament. Són els que van generar les cadenes, els números, etc. Vaig omplir la base de dades amb moltes dades. Inicialment, la configuració contenia 5 elements de dades per host, i aproximadament cada element de dades contenia un activador, per tal que aquesta fos una configuració real. De vegades, fins i tot necessiteu més d'un activador per utilitzar-lo.
Vaig regular l'interval d'actualització i la càrrega en si no només utilitzant 50 agents (afegint més), sinó també utilitzant elements de dades dinàmiques i reduint l'interval d'actualització a 4 segons.
Prova de rendiment. PostgreSQL: 36 mil NVP
El primer llançament, la primera configuració que vaig tenir va ser en PostreSQL 10 pur en aquest maquinari (35 mil valors per segon). En general, com podeu veure a la pantalla, inserir dades triga fraccions de segon: tot és bo i ràpid, unitats SSD (200 gigabytes). L'única cosa és que 20 GB s'omplen bastant ràpidament.
Hi haurà molts gràfics d'aquest tipus en el futur. Aquest és un tauler estàndard de rendiment del servidor Zabbix.
El primer gràfic és el nombre de valors per segon (blau, superior esquerra), 35 mil valors en aquest cas. Això (a dalt al centre) és la càrrega dels processos de compilació, i això (a dalt a la dreta) és la càrrega de processos interns: sincronitzadors d'historial i mestressa, que aquí (a baix al centre) s'està executant durant força temps.
Aquest gràfic (a baix al centre) mostra l'ús de ValueCache: quantes visites de ValueCache per als activadors (uns milers de valors per segon). Un altre gràfic important és el quart (a baix a l'esquerra), que mostra l'ús de HistoryCache, del qual he parlat, que és un buffer abans d'inserir-lo a la base de dades.
Prova de rendiment. PostgreSQL: 50 mil NVP
A continuació, vaig augmentar la càrrega a 50 mil valors per segon al mateix maquinari. Quan va carregar Housekeeper, es van registrar 10 mil valors en 2-3 segons amb càlcul. Què, de fet, es mostra a la següent captura de pantalla:
"Housekeeper" ja comença a interferir amb el treball, però, en general, la càrrega dels caçadors d'enfonsament històric encara està al nivell del 60% (tercer gràfic, a dalt a la dreta). HistoryCache ja comença a omplir-se activament mentre s'executa Housekeeper (a baix a l'esquerra). Va ser aproximadament mig gigabyte, ple al 20%.
Prova de rendiment. PostgreSQL: 80 mil NVP
Llavors el vaig augmentar a 80 mil valors per segon:
Van ser aproximadament 400 mil elements de dades, 280 mil activadors. La inserció, com podeu veure, pel que fa a la càrrega de plomes de la història (n'hi havia 30) ja era força elevada. Llavors vaig augmentar diversos paràmetres: plomes d'historial, memòria cau... En aquest maquinari, la càrrega dels plomes de l'historial va començar a augmentar al màxim, gairebé "a la prestatgeria", per tant, HistoryCache va tenir una càrrega molt alta:
Durant tot aquest temps vaig controlar tots els paràmetres del sistema (com s'utilitza el processador, RAM) i vaig descobrir que la utilització del disc era màxima: vaig aconseguir la capacitat màxima d'aquest disc en aquest maquinari, en aquesta màquina virtual. "Postgres" va començar a bolcar dades de manera bastant activa a tal intensitat, i el disc ja no tenia temps per escriure, llegir...
Vaig agafar un altre servidor que ja tenia 48 processadors i 128 gigabytes de RAM:
També el vaig "sintonitzar": vaig instal·lar History Syncer (60 peces) i vaig aconseguir un rendiment acceptable. De fet, no estem "a la prestatgeria", però probablement aquest és el límit de la productivitat, on ja cal fer-hi alguna cosa.
Prova de rendiment. TimescaleDB: 80 mil NVP
La meva tasca principal era utilitzar TimescaleDB. Cada gràfic mostra una caiguda:
Aquests errors són precisament la migració de dades. Després d'això, al servidor Zabbix, el perfil de càrrega de l'historial sinkers, com podeu veure, va canviar molt. Us permet inserir dades gairebé 3 vegades més ràpid i utilitzar menys HistoryCache; en conseqüència, tindreu les dades lliurades a temps. Un cop més, 80 mil valors per segon és una taxa força alta (per descomptat, no per a Yandex). En general, aquesta és una configuració bastant gran, amb un servidor.
Prova de rendiment de PostgreSQL: 120 mil NVP
A continuació, vaig augmentar el valor del nombre d'elements de dades a mig milió i vaig rebre un valor calculat de 125 mil per segon:
I tinc aquests gràfics:
En principi, aquesta és una configuració de treball, pot funcionar durant força temps. Però com que només tenia un disc d'1,5 terabytes, el vaig fer servir en un parell de dies. El més important és que al mateix temps es van crear noves particions a TimescaleDB, i això va passar completament desapercebut pel que fa al rendiment, cosa que no es pot dir de MySQL.
Normalment, les particions es creen a la nit, perquè això generalment bloqueja la inserció i el treball amb taules i pot provocar la degradació del servei. En aquest cas no és així! La tasca principal era provar les capacitats de TimescaleDB. El resultat va ser la següent xifra: 120 mil valors per segon.
També hi ha exemples a la comunitat:
La persona també va activar TimescaleDB i la càrrega d'utilitzar io.weight va baixar al processador; i l'ús d'elements de procés intern també ha disminuït a causa de la inclusió de TimescaleDB. A més, es tracta de discs de pancake normals, és a dir, una màquina virtual normal en discs normals (no SSD)!
Per a algunes configuracions petites que estan limitades pel rendiment del disc, TimescaleDB, al meu entendre, és una molt bona solució. Us permetrà continuar treballant abans de migrar a un maquinari més ràpid per a la base de dades.
Us convido a tots als nostres esdeveniments: Conferència a Moscou, Cimera a Riga. Utilitzeu els nostres canals: Telegram, fòrum, IRC. Si tens qualsevol dubte, vine al nostre escriptori, podem parlar de tot.
Preguntes del públic
Pregunta de l'audiència (d'ara endavant - A): - Si TimescaleDB és tan fàcil de configurar i augmenta el rendiment, potser s'hauria d'utilitzar com a millor pràctica per configurar Zabbix amb Postgres? I hi ha algun inconvenient i desavantatge d'aquesta solució, o al cap i a la fi, si vaig decidir fer Zabbix per mi mateix, puc agafar fàcilment Postgres, instal·lar-hi Timecale de seguida, utilitzar-lo i no pensar en cap problema?
AG: – Sí, diria que aquesta és una bona recomanació: utilitzeu Postgres immediatament amb l'extensió TimescaleDB. Com ja he dit, moltes bones crítiques, malgrat que aquesta "funció" és experimental. Però en realitat les proves mostren que aquesta és una gran solució (amb TimescaleDB) i crec que evolucionarà! Estem supervisant com es desenvolupa aquesta extensió i farem els canvis necessaris.
Fins i tot durant el desenvolupament, ens vam basar en una de les seves "característiques" conegudes: era possible treballar amb fragments una mica diferent. Però després ho van eliminar a la següent versió i vam haver de deixar de confiar en aquest codi. Recomanaria utilitzar aquesta solució en moltes configuracions. Si utilitzeu MySQL... Per a configuracions mitjanes, qualsevol solució funciona bé.
R: – Als últims gràfics de la comunitat, hi havia un gràfic amb “Housekeeper”:
Va seguir treballant. Què fa Housekeeper amb TimescaleDB?
AG: – Ara no puc dir-ho amb certesa – miraré el codi i us explicaré amb més detall. Utilitza consultes TimescaleDB no per eliminar fragments, sinó per agregar-los d'alguna manera. Encara no estic preparat per respondre aquesta pregunta tècnica. Ho sabrem més a l'estand avui o demà.
R: – Tinc una pregunta similar: sobre el rendiment de l'operació d'eliminació a Timecale.
R (resposta de l'audiència): – Quan elimineu dades d'una taula, si ho feu mitjançant la supressió, heu de passar per la taula: suprimiu, netegeu, marqueu-ho tot per a un futur buit. A Timecale, com que teniu trossos, podeu deixar anar. A grans trets, només li dius al fitxer que es troba en big data: "Suprimeix!"
Timecale simplement entén que aquest tros ja no existeix. I com que està integrat al planificador de consultes, utilitza ganxos per detectar les vostres condicions en operacions selectes o altres i immediatament entén que aquest tros ja no existeix: "Ja no hi aniré!" (dades no disponibles). Això és tot! És a dir, una exploració de la taula se substitueix per una supressió de fitxers binaris, de manera que és ràpid.
R: – Ja hem tocat el tema de no SQL. Pel que entenc, Zabbix no necessita modificar les dades, i tot això és com un registre. És possible utilitzar bases de dades especialitzades que no poden canviar les seves dades, però al mateix temps desar, acumular i distribuir molt més ràpidament - Clickhouse, per exemple, alguna cosa semblant a Kafka?... Kafka també és un registre! És possible integrar-los d'alguna manera?
AG: - Es pot fer la descàrrega. Tenim una certa "característica" des de la versió 3.4: podeu escriure tots els fitxers històrics, esdeveniments, tota la resta als fitxers; i després enviar-lo a qualsevol altra base de dades mitjançant algun controlador. De fet, molta gent reelabora i escriu directament a la base de dades. Sobre la marxa, els sinkers de la història escriuen tot això en fitxers, giren aquests fitxers, etc., i podeu transferir-ho a Clickhouse. No puc dir sobre els plans, però potser el suport addicional per a solucions NoSQL (com ara Clickhouse) continuarà.
R: – En general, resulta que pots desfer-te completament de postgres?
AG: – Per descomptat, la part més difícil de Zabbix són les taules històriques, que creen més problemes i esdeveniments. En aquest cas, si no emmagatzemeu esdeveniments durant molt de temps i emmagatzemeu l'historial amb tendències en algun altre emmagatzematge ràpid, crec que, en general, no hi haurà problemes.
R: – Pots estimar quant més ràpid funcionarà tot si canvies a Clickhouse, per exemple?
AG: - No ho he provat. Crec que almenys els mateixos números es poden aconseguir de manera senzilla, atès que Clickhouse té la seva pròpia interfície, però no puc dir-ho amb certesa. És millor provar. Tot depèn de la configuració: quants hosts tens, etc. Inserir és una cosa, però també cal recuperar aquestes dades: Grafana o una altra cosa.
R: – Per tant, estem parlant d'una lluita per igual, i no del gran avantatge d'aquestes bases de dades ràpides?
AG: – Crec que quan ens integrem, hi haurà proves més precises.
R: – On va anar el bon vell RRD? Què us va fer canviar a bases de dades SQL? Inicialment, totes les mètriques es van recollir a RRD.
AG: – Zabbix tenia RRD, potser en una versió molt antiga. Sempre hi ha hagut bases de dades SQL, un enfocament clàssic. L'enfocament clàssic és MySQL, PostgreSQL (existeixen des de fa molt de temps). Gairebé mai vam utilitzar una interfície comuna per a bases de dades SQL i RRD.
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