Sitzungen

Auf dieser Seite wird das erweiterte Konzept von Sitzungen in Spanner beschrieben, einschließlich Best Practices für Sitzungen beim Erstellen einer Clientbibliothek, mit der REST API oder RPC API oder mit den Google-Clientbibliotheken.

Sitzungen – Übersicht

Eine Sitzung stellt einen Kommunikationskanal mit dem Spanner-Datenbankdienst dar. Eine Sitzung wird verwendet, um Transaktionen auszuführen, die Daten in einer Spanner-Datenbank lesen, schreiben oder ändern. Jede Sitzung gilt für eine einzige Datenbank.

Sitzungen können eine oder mehrere Transaktionen gleichzeitig ausführen. Beim Ausführen mehrerer Transaktionen wird die Sitzung als Multiplex-Sitzung bezeichnet.

Eigenständige Lese-, Schreib- und Abfragevorgänge verwenden intern eine Transaktion.

Leistungsvorteile eines Sitzungspools

Das Erstellen einer Sitzung ist teuer. Um Leistungskosten bei jedem Datenbankvorgang zu vermeiden, sollten Kunden einen Sitzungspool behalten. Das ist ein Pool verfügbarer Sitzungen, die einsatzbereit sind. Der Pool sollte vorhandene Sitzungen speichern und auf Anfrage den entsprechenden Sitzungstyp zurückgeben sowie nicht verwendete Sitzungen bereinigen. Ein Beispiel für die Implementierung eines Sitzungspools finden Sie im Quellcode für eine der Spanner-Clientbibliotheken, z. B. die Go-Clientbibliothek oder die Java-Clientbibliothek.

Sitzungen sind langlebig angelegt. Nachdem eine Sitzung für einen Datenbankvorgang verwendet wurde, sollte der Client die Sitzung also zur Wiederverwendung an den Pool zurückgeben.

Übersicht über gRPC-Kanäle

gRPC-Kanäle werden vom Spanner-Client für die Kommunikation verwendet. Ein gRPC-Kanal entspricht in etwa einer TCP-Verbindung. Ein gRPC-Kanal kann bis zu 100 gleichzeitige Anfragen verarbeiten. Das bedeutet, dass eine Anwendung mindestens so viele gRPC-Kanäle benötigt wie die Anzahl der gleichzeitig ausgeführten Anfragen, geteilt durch 100.

Der Spanner-Client erstellt einen Pool von gRPC-Kanälen, wenn Sie ihn erstellen.

Best Practices für die Verwendung von Google-Clientbibliotheken

Im Folgenden werden Best Practices bei der Verwendung der Google-Clientbibliotheken für Spanner beschrieben.

Anzahl der Sitzungen und gRPC-Kanäle in den Pools konfigurieren

Die Clientbibliotheken haben eine Standardanzahl von Sitzungen im Sitzungspool und eine Standardanzahl von gRPC-Kanälen im Kanalpool. Beide Standardeinstellungen sind in den meisten Fällen ausreichend. Im Folgenden finden Sie die standardmäßige minimale und maximale Anzahl von Sitzungen sowie die Standardanzahl von gRPC-Kanälen für jede Programmiersprache.

C++

MinSessions: 100
MaxSessions: 400
NumChannels: 4

C#

MinSessions: 100
MaxSessions: 400
NumChannels: 4

Go

MinSessions: 100
MaxSessions: 400
NumChannels: 4

Java

MinSessions: 100
MaxSessions: 400
NumChannels: 4

Node.js

Der Node.js-Client unterstützt nicht mehrere gRPC-Kanäle. Daher wird empfohlen, mehrere Clients zu erstellen, anstatt den Sitzungspool auf mehr als 100 Sitzungen für einen einzelnen Client zu erhöhen.

MinSessions: 25
MaxSessions: 100

PHP

Der PHP-Client unterstützt keine konfigurierbare Anzahl von gRPC-Kanälen.

MinSessions: 1
MaxSessions: 500

Python

Python unterstützt vier verschiedene Sitzungspooltypen, mit denen Sie Sitzungen verwalten können.

Ruby

Der Ruby-Client unterstützt nicht mehrere gRPC-Kanäle. Daher wird empfohlen, mehrere Clients zu erstellen, anstatt den Sitzungspool auf mehr als 100 Sitzungen für einen einzelnen Client zu erhöhen.

MinSessions: 10
MaxSessions: 100

Die Anzahl der Sitzungen, die Ihre Anwendung verwendet, entspricht der Anzahl der gleichzeitig von Ihrer Anwendung ausgeführten Transaktionen. Sie sollten die Einstellungen des Standardsitzungspools nur dann ändern, wenn Sie erwarten, dass eine einzelne Anwendungsinstanz mehr gleichzeitige Transaktionen ausführt, als der Standardsitzungspool verarbeiten kann.

Für Anwendungen mit hoher Nebenläufigkeit wird Folgendes empfohlen:

1. Legen Sie für MinSessions die erwartete Anzahl gleichzeitiger Transaktionen fest, die ein einzelner Client ausführen wird.
2. Legen Sie für MaxSessions die maximale Anzahl gleichzeitiger Transaktionen fest, die ein einzelner Client ausführen kann.
3. Legen Sie MinSessions=MaxSessions fest, wenn sich die erwartete Nebenläufigkeit während der Anwendungslebensdauer nicht stark ändert. Dies verhindert, dass der Sitzungspool hoch- oder herunterskaliert wird. Das Hoch- oder Herunterskalieren des Sitzungspools verbraucht auch einige Ressourcen.
4. Setzen Sie NumChannels auf MaxSessions / 100. Ein gRPC-Kanal kann bis zu 100 Anfragen gleichzeitig verarbeiten. Erhöhen Sie diesen Wert, wenn Sie eine hohe Extremwertlatenz (P95/P99-Latenz) feststellen, da dies ein Hinweis auf eine Überlastung des gRPC-Kanals sein könnte.

Wenn Sie die Anzahl der aktiven Sitzungen erhöhen, werden zusätzliche Ressourcen im Spanner-Datenbankdienst und in der Clientbibliothek verwendet. Wenn Sie die Anzahl der Sitzungen über den tatsächlichen Bedarf der Anwendung hinaus erhöhen, kann dies die Leistung Ihres Systems beeinträchtigen.

Sitzungspool erhöhen statt Anzahl der Clients erhöhen

Die Größe des Sitzungspools für eine Anwendung bestimmt, wie viele gleichzeitige Transaktionen eine einzelne Anwendungsinstanz ausführen kann. Es wird nicht empfohlen, die Größe des Sitzungspools über die maximale Nebenläufigkeit hinaus zu erhöhen, die eine einzelne Anwendungsinstanz verarbeiten kann. Wenn die Anwendung eine Burst von Anfragen empfängt, die über die Anzahl der Sitzungen im Pool hinausgeht, werden die Anfragen in die Warteschlange gestellt, während auf eine Sitzung gewartet wird.

Folgende Ressourcen werden von der Clientbibliothek verbraucht:

1. Jeder gRPC-Kanal verwendet eine TCP-Verbindung.
2. Für jeden gRPC-Aufruf ist ein Thread erforderlich. Die maximale Anzahl der Threads, die von der Clientbibliothek verwendet werden, entspricht der maximalen Anzahl gleichzeitiger Abfragen, die die Anwendung ausführt. Diese Threads überlagern allen Threads, die die Anwendung für ihre eigene Geschäftslogik verwendet.

Es wird nicht empfohlen, den Sitzungspool über die maximale Anzahl von Threads hinaus zu erhöhen, die eine einzelne Anwendungsinstanz verarbeiten kann. Erhöhen Sie stattdessen die Anzahl der Anwendungsinstanzen.

Anteil der Schreibsitzungen verwalten

Bei einigen Clientbibliotheken reserviert Spanner einen Teil der Sitzungen für Lese-Schreib-Transaktionen. Dies wird als Anteil der Schreibsitzungen bezeichnet. Wenn Ihre Anwendung alle Lesesitzungen verbraucht hat, verwendet Spanner die nicht schreibgeschützten Sitzungen auch für schreibgeschützte Transaktionen. Für Lese-/Schreibvorgänge ist spanner.databases.beginOrRollbackReadWriteTransaction erforderlich. Wenn der Nutzer die IAM-Rolle spanner.databaseReader hat, schlägt der Aufruf fehl und Spanner gibt die folgende Fehlermeldung zurück:

generic::permission_denied: Resource %resource% is missing IAM permission:
spanner.databases.beginOrRollbackReadWriteTransaction

Bei Clientbibliotheken, die einen Anteil an Schreibsitzungen haben, können Sie diesen festlegen.

C++

Alle C ++-Sitzungen sind identisch. Es gibt weder schreibgeschützte noch nicht schreibgeschützte Sitzungen.

C#

Der standardmäßige Anteil an Schreibsitzungen bei C# beträgt 0,2. Sie können ihn im Feld „WriteSessionsFraction“ von SessionPoolOptions ändern.

Einfach loslegen (Go)

Alle Go-Sitzungen sind gleich. Es gibt weder schreibgeschützte noch nicht schreibgeschützte Sitzungen.

Java

Alle Java-Sitzungen sind gleich. Es gibt weder schreibgeschützte noch nicht schreibgeschützte Sitzungen.

Node.js

Alle Node.js-Sitzungen sind gleich. Es gibt weder schreibgeschützte noch nicht schreibgeschützte Sitzungen.

PHP

Alle PHP-Sitzungen sind gleich. Es gibt keine schreibgeschützten bzw. nicht schreibgeschützten Sitzungen.

Python

Python unterstützt vier verschiedene Sitzungspooltypen, die Sie zum Verwalten von schreibgeschützten und nicht schreibgeschützten Sitzungen verwenden können.

Ruby

Der Standardanteil der Schreibsitzungen bei Ruby ist 0,3. Sie können ihn mit der client initialize-Methode ändern.

Best Practices beim Erstellen einer Clientbibliothek oder bei Verwendung von REST/RPC

Im Folgenden werden Best Practices für die Implementierung von Sitzungen in einer Clientbibliothek für Spanner oder für die Verwendung von Sitzungen mit der REST API oder der RPC API beschrieben.

Diese Best Practices gelten nur, wenn Sie eine Clientbibliothek entwickeln oder wenn Sie REST/RPC-APIs verwenden. Wenn Sie eine der Google-Clientbibliotheken für Spanner verwenden, lesen Sie die Best Practices bei der Verwendung von Google-Clientbibliotheken.

Sitzungspool erstellen und Größe anpassen

Um eine optimale Größe des Sitzungspools für einen Clientprozess zu bestimmen, legen Sie die untere Grenze auf die Anzahl der erwarteten gleichzeitigen Transaktionen und die Obergrenze auf eine anfängliche Testanzahl wie 100 fest. Wenn die obere Grenze nicht ausreicht, setzen Sie sie herauf. Wenn Sie die Anzahl der aktiven Sitzungen erhöhen, werden zusätzliche Ressourcen für den Spanner-Datenbankdienst verwendet. Wenn also nicht verwendete Sitzungen nicht bereinigt werden, kann dies die Leistung beeinträchtigen. Für Nutzer, die mit der RPC API arbeiten, empfehlen wir, nicht mehr als 100 Sitzungen pro gRPC-Kanal zu haben.

Gelöschte Sitzungen

Es gibt drei Möglichkeiten, eine Sitzung zu löschen:

• Ein Client kann eine Sitzung löschen.
• Der Spanner-Datenbankdienst kann eine Sitzung löschen, wenn sie länger als eine Stunde inaktiv ist.
• Der Spanner-Datenbankdienst kann eine Sitzung löschen, wenn sie älter als 28 Tage ist.

Beim Versuch, eine gelöschte Sitzung zu verwenden, wird NOT_FOUND zurückgegeben. Wenn dieser Fehler auftritt, erstellen und verwenden Sie eine neue Sitzung, fügen Sie die neue Sitzung dem Pool hinzu und entfernen Sie die gelöschte Sitzung aus dem Pool.

Inaktive Sitzung offen halten

Der Spanner-Datenbankdienst behält sich das Recht vor, eine nicht verwendete Sitzung zu löschen. Wenn Sie eine inaktive Sitzung unbedingt offen halten müssen, wenn z. B. eine signifikante Erhöhung der Datenbanknutzung in naher Zukunft erwartet wird, können Sie verhindern, dass die Sitzung gelöscht wird. Führen Sie einen kostengünstigen Vorgang wie das Ausführen der SQL-Abfrage SELECT 1 durch, um die Sitzung aktiv zu halten. Wenn Sie eine inaktive Sitzung haben, die nicht in naher Zukunft verwendet werden soll, lassen Sie sie von Spanner löschen. Erstellen Sie dann eine neue Sitzung, wenn das nächste Mal eine Sitzung benötigt wird.

Ein Szenario, in dem Sitzungen offen gehalten werden, ist der Umgang mit regulärer Spitzennachfrage der Datenbank. Wenn eine starke Datenbanknutzung täglich von 9:00 Uhr bis 18:00 Uhr stattfindet, sollten Sie während dieser Zeit einige inaktive Sitzungen offen halten, da diese wahrscheinlich zu Spitzenzeiten erforderlich sind. Nach 18:00 Uhr kann Spanner inaktive Sitzungen wieder löschen. Erstellen Sie jeden Tag vor 9:00 Uhr einige neue Sitzungen, damit sie für die erwartete Nachfrage bereitstehen.

Ein anderes Szenario wäre, wenn Sie eine Anwendung haben, die Spanner verwendet, aber den Verbindungsaufwand dabei vermeiden muss. Sie können eine Gruppe von Sitzungen offen halten, um den Verbindungsaufwand zu vermeiden.

Sitzungsdetails vom Clientbibliotheksbenutzer ausblenden

Wenn Sie eine Clientbibliothek erstellen, sollten Sie dem Nutzer der Clientbibliothek keine Sitzungen bereitstellen. Stellen Sie die Möglichkeit für den Client bereit, Datenbankaufrufe ohne den Aufwand der Erstellung und Verwaltung von Sitzungen durchzuführen. Ein Beispiel für eine Clientbibliothek, bei der die Sitzungsdetails für den Nutzer der Clientbibliothek ausgeblendet werden, finden Sie in der Spanner-Clientbibliothek für Java.

Fehler bei Schreibtransaktionen bearbeiten, die nicht idempotent sind

Schreibtransaktionen ohne Wiederholungsschutz können Mutationen mehr als einmal anwenden. Wenn eine Mutation nicht idempotent ist, kann eine Mutation, die mehrmals angewendet wird, zu einem Fehler führen. Beispiel: Eine Einfügung (Insert) kann den Fehler ALREADY_EXISTS verursachen, obwohl die Zeile vor dem Schreibversuch nicht vorhanden war. Dies kann passieren, wenn der Back-End-Server die Mutation festgeschrieben hat, den Erfolg jedoch nicht dem Client mitteilen konnte. In diesem Fall könnte die Mutation wiederholt werden, was aber zu dem Fehler ALREADY_EXISTS führen würde.

Im Folgenden sind einige Möglichkeiten aufgelistet, wie Sie mit diesem Szenario bei der Bereitstellung Ihrer eigenen Clientbibliothek oder bei der Verwendung der REST API verfahren können:

• Strukturieren Sie Ihre Schreibvorgänge so, dass sie idempotent sind.
• Verwenden Sie Schreibvorgänge mit Wiederholungsschutz.
• Implementieren Sie eine Methode mit der Logik "upsert", d. h. einfügen, wenn neu, oder aktualisieren, wenn bereits vorhanden.
• Bearbeiten Sie den Fehler für den Client.

Für stabile Verbindungen sorgen

Für eine optimale Leistung sollte die Verbindung, die Sie zum Hosten einer Sitzung verwenden, stabil sein. Wenn sich die Verbindung, die eine Sitzung hostet, ändert, bricht Spanner möglicherweise die aktive Transaktion in der Sitzung ab und verursacht eine geringe Belastung Ihrer Datenbank, während die Sitzungsmetadaten aktualisiert werden. Wenn sich einige Verbindungen gelegentlich ändern, ist das kein Problem, aber Sie sollten Situationen vermeiden, in denen sich eine große Anzahl von Verbindungen gleichzeitig ändert. Wenn Sie einen Proxy zwischen dem Client und Spanner verwenden, sollten Sie bei jeder Sitzung für eine stabile Verbindung sorgen.

Aktive Sitzungen überwachen

Mit dem Befehl ListSessions können Sie aktive Sitzungen in Ihrer Datenbank über die Befehlszeile, mit der REST API oder mit der RPC API überwachen. ListSessions zeigt die aktiven Sitzungen für eine bestimmte Datenbank an. Dies ist sinnvoll, wenn Sie die Ursache für ein Sitzungsleck finden möchten. Ein Sitzungsleck ist ein Vorfall, bei dem Sitzungen erstellt, aber nicht zur Wiederverwendung an einen Sitzungspool zurückgegeben werden.

Mit ListSessions können Sie Metadaten zu Ihren aktiven Sitzungen ansehen, z. B. wann eine Sitzung erstellt und wann sie zuletzt verwendet wurde. Die Analyse dieser Daten wird Ihnen bei der Fehlersuche die richtige Richtung weisen. Wenn für die meisten aktiven Sitzungen kein aktueller Wert für approximate_last_use_time vorhanden ist, kann dies darauf hindeuten, dass Sitzungen von Ihrer Anwendung nicht ordnungsgemäß wiederverwendet werden. Weitere Informationen zum Feld approximate_last_use_time finden Sie in der RPC API-Referenz.

Weitere Informationen zur Verwendung von ListSessions finden Sie in der REST API-Referenz, der RPC API-Referenz oder der Referenz zum gcloud-Befehlszeilentool.

Automatische Bereinigung von Sitzungslecks

Vorschau — Automatic cleanup of session leaks

Diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie besehen“ verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Wenn Sie alle Sitzungen in Ihrem Sitzungspool verwenden, wartet jede neue Transaktion, bis eine Sitzung in den Pool zurückgegeben wird. Wenn Sitzungen erstellt, aber nicht zur Wiederverwendung an den Sitzungspool zurückgegeben werden, spricht man von einem Sitzungsleck. Wenn ein Sitzungsleck auftritt, bleiben Transaktionen, die auf eine offene Sitzung warten, unbegrenzt hängen und blockieren die Anwendung. Sitzungslecks werden häufig durch problematische Transaktionen verursacht, die extrem lange ausgeführt werden und nicht festgeschrieben wurden.

Sie können Ihren Sitzungspool so einrichten, dass diese inaktiven Transaktionen automatisch aufgelöst werden. Wenn Sie Ihre Clientbibliothek so aktivieren, dass inaktive Übergangsvorgänge automatisch aufgelöst werden, werden problematische Transaktionen ermittelt, die ein Sitzungsleck verursachen können. Außerdem werden sie aus dem Sitzungspool entfernt und durch eine neue Sitzung ersetzt.

Logging kann auch dabei helfen, diese problematischen Transaktionen zu identifizieren. Wenn Logging aktiviert ist, werden Warnmeldungen standardmäßig freigegeben, sobald mehr als 95% Ihres Sitzungspools genutzt werden. Wenn Ihre Sitzungsnutzung mehr als 95 % beträgt, müssen Sie entweder die maximale Anzahl von Sitzungen im Sitzungspool erhöhen oder es besteht ein Sitzungsleck. Warnlogs enthalten Stacktraces von Transaktionen, die länger als erwartet ausgeführt werden, und können dabei helfen, die Ursache einer hohen Auslastung des Sitzungspools zu ermitteln. Warnlogs werden je nach Konfiguration des Logexporteurs gesendet.

Clientbibliothek aktivieren, um inaktive Transaktionen automatisch aufzulösen

Sie können die Clientbibliothek so einrichten, dass sie Warnlogs sendet und inaktive Transaktionen automatisch auflöst, oder die Clientbibliothek so, dass sie nur Warnmeldungen empfängt.

Java

Verwenden Sie setWarnAndCloseIfInactiveTransactions, um Warnlogs zu erhalten und inaktive Transaktionen zu entfernen.

 final SessionPoolOptions sessionPoolOptions = SessionPoolOptions.newBuilder().setWarnAndCloseIfInactiveTransactions().build()

 final Spanner spanner =
         SpannerOptions.newBuilder()
             .setSessionPoolOption(sessionPoolOptions)
             .build()
             .getService();
 final DatabaseClient client = spanner.getDatabaseClient(databaseId);

Wenn Sie nur Warnlogs erhalten möchten, verwenden Sie setWarnIfInactiveTransactions.

 final SessionPoolOptions sessionPoolOptions = SessionPoolOptions.newBuilder().setWarnIfInactiveTransactions().build()

 final Spanner spanner =
         SpannerOptions.newBuilder()
             .setSessionPoolOption(sessionPoolOptions)
             .build()
             .getService();
 final DatabaseClient client = spanner.getDatabaseClient(databaseId);

Einfach loslegen (Go)

Wenn Sie Warnlogs erhalten und inaktive Transaktionen entfernen möchten, verwenden Sie SessionPoolConfig mit InactiveTransactionRemovalOptions.

 client, err := spanner.NewClientWithConfig(
     ctx, database, spanner.ClientConfig{SessionPoolConfig: spanner.SessionPoolConfig{
         InactiveTransactionRemovalOptions: spanner.InactiveTransactionRemovalOptions{
         ActionOnInactiveTransaction: spanner.WarnAndClose,
         }
     }},
 )
 if err != nil {
     return err
 }
 defer client.Close()

Wenn Sie nur Warnlogs erhalten möchten, verwenden Sie customLogger.

 customLogger := log.New(os.Stdout, "spanner-client: ", log.Lshortfile)
 // Create a logger instance using the golang log package
 cfg := spanner.ClientConfig{
         Logger: customLogger,
     }
 client, err := spanner.NewClientWithConfig(ctx, db, cfg)

Multiplex-Sitzungen

Mit Multiplex-Sitzungen können Sie eine unbegrenzte Anzahl gleichzeitiger Anfragen erstellen. Multiplex-Sitzungen bieten folgende Vorteile:

• Geringere Anforderungen an Back-End-Ressourcen. Beispielsweise vermeiden sie Wartungsaktivitäten im Zusammenhang mit der Wartung der Sitzungsinhaberschaft und der automatischen Speicherbereinigung.
• Langlebige Sitzung, die bei Inaktivität keine Keep-Alive-Anfragen erfordert.
• Typische Clientbibliotheken können für jeden Client eine Multiplex-Sitzung verwenden. Die Anzahl der verwendeten regulären Sitzungen ist bei Clients, die für einige Vorgänge Multiplexsitzungen verwenden, geringer als bei Clients, die nur reguläre Sitzungen nutzen.
• Es ist keine Affinität zu nur einem gRPC-Kanal erforderlich. Clients können für dieselbe Multiplex-Sitzung Anfragen über mehrere Kanäle senden.

Bei Multiplex-Sitzungen wird Folgendes unterstützt:

• Java-Clientbibliothek
• Tools des Spanner-Ökosystems, die von der Java-Clientbibliothek abhängig sind, z. B. PGAdapter, JDBC und Hibernate
• Spanner APIs für schreibgeschützte Transaktionen

Sie verwenden OpenTelemetry-Messwerte, um zu sehen, wie der Traffic zwischen dem vorhandenen Sitzungspool und der Multiplex-Sitzung aufgeteilt wird. OpenTelemetry hat den Messwertfilter is_multiplexed, der Multiplex-Sitzungen anzeigt, wenn er auf true gesetzt ist.

Multiplex-Sitzungen sind für JDBC und den PG-Adapter standardmäßig aktiviert. Bei Java-Clientbibliotheken ist sie standardmäßig deaktiviert. Verwenden Sie die Java-Clientbibliothek, um Multiplex-Sitzungen zu aktivieren. Informationen zum Aktivieren einer Multiplex-Sitzung mit Java finden Sie unter Multiplex-Sitzungen aktivieren.

Multiplex-Sitzungen aktivieren

Setzen Sie GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS auf true, um Multiplex-Sitzungen mit dem Java-Client zu aktivieren.

export GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS=TRUE

Zugriffe für reguläre und Multiplex-Sitzungen ansehen

Opentelemetry bietet den Filter is_multiplexed, um den Traffic für Multiplex-Sitzungen anzuzeigen. Sie setzen diesen Filter auf true to view multiplexed sessions andfalse`, um reguläre Sitzungen anzuzeigen.

1. Richten Sie Opentelemetry für Spanner mit den Verfahren im Abschnitt Vorbereitung für Spanner Opentelemetry ein.

2. Rufen Sie den Metrics Explorer auf.

   Zum Metrics Explorer

3. Filtern Sie im Drop-down-Menü Messwert nach generic.

4. Klicken Sie auf Allgemeine Aufgabe und gehen Sie zu Spanner > Spanner/num_acquired_sessions.

5. Wählen Sie im Feld Filter eine der folgenden Optionen aus:

   a. is_multiplexed = false, um die regulären Sitzungen aufzurufen. b. is_multiplexed = true, um Multiplex-Sitzungen anzusehen.

   In der folgenden Abbildung sehen Sie die Option Filter mit ausgewählten Multiplex-Sitzungen.

Weitere Informationen zur Verwendung von OpenTelemetry mit Spanner finden Sie unter OpenTelemetry nutzen, um die Spanner-Beobachtbarkeit zu demokratisieren und Latenz in einer Spanner-Komponente mit OpenTelemetry untersuchen.