{"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\/sv\/blog\/administrirovanie\/bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik","title":{"rendered":"Bioyino - en distribuerad, skalbar aggregator av metrik","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

S\u00e5, ni samlar in m\u00e4tv\u00e4rden. Precis som vi. Vi samlar ocks\u00e5 in m\u00e4tv\u00e4rden. Sj\u00e4lvklart s\u00e5dana som \u00e4r viktiga f\u00f6r aff\u00e4ren. Idag kommer vi att ber\u00e4tta om den f\u00f6rsta l\u00e4nken i v\u00e5rt \u00f6vervakningssystem \u2013 en statsd-kompatibel aggregationsserver. bioyino<\/a><\/noindex>, varf\u00f6r vi skrev den och varf\u00f6r vi \u00f6vergav brubeck. <\/p>\n

<\/p>\n

\"Bioyino<\/p>\n

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

Fr\u00e5n v\u00e5ra tidigare artiklar (1<\/a><\/noindex>, 2<\/a><\/noindex>) kan man f\u00f6rst\u00e5 att vi tills f\u00f6r en tid sedan samlade in etiketterna med hj\u00e4lp av brubeck<\/a><\/noindex>. Den \u00e4r skriven i C. Ur kodens synvinkel \u00e4r den enkel som en kork (detta \u00e4r viktigt n\u00e4r du vill bidra) och, viktigast av allt, klarar den utan st\u00f6rre problem av v\u00e5ra volymer p\u00e5 2 miljoner m\u00e4tv\u00e4rden per sekund (MPS) i toppen. Dokumentationen p\u00e5st\u00e5r sig st\u00f6dja 4 miljoner MPS med en asterisk. Det betyder att du kommer att f\u00e5 den angivna siffran om du konfigurerar n\u00e4tverket korrekt p\u00e5 Linux. (Vi vet inte hur m\u00e5nga MPS man f\u00e5r om man l\u00e4mnar n\u00e4tverket som det \u00e4r). Trots dessa f\u00f6rdelar hade vi flera allvarliga klagom\u00e5l p\u00e5 brubeck.<\/p>\n

<\/p>\n

Klagom\u00e5l 1.<\/em> Github \u2013 projektets utvecklare \u2013 har slutat att st\u00f6dja den: publicera patchar och fixar, ta emot v\u00e5ra och (inte bara v\u00e5ra) PR. Under de senaste m\u00e5naderna (n\u00e5gon g\u00e5ng fr\u00e5n februari-mars 2018) har aktiviteten \u00f6kat igen, men f\u00f6re det var det n\u00e4stan tv\u00e5 \u00e5r av total tystnad. Dessutom utvecklas projektet f\u00f6r Gihubs interna behov<\/a><\/noindex>, vilket kan bli ett allvarligt hinder f\u00f6r att inf\u00f6ra nya funktioner.<\/p>\n

<\/p>\n

Klagom\u00e5l 2.<\/em> Noggrannheten i ber\u00e4kningarna. Brubeck samlar in endast 65536 v\u00e4rden f\u00f6r aggregation. I v\u00e5rt fall kan det komma mycket fler v\u00e4rden under aggregationsperioden (30 sekunder) f\u00f6r vissa m\u00e4tv\u00e4rden (1 527 392 i toppen). Som ett resultat av s\u00e5dan sampling verkar max- och minv\u00e4rdena vara v\u00e4rdel\u00f6sa. Till exempel s\u00e5 h\u00e4r: <\/p>\n

<\/p>\n

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

<\/p>\n

\"Bioyino
\nS\u00e5 som det borde ha varit<\/em><\/p>\n

<\/p>\n

Av samma anledning r\u00e4knas summor \u00f6verhuvudtaget felaktigt. L\u00e4gg till en bugg med \u00f6verfl\u00f6de av 32-bitars flyttal, som helt enkelt f\u00e5r servern att krascha vid mottagande av en till synes oskyldig m\u00e4tning, och det blir verkligen utm\u00e4rkt. Buggen har f\u00f6r \u00f6vrigt inte blivit \u00e5tg\u00e4rdad.<\/p>\n

<\/p>\n

Och slutligen, Klagom\u00e5l X<\/em>. Vid tidpunkten f\u00f6r artikelns skrivning \u00e4r vi redo att presentationera alla 14 mer eller mindre fungerande implementationer av statsd, som vi kunnat hitta. L\u00e5t oss f\u00f6rest\u00e4lla oss att en viss avgr\u00e4nsad infrastruktur har vuxit s\u00e5 mycket att 4 miljoner MPS inte l\u00e4ngre \u00e4r tillr\u00e4ckligt. Eller s\u00e5 har den kanske \u00e4nnu inte vuxit, men metrik f\u00f6r er \u00e4r redan s\u00e5 viktiga att \u00e4ven korta, 2\u20133 minuters avbrott i graferna kan bli kritiska och orsaka okontrollerbar \u00e5ngest hos cheferna. Eftersom behandling av \u00e5ngest \u00e4r en tacksam uppgift kr\u00e4vs tekniska l\u00f6sningar.<\/p>\n

<\/p>\n

F\u00f6r det f\u00f6rsta, redundans, s\u00e5 att ett pl\u00f6tsligt problem p\u00e5 servern inte utl\u00f6ser en psykiatrisk zombieapokalyps p\u00e5 kontoret. F\u00f6r det andra, skalbarhet, f\u00f6r att f\u00e5 m\u00f6jlighet att hantera mer \u00e4n 4 miljoner MPS, utan att gr\u00e4va djupt i Linux n\u00e4tverksstack och kunna v\u00e4xa \"brett\" till \u00f6nskad storlek.<\/p>\n

<\/p>\n

Eftersom vi hade marginal f\u00f6r skalbarhet beslutade vi att b\u00f6rja med redundans. \"\u00c5h! Redundans! Det \u00e4r enkelt, det kan vi\", t\u00e4nkte vi och startade 2 servrar, d\u00e4r vi s\u00e4tter upp en kopia av brubeck p\u00e5 varje. F\u00f6r detta beh\u00f6vde vi kopiera trafiken med metrik till b\u00e5da servrar och till och med skriva en liten verktygsprogram.<\/a><\/noindex>. Redundansproblemet l\u00f6ste vi s\u00e5, men... inte s\u00e4rskilt bra. F\u00f6rst verkade allt vara bra: var och en brubeck samlar sin variant av aggregering, skriver data till Graphite var 30:e sekund, skrivandes \u00f6ver det gamla intervallet (detta g\u00f6rs p\u00e5 Graphite-sidan). Om en server skulle fallera har vi alltid en andra med en egen kopia av de aggregerade data. Men h\u00e4r \u00e4r problemet: om en server fallerar uppst\u00e5r en \"s\u00e5g\" i graferna. Detta beror p\u00e5 att 30-sekundersintervallen vid brubeck inte \u00e4r synkroniserade, och i \u00f6gonblicket av ett fall registreras inte en av dem. Vid uppstart av den andra servern sker samma sak. Ganska acceptabelt, men vi vill ha b\u00e4ttre! Problemet med skalbarhet f\u00f6rsvann inte heller. Alla metrik forts\u00e4tter att \"flyga\" till en enda server, och d\u00e4rf\u00f6r \u00e4r vi begr\u00e4nsade av de samma 2\u20134 miljoner MPS beroende p\u00e5 n\u00e4tverkskapaciteten.<\/p>\n

<\/p>\n

Om man t\u00e4nker lite p\u00e5 problemet och samtidigt gr\u00e4ver sn\u00f6n med en spade, kan en s\u00e5 uppenbar id\u00e9 dyka upp: vi beh\u00f6ver statsd som kan fungera i distribuerat l\u00e4ge. Det vill s\u00e4ga, ett som har synkronisering mellan noderna baserat p\u00e5 tid och m\u00e4tdata. \"Sj\u00e4lvklart finns det s\u00e4kert redan en s\u00e5dan l\u00f6sning\", sa vi och b\u00f6rjade googla... och hittade ingenting. Efter att ha gr\u00e4vt igenom dokumentationen f\u00f6r olika statsd (https:\/\/github.com\/etsy\/statsd\/wiki#server-implementations<\/a><\/noindex> den 11.12.2017), hittade vi faktiskt ingenting. Tydligen har varken utvecklarna eller anv\u00e4ndarna av dessa l\u00f6sningar med S\u00c5DANA m\u00e4ngder m\u00e4tningar st\u00f6tt p\u00e5 det \u00e4nnu, annars hade de s\u00e4kert kommit p\u00e5 n\u00e5got.<\/p>\n

<\/p>\n

Och h\u00e4r kom vi ih\u00e5g den \"leksaks\" statsd - bioyino, som vi skrev p\u00e5 hackathonet just for fun (projektets namn genererade en script inf\u00f6r hackathonet) och ins\u00e5g att vi akut beh\u00f6vde v\u00e5r egen statsd. Varf\u00f6r?<\/p>\n

<\/p>\n