Dag Allemaal. Hieronder vindt u de transcriptie .
– een monitoringsysteem voor verschillende systemen en diensten, met behulp waarvan systeembeheerders informatie kunnen verzamelen over de huidige parameters van systemen en waarschuwingen kunnen instellen om meldingen te ontvangen over afwijkingen in de werking van systemen.
Het rapport zal een vergelijking bevatten и — projecten voor langetermijnopslag van Prometheus-metrieken.
Eerst zal ik je over Prometheus vertellen. Dit is een monitoringsysteem dat statistieken van specifieke doelen verzamelt en deze opslaat in lokale opslag. Prometheus kan meetgegevens opslaan in externe opslag en waarschuwingen en opnameregels genereren.
Prometheus-beperkingen:
- Het heeft geen globale queryweergave. Dit is wanneer je meerdere onafhankelijke exemplaren van prometheus hebt. Ze verzamelen statistieken. En u wilt query's uitvoeren bovenop al deze statistieken die zijn verzameld uit verschillende Prometheus-instanties. Prometheus staat dit niet toe.
- Met prometheus zijn de prestaties beperkt tot slechts één server. Prometheus schaalt niet automatisch over meerdere servers. U kunt uw doelen alleen handmatig verdelen over meerdere Prometheus.
- De reikwijdte van de statistieken in Prometheus is beperkt tot slechts één server, om dezelfde reden dat deze niet automatisch over meerdere servers kan worden geschaald.
- Het is niet zo eenvoudig om de gegevensveiligheid in Prometheus te organiseren.
Oplossingen voor deze problemen/uitdagingen?
De oplossingen zijn:
Al deze oplossingen zijn bedoeld voor het op afstand opslaan van gegevens verzameld door Prometheus. Ze lossen het probleem met externe opslag uit de vorige dia op verschillende manieren op. In deze presentatie zal ik het alleen hebben over de eerste twee oplossingen: и .
Voor het eerst informatie over verscheen door . De architectuur wordt daar beschreven en hoe het werkt.
Thanos neemt de gegevens die Prometheus op de lokale schijf heeft opgeslagen en kopieert deze naar S3, naar of naar een andere objectopslag.
Thanos biedt dus een globaal zoekoverzicht. U kunt gegevens opvragen die zijn opgeslagen in objectopslag vanuit meerdere Prometheus-instanties.
Thanos ondersteunt PromQL en .
Thanos gebruikt Prometheus-code om gegevens op te slaan.
Thanos is ontwikkeld door dezelfde ontwikkelaars als Prometheus.
Про . Hier , waar we het voor het eerst over hadden .
VictoriaMetrics ontvangt gegevens van verschillende prometheus protocol ondersteund door Prometheus.
VictoriaMetrics biedt een globale queryweergave, omdat meerdere Prometheus-instanties gegevens naar één VictoriaMetrics kunnen schrijven. Dienovereenkomstig kunt u vragen stellen over al deze gegevens.
VictoriaMetrics ondersteunt ook, net als Thanos, PromQL en Prometheus, query-API.
In tegenstelling tot Thanos wordt de VictoriaMetrics-broncode helemaal opnieuw geschreven en geoptimaliseerd voor snelheid en hulpbronnengebruik.
VictoriaMetrics schaalt, in tegenstelling tot Thanos, zowel verticaal als horizontaal. Eten , die verticaal schaalt. Je kunt beginnen met één processor en 1 GB geheugen en geleidelijk doorgroeien naar honderden processors en 1 TB geheugen. VictoriaMetrics kan al deze middelen gebruiken. De prestaties zullen ongeveer 100 keer toenemen in vergelijking met een 1-core systeem.
De geschiedenis van Thanos begon in november 2017, toen de eerste openbare commit verscheen. Voordien werd Thanos intern ontwikkeld .
In juni 2019 was er een mijlpaalrelease 0.5.0, waarin protocol. Hij werd verwijderd uit Thanos omdat hij niet goed presteerde. Vaak werkte het Thanos-cluster niet correct, knooppunten waren er verkeerd mee verbonden vanwege het roddelprotocol. Daarom hebben we besloten hem daar weg te halen. Ik denk dat dit de juiste beslissing is.
In hetzelfde juni 2019 stuurden ze het aanvraagnummer в .
En na een paar maanden werd Thanos toegelaten , waaronder Prometheus, Kubernetes en andere populaire projecten.
In januari 2018 begon de ontwikkeling van VictoriaMetrics.
In september 2018 noemde ik VictoriaMetrics voor het eerst publiekelijk.
In december 2018 werd een versie met één knooppunt gepubliceerd.
In mei 2019 bronnen van zowel versies met één knooppunt als clusterversies.
In juni 2019 hebben wij net als Thanos een aanvraag ingediend bij stichting CNCF onder nummer . We hebben ons een dag vóór Thanos aangemeld.
Maar helaas zijn we daar nog steeds niet geaccepteerd. Gemeenschapshulp nodig.
Laten we eens kijken naar de belangrijkste dia's die de architectuur van Thanos en VictoriaMetrics laten zien.
Laten we beginnen met Thanos. De gele componenten zijn Prometheus-componenten. Al het andere zijn Thanos-componenten. Laten we beginnen met het belangrijkste onderdeel. Thanos Sidecar is een onderdeel dat naast elke Prometheus wordt geïnstalleerd. Het laadt Prometheus-gegevens van lokale opslag naar S3 of een andere objectopslag.
Er is ook een component genaamd Thanos Store Gateway, die deze gegevens uit Object Storage kan lezen bij inkomende verzoeken van Thanos Query. Thanos Query implementeert PromQL en Prometheus API. Dat wil zeggen, van buiten lijkt het op Prometheus. Ontvangt PromQL-query's, stuurt deze naar Thanos Store Gateway, Thanos Store Gateway haalt de benodigde gegevens op uit Object Storage en stuurt deze terug.
Maar we slaan gegevens op in Object Storage zonder de laatste twee uur vanwege een functie van de Thanos Sidecar-implementatie, die de laatste twee uur niet kan uploaden naar Object Storage S3, omdat Prometheus voor deze twee uur nog geen bestanden in de lokale opslag heeft aangemaakt.
Hoe heb je besloten dit te omzeilen? Thanos Query stuurt, naast verzoeken aan de Thanos Store Gateway, parallelle verzoeken naar elke Thanos Sidecar, die zich naast Prometheus bevindt.
En Thanos Sidecar stuurt op zijn beurt verzoeken door naar Prometheus en haalt gegevens van de afgelopen twee uur op.
Naast deze componenten is er ook een optioneel onderdeel zonder welke Thanos niet goed zal presteren. Dit is Thanos Compact, die verantwoordelijk is voor het samenvoegen van kleine bestanden op Object Storage tot grotere bestanden die hier door Thanos Sidecars zijn geüpload. Thanos Sidecar uploadt daar in twee uur databestanden. Als deze bestanden niet worden samengevoegd tot grotere bestanden, kan hun aantal aanzienlijk toenemen. Hoe meer van dergelijke bestanden, hoe meer geheugen er nodig is voor Thanos Store Gateway, hoe meer bronnen nodig zijn om gegevens over het netwerk en metadata over te dragen. Thanos Store Gateway wordt niet meer effectief. Daarom is het noodzakelijk om Thanos Compact uit te voeren, dat kleine bestanden samenvoegt tot grotere, zodat er minder van dergelijke bestanden zijn en de overhead op de Thanos Store Gateway wordt verminderd.
Er is ook zo'n component als Thanos Ruler. Het voert Prometheus-waarschuwingsregels uit en kan Prometheus-opnameregels evalueren om gegevens terug te schrijven naar Object Storage. Maar het gebruik van dit onderdeel wordt niet aanbevolen, omdat... Hij .
Dit is het eenvoudige schema van Thanos.
Laten we het nu vergelijken met het VictoriaMetrics-schema.
VictoriaMetrics heeft 2 versies: Single-node- en clusterversie. Single-node draait op één computer. Single-node heeft deze componenten niet, slechts één binair bestand. Dit binaire getal op de dia ziet eruit als dit vierkant. Alles wat zich binnen het vierkant bevindt, is de inhoud van het binaire bestand voor de versie met één knooppunt. Je hoeft niets over hem te weten. Je voert gewoon het binaire bestand uit en alles werkt voor ons.
De clusterversie is ingewikkelder. Daarin zijn er drie verschillende componenten: vmselect, vminsert en vmstorage. Uit hun naam moet duidelijk blijken wat elk van hen doet. De Insert-component accepteert gegevens in verschillende formaten: van de Prometheus remote write API, het Influx line-protocol, het Graphite-protocol en het OpenTSDB-protocol. De Insert-component accepteert ze, parseert ze en distribueert ze tussen bestaande opslagcomponenten, waar de gegevens al zijn opgeslagen. De Select-component accepteert op zijn beurt PromQL-query's. Hij implementeert , evenals de Prometheus-query-API, en deze kan worden gebruikt als vervanging voor Prometheus in Grafana of andere Prometheus API-clients. Select accepteert een promql-verzoek, parseert het, leest de benodigde gegevens voor het uitvoeren van dit verzoek uit opslagknooppunten, verwerkt deze gegevens en retourneert een antwoord.
Laten we de complexiteit van het installeren van Thanos en VictoriaMetrics vergelijken.
Laten we beginnen met Thanos. Voordat je met Thanos aan de slag gaat, moet je een bucket maken in Object Storage, zoals S3 of GCS, zodat Thanos Sidecar er gegevens naartoe kan schrijven.
Vervolgens moet je voor elke Prometheus Thanos Sidecar installeren. Voordat u dit doet, moet u eraan denken om gegevensverdichting in Prometheus uit te schakelen. Bij gegevenscompactie worden gegevens in de lokale Prometheus-opslag periodiek gecomprimeerd om het verbruik van hulpbronnen te verminderen.
Wanneer u Thanos Sidecar op uw Prometheus installeert, moet u deze gegevensverdichting uitschakelen, omdat Thanos Sidecar niet goed werkt als gegevensverdichting is ingeschakeld. Dit betekent dat uw Prometheus gegevens begint op te slaan in blokken van twee uur en stopt met het samenvoegen van die blokken tot grotere blokken. Als u dus zoekopdrachten uitvoert die de duur van de afgelopen twee uur overschrijden, zullen deze niet zo efficiënt werken als ze zouden kunnen werken als gegevenscompressie was ingeschakeld.
Daarom raadt Thanos aan om de bewaartijd voor gegevens in de lokale opslag terug te brengen tot 6-8 uur om de overhead van een groot aantal kleine blokken te verminderen.
Nadat u Thanos Sidecar hebt geïnstalleerd, moet u voor elke Object Storage Bucket twee componenten installeren. Dit zijn Thanos Compactor en Thanos Store Gateway.
Daarna moet je Thanos Query installeren en configureren zodat het verbinding kan maken met alle Thanos Store Gateways die je hebt, en ook met alle Thanos Sidecars.
Er kan hier sprake zijn van een klein probleem.
U moet een betrouwbare en veilige verbinding van Thanos Query met deze componenten configureren. En als uw Prometheus zich in verschillende datacenters of in verschillende VPC's bevindt, zijn verbindingen met deze van buitenaf verboden. Maar om Thanos Query te laten werken, moet je op de een of andere manier de verbinding daar configureren, en je moet een manier bedenken.
Als u veel van dergelijke datacenters heeft, neemt de betrouwbaarheid van het hele systeem dienovereenkomstig af. Omdat Thanos Query voortdurend verbindingen moet onderhouden met alle Thanos Sidecars die zich in verschillende datacenters bevinden. Voor elk binnenkomend verzoek worden de verzoeken doorgestuurd naar alle Thanos Sidecars. Als de verbinding wordt verbroken, ontvangt u ofwel een onvolledige set gegevens, ofwel ontvangt u de reactie ‘cluster is down’.
In VictoriaMetrics is alles een beetje eenvoudiger. Voor de versie met één knooppunt hoeft u slechts één binair bestand uit te voeren en alles werkt.
In de clusterversie is het voldoende om alle bovengenoemde drie typen componenten in elke gewenste hoeveelheid uit te voeren of te gebruiken om de lancering van componenten in Kubernetes te automatiseren. We zijn ook van plan om een Kubernetes-operator te maken. De Helm-kaart dekt sommige gevallen niet en laat je jezelf in de voet schieten. Hiermee kunt u bijvoorbeeld het aantal opslagknooppunten verminderen, wat tot gegevensverlies zal leiden.
Nadat u een binaire of een geclusterde versie hebt gelanceerd, hoeft u alleen maar Prometheus aan de configuratie toe te voegen zodat het parallel begint met het schrijven van gegevens naar lokale opslag en externe opslag. Zoals u kunt zien, zou deze configuratie veel betrouwbaarder moeten presteren in vergelijking met de Thanos-configuratie. We hoeven geen verbinding van VictoriaMetrics met alle Prometheus te onderhouden, omdat Prometheus zelf verbinding maakt met VictoriaMetrics en gegevens verzendt.
Laten we eens kijken naar de steun van Thanos en VictoriaMetrics.
Thanos moet Sidecar in de gaten houden om er zeker van te zijn dat ze niet stoppen met het laden van gegevens in Object Storage. Ze kunnen deze gegevensdownload stopzetten vanwege downloadfouten, bijvoorbeeld als uw netwerkverbinding met Object Storage tijdelijk is onderbroken of Object Storage tijdelijk niet beschikbaar is. Thanos Sidecar zal dit op dit moment merken, een fout melden, crashen en vervolgens niet meer werken. Als u dit niet controleert, stopt u met het overbrengen van gegevens naar Object Storage. Als de bewaartijd verstrijkt (6-8 uur aanbevolen), raakt u gegevens kwijt die niet in Object Storage zijn terechtgekomen.
Thanos-verdichters werken mogelijk niet meer vanwege . Compactors nemen gegevens uit Object Storage en voegen deze samen tot grotere stukken gegevens. Omdat compactors niet gesynchroniseerd zijn met Sidecars kan het volgende gebeuren: Sidecar heeft nog geen tijd gehad om het blok te voltooien, Compactor besluit dat dit blok volledig is uitgeschreven. Compactor begint het te lezen. Het leest het blok niet volledig en stopt met werken. Zie de details .
Store Gateway kan inconsistente gegevens retourneren vanwege races tussen Compactor en Sidecars. Hier gebeurt hetzelfde, omdat de Store Gateway op geen enkele manier gesynchroniseerd is met Compactors en Sidecars. Dienovereenkomstig kunnen er racecondities optreden wanneer de Store Gateway een deel van de gegevens niet ziet of onnodige gegevens ziet.
De Query-component in Thanos retourneert standaard een gedeeltelijk resultaat als sommige Sidecars of Store Gateways op dit moment niet beschikbaar zijn. U ontvangt een deel van de gegevens en u weet niet eens dat u niet alle gegevens heeft ontvangen. Zo werkt het standaard. In een vergelijkbare situatie retourneert VictoriaMetrics gemarkeerde gegevens als gedeeltelijk.
In tegenstelling tot Thanos verliest VictoriaMetrics zelden gegevens. Zelfs als de verbinding van Prometheus met VictoriaMetrics wordt onderbroken, is dit geen probleem, aangezien Prometheus binnenkomende nieuwe gegevens blijft vastleggen in de Write Ahead Log, waarvan de omvang 2 uur bedraagt. Als u binnen twee uur uw verbinding met VictoriaMetrics herstelt, gaan uw gegevens niet verloren. Prometheus .
In tegenstelling tot Thanos, dat gegevens pas na twee uur naar objectopslag schrijft, repliceert Prometheus automatisch gegevens met behulp van het externe schrijfprotocol naar externe opslag, zoals VictoriaMetrics. Je bent niet bang om lokale opslag in Prometheus te verliezen. Als hij plotseling de lokale opslag verliest, verliest u in het ergste geval de laatste seconden aan gegevens die geen tijd hadden om op externe opslag te worden vastgelegd.
Kubernetes beheert het cluster automatisch, in tegenstelling tot Thanos. Het is lastig om alle Thanos-componenten in één Kubernetes-cluster te plaatsen, in tegenstelling tot de VictoriaMetrics-clustercomponenten.
VictoriaMetrics heeft een zeer eenvoudige update naar de nieuwe versie. Stop gewoon VictoriaMetrics, update de binaire bestanden en start het. Wanneer gestopt via een SIGINT-signaal, voeren alle binaire bestanden van VictoriaMetrics een correcte afsluiting uit. Ze slaan de nodige gegevens correct op, sluiten inkomende verbindingen correct af om niets te verliezen. Je verliest dus niets bij het upgraden.
VictoriaMetrics maakt het heel eenvoudig om een cluster uit te breiden. Voeg gewoon de benodigde componenten toe en ga verder met werken.
Over valkuilen in Thanos en VictoriaMetrics.
Thanos heeft de volgende valkuilen. Prometheus moet gegevens van de afgelopen twee uur bewaren. Als ze verloren gaan, ben je ze volledig kwijt omdat ze nog niet naar Object Storage zoals S3 zijn geschreven.
De component Store Gateway en compactor kunnen veel geheugen nodig hebben om met een grote objectopslag te kunnen werken als daar veel kleine bestanden zijn opgeslagen. Hoe groter het aantal en de grootte van de bestanden, hoe meer Store Gateway en compactor RAM nodig zijn om meta-informatie op te slaan. Thanos heeft veel problemen met betrekking tot het feit dat .
Er wordt geadverteerd dat Thanos voor onbepaalde tijd kan worden geschaald met de hoeveelheid Prometheus die je hebt. Dit is eigenlijk niet waar. Omdat alle verzoeken via de Query-component gaan, die tegelijkertijd alle Store Gateway-componenten en alle Sidecar-componenten moet pollen, moet u daar gegevens vandaan halen en deze vervolgens voorbewerken. Uiteraard wordt de verzoeksnelheid beperkt door de langzaamste zwakke schakel, de langzaamste Store Gateway of de langzaamste Sidecar.
Deze componenten kunnen ongelijkmatig worden belast. Je hebt bijvoorbeeld Prometheus, dat miljoenen statistieken per seconde verzamelt. En er is Prometheus, die duizenden statistieken per seconde verzamelt. Prometheus, dat miljoenen statistieken per seconde verzamelt, belast de server waarop het draait veel zwaarder. Dienovereenkomstig werkt Sidecar daar langzamer. En over het algemeen werkt alles daar langzaam. En de Query-component haalt daar heel langzaam gegevens vandaan. Dienovereenkomstig worden de prestaties van uw hele cluster beperkt door deze trage zijspan.
Standaard geeft Thanos gedeeltelijke gegevens als sommige Sidecars en de Store Gateway niet beschikbaar zijn. Als uw Sidecars bijvoorbeeld over de hele wereld verspreid zijn in verschillende datacenters, neemt de kans op een verbindingsfout en het niet beschikbaar zijn van componenten aanzienlijk toe. Dienovereenkomstig ontvangt u in de meeste gevallen gedeeltelijke gegevens zonder dat u het weet.
VictoriaMetrics kent ook valkuilen. De eerste valkuil is de optie die de hoeveelheid RAM beperkt die wordt gebruikt voor de VictoriaMetrics-cache. Standaard is dit gelijk aan 60% van het RAM-geheugen op de machine waarop VictoriaMetrics wordt uitgevoerd of 60% van het RAM-geheugen van de VictoriaMetrics-pod in Kubernetes.
Als u deze waarde verkeerd wijzigt, kunt u de prestaties van VictoriaMetrics verpesten. Als u de waarde bijvoorbeeld te laag instelt, passen de gegevens mogelijk niet meer in de VictoriaMetrics-cache. Hierdoor zal ze extra werk moeten doen en de processor en schijf moeten laden. Als u deze optie te groot maakt, vergroot dit in de eerste plaats de kans dat VictoriaMetrics crasht met een fout dat het geheugen onvoldoende is, en in de tweede plaats zal dit ertoe leiden dat er heel weinig RAM over zal zijn in het geheugen van het besturingssysteem. bestandscache. En VictoriaMetrics vertrouwt voor de prestaties op een bestandscache. Als dit niet genoeg is, kan de belasting van de schijf aanzienlijk toenemen. Daarom advies: verander de parameter niet, tenzij absoluut noodzakelijk.
Tweede optie. Dit is retentiePeriod: een periode die standaard is ingesteld op 1 maand. Dit is de tijdsduur waarin VictoriaMetrics gegevens bewaart. Na deze periode verwijdert VictoriaMetrics de gegevens.
Veel mensen gebruiken VictoriaMetrics zonder deze parameter en registreren gegevens gedurende een maand. En dan vragen ze: waarom zijn de gegevens van de voorgaande maand verdwenen? Omdat de standaardretentieperiode 1 maand is. Daarom moet u de juiste retentiePeriod kennen en instellen.
Laten we eens kijken naar de unieke kenmerken.
Thanos heeft een functie genaamd downsampling: intervallen van 5 minuten en elk uur, wat vaak het geval is . Als je googlet en naar hun probleem op github kijkt, zijn er veel problemen gerelateerd aan deze downsampling, dat het soms niet correct werkt, of niet werkt zoals gebruikers verwachten.
Thanos heeft gegevensontdubbeling voor Prometheus HA-paren. Wanneer twee Prometheus dezelfde statistieken van dezelfde doelen verzamelen en Thanos deze opslaat in Object Storage. Thanos kan deze gegevens goed ontdubbelen, in tegenstelling tot VictoriaMetrics.
Thanos heeft een waarschuwingscomponent die in het Thanos-schema stond. Maar hij .
Thanos heeft het voordeel dat Thanos en Prometheus dezelfde code delen. Thanos en Prometheus zijn ontwikkeld door dezelfde ontwikkelaars. Met verbeteringen aan Thanos of Prometheus wint de andere kant.
Het belangrijkste kenmerk van VictoriaMetrics is MetricsQL. Dit zijn VictoriaMetrics-extensies voor PromQL, waarover ik het had tijdens de vorige grote monitoringmeetup.
VictoriaMetrics ondersteunt het laden van gegevens met behulp van veel verschillende protocollen. VictoriaMetrics kan niet alleen data van Prometheus accepteren, maar ook via de Influx-, OpenTSDB- en Graphite-protocollen.
VictoriaMetrics-gegevens nemen veel minder ruimte in beslag vergeleken met Thanos en Prometheus.
Als je echte gegevens vastlegt, praten gebruikers over een 2-5 keer kleinere hoeveelheid gegevens op schijf vergeleken met Prometheus en Thanos.
Een ander voordeel van VictoriaMetrics is dat het is geoptimaliseerd voor snelheid.
Laten we eens kijken naar de kosten van infrastructuur.
Een van de voordelen van Thanos is dat het gegevens opslaat in objectopslag, wat relatief goedkoop is.
Wanneer u gegevens opslaat in objectopslag, moet u betalen voor het schrijven en lezen van gegevens ($10 per miljoen bewerkingen). Wanneer u gegevens naar objectopslag schrijft, betaalt u uw hostingkosten voor het uploaden van gegevens naar internet; als uw cluster niet in AWS staat, is het daar gratis. Wanneer u gegevens leest, betaalt u tussen de $ 10 en $ 230 per 1 TB. Dit kan van belang zijn als u regelmatig historische gegevens uit het Thanos-cluster opvraagt.
Voor een Thanos-cluster moet je betalen voor servers voor Compact, Store Gateway, Query-componenten die veel geheugen vereisen, en CPU voor grote hoeveelheden gegevens.
VictoriaMetrics heeft de volgende kosten. Als u gegevens opslaat op GCE HDD-schijven, komt dit uit op $ 40 voor 1 TB. Voor VictoriaMetrics zijn gewone HDD-schijven voldoende; er zijn geen SSD's nodig, die vijf keer zo duur zijn. VictoriaMetrics is geoptimaliseerd voor HDD.
VictoriaMetrics heeft servers nodig voor componenten: Single-nod of geclusterde componenten, die, in tegenstelling tot Thanos-componenten, veel minder CPU en RAM nodig hebben - en dienovereenkomstig goedkoper zullen zijn.
Voorbeelden van implementatie.
Thanos heeft een implementatievoorbeeld in Gitlab. Gitlab draait volledig op Thanos. Maar niet alles verloopt daar zo soepel. Als je naar ze kijkt , dan kun je zien dat ze er constant wat hebben : Er is onvoldoende geheugen voor de Store Gateway- of Query-componenten. Ze moeten voortdurend de hoeveelheid geheugen vergroten.
Hierdoor stijgen de kosten voor het oplossen van deze problemen.
De tweede implementatie, die mogelijk succesvoller is, is het bedrijf Improbable, dat Thanos begon te ontwikkelen. Ze publiceerden de Thanos-broncode. Improbable is een bedrijf dat game-engines ontwikkelt.
VictoriaMetrics heeft voorbeelden van openbare implementatie:
- wix.com websitebouwer
- Adidas implementeert VictoriaMetrics en heeft zelfs een presentatie gegeven op de laatste PromCon 2019
- TrafficStars - advertentienetwerk
- Seznam.cz is een populaire Tsjechische zoekmachine.
En toen waren er bedrijven zonder naam die ik nu niet kan noemen. Ze stemden niet in.
- Eén grote game-ontwikkelaar. Groter dan het is onwaarschijnlijk.
- Grote grafische softwareontwikkelaar.
- Grote Russische bank.
- Europese windturbinefabrikant die VictoriaMetrics met succes heeft getest. Deze fabrikant implementeert VictoriaMetrics om gegevens verzameld van windturbines te monitoren met een snelheid van 50 monsters per seconde per sensor. Elke windturbine heeft enkele honderden sensoren. Ze hebben enkele honderden windturbines.
- Russische luchtvaartmaatschappijen die VictoriaMetrics willen implementeren, maar het nog steeds niet kunnen. We bevinden ons in de contractfase met hen.
Conclusies.
VictoriaMetrics en Thanos lossen vergelijkbare problemen op, maar op verschillende manieren:
- Globale queryweergave
- horizontale schaalverdeling
- willekeurige retentie
Dank u.
Wij wachten op u bij ons .
Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. , Alsjeblieft.
Wat gebruiken jullie als langetermijnopslag voor Prometheus?
-
35,3%Thanos6
-
0,0%Cortex0
-
0,0%M3DB0
-
41,2%VictoriaMetrieken7
-
23,5%andere4
17 gebruikers hebben gestemd. 16 gebruikers onthielden zich van stemming.
Bron: www.habr.com