{"id":52113,"date":"2019-11-01T00:00:00","date_gmt":"2019-10-31T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik"},"modified":"2020-02-18T13:59:47","modified_gmt":"2020-02-18T10:59:47","slug":"bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik","title":{"rendered":"Bioyino \u2014 en distribueret, skalerbar metrics aggregator","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

S\u00e5, du indsamler metrics. Ligesom os. Vi indsamler ogs\u00e5 metrics. Selvf\u00f8lgelig dem, der er n\u00f8dvendige for forretningen. I dag vil vi fort\u00e6lle om det f\u00f8rste led i vores overv\u00e5gningssystem - en statsd-kompatibel aggregationsserver. bioyino<\/a><\/noindex>, hvorfor vi skrev den, og hvorfor vi opgav brubeck. <\/p>\n

<\/p>\n

\"Bioyino<\/p>\n

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

Fra vores tidligere artikler (1<\/a><\/noindex>, 2<\/a><\/noindex>) kan du finde ud af, at vi indtil for nylig indsamlede labels ved hj\u00e6lp af brubeck<\/a><\/noindex>. Den er skrevet i C. Set fra et kodeperspektiv er den simpel som en prop (det er vigtigt, n\u00e5r du \u00f8nsker at bidrage), og vigtigst af alt, den h\u00e5ndterer vores volumener p\u00e5 2 millioner metrics per sekund (MPS) i spidsbelastninger uden st\u00f8rre problemer. Dokumentationen angiver st\u00f8tte til 4 millioner MPS med en anm\u00e6rkning. Det betyder, at du f\u00e5r det angivne tal, hvis du konfigurerer netv\u00e6rket korrekt p\u00e5 Linux. (Hvor mange MPS man kan f\u00e5, hvis man lader netv\u00e6rket v\u00e6re som det er, ved vi ikke). P\u00e5 trods af disse fordele havde vi flere alvorlige klager over brubeck.<\/p>\n

<\/p>\n

Klager 1.<\/em> Github - udvikleren af projektet - har stoppet underst\u00f8ttelsen: offentligg\u00f8re patches og fixes, acceptere vores og (ikke kun vores) PR. I de sidste par m\u00e5neder (cirka siden februar-marts 2018) er aktiviteten genoptaget, men f\u00f8r det var der n\u00e6sten to \u00e5rs total stilhed. Desuden udvikles projektet til interne behov hos Github<\/a><\/noindex>, hvilket kan v\u00e6re en alvorlig hindring for implementeringen af nye funktioner.<\/p>\n

<\/p>\n

Klager 2.<\/em> N\u00f8jagtigheden af beregninger. Brubeck indsamler kun 65,536 v\u00e6rdier til aggregation. I vores tilf\u00e6lde kan der komme meget flere v\u00e6rdier inden for aggregationsperioden (30 sekunder) for nogle metrics (1,527,392 i spidsbelastning). Som f\u00f8lge af denne sampling ser maksimums- og minimumsv\u00e6rdierne ubrugelige ud. For eksempel s\u00e5dan her: <\/p>\n

<\/p>\n

\"Bioyino
\nHvordan det var<\/em><\/p>\n

<\/p>\n

\"Bioyino
\nHvordan det skulle have v\u00e6ret<\/em><\/p>\n

<\/p>\n

Af samme grund beregnes summen overhovedet forkert. Tilf\u00f8j her en bug med overfyldning af 32-bit float, der sender serveren i segfault, n\u00e5r den modtager en tilsyneladende uskyldig metric, og det bliver endnu bedre. Bugen, for \u00f8vrigt, er stadig ikke rettet.<\/p>\n

<\/p>\n

Og til sidst, Klager X<\/em>. P\u00e5 tidspunktet for skrivelsen er vi klar til at pr\u00e6sentere den for alle 14 mere eller mindre fungerende implementeringer af statsd, som vi har v\u00e6ret i stand til at finde. Lad os forestille os, at en bestemt infrastruktur er vokset s\u00e5 meget, at 4 millioner MPS ikke l\u00e6ngere er tilstr\u00e6kkeligt. Eller m\u00e5ske er den endnu ikke vokset, men metrics er allerede s\u00e5 vigtige for dig, at selv kortvarige, 2-3 minutters nedbrud p\u00e5 graferne kan blive kritiske og for\u00e5rsage ubarmhjertig depression blandt ledere. Da behandling af depression er en utaknemmelig opgave, er tekniske l\u00f8sninger n\u00f8dvendige.<\/p>\n

<\/p>\n

For det f\u00f8rste fejltolerance, s\u00e5 en pludselig problem med serveren ikke for\u00e5rsager et psykiatrisk zombie-apokalypse p\u00e5 kontoret. For det andet skal der v\u00e6re skalerbarhed, s\u00e5 vi kan h\u00e5ndtere mere end 4 millioner MPS uden at grave dybt i Linux-netv\u00e6rksstakken og vokse \"udad\" til de n\u00f8dvendige st\u00f8rrelser.<\/p>\n

<\/p>\n

Da vi havde noget overskud til skalerbarhed, besluttede vi at starte med fejltolerance. \"\u00c5h! Fejltolerance! Det er let, det kan vi!\" t\u00e6nkte vi og startede 2 servere, og k\u00f8rte en kopi af brubeck p\u00e5 hver. For at g\u00f8re dette m\u00e5tte vi kopiere trafik med metrics til begge servere og endda skrive en lille v\u00e6rkt\u00f8j<\/a><\/noindex>. Vi l\u00f8ste problemet med fejltolerance med dette, men\u2026 ikke s\u00e6rlig godt. F\u00f8rst var alt tilsyneladende fint: hver brubeck indsamler sin egen variant af aggregation, skriver data til Graphite hvert 30. sekund, og overskriver det gamle interval (dette g\u00f8res p\u00e5 Graphite-siden). Hvis en af serverne skulle svigte, har vi altid den anden med sin egen kopi af de aggregerede data. Men her er problemet: hvis serveren svigter, opst\u00e5r der en \"sav\" p\u00e5 graferne. Dette er relateret til, at de 30-sekunders intervaller hos brubeck ikke er synkroniserede, og p\u00e5 tidspunktet for nedbruddet overskrives en af dem ikke. Det samme sker ved opstarten af den anden server. Det er t\u00e5leligt, men vi \u00f8nsker mere! Problemet med skalerbarhed er heller ikke forsvundet. Alle metrics er stadig \"p\u00e5 vej\" til en enkelt server, og derfor er vi begr\u00e6nset af de samme 2-4 millioner MPS, alt efter hvordan netv\u00e6rket er opgraderet.<\/p>\n

<\/p>\n

N\u00e5r man t\u00e6nker lidt over problemet og samtidig graver sne med en spade, kan en \u00e5benlys id\u00e9 komme frem: der er brug for en statsd, der kan fungere i distribueret tilstand. Det vil sige en, hvor synkronisering mellem noder er implementeret baseret p\u00e5 tid og m\u00e5linger. \"Selvf\u00f8lgelig er der sikkert allerede en s\u00e5dan l\u00f8sning,\" sagde vi og gik i gang med at google... og fandt ingenting. Efter at have gennemg\u00e5et dokumentationen for forskellige statsd (https:\/\/github.com\/etsy\/statsd\/wiki#server-implementations<\/a><\/noindex> pr. 11.12.2017), fandt vi pr\u00e6cis ingenting. Tilsyneladende har hverken udviklerne eller brugerne af disse l\u00f8sninger haft s\u00e5 MANGE m\u00e5linger at g\u00f8re med endnu, ellers ville de helt sikkert have fundet p\u00e5 et eller andet.<\/p>\n

<\/p>\n

Og s\u00e5 kom vi i tanke om den \"leget\u00f8js\" statsd - bioyino, som vi lavede p\u00e5 et hackathon bare for sjov (projektets navn blev genereret af et script f\u00f8r hackathonen) og inds\u00e5, at vi hurtigt havde brug for vores egen statsd. Hvorfor?<\/p>\n

<\/p>\n