Memecahkan masalah kebijakan pemberitahuan

Halaman ini menjelaskan alasan beberapa kebijakan pemberitahuan mungkin berperilaku berbeda dari yang dimaksudkan, dan menawarkan kemungkinan upaya hukum untuk situasi tersebut.

Untuk mengetahui informasi tentang variabel yang dapat memengaruhi kebijakan pemberitahuan, misalnya dengan pilihan periode durasi, lihat Perilaku kebijakan pemberitahuan berbasis metrik.

Variabel untuk label metrik adalah null

Anda akan membuat kebijakan pemberitahuan dan menambahkan variabel untuk label metrik ke bagian dokumentasi. Anda berharap notifikasi akan menampilkan nilai variabel; tetapi, nilainya ditetapkan ke null.

Untuk mengatasi situasi ini, coba hal berikut:

Pastikan setelan agregasi untuk kebijakan pemberitahuan mempertahankan label yang ingin Anda tampilkan.

Misalnya, asumsikan Anda membuat kebijakan pemberitahuan yang memantau byte disk yang ditulis oleh instance VM. Anda ingin dokumentasi mencantumkan perangkat yang menyebabkan notifikasi, jadi Anda menambahkan hal berikut ke kolom dokumentasi: device: ${metric.label.device}.

Anda juga harus memastikan bahwa setelan agregasi Anda mempertahankan nilai label device. Anda dapat mempertahankan label ini dengan menetapkan fungsi agregasi ke none atau dengan memastikan bahwa pilihan pengelompokan menyertakan device.
Verifikasi sintaksis dan penerapan variabel. Untuk mengetahui informasi sintaksis, lihat Menganotasi pemberitahuan dengan dokumentasi yang ditentukan pengguna.

Misalnya, variabel log.extracted_label.KEY hanya didukung untuk notifikasi berbasis log. Variabel ini selalu dirender sebagai null saat kebijakan pemberitahuan memantau metrik, bahkan metrik berbasis log.

Kebijakan penggunaan disk menyebabkan insiden yang tidak terduga

Anda telah membuat kebijakan pemberitahuan untuk memantau kapasitas disk "bekas" di sistem Anda. Kebijakan ini memantau metrik agent.googleapis.com/disk/percent_used. Anda hanya akan diberi tahu saat penggunaan disk fisik melebihi batas yang Anda tetapkan dalam kondisi. Namun, kebijakan ini menimbulkan insiden saat penggunaan disk setiap disk fisik kurang dari batas maksimum.

Penyebab insiden tak terduga yang diketahui untuk kebijakan ini adalah bahwa kondisi tersebut tidak dibatasi untuk pemantauan disk fisik. Sebagai gantinya, kebijakan ini memantau semua disk, termasuk disk virtual seperti perangkat loopback. Jika disk virtual dibuat sedemikian rupa hingga pemakaiannya 100%, insiden untuk kebijakan akan dibuat.

Misalnya, pertimbangkan output perintah df Linux berikut, yang menunjukkan kapasitas disk yang tersedia di sistem file yang terpasang, untuk satu sistem:

$ df
/dev/root     9983232  2337708  7629140   24%  /
devtmpfs      2524080        0  2524080    0%  /dev
tmpfs         2528080        0  2528080    0%  /dev/shm
...
/dev/sda15     106858     3934   102924    4%  /boot/efi
/dev/loop0      56704    56704        0  100%  /snap/core18/1885
/dev/loop1     129536   129536        0  100%  /snap/google-cloud-sdk/150
...

Untuk sistem ini, kebijakan pemberitahuan penggunaan disk harus dikonfigurasi guna memfilter deret waktu untuk perangkat loopback /dev/loop0 dan /dev/loop1. Misalnya, Anda dapat menambahkan filter device !=~ ^/dev/loop.*, yang mengecualikan semua deret waktu yang label device-nya tidak cocok dengan ekspresi reguler ^/dev/loop.*.

Kebijakan waktu beroperasi tidak membuat pemberitahuan yang diharapkan

Anda ingin diberi tahu saat virtual machine (VM) dimulai ulang atau dimatikan, sehingga Anda membuat kebijakan pemberitahuan yang memantau metrik compute.googleapis.com/instance/uptime. Anda membuat dan mengonfigurasi kondisi untuk menghasilkan insiden saat tidak ada data metrik. Anda tidak menentukan kondisi menggunakan Bahasa Kueri Monitoring (MQL)¹. Anda tidak akan diberi tahu saat virtual machine (VM) dimulai ulang atau dimatikan.

Kebijakan pemberitahuan ini hanya memantau deret waktu untuk instance VM Compute Engine yang ada dalam status RUNNING. Deret waktu untuk VM yang ada dalam status lain, seperti STOPPED atau DELETED, difilter sebelum kondisinya dievaluasi. Karena perilaku ini, Anda tidak dapat menggunakan kebijakan pemberitahuan dengan kondisi pemberitahuan yang tidak ada metrik untuk menentukan apakah instance VM sedang berjalan atau tidak. Untuk mengetahui informasi tentang status instance VM, lihat Siklus proses instance VM.

Untuk mengatasi masalah ini, buat kebijakan pemberitahuan untuk memantau pemeriksaan uptime. Untuk endpoint pribadi, gunakan cek uptime pribadi.

Alternatif yang memungkinkan untuk pemberitahuan cek uptime adalah dengan menggunakan kebijakan pemberitahuan yang memantau tidak adanya data. Sebaiknya Anda memberi tahu cek uptime, bukan tidak adanya data: pemberitahuan ketidakhadiran dapat menghasilkan positif palsu jika ada masalah sementara dengan ketersediaan data Monitoring.

Namun, jika penggunaan cek uptime tidak memungkinkan, Anda dapat membuat kebijakan pemberitahuan dengan MQL yang memberi tahu Anda bahwa VM telah dinonaktifkan. Kondisi yang ditentukan MQL tidak memfilter data deret waktu terlebih dahulu berdasarkan status instance VM. Karena MQL tidak memfilter data berdasarkan status VM, Anda dapat menggunakannya untuk mendeteksi tidak adanya data dari VM yang telah dinonaktifkan.

Pertimbangkan kondisi MQL berikut yang memantau metrik compute.googleapis.com/instance/cpu/utilization:

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
|absent_for 3m

Jika VM yang dipantau oleh kondisi ini dinonaktifkan, tiga menit kemudian, insiden akan dihasilkan dan notifikasi dikirim. Nilai absent_for harus berdurasi minimal tiga menit.

Untuk informasi selengkapnya tentang MQL, lihat Kebijakan pemberitahuan dengan MQL.

¹: MQL adalah bahasa berbasis teks ekspresif yang dapat digunakan dengan panggilan Cloud Monitoring API dan di konsol Google Cloud. Untuk mengonfigurasi kondisi dengan MQL saat menggunakan Konsol Google Cloud, Anda harus menggunakan editor kode.

Kebijakan jumlah permintaan tidak membuat pemberitahuan yang diharapkan

Anda ingin memantau jumlah permintaan yang telah selesai. Anda membuat kebijakan pemberitahuan yang memantau yang memantau metrik serviceruntime.googleapis.com/api/request_count, tetapi Anda tidak akan diberi tahu saat jumlah permintaan melebihi nilai minimum yang Anda konfigurasikan.

Periode perataan maksimum untuk metrik jumlah permintaan adalah 7 jam 30 menit.

Untuk mengatasi masalah ini, periksa nilai periode penyelarasan dalam kebijakan pemberitahuan Anda. Jika nilai ini lebih panjang dari nilai maksimum untuk metrik ini, kurangi periode perataan sehingga tidak lebih dari 7 jam 30 menit.

Penyebab umum insiden anomali

Anda membuat kebijakan pemberitahuan dan kebijakan tersebut muncul sebelum waktunya atau salah membuat insiden.

Ada berbagai alasan mengapa Anda mungkin menerima notifikasi insiden yang tampaknya tidak benar:

Jika ada kesenjangan data, terutama untuk kebijakan pemberitahuan yang tidak memiliki metrik atau kondisi nilai minimum "kurang dari", insiden yang tampak tidak wajar dapat dibuat. Terkadang insiden tidak menunjukkan kesenjangan data, dan terkadang kesenjangan data dikoreksi secara otomatis:
- Dalam diagram, misalnya, celah mungkin tidak muncul karena nilai untuk data yang hilang diinterpolasi. Bahkan jika data tidak ada selama beberapa menit, diagram menghubungkan titik-titik yang hilang untuk kontinuitas visual. Kesenjangan dalam data yang mendasari mungkin cukup bagi kebijakan pemberitahuan untuk membuat insiden.
- Poin dalam metrik berbasis log dapat diterima terlambat dan diisi ulang, hingga 10 menit sebelumnya. Perilaku pengisian ulang akan secara efektif memperbaiki kesenjangan; celah akan diisi saat data akhirnya tiba. Jadi, celah dalam metrik berbasis log yang tidak dapat dilihat lagi mungkin telah menyebabkan kebijakan pemberitahuan menimbulkan insiden.
Absensi metrik dan kondisi nilai minimum "kurang dari" dievaluasi secara real time, dengan sedikit penundaan kueri. Status kondisi dapat berubah antara saat dievaluasi dan saat insiden terkait terlihat di Monitoring.
Kondisi yang dikonfigurasi untuk membuat insiden pada satu ukuran dapat menyebabkan insiden yang tampak prematur atau salah. Untuk mencegah situasi ini, pastikan beberapa pengukuran diperlukan sebelum insiden dibuat dengan menetapkan kolom durasi suatu kondisi agar lebih dari dua kali lipat frekuensi sampling metrik.

Misalnya, jika metrik diambil sampelnya setiap 60 detik, tetapkan durasi setidaknya 3 menit. Jika Anda menetapkan kolom durasi ke nilai terbaru, atau yang setara dengan 0 detik, satu pengukuran dapat menyebabkan dibuatnya insiden.
Saat kondisi kebijakan pemberitahuan diedit, diperlukan waktu beberapa menit agar perubahan diterapkan melalui infrastruktur pemberitahuan. Selama jangka waktu ini, Anda mungkin menerima notifikasi insiden yang memenuhi kondisi kebijakan pemberitahuan awal.
Saat data deret waktu tiba, perlu waktu hingga satu menit agar data diterapkan ke seluruh infrastruktur pemberitahuan. Saat periode penyelarasan ditetapkan ke satu menit atau ke sampel terbaru, latensi propagasi mungkin akan memunculkan bahwa kebijakan pemberitahuan dipicu dengan tidak benar. Untuk mengurangi kemungkinan situasi ini, gunakan periode penyelarasan minimal lima menit.

Insiden tidak ditutup saat data berhenti tiba

Anda mengikuti panduan dalam Data metrik parsial dan mengonfigurasi kebijakan pemberitahuan untuk menutup insiden saat data tidak lagi masuk. Dalam beberapa kasus, data berhenti tiba, tetapi insiden terbuka tidak otomatis ditutup.

Jika resource pokok yang dipantau oleh kebijakan pemberitahuan berisi label metadata.system_labels.state, dan jika kebijakan tersebut tidak ditulis dengan Bahasa Kueri Monitoring, Monitoring dapat menentukan status resource. Jika status resource diketahui dinonaktifkan, Monitoring tidak akan secara otomatis menutup insiden saat data berhenti tiba. Namun, Anda dapat menutup insiden ini secara manual.

Kebijakan multi-kondisi membuat beberapa notifikasi

Anda telah membuat kebijakan pemberitahuan yang berisi beberapa kondisi, dan menggabungkan kondisi tersebut dengan AND yang logis. Anda akan menerima satu notifikasi dan satu insiden yang dibuat saat semua kondisi terpenuhi. Namun, Anda akan menerima beberapa notifikasi dan melihat bahwa beberapa insiden dibuat.

Monitoring mengirimkan notifikasi dan membuat insiden untuk setiap deret waktu yang menyebabkan kondisi terpenuhi. Oleh karena itu, jika Anda memiliki kebijakan pemberitahuan dengan beberapa kondisi, Anda berpotensi menerima satu notifikasi dan insiden untuk setiap deret waktu yang menyebabkan kondisi yang digabungkan terpenuhi.

Misalnya, Anda memiliki kebijakan pemberitahuan dengan dua kondisi, dengan setiap kondisi memantau 3 deret waktu. Kebijakan ini hanya mengirimkan notifikasi jika kedua kondisi terpenuhi. Jika kondisi kebijakan terpenuhi, Anda dapat menerima antara 2 (satu deret waktu terpenuhi dalam setiap kondisi) dan 6 (semua deret waktu terpenuhi dalam setiap kondisi).

Anda tidak dapat mengonfigurasi Monitoring untuk membuat satu insiden dan mengirim satu notifikasi.

Untuk informasi selengkapnya, lihat Notifikasi per insiden.

Tidak dapat melihat detail insiden karena kesalahan izin

Anda membuka halaman insiden di Konsol Google Cloud dan memilih insiden untuk ditampilkan. Anda akan membuka halaman detail. Namun, halaman detail gagal terbuka dan pesan "Izin ditolak" akan ditampilkan.

Untuk melihat semua detail insiden kecuali data metrik, pastikan Anda memiliki peran Identity and Access Management (IAM) untuk memantau Cloud Console Incident Viewer (roles/monitoring.cloudConsoleIncidentViewer) dan Stackdriver Accounts Viewer (roles/stackdriver.accounts.viewer).

Untuk melihat semua detail insiden, termasuk data metrik, dan dapat mengonfirmasi atau menutup insiden, pastikan Anda memiliki peran IAM Monitoring Viewer (roles/monitoring.viewer) dan Editor Insiden Konsol Cloud Monitoring (roles/monitoring.cloudConsoleIncidentEditor).

Peran khusus tidak dapat memberikan izin yang diperlukan untuk melihat detail insiden.

Insiden tidak dibuat saat kondisi terpenuhi

Anda telah membuat kebijakan pemberitahuan yang memiliki satu kondisi. Diagram pemberitahuan menunjukkan bahwa data yang dipantau melanggar kondisi, tetapi Anda tidak menerima notifikasi dan insiden tidak dibuat.

Jika salah satu kriteria berikut terpenuhi setelah kondisi kebijakan pemberitahuan terpenuhi, Monitoring tidak akan membuka insiden.

Kebijakan pemberitahuan akan ditunda.
Kebijakan pemberitahuan dinonaktifkan.
Kebijakan pemberitahuan telah mencapai jumlah maksimum insiden yang dapat dibuka secara bersamaan.
Status resource yang dipantau oleh kebijakan pemberitahuan diketahui telah dinonaktifkan. Monitoring dapat menentukan status resource jika resource berisi label metadata.system_labels.state dan saat kebijakan pemberitahuan tidak ditulis dengan Bahasa Kueri Monitoring.

Daftar detail insiden salah project

Anda akan menerima notifikasi, dan ringkasan kondisi berisi daftar project Google Cloud tempat insiden dibuat, yaitu project cakupannya. Namun, Anda memperkirakan insiden akan mencantumkan nama project Google Cloud yang menyimpan deret waktu yang menyebabkan Monitoring membuat insiden.

Opsi agregasi yang ditentukan dalam kondisi kebijakan pemberitahuan menentukan project Google Cloud yang direferensikan dalam notifikasi:

Saat opsi agregasi menghilangkan label yang menyimpan project ID, informasi insiden akan mencantumkan project pencakupan. Misalnya, jika Anda mengelompokkan data hanya berdasarkan zona, maka setelah pengelompokan, label yang menyimpan project ID akan dihapus.
Jika opsi agregasi mempertahankan label yang menyimpan project ID, notifikasi insiden akan menyertakan nama project Google Cloud yang menyimpan deret waktu yang menyebabkan insiden terjadi. Untuk mempertahankan label project ID, sertakan label project_id di kolom pengelompokan, atau jangan kelompokkan deret waktu.

Tidak dapat menutup insiden secara manual

Anda menerima notifikasi insiden di sistem. Anda membuka halaman detail insiden dan mengklik Tutup insiden. Anda memperkirakan insiden itu akan ditutup; tetapi, Anda menerima pesan error:

Unable to close incident with active conditions.

Anda hanya dapat menutup insiden jika tidak ada pengamatan yang dilakukan pada periode pemberitahuan terbaru. Periode pemberitahuan, yang biasanya memiliki nilai default 5 menit, ditetapkan sebagai bagian dari kondisi kebijakan pemberitahuan dan dapat dikonfigurasi. Pesan error sebelumnya menunjukkan bahwa data telah diterima dalam periode pemberitahuan.

Error berikut terjadi saat insiden tidak dapat ditutup karena error internal:

Unable to close incident. Please try again in a few minutes.

Jika melihat pesan error sebelumnya, Anda dapat mencoba kembali operasi tutup tersebut atau mengizinkan Monitoring untuk menutup insiden secara otomatis.

Untuk informasi selengkapnya, lihat Mengelola insiden.

Notifikasi tidak diterima

Anda mengonfigurasi saluran notifikasi dan berharap mendapatkan notifikasi saat insiden terjadi. Anda tidak menerima notifikasi apa pun.

Untuk mengetahui informasi cara menyelesaikan masalah terkait webhook dan notifikasi Pub/Sub, lihat bagian berikut dalam dokumen ini:

Notifikasi webhook tidak diterima
Notifikasi Pub/Sub tidak diterima

Untuk mengumpulkan informasi tentang penyebab kegagalan, lakukan hal berikut:

Di panel navigasi konsol Google Cloud, pilih Logging, lalu pilih Logs Explorer:
Buka Logs Explorer
Pilih project Google Cloud yang sesuai.
Buat kueri log untuk peristiwa saluran notifikasi:
1. Luaskan menu Log name, lalu pilih notification_channel_events.
2. Luaskan menu Keparahan dan pilih Error.
3. Opsional: Untuk memilih rentang waktu kustom, gunakan pemilih rentang waktu.
4. Klik Jalankan kueri.
Langkah sebelumnya akan membuat kueri berikut:
```
logName="projects/PROJECT_ID/logs/monitoring.googleapis.com%2Fnotification_channel_events"
severity=ERROR
```
Informasi kegagalan biasanya disertakan di baris ringkasan dan di kolom jsonPayload.

Baris ringkasan dan kolom jsonPayload biasanya berisi informasi kegagalan. Misalnya, saat terjadi error gateway, baris ringkasan akan menyertakan "failed dengan 502 Bad Gateway".

Tidak ada data baru setelah perubahan pada definisi metrik

Anda mengubah definisi metrik yang ditentukan pengguna, misalnya, dengan mengubah filter yang digunakan dalam metrik berbasis log, dan kebijakan pemberitahuan tidak mencerminkan perubahan yang Anda buat pada definisi metrik.

Untuk mengatasi masalah ini, perbarui paksa kebijakan pemberitahuan dengan mengedit nama tampilan kebijakan.

Notifikasi Webhook yang dikirim ke Google Chat tidak diterima

Anda mengonfigurasi saluran notifikasi webhook di Monitoring, lalu mengonfigurasi webhook untuk dikirim ke Google Chat. Namun, Anda tidak menerima notifikasi atau Anda menerima error 400 Bad Request.

Untuk mengatasi masalah ini, konfigurasikan saluran notifikasi Pub/Sub di Monitoring, lalu konfigurasikan layanan Cloud Run untuk mengonversi pesan Pub/Sub menjadi format yang diharapkan Chat, lalu mengirimkan notifikasi ke Google Chat. Untuk contoh konfigurasi ini, lihat Membuat notifikasi kustom dengan Cloud Monitoring dan Cloud Run.

Notifikasi webhook tidak diterima

Anda mengonfigurasi saluran notifikasi webhook dan ingin menerima notifikasi saat terjadi insiden. Anda tidak menerima notifikasi apa pun.

Endpoint pribadi

Anda tidak dapat menggunakan webhook untuk notifikasi kecuali jika endpoint bersifat publik.

Untuk mengatasi situasi ini, gunakan notifikasi Pub/Sub yang dikombinasikan dengan langganan pull ke topik notifikasi tersebut.

Saat Anda mengonfigurasi saluran notifikasi Pub/Sub, notifikasi insiden dikirim ke antrean Pub/Sub yang memiliki kontrol Identity and Access Management. Layanan apa pun yang dapat membuat kueri atau memproses topik Pub/Sub dapat menggunakan notifikasi ini. Misalnya, aplikasi yang berjalan di virtual machine App Engine, Cloud Run, atau Compute Engine dapat menggunakan notifikasi ini.

Jika Anda menggunakan langganan pull, permintaan akan dikirim ke Google yang menunggu pesan tiba. Langganan ini memerlukan akses ke Google, tetapi tidak memerlukan aturan untuk firewall atau akses masuk.

Endpoint publik

Untuk mengidentifikasi alasan pengiriman gagal, periksa informasi kegagalan pada entri log Cloud Logging Anda.

Misalnya, Anda dapat mencari entri log untuk resource saluran notifikasi menggunakan Logs Explorer, dengan filter seperti berikut:

resource.type="stackdriver_notification_channel"

Notifikasi Pub/Sub tidak diterima

Anda mengonfigurasi saluran notifikasi Pub/Sub, tetapi tidak menerima notifikasi apa pun.

Untuk mengatasi kondisi ini, coba langkah berikut:

Pastikan akun layanan notifikasi ada. Notifikasi tidak akan dikirim saat akun layanan telah dihapus.

Untuk memverifikasi bahwa akun layanan ada, lakukan hal berikut:
1. Pada panel navigasi Konsol Google Cloud, pilih IAM:
  Buka IAM
2. Telusuri akun layanan yang memiliki konvensi penamaan berikut:
```
service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
```
  Jika akun layanan ini tidak tercantum, pilih Sertakan pemberian peran yang disediakan Google.
Jika akun layanan notifikasi tidak ada, Anda harus memulai proses pembuatan saluran notifikasi Pub/Sub agar Monitoring dapat membuat akun layanan:
1. Di panel navigasi konsol Google Cloud, pilih Monitoring, lalu pilih Alerting:
  Buka Alerting
2. Klik Edit saluran notifikasi.
3. Di bagian Pub/Sub, klik Add new.
  
  Monitoring membuat akun layanan notifikasi ketika belum ada. Dialog Create Pub/Sub Channel menampilkan nama akun layanan notifikasi.
  
  Catatan: Anda tidak perlu selesai membuat saluran notifikasi Pub/Sub agar Monitoring dapat membuat akun layanan notifikasi.
4. Jika tidak ingin menambahkan saluran notifikasi, klik Batal. Jika tidak, selesaikan pembuatan saluran notifikasi dan klik Tambahkan saluran.
5. Berikan izin kepada akun layanan untuk memublikasikan topik Pub/Sub:
  1. Di tab browser baru, buka dokumen Buat saluran notifikasi.
  2. Pilih tab Pub/Sub, lalu ikuti langkah-langkah di bagian Authorize service account pada halaman tersebut.
Pastikan akun layanan notifikasi telah diizinkan untuk mengirim notifikasi terkait topik Pub/Sub yang diminati.

Untuk melihat izin akun layanan, Anda dapat menggunakan Google Cloud Console atau perintah Google Cloud CLI:
- Halaman IAM di Google Cloud Console mencantumkan peran untuk setiap akun layanan.
- Halaman Topics Pub/Sub di Konsol Google Cloud mencantumkan setiap topik. Saat Anda memilih topik, tab Izin mencantumkan peran yang diberikan ke akun layanan.
- Untuk menampilkan daftar semua akun layanan dan perannya, jalankan perintah Google Cloud CLI berikut:
```
gcloud projects get-iam-policy PROJECT_ID
```
  Berikut adalah respons sebagian untuk perintah ini:
```
    serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
       role: roles/monitoring.notificationServiceAgent
     - members:
       [...]
       role: roles/owner
     - members:
       - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
       role: roles/pubsub.publisher
```
  Respons perintah hanya menyertakan peran, tidak mencakup otorisasi per topik.
- Untuk menampilkan daftar binding IAM untuk topik tertentu, jalankan perintah berikut:
```
gcloud pubsub topics get-iam-policy TOPIC
```
  Berikut adalah contoh respons untuk perintah ini:
```
    bindings:
    - members:
      - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
      role: roles/pubsub.publisher
    etag: BwXPRb5WDPI=
    version: 1
```
Untuk informasi tentang cara memberikan otorisasi pada akun layanan notifikasi, lihat Mengizinkan akun layanan.