Panduan pemantauan cluster

Version 1.11 (latest)

Versi yang didukung:

• v1.13 (terbaru)                        
• v1.12                         
• v1.11                         
• Daftar versi yang didukung

Versi yang tidak didukung:

• v1.10                                      
• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

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 mengenal Google Cloud Monitoring, lihat dokumentasi Google Cloud Monitoring untuk: Membuat diagram dengan Metrics Explorer dan Cara kerja pemberitahuan.

Cluster Apigee Hybrid menyediakan metrik SLI (Service Level Indicator) 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.

• k8s_container untuk metrik tingkat sistem.
• ProxyV2 untuk metrik Proxy Apigee API.
• TargetV2 untuk metrik Target Apigee API

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 tersedia untuk digunakan, selain label metrik. Kombinasi label Jenis Resource dan label metrik harus digunakan untuk memantau kondisi dan performa cluster secara efektif.

Ambang batas pemberitahuan: Idealnya, nilai minimum pemberitahuan akan terlihat jelas dan dokumentasi yang diberikan akan mencantumkan nilai yang seharusnya memicu pemberitahuan. Pada kenyataannya, kurang jelas bagi Apigee untuk mendefinisikan definisi - apa yang dimaksud dengan performa yang dapat diterima dan apa yang dimaksud dengan pemanfaatan resource yang berbahaya dari layanan dan infrastruktur. Nilai minimum pemberitahuan akan sangat bervariasi, bergantung pada pola traffic dan perjanjian SLO/SLA tertentu.

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

• Responsif: Nilai kurang dari nilai minimum peringatan.
• Perihal: Nilai lebih besar dari nilai minimum peringatan, tetapi nilainya kurang dari Nilai minimum kritis.
• Penting: Nilai > Nilai minimum kritis.

Pelanggan sebaiknya 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 ini maupun analisis Apigee, untuk mengidentifikasi bentuk "normal", lalu menyesuaikan nilai minimum pemberitahuan tersebut.

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

Catatan: Pemantauan Traffic API sama untuk cluster Apigee-X dan Hybrid. Pengguna Apigee-X memiliki akses ke metrik SLI traffic API seperti Proxy, Target, dan Kebijakan dalam project Google Cloud Org, serta dapat menggunakan metrik SLI ini untuk pemantauan dan pemberitahuan.

Tips: Umumnya, dasbor "Rasio Permintaan" berguna secara mandiri untuk visualisasi pola traffic. Penambahan nilai minimum pemberitahuan hanya untuk metrik SLI rasio permintaan bukanlah hal yang mudah, kecuali jika pola/volume traffic-nya sudah ditentukan sebelumnya. Namun, diagram rasio permintaan dapat memberikan informasi yang berguna tentang lonjakan atau penurunan traffic tidak normal yang tidak biasa selama proses debug masalah apa pun yang terkait dengan traffic (baca, tulis, kode respons, dll).

Traffic

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

Rasio Permintaan

Jumlah permintaan proxy

Kasus penggunaan: Gunakan proxyv2/request_count untuk memantau jumlah permintaan proxy. Diagram proxyv2/request_count menampilkan tingkat permintaan untuk proxy. Diagram ini berguna untuk mengidentifikasi Proxy mana yang menerima rasio permintaan lebih tinggi, pola rasio permintaan, dan lonjakan abnormal apa pun dalam panggilan permintaan untuk proxy tertentu. Lonjakan abnormal yang tidak terduga dalam traffic API dapat menjadi masalah keamanan seputar bot atau serangan terhadap proxy API. Demikian pula, penurunan besar dalam keseluruhan cloud traffic menunjukkan adanya 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	jumlah
Pertimbangan notifikasi	Peristiwa seperti pemberitahuan request_count lonjakan/penurunan 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 lebih tinggi, pola rasio permintaan, dan lonjakan abnormal dalam panggilan permintaan untuk target tertentu.

Jenis resource	TargetV2
Metrik	targetv2/request_count
Kelompokkan Menurut	method dan semua label jenis resource TargetV2
Agregator	jumlah
Pertimbangan notifikasi	Peristiwa seperti pemberitahuan request_count lonjakan/penurunan 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 tingkat respons error proxy. Diagram proxyv2/response_count menampilkan tingkat permintaan untuk Proxy API. Diagram ini berguna untuk memahami proxy mana yang mendapatkan tingkat error permintaan 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 ekspresi reguler 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	jumlah
Pertimbangan notifikasi	Rasio error respons proxy: Total error respons / Total jumlah respons. Total error respons = Jumlah proxyv2/response_count dengan filter response_code != 200 Jumlah respons total = Jumlah proxyv2/response_count
Nilai minimum pemberitahuan	Bergantung pada SLO untuk penginstalan. Instalasi produksi dan non-produksi mungkin memiliki batas 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 tingkat respons error Target API. Diagram targetv2/response_count menampilkan tingkat permintaan dari Target API. Diagram ini mungkin 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 ekspresi reguler untuk mengecualikan semua response_code 2xx dan 3xx, misalnya: "response_code !=~ 1.*| 2.*|3.*"
Kelompokkan Menurut	method dan semua label jenis resource TargetV2
Agregator	jumlah
Pertimbangan notifikasi	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	Tergantung 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) dari semua respons proxy API terhadap permintaan. Diagram proxyv2/latencies_percentile mungkin berguna untuk mengidentifikasi latensi di proxy Apigee API terhadap keseluruhan latensi permintaan proxy API Anda.

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 notifikasi	Nilai tinggi p99 latencies_percentile.
Nilai minimum pemberitahuan	Tergantung SLO untuk penginstalan. Misalnya: Untuk produksi, picu notifikasi peristiwa. Jika nilai proxy p99 latencies_percentile 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) dari semua respons target proxy API terhadap permintaan. Diagram targetv2/latencies_percentile mengidentifikasi jumlah total waktu bagi target proxy Apigee API untuk merespons permintaan. Nilai ini tidak termasuk 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 notifikasi	Nilai tinggi p99 latencies_percentile.
Nilai minimum pemberitahuan	Tergantung SLO untuk penginstalan. Misalnya: Untuk produksi, picu notifikasi peristiwa. Jika nilai target p99 latencies_percentile 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) untuk semua kebijakan Apigee. Diagram policyv2/latencies_percentile mungkin berguna untuk mengidentifikasi latensi dalam kebijakan Apigee API terhadap keseluruhan latensi permintaan proxy API 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 notifikasi	Nilai tinggi p99 latencies_percentile.
Nilai minimum pemberitahuan	Tergantung SLO untuk penginstalan. Misalnya: Untuk produksi, picu notifikasi peristiwa. Jika nilai proxy p99 latencies_percentile 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 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 kondisi layanan Cassandra.

Rasio permintaan baca Cassandra

Kasus penggunaan: Metrik SLI cassandra/clientrequest_rate (dengan scope=Read) memberikan insight tentang tarif rata-rata permintaan operasi 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	label jenis resource scope, unit, dan semua k8s_container
Agregator	jumlah
Pertimbangan notifikasi	Untuk potensi masalah atau perubahan signifikan pada pola kueri klien; misalnya lonjakan atau penurunan rasio permintaan baca yang tiba-tiba dan tidak terduga.
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)]

Rasio permintaan tulis Cassandra

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

Jenis resource	k8s_container
Metrik	cassandra/clientrequest_rate
Filter Menurut	scope = Read dan unit = OneMinuteRate
Kelompokkan Menurut	label jenis resource scope, unit, dan semua k8s_container
Agregator	jumlah
Pertimbangan notifikasi	Untuk potensi masalah atau perubahan signifikan pada pola kueri klien; misalnya lonjakan atau penurunan permintaan tulis 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 cassandra/clientrequest_Latency (dengan scope=Read) SLI menyediakan latensi permintaan baca layanan Cassandra (pada persentil ke-99, persentil ke-95, atau persentil ke-75). Metrik ini membantu tampilan keseluruhan performa Cassandra dan dapat menunjukkan perubahan pola penggunaan atau masalah yang muncul dengan sendirinya seiring waktu.

Jenis resource	k8s_container
Metrik	cassandra/clientrequest_Latensi
Filter Menurut	scope = Read dan unit = 99thPercentile
Kelompokkan Menurut	label jenis resource scope, unit, dan semua k8s_container
Agregator	jumlah
Pertimbangan notifikasi	Jika latensi permintaan baca secara konsisten menampilkan latensi persentil ke-99 yang cenderung naik secara terus-menerus.
Nilai minimum pemberitahuan	Tergantung pada SLO untuk layanan Cassandra. Misalnya: Dalam produksi, picu notifikasi peristiwa jika nilai clientrequest_latency baca dari 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 cassandra/clientrequest_Latency (dengan scope=Write) SLI menyediakan latensi permintaan tulis layanan Cassandra (pada persentil ke-99, persentil ke-95, atau persentil ke-75). Metrik ini membantu tampilan performa Cassandra secara keseluruhan dan dapat menunjukkan perubahan pola penggunaan atau masalah yang muncul dengan sendirinya seiring waktu.

Jenis resource	k8s_container
Metrik	cassandra/clientrequest_Latensi
Filter Menurut	scope = Write dan unit = 99thPercentile
Kelompokkan Menurut	label jenis resource scope, unit, dan semua k8s_container
Agregator	jumlah
Pertimbangan notifikasi	Jika latensi permintaan tulis, SLI secara konsisten menunjukkan latensi persentil ke-99 yang cenderung naik secara terus-menerus.
Nilai minimum pemberitahuan	Tergantung pada SLO untuk layanan Cassandra. Misalnya: dalam produksi, picu notifikasi peristiwa jika nilai tulis clientrequest_latency pada 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 == '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 menyediakan jumlah permintaan dan respons serta latensi antara bidang kontrol Apigee dan bidang runtime Hybrid. Instance sinkronisasi yang berjalan pada bidang runtime diharapkan untuk memeriksa 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 Sinkronisasir 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 label jenis resource k8s_container
Agregator	jumlah
Pertimbangan notifikasi	Gunakan ini untuk kelainan traffic, seperti notifikasi lonjakan atau penurunan request_count yang tidak normal.
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 Sinkronkanr dari bidang kontrol Apigee. Diagram ini mungkin berguna untuk mengidentifikasi masalah konektivitas atau konfigurasi antara bidang Apigee Hybrid Runtime dan bidang Kontrol.

Jenis resource	k8s_container
Metrik	upstream/request_count
Filter Menurut	method, response_type, container_name, dan semua label jenis resource k8s_container
Kelompokkan Menurut
Agregator	jumlah
Pertimbangan notifikasi	Jika ada error dalam metrik upstream/response_count dengan kode respons non-200 yang ditampilkan dari bidang Kontrol Apigee, diperlukan penyelidikan lebih lanjut atas error tersebut.
Nilai minimum pemberitahuan	Tergantung pada SLO untuk layanan Cassandra. Misalnya: dalam produksi, picu notifikasi peristiwa jika Sinkronkanr 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 Runtime Apigee, admin cluster dapat memantau penggunaan resource umum container dan pod, seperti jumlah mulai ulang CPU, Mem, disk, dan container. Ikuti dokumentasi GKE untuk mengetahui detail selengkapnya tentang metrik dan label yang tersedia.

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

Nama Layanan	Nama Penampung
Cassandra	apigee-cassandra
Pemroses Pesan(MP)	apigee-runtime
Penyinkron	apigee-synchronizer
Telemetri	apigee-prometheus-app apigee-prometheus-proxy apigee-prometheus-agg apigee-stackdriver-exporter

Container / Pod

Jumlah memulai ulang

Kasus penggunaan: Metrik SLI sistem kubernetes.io/container/restart_count menunjukkan berapa kali container telah dimulai ulang. Diagram ini mungkin berguna untuk mengidentifikasi apakah container mengalami error/sering dimulai ulang. Penampung layanan tertentu dapat difilter menurut label metrik untuk pemantauan container layanan tertentu.

Tabel berikut menunjukkan penggunaan metrik kubernetes.io/container/restart_count untuk container Cassandra. Anda dapat menggunakan metrik ini untuk salah satu penampung pada tabel di atas.

Jenis resource	k8s_container
Metrik	kubernetes.io/container/restart_count
Filter Menurut	namespace_name = apigee dan container_name =~ .*cassandra.*
Kelompokkan Menurut	Label jenis resource cluster_name, namespace_name, pod_name, container_name, dan semua k8s_container
Agregator	jumlah
Pertimbangan notifikasi	Jika container sering dimulai ulang, diperlukan penyelidikan lebih lanjut untuk mengetahui akar masalahnya. Ada beberapa alasan container dapat dimulai ulang, misalnya OOMKilled, disk data penuh, dan masalah konfigurasi.
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)]