Query Insights verwenden, um die Abfrageleistung zu verbessern

Auf dieser Seite wird beschrieben, wie Sie mit dem Query Insights-Dashboard Leistungsprobleme erkennen und analysieren.

Einführung

Mit Query Insights können Sie Probleme bei der Abfrageleistung in Cloud SQL-Datenbanken ermitteln, diagnostizieren und verhindern. Es unterstützt ein intuitives Monitoring und liefert Diagnoseinformationen, die Ihnen helfen, über die Erkennung hinaus die Ursache von Leistungsproblemen zu identifizieren.

Mit Query Insights können Sie die Leistung auf Anwendungsebene überwachen und die Quelle einer problematischen Abfrage im gesamten Anwendungspaket nach Modell, Ansicht, Controller, Route, Nutzer und Host verfolgen. Das Query Insights-Tool lässt sich mit offenen Standards und APIs in Ihre vorhandenen Tools zur Anwendungsüberwachung (APM) und in Google Cloud-Dienste einbinden. So können Sie Abfrageprobleme mit Ihrem Lieblingstool überwachen und beheben.

Mit Query Insights können Sie die Leistung von Cloud SQL-Abfragen verbessern. Dabei werden Sie durch die folgenden Schritte geführt:

1. Datenbanklast für Top-Abfragen ansehen
2. Potenziell problematische Abfrage oder potenziell problematisches Tag identifizieren
3. Abfrage oder Tag ansehen, um Probleme zu ermitteln
4. Verfolgen Sie die Ursache des Problems.

Query Insights wird für alle Cloud SQL-Maschinentypen unterstützt und ist in allen Google Cloud-Regionen verfügbar.

Preise

Für Query Insights fallen keine zusätzlichen Kosten an. Im Query Insights-Dashboard haben Sie Zugriff auf die Daten einer Woche.

Query Insights belegt keinen Speicherplatz in Ihrem Cloud SQL-Instanzspeicher. Messwerte werden in Cloud Monitoring gespeichert. Informationen zu API-Anfragen finden Sie unter Cloud Monitoring-Preise. Cloud Monitoring bietet eine Stufe, die Sie ohne zusätzliche Kosten nutzen können.

Hinweis

Sie benötigen bestimmte IAM-Berechtigungen, um einen Abfrageplan aufzurufen oder End-to-End-Tracing durchzuführen. Erstellen Sie eine benutzerdefinierte Rolle und fügen Sie ihr die IAM-Berechtigung cloudtrace.traces.get hinzu. Fügen Sie diese Rolle dann jedem Nutzerkonto hinzu, das Query Insights verwenden muss.

Wenn Sie Abfragepläne und ihre End-to-End-Ansichten aufrufen möchten, muss in Ihrem Google Cloud-Projekt die Trace API aktiviert sein. Mit dieser Einstellung kann Ihr Google Cloud-Projekt ohne zusätzliche Kosten Trace-Daten von authentifizierten Quellen empfangen. Anhand dieser Daten können Sie Leistungsprobleme in Ihrer Instanz erkennen und diagnostizieren.

So prüfen Sie, ob die Trace API aktiviert ist:

1. Rufen Sie in der Google Cloud Console APIs und Dienste auf:

   Zu "APIs und Dienste"

2. Klicken Sie auf APIs und Dienste aktivieren.
3. Geben Sie in der Suchleiste Trace API ein.
4. Wenn API aktiviert angezeigt wird, ist diese API aktiviert und Sie müssen nichts tun. Klicken Sie andernfalls auf Aktivieren.

Abfragestatistiken aktivieren

Query Insights-Messwerte werden im inaktiven Zustand verschlüsselt. Nutzer mit Zugriff auf das Cloud SQL-Dashboard können im Query Insights-Dashboard auf Query Insights-Messwerte zugreifen. Wenn Sie berechtigt sind, Instanzen zu aktualisieren, können Sie Query Insights konfigurieren. Eine Liste der für Cloud SQL-Instanzen erforderlichen Berechtigungen finden Sie unter Cloud SQL-Projektzugriffssteuerung. Wenn Sie diese Berechtigungen nicht haben und Query Insights für Ihre Instanzen aktivieren möchten, wenden Sie sich an Ihren Administrator.

gcloud sql instances patch INSTANCE_ID \
--insights-config-query-insights-enabled
  

gcloud sql instances patch INSTANCE_ID \
--insights-config-query-insights-enabled \
--insights-config-query-string-length=INSIGHTS_CONFIG_QUERY_STRING_LENGTH \
--query_plans_per_minute=QUERY_PLANS_PER_MINUTE \
--insights-config-record-application-tags \
--insights-config-record-client-address \
--tier=API_TIER_STRING \
--region=REGION
  

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id

{
  "settings" : { "insightsConfig" : { "queryInsightsEnabled" : true } }
}

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id" | Select-Object -Expand Content

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2021-01-28T22:43:40.009Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

resource "google_sql_database_instance" "INSTANCE_NAME" {
 name                = "INSTANCE_NAME"
 database_version    = "POSTGRESQL_VERSION"
 region              = "REGION"
 root_password       = "PASSWORD"
 deletion_protection = false # set to true to prevent destruction of the resource
 settings {
   tier = "DB_TIER"
   insights_config {
     query_insights_enabled  = true
     query_string_length     = 2048 # Optional
     record_application_tags = true # Optional
     record_client_address   = true # Optional
     query_plans_per_minute  = 10 # Optional
   }
 }
}

Messwerte sollten innerhalb von Minuten nach Abschluss der Abfrage in Query Insights verfügbar sein. Sehen Sie sich die Datenaufbewahrungsrichtlinie für Cloud Monitoring an. Query Insights-Traces werden in Cloud Trace gespeichert. Sehen Sie sich die Cloud Trace-Datenaufbewahrungsrichtlinie an.

Query Insights-Dashboard ansehen

Im Query Insights-Dashboard wird die Abfragelast basierend auf von Ihnen ausgewählten Faktoren angezeigt. Die Abfragelast ist ein Maß für die Gesamtarbeit aller Abfragen in der Instanz im ausgewählten Zeitraum. Das Dashboard bietet eine Reihe von Filtern, mit denen Sie die Abfragelast anzeigen können.

So öffnen Sie das Query Insights-Dashboard:

1. Klicken Sie auf den Instanznamen, um die Übersichtsseite einer Instanz zu öffnen.
2. Wählen Sie entweder im linken Navigationsbereich den Tab Query Insights aus oder klicken Sie den Link Zu „Query Insights“ für ausführliche Informationen über Abfragen und zur Leistung.

Das Dashboard "Query Insights" wird geöffnet. Es werden die folgenden Informationen zu Ihrer Instanz angezeigt:

• Datenbanken: Filtert die Abfragelast für eine bestimmte Datenbank oder für alle Datenbanken.
• Nutzer: Filtert die Abfragelast aus einem bestimmten Nutzerkonto.
• Clientadresse: Filtert die Abfragelast von einer bestimmten IP-Adresse.
• Zeitraum: Filtert die Abfragelast nach Zeiträumen, z. B. Stunde, Tag, Woche, Monat oder einen benutzerdefinierten Bereich.
• Diagrammladedatenbank: Zeigt das Abfrageladediagramm basierend auf den gefilterten Daten an.
• CPU-Kapazität, CPU- und CPU-Wartezeit, E/A-Wartezeit und Wartezeit für Sperrungen: Die Filter werden basierend auf den von Ihnen ausgewählten Optionen geladen. Weitere Informationen zu jedem dieser Filter finden Sie unter Datenbanklast für Top-Abfragen ansehen.
• Abfragen und Tags: Filtert die Abfragelast entweder nach einer ausgewählten Abfrage oder einem ausgewählten SQL-Abfrage-Tag. Siehe Datenbanklast filtern.

Datenbanklast für alle Abfragen ansehen

Die Anzahl der Datenbankabfragen ist eine Messung der Arbeit (in CPU-Sekunden), die von den ausgeführten Abfragen in der ausgewählten Datenbank im Zeitverlauf ausgeführt wird. Bei jeder ausgeführten Abfrage wird entweder CPU-Ressourcen, E/A-Ressourcen oder Sperren von CPU-Ressourcen verwendet oder darauf gewartet. Die Datenbankabfragelast ist das Verhältnis der Zeit, die von allen innerhalb eines bestimmten Zeitfensters abgeschlossenen Abfragen benötigt wird, zur tatsächlich verstrichenen Zeit.

Das Dashboard "Query Insights" der obersten Ebene zeigt das Diagramm Datenbanklast – alle Top-Abfragen. Mit Drop-down-Menüs im Dashboard können Sie das Diagramm für eine bestimmte Datenbank, einen bestimmten Nutzer oder eine bestimmte Kundenadresse filtern.

Die farbigen Linien in der Grafik zeigen die Abfragelast, in vier Kategorien unterteilt:

• CPU-Kapazität: Die Anzahl der CPUs, die auf der Instanz verfügbar sind.

• CPU und CPU-Wartezeit: Verhältnis der Zeit, die Abfragen in einem aktiven Zustand benötigen, zur tatsächlich verstrichenen Zeit. IO- und Sperrwartet blockieren keine Abfragen, die aktiv sind. Dieser Messwert kann bedeuten, dass die Abfrage entweder die CPU verwendet oder wartet, bis der Linux-Planer den Serverprozess plant, der die Abfrage ausführt, während andere Prozesse die CPU verwenden.

• E/A-Wartezeit: Das Verhältnis der Zeit, die Abfragen auf E/A warten, zur tatsächlich verstrichenen Zeit. IO Wait beinhaltet Read IO Wait und Write IO Wait.

  Weitere Informationen finden Sie in der PostgreSQL-Ereignistabelle.

  Eine Gliederung der Informationen zu IO Waits nach Sperrung können Sie in Cloud Monitoring anzeigen. Weitere Informationen finden Sie unter Cloud SQL-Messwerte.

• Lock Wait: Das Verhältnis der Zeit, die Abfragen auf Sperren warten, zur tatsächlich verstrichenen Zeit. Dies beinhaltet Wartezeiten nach Sperrung, LwLock-Wartezeiten und BufferPin-Wartezeiten nach Sperrung. Verwenden Sie Cloud Monitoring, um eine Aufschlüsselung der Informationen für Sperrungswartezeiten anzuzeigen. Weitere Informationen finden Sie unter Cloud SQL-Messwerte.

Sehen Sie sich die Grafik an und verwenden Sie die Filteroptionen, um diese Fragen zu untersuchen:

1. Ist die Abfragelast hoch? Ist eine Spitze oder ein Anstieg im Zeitverlauf zu sehen? Wenn keine hohe Last angezeigt wird, liegt das Problem nicht bei Ihrer Abfrage.
2. Wie lange war die Last hoch? Ist sie erst jetzt hoch oder war sie schon lange hoch? Verwenden Sie die Bereichsauswahl, um verschiedene Zeiträume auszuwählen, um herauszufinden, wie lange das Problem besteht. Vergrößern Sie die Ansicht, um ein Zeitfenster zu sehen, in dem Spitzen bei der Abfragelast beobachtet werden. Zoomen Sie heraus, um bis zu einer Woche der Zeitachse anzuzeigen.
3. Wodurch wird die hohe Last verursacht? Sie können zur Auswahl der CPU-Kapazität, der CPU- und CPU-Wartezeit, der Wartezeit der Sperrung oder der E/A-Wartezeit wählen. Das Diagramm für jede dieser Optionen hat eine andere Farbe, sodass Sie leicht die Farbe mit der höchsten Last erkennen können. Die dunkelblaue Linie im Diagramm zeigt die maximale CPU-Kapazität des Systems an. Sie können die Abfragelast mit der maximalen CPU-Systemkapazität vergleichen. Anhand dieses Vergleichs können Sie erkennen, ob die CPU-Ressourcen einer Instanz erschöpft sind.
4. Welche Datenbank hat die Auslastung? Wählen Sie im Drop-down-Menü "Datenbanken" verschiedene Datenbanken aus, um die Datenbanken mit den höchsten Lasten zu finden.
5. Verursachen bestimmte Nutzer oder IP-Adressen eine höhere Last? Wählen Sie in den Drop-down-Menüs verschiedene Nutzer und Adressen aus, um zu identifizieren, welche die höchste Last verursachen.

Datenbanklast filtern

Sie können die Datenbanklast nach Abfragen oder Tags filtern.

Nach Abfragen filtern

Die Tabelle Abfragen bietet einen Überblick über die Abfragen, die die meisten Abfragelasten verursachen. Die Tabelle enthält alle normalisierten Abfragen für das Zeitfenster und die Optionen, die im Query Insights-Dashboard ausgewählt wurden. Es sortiert Abfragen nach der gesamten Ausführungszeit während des ausgewählten Zeitfensters.

Wählen Sie zum Sortieren der Tabelle eine Spaltenüberschrift oder ein Attribut aus Abfragen filtern aus. Die Tabelle enthält die folgenden Attribute:

• Abfrage: Der normalisierte Abfragestring. Query Insights zeigt standardmäßig nur 1.024 Zeichen im Abfragestring an.

  Abfragen mit dem Label UTILITY COMMAND enthalten in der Regel die Befehle BEGIN, COMMIT und EXPLAIN oder Wrapper-Befehle.

• Datenbank: Die Datenbank, für die die Abfrage ausgeführt wurde.

• Last nach Gesamtzeit/Last nach CPU/Last nach E/A-Wartezeit/Last nach Wartezeit der Sperrung: Die Optionen, mit denen Sie bestimmte Abfragen filtern können, um die größte Last zu ermitteln.

• Durchschnittliche Ausführungszeit (ms): Die durchschnittliche Zeit für die Ausführung der Abfrage.

• Aufrufe: Gibt an, wie oft die Anwendung die Abfrage aufgerufen hat.

• Durchschnittliche zurückgegebene Zeilen: Die durchschnittliche Anzahl der Zeilen, die für die Abfrage zurückgegeben wurden.

In Query Insights werden nur normalisierte Abfragen gespeichert und angezeigt. Standardmäßig erfasst Query Insights keine IP-Adressen oder Tag-Informationen. Sie können Query Insights aktivieren, um diese Informationen zu erfassen, und bei Bedarf die Erfassung deaktivieren. Traces des Abfrageplans erfassen oder speichern keine konstanten Werte und entfernen keine personenidentifizierbaren Informationen, die die Konstante anzeigen kann.

Für PostgreSQL 9.6 und 10 zeigt Query Insights normalisierte Abfragen an, also ? ersetzt den Wert der Literalkonstante. Im folgenden Beispiel wird die Namenskonstante entfernt und durch ? ersetzt.

UPDATE
  "demo_customer"
SET
  "customer_id" = ?::uuid,
  "name" = ?,
  "address" = ?,
  "rating" = ?,
  "balance" = ?,
  "current_city" = ?,
  "current_location" = ?
WHERE
  "demo_customer"."id" = ?

Für PostgreSQL Version 11 und höher ersetzen $1, $2, usw. literalkonstante Werte.

UPDATE
  "demo_customer"
SET
  "customer_id" = $1::uuid,
  "name" = $2,
  "address" = $3,
  "rating" = $4,
  "balance" = $5,
  "current_city" = $6,
  "current_location" = $7
WHERE
  "demo_customer"."id" = $8

Nach Abfrage-Tags filtern

Zur Behebung von Fehlern in Anwendungen müssen Sie zuerst Tags zu SQL-Abfragen hinzufügen. Abfragelasttags ermöglichen eine Aufschlüsselung der Abfragelast des ausgewählten Tags im Zeitverlauf.

Query Insights bietet anwendungsorientiertes Monitoring zur Diagnose von Leistungsproblemen für Anwendungen, die mit ORMs erstellt wurden. Wenn Sie für das gesamte Anwendungspaket verantwortlich sind, können Sie mit Query Insights Abfragen in einer Anwendungsansicht verfolgen. Mit der Tag-Kennzeichnung von Abfragen können Sie Probleme auf übergeordneten Konstrukten finden, z. B. mit der Geschäftslogik oder einem Mikrodienst.

Sie können Abfragen nach der Geschäftslogik taggen, z. B. mithilfe der Tags für Zahlungen, Inventar, Geschäftsanalysen oder Versand. Anschließend können Sie die Abfragelast ermitteln, die die verschiedenen Geschäftslogik erstellt haben. Dabei kann es sich beispielsweise um unerwartete Ereignisse wie Spitzen bei den Geschäftsanalyse-Tags um 13:00 Uhr oder abnormales Wachstum bei einem Trend zur Zahlungsbearbeitung in der letzten Woche handeln.

Zur Berechnung der Datenbanklast für Tag verwendet Query Insights die Zeit, die jede Abfrage mit dem von Ihnen ausgewählten Tag benötigt. Das Tool berechnet die Abschlusszeit an der Minutengrenze anhand der tatsächlich verstrichenen Zeit.

Wählen Sie im Dashboard "Query Insights" die Option Tags aus, um die Tag-Tabelle anzuzeigen. Die Tabelle sortiert Tags nach der Gesamtlast nach der Gesamtzeit.

Sie können die Tabelle sortieren. Wählen Sie dazu unter Tags filtern ein Attribut aus oder klicken Sie auf eine Spaltenüberschrift. Die Tabelle enthält die folgenden Attribute:

• Action, Controller, Framework, Route, Application, DB Driver: Jedes Attribut, das Sie Ihren Abfragen hinzugefügt haben, wird als Spalte angezeigt. Sie müssen mindestens eine dieser Eigenschaften hinzufügen, wenn Sie nach Tags filtern möchten.
• Last nach Gesamtzeit/Last nach CPU/Last nach E/A-Wartezeit/Last nach Wartezeit der Sperrung: Optionen zum Filtern bestimmter Abfragen, um die größte Last für jede Option zu finden.
• Durchschnittliche Ausführungszeit (ms): Die durchschnittliche Zeit für die Ausführung der Abfrage.
• Durchschnittliche zurückgegebene Zeilen: Die durchschnittliche Anzahl der Zeilen, die für die Abfrage zurückgegeben wurden.
• Aufrufe: Gibt an, wie oft die Anwendung die Abfrage aufgerufen hat.
• Datenbank: Die Datenbank, für die die Abfrage ausgeführt wurde.

Bestimmte Abfrage oder bestimmtes Tag prüfen

Führen Sie auf dem Tab Abfragen oder Tags Folgendes aus, um festzustellen, ob eine Abfrage oder ein Tag die Ursache für das Problem ist:

1. Wenn Sie die Liste in absteigender Reihenfolge sortieren möchten, klicken Sie auf den Header Last nach Gesamtzeit.
2. Klicken Sie auf die Abfrage oder den Tag am Anfang der Liste. Sie hat die höchste Last und benötigt mehr Zeit als die anderen.

Es wird ein Dashboard mit den Details der ausgewählten Abfrage bzw. des ausgewählten Tags geöffnet.

Bestimmte Abfragelast prüfen

Das Dashboard für ein ausgewähltes Abfrage wird wie unten dargestellt angezeigt:

Das Diagramm Datenbanklast – bestimmte Abfrage zeigt eine Messung der Arbeit (in CPU-Sekunden) an, die Ihre normalisierte Abfrage im Zeitverlauf in der ausgewählten Abfrage ausgeführt hat. Zur Berechnung der Last wird die von normalisierten Abfragen benötigte Zeit zur tatsächlich verstrichenen Zeit verwenden. Am Anfang der Tabelle werden die ersten 1.024 Zeichen der normalisierten Abfrage angezeigt. Literale werden dabei wegen Aggregation und personenidentifizierbaren Informationen entfernt.

Wie beim Diagramm zur Gesamtzeit der Abfragen können Sie die Last für eine bestimmte Abfrage nach Datenbank, Nutzer und Clientadresse filtern. Die Abfragelast wird in CPU-Kapazität, CPU und CPU-Wartezeit, E/A-Wartezeit und Wartezeit nach Sperrung aufgeteilt.

Bestimmte getaggte Abfragelast prüfen

Das Dashboard für ein ausgewähltes Tag wird wie unten dargestellt angezeigt. Beispiel: Wenn alle Abfragen aus einer Zahlung für Mikrodienste mit dem Tag payment gekennzeichnet sind, können Sie mit dem Tag payment den Umfang der Abfragelast anzeigen lassen, die im Trend liegt.

Das Diagramm Datenbanklast – bestimmte Tags zeigt eine Messung der Arbeit (in CPU-Sekunden) an, die Abfragen, die mit Ihren ausgewählten Tags übereinstimmen, in der ausgewählten Datenbank im Laufe der Zeit ausgeführt haben. Wie beim Diagramm zur Gesamtzeit der Abfragen können Sie die Last für eine bestimmte Abfrage nach Datenbank, Nutzer und Clientadresse filtern.

Vorgänge in einem Beispielabfrageplan prüfen

Mit einem Abfrageplan wird eine Stichprobe Ihrer Abfrage erstellt und in einzelne Vorgänge unterteilt. Die einzelnen Vorgänge in der Abfrage werden erläutert.

Das Diagramm Abfrageplanbeispiele zeigt alle Abfragepläne, die zu bestimmten Zeiten ausgeführt werden, sowie die Zeit, die jeder Plan benötigt hat. Sie können die Rate ändern, mit der die Stichproben von Abfrageplänen pro Minute erfasst werden. Siehe Abfragestatistiken aktivieren.

Standardmäßig zeigt das Feld rechts die Details für den Beispiel-Abfrageplan an, der die längste Zeit in Anspruch nimmt, wie im Diagramm Abfrageplan-Beispiele angezeigt. Klicken Sie auf den entsprechenden Kreis im Diagramm, um die Details für einen anderen Beispielabfrageplan anzuzeigen. Erweiterte Details zeigen ein Modell aller Vorgänge im Abfrageplan. Jeder Vorgang zeigt die Latenz, die zurückgegebenen Zeilen und die Kosten für diesen Vorgang an. Wenn Sie einen Vorgang auswählen, werden weitere Details wie freigegebene Trefferblöcke, Schematyp, Schleifen und Planzeilen angezeigt.

Versuchen Sie, das Problem anhand der folgenden Fragen einzugrenzen:

1. Wie hoch ist der Ressourcenverbrauch?
2. Wie hängt er mit anderen Abfragen zusammen?
3. Ändert sich der Verbrauch im Laufe der Zeit?

Latenz prüfen

Latenz ist die tatsächlich verstrichene Zeit, die für den Abschluss der normalisierten Abfrage benötigt wird. Mit dem Diagramm Latenz können Sie die Latenz der Abfrage oder des Tags untersuchen. Im Latenz-Dashboard werden die Latenzen für das 50., 95. und 99. Perzentil angezeigt, um Ausreißerverhalten zu ermitteln.

Das folgende Bild zeigt das Diagramm für die Datenbanklast im 50. Perzentil für eine bestimmte Abfrage mit ausgewählten Filtern für CPU-Kapazität, CPU und CPU-Wartezeit sowie E/A-Wartezeit und Wartezeit nach Sperrung an.

Die Latenz der parallelen Abfragen wird in der tatsächlich verstrichenen Zeit gemessen, obwohl die Abfragelast für die Abfrage höher sein kann, da mehrere Kerne zum Ausführen bestimmter Teile der Abfrage verwendet werden.

Versuchen Sie, das Problem anhand der folgenden Fragen einzugrenzen:

1. Wodurch wird die hohe Last verursacht? Wählen Sie Optionen aus, um die CPU-Kapazität, die CPU und CPU-Wartezeit sowie die E/A-Wartezeit und Wartezeit nach Sperrung zu sehen.
2. Wie lange war die Last hoch? Ist sie nur jetzt hoch? Oder ist sie schon lange hoch? Ändern Sie den Zeitraum, um das Datum und die Uhrzeit zu ermitteln, zu der sich die Leistung der Last verschlechterte.
3. Gibt es Latenzspitzen? Ändern Sie das Zeitfenster, um die bisherige Latenz für die normalisierte Abfrage zu untersuchen.

Verfolgen Sie die Ursache des Problems.

Wenn Sie die Bereiche und Zeiten finden, in denen die Last am höchsten war, identifizieren Sie die Ursache des Problems mithilfe von Tracing.

Damit Sie die Ursache des Problems (z. B. ein Modell, eine Ansicht, einen Controller, eine Route, einen Host oder einen Nutzer) ermitteln können, bietet Query Insights eine kontextbezogene End-to-End-Ansicht zur Anwendungsverfolgung. Diese Ansicht bietet Informationen zu den Vorgängen auf Datenbankebene für eine bestimmte Anfrage und zum Ermitteln der Ursache einer problematischen Abfrage nach Modell, Ansicht, Controller und Route.

Wenn Sie OpenCensus oder OpenTelemetry aktivieren, werden Informationen zu OpenCensus-Span sowie die Taginformationen innerhalb von SQL-Kommentaren an die Datenbank gesendet. Alle Traces von der Anwendung zu Cloud Logging sind mit Datenbankabfrageplan-Traces verknüpft, um dabei zu helfen, die Ursache des Problems zu ermitteln.

Klicken Sie im Bildschirm für die Beispielabfrage auf den Tab Ende zu Ende, um den Kontexttrace anzuzeigen.

Ermitteln Sie anhand der Tabellen Top-Clientadressen und der Top-Nutzer die höchsten Lasten, um herauszufinden, welcher Client und welcher Nutzer das Problem verursachen. Sie können dem Filter einen Nutzer oder eine IP-Adresse hinzufügen, um einen bestimmten Nutzer oder eine bestimmte Nutzer- oder Clientadresse genauer zu analysieren. Zu den Informationen in den Tabellen gehören der Prozentsatz der Abfragelast, die durchschnittliche Ausführungszeit in Millisekunden und die Anzahl der Aufrufe.

Sie können Cloud Trace verwenden, um das End-to-End-Tracing für jeden Schritt im Abfrageplan zu sehen. Klicken Sie im Dashboard "Query Insights" auf die Schaltfläche In Trace ansehen, um das Cloud Trace-Tool zu öffnen. Im Trace-Diagramm werden alle Traces angezeigt, die für den ausgewählten Zeitraum ausgeführt wurden.

Informationen finden Sie unter Traces suchen und ansehen.

Tags zu SQL-Abfragen hinzufügen

Das Taggen von SQL-Abfragen vereinfacht die Fehlerbehebung in Anwendungen. Sie können sqlcommenter verwenden, um Ihren SQL-Abfragen Tags entweder automatisch oder manuell hinzuzufügen.

sqlcommenter mit ORM verwenden

Wenn Sie ORM verwenden, anstatt SQL-Abfragen direkt zu schreiben, finden Sie möglicherweise keinen Anwendungscode, der Leistungsprobleme verursacht. Unter Umständen können Sie auch nicht analysieren, wie sich Ihr Anwendungscode auf die Abfrageleistung auswirkt. Query Insights bietet eine Open-Source-Bibliothek namens sqlcommenter, um dieses Problem zu beheben. Diese Bibliothek ist für Entwickler und Administratoren nützlich, die ORM-Tools verwenden, um zu erkennen, welcher Anwendungscode Leistungsprobleme verursacht.

Wenn Sie ORM und sqlcommenter zusammen verwenden, werden die Tags automatisch erstellt. Sie müssen in der Anwendung weder Code hinzufügen noch ändern.

Sie können sqlcommenter auf dem Anwendungsserver installieren. Die Instrumentierungsbibliothek ermöglicht die Weitergabe von Anwendungsinformationen in Verbindung mit Ihrem Modell, Ihrer Ansicht und Ihrem MVC-Framework zusammen mit den Abfragen als SQL-Kommentar. Die Datenbank ruft diese Tags ab und beginnt die Aufzeichnung und Aggregation von Statistiken nach Tags. Dies sind orthogonale Statistiken mit normalisierten Abfragen. Query Insights zeigt die Tags an, damit Sie wissen, welche Anwendung die Abfragelast verursacht, und den Anwendungscode finden können, der die Leistungsprobleme verursacht.

Ergebnisse in SQL-Datenbanklogs werden so angezeigt:

SELECT * from USERS /*action='run+this',
controller='foo%3',
traceparent='00-01',
tracestate='rojo%2'*/

Zu den unterstützten Tags gehören der Controllername, die Route, das Framework und die Aktion.

Die Gruppe von ORM-Tools in sqlcommenter wird für die folgenden Programmiersprachen unterstützt:

Weitere Informationen über sqlcommenter und wie Sie es in Ihrem ORM-Framework verwenden, finden Sie in der sqlcommenter-Dokumentation.

Tags mit sqlcommenter hinzufügen

Wenn Sie ORM nicht verwenden, müssen Sie sqlcommenter-Tags oder Kommentare manuell im richtigen SQL-Kommentarformat zu Ihrer SQL-Abfrage hinzufügen. Außerdem müssen Sie jede SQL-Anweisung mit einem Kommentar erweitern, der ein serialisiertes Schlüssel/Wert-Paar enthält. Verwenden Sie mindestens einen der folgenden Schlüssel:

• action=''
• controller=''
• framework=''
• route=''
• application=''
• db driver=''

Query Insights löst alle anderen Schlüssel ab.

Query Insights deaktivieren

gcloud sql instances patch INSTANCE_ID \
--no-insights-config-query-insights-enabled
  

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id

{
  "settings" : { "insightsConfig" : { "queryInsightsEnabled" : false } }
}

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id" | Select-Object -Expand Content

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2021-01-28T22:43:40.009Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

Nächste Schritte

• Blog zur Einführung: Datenbank-Sichtbarkeit für Entwickler: Einführung von Cloud SQL Insights

• Siehe Cloud SQL-Messwerte. Die Messwerttyp-Strings von Query Insights beginnen mit database/postgresql/insights.

• Blog: Mit Cloud SQL Insights die Fähigkeiten zur Fehlerbehebung bei Abfragen verbessern
• Video: Einführung in Cloud SQL Insights
• Podcast: Cloud SQL Insights
• Informationen zu Codelabs
• Blog: Einführung von Sqlcommenter: Eine Open-Source-Bibliothek mit ORM-Instrumentierung
• Blog: Abfrage-Tagging mit Sqlcommenter aktivieren