CloudMonitor menyediakan aturan peringatan berbasis ambang dinamis untuk memantau metrik sumber daya Alibaba Cloud. Aturan ini secara otomatis menyesuaikan data metrik historis dan menampilkan batas ambang, membantu mengidentifikasi anomali seperti peningkatan atau penurunan mendadak pada nilai metrik serta memastikan stabilitas bisnis.
Apa itu ambang dinamis?
Ambang dinamis menggunakan algoritma pembelajaran mesin untuk mengidentifikasi karakteristik pola data historis seperti periodisitas, tren, dan fluktuasi metrik. Ambang ini mengintegrasikan metrik layanan cloud tertentu untuk secara otomatis menghitung batas ambang atas dan bawah setiap instance.
Batasan
Fitur peringatan berbasis ambang dinamis saat ini dalam pratinjau undangan. Untuk menggunakannya, ajukan tiket.
Skenario
Karakteristik statistik metrik sumber daya cloud, seperti penggunaan sumber daya, perubahan periodik, dan fluktuasi varians, bervariasi di berbagai skenario bisnis. Misalnya, jika lalu lintas tinggi di siang hari dan rendah di malam hari, metrik seperti lalu lintas gateway dan akumulasi pesan ApsaraMQ dari Instance ECS atau nama domain CDN Alibaba Cloud akan menunjukkan nilai puncak dan lembah sesuai dengan pola tersebut. Layanan intensif I/O dan tugas komputasi intensif juga menyebabkan penggunaan CPU atau ambang beban (load.1m, load.5m, dan load.15m) yang berbeda pada instance ECS.
Ambang tetap pada aturan peringatan berbasis satu metrik tidak cocok untuk skenario bisnis kompleks. Hal ini sering menyebabkan peringatan konstan pada instance dengan beban tinggi, sementara pengecualian pada instance dengan beban rendah mungkin tidak mencapai ambang peringatan atau terdeteksi setelah lebih dari setengah jam. Untuk meningkatkan pengalaman peringatan dan mempersingkat waktu deteksi pengecualian, CloudMonitor menyediakan fitur peringatan berbasis ambang dinamis. Algoritma inti fitur ini mengidentifikasi karakteristik historis pola data seperti periodisitas, fluktuasi, dan penggunaan metrik, serta mengintegrasikan metrik layanan cloud tertentu untuk menghasilkan batas ambang atas dan bawah setiap instance. Fitur ini memungkinkan visualisasi efek ambang dan menyediakan penyetelan parameter sensitivitas melalui pendekatan white boxing.
Manfaat
Dibandingkan dengan aturan peringatan berbasis satu metrik atau multi-metrik, aturan peringatan berbasis ambang dinamis menawarkan keuntungan berikut:
Penghilangan derau peringatan
Fitur peringatan berbasis ambang dinamis mengumpulkan data metrik setiap instance dan menggunakan model seperti dekomposisi deret waktu kuat serta prediksi untuk menyesuaikan penggunaan data dan perubahan bisnis pada metrik instance yang berbeda. Fitur ini juga menyaring kebisingan abnormal berdasarkan pengelompokan peringatan historis dan pencocokan kesamaan, meningkatkan akurasi peringatan. Fitur ini cocok untuk skenario berikut:
Berbagai Tingkat Penggunaan Metrik Instance
Misalnya, sebuah perusahaan game menggunakan instance ECS yang berbeda untuk komputasi offline dan layanan online. Template peringatan yang sama sering digunakan, sehingga peringatan dipicu ketika metrik seperti penggunaan CPU, beban, atau memori melebihi 80%. Akibatnya, peringatan terpicu secara tak terduga pada instance dengan beban tinggi.
Peningkatan Beban Akibat Tugas Terjadwal
Misalnya, seorang pengguna menggunakan ApsaraDB RDS untuk penyimpanan dan menetapkan tugas terjadwal untuk membersihkan data historis yang dihasilkan 30 hari lalu pada 00:00:00 setiap hari. Saat tugas berjalan, penggunaan IOPS ApsaraDB RDS mendekati 100% secara instan dan memicu peringatan, meskipun penggunaan IOPS dengan cepat kembali normal. Positif palsu terjadi secara terjadwal setiap hari.
Dalam skenario tersebut, fitur peringatan berbasis ambang dinamis dapat mengurangi tingkat positif palsu hingga 80%-90%, memungkinkan fokus pada pengecualian bisnis dan meningkatkan pengalaman pemantauan serta O&M.
Pendeteksian pengecualian otomatis
Pengecualian pada metrik instance layanan cloud biasanya disebabkan oleh perubahan pada layanan hulu dan hilir, lalu lintas, atau aplikasi dan data yang diterapkan pada instance layanan cloud. Fitur peringatan berbasis ambang dinamis dapat mendeteksi pengecualian layanan dengan cepat, seperti koneksi Server Load Balancer (SLB) yang menghadap Internet dan akumulasi pesan besar dari ApsaraMQ. Anda dapat menggunakan fitur ini untuk mendeteksi pengecualian pada metrik ECS dari sumber daya dasar dan menemukan penyebab utama pengecualian bisnis.
Saat mengonfigurasi aturan peringatan berbasis satu metrik atau multi-metrik, ambang tinggi sering ditetapkan untuk mencegah positif palsu berlebihan. Namun, aturan tersebut berlaku untuk grup aplikasi atau semua sumber daya, sehingga parameter tidak dapat disesuaikan untuk layanan atau instance tertentu. Aturan peringatan berbasis ambang dinamis dapat mendeteksi peningkatan atau penurunan mendadak pada nilai metrik dengan cepat dan akurat, cocok untuk skenario berikut:
Pendeteksian Pengecualian Metrik Setelah Perubahan Kode
Misalnya, setelah pengembang mengubah kode aplikasi, terjadi kebocoran memori yang mengakibatkan pengumpulan sampah penuh dan peningkatan signifikan pada penggunaan CPU. Namun, peringatan berbasis satu metrik untuk penggunaan CPU tinggi tidak dapat dipicu dalam kasus ini.
Peringatan Tepat Waktu Sebelum Layanan Menjadi Tidak Tersedia
Misalnya, jika lalu lintas layanan hulu meningkat secara tiba-tiba, aturan peringatan berbasis ambang dinamis dapat mendeteksi pengecualian dengan cepat dan memicu peringatan sebelum ambang penggunaan yang ditentukan dalam aturan peringatan berbasis satu metrik tercapai, mencegah layanan hilir menjadi tidak tersedia karena lalu lintas tinggi yang terus-menerus.
Dalam skenario bisnis tersebut, aturan peringatan berbasis ambang dinamis dapat memantau metrik inti layanan cloud. Dengan cara ini, CloudMonitor dapat mengingat kembali 85% atau lebih masalah dan titik kegagalan dalam waktu 3 menit setelah pengecualian metrik terjadi.
Pengurangan biaya konfigurasi dan pemeliharaan ambang
Anda tidak perlu menentukan nilai untuk ambang dinamis. Cukup buat aturan peringatan berbasis ambang dinamis dan pilih kondisi peringatan yang sesuai (di luar batas, lebih tinggi dari batas atas, atau di bawah batas bawah) untuk menyelesaikan pengaturan ambang. Fitur ini secara signifikan mengurangi biaya konfigurasi dan pemeliharaan, cocok untuk skenario berikut:
Pengaturan Ambang Spesifik
Saat mengonfigurasi aturan peringatan untuk metrik tanpa batas atas fisik, seperti lalu lintas, lebar pita jaringan, dan permintaan per detik (QPS) dari instance ECS, nilai metrik dapat bervariasi secara signifikan, sehingga sulit menentukan nilai umum yang sesuai. Jika nilai aktual metrik berubah dengan perubahan O&M atau bisnis, ambang terkait harus dimodifikasi untuk mencegah positif palsu atau negatif palsu.
Konfigurasi Beberapa Aturan untuk Memicu Peringatan dengan Ambang Berbeda pada Periode Waktu Berbeda
Jika beberapa metrik menunjukkan nilai puncak dan lembah signifikan pada periode waktu berbeda, Anda perlu mengonfigurasi beberapa aturan dan menentukan waktu efektif yang berbeda.
Praktik Terbaik
Penghilangan derau peringatan untuk sumber daya dasar ECS
Seorang pengguna menggunakan instance ECS untuk rendering offline dan instance ECS lainnya untuk dukungan bisnis online. Penggunaan memori instance ECS untuk rendering offline secara signifikan lebih tinggi daripada instance ECS lainnya untuk tugas online. Saat mengonfigurasi aturan peringatan berbasis satu metrik dengan ambang penggunaan memori lebih besar dari 80%, peringatan konstan dipicu pada instance ECS untuk rendering offline selama seminggu, menghasilkan total 200 peringatan. Setelah mengonfigurasi aturan peringatan berbasis ambang dinamis, kurang dari lima peringatan dihasilkan dalam seminggu, dengan tingkat konvergensi positif palsu mencapai 95%.
Praktik terbaik penghilangan derau peringatan berlaku untuk metrik lain selain penggunaan memori instance ECS. Kami merekomendasikan mengonfigurasi aturan peringatan berbasis ambang dinamis untuk metrik yang dijelaskan dalam tabel berikut.
Pengecualian umum | Penyebab mungkin | Metrik | Kondisi peringatan |
Beban terlalu tinggi, beban berfluktuasi secara signifikan, atau beban puncak berlangsung lama. | Sumber daya sistem tidak mencukupi, proses mengalami pengecualian (seperti loop tanpa akhir dan kebocoran memori), jumlah proses meningkat secara tiba-tiba, atau sejumlah besar permintaan atau operasi pemrosesan data dihasilkan secara tiba-tiba oleh beberapa aplikasi atau layanan sistem. |
| Lebih tinggi dari batas atas |
Jumlah permintaan meningkat secara tiba-tiba, jumlah permintaan berfluktuasi secara signifikan, atau jumlah permintaan puncak berlangsung lama. | Pengecualian terjadi pada aplikasi atau layanan sistem. Kinerja I/O disk tidak mencukupi, atau kapasitas disk tidak mencukupi. Sejumlah besar operasi baca atau tulis disk dilakukan pada beberapa aplikasi atau layanan. |
| Di luar batas |
Jumlah koneksi terlalu tinggi, jumlah koneksi berfluktuasi secara signifikan, atau jumlah koneksi puncak berlangsung lama. | Beban sistem terlalu tinggi, pool koneksi TCP tidak mencukupi, pengecualian terjadi pada aplikasi atau layanan, atau sejumlah besar operasi koneksi TCP dilakukan pada waktu tertentu pada beberapa aplikasi atau layanan. | (Agent)network.tcp.connection_state | Di luar batas |
Konvergensi positif palsu yang disebabkan oleh tugas terjadwal ApsaraDB RDS
Saat tugas terjadwal yang ditentukan pengguna dieksekusi untuk membersihkan data historis di awal pagi setiap hari, QPS database ApsaraDB RDS for MySQL melonjak secara instan. Aturan peringatan berbasis satu metrik memicu positif palsu saat tugas terjadwal dieksekusi. Setelah mengubah aturan peringatan menjadi aturan berbasis ambang dinamis, positif palsu terjadwal tidak lagi terjadi.
Praktik terbaik konvergensi positif palsu akibat tugas terjadwal berlaku untuk metrik lain selain QPS ApsaraDB RDS for MySQL. Kami merekomendasikan mengonfigurasi aturan peringatan berbasis ambang dinamis untuk metrik yang dijelaskan dalam tabel berikut.
Pengecualian umum | Penyebab mungkin | Metrik | Kondisi peringatan |
Kinerja instance ApsaraDB RDS berfluktuasi secara signifikan. | Beban sistem terlalu tinggi, atau pool koneksi database tidak mencukupi. Sejumlah besar kueri dilakukan pada waktu tertentu pada aplikasi atau layanan. |
| Lebih tinggi dari batas atas |
Pendeteksian pengecualian pada OSS atau CDN
Object Storage Service (OSS) dan Alibaba Cloud CDN (CDN) berfungsi sebagai komponen optimasi penyimpanan dan pengiriman konten yang dipercepat dari layanan. Pengecualian pada OSS dan CDN secara langsung memengaruhi ketersediaan fitur layanan. Namun, pemantauan ketersediaan aplikasi umumnya tidak mencakup ketersediaan OSS dan CDN, sehingga peringatan mungkin tidak dipicu saat pengecualian terjadi.
Misalnya, jika BPS CDN turun menjadi nol, fitur peringatan berbasis ambang dinamis dapat mendeteksi dan mengingat kembali pengecualian tepat waktu serta mengirimkan notifikasi peringatan.
Aturan peringatan berbasis ambang dinamis dapat digunakan untuk mencakup peringatan pemantauan OSS dan CDN dengan cepat serta mendeteksi pengecualian sebelum layanan menjadi tidak tersedia. Kami merekomendasikan mengonfigurasi aturan peringatan berbasis ambang dinamis untuk metrik yang dijelaskan dalam tabel berikut.
Layanan Alibaba Cloud | Pengecualian umum | Penyebab mungkin | Metrik | Kondisi peringatan |
OSS | Jumlah permintaan sukses menurun secara tiba-tiba, atau jumlah kesalahan permintaan meningkat secara tiba-tiba. | Koneksi jaringan tidak stabil atau mengalami pengecualian. Anda tidak memiliki izin pada objek OSS atau objek OSS tidak ada. Kesalahan terjadi ketika operasi API dipanggil. |
| Di bawah batas bawah |
| Lebih tinggi dari batas atas | |||
Lalu lintas meningkat secara tiba-tiba, lalu lintas menurun secara tiba-tiba, lalu lintas berfluktuasi secara signifikan, atau lalu lintas puncak berlangsung lama. | Koneksi jaringan tidak stabil atau mengalami pengecualian. Sejumlah besar permintaan dikirim oleh beberapa aplikasi atau layanan pada waktu tertentu. |
| Di luar batas | |
CDN | QPS meningkat secara tiba-tiba, QPS menurun secara tiba-tiba, QPS berfluktuasi secara signifikan, QPS puncak berlangsung lama, atau waktu respons meningkat. | Beban sistem terlalu tinggi, cache tidak mencukupi, dan node CDN tidak mencukupi. Jumlah kunjungan pengguna meningkat secara tiba-tiba. Sejumlah besar permintaan dicoba ulang setelah permintaan gagal. | BPS_isp QPS_isp InternetOut | Di luar batas |
rt | Lebih tinggi dari batas atas | |||
Rasio hit menurun. | Permintaan dialihkan ke server asal dan percepatan gagal. | hitRate | Di bawah batas bawah |
Konfigurasi O&M yang disederhanakan untuk ApsaraMQ for Kafka
Beberapa metrik ApsaraMQ for Kafka terkait dengan layanan, seperti jumlah kali pesan dikirim pada instance dan jumlah pesan yang dikonsumsi pada instance. Selain itu, konsumsi pesan bervariasi secara signifikan di antara grup dan topik, sehingga sulit menetapkan ambang umum untuk memantau antrian pesan untuk layanan berbeda. Ini dapat menyebabkan kesalahan seperti negatif palsu dan deteksi tertunda.
Dengan kemampuan peringatan otomatis, fitur peringatan berbasis ambang dinamis dapat menyederhanakan konfigurasi aturan peringatan dan mengurangi biaya pemeliharaan. Fitur ini dapat mendeteksi pengecualian dalam waktu 2 hingga 3 menit, secara efektif mengurangi mean time to repair (MTTR) layanan.
Misalnya, jika jumlah pesan terakumulasi untuk ApsaraMQ for Kafka meningkat secara tiba-tiba, fitur ini mengingat kembali pengecualian dan mengirimkan notifikasi peringatan.
Kami merekomendasikan mengonfigurasi aturan peringatan berbasis ambang dinamis untuk metrik ApsaraMQ for Kafka yang tercantum dalam tabel berikut.
Pengecualian umum | Penyebab mungkin | Metrik | Kondisi peringatan |
Lalu lintas meningkat atau menurun secara tiba-tiba. | Banyak pengguna mengakses aplikasi atau melakukan sejumlah besar operasi transmisi data. Pengecualian terjadi pada aplikasi atau lebar pita jaringan dikonsumsi oleh program jahat. |
| Di luar batas |
Pesan terakumulasi. | Sumber daya sistem tidak mencukupi, proses mengalami pengecualian (seperti loop tanpa akhir dan kebocoran memori), jumlah proses meningkat secara tiba-tiba, atau sejumlah besar permintaan atau operasi pemrosesan data dihasilkan secara tiba-tiba oleh beberapa aplikasi atau layanan sistem. |
| Lebih tinggi dari batas atas |
Jumlah koneksi terlalu tinggi, jumlah koneksi berfluktuasi secara signifikan, atau jumlah koneksi puncak berlangsung lama. | Beban sistem terlalu tinggi, pool koneksi TCP tidak mencukupi, pengecualian terjadi pada aplikasi atau layanan, atau sejumlah besar operasi koneksi TCP dilakukan pada waktu tertentu pada beberapa aplikasi atau layanan. |
| Di luar batas |