Zusammenfassung: Als hervorragende Open-Source-Software für verteilte Datenbanken hat TiDB immer mehr Aufmerksamkeit und Anwendungen von Benutzern erhalten. Im Prozess der Betriebs- und Wartungssicherung ist es jedoch auch mit Betriebs- und Wartungsinseln, Schwierigkeiten bei der Abgrenzung und Positionierung usw. konfrontiert Dieser Artikel fasst die Best Practices für TiDB-Benutzer zum Aufbau einer Full-Stack-Observability auf Basis von DeepFlow zusammen, einschließlich der Verwendung der leistungsstarken, eingriffsfreien Observability-Technologie von DeepFlow, um die blinden Flecken der Full-Link-Verfolgung zu beseitigen Die TiDB-Seite und die Verwendung der leistungsstarken Zero-Intrusion-Observability-Technologie von DeepFlow, um blinde Flecken auf der TiDB-Seite zu beseitigen .
01: Herausforderungen bei Betrieb und Wartung verteilter Datenbanken
Im täglichen Betrieb und bei der Wartung stehen DBAs verteilter Datenbanken in der Regel vor drei Herausforderungen:
- Echtzeitleistung von Beobachtungsdaten : Da die herkömmliche Instrumentierungsmethode offensichtliche Leistungseinbußen mit sich bringt, aktiviert der DBA die integrierte verteilte Verfolgungsfunktion von TiDB erst, nachdem eine Geschäftsausnahme auftritt. Die Fehlerbehandlung kann nur durch wiederholte Wiederholungen nach der Analyse erfolgen und passive Positionierung.
- Umfang der Beobachtungsdaten : Der herkömmliche Datenbankbetrieb und die Wartung basieren hauptsächlich auf den eigenen Daten der Datenbank. Es fehlen Echtzeitdaten von Clientanwendungen, Systemressourcen, Lesen und Schreiben von Datenbankdateien, Servernetzwerkleistung und anderen Dimensionen diagnostischer blinder Fleck.
- Beobachtungs- und Diagnosekontinuität : Bei herkömmlichen Überwachungstools müssen die Daten häufig zwischen verschiedenen Betriebs- und Wartungsteams übertragen werden. Der Analyseprozess erfordert häufig eine Unterbrechung.
Die oben genannten Probleme haben zu einer Trennung zwischen Datenbankbetrieb und -wartung und anderen Vorgängen und Wartungsarbeiten geführt, wodurch eine Betriebs- und Wartungsinsel entstanden ist. Betriebsrisiken sind schwer zu erkennen, Fehler sind schwer abzugrenzen, Wiederherstellungszyklen sind lang, Kommunikation und Zusammenarbeit sind zahlreich und es gibt zahlreiche Betriebs- und Wartungskonflikte.
DeepFlow bietet TiDB Full-Stack-, Full-Link- und produktionsbereite Beobachtungsfunktionen durch mehrere Kernfunktionen wie Zero-Intrusion, Hochleistungs-Beobachtungsdatenerfassung, offenen Beobachtungsdatenzugriff und einheitliche Beobachtungsdaten-Korrelationsanalyse und unterstützt DBA bei der Erstellung vollständiger Daten -Link-Überwachung, schnelle Fehlerabgrenzung, Ursachenanalyse und andere Funktionen, um die Effizienz des Betriebs und der Wartung verteilter Datenbanken effektiv zu verbessern und die oben genannten Betriebs- und Wartungsprobleme zu lösen.
02: TiDB Observability-Bereitstellungslösung
Im TiDB-Beobachtungspraxisplan stellen wir DeepFlow Agent automatisch im Knoten des Geschäftsclusters und des verteilten TiDB-Datenbankclusters bereit, um mehrdimensionale Beobachtungsdaten zu sammeln und zu sammeln. Die strukturierten Beobachtungsdaten werden über das Netzwerk übertragen und einheitlich verarbeitet (Einheitliche Datenkennzeichnung). , einheitliche zugehörige Daten und einheitliche Analysedaten) werden zentral auf dem DeepFlow-Server gespeichert; durch ein funktionales Design, das eng an das Betriebs- und Wartungsszenario angepasst ist, bieten diese Daten flexible, mehrdimensionale Full-Stack-Beobachtungs- und Analysefunktionen von Makro bis Mikro. .
DeepFlow Agent sammelt und sammelt umfangreiche Beobachtungsdaten, darunter:
- eBPF-Zero-Intrusion-Daten : Anrufkettenverfolgung, SQL-Leistungsindikatoren, SQL-Anrufprotokolle, Netzwerkleistungsindikatoren, Netzwerkflussprotokolle, Dateilese- und -schreibereignisse, CPU-Leistung und andere Beobachtungsdaten
- OpenTelemetry-Instrumentierungsdaten : Anrufkettenverfolgungsdaten innerhalb jeder Komponente von TiDB
- Prometheus Exporter-Daten : K8s-Systemindikatoren, TiDB-Leistungsindikatoren
03: Anrufkettenverfolgung
In der Praxis der Full-Stack-Beobachtung von TiDB haben wir durch die eBPF-Technologie vollständige Link-Anrufkettenverfolgungsfunktionen einschließlich Front-End-Anwendungen, Zwischennetzwerken, TiDB-Proxy und TiDB erreicht implementiert durch DeepFlow Tracking hat die folgenden vorteilhaften Eigenschaften:
- Keine blinden Flecken : Eliminiert blinde Flecken bei der Verfolgung in TiDB, Gateway-Middleware und Zwischennetzwerken;
- Hohe Leistung : Hochleistungsfähiges, eingriffsfreies Tracking, das durch die eBPF-Technologie erreicht wird, schafft produktionsbereite , nicht stichprobenartige Tracking- und Beobachtungsfunktionen für TiDB;
- Hot-Reloading : Durch die Code-Hot-Swapping-Funktion der eBPF-Technologie stehen in Anwendungen und TiDB-Clustern jederzeit Online- Tracking-Funktionen zur Verfügung . Selbst kleine Leistungsschwankungen können kontinuierlich auf einer feinkörnigen Ebene beobachtet werden, um Systemrisiken schnell zu erkennen und zu beseitigen.
- Technologieübergreifender Stack : Durch die Full-Stack-Tracking-Fähigkeit werden eine einheitliche Verfolgung und einheitliche Zusammenarbeit mehrerer Betriebs- und Wartungstechnologie-Stacks wie DBA, Datenbankentwicklung, Systembetrieb und -wartung sowie Anwendungsbetrieb und -wartung realisiert, um Fehlergrenzen schnell zu ermitteln und Verbesserung der Effizienz der technischen Zusammenarbeit.
1) Anrufkettenverfolgung ohne tote Winkel
Wir können diese Frage anhand eines einfachen schematischen Diagramms beantworten: Warum erreicht DeepFlow eBPF Zero-Intrusion Collection im Vergleich zu herkömmlichen Instrumentierungslösungen tatsächlich eine Anrufkettenverfolgung ohne tote Winkel?
Anwendungsinstrumentierung
Herkömmliche APM-Technologie verfolgt die Anwendungsaufrufkette durch Anwendungscode-Instrumentierung. Der Beobachtungsbereich ist auf den Anwendungsbereich beschränkt, der instrumentiert werden kann. Die Überwachungsfähigkeit bildet einen blinden Fleck auf der TiDB-Seite Es ist unmöglich, schnell festzustellen, ob TiDB die Ursache des Problems ist.
Anwendungsinstrumentierung + TiDB-Instrumentierung
Um die Tracking-Funktion für Anwendungsaufrufe auf TiDB auszudehnen, haben wir der TiDB-Community eine PR zur Code-Reparatur vorgelegt und die Tracking-Funktion auf der TiDB-Seite implementiert. Später stellten wir jedoch fest, dass es in TiDB immer noch drei Probleme mit der Instrumentierung gibt:
- Das Netzwerk in der TiDB-Betriebsumgebung befindet sich in einem toten Winkel und die Auswirkungen des Netzwerks auf die SQL-Leistung können nicht diagnostiziert werden.
- TiDB-Proxy vor TiDB befindet sich in einem blinden Fleck bei der Verfolgung und kann die Auswirkungen von TiDB-Proxy auf die SQL-Leistung nicht diagnostizieren;
- Die Antwortleistung ist nach der TiDB-Instrumentierung erheblich gesunken (spezifische Daten siehe unten) und kann nicht kontinuierlich in einem Produktionssystem verwendet werden.
DeepFlow eBPF Zero-Intrusion-Erfassung
Die Zero-Intrusion-Call-Chain-Tracking-Funktion, die durch die eBPF-Technologie von DeepFlow aufgebaut wird, eliminiert die Tracking-Blindspots von TiDB und verfügt über vollständige Tracking-Funktionen für die folgenden Standorte in jedem Anwendungsaufrufprozess: 1) Front-End-Anwendung 2) TiDB-Proxy; 4) K8s-Netzwerk.
An diesem Punkt können wir eine bestimmte langsame Antwort im Flammendiagramm der DeepFlow-Anrufkettenverfolgung verfolgen, intuitiv den Beitragsanteil jeder Position zur Antwortverzögerung beobachten und so schnell den Quellort einer bestimmten langsamen Antwort bestimmen:
In der folgenden Abbildung können wir beispielsweise in einem Teil eines DeepFlow-Aufrufkettenverfolgungs-Flammendiagramms deutlich feststellen, dass der MySQL- COM_QUERY COMMITAufruf in einem bestimmten Geschäftsprozess eine Verzögerung von 480 ms bei der Verarbeitung des TIDB-Proxy-Prozesses einführt:
2) Hochleistungsfähige Anrufkettenverfolgung
Das kritischste Problem, das die Implementierung der TiDB-Beobachtbarkeit in tatsächlichen Produktionssystemen behindert, ist die Leistung der Beobachtungsdatenerfassung.
Wir haben festgestellt, dass die Verwendung von Technologien wie In-Application-Instrumentierung und Java-Agent-Bytecode-Verbesserung zur Implementierung der Aufrufkettensammlung zu einem erheblichen und schwer zu definierenden zusätzlichen Ressourcenverbrauch führen und zu erheblichen Leistungseinbußen im Unternehmen führen kann, was zu solchen Problemen führt Technische Lösungen können nicht in Systemen mit hohen Anforderungen an Parallelität, Leistung und Zuverlässigkeit implementiert werden. Viele Unternehmen können solche Tracking-Funktionen nur in Testsystemen oder unwichtigen Produktionssystemen aktivieren, während wichtigere Produktionssysteme nur eine hohe Sampling- und Tracking-Leistung nutzen können, um die negativen Auswirkungen auf das Geschäft, insbesondere die Kernproduktionssysteme, zu reduzieren Die Industrie wird vollständig auf Tracking-Funktionen verzichten, um sicherzustellen, dass die Geschäftsleistung nicht beeinträchtigt wird. Dies führt jedoch zu schwachen Betriebsunterstützungsfunktionen und außer Kontrolle geratenen Betriebs- und Wartungsrisiken.
DeepFlow nutzt die eBPF-Technologie, um eine Zero-Intrusion-Beobachtbarkeit (Zero Code) zu erreichen, die diese Probleme sehr gut löst. Die Auswirkungen auf das Geschäft (Reaktionszeit) liegen normalerweise nur unter einer Millisekunde, und der Ressourcenverbrauch des Agenten ist vorhersehbar und konfigurierbar. Dank der Just-in-Time-Technologie (JIT) kann die Laufeffizienz des eBPF-Codes von DeepFlow Agent mit der Leistung des nativen Codes des Kernels vergleichbar sein und hat keinen Einfluss auf den Verarbeitungsprozess der Anwendung während des Erfassungsprozesses, sodass die Anwendung dies kann Nennen Sie den Verarbeitungsprozess „Zero Intrusion“.
In der Full-Stack-Beobachtungspraxis von TiDB durch DeepFlow haben wir die unterschiedliche Leistung der Geschäftsleistung des TiDB-Clusters getestet und verifiziert, wenn wir Jaeger-Instrumente und die eBPF-Zero-Intrusion-Technologie von DeepFlow für die Beobachtbarkeitspraxis verwendet haben.
TiDB-SQL-Antwortverzögerung während der Jaeger-Instrumentierungserfassung : Wir haben die OpenTracing-Funktion von TiDB aktiviert und die Antwortleistung des Anwendungsinstanzspeicherorts (svc-order) beim Zugriff auf Tiproxy beobachtet. Wir können sehen, dass die durchschnittliche SQL-Antwortverzögerung stabil bei 300 bis 400 ms liegt In einigen Fällen beträgt die durchschnittliche maximale Verzögerung mehr als 1,5 Sekunden .
Verzögerung der TiDB-SQL-Antwort während der DeepFlow-eBPF-Erfassung : Wir verwenden den DeepFlow-Agenten, um nicht abgetastete Beobachtungsdaten im verteilten TiDB-Cluster zu sammeln und die Antwortleistung des Anwendungsinstanzspeicherorts (svc-order) beim Zugriff auf tiproxy zu beobachten Die durchschnittliche Verzögerung wird auf 3 bis 5 ms reduziert und die maximale Verzögerung überschreitet 38 ms nicht .
Aus den oben genannten Leistungsvergleichsdaten haben wir herausgefunden , dass die von DeepFlow durch die eBPF-Technologie erreichte Zero-Intrusion-Beobachtbarkeit die durch die Instrumentierungslösung verursachten Geschäftsleistungsprobleme löst, sodass eine produktionsbereite, unkomplizierte Lösung für die verteilte TiDB erstellt werden kann Datenbank des Kern-IT-Produktionssystems. Sampling- und Tracking-Beobachtungsfunktionen.
3) Anrufkettenverfolgung mit Hot Loading jederzeit
Aufgrund von geschäftlichen Leistungseinbußen, die durch technische Maßnahmen wie In-Application-Instrumentierung und Java-Agent-Bytecode-Verbesserung verursacht werden, schalten wichtige Kernproduktionssysteme grundsätzlich die Tracing-Funktionen im täglichen Betrieb ab. Wenn jedoch Fehler oder Ausnahmen auftreten, ist eine differenzierte Tracing-Funktion erforderlich. , stellte jedoch fest, dass der Startvorgang der Instrumentierung und des Java-Agenten einen Neustart der Anwendungsinstanzen und TiDB-Komponenteninstanzen des Kernproduktionssystems erfordert. Zu diesem Zeitpunkt wird es zu einer schwierigen und schmerzhaften Entscheidung, ob die Tracking-Funktion aktiviert werden soll, was letztendlich dazu führt Betriebs- und Wartungsstatus quo:
- Kleinere Fehler bleiben unbemerkt und führen dazu, dass das System mit versteckten Gefahren läuft.
- Für Zwischenfehler wird viel investiert , die Testumgebung wird wiederholt getestet und die Grundursache wird durch Glück ermittelt.
- Es wurden alle Anstrengungen unternommen, um größere Störungen zu beheben , und das gesamte Team arbeitete rund um die Uhr, unabhängig von den Kosten, bis der Betrieb wiederhergestellt war.
Das Gesetz von Hayne sagt uns, dass hinter jedem schweren Unfall 29 kleinere Unfälle und 300 potenzielle versteckte Gefahren stehen. Das gleiche Muster gilt für den Betrieb und die Wartung von IT-Systemen. Gerade aufgrund der für den Start der Instrumentierung und des Java-Agenten erforderlichen Neustartaktionen sind viele potenzielle versteckte Gefahren und kleinere Fehler in der Produktionsumgebung schwer zu diagnostizieren und zu lokalisieren Es treten weiterhin schwerwiegende Störungen auf.
Die Zero-Intrusion Observability von DeepFlow löst dieses Problem perfekt. Wenn Sie die Anrufkettenverfolgungsfunktion für ein Anwendungssystem oder eine TiDB aktivieren müssen, können Sie den DeepFlow-Agenten jederzeit mit einem Klick bereitstellen, um mit der Verfolgung der Datenerfassung zu beginnen. Bei der Bereitstellung des Agenten müssen Sie nicht in den Anwendungs-POD und die TiDB eindringen Komponente POD, noch müssen Sie die Anwendung, TiDB oder das Betriebssystem neu starten. Der Agent kann den Tracking-Datenerfassungscode sofort in den Kernel des Betriebssystems laden und nur über die eBPF-Technologie des mit der Tracking-Datenerfassung an jedem Standort beginnen Linux-Betriebssystem. Selbst bei Geschäftssystemen mit sehr hoher Auslastung können Sie, wenn Sie die Tracking-Funktion deinstallieren möchten, den eBPF-Erfassungsschalter des Agenten online deaktivieren oder den Agenten deinstallieren, und der Tracking-Datenerfassungscode kann sofort vom Betriebssystemkernel deinstalliert werden . Während dieses gesamten Prozesses haben die Anwendung der oberen Schicht und das TiDB-Komponentenprogramm kein Bewusstsein.
Die Call-Chain-Tracking-Funktion von DeepFlow Agent kann jederzeit im Betriebssystemkernel geladen werden, sodass wir jederzeit Online- und Offline-Funktionen im Anwendungssystem und im TiDB-Cluster verfolgen und beobachten können, ohne uns Gedanken über Störungen der Anwendung machen zu müssen um kleinere und mittlere Fehler jederzeit zu erkennen. Führen Sie detaillierte Beobachtungen durch, um Systemgefahren schnell zu erkennen und zu beseitigen und so größere Ausfälle zu vermeiden.
4) Anrufkettenverfolgung für eine einheitliche Zusammenarbeit über Technologie-Stacks hinweg
Die APM-Verfolgung der traditionellen Instrumentierungstechnologie eignet sich für Anwendungsentwickler und TiDB-Entwickler. Die Aufrufkette spiegelt mehr über die Funktionsaufrufbeziehung innerhalb des Prozesses wider, die ohne Entwicklungshintergrund schwer zu verstehen ist Operationen müssen dimensionale Rollen sind von wenig praktischer Hilfe. Die DeepFlow-Beobachtungsplattform realisiert die vollständige Stapelverfolgungsfunktion jedes Anwendungsaufrufs von der Anwendung zum Betriebssystem und zum zugrunde liegenden Netzwerk, sodass sie TiDB-Betrieb und -Wartung, TiDB-Entwicklung, Anwendungsentwicklung, K8s-Betrieb und -Wartung sowie Middleware-Betrieb aufbauen kann Mit den umfassenden Betriebs- und Wartungsfunktionen jedes Technologie-Stacks können wir klare Einblicke in die Leistung jeder Verarbeitungsverbindung im gesamten Prozess eines Anwendungsaufrufs gewinnen und die Fehlergrenze schnell bestimmen.
Nehmen Sie die obige Abbildung als Beispiel in der beobachtbaren DeepFlow-Plattform:
- Entwicklung, Betrieb und Wartung von Geschäftsanwendungen : Durch die Aufrufverzögerung von Geschäftsanwendungs-Microservices können versteckte Gefahren oder Fehler in Geschäftsanwendungen schnell diagnostiziert und entdeckt werden.
- Betrieb und Wartung von K8s : Durch die Anrufverzögerung der Netzwerkkarte zwischen den einzelnen Microservice-Instanzen können versteckte Gefahren oder Fehler in der K8s-Plattform erkannt werden.
- Betrieb und Wartung der Middleware : Durch die Aufrufverzögerung des TiDB-Proxy-Standorts können versteckte Gefahren oder Fehler in der Middleware schnell diagnostiziert und entdeckt werden.
- DBA : Verwenden Sie die von eBPF erfasste TiDB-Aufrufverzögerung, um versteckte Gefahren oder Fehler auf der TiDB-Seite schnell zu diagnostizieren.
- Datenbankentwicklung : Nachdem Datenbankentwickler die OpenTelemetry-Instrumentierungsdaten von TiDB bei Bedarf aktiviert haben, können sie versteckte Gefahren oder Fehler in wichtigen internen Funktionen von TiDB schnell diagnostizieren.
04: Rundumbeobachtung
Neben der Aufrufkettenverfolgung sind während des täglichen Betriebs und der Wartung von TiDB auch das Geschäftspanorama, die Netzwerkleistung, die Systemressourcenleistung, die Lese- und Schreibleistung von Betriebssystemdateien und die Leistung von Anwendungsfunktionen Dimensionen, die umfassend beobachtet und analysiert werden müssen Finden Sie das Problem schnell. Die Grundursache besteht darin, dass die Observability-Praxis die Silos mehrerer Arten von Beobachtungsdaten öffnen, Verbindungen zwischen Beobachtungsdaten herstellen und einen reibungslosen Beobachtungsbetriebsablauf entwerfen muss, damit das gesamte Betriebs- und Wartungspersonal effizient und effizient arbeiten kann Führen Sie den Beobachtungs-, Betriebs- und Wartungsprozess reibungslos durch. Beobachten Sie umfassende Daten und finden Sie schneller und einfacher Schlussfolgerungen aus den Daten.
In der TiDB-Beobachtbarkeitspraxis haben wir eine einheitliche Erfassung und Analyse mehrerer Datentypen in der DeepFlow-Plattform implementiert. Durch reibungslose Betriebsabläufe können wir effizient auf verschiedene Datentypen zugreifen und eine vollständige Palette von Beobachtungsfunktionen erreichen, darunter:
- Business-Panoramabeobachtung
- Beobachtung der Netzwerkleistung
- Traceback von SQL-Anweisungen
- Beobachtung der Systemressourcenleistung
- Beobachtung der Lese- und Schreibleistung von Dateien
- Beobachtung der Funktionsleistung (CPU-Profiling)
1) Geschäftspanoramabeobachtung
DeepFlow ruft Ressourcen-Tags und Geschäfts-Tags dynamisch durch Echtzeit-Docking mit Cloud-nativen API-Schnittstellen ab und ruft Daten-Tag-Tags für in Echtzeit gesammelte Anwendungen auf und realisiert so die Möglichkeit, ein Geschäftspanorama zu erstellen, das automatisiert und dynamisch mit dem Unternehmen aktualisiert wird .
In der auf DeepFlow basierenden TiDB-Beobachtbarkeitspraxis haben wir ein End-to-End-Geschäftspanorama von Cloud-nativen Anwendungsclustern bis hin zu verteilten TiDB-Datenbankclustern erstellt (wie unten gezeigt):
Durch den Aufbau einer Geschäftspanoramatopologie aus Cloud-nativen Anwendungsclustern und TiDB-Datenbankclustern können wir das Gesamtbild des IT-Geschäftssystems aus einer Makroperspektive beobachten. Wenn im Geschäftspanorama lokale Geschäftsleistungsanomalien festgestellt werden, können wir diese schrittweise mikroskopisch untersuchen Finden Sie schnell unbekannte Unbekannte.
2) Beobachtung der Netzwerkleistung
Netzwerkpaketverlust und Netzwerkverzögerung sind häufig vermutete Probleme im Fehlerdiagnoseprozess des TiDB-Datenbankclusters. Durch Beobachtung der Netzwerkleistung kann DeepFlow schnell feststellen, ob ein bestimmter Geschäftsausfall einer verteilten Datenbank durch einen Netzwerkausfall verursacht wird.
Bei der Beobachtung der Netzwerkleistung können wir die Netzwerkinteraktionsleistung des externen Zugriffs auf den TiDB-Cluster und des gegenseitigen Zugriffs auf interne Komponenten des TiDB-Clusters anhand der folgenden sechs Indikatoren beobachten und verschiedene Arten von Netzwerkübertragungsproblemen diagnostizieren und bestimmen:
- Bytes (Durchsatzrate) – Beobachten Sie den Netzwerkdurchsatzdruck
- TCP-Neuübertragungsverhältnis – Netzwerkpaketverlust beobachten
- TCP-Nullfensterverhältnis – Beobachtung der TCP-Überlastung
- Verbindungsaufbau-Fehler-Verhältnis: Beobachten Sie Anomalien beim TCP-Verbindungsaufbau
- Durchschnittliche Verzögerung beim TCP-Verbindungsaufbau – Beobachtete Netzwerk-RTT
- Durchschnittliche TCP/ICMP-Systemlatenz – beobachten Sie die Reaktionsgeschwindigkeit des Betriebssystems
Beispiel 1: Beobachten Sie schnell die Netzwerkinteraktionsleistung des Clients, der auf das TiDB-Portal zugreift
Beispiel 2: Beobachten Sie schnell die Netzwerkinteraktionsleistung zwischen internen TiDB-Komponenten
3) SQL-Anweisungs-Traceback
Unangemessene SQL-Anweisungen beanspruchen eine große Menge an CPU- und Speicherressourcen, erhöhen die Antwortverzögerung von TiDB und verringern die Gesamtleistung von TiDB. Daher ist das schnelle Zurückverfolgen ineffizienter SQL-Anweisungen ein wichtiger Teil des Datenbankbetriebs und der Datenbankwartung. Abfragen, die keine Indizes verwenden, vollständige Tabellenscans, übermäßig komplexe Abfragen und die Verwendung ungeeigneter Funktionen oder Datentypen sind alles Arten von „schlechtem SQL“, die eine Rückverfolgung und Konzentration auf SQL-Anweisungen erfordern.
In der TiDB-Beobachtbarkeitspraxis nutzt DeepFlow Zero-Intrusion-Bypass-Erfassungsfunktionen, um die Details jeder SQL-Anweisung, einschließlich SQL-Anweisungen, Antwortverzögerungen, Auftrittszeiten, Quellknoten usw., vollständig aufzuzeichnen, die beim Abrufen des Anrufprotokolls abgerufen werden können Verfolgen Sie die Häufigkeit fehlerhaften SQLs in Echtzeit und ermitteln Sie die SQL-Quelle.
4) Beobachtung der Systemressourcenleistung
Eine übermäßige CPU- und Speicherauslastung des Betriebssystems oder eine Überlastung der Netzwerkschnittstelle im gleichen Zeitraum können zum Auftreten von langsamem SQL führen. Um die Grundursache für langsame SQL-Probleme schneller und genauer zu finden, analysieren Sie daher schnell die TiDB Komponenten während des Fehlerdiagnoseprozesses Die CPU-, Speicher- und Netzwerkschnittstellenindikatoren einer Instanz sind ein wesentlicher Bestandteil der Verbesserung der Beobachtungsfunktionen, Betriebs- und Wartungsfunktionen sowie der Fehlerbehebungseffizienz verteilter Datenbanken.
In der Praxis der TiDB-Beobachtbarkeit sammeln wir Systemindikatoren über den Grafana-Agenten und importieren die Daten einheitlich in die DeepFlow-Beobachtbarkeitsplattform Indem Sie den Quell-POD von langsamem SQL in der Aufrufkettenverfolgung ermitteln, können Sie mit einem Klick die Änderungskurve der CPU-Auslastung, die Änderungskurve der Speicherauslastung und die Änderungskurve des Netzwerkdurchsatzes des POD anzeigen und das langsame SQL-Ereignis anhand der Indikatorwerte einfach ermitteln Während des Problemzeitraums. Korrelation mit der Leistung von System-CPU, Speicher und Netzwerkschnittstellenressourcen.
5) Beobachtung der Lese- und Schreibleistung von Dateien
Die Leistung beim Lesen und Schreiben von Dateien hat einen erheblichen Einfluss auf die SQL-Antwortleistung von TiDB. Obwohl die Möglichkeit eines langsamen Lesens und Schreibens von Dateien so weit wie möglich vermieden werden kann, müssen dabei immer noch zwei Fragen beantwortet werden TiDB-Betrieb und Wartung:
- Wenn sporadisch langsames SQL auftritt, wie kann dann festgestellt werden, ob sporadisch langsames Lesen und Schreiben von Dateien die Hauptursache des Problems ist?
- Wenn im System unbekannte große Dateien gelesen oder geschrieben werden oder häufig Dateien gelesen und geschrieben werden, wie kann dann der Quellprozess des Lesens und Schreibens von Dateien ermittelt werden?
DeepFlow realisiert die vollständige Erfassung und Beobachtung von Lese- und Schreibereignissen von Betriebssystemdateien über die eBPF-Funktion des Linux-Kernels und unterstützt mehrere Erfassungsmodi wie vollständige Erfassung und teilweise Erfassung.
Wenn eine Anwendung langsam reagiert, kann DeepFlow mit einem Klick alle Dateilese- und -schreibereignisse auf dem Client und Server während des Problemzeitraums abrufen und Dateivorgangsereignisse und Quellprozesse schnell in der Liste sperren. Wenn eine langsame SQL-Antwort auftritt, kann der DBA innerhalb von Sekunden feststellen, ob ein damit verbundenes langsames E/A-Ereignis vorliegt. Bei unbekanntem Dateilese- und -schreibverhalten können Systembetrieb und -wartung die Datei-E/A-Quelle innerhalb von Sekunden sperren:
6) Beobachtung der Funktionsleistung (CPU-Profiling)
Wenn während des Fehlerbehebungsprozesses für langsames SQL festgestellt wird, dass die CPU zum Engpass der Geschäftsleistung geworden ist, müssen Sie als Nächstes die CPU-Planungssituation des POD der TiDB-Komponente analysieren und die Hot-Funktionen in der TiDB-Komponente ermitteln Programm, und dann finden Sie das Programm Der Einstiegspunkt für die Optimierung. DeepFlow implementiert die CPU-Leistung-Datenerfassungs- und Beobachtungsfunktionen des Anwendungsprozesses durch die eBPF-Technologie des Linux-Kernels. Durch die Analyse der CPU-Leistung des TiDB-Komponentenanwendungsprozesses können Entwickler die Kernelfunktionen, Bibliotheksfunktionen und Anwendungsfunktionen einfach sperren jedes TiDB-Komponentenprogramm.
In der TiDB-Beobachtbarkeitspraxis haben wir DeepFlow verwendet, um die CPU-Leistung von TiDB-, PD- und TiKV-Komponenten zu analysieren. Darunter können wir im folgenden Flammendiagramm der CPU-Leistungsanalyse des TiDB-Prozesses deutlich erkennen, dass die Jaeger-Instrumentierung einen erheblichen CPU-Ressourcenaufwand für den TiDB-Prozess mit sich bringt :
05: Wertzusammenfassung
Gute Betriebs- und Wartungsunterstützungsfunktionen sind eine Voraussetzung für den stabilen Betrieb der verteilten TiDB-Datenbank. In dieser Observability-Praxis verwendet DeepFlow die führende leistungsstarke eBPF-Technologie zur Null-Intrusion-Datenerfassung, Zero-Instrumentation-Call-Chain-Tracking-Technologie und Multi-Source-The Die einheitliche Datenbeobachtungstechnologie bildet eine Beobachtbarkeitslösung für den vollständigen Stapel, die vollständige Verbindung, das jederzeitige Hot-Loading und die Produktionsimplementierung von TiDB , die die umfassenden Betriebs- und Wartungsfunktionen von TiDB erheblich verbessert und den stabilen Betrieb der TiDB-Datenbank effizient unterstützt hilft Benutzern, einen zuverlässigeren und stabileren Datenbankdienst zu erstellen.
06: Was ist DeepFlow?
DeepFlow ist ein von Yunshan Network entwickeltes Observability-Produkt mit dem Ziel, eine umfassende Observability für komplexe Cloud-Infrastrukturen und Cloud-native Anwendungen bereitzustellen. Basierend auf eBPF realisiert DeepFlow die Zero-Intrusion (Zero Code)-Sammlung von Beobachtungssignalen wie Anwendungsleistungsindikatoren, verteilter Ablaufverfolgung und kontinuierlicher Leistungsanalyse und kombiniert sie mit der Smart-Label-Technologie (SmartEncoding), um die Full-Stack-Korrelation zu realisieren Integration aller Beobachtungssignale. Mithilfe von DeepFlow können Cloud-native Anwendungen automatisch über eine umfassende Beobachtbarkeit verfügen, wodurch die schwere Last der kontinuierlichen Instrumentierung für Entwickler entfällt und DevOps/SRE-Teams Überwachungs- und Diagnosefunktionen vom Code bis zur Infrastruktur erhalten.
GitHub-Adresse: https://github.com/deepflowio/deepflow
Besuchen Sie die DeepFlow-Demo und erleben Sie null Instrumentierung, vollständige Abdeckung und vollständig relevante Beobachtbarkeit.
Ich beschloss , auf Open-Source -Industriesoftware zu verzichten – OGG 1.0 wurde veröffentlicht, das Team von Ubuntu 24.04 LTS wurde offiziell entlassen ". Fedora Linux 40 wurde offiziell veröffentlicht. Ein bekanntes Spieleunternehmen veröffentlichte neue Vorschriften: Hochzeitsgeschenke von Mitarbeitern dürfen 100.000 Yuan nicht überschreiten. China Unicom veröffentlicht die weltweit erste chinesische Llama3 8B-Version des Open-Source-Modells. Pinduoduo wird zur Entschädigung verurteilt 5 Millionen Yuan für unlauteren Wettbewerb. Inländische Cloud-Eingabemethode – nur Huawei hat keine Sicherheitsprobleme beim Hochladen von Cloud-Daten