{"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 ein verteilter, skalierbarer Metriken-Aggregator","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Also, Sie sammeln Metriken. So wie wir. Auch wir sammeln Metriken. Nat\u00fcrlich die, die f\u00fcr das Gesch\u00e4ft wichtig sind. Heute erz\u00e4hlen wir Ihnen vom ersten Glied in unserem \u00dcberwachungssystem \u2014 einem statsd-kompatiblen Aggregationsserver. <noindex><a rel=\"nofollow\" href=\"http:\/\/bit.ly\/2Noxg1M\">bioyino<\/a><\/noindex>, warum wir ihn entwickelt haben und warum wir uns von brubeck abgewandt haben. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Bioyino \u2013 ein verteilter, skalierbarer Metriken-Aggregator\" 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 Metriken mithilfe von <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/brubeck\">brubeck<\/a><\/noindex>sammlen. Es ist in C geschrieben. Aus Sicht des Codes ist es einfach wie ein Korken (das ist wichtig, wenn Sie beitragen m\u00f6chten) und, am wichtigsten, es bew\u00e4ltigt ohne gr\u00f6\u00dfere Probleme unsere Volumen von 2 Millionen Metriken pro Sekunde (MPS) im Peak. Die Dokumentation gibt an, dass eine Unterst\u00fctzung von 4 Millionen MPS unter Vorbehalt m\u00f6glich ist. Das bedeutet, dass Sie die angegebene Zahl erreichen, wenn Sie das Netzwerk unter Linux richtig konfigurieren. (Wie viele MPS man erh\u00e4lt, 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 \u2014 der Entwickler des Projekts \u2014 hat die Unterst\u00fctzung eingestellt: keine Patches, Fixes, oder unsere (nicht nur unsere) PRs angenommen. In den letzten Monaten (ungef\u00e4hr seit Februar-M\u00e4rz 2018) hat sich die Aktivit\u00e4t zwar wiederbelebt, jedoch gab es davor fast 2 Jahre v\u00f6llige Stille. Dar\u00fcber hinaus wird das Projekt <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/github\/brubeck\/pull\/31#issuecomment-325907734\">f\u00fcr interne Bed\u00fcrfnisse von Github<\/a><\/noindex>, was ein ernsthaftes Hindernis f\u00fcr die Einf\u00fchrung neuer Funktionen darstellen kann.<\/p>\n<p><\/p>\n<p><em>Beschwerde 2.<\/em> Die Genauigkeit der Berechnungen. Brubeck aggregiert nur 65536 Werte. In unserem Fall k\u00f6nnen in einigen Metriken w\u00e4hrend der Aggregationsperiode (30 Sekunden) viel mehr Werte ankommen (1.527.392 im Peak). Durch diese Sampling-Methode erscheinen die H\u00f6chst- und Tiefstwerte unbrauchbar. Zum Beispiel so: <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Bioyino \u2013 ein verteilter, skalierbarer Metriken-Aggregator\" src=\"\/wp-content\/uploads\/2019\/11\/4222a1a7d1e127137220595241f5276c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Wie bereits erw\u00e4hnt<\/em><\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Bioyino \u2013 ein verteilter, skalierbarer Metriken-Aggregator\" src=\"\/wp-content\/uploads\/2019\/11\/c8f0025c61f708584328ea30aacf7bc0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>So h\u00e4tte es sein sollen<\/em><\/p>\n<p><\/p>\n<p>Aus demselben Grund werden Summen insgesamt falsch berechnet. F\u00fcgen Sie dazu einen Fehler mit einem \u00dcberlauf des 32-Bit-Floats hinzu, der den Server bei der Verarbeitung einer scheinbar harmlosen Metrik in einen Segfault versetzt, und es wird wirklich gro\u00dfartig. Dieser Fehler wurde \u00fcbrigens bis heute nicht behoben.<\/p>\n<p><\/p>\n<p>Und schlie\u00dflich, <em>Beschwerde X<\/em>. Zum Zeitpunkt der Abfassung dieses Artikels sind wir bereit, sie allen 14 mehr oder weniger funktionierenden Implementierungen von statsd vorzulegen, die wir finden konnten. Stellen wir uns vor, dass eine bestimmte Infrastruktur so gewachsen ist, dass sie 4 Millionen MPS nicht mehr bew\u00e4ltigen kann. Oder sie ist noch nicht gewachsen, aber Metriken sind f\u00fcr Sie bereits so wichtig, dass selbst kurze, 2-3-min\u00fctige Ausf\u00e4lle in den Grafiken kritisch werden und eine un\u00fcberwindbare Depression bei den Managern hervorrufen k\u00f6nnen. Da die Behandlung von Depressionen ein dankloses Unterfangen ist, sind technische L\u00f6sungen erforderlich.<\/p>\n<p><\/p>\n<p>Erstens, Ausfallsicherheit, damit pl\u00f6tzliche Probleme auf dem Server im B\u00fcro keinen psychiatrischen Zombieapokalypse ausl\u00f6sen. Zweitens, Skalierbarkeit, um in der Lage zu sein, mehr als 4 Millionen MPS zu verarbeiten, ohne in den Linux-Netzwerkstack tiefer graben zu m\u00fcssen und beruhigt \u201ebreit\u201c auf die ben\u00f6tigten Gr\u00f6\u00dfen zu wachsen.<\/p>\n<p><\/p>\n<p>Da wir bei der Skalierbarkeit genug Spielraum hatten, beschlossen wir, mit der Ausfallsicherheit zu beginnen. \u201eOh! Ausfallsicherheit! Das ist einfach, das k\u00f6nnen wir\u201c, dachten wir und starteten 2 Server, auf denen jeweils eine Kopie von brubeck lief. Dazu mussten wir den Traffik mit Metriken auf beide Server kopieren und sogar ein <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Albibek\/udpdup\">kleines Dienstprogramm<\/a><\/noindex>schreiben. Dieses Problem mit der Ausfallsicherheit haben wir gel\u00f6st, aber \u2026 nicht besonders gut. Zun\u00e4chst lief alles ganz gut: Jeder brubeck sammelt seine eigene Aggregationsvariante, schreibt alle 30 Sekunden Daten in Graphite und \u00fcberschreibt den alten Zeitraum (das geschieht auf der Graphite-Seite). Wenn einer der Server ausf\u00e4llt, haben wir immer noch den anderen 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 liegt daran, dass die 30-Sekunden-Intervalle bei brubeck nicht synchronisiert sind und im Moment des Ausfalls eines von ihnen nicht \u00fcberschrieben wird. Wenn der zweite Server gestartet wird, passiert das Gleiche. Das ist zwar ertr\u00e4glich, aber wir m\u00f6chten es besser haben! Auch das Skalierbarkeitsproblem ist nach wie vor pr\u00e4sent. Alle Metriken laufen immer noch auf einen einzelnen Server, weshalb wir auf denselben 2-4 Millionen MPS in Abh\u00e4ngigkeit von der Netzwerkverf\u00fcgbarkeit beschr\u00e4nkt sind.<\/p>\n<p><\/p>\n<p>Wenn man ein wenig \u00fcber das Problem nachdenkt und gleichzeitig mit einer Schaufel Schnee schaufelt, k\u00f6nnte einem die offensichtliche Idee kommen: wir brauchen ein statsd, das im verteilten Modus funktioniert. Das hei\u00dft, eines, in dem die Synchronisation zwischen den Knoten nach Zeit und Metriken umgesetzt wird. \u201eNat\u00fcrlich gibt es so eine L\u00f6sung wahrscheinlich schon\u201c, sagten wir und fingen an zu googeln ... und fanden nichts. Wir durchst\u00f6berten die Dokumentation verschiedener statsd (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/etsy\/statsd\/wiki#server-implementations\">https:\/\/github.com\/etsy\/statsd\/wiki#server-implementations<\/a><\/noindex> Zum Zeitpunkt des 11.12.2017 haben wir tats\u00e4chlich nichts gefunden. Offenbar hatten weder Entwickler noch Nutzer solcher L\u00f6sungen bisher mit SO VIELEN Metriken zu tun, sonst h\u00e4tten sie sicherlich etwas erfunden.<\/p>\n<p><\/p>\n<p>Und dann erinnerten wir uns an den \"Spielzeug\" statsd \u2014 bioyino, den wir w\u00e4hrend eines Hackathons just for fun geschrieben haben (der Projektname wurde zu Beginn des Hackathons von einem Skript 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 zu wenige Klone von statsd gibt,<\/li>\n<li>weil man die gew\u00fcnschte oder nah an der gew\u00fcnschten Fehlertoleranz und Skalierbarkeit gew\u00e4hrleisten kann (unter anderem das Synchronisieren aggregierter Metriken zwischen Servern und das L\u00f6sen von Konflikten beim Senden),<\/li>\n<li>weil man Metriken genauer z\u00e4hlen kann, als es brubeck tut,<\/li>\n<li>weil wir detailliertere Statistiken selbst sammeln k\u00f6nnen, die brubeck uns praktisch nicht zur Verf\u00fcgung stellte,<\/li>\n<li>weil sich die Gelegenheit bot, unsere eigene hochperformante verteilte Scalablapplikation zu programmieren, die nicht die Architektur eines \u00e4hnlichen hyperperformanten Systems vollst\u00e4ndig wiederholen w\u00fcrde. <\/li>\n<\/ul>\n<p><\/p>\n<p>Worauf sollten wir programmieren? Nat\u00fcrlich auf Rust. Warum?<\/p>\n<p><\/p>\n<ul>\n<li>weil es bereits einen Prototyp der L\u00f6sung gab,<\/li>\n<li>weil der Autor des Artikels zu diesem Zeitpunkt bereits Rust kannte und darauf brannte, etwas f\u00fcr die Produktion zu schreiben, das er als Open-Source ver\u00f6ffentlichen konnte,<\/li>\n<li>weil Sprachen mit GC uns aufgrund der Art des empfangenen Traffics (praktisch in Echtzeit) nicht passen, und GC-Pausen praktisch inakzeptabel sind, <\/li>\n<li>weil maximale Leistung ben\u00f6tigt wird, vergleichbar mit C<\/li>\n<li>weil Rust uns furchtlose Parallelit\u00e4t bietet, und w\u00fcrden wir beginnen, das in C\/C++ zu schreiben, h\u00e4tten wir noch mehr Sicherheitsanf\u00e4lligkeiten, Buffer\u00fcberl\u00e4ufe, Race Conditions und andere gruselige W\u00f6rter als bei brubeck.<\/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 derzeit planen wir auch nicht, es in unserem Hauptprojekt zu verwenden. Daher gab es ernsthafte Bedenken, dass nichts klappen w\u00fcrde, aber wir beschlossen, das Risiko einzugehen und es zu versuchen.<\/p>\n<p><\/p>\n<p>Die Zeit verging...<\/p>\n<p><\/p>\n<p>Schlie\u00dflich, nach mehreren gescheiterten Versuchen, war die erste funktionierende Version fertig. Was ist dabei herausgekommen? Es kam das hier heraus.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Bioyino \u2013 ein verteilter, skalierbarer Metriken-Aggregator\" src=\"\/wp-content\/uploads\/2019\/11\/322c4136ed033b80b31a89d7b5f63af8.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Jede Node erh\u00e4lt ihren eigenen Satz von Metriken und speichert sie lokal, ohne die Metriken f\u00fcr jene Typen zu aggregieren, bei denen f\u00fcr die finale Aggregation der vollst\u00e4ndige Satz erforderlich ist. Die Nodes sind durch ein gewisses Protokoll der verteilten Sperre (distributed lock) miteinander verbunden, das es erm\u00f6glicht, unter ihnen die eine (hier haben wir geweint) auszuw\u00e4hlen, die w\u00fcrdig ist, die Metriken an den Gro\u00dfen zu senden. Momentan wird dieses Problem durch <noindex><a rel=\"nofollow\" href=\"https:\/\/www.consul.io\/docs\/guides\/leader-election.html\">Consul<\/a><\/noindex>, aber in Zukunft streben die Ambitionen des Autors an <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, wo die besagte W\u00fcrdige nat\u00fcrlich die konsensf\u00fchrende Node sein wird. Neben dem Konsens senden die Nodes recht h\u00e4ufig (standardm\u00e4\u00dfig einmal pro Sekunde) ihren Nachbarn die Teile der voraggregierten Metriken, die sie in dieser Sekunde gesammelt haben. Das bedeutet, dass Skalierung und Fehlertoleranz erhalten bleiben \u2014 jede der Nodes beh\u00e4lt weiterhin ihren vollst\u00e4ndigen Satz von Metriken, aber die Metriken werden nun bereits aggregiert \u00fcber TCP und in einem bin\u00e4ren Protokoll kodiert gesendet, sodass die Kosten f\u00fcr die Duplizierung im Vergleich zu UDP erheblich sinken. Trotz einer recht gro\u00dfen Anzahl an eintreffenden Metriken ben\u00f6tigt die Ansammlung 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 die Abwesenheit unn\u00f6tiger Daten\u00fcberschreibungen in Graphite, wie es bei burbeck der Fall war.<\/p>\n<p><\/p>\n<p>UDP-Pakete mit Metriken werden auf den Netzwerkger\u00e4ten zwischen den Nodes mithilfe eines einfachen Round Robin verteilt. Selbstverst\u00e4ndlich analysiert die Netzwerktechnologie den Inhalt der Pakete nicht und kann daher weit mehr bew\u00e4ltigen als 4 Millionen Pakete pro Sekunde, ganz zu schweigen von den Metriken, \u00fcber die sie \u00fcberhaupt nichts wei\u00df. Wenn man bedenkt, dass die Metriken nicht einzeln in jedem Paket ankommen, sehen wir hier keine Leistungsprobleme. Im Falle eines Serverausfalls erkennt das Netzwerkger\u00e4t dieses Ereignis schnell (innerhalb von 1-2 Sekunden) und entfernt den ausgefallenen Server aus der Rotation. Dadurch k\u00f6nnen passive (also nicht der F\u00fchrer sein) Nodes praktisch ohne sp\u00fcrbare Einbr\u00fcche in den Grafiken ein- und ausgeschaltet werden. Das Maximum, was wir verlieren, ist ein Teil der Metriken, die in der letzten Sekunde eingegangen sind. Ein pl\u00f6tzlicher Verlust\/Ausschalten\/Wechsel des F\u00fchrers wird immer noch eine geringf\u00fcgige Anomalie anzeigen (ein 30-Sekunden-Intervall ist nach wie vor desynchronisiert), aber bei vorhandenem Kontakt zwischen den Nodes kann man auch diese Probleme minimieren, beispielsweise durch den Versand von synchronisierenden Paketen.<\/p>\n<p><\/p>\n<p>Ein bisschen \u00fcber die interne Struktur. Die Anwendung ist nat\u00fcrlich mehrsprachig, jedoch unterscheidet sich die Thread-Architektur von der in brubeck. In brubeck sind die Threads gleichf\u00f6rmig \u2013 jeder ist sowohl f\u00fcr die Informationssammlung als auch f\u00fcr die Aggregation zust\u00e4ndig. In bioyino sind die Arbeits-Threads (workers) in zwei Gruppen unterteilt: verantwortlich f\u00fcr das Netzwerk und verantwortlich f\u00fcr die Aggregation. Diese Trennung erm\u00f6glicht eine flexiblere Verwaltung der Anwendung, abh\u00e4ngig von der Art der Metriken: dort, wo intensive Aggregation erforderlich ist, k\u00f6nnen mehr Aggregatoren hinzugef\u00fcgt werden, und dort, wo viel Netzwerkverkehr herrscht, kann die Anzahl der Netzwerk-Threads erh\u00f6ht werden. Momentan arbeiten wir auf unseren Servern mit 8 Netzwerk-Threads und 4 Aggregations-Threads.<\/p>\n<p><\/p>\n<p>Der berechnende Teil, der f\u00fcr die Aggregation verantwortlich ist, ist ziemlich langweilig. Die mit Netzwerk-Threads gef\u00fcllten Puffer werden zwischen den berechnenden Threads verteilt, wo sie weiter geparst und aggregiert werden. Auf Anfrage werden die Metriken zur Versendung an andere Knoten bereitgestellt. All dies, einschlie\u00dflich der \u00dcbertragung von Daten zwischen Knoten und der Arbeit mit Consul, geschieht asynchron, basierend auf dem Framework <noindex><a rel=\"nofollow\" href=\"https:\/\/tokio.rs\">tokio<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p>Viel mehr Probleme bei der Entwicklung bereitete der Netzwerkteil, der f\u00fcr den Empfang von Metriken verantwortlich ist. Das Hauptziel der Trennung der Netzwerk-Threads in separate Entit\u00e4ten war der Wunsch, die Zeit zu reduzieren, die ein Thread ben\u00f6tigt <em>nicht<\/em> zum Lesen von Daten aus dem Socket. Die Optionen mit asynchronem UDP und gew\u00f6hnlichem recvmsg wurden schnell verworfen: das erste verbraucht zu viel CPU im Benutzermodus zur Ereignisverarbeitung, das zweite \u2013 zu viele Kontextwechsel. Daher verwenden wir jetzt <noindex><a rel=\"nofollow\" href=\"https:\/\/linux.die.net\/man\/2\/recvmmsg\">recvmmsg<\/a><\/noindex> mit gro\u00dfen Puffern (und Puffer, meine Herren, sind nicht einfach irgendetwas!). Die Unterst\u00fctzung f\u00fcr gew\u00f6hnliches UDP bleibt f\u00fcr unauff\u00e4llige F\u00e4lle, in denen recvmmsg nicht ben\u00f6tigt wird. Im Multimessage-Modus kann das Hauptziel erreicht werden: Der Gro\u00dfteil der Zeit r\u00e4umt der Netzwerk-Thread die Warteschlange des Betriebssystems auf \u2013 Daten werden aus dem Socket gelesen und in den Userspace-Puffer verschoben, nur gelegentlich wird gewechselt, um den gef\u00fcllten Puffer an die Aggregatoren weiterzugeben. Die Warteschlange im Socket baut sich kaum auf, die Anzahl der verworfenen Pakete w\u00e4chst praktisch nicht. <\/p>\n<p>\n<b class=\"spoiler_title\">Hinweis<\/b><\/p>\n<p>In den Standardeinstellungen ist die Puffergr\u00f6\u00dfe relativ gro\u00df eingestellt. Wenn Sie sich entscheiden, den Server selbst auszuprobieren, k\u00f6nnen Sie darauf sto\u00dfen, dass nach dem Senden einer kleinen Anzahl von Metriken diese nicht in Graphite ankommen, weil sie im Puffer des Netzwerk-Threads bleiben. Um mit einer kleinen Anzahl von Metriken zu arbeiten, m\u00fcssen die Werte f\u00fcr bufsize und task-queue-size im Konfigurationsdatei kleiner gesetzt werden.<\/p>\n<p><\/p>\n<p>Zum Schluss \u2013 ein paar Grafiken f\u00fcr die Grafikliebhaber.<\/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 ein verteilter, skalierbarer Metriken-Aggregator\" src=\"\/wp-content\/uploads\/2019\/11\/c6cb1a36c267657d55ec22df518f8d03.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Trennung eines der Knoten und Neuzuordnung der eingehenden Metriken.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Bioyino \u2013 ein verteilter, skalierbarer Metriken-Aggregator\" 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 \u2013 der Oberboss.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Bioyino \u2013 ein verteilter, skalierbarer Metriken-Aggregator\" src=\"\/wp-content\/uploads\/2019\/11\/582730b501a42bb3a371a84bf2e2394b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Statistik der Arbeit jedes Knotens mit Ber\u00fccksichtigung von Fehlern in verschiedenen Modulen des Systems.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Bioyino \u2013 ein verteilter, skalierbarer Metriken-Aggregator\" src=\"\/wp-content\/uploads\/2019\/11\/101377281c3add8c598c6439ca25d271.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Detailansicht der eingehenden Metriken (die Namen der Metriken sind verborgen).<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Bioyino \u2013 ein verteilter, skalierbarer Metriken-Aggregator\" 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 mit all dem? Nat\u00fcrlich werden wir Code schreiben, bl...! Das Projekt wurde urspr\u00fcnglich als Open-Source geplant und wird dies sein, solange es existiert. In naher Zukunft steht der \u00dcbergang zu unserer eigenen Raft-Version, der Wechsel zu einem tragf\u00e4higeren Peer-Protokoll, die Integration zus\u00e4tzlicher interner Statistiken, neuer Metriktypen, Fehlerbehebungen und anderer Verbesserungen auf der Agenda. <\/p>\n<p><\/p>\n<p>Nat\u00fcrlich sind alle willkommen, die zur Entwicklung des Projekts beitragen m\u00f6chten: erstellen Sie PRs, Issues, wir werden versuchen, zu antworten, zu verbessern usw.<\/p>\n<p><\/p>\n<p>Damit ist, wie man so sch\u00f6n sagt, das alles, Leute, kauft 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.0.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.0.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 \u2013 verteilter, skalierbarer Metrikaggregator | ProHoster","description":"Also sammeln Sie Metriken. So wie wir. Wir sammeln auch Metriken. Nat\u00fcrlich die, die f\u00fcr das Gesch\u00e4ft wichtig 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}]}}