{"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\/de\/blog\/administrirovanie\/bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik","title":{"rendered":"Bioyino \u2013 verteilter, skalierbarer Metrikaggregator","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Also, Sie sammeln Metriken. So wie wir. Auch wir sammeln Metriken. Nat\u00fcrlich solche, die f\u00fcr das Gesch\u00e4ft notwendig sind. Heute werden wir \u00fcber das erste Glied in unserem \u00dcberwachungssystem sprechen \u2013 einen statsd-kompatiblen Aggregationsserver. <noindex><a rel=\"nofollow\" href=\"http:\/\/bit.ly\/2Noxg1M\">bioyino<\/a><\/noindex>, warum wir ihn geschrieben haben und warum wir auf brubeck verzichtet haben. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Bioyino \u2013 verteilter, skalierbarer Metrikaggregator\" src=\"\/wp-content\/uploads\/2019\/11\/312c9a706828acc65f638a6a8abfc5b5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Aus unseren vorherigen Artikeln (<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/avito\/blog\/335410\/\">1<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/avito\/blog\/343928\/\">2<\/a><\/noindex>) k\u00f6nnen Sie erfahren, dass wir bis zu einem bestimmten Zeitpunkt die Metriken mit Hilfe von <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/brubeck\">brubeck<\/a><\/noindex>gesammelt haben. Er ist in C geschrieben. In Bezug auf den Code \u2013 so einfach wie ein Korken (das ist wichtig, wenn Sie beitragen m\u00f6chten) und vor allem, dass er ohne gr\u00f6\u00dfere Probleme mit unserem Volumen von 2 Millionen Metriken pro Sekunde (MPS) in der Spitze zurechtkommt. Die Dokumentation behauptet eine Unterst\u00fctzung von 4 Millionen MPS mit Sternchen. Das bedeutet, dass Sie die angegebene Zahl erreichen, wenn Sie das Netzwerk auf Linux korrekt konfigurieren. (Wie viele MPS man erreichen kann, wenn man das Netzwerk so l\u00e4sst, wie es ist, wissen wir nicht). Trotz dieser Vorteile hatten wir einige ernsthafte Beschwerden \u00fcber brubeck.<\/p>\n<p><\/p>\n<p><em>Beschwerde 1.<\/em> Github \u2013 der Entwickler des Projekts \u2013 hat die Unterst\u00fctzung eingestellt: keine Ver\u00f6ffentlichung von Patches und Fixes, keine Annahme unserer und (nicht nur unserer) PR. In den letzten Monaten (irgendwo seit Februar-M\u00e4rz 2018) hat sich die Aktivit\u00e4t wiederbelebt, aber vorher gab es fast 2 Jahre vollst\u00e4ndige Stille. Au\u00dferdem wird das Projekt <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/brubeck\/pull\/31#issuecomment-325907734\">f\u00fcr die internen Bed\u00fcrfnisse von Github<\/a><\/noindex>, was ein ernsthaftes Hindernis f\u00fcr die Einf\u00fchrung neuer Funktionen sein kann.<\/p>\n<p><\/p>\n<p><em>Beschwerde 2.<\/em> Die Genauigkeit der Berechnungen. Brubeck sammelt f\u00fcr die Aggregation nur 65536 Werte. In unserem Fall k\u00f6nnen w\u00e4hrend der Aggregation (30 Sekunden) bei einigen Metriken deutlich mehr Werte (1.527.392 in der Spitze) ankommen. Infolgedessen sind die Werte der Maxima und Minima v\u00f6llig nutzlos. Zum Beispiel so: <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Bioyino \u2013 verteilter, skalierbarer Metrikaggregator\" src=\"\/wp-content\/uploads\/2019\/11\/4222a1a7d1e127137220595241f5276c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Wie zuvor<\/em><\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Bioyino \u2013 verteilter, skalierbarer Metrikaggregator\" src=\"\/wp-content\/uploads\/2019\/11\/c8f0025c61f708584328ea30aacf7bc0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Wie es sein sollte<\/em><\/p>\n<p><\/p>\n<p>Aus demselben Grund werden die Summen \u00fcberhaupt falsch berechnet. F\u00fcgen Sie hier einen Fehler mit der \u00dcberlauf von 32-Bit-Float hinzu, der den Server bei Erhalt einer scheinbar harmlosen Metrik in einen Segfault versetzt, und es wird wirklich gro\u00dfartig. Der Fehler wurde \u00fcbrigens bis heute nicht behoben.<\/p>\n<p><\/p>\n<p>Und schlie\u00dflich, <em>Beschwerde X<\/em>. Zum Zeitpunkt des Verfassens dieses Artikels sind wir bereit, ihn allen 14 mehr oder weniger funktionierenden Implementierungen von statsd zu pr\u00e4sentieren, die wir finden konnten. Stellen wir uns vor, dass eine bestimmte Infrastruktur so gewachsen ist, dass die Verarbeitung von 4 Millionen MPS nicht mehr ausreicht. Oder sie ist vielleicht noch nicht gewachsen, aber die Metriken sind bereits so wichtig f\u00fcr Sie, dass selbst kurze, 2-3-min\u00fctige Ausf\u00e4lle in den Grafiken kritisch werden k\u00f6nnen und bei den Managern anhaltende Depressionen ausl\u00f6sen. Da die Behandlung von Depressionen eine danklose Aufgabe ist, sind technische L\u00f6sungen erforderlich.<\/p>\n<p><\/p>\n<p>Erstens, Fehlertoleranz, damit ein pl\u00f6tzliches Problem auf dem Server im B\u00fcro keinen psychiatrischen Zombie-Apokalyptischen Anfall ausl\u00f6st. Zweitens, Skalierung, um die M\u00f6glichkeit zu erhalten, mehr als 4 Millionen MPS zu verarbeiten, ohne tief im Netzwerk-Stack von Linux graben zu m\u00fcssen, und um in die gew\u00fcnschten Gr\u00f6\u00dfen \u201ebreit\u201c wachsen zu k\u00f6nnen.<\/p>\n<p><\/p>\n<p>Da wir beim Thema Skalierung \u00fcber Spielraum verf\u00fcgten, entschieden wir uns, zun\u00e4chst mit der Fehlertoleranz zu beginnen. \u201eOh! Fehlertoleranz! Das ist einfach, das k\u00f6nnen wir!\u201c, dachten wir und starteten 2 Server, auf jedem eine Kopie von brubeck. Dazu mussten wir den Datenverkehr mit den Metriken auf beide Server kopieren und sogar daf\u00fcr <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Albibek\/udpdup\">ein kleines Dienstprogramm<\/a><\/noindex>. Dieses Problem der Fehlertoleranz haben wir damit gel\u00f6st, aber\u2026 nicht sehr gut. Zun\u00e4chst schien alles super zu funktionieren: Jeder brubeck sammelt seine eigene Variante der Aggregation, schreibt die Daten alle 30 Sekunden in Graphite und \u00fcberschreibt den alten Intervall (das wird auf Seiten von Graphite gemacht). Wenn pl\u00f6tzlich ein Server ausf\u00e4llt, haben wir immer einen zweiten mit einer eigenen Kopie der aggregierten Daten. Aber hier ist das Problem: Wenn der Server ausf\u00e4llt, tritt in den Grafiken eine \u201eS\u00e4ge\u201c auf. Das h\u00e4ngt damit zusammen, dass die 30-Sekunden-Intervalle von brubeck nicht synchronisiert sind, und im Moment des Ausfalls wird einer von ihnen nicht \u00fcberschrieben. Beim Starten des zweiten Servers passiert das Gleiche. Ziemlich ertr\u00e4glich, aber wir m\u00f6chten es besser! Das Problem der Skalierbarkeit ist ebenfalls nicht verschwunden. Alle Metriken fliegen immer noch auf einen einzelnen Server, und daher sind wir durch die gleichen 2-4 Millionen MPS, abh\u00e4ngig von der Netzwerkverbindung, begrenzt.<\/p>\n<p><\/p>\n<p>Wenn man ein wenig \u00fcber das Problem nachdenkt und gleichzeitig Schnee mit einer Schaufel schaufelt, kann einem eine offensichtliche Idee kommen: Wir brauchen ein StatsD, das im verteilten Modus funktioniert. Das hei\u00dft, ein System, in dem die Synchronisation zwischen den Knoten nach Zeit und Metriken realisiert ist. \"Nat\u00fcrlich gibt es eine solche L\u00f6sung schon\", sagten wir und fingen an zu googeln... und fanden nichts. Bei der Durchsicht der Dokumentation zu verschiedenen StatsD (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/etsy\/statsd\/wiki#server-implementations\">https:\/\/github.com\/etsy\/statsd\/wiki#server-implementations<\/a><\/noindex> Stand 11.12.2017) fanden wir absolut nichts. Anscheinend sind weder die Entwickler noch die Nutzer dieser L\u00f6sungen mit SO VIELEN Metriken konfrontiert gewesen, sonst h\u00e4tten sie mit Sicherheit etwas erfunden.<\/p>\n<p><\/p>\n<p>Und dann erinnerten wir uns an das \"Spielzeug\" StatsD - bioyino, das wir beim Hackathon just for fun geschrieben hatten (der Projektname wurde von einem Skript vor Beginn des Hackathons generiert) und erkannten, dass wir dringend unser eigenes StatsD ben\u00f6tigten. Warum?<\/p>\n<p><\/p>\n<ul>\n<li>weil es in der Welt viel zu wenige Klone von StatsD gibt,<\/li>\n<li>weil wir die gew\u00fcnschte oder ann\u00e4hernd gew\u00fcnschte Fehlertoleranz und Skalierbarkeit gew\u00e4hrleisten k\u00f6nnen (einschlie\u00dflich der Synchronisation aggregierter Metriken zwischen Servern und der L\u00f6sung von Konflikten beim Senden),<\/li>\n<li>weil wir Metriken genauer z\u00e4hlen k\u00f6nnen als es Brubeck tut,<\/li>\n<li>weil wir selbst detailliertere Statistiken sammeln k\u00f6nnen, die uns Brubeck praktisch nicht zur Verf\u00fcgung stellte,<\/li>\n<li>weil sich die Gelegenheit bot, unsere eigene hyperperformante verteilte Skalierlab-Anwendung zu programmieren, die nicht die Architektur einer anderen solchen hyperperformanten.... nund\u00ed\u0161 azept. <\/li>\n<\/ul>\n<p><\/p>\n<p>Worauf schreiben? Nat\u00fcrlich auf Rust. Warum?<\/p>\n<p><\/p>\n<ul>\n<li>weil bereits ein Prototyp der L\u00f6sung vorlag,<\/li>\n<li>weil der Autor des Artikels zu diesem Zeitpunkt bereits Rust kannte und brannte darauf, etwas f\u00fcr die Produktion zu schreiben, das in Open Source ver\u00f6ffentlicht werden kann,<\/li>\n<li>weil uns Sprachen mit GC aufgrund der Natur des erzeugten Traffics (praktisch in Echtzeit) nicht passen und GC-Pausen praktisch unzul\u00e4ssig sind, <\/li>\n<li>weil maximale Leistung erforderlich ist, die mit C vergleichbar ist,<\/li>\n<li>weil Rust uns furchtlose Nebenl\u00e4ufigkeit bietet, und wenn wir beg\u00e4nnen, dies in C\/C++ zu schreiben, w\u00fcrden wir noch mehr Sicherheitsanf\u00e4lligkeiten, Buffer Overflows, Race Conditions und andere schreckliche W\u00f6rter als bei Brubeck erleiden.<\/li>\n<\/ul>\n<p><\/p>\n<p>Es gab auch ein Argument gegen Rust. Das Unternehmen hatte keine Erfahrung in der Erstellung von Projekten mit Rust und plant derzeit auch nicht, es im Hauptprojekt zu verwenden. Deshalb gab es ernsthafte Bedenken, dass es nicht klappen w\u00fcrde, aber wir entschieden uns, das Risiko einzugehen und es auszuprobieren.<\/p>\n<p><\/p>\n<p>Es verging Zeit\u2026<\/p>\n<p><\/p>\n<p>Endlich, nach mehreren gescheiterten Versuchen, war die erste funktionierende Version bereit. Was ist dabei herausgekommen? Es ist so geworden.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Bioyino \u2013 verteilter, skalierbarer Metrikaggregator\" src=\"\/wp-content\/uploads\/2019\/11\/322c4136ed033b80b31a89d7b5f63af8.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Jede Node erh\u00e4lt ihr eigenes Set an Metriken und speichert diese, ohne die Metriken f\u00fcr die Typen zu aggregieren, f\u00fcr die eine vollst\u00e4ndige Sammlung f\u00fcr die finale Aggregation erforderlich ist. Die Nodes sind durch ein Protokoll der verteilten Sperre (distributed lock) miteinander verbunden, das es erm\u00f6glicht, unter ihnen die eine einzige auszuw\u00e4hlen (hier weinten wir), die berechtigt ist, die Metriken an den Gro\u00dfen zu senden. Momentan wird dieses Problem mit Mitteln gel\u00f6st <noindex><a rel=\"nofollow\" href=\"https:\/\/www.consul.io\/docs\/guides\/leader-election.html\">Consul<\/a><\/noindex>, aber in Zukunft erstrecken sich die Ambitionen des Autors bis zu <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Albibek\/raft-consensus\">eigenem<\/a><\/noindex> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Albibek\/raft-tokio\">Implementierung.<\/a><\/noindex> Raft, wobei die besagte w\u00fcrdige Node nat\u00fcrlich die Konsensus-F\u00fchrungs-Node sein wird. Neben dem Konsens senden Nodes ihren Nachbarn relativ h\u00e4ufig (standardm\u00e4\u00dfig einmal pro Sekunde) die Teile der voraggregierten Metriken zu, die sie in dieser Sekunde gesammelt haben. Daher bleibt die Skalierbarkeit und Fehlertoleranz erhalten \u2013 jede der Nodes beh\u00e4lt nach wie vor ihr vollst\u00e4ndiges Set an Metriken, aber die Metriken werden nun aggregiert, \u00fcber TCP und in einem bin\u00e4ren Protokoll codiert, wodurch die Ausgaben f\u00fcr Duplikate im Vergleich zu UDP deutlich reduziert werden. Trotz der relativ gro\u00dfen Anzahl an eingehenden Metriken ben\u00f6tigt die Speicherung nur sehr wenig Speicher und noch weniger CPU. F\u00fcr unsere gut komprimierbaren Metriken sind das nur einige Dutzend Megabyte Daten. Als zus\u00e4tzlichen Bonus erhalten wir das Fehlen \u00fcberfl\u00fcssiger Daten\u00fcberschreibungen in Graphite, wie es im Fall von burbeck war.<\/p>\n<p><\/p>\n<p>UDP-Pakete mit Metriken sind auf den Netzwerkger\u00e4ten \u00fcber einfaches Rundlaufverfahren zwischen den Knoten verteilt. Nat\u00fcrlich versteht die Netzwerkhardware den Inhalt der Pakete nicht und kann daher viel mehr als 4 Millionen Pakete pro Sekunde verarbeiten, ganz zu schweigen von Metriken, \u00fcber die sie \u00fcberhaupt nichts wei\u00df. Angesichts der Tatsache, dass Metriken nicht einzeln in jedem Paket kommen, erwarten wir an dieser Stelle keine Leistungsprobleme. Im Falle eines Serverausfalls erkennt das Netzwerkger\u00e4t schnell (innerhalb von 1-2 Sekunden) diesen Umstand und entfernt den ausgefallenen Server aus der Rotation. Infolgedessen k\u00f6nnen passive (d. h. nicht f\u00fchrende) Knoten ein- und ausgeschaltet werden, ohne dass signifikante R\u00fcckg\u00e4nge in den Grafiken zu verzeichnen sind. Das Maximum, was wir verlieren, ist ein Teil der Metriken, die in der letzten Sekunde gesendet wurden. Ein pl\u00f6tzlicher Verlust\/Ausfall\/Umstieg des Leiters wird immer noch eine kleine Anomalie aufzeichnen (der 30-Sekunden-Intervall ist weiterhin unsynchronisiert), aber bei bestehender Verbindung zwischen den Knoten k\u00f6nnen auch diese Probleme minimiert werden, beispielsweise durch das Versenden synchronisierender Pakete.<\/p>\n<p><\/p>\n<p>Ein wenig \u00fcber die interne Struktur. Die Anwendung ist nat\u00fcrlich mehrthreadig, aber die Architektur der Threads unterscheidet sich von der, die in Brubeck verwendet wird. Die Threads in Brubeck sind identisch \u2013 jeder von ihnen ist sowohl f\u00fcr das Sammeln von Informationen als auch f\u00fcr die Aggregation verantwortlich. In Bioyino sind die Arbeitsthreads (Worker) in zwei Gruppen unterteilt: eine f\u00fcr das Netzwerk und eine f\u00fcr die Aggregation. Diese Trennung erm\u00f6glicht eine flexiblere Verwaltung der Anwendung abh\u00e4ngig von der Art der Metriken: Wo intensive Aggregation erforderlich ist, kann die Anzahl der Aggregatoren erh\u00f6ht werden, dort wo es viel Netzwerkverkehr gibt \u2013 kann die Anzahl der Netzwerkthreads erh\u00f6ht werden. Derzeit arbeiten wir auf unseren Servern mit 8 Netzwerk- und 4 Aggregationsthreads.<\/p>\n<p><\/p>\n<p>Der z\u00e4hlende (f\u00fcr die Aggregation verantwortliche) Teil ist ziemlich langweilig. Bef\u00fcllte Netzwerk-Threads werden auf die z\u00e4hlenden Threads verteilt, wo sie dann geparst und aggregiert werden. Auf Anfrage werden die Metriken zur Versendung an andere Knoten bereitgestellt. All dies, einschlie\u00dflich der \u00dcbertragung von Daten zwischen den Knoten und der Arbeit mit Consul, erfolgt asynchron, basiert auf dem Framework <noindex><a rel=\"nofollow\" href=\"https:\/\/tokio.rs\">tokio<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p>Die Netzwerkkomponente, die f\u00fcr das Empfangen von Metriken verantwortlich ist, stellte bei der Entwicklung weitaus gr\u00f6\u00dfere Probleme dar. Die Hauptaufgabe bei der Trennung der Netzwerkstr\u00f6me in separate Entit\u00e4ten war der Versuch, die Zeit zu reduzieren, die der Stream f\u00fcr das Lesen von Daten aus dem Socket ben\u00f6tigt. <em>nicht<\/em> Die M\u00f6glichkeiten mit asynchronem UDP und dem herk\u00f6mmlichen recvmsg fielen schnell weg: Erstere verbraucht zu viel CPU im User-Space zur Verarbeitung von Ereignissen, letztere verursacht zu viele Kontextwechsel. Daher wird jetzt verwendet <noindex><a rel=\"nofollow\" href=\"https:\/\/linux.die.net\/man\/2\/recvmmsg\">recvmmsg<\/a><\/noindex> mit gro\u00dfen Puffern (und die Puffer, liebe Offiziere, sind nicht einfach irgendetwas!). Die Unterst\u00fctzung des normalen UDP wurde f\u00fcr weniger belastete F\u00e4lle beibehalten, in denen recvmmsg nicht notwendig ist. Im Multimessage-Modus gelingt es, das Hauptziel zu erreichen: Die \u00fcberwiegende Mehrheit der Zeit verarbeitet der Netzwerkstream die Warteschlange des Betriebssystems \u2014 er liest Daten aus dem Socket und legt sie in den Userspace-Puffer, wobei er nur selten umschaltet, um den gef\u00fcllten Puffer an die Aggregatoren zur\u00fcckzugeben. Die Warteschlange im Socket w\u00e4chst praktisch nicht an, die Anzahl der verworfenen Pakete nimmt kaum zu. <\/p>\n<p>\n<b class=\"spoiler_title\">Hinweis<\/b><\/p>\n<p>In den Standardeinstellungen ist die Puffegr\u00f6\u00dfe ausreichend gro\u00df eingestellt. Wenn Sie zuf\u00e4llig entscheiden, den Server selbst auszuprobieren, stellen Sie m\u00f6glicherweise fest, dass nach dem Senden einer geringen Anzahl von Metriken diese nicht in Graphite ankommen und im Puffer des Netzwerkstreams verbleiben. Um mit einer kleinen Anzahl von Metriken zu arbeiten, m\u00fcssen die Werte f\u00fcr bufsize und task-queue-size in der Konfiguration kleiner eingestellt werden.<\/p>\n<p><\/p>\n<p>Zum Schluss \u2014 einige Grafiken f\u00fcr die Liebhaber von Grafiken.<\/p>\n<p><\/p>\n<p>Statistik der eingehenden Metriken pro Server: \u00fcber 2 Millionen MPS.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Bioyino \u2013 verteilter, skalierbarer Metrikaggregator\" src=\"\/wp-content\/uploads\/2019\/11\/c6cb1a36c267657d55ec22df518f8d03.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Deaktivierung eines der Knoten und Neuzuteilung der eingehenden Metriken.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Bioyino \u2013 verteilter, skalierbarer Metrikaggregator\" src=\"\/wp-content\/uploads\/2019\/11\/106af265a6bc2a8b31fe34df69e9c200.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Statistik der ausgehenden Metriken: immer nur ein Knoten sendet \u2014 der Raidsboss.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Bioyino \u2013 verteilter, skalierbarer Metrikaggregator\" src=\"\/wp-content\/uploads\/2019\/11\/582730b501a42bb3a371a84bf2e2394b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Statistik \u00fcber die Arbeiten jedes Knotens unter Ber\u00fccksichtigung der Fehler in verschiedenen Modulen des Systems.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Bioyino \u2013 verteilter, skalierbarer Metrikaggregator\" src=\"\/wp-content\/uploads\/2019\/11\/101377281c3add8c598c6439ca25d271.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Detailansicht der eingehenden Metriken (Metriknamen sind verborgen).<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Bioyino \u2013 verteilter, skalierbarer Metrikaggregator\" src=\"\/wp-content\/uploads\/2019\/11\/6cf0b61b454b0414799460c482e03242.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Was planen wir als N\u00e4chstes damit? Nat\u00fcrlich werden wir Code schreiben, bl...! Das Projekt wurde urspr\u00fcnglich als Open Source geplant und wird es sein, solange es existiert. Zu den n\u00e4chsten Schritten geh\u00f6ren der \u00dcbergang zu unserer eigenen Raft-Version, der Wechsel zu einem portableren Peer-Protokoll, die Einf\u00fchrung zus\u00e4tzlicher interner Statistiken, neuer Metriktypen, Fehlerbehebungen und andere Verbesserungen. <\/p>\n<p><\/p>\n<p>Selbstverst\u00e4ndlich sind alle, die an der Weiterentwicklung des Projekts mitarbeiten m\u00f6chten, herzlich willkommen: erstellt PR, Issues, wir werden nach M\u00f6glichkeit antworten und weiterarbeiten usw.<\/p>\n<p><\/p>\n<p>Das w\u00e4re es dann, wie man so sch\u00f6n sagt, das sind all unsere Neuigkeiten, kaufen Sie unsere Elefanten!<\/p>\n<p>\n<center><div class=\"youtube-placeholder\" data-id=\"siCiIyg4ZZY\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/siCiIyg4ZZY\/hqdefault.jpg\" alt=\"Video abspielen\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><br \/>\n<br \/>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/354714\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0418\u0442\u0430\u043a, \u0432\u044b \u0441\u043e\u0431\u0438\u0440\u0430\u0435\u0442\u0435 \u043c\u0435\u0442\u0440\u0438\u043a\u0438. \u041a\u0430\u043a \u0438 \u043c\u044b. \u041c\u044b \u0442\u043e\u0436\u0435 \u0441\u043e\u0431\u0438\u0440\u0430\u0435\u043c \u043c\u0435\u0442\u0440\u0438\u043a\u0438. \u041a\u043e\u043d\u0435\u0447\u043d\u043e \u0436\u0435, \u043d\u0443\u0436\u043d\u044b\u0435 \u0434\u043b\u044f \u0431\u0438\u0437\u043d\u0435\u0441\u0430. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u043c\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u043c \u043e \u0441\u0430\u043c\u043e\u043c \u043f\u0435\u0440\u0432\u043e\u043c \u0437\u0432\u0435\u043d\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043d\u0430\u0448\u0435\u0433\u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u2014 statsd-\u0441\u043e\u0432\u043c\u0435\u0441\u0442\u0438\u043c\u043e\u043c \u0441\u0435\u0440\u0432\u0435\u0440\u0435 \u0430\u0433\u0440\u0435\u0433\u0430\u0446\u0438\u0438 bioyino, \u0437\u0430\u0447\u0435\u043c \u043c\u044b \u0435\u0433\u043e \u043d\u0430\u043f\u0438\u0441\u0430\u043b\u0438 \u0438 \u043f\u043e\u0447\u0435\u043c\u0443 \u043e\u0442\u043a\u0430\u0437\u0430\u043b\u0438\u0441\u044c \u043e\u0442 brubeck. \u0418\u0437 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0438\u0445 \u043d\u0430\u0448\u0438\u0445 \u0441\u0442\u0430\u0442\u0435\u0439 (1, 2) \u043c\u043e\u0436\u043d\u043e \u0443\u0437\u043d\u0430\u0442\u044c, \u0447\u0442\u043e \u0434\u043e \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438 \u043c\u0435\u0442\u043a\u0438 \u043c\u044b \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52113","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0418\u0442\u0430\u043a, \u0432\u044b \u0441\u043e\u0431\u0438\u0440\u0430\u0435\u0442\u0435 \u043c\u0435\u0442\u0440\u0438\u043a\u0438. \u041a\u0430\u043a \u0438 \u043c\u044b. \u041c\u044b \u0442\u043e\u0436\u0435 \u0441\u043e\u0431\u0438\u0440\u0430\u0435\u043c \u043c\u0435\u0442\u0440\u0438\u043a\u0438. \u041a\u043e\u043d\u0435\u0447\u043d\u043e \u0436\u0435, \u043d\u0443\u0436\u043d\u044b\u0435 \u0434\u043b\u044f \u0431\u0438\u0437\u043d\u0435\u0441\u0430.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Bioyino \u2014 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u044b\u0439, \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u0443\u0435\u043c\u044b\u0439 \u0430\u0433\u0440\u0435\u0433\u0430\u0442\u043e\u0440 \u043c\u0435\u0442\u0440\u0438\u043a | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0418\u0442\u0430\u043a, \u0432\u044b \u0441\u043e\u0431\u0438\u0440\u0430\u0435\u0442\u0435 \u043c\u0435\u0442\u0440\u0438\u043a\u0438. \u041a\u0430\u043a \u0438 \u043c\u044b. \u041c\u044b \u0442\u043e\u0436\u0435 \u0441\u043e\u0431\u0438\u0440\u0430\u0435\u043c \u043c\u0435\u0442\u0440\u0438\u043a\u0438. \u041a\u043e\u043d\u0435\u0447\u043d\u043e \u0436\u0435, \u043d\u0443\u0436\u043d\u044b\u0435 \u0434\u043b\u044f \u0431\u0438\u0437\u043d\u0435\u0441\u0430.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T10:59:47+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Bioyino \u2014 ein verteil aggregator f\u00fcr Metriken, der skalierbar ist | ProHoster","description":"Also, ihr sammelt Metriken. So wie wir. Auch wir sammeln Metriken. Nat\u00fcrlich solche, die f\u00fcr das Gesch\u00e4ft notwendig sind.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Bioyino \u2014 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u044b\u0439, \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u0443\u0435\u043c\u044b\u0439 \u0430\u0433\u0440\u0435\u0433\u0430\u0442\u043e\u0440 \u043c\u0435\u0442\u0440\u0438\u043a | ProHoster","og:description":"\u0418\u0442\u0430\u043a, \u0432\u044b \u0441\u043e\u0431\u0438\u0440\u0430\u0435\u0442\u0435 \u043c\u0435\u0442\u0440\u0438\u043a\u0438. \u041a\u0430\u043a \u0438 \u043c\u044b. \u041c\u044b \u0442\u043e\u0436\u0435 \u0441\u043e\u0431\u0438\u0440\u0430\u0435\u043c \u043c\u0435\u0442\u0440\u0438\u043a\u0438. \u041a\u043e\u043d\u0435\u0447\u043d\u043e \u0436\u0435, \u043d\u0443\u0436\u043d\u044b\u0435 \u0434\u043b\u044f \u0431\u0438\u0437\u043d\u0435\u0441\u0430.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T21:00:00+00:00","article:modified_time":"2020-02-18T10:59:47+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"52113","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 02:30:22","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:49:49","updated":"2026-01-24 02:30:22","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/52113","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=52113"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/52113\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=52113"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=52113"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=52113"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}