Menganotasi notifikasi dengan label

Dokumen ini menjelaskan cara mengelola notifikasi dan insiden dengan menambahkan label buatan pengguna ke kebijakan pemberitahuan. Karena label yang ditentukan pengguna disertakan dalam notifikasi, jika Anda menambahkan label yang menunjukkan tingkat keparahan insiden, notifikasi tersebut akan berisi informasi yang dapat membantu Anda memprioritaskan pemberitahuan untuk diselidiki.

Tentang label

Label adalah key-value pair yang terkait dengan deret waktu, kebijakan pemberitahuan, dan insiden. Ada label metrik, label resource, dan label buatan pengguna. Label metrik dan resource berisi informasi spesifik tentang metrik yang dikumpulkan atau resource yang digunakan untuk menulis metrik. Sebaliknya, label yang ditentukan pengguna adalah label yang Anda buat dan merekam informasi khusus untuk kebutuhan Anda.

Saat data deret waktu ditulis, label dilampirkan ke data untuk mencatat informasi tentang data tersebut. Misalnya, label pada deret waktu dapat mengidentifikasi virtual machine (VM), zona, project Google Cloud, dan jenis perangkat.

Anda dapat menambahkan label pengguna ke kebijakan pemberitahuan dan insiden:

Melihat label di notifikasi

Anda dapat melihat label kebijakan pemberitahuan atau insiden di halaman detail insiden, halaman detail kebijakan pemberitahuan, dan di beberapa notifikasi:

  • Dalam notifikasi email, label yang Anda tambahkan ke kebijakan tercantum di bagian Label kebijakan, sedangkan label yang Anda tambahkan ke insiden dicantumkan di bagian Label metrik.

  • Di notifikasi PagerDuty, Webhook, dan Pub/Sub, label yang Anda tambahkan ke insiden atau kebijakan pemberitahuan disertakan dalam data JSON. Label kebijakan pemberitahuan tercantum di kolom policy_user_labels dalam struktur JSON:

    "policy_user_labels": {
  "severity": "critical",
}

    Label insiden disertakan di kolom metric pada struktur JSON:

    "metric": {
  "type" : "compute.googleapis.com/instance/cpu/utilization"
  "displayName": "CPU Utilization",
  "labels": {
    "instance_name": "some_instance_name",
    "severity": "critical"
  },
}

    Seperti yang ditunjukkan sebelumnya, kolom metric mencantumkan jenis metrik, nama tampilan untuk metrik, label metrik, dan label yang ditentukan pengguna yang ditambahkan ke insiden.

Contoh: membuat tingkat keparahan dinamis menggunakan label dan MQL

Anda dapat menggunakan MQL untuk mengonfigurasi label sehingga nilainya berubah secara dinamis berdasarkan data deret waktu. Misalnya, Anda ingin insiden memiliki label Criticality yang nilainya berubah, bergantung pada nilai metrik penggunaan CPU yang dipantau:

fetch gce_instance
| metric 'compute.googleapis.com/instance/cpu/utilization'
| group_by sliding(5m), [value_utilization_mean: mean(value.utilization)]
| map
    add[
      Criticality:
        if(val() >= 90 '%', 'CRITICAL',
          if(val() >= 80 '%', 'WARNING',
            if(val() >= 70 '%', 'INFO', 'GOOD')))
    ]
| condition val() >= 70 '%'

Gambar berikut mengilustrasikan cara kebijakan pemberitahuan yang menggunakan kueri MQL memproses data deret waktu yang dipantau:

Ilustrasi tentang cara kebijakan pemberitahuan memproses deret waktu yang dipantau.

Pengendali kebijakan memproses data penggunaan CPU dan menghasilkan deret waktu yang menunjukkan kapan kondisi tersebut dipicu. Pada contoh sebelumnya, kondisi ini dipicu saat pemakaian CPU minimal 70%. Untuk setiap deret waktu input, pengendali kebijakan dapat membuat salah satu dari empat deret waktu:

Nama deret waktu output Kondisi dipicu Deskripsi
"BAGUS" Tidak Deret waktu ini memiliki label yang sama dengan deret waktu input. dan tidak memiliki label tingkat keparahan.
"KRITIS" Ya Pemakaian CPU minimal 90%. Deret waktu output memiliki label yang sama dengan deret waktu "GOOD" plus label tingkat keparahan dengan nilai "CRITITY".
"PERINGATAN" Ya Pemakaian CPU minimal 80% tetapi kurang dari 90%. Deret waktu output memiliki label yang sama dengan deret waktu "GOOD" plus label tingkat keparahan dengan nilai "WARNING".
"INFO" Ya Pemakaian CPU minimal 70% tetapi kurang dari 80%. Deret waktu output memiliki label yang sama dengan deret waktu "GOOD" plus label tingkat keparahan dengan nilai "INFO".

Data deret waktu yang dihasilkan oleh pengendali kebijakan adalah input ke pengelola insiden, yang menentukan kapan insiden dibuat dan ditutup. Untuk menentukan kapan harus menutup insiden, pengelola insiden menggunakan nilai kolom duration, evaluationMissingData, dan autoClose.

Praktik terbaik

Untuk memastikan bahwa maksimal satu insiden terbuka pada satu waktu ketika Anda membuat label yang nilainya ditetapkan secara dinamis, lakukan hal berikut:

  • Pada objek MetricThreshold, ganti nilai default untuk kolom berikut:

    • Kolom duration: Tetapkan ke nilai bukan nol.
    • Kolom evaluationMissingData: Tetapkan agar insiden ditutup saat data berhenti tiba. Saat Anda menggunakan Cloud Monitoring API, tetapkan kolom ini ke EVALUATION_MISSING_DATA_INACTIVE. Saat Anda menggunakan Konsol Google Cloud, tetapkan kolom ke "Titik data tidak ada diperlakukan sebagai nilai yang tidak melanggar kondisi kebijakan".

  • Pada objek AlertStrategy, tetapkan kolom autoClose ke nilai minimumnya 30 menit. Saat Anda menggunakan Cloud Monitoring API, tetapkan kolom ini ke 30m.

Untuk informasi selengkapnya, lihat Data metrik parsial.

Alur insiden

Misalkan pengukuran pemakaian CPU kurang dari 70% saat kebijakan pemberitahuan dibuat. Urutan berikut mengilustrasikan cara insiden dibuka dan ditutup:

  1. Karena pengukuran pemakaian CPU kurang dari 70%, pengendali kebijakan menghasilkan deret waktu "GOOD" dan tidak ada insiden yang dibuka.

  2. Selanjutnya, asumsikan penggunaan CPU naik hingga 93%. Pengendali kebijakan berhenti menghasilkan data deret waktu "GOOD" dan mulai menghasilkan data untuk deret waktu "Penting".

    Manajer insiden melihat deret waktu baru yang memicu kondisi, deret waktu "KRITIS", dan menciptakan insiden. Notifikasi tersebut menyertakan label tingkat keparahan dengan nilai CRITICAL.

  3. Asumsikan pemakaian CPU turun ke 75%. Pengendali kebijakan berhenti menghasilkan deret waktu "KRITIS" dan mulai membuat deret waktu "INFO".

    Pengelola insiden melihat deret waktu baru yang memicu kondisi, deret waktu "INFO", dan membuka insiden. Notifikasi ini menyertakan label tingkat keparahan dengan nilai INFO.

    Pengelola insiden melihat bahwa tidak ada data yang masuk untuk deret waktu "KRITIS" dan bahwa ada insiden yang terbuka untuk deret waktu tersebut. Karena kebijakannya dikonfigurasi untuk menutup insiden saat data tidak lagi tiba, pengelola insiden menutup insiden yang terkait dengan deret waktu "KRITIS". Oleh karena itu, hanya insiden yang label tingkat keparahannya memiliki nilai INFO yang akan tetap terbuka.

  4. Terakhir, asumsikan bahwa pemakaian CPU turun menjadi 45%. Nilai ini kurang dari semua nilai minimum, sehingga pengendali kebijakan berhenti menghasilkan deret waktu "INFO" dan mulai menghasilkan deret waktu "GOOD".

    Pengelola insiden melihat bahwa tidak ada data yang masuk untuk deret waktu "INFO" dan bahwa ada insiden yang terbuka untuk deret waktu tersebut. Karena kebijakan tersebut menggunakan setelan yang direkomendasikan, insiden ditutup.

Jika Anda tidak menggunakan nilai yang direkomendasikan untuk kolom evaluationMissingData, saat data berhenti tiba, insiden terbuka tidak akan langsung ditutup. Hasilnya adalah Anda mungkin melihat beberapa insiden terbuka untuk deret waktu input yang sama. Untuk informasi selengkapnya, lihat Data metrik parsial.

Langkah selanjutnya