{"id":94153,"date":"2020-09-13T19:42:30","date_gmt":"2020-09-13T17:42:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev"},"modified":"2020-09-13T19:42:30","modified_gmt":"2020-09-13T17:42:30","slug":"victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev","title":{"rendered":"VictoriaMetrics og overv\u00e5gning af private skyer. Pavel Kolobaev","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"VictoriaMetrics<\/p>\n

<\/p>\n

VictoriaMetrics \u2014 en hurtig og skalerbar database til lagring og behandling af data i form af tidsserier (en optagelse udg\u00f8r tid og et s\u00e6t af v\u00e6rdier, der svarer til dette tidspunkt, for eksempel opn\u00e5et gennem periodiske foresp\u00f8rgsler af sensorernes tilstand eller indsamling af m\u00e5linger).<\/p>\n

<\/a><\/noindex>
\n

\r\n \"Afspil\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Mit navn er Kolobaev Pavel. DevOps, SRE, LeroyMerlin, alt som kode \u2013 det handler alt sammen om os: om mig og andre medarbejdere hos LeroyMerlin.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

https:\/\/bit.ly\/3jf1fIK<\/a><\/noindex><\/p>\n

<\/p>\n

Der er en sky baseret p\u00e5 OpenStack. Her er et lille link til teknologiradar. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Det er bygget p\u00e5 hardware fra Kubernetes, samt alle tilknyttede tjenester til OpenStack og logning. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Skemaet var s\u00e5ledes, da vi udviklede det. Da vi udviklede alt dette, havde vi en Prometheus-operator, der opbevarede data inden for selve K8s-klyngen. Den finder automatisk det, der skal scrapes, og l\u00e6gger det for sig selv, groft sagt. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Alle data skal vi flytte ud af Kubernetes-klyngen, fordi hvis noget g\u00e5r galt, skal vi forst\u00e5, hvad der er sket og hvor. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Den f\u00f8rste l\u00f8sning \u2013 vi bruger federation, n\u00e5r vi har en ekstern Prometheus, n\u00e5r vi tilg\u00e5r klyngen Kubernetes gennem federation-mekanismen.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Men der opst\u00e5r sm\u00e5 problemer. I vores tilf\u00e6lde startede problemerne, da vi havde 250.000 m\u00e5linger, og da der blev 400.000 m\u00e5linger, inds\u00e5 vi, at vi ikke kunne arbejde p\u00e5 denne m\u00e5de. Vi \u00f8gede scrape_timeout til 25 sekunder.<\/p>\n

<\/p>\n

Hvorfor m\u00e5tte vi g\u00f8re dette? Prometheus begynder at t\u00e6lle timeout-tiden fra det \u00f8jeblik, dataene indsamles. Og det betyder ikke noget, at dataene stadig str\u00f8mmer. Hvis dataene ikke er blevet indsamlet, og sessionen ikke lukkes via http i den angivne tidsperiode, betragtes sessionen som mislykket, og dataene kommer ikke ind i selve Prometheus.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Alle er bekendt med de grafer, vi f\u00e5r, n\u00e5r nogle data mangler. Graferne er uj\u00e6vne, og det er ikke acceptabelt for os. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Den n\u00e6ste mulighed \u2013 det er sharding baseret p\u00e5 to forskellige Prometheus gennem den samme federation-mekanisme.<\/p>\n

<\/p>\n

For eksempel bare tage dem og shardere dem efter navn. Det kan ogs\u00e5 bruges, men vi besluttede at tage et skridt videre. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Vi bliver nu n\u00f8dt til at h\u00e5ndtere disse shards p\u00e5 en eller anden m\u00e5de. Vi kan tage promxy, som g\u00e5r ind i shardomr\u00e5det og multiplerer data. Den fungerer med to shards som et enkelt adgangspunkt. Det kan realiseres gennem promxy, men er stadig for kompliceret. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Den f\u00f8rste mulighed \u2013 vi \u00f8nsker at afst\u00e5 fra federation-mekanismen, fordi den er meget langsom. <\/p>\n

<\/p>\n

Udviklerne af Prometheus siger tydeligt: \u201eFolk, brug andre TimescaleDB, fordi vi ikke vil st\u00f8tte langvarig opbevaring af m\u00e5linger.\u201c Det er ikke deres opgave. \"VictoriaMetrics<\/p>\n

<\/p>\n

Vi noterer p\u00e5 papir, at vi faktisk har brug for en ekstern eksport, s\u00e5 vi ikke opbevarer alt p\u00e5 \u00e9t sted. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Den anden ulempe er hukommelsesforbruget. Ja, jeg forst\u00e5r, at mange vil sige, at et par gigabyte hukommelse i 2020 er billigere, men det er stadigv\u00e6k. <\/p>\n

<\/p>\n

I \u00f8jeblikket har vi et udviklings- og produktionsmilj\u00f8. I udviklingen er der omkring 9 gigabyte for 350.000 m\u00e5linger. I produktion er der lidt over 14 gigabyte for 780.000 m\u00e5linger. Samtidig har vi kun 30 minutters retention-tid. Det er ikke godt. Og jeg vil nu forklare hvorfor.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Vi laver beregninger, dvs. med halvanden million m\u00e5linger, som vi allerede n\u00e6sten er ved at n\u00e5, har vi under designfasen beregnet 35-37 gigabyte hukommelse. Men allerede ved 4 millioner m\u00e5linger kr\u00e6ves der omkring 90 gigabyte hukommelse. Dvs. dette er blevet beregnet ud fra den formel, som udviklerne af Prometheus giver. Vi har set p\u00e5 korrelationen og indset, at vi ikke \u00f8nsker at betale et par millioner for en server bare til overv\u00e5gning. <\/p>\n

<\/p>\n

Vi f\u00e5r ikke bare flere maskiner, vi overv\u00e5ger ogs\u00e5 de virtuelle maskiner. Derfor, jo flere virtuelle maskiner, jo flere m\u00e5linger af forskellige arter osv. Vi vil have en specifik v\u00e6kst af vores klynge i forhold til m\u00e5linger.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Med diskpladsen er der ikke s\u00e5 meget galt, men vi ville gerne se en forbedring. Vi har samlet 120 gigabyte over 15 dage, hvoraf 100 er komprimerede data, 20 er ukomprimerede data, men man \u00f8nsker altid mindre. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Derfor skriver vi ogs\u00e5 et punkt ned \u2013 der er et stort forbrug af ressourcer, som vi gerne vil spare, fordi vi ikke \u00f8nsker, at vores overv\u00e5gningsklynge bruger flere ressourcer end vores klynge, der h\u00e5ndterer OpenStack.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Der er en anden ulempe ved Prometheus, som vi har identificeret, og det er et eller andet begr\u00e6nsning p\u00e5 hukommelsen. Med Prometheus er det meget v\u00e6rre, fordi der faktisk ikke er s\u00e5danne indstillinger. At bruge begr\u00e6nsninger i Docker er heller ikke en l\u00f8sning. Hvis din RAF falder og der er 20-30 gigabyte, vil det tage meget lang tid at komme op igen. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Det er endnu en grund til, at Prometheus ikke er passende for os, dvs. man kan ikke begr\u00e6nse hukommelsesforbruget. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Man kunne g\u00e5 tilbage til denne ordning. Denne ordning er n\u00f8dvendig for at organisere et HA-kluster. Vi \u00f8nsker, at vores m\u00e5linger altid skal v\u00e6re tilg\u00e6ngelige, selv hvis serveren, der gemmer disse m\u00e5linger, g\u00e5r ned. Derfor er vi n\u00f8dt til at bygge en s\u00e5dan ordning. <\/p>\n

<\/p>\n

Denne ordning betyder, at vi vil have duplikater af shards og dermed ogs\u00e5 duplikation af de ressourcer, der forbruges. Den kan n\u00e6sten skaleres horisontalt, men forbruget af ressourcer vil stadig v\u00e6re enormt. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Ulemperne i den r\u00e6kkef\u00f8lge, som vi har skrevet dem ned:<\/p>\n

<\/p>\n