Hologres:Metrik pemantauan

Instance CPU Usage (%)

Beban CPU keseluruhan instans.

Proses latar belakang dan tugas compaction mengonsumsi CPU bahkan tanpa kueri aktif, sehingga penggunaan saat idle merupakan hal normal. Hologres menggunakan paralelisme multi-core, sehingga satu kueri saja dapat mendorong CPU ke 100% — ini menunjukkan pemanfaatan resource penuh, bukan masalah.

Kapan perlu diselidiki: Jika penggunaan CPU tetap mendekati 100% selama 3 jam atau di atas 90% selama 12 jam, instans sangat terbebani dan CPU kemungkinan menjadi bottleneck. Pertimbangkan apakah:

• Impor data offline besar (INSERT) sedang berjalan dengan volume data yang terus bertambah.

• Kueri atau penulisan ber-QPS tinggi mengonsumsi semua resource CPU.

• Beban kerja hibrida menggabungkan skenario di atas.

Jika beban CPU tinggi berkelanjutan diharapkan, lakukan penskalaan naik instans.

FAQ untuk metrik pemantauan.

Worker Node CPU Usage (%)

Beban CPU pada setiap node Worker. Jumlah node Worker bervariasi berdasarkan tipe instans. Untuk informasi lebih lanjut, lihat Manajemen instans.

Versi: V1.1+

• Jika semua node Worker menunjukkan penggunaan CPU berkelanjutan mendekati 100%, instans sangat terbebani. Optimalkan kueri atau lakukan penskalaan naik instans.

• Jika hanya beberapa node Worker yang menunjukkan penggunaan CPU tinggi, terjadi ketimpangan resource. Untuk penyebab umum dan troubleshooting, lihat FAQ untuk metrik pemantauan.

Cluster CPU Usage (%)

Penggunaan CPU setiap Cluster dalam compute group.

Versi: V4.0+. Hanya untuk instans compute group.

Instance Memory Usage (%)

Konsumsi memori keseluruhan instans.

Hologres menyisihkan memori untuk metadata, indeks, dan cache guna mempercepat kueri. Penggunaan idle sekitar 30%–40% merupakan hal biasa. Jika penggunaan mendekati 80%, memori mungkin menjadi bottleneck.

Gunakan metrik distribusi memori bersama QPS dan indikator lain untuk mengidentifikasi konsumen memori tinggi. Panduan troubleshooting untuk masalah kehabisan memori.

Worker Node Memory Usage (%)

Beban memori pada setiap node Worker. Jumlah node Worker bervariasi berdasarkan tipe instans. Untuk informasi lebih lanjut, lihat Manajemen instans.

Versi: V1.1+

• Jika semua node Worker menunjukkan penggunaan memori berkelanjutan mendekati 80%, instans sangat terbebani. Optimalkan kueri atau lakukan penskalaan naik instans.

• Jika hanya beberapa node Worker yang menunjukkan penggunaan memori tinggi, terjadi ketimpangan resource. Untuk penyebab umum dan troubleshooting, lihat FAQ untuk metrik pemantauan.

Detailed Instance Memory Usage (%)

Versi: V2.0+ (metrik distribusi memori tersedia mulai V2.0.15)

Hologres membagi memori menjadi enam kategori:

Troubleshooting: Penggunaan memori Query tinggi atau kejadian kehabisan memori (OOM) biasanya menunjukkan kueri kompleks atau konkurensi tinggi. Untuk panduan optimasi, lihat Optimalkan performa kueri.

QE Query Memory Usage (bytes)

Memori (dalam byte) yang digunakan oleh kueri yang dieksekusi oleh mesin HQE, SQE, atau mesin XQE lainnya.

Versi: V2.0.44+ / V2.1.22+

Dalam rincian memori, penggunaan memori Query melebihi penggunaan memori QE Query karena Query mencakup semua jenis mesin. Penggunaan memori QE Query yang lebih tinggi menunjukkan kueri lebih kompleks yang membutuhkan lebih banyak memori.

QE Query Memory Usage (%)

Persentase memori yang digunakan oleh kueri mesin QE.

Versi: V2.0.44+ / V2.1.22+

Penggunaan tinggi dapat menyebabkan error OOM. Optimalkan kueri atau lakukan penskalaan naik instans.

Cluster Memory Usage (%)

Penggunaan memori setiap Cluster dalam compute group.

Versi: V4.0+. Hanya untuk instans compute group.

Query QPS (count/s)

Rata-rata pernyataan SQL yang dieksekusi per detik, termasuk SELECT, INSERT, UPDATE, DELETE, UTILITY, dan UNKNOWN.

Hubungan: Query QPS >= QE Query QPS + FixedQE Query QPS

Total QPS mencakup semua kueri (UNKNOWN, UTILITY, Engine Type={PG}), sehingga nilainya sama dengan atau melebihi jumlah QPS QE dan FixedQE.

QE Query QPS (count/s)

Kueri per detik yang dieksekusi oleh mesin QE, termasuk SELECT, INSERT, UPDATE, dan DELETE.

Versi: V2.2+

FixedQE Query QPS (count/s)

Kueri per detik yang dieksekusi oleh mesin FixedQE (jalur Fixed Plan, sebelumnya SDK), termasuk SELECT, INSERT, UPDATE, dan DELETE.

Versi: V2.2+

DML RPS (count/s)

Rata-rata catatan data yang diimpor atau diperbarui per detik, termasuk INSERT, UPDATE, dan DELETE.

Hubungan: DML RPS = QE DML RPS + FixedQE DML RPS

QE DML RPS (count/s)

Catatan data yang diimpor atau diperbarui per detik oleh mesin QE, termasuk INSERT, UPDATE, dan DELETE.

Versi: V2.2+

Skenario QE umum:

• Impor atau pembaruan batch dari tabel eksternal MaxCompute atau OSS

• Penulisan atau pembaruan batch menggunakan COPY

• Impor batch antar tabel Hologres

FixedQE DML RPS (count/s)

Catatan data yang diimpor atau diperbarui per detik oleh mesin FixedQE (jalur Fixed Plan, sebelumnya SDK), termasuk INSERT, UPDATE, dan DELETE.

Versi: V2.2+

Skenario FixedQE umum:

• Penulisan real-time menggunakan Flink

• Penulisan menggunakan Holo-Client

• Impor menggunakan Spark

• Sinkronisasi real-time Binlog MySQL ke Hologres

• Impor dari DataHub

• Penulisan offline menggunakan Data Integration (DataX)

• Penulisan menggunakan SQL atau JDBC dengan INSERT INTO VALUES()

Query Latency (milliseconds)

Latensi rata-rata semua kueri, termasuk SELECT, INSERT, UPDATE, DELETE, UTILITY, dan UNKNOWN.

Hubungan: Query Latency >= MAX(QE Query Latency, FixedQE Query Latency)

QE Query Latency (milliseconds)

Latensi rata-rata kueri yang dieksekusi oleh mesin QE, termasuk SELECT, INSERT, UPDATE, dan DELETE.

Versi: V2.2+

Untuk troubleshooting latensi QE Query yang tinggi, periksa metrik Optimization Phase Duration, Start Query Phase Duration, Get Next Phase Duration, dan QE QPS.

FixedQE Query Latency (milliseconds)

Latensi rata-rata kueri yang dieksekusi oleh mesin FixedQE, termasuk SELECT, INSERT, UPDATE, dan DELETE.

Versi: V2.2+

Troubleshooting:

• Peningkatan sesekali: Mungkin menunjukkan lock HQE. Periksa apakah FixedQE Backend Lock Wait Time meningkat. Jika ya, gunakan Dapatkan insight kueri untuk mengidentifikasi kueri yang melakukan locking.

• Latensi tinggi berkelanjutan: Mungkin disebabkan desain tabel yang suboptimal atau gangguan dari kueri kompleks. Lihat Masalah umum dan diagnostik untuk Blink dan Flink.

Optimization Phase Duration (milliseconds)

Waktu yang dihabiskan dalam fase Optimasi, tempat pengoptimal mengurai SQL dan menghasilkan rencana fisik.

Versi: V2.0.44+ / V2.1.22+

Durasi Optimasi yang panjang menunjukkan kueri kompleks. Jika kueri hanya berbeda pada parameternya, gunakan Prepared Statements untuk mengurangi overhead optimasi. Untuk informasi lebih lanjut, lihat JDBC.

Start Query Phase Duration (milliseconds)

Waktu yang dihabiskan dalam fase Start Query — inisialisasi sebelum eksekusi kueri, termasuk locking dan penyelarasan versi skema.

Versi: V2.0.44+ / V2.1.22+

Durasi Start Query yang panjang sering disebabkan oleh waktu tunggu lock atau penggunaan CPU tinggi. Gunakan rencana eksekusi untuk analisis lebih mendalam.

Get Next Phase Duration (milliseconds)

Waktu dari akhir fase Start Query hingga semua hasil dikembalikan, termasuk komputasi dan pengiriman hasil.

Versi: V2.0.44+ / V2.1.22+

Durasi Get Next yang panjang sering mencerminkan komputasi kompleks. Korelasikan dengan penggunaan memori QE dan QE QPS. Jika tidak ada anomali pada metrik tersebut, kemungkinan klien lambat dalam mengonsumsi hasil.

Query P99 Latency (milliseconds)

Latensi persentil ke-99 semua kueri, termasuk SELECT, INSERT, UPDATE, UTILITY, dan kueri sistem.

Longest Running Query Duration in This Instance (milliseconds)

Durasi kueri aktif dengan durasi terpanjang, mencakup SELECT, INSERT, UPDATE, DELETE, UTILITY, dan UNKNOWN.

Versi: V1.1+

Kueri didistribusikan ke node Worker. Metrik ini melaporkan kueri dengan durasi terpanjang di seluruh Worker. Misalnya, jika Worker menjalankan kueri selama 10 menit, 5 menit, dan 30 detik, nilai yang dilaporkan adalah 10 menit.

Gabungkan metrik ini dengan kueri aktif atau log kueri lambat untuk mendiagnosis kueri berdurasi panjang dan menyelesaikan deadlock.

Metrik dilaporkan setiap menit, sehingga "durasi berjalan saat ini" dimulai sedikit setelah kueri dimulai. Metrik ini berguna untuk deteksi anomali tetapi tidak memberikan waktu yang tepat.

Failed Query QPS (milliseconds)

Rata-rata pernyataan SQL gagal per detik, termasuk SELECT, INSERT, UPDATE, DELETE, UTILITY, dan UNKNOWN.

Hubungan: Failed Query QPS >= QE Failed Query QPS + FixedQE Failed Query QPS

Total QPS gagal mencakup semua kueri gagal (UNKNOWN, UTILITY, Engine Type={PG}), sehingga nilainya sama dengan atau melebihi jumlah QPS gagal QE dan FixedQE.

Gunakan jenis dan frekuensi kueri gagal untuk menemukan kueri gagal di log kueri lambat, lalu analisis akar penyebabnya untuk meningkatkan ketersediaan.

QE Failed Query QPS (count/s)

Kueri gagal per detik oleh mesin QE, termasuk SELECT, INSERT, UPDATE, dan DELETE.

Versi: V2.2+

FixedQE Failed Query QPS (count/s)

Kueri gagal per detik oleh mesin FixedQE, termasuk SELECT, INSERT, UPDATE, dan DELETE.

Versi: V2.2+

Maximum FE Lock Wait Time (milliseconds)

Hologres memiliki beberapa node FE yang mengurai, mengirimkan, dan mengarahkan pernyataan SQL. Ketika beberapa koneksi pada FE yang sama melakukan operasi DDL pada tabel yang sama (seperti CREATE atau DROP), terjadi lock FE. Metrik ini menunjukkan waktu tunggu lock DDL per FE.

Versi: V2.2+

Jika waktu tunggu lock FE melebihi 5 menit dan FE Replay Delay juga melonjak, kemungkinan operasi DDL macet. Gunakan Kelola kueri untuk menemukan dan menghentikan kueri berdurasi panjang.

FixedQE Backend Lock Wait Time (milliseconds)

Kueri INSERT, DELETE, atau UPDATE yang menggunakan HQE mengambil table locks, sedangkan kueri FixedPlan mengambil row locks. Metrik ini meningkat ketika kueri FixedPlan menunggu row locks sementara kueri HQE memegang table locks pada tabel yang sama.

Versi: V2.2+

Jika nilai ini tinggi, periksa log kueri lambat untuk kueri FixedQE lambat, lalu gunakan Dapatkan insight kueri untuk mengidentifikasi kueri HQE yang melakukan locking.

Total Backend Lock Wait Time for Instance (milliseconds)

Total waktu tunggu lock untuk kueri INSERT, DELETE, atau UPDATE dalam instans, termasuk waktu tunggu lock FixedQE dan HQE.

Versi: V2.2+

Jika nilai ini tinggi, periksa log kueri lambat untuk kueri INSERT, DELETE, atau UPDATE lambat, lalu gunakan Dapatkan insight kueri untuk mengidentifikasi kueri HQE yang melakukan locking.

Gateway Connections (count)

Total koneksi pada lapisan Gateway instans, mencerminkan beban koneksi keseluruhan pada lapisan akses.

• Gateway connections = koneksi FE + pengirim WAL FE + Fixed FE non-Binlog + Fixed FE Binlog.

• Jika koneksi Gateway tetap mendekati batas instans dalam periode lama, resource koneksi hampir jenuh. Bersihkan koneksi idle atau lakukan penskalaan naik untuk mendapatkan kapasitas koneksi lebih besar.

Maximum Gateway Connection Usage (%)

Tingkat penggunaan koneksi Gateway tertinggi, mencerminkan tekanan puncak pada kolam koneksi lapisan akses. Saat penggunaan terus-menerus mendekati 100%, koneksi baru mungkin gagal. Selidiki bersama metrik Gateway Connections dan pertimbangkan penskalaan naik.

FE Connections (count)

Koneksi pada node FE (Frontend), mencerminkan beban koneksi pada lapisan penguraian dan pengarahan SQL. Hologres menetapkan batas koneksi FE default berdasarkan spesifikasi instans. Untuk informasi lebih lanjut, lihat Manajemen instans. Termasuk koneksi aktif, idle, dan idle-in-transaction. Gunakan Kelola kueri untuk melihat penggunaan koneksi saat ini dan menghentikan koneksi idle saat resource rendah.

FE Connections by Database (count)

Koneksi FE dipecah berdasarkan database, untuk mengidentifikasi database mana yang paling banyak mengonsumsi koneksi.

FE Connections by FE Node (count)

Koneksi FE dipecah berdasarkan node FE, untuk menilai apakah beban koneksi seimbang di seluruh node.

• Batas koneksi default per node FE: 128. Untuk batas total, lihat Manajemen instans.

• Jika koneksi pada node mana pun mendekati batas, tinjau koneksi idle versus aktif. Gunakan Kelola koneksi untuk membersihkan koneksi idle atau lakukan penskalaan naik.

• Jika beban koneksi tidak merata di seluruh node, gunakan Kelola koneksi untuk mengidentifikasi dan membersihkan koneksi idle.

Maximum FE Connection Usage (%)

Tingkat penggunaan koneksi FE tertinggi: Max(frontend_connection_used_rate). Gunakan ini untuk mendeteksi kapan node FE mendekati batas koneksi. Node FE menggunakan load balancing round-robin. Gunakan Kelola kueri untuk melihat detail penggunaan dan menghentikan koneksi idle saat diperlukan.

FE WAL Sender Count by FE Node (count)

WAL sender per node FE. Saat mengonsumsi Binlog melalui JDBC, setiap shard setiap tabel menggunakan satu koneksi WAL sender. Koneksi WAL sender independen dari koneksi biasa dan memiliki batas sendiri. Gunakan metrik ini untuk memantau pemanfaatan WAL sender per node FE.

Maximum WAL Sender Usage (%)

Tingkat penggunaan WAL sender tertinggi, mencerminkan tekanan maksimum pada koneksi terkait Binlog. Saat penggunaan mendekati batas, konsumsi Binlog mungkin terpengaruh. Selidiki dan lakukan penskalaan naik jika diperlukan.

Fixed FE Connections (non-Binlog) (count)

Koneksi non-Binlog pada node Fixed FE, mencerminkan beban koneksi pada jalur eksekusi Fixed Plan.

Fixed FE Binlog Connections (count)

Koneksi Binlog pada node Fixed FE, mencerminkan beban koneksi terkait Binlog pada jalur eksekusi Fixed Plan.

Queued Queries Count (count)

Jumlah permintaan kueri yang menunggu untuk dieksekusi.

Versi: V3.0+

Query Queue Entry QPS (count/s)

Kueri yang dikirim ke antrian sistem per detik. Gunakan ini untuk mengukur beban sistem dan frekuensi kueri.

Versi: V3.0+

Queries Transitioned from Queued to Running QPS (count/s)

Kueri yang berpindah dari status menunggu ke berjalan per detik.

Versi: V3.0+

QPS by State for Queries That Started Running (count/s)

Jumlah kueri per detik dalam antrian kueri, dikelompokkan berdasarkan status:

• kReadyToRun -- memenuhi syarat untuk berjalan

• kQueueTimeout -- gagal karena timeout antrian

• kCanceled -- gagal karena pembatalan

• kExceedConcurrencyLimit -- gagal karena batas konkurensi

Versi: V3.0+

Average Query Queue Wait Time (milliseconds)

Waktu rata-rata dari masuk antrian hingga mulai diproses. Ini tidak termasuk waktu eksekusi kueri aktual.

Versi: V3.0+

Query Queue Auto-Rate-Limit Max Concurrency (count)

Konkurensi maksimum untuk antrian kueri dengan auto-rate-limit.

Versi: V3.1+. Hanya untuk instans compute group.

Standard I/O Read Throughput (bytes/s)

Throughput baca untuk data penyimpanan Standard.

Standard I/O Write Throughput (bytes/s)

Throughput tulis untuk data penyimpanan Standard.

Low-Frequency IO Read Throughput (bytes/s)

Throughput baca untuk data penyimpanan IA.

Write throughput for low-frequency I/O (bytes/s)

Throughput tulis untuk data penyimpanan IA.

Standard Storage Used Capacity (bytes)

Kapasitas yang digunakan dalam penyimpanan Standard. Lakukan penskalaan naik penyimpanan jika penggunaan melebihi kapasitas yang dibeli.

Standard Storage Usage (%)

Persentase penggunaan kapasitas penyimpanan Standard. Lakukan penskalaan naik penyimpanan jika penggunaan melebihi kapasitas yang dibeli.

IA Storage Used Capacity (bytes)

Kapasitas yang digunakan dalam penyimpanan IA. Lakukan penskalaan naik penyimpanan jika penggunaan melebihi kapasitas yang dibeli.

IA Storage Usage (%)

Persentase penggunaan kapasitas penyimpanan IA. Lakukan penskalaan naik penyimpanan jika penggunaan melebihi kapasitas yang dibeli.

Recycle Bin Storage Usage (bytes)

Versi: V3.1+

Hologres mendukung recycle bin tabel mulai V3.1. Tabel yang dihapus dengan DROP tetap berada di recycle bin selama periode retensi, memungkinkan pemulihan tabel yang tidak sengaja dihapus. Tabel-tabel ini tetap mengonsumsi penyimpanan instans.

Pantau penggunaan recycle bin per database. Jika penghapusan tabel sering menyebabkan penggunaan recycle bin tinggi, konfigurasikan tabel agar melewati recycle bin saat dihapus.

FE Replay Delay (milliseconds)

Versi: V2.2+

Hologres memiliki beberapa node FE. Untuk operasi DDL, Hologres mengeksekusi operasi pada satu FE dan mereplay-nya di FE lain. Delay replay dalam milidetik atau detik adalah normal.

Jika delay replay FE melebihi beberapa menit, terlalu banyak operasi DDL mungkin membebani proses replay. Jika delay terus meningkat, kemungkinan ada kueri yang macet. Gunakan hg_stat_activity untuk menemukan dan menghentikan kueri berdurasi panjang.

Shard Multi-Replica Sync Delay (milliseconds)

Delay sinkronisasi antara replika Shard setelah Replikasi diaktifkan.

Delay replika Shard biasanya dalam milidetik. Penulisan data berat, pembaruan, atau operasi DDL sering dapat meningkatkan delay sinkronisasi.

Primary-Follower Sync Delay (milliseconds)

Delay saat instans follower membaca data dari instans primary. Metrik ini hanya muncul untuk instans follower, bukan instans primary.

• Data hanya muncul setelah instans follower diikat ke instans primary (0 ms awalnya). Delay sinkronisasi berfluktuasi saat instans primary menerima penulisan.

• Delay sinkronisasi normal dalam milidetik. Jitter sesekali akibat operasi DDL primary aman diabaikan. Delay tinggi berkelanjutan lebih dari beberapa detik mungkin menunjukkan beban instans tinggi atau kekurangan resource — periksa penggunaan CPU dan memori serta lakukan penskalaan naik jika diperlukan.

• Delay sinkronisasi mungkin melonjak hingga beberapa menit selama restart atau peningkatan dan kemudian pulih otomatis.

Cross-Instance File Sync Delay (milliseconds)

Delay sinkronisasi file antar instans pemulihan bencana. Metrik ini hanya muncul pada instans follower (follower read-only).

Tables Missing Statistics per Database (count)

Jumlah tabel yang tidak memiliki statistik di setiap database.

Versi: V2.2+

Untuk Hologres V2.0 dan seterusnya, Auto Analyze berjalan secara default. Setelah pembuatan tabel atau penulisan/pembaruan massal, statistik mungkin sementara tertinggal — amati terlebih dahulu dalam periode singkat.

Jika database secara konsisten tidak memiliki statistik selama berjam-jam atau berhari-hari, Auto Analyze mungkin belum dipicu. Gunakan Tampilan HG_STATS_MISSING untuk mencantumkan tabel yang terpengaruh, lalu jalankan ANALYZE secara manual. Untuk informasi lebih lanjut, lihat ANALYZE dan AUTO ANALYZE.

Longest Running Serverless Computing Query Duration (milliseconds)

Durasi kueri dengan durasi terpanjang dalam Serverless Computing. Serverless Computing menjalankan kueri tertentu dalam kolam resource khusus, terisolasi dari instans utama.

Versi: V2.1+

Gunakan hg_stat_activity untuk memeriksa status kueri Serverless Computing.

Serverless Computing Query Queue Count (count)

Jumlah kueri yang mengantri di kolam resource Serverless Computing.

Versi: V2.2+

Serverless Computing Resource Quota Usage (%)

Rasio resource Serverless Computing yang digunakan terhadap resource maksimum yang dapat dialokasikan.

Versi: V2.2+

Binlog Consumption Rate (count/s)

Jumlah entri Binlog yang dikonsumsi per detik. Hologres mendukung berlangganan Binlog Hologres untuk tiering data real-time dan penerusan data dipercepat.

Versi: V2.2+

Binlog Consumption Rate (bytes/s)

Byte yang dikonsumsi dari Binlog per detik. Field yang lebih besar atau volume data lebih tinggi meningkatkan jumlah byte.

Versi: V2.2+

WAL Sender Count per FE (count)

Jumlah WAL sender yang digunakan per node FE. Setiap shard setiap tabel mengonsumsi satu koneksi WAL sender saat mengonsumsi Binlog menggunakan JDBC. Koneksi WAL sender independen dari koneksi biasa dan memiliki batas default.

Versi: V2.2+

WAL Sender Usage Rate of FE with Highest Usage (%)

Pemanfaatan WAL sender tertinggi di seluruh node FE.

Versi: V2.2+

Jika penggunaan WAL sender mencapai batas, lihat Konsumsi Binlog Hologres melalui JDBC untuk troubleshooting.

Elastic Core Count for Compute Groups

Core yang ditambahkan oleh penskalaan berbasis waktu dalam compute group. Elastisitas berbasis waktu (Beta).

Versi: V2.2.21+. Hanya untuk instans compute group.

Compute Group Auto-Elastic Core Count (count)

Core yang ditambahkan oleh auto-scaling dalam compute group. Multi-kluster dan auto-elastisitas (Beta).

Versi: V4.0+. Hanya untuk instans compute group.

Gateway CPU Usage (%)

Penggunaan CPU setiap Gateway dalam instans.

Versi: V2.0+. Hanya untuk instans compute group.

Gateway menggunakan penerusan trafik round-robin, sehingga penggunaan CPU terjadi bahkan tanpa koneksi baru. Mulai V2.2.22, Gateway meluncurkan lebih banyak thread pekerja secara default untuk meningkatkan penanganan koneksi, yang meningkatkan penggunaan CPU dasar.

Gateway Memory Usage (%)

Penggunaan memori setiap Gateway dalam instans.

Versi: V2.0+. Hanya untuk instans compute group.

Gateway New Connection Requests per Second (count/s)

Jumlah maksimum koneksi baru yang dapat diterima dan berhasil dibuat sistem per detik.

Versi: V2.1.12+. Hanya untuk instans compute group.

Satu Gateway menangani sekitar 100 koneksi baru per detik. Jika permintaan koneksi baru mendekati 100 x jumlah Gateway, Gateway menjadi bottleneck. Konfigurasikan kolam koneksi atau lakukan penskalaan naik jumlah Gateway.

Gateway Inbound Traffic Rate (B/s)

Volume data yang masuk melalui Gateway per detik.

Versi: V2.1+. Hanya untuk instans compute group.

Jika trafik inbound mendekati 200 MiB/s x jumlah Gateway, kapasitas jaringan Gateway menjadi bottleneck. Lakukan penskalaan naik jumlah Gateway.

Gateway Outbound Traffic Rate (B/s)

Volume data yang dikirim dari Gateway per detik.

Versi: V2.1+. Hanya untuk instans compute group.

Jika trafik outbound mendekati 200 MiB/s x jumlah Gateway, kapasitas jaringan Gateway menjadi bottleneck. Lakukan penskalaan naik jumlah Gateway.