AnalyticDB：Pemantauan

Ikhtisar FAQ

• Bagaimana cara memantau penggunaan disk untuk kluster Data Warehouse Edition dalam mode reserved?

• Bagaimana cara melihat berapa banyak penyimpanan yang digunakan untuk hot data dan cold data?

• Bagaimana cara memeriksa informasi seperti ukuran tabel?

• Mengapa penggunaan hot data pada halaman Monitoring Information lebih besar daripada total penggunaan data?

• Mengapa rata-rata pemanfaatan CPU meningkat pada antarmuka pemantauan setelah kluster diubah dari mode reserved ke mode elastic?

• Waktu respons kueri yang lama ditampilkan pada halaman Monitoring Information, tetapi tidak ditemukan kueri SQL yang memakan waktu lama yang sesuai pada halaman Diagnostics and Optimization. Mengapa?

Bagaimana cara memantau penggunaan disk untuk kluster Data Warehouse Edition dalam mode reserved?

Untuk mencegah penggunaan disk melebihi ambang batas, konfigurasikan aturan peringatan yang akan mengirim notifikasi saat penggunaan mencapai ambang batas tertentu. Hal ini membantu Anda mengelola ruang disk dan menjaga kelangsungan bisnis.

1. Masuk ke Konsol AnalyticDB for MySQL. Di pojok kiri atas konsol, pilih wilayah. Di panel navigasi sebelah kiri, klik Clusters. Temukan kluster yang ingin Anda kelola dan klik ID kluster tersebut.

2. Di panel navigasi sebelah kiri, klik Monitoring and Alerts.

3. Pada halaman Monitoring and Alerts, lihat penggunaan disk.

   Dalam mode reserved, penggunaan disk ditampilkan dalam persentase. Dalam mode elastic, penggunaan disk absolut dari node baca/tulis ditampilkan.

   • Mode Cadangan

     Catatan

     Penggunaan disk maksimum adalah penggunaan disk tertinggi di antara semua node dalam kluster. Jika nilainya mencapai 90% atau lebih, disk akan dikunci. Pantau metrik ini secara seksama.

   • Mode Elastis

     Catatan

     Penggunaan disk adalah penggunaan disk maksimum dari satu node baca/tulis. Jika nilainya mencapai 8 TB atau lebih, data tidak dapat ditulis ke kluster. Pantau metrik ini secara seksama.

4. Klik tab Alerts.

5. Pada halaman tab Alerts, klik Create Alert Rule.

6. Pada halaman Create Alert Rule, konfigurasikan parameter-parameter berikut.

   Parameter	Deskripsi
   Resource Scope	Ruang lingkup yang berlaku untuk aturan peringatan. Nilai yang valid: All Resources: Aturan berlaku untuk semua instans produk di bawah akun Anda. Misalnya, Anda dapat menetapkan aturan peringatan ketika penggunaan disk instans AnalyticDB for MySQL Anda mencapai atau melebihi 80%. Jika Anda menetapkan Resource Scope ke All Resources, aturan tersebut dapat memantau maksimal 1.000 resource. Jika Anda memiliki lebih dari 1.000 resource AnalyticDB for MySQL, peringatan mungkin tidak dipicu meskipun ambang batas tercapai. Kami menyarankan agar Anda menggunakan application groups untuk membagi resource berdasarkan bisnis sebelum menetapkan peringatan. Application Group: Aturan berlaku untuk semua resource dalam application group tertentu untuk produk cloud tersebut. Instance: Aturan hanya berlaku untuk instans tertentu dari produk cloud tersebut. Misalnya, jika Anda menetapkan peringatan ketika penggunaan disk instans tertentu mencapai atau melebihi 80%, notifikasi peringatan hanya dikirim saat penggunaan disk instans tersebut memenuhi kondisi tersebut.
   Rule Description	Inti dari aturan peringatan. Aturan dipicu ketika data pemantauan memenuhi kondisi peringatan. Untuk menetapkan deskripsi aturan: Klik Add Rule. Pada panel Add Rule Description, tetapkan Rule Name, Metric Type, Monitoring Metrics, Threshold and Alert Level, dan pratinjau Monitoring Chart. Klik OK.
   Mute Period	Interval pengiriman ulang notifikasi peringatan jika masalah belum terselesaikan. Nilai yang valid: 5 menit, 15 menit, 30 menit, 60 menit, 3 jam, 6 jam, 12 jam, dan 24 jam. Saat metrik mencapai ambang batas peringatan, peringatan dikirim. Jika metrik terus melebihi ambang batas selama periode bisu, tidak ada peringatan tambahan yang dikirim. Jika metrik belum kembali normal setelah periode bisu berakhir, Cloud Monitor akan mengirim notifikasi peringatan lainnya.
   Effective Period	Periode saat aturan peringatan aktif. Aturan hanya memeriksa data pemantauan untuk peringatan selama periode ini. Penting Untuk peringatan penggunaan disk, setiap kontak peringatan dapat menerima maksimal empat notifikasi per hari. Setelah notifikasi keempat, kontak tersebut dibisukan untuk hari tersebut.
   Alert Contact Group	Kelompok kontak yang menerima notifikasi peringatan. Notifikasi peringatan untuk application group dikirim ke kontak dalam kelompok kontak peringatan ini. Kelompok kontak peringatan dapat berisi satu atau beberapa kontak peringatan. Untuk informasi lebih lanjut tentang cara membuat kontak peringatan dan kelompok kontak peringatan, lihat Create an alert contact or an alert contact group.
   Alert Callback	Masukkan URL publik. Cloud Monitor mendorong informasi peringatan ke URL ini melalui permintaan POST. Hanya protokol HTTP yang didukung. Untuk informasi lebih lanjut tentang cara menyiapkan alert callback, lihat Use a threshold-triggered alert callback. Catatan Klik Advanced Settings untuk mengonfigurasi parameter ini.
   Auto Scaling	Jika Anda mengaktifkan Auto Scaling, aturan penskalaan yang sesuai akan dipicu saat peringatan terjadi. Anda harus menetapkan Region, Auto Scaling Group, dan Auto Scaling Rule. Untuk informasi lebih lanjut tentang cara membuat grup Auto Scaling, lihat Configure a scaling group. Untuk informasi lebih lanjut tentang cara membuat aturan Auto Scaling, lihat Configure a scaling rule. Catatan Klik Advanced Settings untuk mengonfigurasi parameter ini.
   Simple Log Service	Jika Anda mengaktifkan Simple Log Service, informasi peringatan akan ditulis ke Simple Log Service saat peringatan terjadi. Anda harus menetapkan Region, Project, dan Logstore untuk Simple Log Service. Untuk informasi lebih lanjut tentang cara membuat Project dan Logstore, lihat Use LoongCollector to collect and analyze text logs on an ECS instance. Catatan Klik Advanced Settings untuk mengonfigurasi parameter ini.
   Simple Message Queue (formerly MNS) — topic	Jika Anda mengaktifkan Simple Message Queue (formerly MNS) — topic, informasi peringatan akan dikirim ke topik Message Service saat peringatan terjadi. Anda harus menetapkan wilayah dan topik untuk Message Service. Untuk informasi lebih lanjut tentang cara membuat topik, lihat Create a topic.
   Method for Handling No Data	Metode penanganan peringatan saat tidak tersedia data pemantauan. Nilai yang valid: Do not process (Default) Send no-data alert Consider as recovered Catatan Klik Advanced Settings untuk mengonfigurasi parameter ini.
   Tags	Label peringatan ditambahkan ke konten peringatan. Setiap label terdiri dari kunci dan nilai. Anda dapat menetapkan beberapa pasangan kunci-nilai.

7. Klik OK.

Bagaimana cara melihat berapa banyak penyimpanan yang digunakan untuk hot data dan cold data?

Masuk ke Konsol AnalyticDB for MySQL. Pada halaman Monitoring and Alerts, lihat metrik Hot Data Size dan Cold Data Size pada grafik Disk Space Used.

Bagaimana cara memeriksa informasi seperti ukuran tabel?

Masuk ke AnalyticDB for MySQL console. Pada halaman kluster Storage Analysis > Storage Overview, klik tab Table Storage Information untuk melihat informasi seperti ukuran tabel.

Mengapa penggunaan hot data pada halaman Monitoring Information lebih besar daripada total penggunaan data?

Kluster AnalyticDB for MySQL memiliki beberapa node penyimpanan. Metrik Disk Data Usage menunjukkan penggunaan maksimum dari satu node baca/tulis, sedangkan metrik Hot Data Usage menunjukkan total penggunaan dari semua node baca/tulis.

Mengapa rata-rata pemanfaatan CPU meningkat pada antarmuka pemantauan setelah kluster diubah dari mode reserved ke mode elastic?

Saat kluster C32 diubah dari mode reserved ke mode elastic, jumlah core pada satu node dikurangi menjadi 8. Secara default, pekerjaan BUILD menggunakan 3 core, sehingga menyebabkan rata-rata pemanfaatan CPU meningkat. Jika bisnis Anda tidak terpengaruh, Anda dapat mengabaikan peningkatan ini. Jika bisnis Anda terpengaruh, Anda dapat melakukan upgrade kluster atau Submit a ticket untuk dukungan teknis. Untuk informasi lebih lanjut tentang pekerjaan BUILD, lihat BUILD.

Waktu respons kueri yang lama ditampilkan pada halaman Monitoring Information, tetapi tidak ditemukan kueri SQL yang memakan waktu lama yang sesuai pada halaman Diagnostics and Optimization. Mengapa?

Query Response Time pada halaman Monitoring Information dan Total Duration pada halaman Diagnostics and Optimization dihitung dengan cara yang berbeda. Query Response Time mencakup waktu yang diperlukan untuk menyimpan cache set hasil, sedangkan Total Duration tidak. Oleh karena itu, jika suatu kueri mengembalikan set hasil yang besar, waktu caching dapat membuat Query Response Time lebih lama daripada Total Duration. Anda dapat menemukan kueri SQL yang memakan waktu lama pada halaman SQL Audit.

Bagian berikut menjelaskan komponen waktu dari kueri SQL:

Saat Anda mengirim kueri SQL ke AnalyticDB for MySQL, kueri tersebut melewati beberapa tahap, yang masing-masing berkontribusi terhadap total waktu respons. Pertama, kueri masuk ke antrian. Konkurensi kueri yang tinggi dapat menyebabkan waktu antrian yang lama. Setelah keluar dari antrian, kueri memasuki mesin eksekusi, yang mengurai pernyataan dan menghasilkan rencana eksekusi. Kemudian, subtugas dijalankan pada node penyimpanan dan komputasi. Terakhir, jika kueri mengembalikan set hasil yang besar, node frontend menyimpan cache hasil tersebut. Proses caching ini juga berkontribusi terhadap total waktu respons. Gambar berikut menunjukkan rincian waktu dari kueri SQL: