Hi almal. Hieronder is die dekripsie .
– 'n stelsel vir die monitering van verskeie stelsels en dienste, met behulp waarvan stelseladministrateurs inligting oor die huidige parameters van stelsels kan insamel en waarskuwings kan opstel om kennisgewings oor afwykings in die werking van stelsels te ontvang.
Die verslag sal vergelyk и — projekte vir langtermynberging van Prometheus-metrieke.
Kom ek vertel jou eers van Prometheus. Dit is 'n moniteringstelsel wat statistieke van gegewe teikens insamel en dit in plaaslike berging stoor. Prometheus kan metrieke na afgeleë berging skryf, kan waarskuwings genereer en reëls opneem.
Prometheus Beperkings:
- Dit het nie 'n globale navraag-aansig nie. Dit is wanneer jy verskeie onafhanklike prometheus-gevalle het. Hulle versamel maatstawwe. En jy wil navraag doen oor al hierdie statistieke wat uit verskillende prometheus-gevalle versamel is. Prometheus laat dit nie toe nie.
- Met prometheus is werkverrigting beperk tot slegs een bediener. Prometheus kan nie outomaties na verskeie bedieners skaal nie. U kan slegs u teikens met die hand tussen verskeie Prometheus verdeel.
- Die omvang van metrieke in Prometheus is beperk tot slegs een bediener om dieselfde rede dat dit nie outomaties na verskeie bedieners kan skaal nie.
- In Prometheus is dit nie so maklik om die veiligheid van data te organiseer nie.
Oplossings vir hierdie probleme/take?
Oplossings is:
Al hierdie oplossings is vir afstandberging van data wat deur Prometheus ingesamel is. Hulle los die afgeleë bergingsprobleem van die vorige skyfie op verskillende maniere op. In hierdie aanbieding gaan ek net oor die eerste twee oplossings praat: и .
Vir die eerste keer inligting oor verskyn op . Die argitektuur word beskryf en hoe dit werk.
Thanos neem die data wat Prometheus gestoor het na die plaaslike skyf en kopieer dit na S3, of na 'n ander voorwerpberging.
Thanos bied dus 'n globale navraag-aansig. U kan navraag doen oor data wat in objekberging gestoor is vanaf verskeie Prometheus-gevalle.
Thanos ondersteun PromQL en .
Thanos gebruik Prometheus-kode om data te stoor.
Thanos is ontwikkel deur dieselfde ontwikkelaars as Prometheus.
op . hier waaroor ons die eerste keer gepraat het .
VictoriaMetrics ontvang data van verskeie prometheus protokol ondersteun deur Prometheus.
VictoriaMetrics bied 'n globale navraag-aansig, aangesien verskeie Prometheus-gevalle data na 'n enkele VictoriaMetrics kan skryf. Gevolglik kan u navrae oor al hierdie data maak.
VictoriaMetrics ondersteun ook, soos Thanos, PromQL en Prometheus navrae API.
Anders as Thanos, is VictoriaMetrics se bronkode van nuuts af geskryf en geoptimaliseer vir spoed en hulpbronverbruik.
VictoriaMetrics, anders as Thanos, skaal beide vertikaal en horisontaal. Eet , wat vertikaal skaal. Jy kan begin met een verwerker en 1 GB geheue en groei tot honderde verwerkers en 1 TB geheue. VictoriaMetrics weet hoe om al hierdie hulpbronne te gebruik. Sy werkverrigting sal met ongeveer 100 keer toeneem in vergelyking met 'n 1-kern stelsel.
Die geskiedenis van Thanos het in November 2017 begin, toe die eerste openbare verbintenis verskyn het. Voor dit is Thanos intern ontwikkel .
In Junie 2019 was daar 'n landmerkvrystelling 0.5.0, waarin protokol. Hy is van Thanos verwyder omdat hy nie goed gevaar het nie. Dikwels het die Thanos-kluster nie reg gewerk nie, nodusse het verkeerdelik daaraan gekoppel as gevolg van die skinderprotokol. Ons het dus besluit om dit daarvandaan te verwyder. Ek glo dit is die regte besluit.
In dieselfde Junie 2019 het hulle 'n aansoeknommer gestuur в .
En na 'n paar maande is Thanos aanvaar , wat Prometheus, Kubernetes en ander gewilde projekte insluit.
In Januarie 2018 het die ontwikkeling van VictoriaMetrics begin.
In September 2018 het ek VictoriaMetrics die eerste keer in die openbaar genoem.
In Desember 2018 is die Enkelnode-weergawe gepubliseer.
In Mei 2019 bronne van beide enkelnodus- en groepweergawe.
Ons het in Junie 2019, net soos Thanos, 'n aansoek by die CNCF-stigting ingedien onder die nommer . Ons het een dag voor Thanos aansoek gedoen het.
Maar ongelukkig is ons steeds nie daar aanvaar nie. Gemeenskapshulp benodig.
Oorweeg die belangrikste skyfies wat die argitektuur van Thanos en VictoriaMetrics wys.
Kom ons begin met Thanos. Die geel komponente is Prometheus komponente. Al die ander is Thanos-komponente. Kom ons begin met die belangrikste komponent. Thanos Sidecar is 'n komponent wat langs elke Prometheus geïnstalleer word. Dit is verantwoordelik vir die laai van Prometheus-data van plaaslike berging na S3 of ander objekberging.
Daar is ook so 'n komponent soos Thanos Store Gateway, wat hierdie data vanaf Object Storage kan lees op inkomende versoeke van Thanos Query. Thanos Query implementeer PromQL en Prometheus API. Dit wil sê, van buite lyk dit soos Prometheus. Dit aanvaar PromQL-versoeke, stuur dit na Thanos Store Gateway, Thanos Store Gateway kry die nodige data van Object Storage, stuur dit terug.
Maar ons het data gestoor in Object Storage sonder die laaste twee ure as gevolg van die implementering van Thanos Sidecar, wat nie die laaste twee ure na Object Storage S3 kan oplaai nie, aangesien Prometheus nog nie lêers in plaaslike berging geskep het vir hierdie twee ure nie.
Hoe het jy besluit om dit te omseil? Thanos Query, bykomend tot versoeke aan die Thanos Store Gateway, stuur parallelle versoeke na elke Thanos Sidecar wat langs Prometheus is.
En Thanos Sidecar stuur op sy beurt gevolmagtigde versoeke verder na Prometheus, en kry data vir die laaste twee uur.
Benewens hierdie komponente is daar ook 'n opsionele komponent, waarsonder Thanos sleg sal voel. Dit is Thanos Compact, wat klein lêers op Object Storage saamsmelt in groter lêers wat deur Thanos Sidecars hierheen opgelaai is. Thanos Sidecar laai datalêers vir twee uur daarheen op. Hierdie lêers, as hulle nie in groter lêers saamgevoeg word nie, kan hul aantal baie aansienlik groei. Hoe meer sulke lêers, hoe meer geheue word benodig vir Thanos Store Gateway, hoe meer hulpbronne is nodig om data oor die netwerk oor te dra, metadata. Thanos Store Gateway word ondoeltreffend. Daarom is dit nodig om Thanos Compact te laat loop, wat klein lêers in groter lêers saamvoeg, sodat daar minder sulke lêers is en om bokoste op Thanos Store Gateway te verminder.
Daar is ook so 'n komponent soos Thanos Ruler. Dit voer Prometheus-waarskuwingsreëls uit en kan Prometheus-opnamereëls bereken om data terug te skryf na Object Storage. Maar hierdie komponent word nie aanbeveel om gebruik te word nie, want. Hy .
Hier is 'n eenvoudige skema vir Thanos.
Kom ons vergelyk nou met die VictoriaMetrics-skema.
VictoriaMetrics het 2 weergawes: Enkelnode en cluster weergawe. Enkelnode loop op een rekenaar. Enkelnode het nie hierdie komponente nie, net een binêre. Hierdie binêre op die skyfie lyk soos hierdie vierkant. Alles binne die vierkant is die inhoud van die binêre lêer vir die Enkelnode-weergawe. Jy hoef nie daarvan te weet nie. Begin net die binêre - en alles werk vir ons.
Die groepweergawe is moeiliker. Binne dit is drie verskillende komponente: vmselect, vminsert en vmstorage. Uit hul naam behoort dit duidelik te wees wat elkeen van hulle doen. Die Insert-komponent aanvaar data in verskillende formate: van die Prometheus-afstandskryf-API, die Influx-lynprotokol, die Graphite-protokol en die OpenTSDB-protokol. Die Insert-komponent aanvaar hulle, ontleed hulle en versprei dit onder die bestaande stoorkomponente, waar die data reeds gestoor is. Die Select-komponent aanvaar op sy beurt PromQL-versoeke. Dit implementeer , sowel as die Prometheus-navraag-API, en kan gebruik word as 'n plaasvervanger vir Prometheus in Grafana of ander Prometheus API-kliënte. Select neem 'n promql-versoek, ontleed dit, lees die nodige data om hierdie versoek vanaf stoornodusse uit te voer, verwerk hierdie data en gee 'n antwoord terug.
Kom ons vergelyk die kompleksiteit van die installering van Thanos en VictoriaMetrics.
Kom ons begin met Thanos. Voordat jy met Thanos begin werk, moet jy 'n emmer in Object Storage skep, soos S3 of GCS, sodat Thanos Sidecar data daar kan skryf.
Dan moet jy vir elke Prometheus Thanos Sidecar installeer. Voor dit moet jy onthou om dataverdigting in Prometheus uit te skakel. Datakompaksie pers data van tyd tot tyd in Prometheus plaaslike berging saam om hulpbronverbruik te verminder.
Wanneer jy Thanos Sidecar op jou Prometheus installeer, moet jy hierdie datakompaksie deaktiveer omdat Thanos Sidecar nie behoorlik werk met datakompaksie geaktiveer nie. Dit beteken dat jou Prometheus data in blokke van twee uur begin stoor en ophou om hierdie blokke in groteres saam te voeg. Gevolglik, as jy versoeke rig wat die duur van die afgelope twee uur oorskry, sal hulle nie so doeltreffend werk as wat hulle sou kon werk as dataverdigting geaktiveer is nie.
Daarom beveel Thanos aan om die data-retensietyd in plaaslike berging na 6-8 uur te verminder om hierdie bokoste van 'n groot aantal klein blokkies te verminder.
Nadat jy Thanos Sidecar geïnstalleer het, moet jy twee komponente vir elke Object Storage Emmer installeer. Dit is Thanos Compactor en Thanos Store Gateway.
Daarna moet jy Thanos Query installeer en dit opstel sodat dit kan koppel aan alle Thanos Store Gateways wat jy het, sowel as om aan alle Thanos Sidecars te kan koppel.
Daar is dalk 'n klein probleem hier.
U moet 'n betroubare en veilige verbinding vanaf Thanos Query na hierdie komponente opstel. En as u Prometheus'y in verskillende datasentrums of in verskillende VPC's het, is verbindings van buite af met hulle verbied. Maar vir Thanos Query om te werk, moet jy op een of ander manier die verbinding daar konfigureer, en jy moet 'n manier vind.
As u baie sulke datasentrums het, neem die betroubaarheid van die hele stelsel dienooreenkomstig af. Aangesien Thanos Query voortdurend verbindings moet hou met alle Thanos Sidecars wat in verskillende datasentrums geleë is. Met elke inkomende versoek sal dit versoeke aan alle Thanos Sidecars stuur. As die verbinding onderbreek word, sal jy óf 'n onvolledige datastel ontvang, óf jy sal 'n antwoord ontvang "die groep werk nie".
In VictoriaMetrics is dinge 'n bietjie eenvoudiger. Vir die enkel-node weergawe, hardloop net een binêre en alles werk.
In die gegroepeerde weergawe is dit genoeg om al die bogenoemde drie tipes komponente uit te voer in enige hoeveelheid wat jy nodig het, of gebruik om die bekendstelling van komponente in Kubernetes te outomatiseer. Ons beplan ook om 'n Kubernetes-operateur te maak. Roerkaart dek nie sommige gevalle nie en laat jou toe om jou voet te skiet. Dit laat jou byvoorbeeld toe om die aantal stoornodusse te verminder, wat tot dataverlies sal lei.
Nadat u een binêre of gegroepeerde weergawe bekendgestel het, hoef u net by die Prometheus-konfigurasie te voeg sodat dit begin om data parallel met plaaslike berging en afgeleë berging te skryf. Soos u kan sien, behoort hierdie konfigurasie baie meer betroubaar te werk as die Thanos-konfigurasie. Ons hoef nie 'n verbinding van VictoriaMetrics na alle Prometheus's te hou nie, want Prometheus's koppel self aan VictoriaMetrics en dra data oor.
Oorweeg ondersteuning vir Thanos en VictoriaMetrics.
Thanos moet Sidecar dophou sodat hulle nie ophou om data na Object Storage op te laai nie. Hulle kan hierdie data-aflaai stop as gevolg van aflaaifoute, soos jou netwerkverbinding met Object Storage is tydelik verlore, of Object Storage is tydelik onbeskikbaar. Thanos Sidecar sal dit op hierdie stadium opmerk, 'n fout rapporteer, kan ineenstort en dan ophou werk. As jy dit nie monitor nie, sal jou data nie meer na Object Storage oorgedra word nie. As die retensietyd verbygaan (6-8 uur word aanbeveel), sal jy data verloor wat nie in Object Storage beland het nie.
Thanos kompakteerders kan ophou werk a.g.v . Kompaktors neem data uit Object Storage en voeg dit saam in groter stukke data. Aangesien die kompakteerders nie met die Sidecars gesinchroniseer is nie, kan die volgende gebeur: die Sidecar het nog nie tyd gehad om die blok by te voeg nie, die Compactor besluit dat hierdie blok volledig geskryf is. Compactor begin dit lees. Dit lees die blok onvolledig en hou op werk. Sien besonderhede .
Store Gateway kan inkonsekwente data terugstuur as gevolg van resies tussen Compactor en Sidecars. Dit is dieselfde ding hier, want Store Gateway is op geen manier met Compactors en Sidecars gesinchroniseer nie. Gevolglik kan wedrentoestande voorkom wanneer die Store Gateway nie 'n deel van die data sien nie, of ekstra data sien.
Die Navraag-komponent in Thanos gee by verstek 'n gedeeltelike resultaat as sommige Sidecars of Store Gateways nie op die oomblik beskikbaar is nie. Jy sal van die data ontvang, en sal nie eers weet dat jy nie al die data ontvang het nie. Dit is hoe dit by verstek werk. In 'n soortgelyke situasie gee VictoriaMetrics gemerkte data as gedeeltelik terug.
Anders as Thanos, verloor VictoriaMetrics selde data. Selfs as die verbinding van Prometheus na VictoriaMetrics onderbreek word, is dit nie 'n probleem nie, aangesien Prometheus voortgaan om inkomende nuwe data na die Write Ahead Log te skryf, wat 2 uur lank is. As jy die verbinding met VictoriaMetrics binne twee uur herstel, sal die data nie verlore gaan nie. Prometheus .
Anders as Thanos, wat data eers na twee uur na objekberging skryf, repliseer Prometheus outomaties data via afstandskryfprotokol na afgeleë berging, soos VictoriaMetrics. Jy is nie bang om plaaslike berging in Prometheus te verloor nie. As hy skielik plaaslike berging verloor het, sal jy in die ergste geval die laaste sekondes se data verloor wat nie tyd gehad het om na afgeleë berging te skryf nie.
Kubernetes bestuur die groep outomaties anders as Thanos. Dit is moeilik om alle Thanos-komponente in een Kubernetes-kluster te plaas, anders as VictoriaMetrics-klusterkomponente.
VictoriaMetrics het 'n baie maklike opgradering na die nuwe weergawe. Stop net VictoriaMetrics, werk die binaries op en begin. Wanneer dit via 'n SIGINT-sein gestop word, doen alle VictoriaMetrics-binaries 'n grasieuse afsluiting. Hulle stoor die nodige data korrek, sluit inkomende verbindings korrek om niks te verloor nie. Jy sal dus niks verloor wanneer jy opgradeer nie.
Dit is baie maklik vir VictoriaMetrics om die groep uit te brei. Voeg net die nodige komponente by en hou aan werk.
Oor slaggate in Thanos en VictoriaMetrics.
Thanos het die volgende slaggate. Prometheus behoort data vir die laaste twee uur te stoor. As hulle verlore raak, sal jy hulle heeltemal verloor, aangesien hulle nie tyd gehad het om na Object Storage, soos S3, te skryf nie.
Die Store Gateway-komponent en kompakteerder-komponent kan geheue-intensief wees om groot voorwerpberging te hanteer as daar baie klein lêers daar gestoor is. Hoe groter die aantal en grootte van lêers, hoe meer RAM benodig die Store Gateway en kompakteerder om meta-inligting te stoor. Thanos het baie probleme oor wat .
Thanos word geadverteer dat hy onbepaald kan skaal volgens die aantal Prometheus wat jy het. Eintlik is dit nie waar nie. Aangesien alle versoeke deur die Query-komponent gaan, wat alle Store Gateway-komponente en alle Sidecar-komponente parallel moet ondersoek, onttrek data daarvandaan en verwerk dit dan vooraf. Dit is duidelik dat die tempo van versoeke beperk word deur die stadigste swak skakel, die stadigste Winkelpoort of die stadigste Sidecar.
Hierdie komponente kan oneweredig gelaai wees. Byvoorbeeld, jy het Prometheus, wat miljoene metrieke per sekonde versamel. En daar is Prometheus, wat duisende metrieke per sekonde versamel. Prometheus, wat miljoene statistieke per sekonde insamel, laai die bediener waarop dit loop baie meer. Gevolglik is Sidecar daar stadiger. En oor die algemeen is alles daar stadig. En die Query-komponent sal data baie stadig van daar af trek. Gevolglik sal die werkverrigting van jou hele groep beperk word deur hierdie stadige Sidecar.
By verstek gee Thanos gedeeltelike data terug as sommige Sidecars en óf winkelpoorte nie beskikbaar is nie. Byvoorbeeld, as jy Sidecars het wat oor die wêreld versprei is in verskillende datasentrums, dan neem die waarskynlikheid van 'n ontkoppeling en onbeskikbaarheid van komponente aansienlik toe. Gevolglik sal jy in die meeste gevalle gedeeltelike data ontvang sonder dat jy dit eers weet.
VictoriaMetrics het ook slaggate. Die eerste slaggat is 'n opsie wat die hoeveelheid RAM wat vir die VictoriaMetrics-kas gebruik word, beperk. Dit is verstek na 60% RAM op die masjien waar VictoriaMetrics loop, of 60% RAM op die VictoriaMetrics-peul in Kubernetes.
As jy hierdie waarde verkeerd verander, kan jy die prestasie van VictoriaMetrics verwoes. Byvoorbeeld, as die waarde te laag gestel is, pas die data dalk nie meer in die VictoriaMetrics-kas nie. As gevolg hiervan sal sy ekstra werk moet doen en die verwerker met die skyf moet laai. As jy hierdie opsie te groot maak, verhoog dit eerstens die waarskynlikheid dat VictoriaMetrics sal ineenstort met 'n gebrek aan geheue, en tweedens sal dit lei tot die feit dat die bedryfstelsel baie min RAM oor sal hê. geheue vir die lêer kas. En VictoriaMetrics maak staat op die lêerkas vir prestasie. As dit nie genoeg is nie, kan die las op die skyf aansienlik toeneem. Daarom, raad: moenie die parameter verander nie, tensy dit absoluut noodsaaklik is.
Tweede opsie. Hierdie retensietydperk is 'n tydperk wat by verstek op 1 maand gestel is. Dit is die tyd waartydens VictoriaMetrics die data hou. Na hierdie tydperk vee VictoriaMetrics die data uit.
Baie mense bestuur VictoriaMetrics sonder hierdie opsie en teken data vir 'n maand aan. En dan vra hulle: hoekom het die data vir die vorige maand verdwyn? Omdat die verstekbehoudtydperk 1 maand is. Daarom moet u die korrekte retensieperiode ken en instel.
Kom ons gaan deur die unieke kenmerke.
Thanos het 'n kenmerk genaamd downsampling: 5-minute en uurlikse intervalle, wat dikwels is . As jy google en na hul probleem op github kyk, is daar baie probleme wat verband hou met hierdie afname, dat dit soms nie reg werk nie, of nie werk soos gebruikers verwag nie.
Thanos het data-deduplisering vir Prometheus HA-pare. Wanneer twee Prometheus dieselfde maatstawwe van dieselfde teikens versamel en Thanos dit by Object Storage voeg. Thanos kan hierdie data behoorlik ontduik, anders as VictoriaMetrics.
Thanos het 'n waarskuwingskomponent wat op die Thanos-skema was. Maar hy .
Thanos het die voordeel dat Thanos en Prometheus dieselfde kode deel. Thanos en Prometheus word deur dieselfde ontwikkelaars ontwikkel. Met verbeterings in Thanos of Prometheus wen die ander kant.
VictoriaMetrics se hoofkenmerk is MetricsQL. Dit is die VictoriaMetrics-uitbreidings vir PromQL, waaroor ek by die vorige groot moniteringsmetup gepraat het.
VictoriaMetrics ondersteun die oplaai van data deur baie verskillende protokolle te gebruik. VictoriaMetrics kan nie net data van Prometheus ontvang nie, maar ook via die Influx-, OpenTSDB- en Graphite-protokolle.
VictoriaMetrics-data neem baie minder spasie op as Thanos en Prometheus.
Wanneer regte data geskryf word, praat gebruikers van 'n 2-5-voudige vermindering in datagrootte op skyf in vergelyking met Prometheus en Thanos.
Nog 'n voordeel van VictoriaMetrics is dat dit geoptimaliseer is vir spoed.
Kom ons gaan oor die koste van infrastruktuur.
Een van die voordele van Thanos is dat dit data in objekberging stoor, wat relatief goedkoop is.
Wanneer u data in objekberging stoor, moet u betaal vir dataskryf- en leesbewerkings ($10 per miljoen bewerkings). Wanneer jy data na objekberging skryf, betaal jy vir jou gasheerkoste vir die oplaai van data na die internet, as jou cluster nie in AWS is nie – dit is gratis daar. Wanneer jy data lees, betaal jy tussen $10 en $230 vir 1TB. Dit kan betekenisvol wees as jy gereeld historiese data van die Thanos-groepering aanvra.
Vir 'n Thanos-kluster moet jy betaal vir bedieners vir Compact, Store Gateway, Query-komponente wat baie geheue benodig, SVE vir groot hoeveelhede data.
VictoriaMetrics het die volgende koste. As jy data op GCE HDD's stoor, kom $40 vir 1TB uit. Vir VictoriaMetrics is gewone HDD-aandrywers genoeg, geen SSD's is nodig nie, wat vyf keer meer kos. VictoriaMetrics is geoptimaliseer vir HDD.
VictoriaMetrics benodig bedieners vir komponente: óf Enkel-knik óf vir gegroepeerde komponente, wat, anders as Thanos-komponente, baie minder SVE, RAM vereis - onderskeidelik, dit sal goedkoper wees.
Implementeringsvoorbeelde.
Vir Thanos is die implementeringsvoorbeeld Gitlab. Gitlab loop geheel en al op Thanos. Maar nie alles is so glad daar nie. As jy na hulle kyk , dan kan jy sien dat hulle gedurig 'n paar het : Nie genoeg geheue vir Store Gateway of Query-komponente nie. Hulle moet voortdurend die hoeveelheid geheue verhoog.
As gevolg hiervan neem die koste om hierdie probleme op te los.
Die tweede implementering, wat meer suksesvol kan wees, is Improbable, wat die ontwikkeling van Thanos begin het. Hulle het die Thanos-bron vrygestel. Improbable is 'n maatskappy wat speletjie-enjins ontwikkel.
VictoriaMetrics het openbare implementeringsvoorbeelde wat is:
- wix webwerf bouer
- Adidas implementeer VictoriaMetrics en het selfs 'n aanbieding by die laaste PromCon 2019 gemaak
- TrafficStars-advertensie netwerk
- Seznam.cz is 'n gewilde Tsjeggiese soekenjin.
En dan was daar geen-naam maatskappye wat ek nie nou kan noem nie. Hulle het nie saamgestem nie.
- Een groot speletjie-ontwikkelaar. Groter as onwaarskynlik.
- Groot ontwikkelaar van grafiese sagteware.
- Groot Russiese bank.
- Europese windturbinevervaardiger wat VictoriaMetrics suksesvol getoets het. Hierdie vervaardiger implementeer VictoriaMetrics om windturbinedata teen 'n tempo van 50 monsters per sekonde per sensor te monitor. Elke windturbine het etlike honderde sensors. Hulle het 'n paar honderd windturbines.
- Russiese lugrederye wat VictoriaMetrics wil implementeer, maar steeds nie kan nie. Ons is in die kontrakstadium met hulle.
Gevolgtrekkings.
VictoriaMetrics en Thanos los soortgelyke probleme op, maar op verskillende maniere:
- Globale navraag-aansig
- horisontale skaal
- arbitrêre retensie
Dankie.
Ons wag vir jou op ons .
Slegs geregistreerde gebruikers kan aan die opname deelneem. , asseblief.
Wat gebruik jy as langtermynberging vir Prometheus?
35,3%Thanos6
0,0%Korteks0
0,0%M3DB0
41,2%VictoriaMetrics7
23,5%ander 4
17 gebruikers het gestem. 16 gebruikers het buite stemming gebly.
Bron: will.com
