Memecahkan masalah kebijakan pemberitahuan

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

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

Kebijakan pemanfaatan disk menyebabkan insiden yang tidak terduga

Anda 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 ambang batas.

Penyebab umum insiden tak terduga untuk kebijakan ini adalah kondisi tersebut tidak dibatasi pada pemantauan disk fisik. Sebagai gantinya, kebijakan ini akan memantau semua disk, termasuk disk virtual seperti perangkat loopback. Jika disk virtual dibuat sedemikian rupa sehingga penggunaannya adalah 100%, maka akan menyebabkan insiden untuk dibuat kebijakan.

Misalnya, perhatikan output dari 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 untuk 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 mendapatkan notifikasi saat virtual machine (VM) dimulai ulang atau dimatikan, jadi 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)1. 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 berada dalam status RUNNING. Deret waktu untuk VM yang berada dalam status lain, seperti STOPPED atau DELETED, difilter sebelum kondisinya dievaluasi. Karena perilaku ini, Anda tidak dapat menggunakan kebijakan pemberitahuan dengan kondisi pemberitahuan tidak ada metrik untuk menentukan apakah instance VM berjalan atau tidak. Untuk mengetahui informasi tentang status instance VM, baca Siklus proses instance VM.

Untuk mengatasi masalah ini, buat kebijakan pemberitahuan untuk memantau cek 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. Kami sangat merekomendasikan pemberitahuan tentang cek uptime, bukan tidak adanya data: pemberitahuan tidak ada dapat menghasilkan positif palsu jika ada masalah sementara terkait ketersediaan data Monitoring.

Namun, jika tidak dapat menggunakan cek uptime, 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 akan dikirim. Nilai absent_for harus setidaknya tiga menit.

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

1: 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 metrik serviceruntime.googleapis.com/api/request_count, tetapi Anda tidak akan diberi tahu saat jumlah permintaan melebihi nilai minimum yang dikonfigurasi.

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 nilainya lebih panjang dari nilai maksimum untuk metrik ini, kurangi periode penyelarasan sehingga tidak lebih dari 7 jam 30 menit.

Penyebab umum insiden anomali

Anda telah membuat kebijakan pemberitahuan dan kebijakan tersebut muncul sebelum waktunya atau membuat insiden secara tidak benar.

Ada berbagai alasan mengapa Anda menerima notifikasi insiden yang tampaknya salah:

  • Jika ada kesenjangan data, terutama untuk kebijakan pemberitahuan yang tidak memiliki metrik atau kondisi nilai minimum "kurang dari", insiden dapat dibuat yang tampak tidak wajar. Menentukan apakah ada kesenjangan dalam data mungkin tidak mudah. Terkadang celah tersamarkan, dan terkadang diperbaiki secara otomatis:

    • Misalnya, dalam diagram, celah mungkin terkabur karena nilai untuk data yang hilang diinterpolasi. Meskipun data selama beberapa menit hilang, diagram menghubungkan titik-titik yang hilang untuk kontinuitas visual. Kesenjangan dalam data pokok tersebut mungkin cukup bagi kebijakan pemberitahuan untuk membuat insiden.

    • Poin dalam metrik berbasis log dapat terlambat diterima dan diisi ulang, hingga 10 menit yang lalu. Perilaku pengisian ulang secara efektif memperbaiki celah; celah akan diisi saat data akhirnya tiba. Oleh karena itu, kesenjangan dalam metrik berbasis log yang tidak dapat dilihat lagi mungkin telah menyebabkan kebijakan pemberitahuan membuat insiden.

  • Ketiadaan metrik dan kondisi nilai minimum "kurang dari" dievaluasi secara real time, dengan sedikit penundaan kueri. Status kondisi dapat berubah antara saat kondisi dievaluasi dan saat insiden yang terkait terlihat di Monitoring.

  • Kondisi yang dikonfigurasi untuk membuat insiden pada satu tindakan dapat menyebabkan insiden yang tampak prematur atau salah. Untuk mencegah situasi ini, pastikan beberapa pengukuran diperlukan sebelum insiden dibuat dengan menetapkan kolom durasi kondisi agar lebih dari dua kali lipat frekuensi pengambilan sampel metrik.

    Misalnya, jika sebuah metrik diambil sampelnya setiap 60 detik, tetapkan durasi setidaknya ke 3 menit. Jika Anda menetapkan kolom durasi ke nilai terbaru, atau setara dengan 0 detik, satu pengukuran dapat menyebabkan insiden dibuat.

  • Saat kondisi kebijakan pemberitahuan diedit, diperlukan waktu beberapa menit agar perubahan diterapkan di seluruh infrastruktur pemberitahuan. Selama jangka waktu ini, Anda mungkin akan menerima notifikasi insiden yang memenuhi ketentuan kebijakan pemberitahuan asli.

  • Saat data deret waktu tiba, diperlukan waktu hingga satu menit agar data menyebar ke seluruh infrastruktur pemberitahuan. Saat periode penyelarasan ditetapkan ke satu menit atau ke sampel terbaru, latensi propagasi mungkin membuat kebijakan pemberitahuan tidak dipicu dengan benar. Untuk mengurangi kemungkinan situasi ini, gunakan periode penyelarasan minimal lima menit.

Insiden tidak ditutup saat data berhenti tiba

Anda dapat mengikuti panduan di bagian Data metrik parsial dan mengonfigurasi kebijakan pemberitahuan untuk menutup insiden saat data tidak lagi masuk. Pada 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 telah dinonaktifkan, Monitoring tidak akan otomatis menutup insiden saat data berhenti tiba. Namun, Anda dapat menutup insiden ini secara manual.

Kebijakan multikondisi membuat beberapa notifikasi

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

Jika kebijakan pemberitahuan berisi beberapa kondisi yang digabungkan oleh AND yang logis, jika kebijakan tersebut terpicu, maka untuk setiap deret waktu yang menghasilkan kondisi terpenuhi, kebijakan tersebut akan mengirimkan notifikasi dan membuat insiden. Misalnya, jika Anda memiliki kebijakan dengan dua kondisi dan setiap kondisi memantau satu deret waktu, dua insiden akan terbuka dan Anda akan menerima dua notifikasi.

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

Untuk informasi selengkapnya, lihat Notifikasi per insiden.

Tidak dapat melihat detail insiden karena error izin

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

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

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

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

Insiden tidak dibuat ketika 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 benar setelah kondisi kebijakan pemberitahuan terpicu, Cloud 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

Anda akan menerima notifikasi tentang pemberitahuan dan ringkasan kondisi mencantumkan project Google Cloud tempat pemberitahuan dibuat, yaitu project pencakupan. Namun, Anda diharapkan insiden untuk mencantumkan nama project Google Cloud yang menyimpan deret waktu yang menyebabkan insiden dipicu.

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

  • Saat opsi agregasi menghapus label yang menyimpan project ID, informasi insiden akan mencantumkan project pencakupan. Misalnya, jika Anda mengelompokkan data hanya berdasarkan zona, setelah pengelompokan dilakukan, 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 dipicu. Untuk mempertahankan label project ID, jangan mengelompokkan deret waktu atau menyertakan label project_id di kolom pengelompokan.

Tidak dapat menutup insiden secara manual

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

Unable to close incident with active conditions.

Anda hanya dapat menutup insiden jika tidak ada observasi yang masuk 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 atau membiarkan Monitoring menutup insiden secara otomatis.

Untuk informasi selengkapnya, lihat Mengelola insiden.

Notifikasi tidak diterima

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

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

Untuk mengumpulkan informasi tentang penyebab kegagalan, lakukan hal berikut:

  1. Pada panel navigasi Google Cloud Console, pilih Logging, lalu pilih Logs Explorer:

    Buka Logs Explorer

  2. Pilih project Google Cloud yang sesuai.
  3. Mengkueri log untuk peristiwa saluran notifikasi:

    1. Luaskan menu Log name, lalu pilih notification_channel_events.
    2. Luaskan menu Tingkat Keparahan dan pilih Error.
    3. Opsional: Untuk memilih rentang waktu kustom, gunakan pemilih rentang waktu.
    4. Klik Jalankan kueri.

    Langkah sebelumnya 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 menampilkan "failed dengan Gateway Bad 502".

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 secara paksa kebijakan pemberitahuan dengan mengedit nama tampilan kebijakan.

Notifikasi Webhook yang dikirim ke Google Chat tidak diterima

Anda mengonfigurasi saluran notifikasi webhook di Cloud 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 Cloud Monitoring, lalu konfigurasikan layanan Cloud Run untuk mengonversi pesan Pub/Sub menjadi formulir yang diharapkan Chat, lalu kirimkan notifikasi tersebut 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 pemberitahuan saat terjadi insiden. Anda tidak menerima notifikasi apa pun.

Endpoint pribadi

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

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

Saat Anda mengonfigurasi saluran notifikasi Pub/Sub, notifikasi insiden akan dikirim ke antrean Pub/Sub yang memiliki kontrol Identity and Access Management. Layanan apa pun yang dapat mengkueri, 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 untuk menunggu pesan tiba. Langganan ini memerlukan akses ke Google, tetapi tidak memerlukan aturan untuk firewall atau akses masuk.

Endpoint publik

Untuk mengidentifikasi alasan kegagalan pengiriman, 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 pemberitahuan apa pun.

Untuk mengatasi kondisi ini, coba langkah berikut:

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

    Untuk memverifikasi bahwa akun layanan sudah 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, seperti yang ditunjukkan di screenshot berikut:

      Pilih opsi Sertakan pemberian peran yang disediakan Google.

    Untuk membuat akun layanan notifikasi, lakukan hal berikut:

    1. Pada 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.

      Dialog Created Pub/Sub Channel menampilkan nama akun layanan yang dibuat Monitoring.

    4. Klik Cancel.

    5. Beri akun layanan izin untuk memublikasikan topik Pub/Sub seperti yang dijelaskan di Mengizinkan akun layanan.

  • Pastikan akun layanan notifikasi telah diizinkan untuk mengirim notifikasi terkait topik Pub/Sub yang diminati.

    Untuk melihat izin akun layanan, Anda dapat menggunakan konsol Google Cloud 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 mengizinkan akun layanan notifikasi, lihat Mengizinkan akun layanan.