Saluton al ĉiuj. Malsupre estas la deĉifrado .
- sistemo por kontrolado de diversaj sistemoj kaj servoj, per kiu la administrantoj de la sistemo povas kolekti informojn pri la aktualaj parametroj de sistemoj kaj starigi atentigojn por ricevi sciigojn pri devioj en la funkciado de sistemoj.
La raporto komparos и — projektoj por longdaŭra stokado de Prometheus-metrikoj.
Mi unue rakontu al vi pri Prometeo. Ĉi tio estas monitora sistemo, kiu kolektas metrikojn de donitaj celoj kaj konservas ilin en loka stokado. Prometheus povas skribi metrikojn al fora stokado, povas generi atentigojn kaj registrajn regulojn.
Limigoj de Prometheus:
- Ĝi ne havas tutmondan demandan vidon. Jen kiam vi havas plurajn sendependajn prometheus-kazojn. Ili kolektas metrikojn. Kaj vi volas demandi aldone al ĉiuj ĉi tiuj metrikoj kolektitaj de malsamaj prometheus-instancoj. Prometeo ne permesas ĉi tion.
- Kun prometheus, rendimento estas limigita al nur unu servilo. Prometheus ne povas aŭtomate grimpi al pluraj serviloj. Vi povas nur mane dividi viajn celojn inter pluraj Prometheus.
- La amplekso de metrikoj en Prometheus estas limigita al nur unu servilo pro la sama kialo, ke ĝi ne povas aŭtomate grimpi al pluraj serviloj aŭtomate.
- En Prometeo, ne estas tiel facile organizi la sekurecon de datumoj.
Solvoj al ĉi tiuj problemoj/defioj?
Solvoj estas:
Ĉiuj ĉi tiuj solvoj estas por fora stokado de datumoj kolektitaj de Prometheus. Ili solvas la problemon de fora stokado de la antaŭa glito en malsamaj manieroj. En ĉi tiu prezento, mi nur parolos pri la unuaj du solvoj: и .
Unuafoje informoj pri aperis sur . La arkitekturo estas priskribita kaj kiel ĝi funkcias.
Thanos prenas la datumojn, kiujn Prometeo konservis al la loka disko kaj kopias ĝin al S3, aŭ al alia objektostokado.
Tiel Thanos disponigas tutmondan demandan vidon. Vi povas demandi datumojn konservitajn en objektostokado de pluraj Prometheus-kazoj.
Thanos subtenas PromQL kaj .
Thanos uzas Prometheus-kodon por konservi datumojn.
Thanos estas evoluigita de la samaj programistoj kiel Prometheus.
pri . Ĉi tie kie ni unue parolis .
VictoriaMetrics ricevas datumojn de pluraj prometeoj protokolo subtenata de Prometeo.
VictoriaMetrics disponigas tutmondan demandan vidon, ĉar pluraj Prometheus-kazoj povas skribi datumojn al ununura VictoriaMetrics. Sekve, vi povas fari demandojn pri ĉiuj ĉi tiuj datumoj.
VictoriaMetrics ankaŭ subtenas, kiel Thanos, PromQL kaj Prometheus pridemandado de API.
Male al Thanos, la fontkodo de VictoriaMetrics estas skribita de nulo kaj optimumigita por rapideco kaj resursa konsumo.
VictoriaMetrics, male al Thanos, skalas kaj vertikale kaj horizontale. Manĝu , kiu grimas vertikale. Vi povas komenci per unu procesoro kaj 1 GB da memoro kaj kreski ĝis centoj da procesoroj kaj 1 TB da memoro. VictoriaMetrics scias kiel uzi ĉiujn ĉi tiujn rimedojn. Ĝia agado pliiĝos ĉirkaŭ 100 fojojn kompare kun 1-kerna sistemo.
La historio de Thanos komenciĝis en novembro 2017, kiam aperis la unua publika kompromiso. Antaŭ tio, Thanos estis evoluigita interne .
En junio 2019, estis grava eldono 0.5.0, en kiu protokolo. Li estis forigita de Thanos ĉar li ne rezultis bone. Ofte la Thanos-areo ne funkciis ĝuste, nodoj malĝuste konektitaj al ĝi pro la klaĉa protokolo. Do ni decidis forigi ĝin de tie. Mi kredas, ke ĉi tio estas la ĝusta decido.
En la sama junio 2019, ili sendis kandidatiĝon в .
Kaj post kelkaj monatoj, Thanos estis akceptita , kiu inkluzivas Prometheus, Kubernetes kaj aliajn popularajn projektojn.
En januaro 2018, la evoluo de VictoriaMetrics komenciĝis.
En septembro 2018, mi unue publike menciis VictoriaMetrics.
En decembro 2018, la Unu-noda versio estis publikigita.
En majo 2019 fontoj de kaj Ununoda kaj cluster versio.
En junio 2019, same kiel Thanos, ni prezentis peton al la fondaĵo CNCF sub la numero . Ni kandidatiĝis unu tagon antaŭ ol Thanos kandidatiĝis.
Sed, bedaŭrinde, ni ankoraŭ ne estis akceptitaj tie. Komunuma helpo bezonata.
Konsideru la plej gravajn lumbildojn montrantajn la arkitekturon de Thanos kaj VictoriaMetrics.
Ni komencu kun Thanos. La flavaj komponentoj estas Prometheus-komponentoj. Ĉio alia estas Thanos-komponentoj. Ni komencu per la plej grava komponanto. Thanos Sidecar estas komponanto instalita apud ĉiu Prometeo. Ĝi respondecas pri ŝarĝo de Prometheus-datumoj de loka stokado al S3 aŭ alia Objekta Stokado.
Ankaŭ ekzistas tia komponanto kiel Thanos Store Gateway, kiu povas legi ĉi tiujn datumojn de Object Storage laŭ envenantaj petoj de Thanos Query. Thanos Query efektivigas PromQL kaj Prometheus API. Tio estas, de ekstere ĝi aspektas kiel Prometeo. Ĝi akceptas PromQL-petojn, sendas ilin al Thanos Store Gateway, Thanos Store Gateway ricevas la necesajn datumojn de Object Storage, resendas ĝin.
Sed ni havas datumojn konservitajn en Object Storage sen la lastaj du horoj pro la efektivigo de Thanos Sidecar, kiu ne povas alŝuti la lastajn du horojn al Object Storage S3, ĉar Prometheus ankoraŭ ne kreis dosierojn en loka stokado dum ĉi tiuj du horoj.
Kiel vi decidis ĉirkaŭiri ĉi tion? Thanos Query, krom petoj al la Thanos Store Gateway, sendas paralelajn petojn al ĉiu Thanos Sidecar kiu estas apud Prometeo.
Kaj Thanos Sidecar, siavice, transdonas petojn plu al Prometheus, kaj ricevas datumojn dum la lastaj du horoj.
Krom ĉi tiuj komponantoj, ekzistas ankaŭ laŭvola komponanto, sen kiu Thanos sentos malbonon. Ĉi tio estas Thanos Compact, kiu kunfandas malgrandajn dosierojn sur Object Storage en pli grandajn dosierojn, kiuj estis alŝutitaj ĉi tie de Thanos Sidecars. Thanos Sidecar alŝutas datumdosierojn tie dum du horoj. Ĉi tiuj dosieroj, se ili ne estas kunfanditaj en pli grandajn dosierojn, ilia nombro povas kreski tre signife. Ju pli da tiaj dosieroj, des pli da memoro necesas por Thanos Store Gateway, des pli da rimedoj necesas por transdoni datumojn tra la reto, metadatenojn. Thanos Store Gateway fariĝas malefika. Sekve, necesas ruli Thanos Compact, kiu kunfandas malgrandajn dosierojn en pli grandajn, por ke ekzistas malpli da tiaj dosieroj kaj redukti superkompeton sur Thanos Store Gateway.
Ekzistas ankaŭ tia komponento kiel Thanos Ruler. Ĝi plenumas Prometheus-avertregulojn kaj povas komputi Prometheus-registradajn regulojn por reskribi datumojn al Object Storage. Sed ĉi tiu komponanto ne rekomendas esti uzata, ĉar. Li .
Jen simpla skemo por Thanos.
Nun ni komparu kun la VictoriaMetrics-skemo.
VictoriaMetrics havas 2 versiojn: Unu-noda kaj cluster-versio. Unu-nodo funkcias per unu komputilo. Unu-nodo ne havas ĉi tiujn komponentojn, nur unu binaron. Ĉi tiu duuma sur la glito aspektas kiel ĉi tiu kvadrato. Ĉio ene de la kvadrato estas la enhavo de la binara dosiero por la Ununoda versio. Vi ne bezonas scii pri ĝi. Nur rulu la binaron - kaj ĉio funkcias por ni.
La cluster-versio estas pli malfacila. En ĝi estas tri malsamaj komponantoj: vmselect, vminsert kaj vmstorage. De ilia nomo devus esti klare, kion ĉiu el ili faras. La Insert-komponento akceptas datumojn en malsamaj formatoj: de la Prometheus fora skriba API, la Influx-linia protokolo, la Graphite-protokolo, kaj la OpenTSDB-protokolo. La Insert-komponento akceptas ilin, analizas ilin kaj distribuas ilin inter la ekzistantaj stokadkomponentoj, kie la datumoj jam estas stokitaj. La Elekto-komponento, siavice, akceptas PromQL-petojn. Ĝi efektivigas , same kiel la Prometheus demandanta API, kaj povas esti uzata kiel anstataŭaĵo por Prometheus en Grafana aŭ aliaj Prometheus API klientoj. Elektu prenas promql-peton, analizas ĝin, legas la necesajn datumojn por plenumi ĉi tiun peton de stokaj nodoj, prilaboras ĉi tiujn datumojn kaj resendas respondon.
Ni komparu la kompleksecon de instalo de Thanos kaj VictoriaMetrics.
Ni komencu kun Thanos. Antaŭ ol vi komencas labori kun Thanos, vi devas krei sitelon en Object Storage, kiel S3 aŭ GCS, por ke Thanos Sidecar povu skribi datumojn tie.
Tiam por ĉiu Prometheus vi devas instali Thanos Sidecar. Antaŭ tio, vi devas memori malŝalti datumajn kompaktojn en Prometheus. Kompaktado de datumoj periode kunpremas datumojn en loka stokado de Prometheus por redukti la konsumon de rimedoj.
Kiam vi instalas Thanos Sidecar sur via Prometheus, vi devas malŝalti ĉi tiun datuman kompakton ĉar Thanos Sidecar ne funkcias ĝuste kun datuma kompaktado ebligita. Ĉi tio signifas, ke via Prometheus komencas ŝpari datumojn en blokoj de du horoj kaj ĉesas kunfandi ĉi tiujn blokojn en pli grandajn. Sekve, se vi faras petojn, kiuj superas la daŭron de la lastaj du horoj, tiam ili ne funkcios tiel efike kiel ili povus funkcii se datuma kompaktado estus ebligita.
Tial Thanos rekomendas redukti la datumtempon en loka stokado al 6-8 horoj por redukti ĉi tiun superkoston de granda nombro da malgrandaj blokoj.
Post kiam vi instalis Thanos Sidecar, vi devas instali du komponantojn por ĉiu Objekta Stokado-Sitelo. Ĉi tiuj estas Thanos Compactor kaj Thanos Store Gateway.
Post tio, vi devas instali Thanos Query kaj agordi ĝin por ke ĝi povu konektiĝi al ĉiuj Thanos Store Gateways, kiujn vi havas, kaj ankaŭ povi konektiĝi al ĉiuj Thanos Sidecars.
Eble estas eta problemo ĉi tie.
Vi devas agordi fidindan kaj sekuran konekton de Thanos Query al ĉi tiuj komponantoj. Kaj se vi havas Prometheus'y situanta en malsamaj datumcentroj, aŭ en malsamaj VPC-oj, tiam ligoj al ili de ekstere estas malpermesitaj. Sed por ke Thanos Query funkciu, vi devas iel agordi la konekton tie, kaj vi devas elpensi manieron.
Se vi havas multajn tiajn datumcentrojn, tiam, sekve, la fidindeco de la tuta sistemo malpliiĝas. Ĉar Thanos Query devas konstante konservi ligojn al ĉiuj Thanos Sidecars situantaj en malsamaj datumcentroj. Kun ĉiu envenanta peto, ĝi sendos petojn al ĉiuj Thanos Sidecars. Se la konekto estas interrompita, tiam vi aŭ ricevos nekompletan datuman aron, aŭ vi ricevos respondon "la areto ne funkcias".
En VictoriaMetrics, aferoj estas iom pli simplaj. Por la Ununoda versio, nur rulu unu binaron kaj ĉio funkcias.
En la amasigita versio, sufiĉas ruli ĉiujn ĉi-suprajn tri specojn de komponantoj en ajna kvanto, kiun vi bezonas aŭ uzi por aŭtomatigi la lanĉon de komponantoj en Kubernetes. Ni ankaŭ planas fari Kubernetes-funkciigiston. Helm-diagramo ne kovras iujn kazojn kaj permesas vin pafi vian piedon. Ekzemple, ĝi permesas vin redukti la nombron da stokaj nodoj, kio kondukos al perdo de datumoj.
Post kiam vi lanĉis unu binaran aŭ amasigitan version, vi nur bezonas aldoni al la agordo de Prometheus tiel ke ĝi komencas skribi datumojn paralele al loka stokado kaj fora stokado. Kiel vi povas vidi, ĉi tiu agordo devus funkcii multe pli fidinde ol la agordo de Thanos. Ni ne bezonas konservi konekton de VictoriaMetrics al ĉiuj Prometheus, ĉar Prometheus mem konektas al VictoriaMetrics kaj transdonas datumojn.
Konsideru subtenon por Thanos kaj VictoriaMetrics.
Thanos devas observi Sidecar por ke ili ne ĉesu alŝuti datumojn al Object Storage. Ili povas ĉesigi ĉi tiun datuman elŝuton pro elŝutaj eraroj, ekzemple, via retkonekto al Object Storage estas provizore perdita, aŭ Object Storage estas provizore neatingebla. Thanos Sidecar rimarkos ĉi tion ĉi-momente, raportos eraron, eble kraŝos kaj poste ĉesos funkcii. Se vi ne kontrolas ĝin, tiam viaj datumoj ne plu estos transdonitaj al Object Storage. Se la retentempo pasas (6-8 horoj rekomendas), tiam vi perdos datumojn, kiuj ne eniris en Objektan Stokadon.
Thanos-kompaktigiloj eble ĉesos funkcii pro . Kompaktiloj prenas datumojn de Object Storage kaj kunfandas ĝin en pli grandajn partojn de datumoj. Ĉar la kompaktveturiloj ne estas sinkronigitaj kun la Sidecars, la sekvanta povas okazi: la Sidecar ankoraŭ ne havis tempon aldoni la blokon, la Compactor decidas ke tiu bloko estis tute skribita. Kompakilo komencas legi ĝin. Ĝi legas la blokon nekomplete kaj ĉesas funkcii. Vidu detalojn .
Store Gateway povas resendi malkonsekvencajn datumojn pro vetkuroj inter Kompakilo kaj Sidecars. Ĉi tie estas la sama, ĉar Store Gateway neniel sinkroniĝas kun Kompakiloj kaj Sidecars. Sekve, raskondiĉoj povas okazi kiam la Store Gateway ne vidas parton de la datumoj, aŭ vidas kromajn datumojn.
La Demando-komponento en Thanos resendas partan rezulton defaŭlte se iuj Sidecars aŭ Store Gateways ne estas disponeblaj nuntempe. Vi ricevos iujn datumojn, kaj eĉ ne scios, ke vi ne ricevis ĉiujn datumojn. Jen kiel ĝi funkcias defaŭlte. En simila situacio, VictoriaMetrics resendas etikeditajn datumojn kiel partajn.
Male al Thanos, VictoriaMetrics malofte perdas datumojn. Eĉ se la konekto de Prometheus al VictoriaMetrics estas interrompita, tiam ĉi tio ne estas problemo, ĉar Prometheus daŭre skribas envenantajn novajn datumojn al la Skribu Antaŭe-Protokolo, kiu estas 2 horoj. Se vi restarigas la konekton al VictoriaMetrics ene de du horoj, la datumoj ne estos perditaj. Prometeo .
Male al Thanos, kiu skribas datumojn al objektostokado nur post du horoj, Prometheus aŭtomate reproduktas datumojn per fora skriba protokolo al fora stokado, kiel VictoriaMetrics. Vi ne timas perdi lokan stokadon en Prometeo. Se li subite perdis lokan stokadon, tiam vi perdos la lastajn sekundojn da datumoj, kiuj ne havis tempon por skribi al fora stokado en la plej malbona kazo.
Kubernetes administras la areton aŭtomate male al Thanos. Estas malfacile meti ĉiujn Thanos-komponentojn en unu Kubernetes-areton, male al VictoriaMetrics-grupo-komponentoj.
VictoriaMetrics havas tre facilan ĝisdatigon al la nova versio. Nur ĉesu VictoriaMetrics, ĝisdatigu la binarojn kaj komencu. Kiam haltigita per SIGINT-signalo, ĉiuj VictoriaMetrics binaroj faras gracian haltigon. Ili ĝuste konservas la necesajn datumojn, ĝuste fermas envenantajn konektojn por ne perdi ion ajn. Do vi nenion perdos kiam vi ĝisdatigas.
Estas tre facile por VictoriaMetrics vastigi la areton. Nur aldonu la necesajn komponantojn kaj daŭre laboru.
Pri kaptiloj en Thanos kaj VictoriaMetrics.
Thanos havas la sekvajn malfacilaĵojn. Prometheus devus stoki datumojn dum la lastaj du horoj. Se ili perdiĝos, vi tute perdos ilin, ĉar ili ne havis tempon por skribi al Object Storage, kiel S3.
La Store Gateway-komponento kaj kompaktkomponento povas esti memorintensa por trakti grandan Objektan Stokadon se ekzistas multaj malgrandaj dosieroj stokitaj tie. Ju pli granda estas la nombro kaj grandeco de dosieroj, des pli da RAM la Store Gateway kaj kompaktilo bezonas por stoki metainformojn. Thanos havas multajn problemojn pri kio .
Thanos estas anoncita kiel kapabla grimpi senfine laŭ la nombro da Prometeo, kiun vi havas. Fakte ĉi tio ne estas vera. Ĉar ĉiuj petoj trairas la Query-komponenton, kiu devas baloti ĉiujn Store Gateway-komponentojn kaj ĉiujn Sidecar-komponentojn paralele, ĉerpi datumojn de tie kaj poste antaŭprocezi ilin. Estas evidente, ke la indico de petoj estas limigita de la plej malrapida malforta ligo, la plej malrapida Store Gateway aŭ la plej malrapida Sidecar.
Ĉi tiuj komponantoj povas esti malegale ŝarĝitaj. Ekzemple, vi havas Prometheus, kiu kolektas milionojn da metrikoj je sekundo. Kaj ekzistas Prometeo, kiu kolektas milojn da metrikoj je sekundo. Prometheus, kiu kolektas milionojn da metrikoj je sekundo, ŝarĝas la servilon sur kiu ĝi funkcias multe pli. Sekve, Sidecar estas pli malrapida tie. Kaj ĝenerale, ĉio tie estas malrapida. Kaj la Query-komponento eltiros datumojn tre malrapide de tie. Sekve, la rendimento de via tuta areto estos limigita de ĉi tiu malrapida Sidecar.
Defaŭlte, Thanos resendas partajn datumojn se iuj Sidecars kaj aŭ Store Gateways ne estas disponeblaj. Ekzemple, se vi havas Sidecars disigitaj tra la mondo en malsamaj datumcentroj, tiam la probablo de malkonekto kaj nehavebleco de komponantoj multe pliiĝas. Sekve, en la plej multaj kazoj, vi ricevos partajn datumojn eĉ sen scii ĝin.
VictoriaMetrics ankaŭ havas malfacilaĵojn. La unua faŭlto estas opcio, kiu limigas la kvanton de RAM uzata por la kaŝmemoro de VictoriaMetrics. Ĝi defaŭlte al 60% RAM sur la maŝino kie VictoriaMetrics funkcias, aŭ 60% RAM sur la VictoriaMetrics pod en Kubernetes.
Se vi ŝanĝas ĉi tiun valoron malĝuste, vi povas ruinigi la agadon de VictoriaMetrics. Ekzemple, se la valoro estas agordita tro malalta, tiam la datumoj eble ne plu taŭgas en la kaŝmemoro de VictoriaMetrics. Pro tio ŝi devos fari kroman laboron kaj ŝarĝi la procesoron per la disko. Se vi faras ĉi tiun opcion tro granda, ĝi pliigas, unue, la verŝajnecon, ke VictoriaMetrics kraŝos kun eraro sen memoro, kaj due, ĝi kondukos al la fakto, ke la operaciumo restos tre malmulte da RAM memoro por la dosiero. kaŝaĵo. Kaj VictoriaMetrics dependas de la dosierkaŝmemoro por agado. Se ĝi ne sufiĉas, tiam la ŝarĝo sur la disko povas multe pliiĝi. Tial, konsilo: ne ŝanĝu la parametron krom se nepre necese.
Dua opcio. Ĉi tiu retenperiodo estas periodo agordita al 1 monato defaŭlte. Ĉi tiu estas la tempo dum kiu VictoriaMetrics konservas la datumojn. Post ĉi tiu periodo, VictoriaMetrics forigas la datumojn.
Multaj homoj kuras VictoriaMetrics sen ĉi tiu opcio kaj registras datumojn dum monato. Kaj tiam ili demandas: kial la datumoj malaperis por la antaŭa monato? Ĉar la defaŭlta retenperiodo estas 1 monato. Tial vi devas scii kaj agordi la ĝustan retenperiodon.
Ni trarigardu la unikajn trajtojn.
Thanos havas funkcion nomatan subspecimeno: 5-minutaj kaj horaj intervaloj, kiuj ofte estas . Se vi guglos kaj rigardas ilian problemon sur github, estas multaj problemoj rilataj al ĉi tiu subspecimeno, ke ĝi foje ne funkcias ĝuste, aŭ ne funkcias kiel uzantoj atendas.
Thanos havas datumduplikadon por Prometheus HA-paroj. Kiam du Prometeo kolektas la samajn metrikojn de la samaj celoj kaj Thanos aldonas ilin al Object Storage. Thanos povas ĝuste dedupliki ĉi tiujn datumojn, male al VictoriaMetrics.
Thanos havas atentan komponanton, kiu estis sur la skemo de Thanos. Sed li .
Thanos havas la avantaĝon, ke Thanos kaj Prometeo dividas la saman kodon. Thanos kaj Prometheus estas evoluigitaj de la samaj programistoj. Kun plibonigoj en Thanos aŭ Prometeo, la alia flanko venkas.
La ĉefa trajto de VictoriaMetrics estas MetricsQL. Ĉi tiuj estas la etendoj de VictoriaMetrics por PromQL, pri kiuj mi parolis ĉe la antaŭa granda monitorado.
VictoriaMetrics subtenas alŝuti datumojn uzante multajn malsamajn protokolojn. VictoriaMetrics povas ne nur ricevi datumojn de Prometheus, sed ankaŭ per la protokoloj Influx, OpenTSDB kaj Graphite.
VictoriaMetrics-datumoj okupas multe malpli da spaco ol Thanos kaj Prometheus.
Skribante realajn datumojn, uzantoj parolas pri 2-5-obla redukto de la grandeco de datumoj sur disko kompare kun Prometheus kaj Thanos.
Alia avantaĝo de VictoriaMetrics estas, ke ĝi estas optimumigita por rapideco.
Ni transiru la koston de infrastrukturo.
Unu el la avantaĝoj de Thanos estas, ke ĝi stokas datumojn en objektostokado, kiu estas relative malmultekosta.
Dum konservado de datumoj en objektostokado, vi devas pagi por datumskribado kaj legado de operacioj ($10 por miliono da operacioj). Kiam vi skribas datumojn al objektostokado, vi pagas viajn gastigajn kostojn por alŝuto de datumoj al Interreto, se via areto ne estas en AWS - ĝi estas senpaga tie. Kiam vi legas datumojn, vi pagas inter $10 kaj $230 por 1TB. Ĉi tio povas esti grava se vi ofte petas historiajn datumojn de la Thanos-areo.
Por Thanos-grupo, vi devas pagi por serviloj por Kompakta, Store Gateway, Query-komponentoj kiuj postulas multan memoron, CPU por grandaj kvantoj da datumoj.
VictoriaMetrics havas la jenajn kostojn. Se vi stokas datumojn sur GCE-HDD-oj, tiam eliras $ 40 por 1TB. Por VictoriaMetrics sufiĉas ordinaraj HDD-diskoj, ne necesas SSD-oj, kiuj kostas kvinoble pli. VictoriaMetrics estas optimumigita por HDD.
VictoriaMetrics bezonas servilojn por komponantoj: aŭ Unu-kapjeto aŭ por amasigitaj komponantoj, kiuj, male al Thanos-komponentoj, postulas multe malpli CPU, RAM - respektive, ĝi estos pli malmultekosta.
Ekzemploj de efektivigo.
Por Thanos, la efektiviga ekzemplo estas Gitlab. Gitlab funkcias tute sur Thanos. Sed ne ĉio estas tiel glata tie. Se vi rigardas ilin , tiam vi povas vidi, ke ili konstante havas kelkajn : Ne sufiĉa memoro por Store Gateway aŭ Query-komponentoj. Ili konstante devas pliigi la kvanton de memoro.
Pro tio, la kostoj de solvi ĉi tiujn problemojn pliiĝas.
La dua efektivigo, kiu povas esti pli sukcesa, estas Neprobabla, kiu komencis la disvolviĝon de Thanos. Ili publikigis la fonton de Thanos. Improbable estas kompanio, kiu disvolvas ludmotorojn.
VictoriaMetrics havas publikajn efektivigajn ekzemplojn kiuj estas:
- Wix-reteja konstruanto
- Adidas efektivigas VictoriaMetrics kaj eĉ faris prezenton ĉe la lasta PromCon 2019
- TrafficStars-reto
- Seznam.cz estas populara ĉeĥa serĉilo.
Kaj tiam estis sennomaj kompanioj, kiujn mi nun ne povas nomi. Ili ne konsentis.
- Unu grava ludprogramisto. Pli granda ol neverŝajna.
- Granda programisto de grafika programaro.
- Granda rusa banko.
- Eŭropa ventoturbina fabrikisto, kiu sukcese testis VictoriaMetrics. Ĉi tiu fabrikisto efektivigas VictoriaMetrics por monitori datumojn de ventoturbinoj kun rapideco de 50 specimenoj je sekundo per sensilo. Ĉiu ventoturbino havas plurcent sensilojn. Ili havas plurcent ventoturbinojn.
- Rusaj aviadkompanioj kiuj volas efektivigi VictoriaMetrics sed ankoraŭ ne povas. Ni estas ĉe la kontraktstadio kun ili.
Konkludoj.
VictoriaMetrics kaj Thanos solvas similajn problemojn, sed en malsamaj manieroj:
- Tutmonda demanda vido
- horizontala skalo
- arbitra reteno
Kontrolo.
Ni atendas vin ĉe nia .
Nur registritaj uzantoj povas partopreni la enketon. , bonvolu.
Kion vi uzas kiel longtempa konservado por Prometheus?
-
35,3%Thanos6
-
0,0%Cortex0
-
0,0%M3DB0
-
41,2%VictoriaMetrics7
-
23,5%aliaj4
17 uzantoj voĉdonis. 16 uzantoj sindetenis.
fonto: www.habr.com