In Didi stellen die Metrikdaten der beobachtbaren Plattform einige Anforderungen an die Echtzeitberechnung, und diese Anforderungen an die Echtzeitberechnung werden von einer Reihe von Flink-Aufgaben getragen. Der Grund, warum es mehrere Sätze von Flink-Aufgaben gibt, liegt darin, dass jeder Dienst entsprechend seinen Geschäftsbeobachtungen unterschiedliche Indikatorberechnungen erfordert, was auch unterschiedlichen Datenverarbeitungstopologien entspricht . Wir versuchen unser Bestes, um die gleichen Rechenanforderungen der Benutzer zu abstrahieren. Aufgrund der Einschränkungen des Echtzeit-Rechenaufgabenentwicklungsmodells und des Echtzeit-Rechenrahmens von Flink ist das Design dieser Beobachtungsindikator-Rechenaufgaben jedoch nicht universell genug. Bei der Verwendung von Flink zur Echtzeitberechnung von Metrikindikatoren treten bei der Verwaltung mehrerer Sätze von Flink-Aufgaben die folgenden Probleme auf:
Die allgemeinen Rechenfunktionen für Metriken, die hätten abstrahiert werden sollen, wurden wiederholt erstellt, sind von unterschiedlicher Qualität und können nicht akkumuliert werden.
Die Verarbeitungslogik ist zufällig fest in den Code der Streaming-Aufgabe einprogrammiert und lässt sich nur schwer aktualisieren und warten.
Die Freigabe, Erweiterung und Reduzierung von Flink erfordert einen Neustart der Aufgaben, was zu Verzögerungen bei der Anzeigeausgabe, Haltepunkten und Fehlern führt.
Die Flink-Plattform ist relativ teuer und macht einen großen Teil unserer internen Kostenrechnungen aus, und es besteht ein gewisser Kostendruck.
Um diese Probleme zu lösen, haben wir eine Reihe von Echtzeit-Computing-Engines entwickelt: Observe-Compute (kurz OBC). Im Folgenden finden Sie eine Einführung in die Implementierung von OBC.
Designziele
Zu Beginn des Projekts wurden von OBC folgende Entwurfsziele festgelegt:
1. Erstellen Sie eine universelle Echtzeit-Berechnungs-Engine im Bereich der Berechnung von Metrikindikatoren . Diese Engine weist die folgenden Eigenschaften auf:
Im Einklang mit Industriestandards: Verwendung von PromQL als Beschreibungssprache für Stream-Verarbeitungsaufgaben
Flexible Aufgabenverwaltung und -steuerung: Strategien werden konfiguriert, Rechenaufgaben werden in Echtzeit wirksam und in den Ausführungsplan kann manuell eingegriffen werden
Rückverfolgbarkeit von Rechenverbindungen: Kann eine Rückverfolgbarkeit der Berechnungsergebnisse auf Richtlinienebene erreichen
Cloud-native Containerisierung: Die Bereitstellung der Engine-Containerisierung ermöglicht eine dynamische Erweiterung und Verkleinerung ohne Ausfallzeiten.
2. Das Produkt kann alle Anforderungen der beobachtbaren Plattform an die Berechnung von Metrikindikatoren erfüllen, wiederholte Berechnungsaufgaben ersetzen, Kosten senken und die Effizienz steigern sowie die Beobachtungserfassungs-, Übertragungs- und Berechnungsverbindungen neu gestalten.
Bis auf die Funktion zur Berechnung der Link-Verfolgbarkeit sind derzeit alle anderen Engine-Funktionen implementiert. OBC läuft seit mehr als mehreren Monaten stabil online. Mehrere Sätze von Flink-Computing-Aufgaben im Kern der Observable-Plattform wurden auf OBC migriert. Es wird erwartet, dass die migrierten Aufgaben kumulative Kosten von 1 Million Yuan für das Observable einsparen werden Plattform bis Ende des Jahres.
Motorarchitektur
Die Engine-Architektur ist in der Abbildung oben dargestellt und in drei Komponenten unterteilt: obc-ruler ist die Steuerkomponente in der Engine, die Dienstregistrierungs- und Erkennungsfunktionen für andere Komponenten in der Engine bereitstellt. Sie ist auch für den Zugriff auf externe Komponenten verantwortlich Rechenstrategien und die Kontrolle von Ausführungsplänen. obc-distributor nimmt Metrics-Indikatoren aus der Metrics-Nachrichtenwarteschlange auf, stimmt mit der Berechnungsstrategie überein und leitet die Daten gemäß dem Ausführungsplan der Strategie an obc-worker weiter. obc-worker ist die Komponente in der Engine, die eigentlich für die Berechnungen verantwortlich ist. Sie ist dafür verantwortlich, Indikatorberechnungen gemäß dem Ausführungsplan abzuschließen und die Berechnungsergebnisse an einen externen persistenten Speicher zu liefern.
Usability-Diskussion
Bevor wir die Kernlogik jeder Komponente im Detail vorstellen, wollen wir zunächst unsere Gedanken und Kompromisse zur Benutzerfreundlichkeit sowie einige Konzepte vorstellen, die zur Erreichung der Benutzerfreundlichkeitsziele eingeführt wurden. Dieser Teil der Diskussion wird dazu beitragen, die Kernlogik jeder Komponente zu verstehen.
Usability-Denken
Die Anforderungen an die Datenverfügbarkeit in Echtzeit-Computing-Szenarien lassen sich in Echtzeitanforderungen und Genauigkeitsanforderungen unterteilen , die Daten mit geringer Latenz und hoher Präzision erfordern. Genauigkeit kann als gute Daten und kein Verlust beschrieben werden. Die Anforderung, dass die Daten gut sind, nenne ich die Genauigkeitsanforderung, und die Anforderung, dass die Daten nicht verloren gehen, nenne ich die Integritätsanforderung.
Für Geschäftsbeobachtungsdaten ist es aus Sicht der endgültigen Ausgabeergebnisse auch geeignet, die Verfügbarkeit aus den oben genannten drei Perspektiven zu diskutieren:
Echtzeit: Es sollte keine große Verzögerung geben, bis die Daten in den Speicher gelangen
Genauigkeit: Im Speicher abgelegte Daten müssen den Zustand des Systems genau widerspiegeln
Integrität: Die im Speicher abgelegten Daten dürfen keine fehlenden Punkte oder Haltepunkte aufweisen.
Der einfache Prozess der Beobachtungsdatenverarbeitung kann wie folgt vereinfacht werden: Sammlung => Speicherung. Was in einem solchen Prozess gesammelt wird, ist das, was gesammelt wird, und es besteht keine Notwendigkeit, die Genauigkeit der Daten zu diskutieren. Unter den beiden Anforderungen Echtzeit und Integrität besteht der allgemeine Ansatz darin, Echtzeit sicherzustellen und die Integrität zu opfern, um die Implementierungskomplexität und den Betriebsaufwand des Systems zu verringern.
Szenarien, in denen Beobachtungsdaten an Echtzeitberechnungen beteiligt sind, werden komplexer sein als gewöhnliche Szenarien, und die Genauigkeit der Daten muss weiter diskutiert werden. Unser interner Datenfluss vom Beobachtungsagenten (Erfassungsende) => mq => obc-distributor => obc-worker => persistenter Speicher, unter der Voraussetzung, dass die Verzögerungsverteilung der Daten im selben Berechnungsfenster, die obc-worker erreichen, erfüllt Annahme: Mindestens die Semantik vom Sammlungsende bis zum Obc-Worker muss gewährleistet sein, und die Logik der Datendeduplizierung und die Integrität des Berechnungsfensters müssen auf dem Obc-Worker implementiert sein, um genaue Ergebnisse sicherzustellen. Für uns sind sowohl die Kosten für Design und Implementierung als auch die Kosten für zusätzliche Rechenressourcen zur Gewährleistung der Genauigkeit etwas höher. Und wenn wir Flink zur Berechnung von Metrikindikatoren verwenden, können wir nicht garantieren, dass die endgültigen Ausgabedaten korrekt sind. Daher hat OBC auch einige notwendige Kompromisse beim Design der Lösung eingegangen. Unter der Voraussetzung, die Echtzeitausgabe sicherzustellen Berechnungsergebnisse, wir versuchen unser Bestes, um die Berechnungsergebnisse sicherzustellen . Es werden nur Punkte gebrochen (Vollständigkeit) und keine Fehler gemacht (Genauigkeit), es wird jedoch nicht versprochen, dass die erzeugten Daten korrekt sind.
Usability-Design
Zunächst stellen wir ein Konzept vor, das als Umstellungszeit bezeichnet wird. Die Bedeutung von Umstellung ist Umschalten. Dieses Konzept ist von m3aggregator entlehnt. In OBC wird die Umstellungszeit auf einen Zeitpunkt festgelegt, der später liegt als der Zeitpunkt, zu dem sich die Konfiguration ändert, als tatsächlicher effektiver Zeitpunkt der Konfiguration, sodass obc-distributor und obc-worker mehrere Möglichkeiten haben, sich vor der Änderung mit derselben Konfiguration zu synchronisieren Die Konfiguration wird tatsächlich wirksam. Das Konzept der Umstellungszeit wird hier zunächst eingeführt, denn wenn der Obc-Distributor Daten an den Obc-Worker weiterleitet, wählt er aus, an welche Worker-Instanz auf dem von Obc-Worker gebildeten Hash-Ring weitergeleitet werden muss. Sobald sich der Status einer Worker-Instanz ändert , Der Worker Wenn sich der konstituierte Hash ändert, tritt ein Problem auf: Wenn die Änderung sofort wirksam wird, erkennt der Obc-Distributor, dass der Prozess der Hash-Änderung sequentiell ist, und der Worker-Hash-Ring, der im Distributor-Cluster wirksam wird, ist inkonsistent für einen kurzen Zeitraum. Die Konfiguration wird durch die Umstellung konfiguriert. Durch die Verzögerung der tatsächlichen effektiven Zeit kann der Verteiler mehr Zeit haben, die Konfigurationsänderungen zu erkennen. Das spezifischere Usability-Design gliedert sich in die folgenden Punkte:
1. Obc-Worker stürzt ab, driftet ab und startet neu, was in einigen Kurven höchstens drei Haltepunkte verursacht, ohne dass Fehlerpunkte auftreten.
Es gibt einen Heartbeat-Synchronisationsmechanismus zwischen Worker und Ruler, der alle 3 Sekunden synchronisiert wird.
Der Verteiler synchronisiert den Worker-Hash vom Lineal mit einer Ruffrequenz von 3 Sekunden.
Der Herrscher vervollständigt die Versionsaktualisierungslogik des Hash-Rings basierend auf dem Status des Workers. Ein Cutover ist eine Version, und die historische Version wird bis zu 10 Minuten lang aufbewahrt.
Urteil des Herrschers zum Tod des Arbeiters: Der Herzschlag wurde 8 Sekunden lang nicht aktualisiert, oder der Herrscher ruft die Schnittstelle aktiv auf, um sich abzumelden.
Ausbreitungsverzögerungszeit für Hash-Ring: 8 s
2. Drift und Neustart des obc-Verteilers führen nicht zu Kurvenhaltepunkten oder falschen Punkten.
obc wird auf unserer internen Cloud-Plattform bereitgestellt. Unsere interne Cloud-Plattform verfügt über einige Unterstützungsfunktionen für einen ordnungsgemäßen Neustart: Containerdrift und Neustart senden ein SIGTERM-Signal an den Geschäftsprozess. Der Verteiler hört dieses Signal ab und führt nach dem Empfang des Signals zwei Dinge aus:
Hören Sie auf, von MQ zu konsumieren
Metrikdatenpunkte und Datenpunkte im Cache, die noch nicht an den Worker gesendet wurden, werden so schnell wie möglich gesendet.
3. Der Obc-Verteiler gerät in Panik und der physische Knoten, auf dem er sich befindet, kann Haltepunkte und Fehler verursachen.
In diesem Fall hat der Verteiler keine Chance, die Folgen zu bewältigen: Ein Teil der Daten, die im Speicher zwischengespeichert und noch nicht an den Arbeiter gesendet wurden, geht verloren, was zu Fehlern in den Berechnungsergebnissen führt.
Welche Auswirkungen hat diese Situation auf die Benutzer? Unser alter Metrikberechnungslink Observer-Agent (Sammlungsende) => mq => Router => Kafka => Flink. Das Router-Modul im Link übernimmt einen Teil der Arbeit ähnlich wie der Verteiler. Es hat auch das gleiche Problem und wurde ausgeführt seit so vielen Jahren. Es scheint, dass die Benutzerwahrnehmung nicht offensichtlich ist
4. Die Genauigkeitsanforderung an die Indikatorausgabe besteht darin, dass es bei der Aktualisierung von Strategien innerhalb von 60 Sekunden oder weniger zu keinen Unterbrechungen oder Fehlern kommt.
Nachdem die Richtlinienaktualisierung im Cluster wirksam wird, treten kurzfristige Fehler auf, wenn die Richtlinie nicht synchronisiert ist. Um dieses Problem zu lösen, wird auch das Konzept der Umstellungszeit in die Richtlinie eingeführt. Die Umstellungszeit ist auf 60 Sekunden ausgerichtet .
Einführung in jede Komponente
obc-Herrscher
Das Linealmodul hat zwei Hauptfunktionen: Dienstregistrierung/-erkennung und Richtlinienverwaltung, wie in der folgenden Abbildung dargestellt:
Der Aufbau der Dienstregistrierungs-/Erkennungsfunktionen ist in drei Schichten unterteilt. Die KV-Abstract-Schicht und die Memberlist-KV-Schicht verwenden die Drei-Parteien-Bibliothek grafana/dskit. Diese Bibliothek unterstützt verschiedene KVs wie Consul und etcd unter der KV-Abstract-Schicht. Wir schließlich Wir haben uns für die Verwendung von Memberlist-KV entschieden, um die endgültige Konsistenz-KV basierend auf der vom Gossip-Protokoll bereitgestellten Datensynchronisierungsfunktion zu erstellen. Der Grund dafür ist, dass wir hoffen, dass das Observable selbst externe Abhängigkeiten so weit wie möglich reduziert, um zu vermeiden, dass es sich bei der Bereitstellung auf externe Komponenten verlässt Beobachtungsfähigkeiten, und diese externen Komponenten sind auf unsere Beobachtungsfähigkeiten angewiesen, um ihre Stabilität sicherzustellen, was ein zirkuläres Abhängigkeitsproblem darstellt. Die direkte Erklärung für den Heartbeat und das Hashing der oberen Schicht sind die beiden im KV-Speicher registrierten Schlüssel und ihre unterstützende Konfliktzusammenführungslogik. Der Heartbeat-Schlüssel speichert Informationen wie die Adresse des Workers, die Registrierungszeit, die letzte Heartbeat-Zeit, dem Worker zugewiesene Hash-Tokens usw., während der Hashing-Schlüssel die Worker-Hash-Ringe mehrerer Cutover-Versionen speichert.
Das Richtlinienverwaltungsmodul ist in vier Schichten unterteilt. Die unterste Schicht besteht aus verschiedenen Ladeprogrammen, die für das Laden von Konfigurationen aus externen Richtlinienquellen verantwortlich sind. In der Abbildung sind die Computing-Richtlinienladeprogramme mehrerer unserer wichtigsten Produkte aufgeführt. Für bestehende Rechenaufgaben werden wir zur Migration von OBC einen Parser anpassen, um Rechenstrategien umzuwandeln. Für neue Rechenaufgaben benötigen wir eine einheitliche Verwendung von PromQL, um seine Rechenanforderungen zu beschreiben und die PromQL-Parser-Analyse zu verwenden. Der vom Parser erstellte Ausführungsplan ist ein Baum, und der Optimierer führt einige Optimierungen am Ausführungsplan durch. Tatsächlich handelt es sich derzeit nur um eine einfache Zusammenführung einiger Operatoren. Der Multiversionsmanager übernimmt die Gesamtplanung von Richtlinienaktualisierungen und verbietet abnormale Richtlinien.
obc-verteiler
Die Kernfunktion des Verteilermoduls besteht darin, Berechnungsstrategien zu korrelieren und Metrik-Datenpunkte weiterzuleiten.
Die hier beim Strategieabgleich geleistete Arbeit besteht darin, Datenpunkte gemäß der angegebenen Bezeichnung zu filtern und die gefilterten Datenpunkte mit der ID der entsprechenden Strategie zu kennzeichnen. Einer unserer größeren Online-OBC-Computing-Cluster hat ein Eingabevolumen von fast 1.000 W/s und die Anzahl der effektiven Computing-Richtlinien beträgt 1,2 W. Die Datenmenge ist in der Tat zu groß. Um die Screening-Effizienz zu verbessern, haben wir dies getan Es wurden einige Einschränkungen für die wirksamen Richtlinien vorgenommen: Die Richtlinienüberprüfung muss zwei Beschriftungen enthalten, __name__ und __ns__, und diese beiden Beschriftungen können keinen regulären Abgleich verwenden. __name__ ist der Name des Indikators und __ns__ bedeutet Namespace, der den Dienstcluster darstellt, an den der Indikator gemeldet wird. Wir verlassen uns auf diese beiden Labels, um einen zweistufigen Index zu erstellen und die Effizienz des Richtlinienabgleichs zu verbessern.
Die Neuetikettierungsaktion besteht darin, die Beschriftungen von Datenpunkten gemäß den Anforderungen der Richtlinie hinzuzufügen/zu löschen/zu ändern. In Bezug auf die Konfigurationssyntax verarbeiten wir diese Regeln zur Vereinheitlichung der Beschreibung in PromQL-Funktionen und beschränken die Vektorparameter dieser Funktionen nur auf einen Selektor oder eine andere Relabel-Funktion. Die Mapping-Aktion ähnelt dem Dimensionstabellen-Join bei anderen Streaming-Computing-Vorgängen. Sie ist das Produkt eines Kompromisses, um auf bestehende Computeraufgaben zuzugreifen, und wird nicht im Detail vorgestellt.
Der Prozess der Arbeitnehmerauswahl:
Datenpunkt-Ereigniszeit-Ausrichtungszeit: align_time = event_time - event_time % Auflösung, wobei die Auflösung die Genauigkeit des erwarteten Ausgabeindikators ist, der in der Strategie angegeben ist
Auswahl des Worker-Hash-Rings: Verwenden Sie align_time, um den neuesten Worker-Hash-Ring in der Hash-Ring-Liste zu finden, dessen Cutover nicht größer als align_time ist.
Auswahl der Worker-Instanz: Verwenden Sie planid + align_time + den Wert einer Reihe angegebener Labels als Schlüssel zum Berechnen des Hash-Werts und verwenden Sie den Hash-Wert, um die Worker-Instanz im Worker-Hash-Ring zu finden. Die angegebene Reihe von Beschriftungen wird vom Lineal nach der Analyse der Strategie generiert und ist im Allgemeinen leer für Strategien, die die Verarbeitung einer kleinen Datenmenge erfordern.
obc-worker
Die Kernfunktion des Arbeiters ist die Berechnung von Metrikindikatoren
Der Distributor stellt sicher, dass Metrikpunkte derselben Richtlinie, derselben Aggregationsdimension und desselben Berechnungsfensters an denselben Worker weitergeleitet werden. Die vom Mitarbeiter empfangenen Metrikdatenpunkte enthalten die Richtlinien-ID-Informationen, und der Mitarbeiter verwendet diese, um den Richtlinieninhalt zu finden und zu berechnen. Die kleinste logische Operationseinheit zur Berechnung von Strategien ist Action. Funktionen, Binäroperationen und Aggregationsoperationen in PromQL werden alle in Actions übersetzt. In der Aggregationsmatrix des Workers befindet sich unter jeder Aktion eine Reihe von Zeitfenstern, die entsprechend der Auflösung ausgerichtet sind. Innerhalb des Zeitfensters wird ein Satz von Daten, die zusammen berechnet werden müssen, auf dieselbe Recheneinheit geschrieben. Die Recheneinheit ist im Arbeiter. Die kleinste physikalische Recheneinheit. Daten, die derselben Recheneinheit hinzugefügt werden, werden nicht zwischengespeichert, sondern für Berechnungen in Echtzeit verwendet, sofern dies nicht erforderlich ist.
Dies ist möglicherweise schwer zu verstehen. Lassen Sie mich ein Beispiel geben, indem ich die Berechnungsregel sum by (caller, callee) (rpc_counter) nehme. Die Filterung des ursprünglichen Indikators rpc_counter wird im Verteiler abgeschlossen und die Aktion sum by (caller , Aufgerufener) wird als Aktion verarbeitet. Der Aktionstyp ist eine Aggregationsoperation. Der Aggregationstyp ist Summierung. Die Dimensionen der Datenausgabe nach der Aggregation sind Aufrufer und Aufgerufener. Bei der Verarbeitung von Datenpunkten vergleicht der Worker die Daten mit dem Gleicher Wert der beiden Bezeichnungen „Anrufer“ und „Angerufener“. Die Punkte werden an dieselbe Aggregationseinheit gesendet. Jedes Mal, wenn die Aggregationseinheit einen Punkt empfängt, führt sie eine Aktion wie „Summe += Punkt.Wert“ aus.
Ein Problem, auf das Mitarbeiter bei der Verarbeitung binärer Operationen und Aggregationsoperationen achten müssen, ist die Einstellung der Fensteröffnungszeit. Wie lange wartet ein Fenster auf das Eintreffen aller Daten, die es benötigt? Dieser Wert wirkt sich direkt auf die Echtzeit und Genauigkeit von aus Anzeigeausgang. Wir haben die folgende Standardrichtlinie basierend auf der Verzögerungsverteilung unserer eigenen Metriken bei der Linkübertragung festgelegt:
Wenn der ursprüngliche Anzeigeschrittwert kleiner oder gleich 10 ist, wird die Fensteröffnungszeit auf 25 s eingestellt.
Wenn der ursprüngliche Indikatorschrittwert größer als 10 ist, wird die Fensteröffnungszeit auf 2*Schritt + 5 eingestellt. Wenn die Fensteröffnungszeit größer als 120 Sekunden ist, wird die Fensteröffnungszeit auf 120 eingestellt
In diesem Teil wird die Implementierung jeder Komponente relativ kurz vorgestellt. Es wird nur der Kernprozess vorgestellt. Viele der Kompromisse und Optimierungen, die wir in Bezug auf Leistung und Funktionen vorgenommen haben, werden bei Gelegenheit separat vorgestellt.
Ergänzende Inhalte
Um das Verständnis für alle zu erleichtern, werden hier einige zusätzliche Inhalte hinzugefügt.
Beispiel für eine Berechnungsstrategie
Die interne Strategie von OBC wird in Form eines Baums ausgedrückt. Die Blattknoten des Baums müssen die Filterbedingungen oder Konstanten von Metriken sein, und die Blattknoten dürfen keine Konstanten sein (eine solche Strategie ist für ereignisgesteuert bedeutungslos). Die Filterung von Metriken Die Bedingung wird in der Richtlinie als Filter bezeichnet. Der Filter wird auf dem Verteiler ausgeführt, und die restlichen Aktionen werden auf dem Worker ausgeführt. Wenn die Richtlinie nicht speziell festgelegt ist, werden die mit der Richtlinie im selben Fenster übereinstimmenden Metriken an denselben Worker gesendet. Die nachfolgende Aktionsverarbeitung wird für diesen Worker abgeschlossen. Daten aus verschiedenen Fenstern können an verschiedene Worker gesendet werden. Der Grund dafür Dies bedeutet, dass ein Lastausgleich zwischen den Arbeitnehmern nicht einfach dadurch erreicht werden kann, dass man sie in der politischen Dimension verteilt.
Hier ist ein besonderer Punkt zu beachten: Wenn die Datenmenge in einem einzelnen Fenster einer bestimmten Richtlinie zu groß ist, als dass ein einzelner Mitarbeiter sie verarbeiten könnte, nehmen wir manuell einige Einstellungen vor, um die Richtlinie gemäß einer aggregierten Berechnung auf mehrere Mitarbeiter zu verteilen Maße. Wenn es nicht zerlegt werden kann oder wenn ein einzelner Arbeiter nach dem Zerkleinern immer noch nicht damit umgehen kann, werden wir uns dafür entscheiden, es zu verbieten. Da wir die gefilterten Daten in der Berechnungsrichtlinie auf die Bezeichnung __ns__ beschränken und nur die Metrikdaten desselben Dienstes für die Berechnung verwenden können, sind wir bisher natürlich noch nicht auf eine Situation gestoßen, die eine Verbotsrichtlinie erfordert. Für Situationen, in denen ein einzelner Mitarbeiter damit nicht umgehen kann, können Sie sich auch dafür entscheiden, Kaskaden-Computing-Funktionen zwischen Mitarbeitern zu implementieren und große Datenaufgaben zusammengeführt zu verarbeiten. Bei späterem Bedarf kann diese Fähigkeit schnell auf die aktuelle Architektur erweitert werden.
Unterstützung für PromQL
OBC hofft, PromQL als Benutzerzugriffsmethode für Computerstrategien verwenden zu können, wodurch das Verständnis der Benutzer für Strategien und die Zugriffskosten verringert werden können. Zum Zeitpunkt des Verfassens dieses Artikels ist unser Fertigstellungsgrad der PromQL-Syntax- und Funktionsunterstützung nicht hoch. Der Hauptgrund dafür ist, dass es viele Vorgänge und strategische Zugriffe auf Betreiberbestände gibt, die nicht genutzt werden. Die Nachfrage treibt uns zu einer schrittweisen Implementierung Sie können sie bei Bedarf verwenden. In der Implementierung gibt es auch einige PromQL-Syntax, die nicht für die Implementierung in Echtzeitberechnungen geeignet ist, wie z. B. Offset-Modifikator, @-Modifikator und Unterabfrage.
Im vorherigen Artikel haben wir vorgestellt, dass der Verteiler sicherstellt, dass die Daten desselben Berechnungsfensters derselben Berechnungsstrategie an denselben Mitarbeiter weitergeleitet werden. Sie fragen sich hier vielleicht, was ist mit dem Bereichsvektor? Wie berechnet man irate, wenn zwei Punkte im Fenster vor und nach Vorgängen wie irate (http_request_total[10s]) an verschiedene Worker weitergeleitet werden? Wenn Sie solche Zweifel haben, dann sollte ich mir selbst gratulieren, dass ich Sie dazu gebracht habe, sorgfältig zu lesen und zu verstehen, was ich zuvor geschrieben habe.
Entfernungsvektoren, einschließlich Entfernungsvektorauswahl und Entfernungsvektorfunktion, werden in der aktuellen Version von OBC nicht unterstützt. Der Grund, warum sie nicht unterstützt werden, liegt darin, dass wir sie derzeit nicht verwenden können. Sie können denken, dass unsere internen Daten alle Gauge-Daten sind Typen in Prometheus. Für Anfragen Der sogenannte Counter-Indikator auf unserer Seite zählt tatsächlich das Anfragevolumen in jedem 10-s-Zyklus. Die Daten zwischen den Zyklen werden nicht akkumuliert, genauso wie unsere Counter-Daten erhöht wurden (http_request_total), bevor sie gemeldet werden. [ 10s]) einen solchen Vorgang. Natürlich werden wir in Zukunft definitiv darüber nachdenken, die Syntaxunterstützung für Bereichsvektoren zu implementieren, aber wir werden auch einige Syntaxeinschränkungen vornehmen.
Genaue Cluster-Granularitäts-Anforderungslatenz
Die Didi Observable Platform hatte das Konzept des Histogramms als Datentyp nicht, bevor sie die Prometheus Exporter-Erfassung und den PromQL-Datenabruf unterstützte. In Bezug auf die Verzögerung der Dienstanforderung verwenden wir den T-Digest-Algorithmus auf der Erfassungsseite, um die Schnittstellenverzögerungsverteilung jeder Dienstinstanz zu approximieren, und melden standardmäßig die Verzögerungsdaten der Quantilwerte 99, 95, 90 und 50. Aufgrund des Mangels an Originalinformationen ist es nicht möglich, Benutzern eine relativ genaue Berechnung des Verzögerungsquantilwerts der Cluster-Granularitätsschnittstelle bereitzustellen. Sie können stattdessen nur den Durchschnitts- oder Maximalwert des Verzögerungsquantilwertindikators für die Granularität einer einzelnen Maschine verwenden.
Wir haben dieses Problem auch auf OBC gelöst. Die spezifische Methode besteht darin, dass OBC mit dem Sammlungsende zusammenarbeitet. Wenn das Sammlungsende den Verzögerungsquantilwertindikator meldet, werden auch die Bucket-Informationen der Schnittstellenverzögerungsverteilung zusammen gemeldet. Bucket-Informationen fallen nicht in den persistenten Speicher, sondern werden nur bei Bedarf in OBC aufgenommen. OBC erweitert die relevanten Vorgänge in einen PromQL-Aggregationsoperator. Der Name dieses Operators ist Percentile und seine Aktion besteht darin, die Bucket-Informationen eines einzelnen zusammenzuführen Maschine. Eine neue Verzögerungsverteilung, die bei Bedarf die Quantile dieser Verteilung erzeugt.
Zusammenfassung und Ausblick
Bisher läuft OBC seit mehr als mehreren Monaten stabil online. Mehrere zentrale Metrics-Computing-Aufgaben der Observable-Plattform wurden auf OBC migriert und erhebliche Kostenvorteile erzielt.
In Bezug auf die Ideen für die anschließende Projektiteration finden Sie hier eine Einführung in einen der Kernpunkte. Wir hoffen, das Sammlungsende in diesen Satz von Computer-Engines einzubeziehen, um die Integration von Sammlung und Berechnung zu erreichen: Für die Computeranforderungen des Benutzers können wir uns bewegen so weit wie möglich nach vorne. Das Erfassungsende ist abgeschlossen, und die Vorberechnung kann am Erfassungsende durchgeführt werden, und die Vorberechnung kann so weit wie möglich am Erfassungsende durchgeführt werden.
Nach der Berechnung durch die Berechnungsmaschine haben wir weitere Beobachtungsdaten erstellt, darunter Originaldaten und neue Berechnungsergebnisse. Wo werden diese Daten letztendlich gespeichert? Ob man sich für Zeilenspeicher oder Spaltenspeicher entscheidet, ob man bestehende Lösungen nutzt oder selbst recherchiert und wie man massive Datenprobleme löst. Der nächste Artikel erzählt die Geschichte der Beobachtungsdatenspeicherung in Didi.
Cloud Native Night Talk
Wie unterstützen Sie die Berechnungsanforderungen beobachtbarer Indikatoren in der Produktionsumgebung? Hinterlassen Sie gerne eine Nachricht im Kommentarbereich. Wenn Sie weiter mit uns kommunizieren möchten, können Sie auch direkt eine private Nachricht an das Backend senden.
Der Autor wählt eine der bedeutungsvollsten Nachrichten aus und sendet einen maßgeschneiderten Didi-Koffer und wünscht Ihnen eine sorgenfreie Reise am 1. Oktober. Die Verlosung erfolgt am 26. September um 21 Uhr.
