Sesi

Halaman ini menjelaskan konsep lanjutan sesi di Spanner, termasuk praktik terbaik untuk sesi saat membuat library klien, menggunakan REST API atau RPC API, atau menggunakan library klien Google.

Sesi mewakili saluran komunikasi dengan layanan database Spanner. Sesi digunakan untuk melakukan transaksi yang membaca, menulis, atau mengubah data dalam database Spanner. Setiap sesi berlaku untuk satu database.

Sesi dapat menjalankan satu atau beberapa transaksi sekaligus. Saat melakukan beberapa transaksi, sesi tersebut disebut sesi yang dimultipleks. Pembacaan, penulisan, dan kueri mandiri menggunakan satu transaksi secara internal.

Manfaat performa kumpulan sesi

Membuat sesi memerlukan biaya yang besar. Untuk menghindari biaya performa setiap kali operasi database dilakukan, klien harus menyimpan kumpulan sesi, yang merupakan kumpulan sesi yang tersedia dan siap digunakan. Kumpulan sesi harus menyimpan sesi yang ada dan menampilkan jenis sesi yang sesuai saat diminta, serta menangani pembersihan sesi yang tidak digunakan. Untuk contoh cara menerapkan kumpulan sesi, lihat kode sumber untuk salah satu library klien Spanner, seperti library klien Go atau library klien Java.

Sesi dimaksudkan untuk digunakan dalam jangka panjang, sehingga setelah sesi digunakan untuk operasi database, klien harus mengembalikan sesi ke kumpulan sesi untuk digunakan kembali.

Ringkasan channel gRPC

Channel gRPC digunakan oleh klien Spanner untuk komunikasi. Satu channel gRPC kira-kira setara dengan koneksi TCP. Satu channel gRPC dapat menangani hingga 100 permintaan serentak. Artinya, aplikasi akan memerlukan setidaknya channel gRPC sebanyak jumlah permintaan serentak yang akan dijalankan aplikasi, dibagi 100.

Klien Spanner membuat kumpulan channel gRPC saat Anda membuatnya.

Praktik terbaik saat menggunakan library klien Google

Berikut ini praktik terbaik saat menggunakan library klien Google untuk Spanner.

Mengonfigurasi jumlah sesi dan channel gRPC dalam kumpulan sesi

Library klien memiliki jumlah sesi default dalam kumpulan sesi dan jumlah channel gRPC default dalam kumpulan channel. Kedua nilai default tersebut memadai untuk sebagian besar kasus. Berikut adalah sesi minimum dan maksimum default serta jumlah channel gRPC default untuk setiap bahasa pemrograman.

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

Klien Node.js tidak mendukung beberapa channel gRPC. Oleh karena itu, sebaiknya buat beberapa klien, bukan meningkatkan ukuran kumpulan sesi di atas 100 sesi untuk satu klien.

MinSessions: 25
MaxSessions: 100

PHP

Klien PHP tidak mendukung jumlah channel gRPC yang dapat dikonfigurasi.

MinSessions: 1
MaxSessions: 500

Python

Python mendukung empat jenis kumpulan sesi berbeda yang dapat Anda gunakan untuk mengelola sesi.

Ruby

Klien Ruby tidak mendukung beberapa channel gRPC. Oleh karena itu, sebaiknya buat beberapa klien, bukan meningkatkan ukuran kumpulan sesi di atas 100 sesi untuk satu klien.

MinSessions: 10
MaxSessions: 100

Jumlah sesi yang digunakan aplikasi Anda sama dengan jumlah transaksi serentak yang dijalankan aplikasi Anda. Anda hanya boleh mengubah setelan kumpulan sesi default jika Anda memperkirakan satu instance aplikasi akan menjalankan lebih banyak transaksi serentak daripada yang dapat ditangani oleh kumpulan sesi default.

Untuk aplikasi konkurensi tinggi, sebaiknya lakukan hal berikut:

  1. Tetapkan MinSessions ke jumlah transaksi serentak yang diharapkan yang akan dijalankan oleh satu klien.
  2. Tetapkan MaxSessions ke jumlah maksimum transaksi serentak yang dapat dijalankan oleh satu klien.
  3. Tetapkan MinSessions=MaxSessions jika konkurensi yang diharapkan tidak banyak berubah selama masa aktif aplikasi. Hal ini mencegah kumpulan sesi melakukan penskalaan naik atau turun. Penskalaan kumpulan sesi naik atau turun juga menggunakan beberapa resource.
  4. Tetapkan NumChannels ke MaxSessions / 100. Satu channel gRPC dapat menangani hingga 100 permintaan secara serentak. Tingkatkan nilai ini jika Anda mengamati latensi ekor yang tinggi (latensi p95/p99), karena hal ini dapat menjadi indikasi kemacetan channel gRPC.

Meningkatkan jumlah sesi aktif menggunakan resource tambahan pada layanan database Spanner dan di library klien. Meningkatkan jumlah sesi di luar kebutuhan aplikasi yang sebenarnya dapat menurunkan performa sistem Anda.

Meningkatkan kumpulan sesi versus meningkatkan jumlah klien

Ukuran kumpulan sesi untuk aplikasi menentukan jumlah transaksi serentak yang dapat dijalankan oleh satu instance aplikasi. Sebaiknya jangan meningkatkan ukuran kumpulan sesi di luar konkurensi maksimum yang dapat ditangani oleh satu instance aplikasi. Jika aplikasi menerima lonjakan permintaan yang melebihi jumlah sesi dalam kumpulan sesi, permintaan akan diantrekan saat menunggu sesi tersedia.

Resource yang digunakan oleh library klien adalah sebagai berikut:

  1. Setiap channel gRPC menggunakan satu koneksi TCP.
  2. Setiap pemanggilan gRPC memerlukan thread. Jumlah maksimum thread yang digunakan oleh library klien sama dengan jumlah maksimum kueri serentak yang dijalankan aplikasi. Thread ini berada di atas thread yang digunakan aplikasi untuk logika bisnisnya sendiri.

Sebaiknya jangan meningkatkan ukuran kumpulan sesi di luar jumlah maksimum thread yang dapat ditangani oleh satu instance aplikasi. Sebagai gantinya, tingkatkan jumlah instance aplikasi.

Mengelola fraksi sesi tulis

Untuk beberapa library klien, Spanner mencadangkan sebagian sesi untuk transaksi baca-tulis, yang disebut fraksi sesi tulis. Jika aplikasi Anda menggunakan semua sesi baca, Spanner akan menggunakan sesi baca-tulis, bahkan untuk transaksi hanya baca. Sesi baca-tulis memerlukan spanner.databases.beginOrRollbackReadWriteTransaction. Jika pengguna berada dalam peran IAM spanner.databaseReader, panggilan akan gagal dan Spanner akan menampilkan pesan error ini:

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

Untuk library klien yang mempertahankan fraksi sesi tulis, Anda dapat menetapkan fraksi sesi tulis.

C++

Semua sesi C++ sama. Tidak ada sesi hanya baca atau baca-tulis.

C#

Fraksi sesi tulis default untuk C# adalah 0,2. Anda dapat mengubah fraksi menggunakan kolom WriteSessionsFraction dari SessionPoolOptions.

Go

Semua sesi Go sama. Tidak ada sesi hanya baca atau baca-tulis.

Java

Semua sesi Java sama. Tidak ada sesi hanya baca atau baca-tulis.

Node.js

Semua sesi Node.js sama. Tidak ada sesi hanya baca atau baca-tulis.

PHP

Semua sesi PHP sama. Tidak ada sesi hanya baca atau baca-tulis.

Python

Python mendukung empat jenis kumpulan sesi berbeda yang dapat Anda gunakan untuk mengelola sesi baca dan baca-tulis.

Ruby

Fraksi sesi tulis default untuk Ruby adalah 0,3. Anda dapat mengubah fraksi menggunakan klien metode inisialisasi.

Praktik terbaik saat membuat library klien atau menggunakan REST/RPC

Berikut ini praktik terbaik untuk menerapkan sesi di library klien untuk Spanner, atau untuk menggunakan sesi dengan REST API atau RPC API.

Praktik terbaik ini hanya berlaku jika Anda mengembangkan library klien, atau jika Anda menggunakan REST/RPC API. Jika Anda menggunakan salah satu library klien Google untuk Spanner, lihat Praktik terbaik saat menggunakan library klien Google.

Membuat dan menentukan ukuran kumpulan sesi

Untuk menentukan ukuran kumpulan sesi yang optimal untuk proses klien, tetapkan batas bawah ke jumlah transaksi serentak yang diharapkan, dan tetapkan batas atas ke angka pengujian awal, seperti 100. Jika batas atas tidak memadai, tingkatkan. Meningkatkan jumlah sesi aktif menggunakan resource tambahan pada layanan database Spanner, sehingga kegagalan membersihkan sesi yang tidak digunakan dapat menurunkan performa. Untuk pengguna yang menggunakan RPC API, sebaiknya jangan memiliki lebih dari 100 sesi per channel gRPC.

Menangani sesi yang dihapus

Ada tiga cara untuk menghapus sesi:

  • Klien dapat menghapus sesi.
  • Layanan database Spanner dapat menghapus sesi saat sesi tidak aktif selama lebih dari 1 jam.
  • Layanan database Spanner dapat menghapus sesi jika sesi tersebut berusia lebih dari 28 hari.

Upaya untuk menggunakan sesi yang dihapus akan menghasilkan NOT_FOUND. Jika Anda mengalami error ini, buat dan gunakan sesi baru, tambahkan sesi baru ke kumpulan sesi, dan hapus sesi yang dihapus dari kumpulan sesi.

Mempertahankan sesi yang tidak aktif

Layanan database Spanner berhak menghapus sesi yang tidak digunakan. Jika Anda benar-benar perlu mempertahankan sesi yang tidak aktif, misalnya, jika diperkirakan akan terjadi peningkatan penggunaan database yang signifikan dalam waktu dekat, Anda dapat mencegah sesi dihapus. Lakukan operasi yang tidak mahal seperti menjalankan kueri SQL SELECT 1 untuk mempertahankan sesi. Jika Anda memiliki sesi yang tidak aktif dan tidak diperlukan untuk penggunaan dalam waktu dekat, biarkan Spanner menghapus sesi tersebut, lalu buat sesi baru saat sesi diperlukan.

Salah satu skenario untuk mempertahankan sesi adalah menangani permintaan puncak reguler pada database. Jika penggunaan database yang berat terjadi setiap hari dari pukul 09.00 hingga 18.00, Anda harus mempertahankan beberapa sesi yang tidak aktif selama waktu tersebut, karena kemungkinan sesi tersebut diperlukan untuk penggunaan puncak. Setelah pukul 18.00, Anda dapat membiarkan Spanner menghapus sesi yang tidak aktif. Sebelum pukul 09.00 setiap hari, buat beberapa sesi baru sehingga sesi tersebut akan siap untuk permintaan yang diharapkan.

Skenario lainnya adalah jika Anda memiliki aplikasi yang menggunakan Spanner tetapi harus menghindari overhead koneksi saat melakukannya. Anda dapat mempertahankan sekumpulan sesi untuk menghindari overhead koneksi.

Menyembunyikan detail sesi dari pengguna library klien

Jika Anda membuat library klien, jangan ekspos sesi ke konsumen library klien. Berikan kemampuan kepada klien untuk melakukan panggilan database tanpa kerumitan membuat dan mempertahankan sesi. Untuk contoh library klien yang menyembunyikan detail sesi dari konsumen library klien, lihat library klien Spanner untuk Java.

Menangani error untuk transaksi tulis yang tidak idempoten

Transaksi tulis tanpa perlindungan replay dapat menerapkan mutasi lebih dari sekali. Jika mutasi tidak idempoten, mutasi yang diterapkan lebih dari sekali dapat menyebabkan kegagalan. Misalnya, penyisipan dapat gagal dengan ALREADY_EXISTS meskipun baris tidak ada sebelum upaya penulisan. Hal ini dapat terjadi jika server backend melakukan mutasi tetapi tidak dapat mengomunikasikan keberhasilan kepada klien. Dalam peristiwa tersebut, mutasi dapat dicoba lagi, sehingga menyebabkan kegagalan ALREADY_EXISTS.

Berikut adalah kemungkinan cara untuk mengatasi skenario ini saat Anda menerapkan library klien sendiri atau menggunakan REST API:

  • Strukturkan penulisan Anda agar idempoten.
  • Gunakan penulisan dengan perlindungan replay.
  • Terapkan metode yang melakukan logika "upsert": sisipkan jika baru atau perbarui jika ada.
  • Tangani error atas nama klien.

Mempertahankan koneksi yang stabil

Untuk performa terbaik, koneksi yang Anda gunakan untuk menghosting sesi harus tetap stabil. Saat koneksi yang menghosting sesi berubah, Spanner dapat membatalkan transaksi aktif pada sesi dan menyebabkan sedikit beban tambahan pada database Anda saat memperbarui metadata sesi. Tidak masalah jika beberapa koneksi berubah secara sporadis, tetapi Anda harus menghindari situasi yang akan mengubah sejumlah besar koneksi pada saat yang sama. Jika Anda menggunakan proxy antara klien dan Spanner, Anda harus mempertahankan stabilitas koneksi untuk setiap sesi.

Memantau sesi aktif

Anda dapat menggunakan perintah ListSessions untuk memantau sesi aktif di database Anda dari command line, dengan REST API, atau dengan RPC API. ListSessions menampilkan sesi aktif untuk database tertentu. Hal ini berguna jika Anda perlu menemukan penyebab kebocoran sesi. (Kebocoran sesi adalah insiden saat sesi dibuat tetapi tidak dikembalikan ke kumpulan sesi untuk digunakan kembali.)

ListSessions memungkinkan Anda melihat metadata tentang sesi aktif, termasuk kapan sesi dibuat dan kapan sesi terakhir digunakan. Menganalisis data ini akan mengarahkan Anda ke arah yang benar saat memecahkan masalah sesi. Jika sebagian besar sesi aktif tidak memiliki approximate_last_use_time terbaru, hal ini dapat menunjukkan bahwa sesi tidak digunakan kembali dengan benar oleh aplikasi Anda. Lihat referensi RPC API untuk mengetahui informasi selengkapnya tentang kolom approximate_last_use_time.

Lihat referensi REST API, referensi RPC API, atau referensi alat command line gcloud untuk mengetahui informasi selengkapnya tentang penggunaan ListSessions.

Pembersihan otomatis kebocoran sesi

Saat Anda menggunakan semua sesi dalam kumpulan sesi, setiap transaksi baru akan menunggu hingga sesi dikembalikan ke kumpulan sesi. Saat sesi dibuat tetapi tidak dikembalikan ke kumpulan sesi untuk digunakan kembali, hal ini disebut kebocoran sesi. Jika terjadi kebocoran sesi, transaksi yang menunggu sesi terbuka akan macet tanpa batas waktu dan memblokir aplikasi. Kebocoran sesi sering kali disebabkan oleh transaksi bermasalah yang berjalan sangat lama dan tidak dilakukan.

Anda dapat menyiapkan kumpulan sesi untuk otomatis menyelesaikan transaksi yang tidak aktif ini. Saat Anda mengaktifkan library klien untuk otomatis menyelesaikan transisi yang tidak aktif, library klien akan mengidentifikasi transaksi bermasalah yang dapat menyebabkan kebocoran sesi, menghapusnya dari kumpulan sesi, dan menggantinya dengan sesi baru.

Logging juga dapat membantu mengidentifikasi transaksi bermasalah ini. Jika logging diaktifkan, log peringatan akan dibagikan secara default saat lebih dari 95% kumpulan sesi Anda digunakan. Jika penggunaan sesi Anda lebih besar dari 95%, Anda harus meningkatkan sesi maksimum yang diizinkan dalam kumpulan sesi, atau Anda mungkin mengalami kebocoran sesi. Log peringatan berisi pelacakan tumpukan transaksi yang berjalan lebih lama dari yang diharapkan dan dapat membantu mengidentifikasi penyebab penggunaan kumpulan sesi yang tinggi. Log peringatan akan dikirimkan bergantung pada konfigurasi pengekspor log Anda.

Mengaktifkan library klien untuk otomatis menyelesaikan transaksi yang tidak aktif

Anda dapat mengaktifkan library klien untuk mengirim log peringatan dan otomatis menyelesaikan transaksi yang tidak aktif, atau mengaktifkan library klien untuk hanya menerima log peringatan.

Java

Untuk menerima log peringatan dan menghapus transaksi yang tidak aktif, gunakan setWarnAndCloseIfInactiveTransactions.

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

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

Untuk hanya menerima log peringatan, gunakan setWarnIfInactiveTransactions.

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

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

Go

Untuk menerima log peringatan dan menghapus transaksi yang tidak aktif, gunakan SessionPoolConfig dengan 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()

Untuk hanya menerima log peringatan, gunakan 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)

Sesi yang dimultipleks

Sesi yang dimultipleks memungkinkan Anda membuat sejumlah besar permintaan serentak dalam satu sesi. Sesi yang dimultipleks adalah ID yang Anda gunakan di beberapa channel gRPC. Sesi ini tidak menimbulkan bottleneck tambahan. Sesi yang dimultipleks memiliki keunggulan sebagai berikut:

  • Pengurangan penggunaan resource backend karena protokol pengelolaan sesi yang lebih sederhana. Misalnya, sesi ini menghindari aktivitas pemeliharaan sesi yang terkait dengan pemeliharaan kepemilikan sesi dan pengumpulan sampah.
  • Sesi yang digunakan dalam jangka panjang dan tidak memerlukan permintaan keep-alive saat tidak aktif.

Sesi yang dimultipleks didukung di:

  • Library klien C++, Go, Java, Node.js, PHP, Python, dan Ruby client libraries.

  • Alat ekosistem Spanner yang bergantung pada Library klien yang disebutkan, seperti PGAdapter, JDBC, Hibernate, driver database/sql, driver dbAPI, dan GORM.

  • Alat ekosistem Spanner yang bergantung pada Library klien Java dan Go, seperti PGAdapter, JDBC, Hibernate, driver database atau sql, dan GORM. Anda dapat menggunakan metrik OpenTelemetry untuk melihat cara traffic dibagi antara kumpulan sesi yang ada dan sesi yang dimultipleks. OpenTelemetry memiliki filter metrik, is_multiplexed, yang menampilkan sesi yang dimultipleks jika ditetapkan ke true.

Sesi yang dimultipleks didukung untuk semua jenis transaksi.

Library klien merotasi sesi yang dimultipleks setiap 7 hari untuk mencegah pengiriman transaksi pada sesi yang tidak aktif.

Sesi yang dimultipleks diaktifkan secara default di beberapa library klien. Untuk library klien lainnya, Anda harus menggunakan variabel lingkungan untuk mengaktifkannya. Untuk mengetahui detailnya, lihat Mengaktifkan sesi yang dimultipleks.

Pertimbangan

Jika Anda mencoba melakukan transaksi baca atau tulis kosong atau transaksi yang setiap kueri atau pernyataan DML-nya gagal, ada beberapa skenario yang perlu dipertimbangkan dengan sesi yang dimultipleks. Sesi yang dimultipleks mengharuskan Anda menyertakan token pra-commit yang dibuat server di setiap permintaan commit. Untuk transaksi yang berisi kueri atau DML, harus ada setidaknya satu transaksi kueri atau DML sebelumnya yang berhasil agar server dapat mengirim kembali token yang valid ke library klien. Jika tidak ada kueri atau transaksi DML yang berhasil, library klien akan secara implisit menambahkan SELECT 1 sebelum commit.

Untuk transaksi baca atau tulis pada sesi yang dimultipleks yang hanya memiliki mutasi, jika salah satu mutasi adalah untuk tabel atau kolom yang TIDAK ada dalam skema, klien dapat menampilkan error INVALID_ARGUMENT, bukan error NOT_FOUND.

Mengaktifkan sesi yang dimultipleks

Sesi yang dimultipleks diaktifkan secara default di library klien berikut:

  • C++ dalam versi 2.41.0 dan yang lebih baru.
  • Go dalam versi 1.85.0 dan yang lebih baru.
  • Java dalam versi 6.98.0 dan yang lebih baru.
  • Node.js dalam versi 8.3.0 dan yang lebih baru.
  • PHP dalam versi 2.0.0 dan yang lebih baru.
  • Python dalam versi 3.57.0 dan yang lebih baru.
  • Ruby dalam versi 2.30.0 dan yang lebih baru.

Untuk menggunakan sesi yang dimultipleks di versi library klien Node.js, Java, dan Go yang lebih lama, Anda harus menetapkan variabel lingkungan terlebih dahulu untuk mengaktifkannya.

Untuk mengaktifkan sesi yang dimultipleks, tetapkan variabel lingkungan GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS ke TRUE. Flag ini juga mengaktifkan dukungan sesi yang dimultipleks untuk transaksi ReadOnly.

export GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS=TRUE

Untuk mengaktifkan dukungan operasi yang dipartisi untuk sesi yang dimultipleks, tetapkan variabel lingkungan GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS_PARTITIONED_OPS ke TRUE.

export GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS_PARTITIONED_OPS=TRUE

Untuk mengaktifkan dukungan transaksi baca-tulis untuk sesi yang dimultipleks, tetapkan variabel lingkungan GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS_FOR_RW ke TRUE.

export GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS_FOR_RW=True

Anda harus menetapkan GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS ke TRUE sebagai prasyarat untuk mendukung transaksi pada sesi yang dimultipleks.

Melihat traffic untuk sesi reguler dan sesi yang dimultipleks

OpenTelemetry memiliki filter is_multiplexed untuk menampilkan traffic untuk sesi yang dimultipleks. Anda menetapkan filter ini ke true to view multiplexed sessions andfalse` untuk melihat sesi reguler.

  1. Siapkan OpenTelemetry untuk Spanner menggunakan prosedur di Spanner OpenTelemetry Sebelum memulai bagian.

  2. Buka Metrics Explorer.

    Buka Metrics Explorer

  3. Di menu drop-down Metrik, filter berdasarkan generic.

  4. Klik Tugas Umum dan buka Spanner > Spanner/num_acquired_sessions.

  5. Di kolom Filter, pilih salah satu opsi berikut:

    a. is_multiplexed = false untuk melihat sesi reguler. b. is_multiplexed = true untuk melihat sesi yang dimultipleks.

    Gambar berikut menunjukkan opsi Filter dengan sesi yang dimultipleks dipilih.

Untuk mengetahui informasi selengkapnya tentang penggunaan OpenTelemetry dengan Spanner, lihat Memanfaatkan OpenTelemetry untuk mendemokratisasi Kemampuan Observasi Spanner dan Memeriksa latensi dalam komponen Spanner dengan OpenTelemetry.

Dasbor Opentelemetry yang menampilkan filter is-multiplexed.

Memecahkan masalah

Error terkait sesi umum yang mungkin dialami aplikasi Anda mencakup:

  • Session not found
  • RESOURCE_EXHAUSTED

Untuk mengetahui informasi selengkapnya, lihat Error sesi.