Panduan pemantauan cluster

Ringkasan

Panduan ini memberikan pedoman tentang apa yang harus dipantau dan cara memantau deployment Apigee Hybrid. Fitur ini ditujukan untuk administrator cluster hybrid dan admin Org.

Jika Anda baru menggunakan pemantauan Google Cloud, lihat dokumentasi Google Cloud Monitoring untuk: Membuat diagram dengan Metrics Explorer dan Cara kerja pemberitahuan.

Cluster Apigee Hybrid menyediakan metrik SLI (Indikator Tingkat Layanan) untuk membantu Anda memahami performa aplikasi dan layanan sistem pada waktu tertentu. Anda dapat melihat daftar lengkap Metrik yang tersedia.

Google Cloud Monitoring menggunakan Jenis Resource untuk mengidentifikasi setiap metrik SLI. Ada tiga Jenis Resource umum yang digunakan untuk semua metrik Apigee Hybrid.

Jenis Resource memiliki label umum yang berlaku untuk semua metrik terkaitnya. Misalnya, semua metrik dengan jenis resource k8s_container memiliki label cluster_name, pod_name, dan container_name yang dapat digunakan, selain label metrik. Kombinasi label Jenis Resource dan label metrik harus digunakan untuk memantau kondisi dan performa cluster secara efektif.

Nilai minimum pemberitahuan: Idealnya, nilai minimum pemberitahuan akan jelas dan dokumentasi yang diberikan akan mencantumkan nilai yang harus memicu pemberitahuan. Pada kenyataannya, Apigee kurang jelas dalam mendefinisikan performa yang dapat diterima dan pemanfaatan resource layanan dan infrastruktur yang berbahaya. Nilai minimum pemberitahuan akan sangat bervariasi bergantung pada pola traffic tertentu dan perjanjian SLO/SLA.

Pengoptimalan dan penentuan nilai minimum Pemberitahuan adalah proses berkelanjutan karena dapat berubah seiring dengan penggunaan layanan dan infrastruktur. Gunakan nilai minimum Peringatan dan Kritis untuk notifikasi dan pemberitahuan.

  • Sehat: Nilai kurang dari ambang batas peringatan.
  • Mengkhawatirkan: Nilai lebih besar dari ambang batas peringatan, tetapi nilai kurang dari ambang batas kritis.
  • Kritis: Nilai > Nilai minimum kritis.

Pelanggan harus menggunakan alat yang disediakan untuk menentukan nilai minimum yang optimal, baik itu dasbor Cloud Monitoring yang dapat dibuat pelanggan dengan MQL yang disediakan di bawah atau analisis Apigee, untuk mengidentifikasi seperti apa "normal" itu dan kemudian menyesuaikan nilai minimum pemberitahuan dengan tepat.

Pemantauan cluster hybrid dapat dikategorikan ke dalam empat grup umum yang berbeda, misalnya Traffic, Database, bidang kontrol Apigee, dan pemantauan infrastruktur. Bagian berikut menjelaskan kelompok ini secara detail:

Traffic

Metrik SLI Proxy dan Target Apigee memberikan jumlah permintaan/respons dan latensi untuk Proxy dan Target API. Metrik SLI latensi Kebijakan Apigee memberikan latensi respons kebijakan. Metrik SLI ini memberikan cakupan untuk memantau traffic API Apigee.

Rasio Permintaan

Jumlah permintaan proxy

Kasus penggunaan: Gunakan proxyv2/request_count untuk memantau jumlah permintaan proxy. Diagram proxyv2/request_count menampilkan kecepatan permintaan untuk proxy. Diagram ini berguna untuk mengidentifikasi Proxy mana yang menerima rasio permintaan yang lebih tinggi, pola rasio permintaan, dan lonjakan panggilan permintaan yang tidak normal untuk proxy tertentu. Lonjakan tidak normal yang tidak terduga pada traffic API dapat menjadi masalah keamanan terkait bot atau serangan pada proxy API. Demikian pula, penurunan besar dalam traffic keseluruhan dapat menunjukkan masalah pada klien atau konektivitas dari komponen upstream Apigee.

Jenis resource ProxyV2
Metrik proxyv2/request_count
Kelompokkan Menurut method dan semua label jenis resource ProxyV2
Agregator sum
Pertimbangan pemberitahuan Peristiwa seperti peringatan lonjakan/penurunan request_count yang tidak normal
Nilai minimum pemberitahuan Tidak ada
Kueri MQL dasbor Cloud Monitoring: 
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/proxyv2/request_count'
| align rate(1m)
| every 1m
| group_by [metric.method],
  [value_request_count_aggregate: aggregate(value.request_count)]

Jumlah permintaan target

Kasus penggunaan: Gunakan targetv2/request_count untuk memantau jumlah permintaan target runtime Apigee. Diagram targetv2/request_count menampilkan rasio permintaan yang diterima oleh target Apigee. Diagram ini mungkin berguna untuk melihat target mana yang mendapatkan rasio permintaan yang lebih tinggi, pola rasio permintaan, dan lonjakan panggilan permintaan yang tidak normal untuk target tertentu.

Jenis resource TargetV2
Metrik targetv2/request_count
Kelompokkan Menurut method dan semua label jenis resource TargetV2
Agregator sum
Pertimbangan pemberitahuan Peristiwa seperti peringatan lonjakan/penurunan request_count yang tidak normal
Nilai minimum pemberitahuan Tidak ada
Kueri MQL dasbor Cloud Monitoring: 
fetch apigee.googleapis.com/TargetV2
| metric 'apigee.googleapis.com/targetv2/request_count'
| align rate(1m)
| every 1m
| group_by [metric.method, metric.type, metric.endpoint],
  [value_request_count_aggregate: aggregate(value.request_count)]

Tingkat Error

Jumlah respons error proxy

Kasus penggunaan: Gunakan proxyv2/response_count untuk memantau rasio respons error proxy. Diagram proxyv2/response_count menampilkan kecepatan permintaan untuk Proxy API. Diagram ini berguna untuk memahami proxy mana yang mendapatkan rasio error permintaan yang lebih tinggi atau lonjakan error yang tidak normal dalam panggilan permintaan untuk proxy tertentu.

Jenis resource ProxyV2
Metrik proxyv2/response_count
Filter Menurut response_code != 200

Gunakan regex untuk mengecualikan semua response_code 2xx dan 3xx, misalnya:

"response_code !=~ 1.*| 2.*|3.*"
Kelompokkan Menurut method, response_code, fault_code, fault_source, apigee_fault, dan semua label jenis resource ProxyV2
Agregator sum
Pertimbangan pemberitahuan Rasio error respons Proxy: Total error respons / Total jumlah respons.
  • Total error respons = Jumlah proxyv2/response_count dengan filter response_code != 200
  • Jumlah total respons = Jumlah proxyv2/response_count
Nilai minimum pemberitahuan Bergantung pada SLO untuk penginstalan. Penginstalan produksi dan non-produksi mungkin memiliki nilai minimum yang berbeda. Misalnya: Untuk produksi, picu notifikasi peristiwa jika rasio error 500 respons proxy adalah 5% selama 5 menit.
Kueri MQL dasbor Cloud Monitoring: 
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/proxyv2/response_count'
| filter (metric.response_code != '200')
| align rate(1m)
| every 1m
| group_by
  [metric.method, metric.response_code, metric.fault_code,
   metric.fault_source, metric.apigee_fault],
  [value_response_count_aggregate: aggregate(value.response_count)]
Contoh MQL kebijakan Pemberitahuan operasi Google Cloud: 
fetch apigee.googleapis.com/ProxyV2::apigee.googleapis.com/proxyv2/response_count
| {
   filter (metric.response_code == '500')
   ;
   ident
}
| group_by drop[metric.response_code ], sliding(5m), .sum
| ratio
| scale '%'
| every (30s)
| condition val() > 5'%'

Jumlah respons error target

Kasus penggunaan: Gunakan targetv2/response_count untuk memantau rasio respons error Target API. Diagram targetv2/response_count menampilkan kecepatan permintaan dari Target API. Diagram ini dapat berguna untuk mengidentifikasi target mana yang mendapatkan rasio permintaan lebih tinggi atau lonjakan error yang tidak normal dalam panggilan permintaan.

Jenis resource TargetV2
Metrik targetv2/response_count
Filter Menurut response_code != 200

Gunakan regex untuk mengecualikan semua response_code 2xx dan 3xx, misalnya:

"response_code !=~ 1.*| 2.*|3.*"
Kelompokkan Menurut method dan semua label jenis resource TargetV2
Agregator sum
Pertimbangan pemberitahuan Rasio error respons Proxy, misalnya: Total error respons / Total jumlah respons.
  • Total error respons = Jumlah targetv2/response_count dengan filter response_code != 200
  • Total jumlah respons = Jumlah targetv2/response_count
Nilai minimum pemberitahuan Bergantung pada SLO untuk penginstalan. Misalnya: Untuk produksi, picu notifikasi peristiwa, jika rasio error respons target adalah 5% selama 3 menit.
Kueri MQL dasbor Cloud Monitoring: 
fetch apigee.googleapis.com/TargetV2
| metric 'apigee.googleapis.com/targetv2/response_count'
| filter (metric.response_code != '200')
| align rate(1m)
| every 1m
| group_by
  [metric.method, metric.type, metric.endpoint,
   metric.response_code],
  [value_response_count_aggregate: aggregate(value.response_count)]

Latensi

Persentil latensi proxy

Kasus penggunaan: Gunakan proxyv2/latencies_percentile untuk memantau persentil latensi (p50, p90, p95, dan p99) semua respons proxy API terhadap permintaan. Diagram proxyv2/latencies_percentile dapat berguna untuk mengidentifikasi latensi di proxy API Apigee terhadap latensi permintaan proxy API secara keseluruhan.

Jenis resource ProxyV2
Metrik proxyv2/latencies_percentile
Filter Menurut percentile = p99
Kelompokkan Menurut method, persentil, dan semua label jenis resource ProxyV2
Agregator p99 (persentil ke-99)
Pertimbangan pemberitahuan Nilai tinggi latensi_persentil p99.
Nilai minimum pemberitahuan Bergantung pada SLO untuk penginstalan. Misalnya: Untuk produksi, picu notifikasi peristiwa, Jika nilai persentil latensi p99 proxy adalah 5 detik selama 5 menit.
Kueri MQL dasbor Cloud Monitoring: 
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/proxyv2/latencies_percentile'
| filter (metric.percentile == 'p99')
| group_by 1m,
  [value_latencies_percentile_mean: mean(value.latencies_percentile)]
| every 1m
| group_by [metric.method, metric.percentile],
  [value_latencies_percentile_mean_percentile:
     percentile(value_latencies_percentile_mean, 99)]

Persentil latensi target

Kasus penggunaan: Gunakan targetv2/latencies_percentile untuk memantau persentil latensi (p50, p90, p95, dan p99) semua respons target proxy API terhadap permintaan. Diagram targetv2/latencies_percentile mengidentifikasi total waktu yang dibutuhkan target proxy API Apigee untuk merespons permintaan. Nilai ini tidak mencakup overhead proxy Apigee API.

Jenis resource TargetV2
Metrik targetv2/latencies_percentile
Filter Menurut percentile = p99
Kelompokkan Menurut method, persentil, dan semua label jenis resource TargetV2
Agregator p99 (persentil ke-99)
Pertimbangan pemberitahuan Nilai tinggi latensi_persentil p99.
Nilai minimum pemberitahuan Bergantung pada SLO untuk penginstalan. Misalnya: Untuk produksi, picu notifikasi peristiwa, Jika nilai persentil latensi p99 target adalah 5 detik selama 5 menit.
Kueri MQL dasbor Cloud Monitoring: 
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/proxyv2/latencies_percentile'
| filter (metric.percentile == 'p99')
| group_by 1m,
  [value_latencies_percentile_mean: mean(value.latencies_percentile)]
| every 1m
| group_by [metric.method, metric.percentile],
  [value_latencies_percentile_mean_percentile:
     percentile(value_latencies_percentile_mean, 99)]

Persentil latensi kebijakan

Kasus penggunaan: Gunakan policyv2/latencies_percentile untuk memantau persentil latensi pemrosesan (p50, p90, p95, dan p99) semua kebijakan Apigee. Diagram policyv2/latencies_percentile dapat berguna untuk mengidentifikasi latensi dalam kebijakan API Apigee terhadap latensi permintaan proxy API secara keseluruhan pelanggan.

Jenis resource ProxyV2
Metrik proxyv2/latencies_percentile
Filter Menurut percentile = p99
Kelompokkan Menurut method, persentil, dan semua label jenis resource ProxyV2
Agregator p99 (persentil ke-99)
Pertimbangan pemberitahuan Nilai tinggi latensi_persentil p99.
Nilai minimum pemberitahuan Bergantung pada SLO untuk penginstalan. Misalnya: Untuk produksi, picu notifikasi peristiwa, Jika nilai persentil latensi p99 proxy adalah 5 detik selama 5 menit.
Kueri MQL dasbor Cloud Monitoring: 
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/policyv2/latencies_percentile'
| filter (metric.percentile == 'p99')
| group_by 1m,
  [value_latencies_percentile_mean: mean(value.latencies_percentile)]
| every 1m
| group_by [metric.policy_name, metric.percentile],
  [value_latencies_percentile_mean_aggregate:
     aggregate(value_latencies_percentile_mean)]

Database

Cassandra

Layanan database Apigee Cassandra memiliki beberapa metrik SLI Cassandra. Metrik SLI ini dapat memberikan pemantauan yang komprehensif untuk layanan Apigee Cassandra. Setidaknya, bersama dengan penggunaan resource Cassandra (CPU, Mem, dan volume disk), latensi permintaan baca dan tulis klien harus dipantau untuk mengetahui kondisi layanan Cassandra.

Kecepatan permintaan baca Cassandra

Kasus penggunaan: Metrik SLI cassandra/clientrequest_rate (dengan scope=Read) memberikan insight tentang kecepatan rata-rata permintaan baca layanan Cassandra pada waktu tertentu. Metrik ini membantu memahami tren tingkat aktivitas permintaan baca klien.

Jenis resource k8s_container
Metrik cassandra/clientrequest_rate
Filter Menurut scope = Read dan unit = OneMinuteRate
Kelompokkan Menurut scope, unit, dan semua label jenis resource k8s_container
Agregator sum
Pertimbangan pemberitahuan Untuk potensi masalah atau perubahan signifikan dalam pola kueri klien; misalnya, lonjakan atau penurunan yang tiba-tiba dan tidak terduga dalam rasio permintaan baca.
Nilai minimum pemberitahuan Tidak ada
Kueri MQL dasbor Cloud Monitoring: 
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Read' && metric.unit == 'OneMinuteRate')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Kecepatan permintaan tulis Cassandra

Kasus penggunaan: Metrik SLI cassandra/clientrequest_rate (dengan scope=Write) memberikan insight tentang kecepatan rata-rata permintaan penulisan layanan Cassandra pada waktu tertentu. Metrik ini membantu memahami tren tingkat aktivitas permintaan penulisan klien.

Jenis resource k8s_container
Metrik cassandra/clientrequest_rate
Filter Menurut scope = Read dan unit = OneMinuteRate
Kelompokkan Menurut scope, unit, dan semua label jenis resource k8s_container
Agregator sum
Pertimbangan pemberitahuan Untuk potensi masalah atau perubahan signifikan dalam pola kueri klien; misalnya, lonjakan atau penurunan permintaan penulisan yang tiba-tiba dan tidak terduga yang memerlukan penyelidikan lebih lanjut.
Nilai minimum pemberitahuan Tidak ada
Kueri MQL dasbor Cloud Monitoring: 
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Write' && metric.unit == 'OneMinuteRate')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Latensi permintaan baca Cassandra

Kasus penggunaan: Metrik SLI cassandra/clientrequest_latency (dengan cakupan=Baca) memberikan latensi permintaan baca layanan Cassandra (pada persentil ke-99, persentil ke-95, atau persentil ke-75). Metrik ini membantu memberikan gambaran keseluruhan performa Cassandra dan dapat menunjukkan perubahan pada pola penggunaan atau masalah yang muncul seiring waktu.

Jenis resource k8s_container
Metrik cassandra/clientrequest_latency
Filter Menurut scope = Read dan unit = 99thPercentile
Kelompokkan Menurut scope, unit, dan semua label jenis resource k8s_container
Agregator sum
Pertimbangan pemberitahuan Jika SLI latensi permintaan baca secara konsisten menunjukkan tren latensi persentil ke-99 yang terus meningkat.
Nilai minimum pemberitahuan Bergantung pada SLO Anda untuk layanan Cassandra. Misalnya: Di produksi, picu notifikasi peristiwa jika nilai clientrequest_latency 99thPercentile adalah 5 detik selama 3 menit
Kueri MQL dasbor Cloud Monitoring: 
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Read' && metric.unit == '99thPercentile')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Latensi permintaan tulis Cassandra

Kasus penggunaan: Metrik SLI cassandra/clientrequest_latency (dengan scope=Write) memberikan latensi permintaan tulis layanan Cassandra (pada persentil ke-99, persentil ke-95, atau persentil ke-75). Metrik ini membantu memberikan gambaran keseluruhan performa Cassandra dan dapat menunjukkan perubahan pola penggunaan atau masalah yang muncul seiring waktu.

Jenis resource k8s_container
Metrik cassandra/clientrequest_latency
Filter Menurut scope = Write dan unit = 99thPercentile
Kelompokkan Menurut scope, unit, dan semua label jenis resource k8s_container
Agregator sum
Pertimbangan pemberitahuan Jika SLI latensi permintaan tulis secara konsisten menunjukkan tren latensi persentil ke-99 yang terus meningkat.
Nilai minimum pemberitahuan Bergantung pada SLO Anda untuk layanan Cassandra. Misalnya: di produksi, picu notifikasi peristiwa jika nilai clientrequest_latency 99thPercentile penulisan adalah 5 detik selama 3 menit
Kueri MQL dasbor Cloud Monitoring: 
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Write' && metric.unit == '99thPercentile')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Bidang kontrol Apigee

Metrik SLI layanan Apigee Synchronizer memberikan jumlah dan latensi permintaan dan respons antara bidang kontrol Apigee dan bidang runtime Hybrid. Instance sinkronisasi yang berjalan di bidang runtime diharapkan melakukan polling bidang kontrol secara rutin, mendownload kontrak, dan menyediakannya untuk instance runtime lokal.

Rasio permintaan

Jumlah permintaan upstream

Kasus penggunaan: Metrik upstream/request_count menunjukkan jumlah permintaan yang dibuat oleh layanan Synchronizer ke bidang kontrol Apigee.

Jenis resource k8s_container
Metrik upstream/request_count
Filter Menurut container_name = apigee-synchronizer dan type = CONTRACT
Kelompokkan Menurut method, type, container_name, dan semua k8s_container jenis resource label
Agregator sum
Pertimbangan pemberitahuan Gunakan ini untuk mendeteksi anomali traffic, seperti lonjakan request_count yang tidak normal atau pemberitahuan penurunan.
Nilai minimum pemberitahuan Tidak ada
Kueri MQL dasbor Cloud Monitoring: 
fetch k8s_container
| metric 'apigee.googleapis.com/upstream/request_count'
| filter
  (resource.container_name == 'apigee-synchronizer')
  && (metric.type == 'CONTRACT')
| align rate(1m)
| every 1m
| group_by [metric.method, metric.type, resource.container_name],
  [value_request_count_aggregate: aggregate(value.request_count)]

Tingkat error

Jumlah respons upstream

Kasus penggunaan: Metrik SLI upstream/response_count memberikan jumlah respons yang diterima layanan Sinkronisasi dari bidang kontrol Apigee. Diagram ini mungkin berguna untuk mengidentifikasi masalah konektivitas atau konfigurasi antara bidang Runtime Apigee Hybrid dan Bidang kontrol.

Jenis resource k8s_container
Metrik upstream/request_count
Filter Menurut method, response_type, container_name, dan semua jenis resource k8s_container label
Kelompokkan Menurut
Agregator sum
Pertimbangan pemberitahuan Jika ada error dalam metrik upstream/response_count dengan kode respons non-200 yang ditampilkan dari Panel kontrol Apigee, maka diperlukan penyelidikan lebih lanjut terhadap error tersebut.
Nilai minimum pemberitahuan Bergantung pada SLO Anda untuk layanan Cassandra. Misalnya: dalam produksi, picu notifikasi peristiwa jika Synchronizer mengalami lebih dari satu error response_code setiap tiga menit.
Kueri MQL dasbor Cloud Monitoring: 
fetch k8s_container
| metric 'apigee.googleapis.com/upstream/response_count'
| filter
  (resource.container_name == 'apigee-synchronizer')
  && (metric.response_code != '200' && metric.type == 'CONTRACT')
| align rate(1m)
| every 1m
| group_by
  [metric.method, metric.response_code, metric.type, resource.container_name],
  [value_response_count_aggregate: aggregate(value.response_count)]

Infrastruktur

GKE dan platform Kubernetes lainnya menyediakan metrik SLI tingkat sistem. Label metrik SLI dapat difilter dan dikelompokkan untuk memantau penampung tertentu dan penggunaan resource-nya. Untuk memantau kondisi dan ketersediaan infrastruktur cluster Apigee Runtime, admin cluster dapat memantau penggunaan resource umum container dan pod seperti CPU, Mem, disk, dan jumlah mulai ulang container. Ikuti dokumentasi GKE untuk mengetahui detail selengkapnya tentang metrik dan label yang tersedia.

Tabel berikut mencantumkan beberapa layanan dan penampung yang dapat Anda pantau untuk setiap layanan.

Nama Layanan Nama Penampung
Cassandra apigee-cassandra
Message Processor(MP) apigee-runtime
Synchronizer apigee-synchronizer
Telemetri apigee-prometheus-app
apigee-prometheus-proxy
apigee-prometheus-agg
apigee-stackdriver-exporter

Container / Pod

Jumlah mulai ulang

Kasus penggunaan: Metrik SLI sistem kubernetes.io/container/restart_count memberikan jumlah berapa kali sebuah container telah dimulai ulang. Diagram ini dapat berguna untuk mengidentifikasi apakah container sering mengalami error/dimulai ulang. Container layanan tertentu dapat difilter berdasarkan label metrik untuk pemantauan container layanan tertentu.

Berikut menunjukkan penggunaan metrik kubernetes.io/container/restart_count untuk container Cassandra. Anda dapat menggunakan metrik ini untuk semua penampung dalam tabel di atas.

Jenis resource k8s_container
Metrik kubernetes.io/container/restart_count
Filter Menurut namespace_name = apigee dan container_name =~ .*cassandra.*
Kelompokkan Menurut cluster_name, namespace_name, pod_name, container_name, dan semua label jenis resource k8s_container
Agregator sum
Pertimbangan pemberitahuan Jika penampung sering dimulai ulang, penyelidikan lebih lanjut diperlukan untuk mengetahui penyebab utamanya. Ada beberapa alasan mengapa penampung dapat dimulai ulang, seperti OOMKilled, disk data penuh, dan masalah konfigurasi, serta beberapa alasan lainnya.
Nilai minimum pemberitahuan Bergantung pada SLO untuk penginstalan. Misalnya: Untuk produksi, picu notifikasi peristiwa, jika penampung dimulai ulang lebih dari 5 kali dalam waktu 30 menit.
Kueri MQL dasbor Cloud Monitoring: 
fetch k8s_container
| metric 'kubernetes.io/container/restart_count'
| filter
  (resource.container_name =~ '.*cassandra.*'
   && resource.namespace_name == 'apigee')
| align rate(1m)
| every 1m
| group_by
  [resource.cluster_name, resource.namespace_name, resource.pod_name,
   resource.container_name],
  [value_restart_count_aggregate: aggregate(value.restart_count)]