Panduan pemantauan cluster

Ringkasan

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

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

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

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

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

Ambang batas pemberitahuan: Pada kondisi normal, ambang batas pemberitahuan itu terlihat jelas dan dokumentasi akan mencantumkan nilai yang harus memicu pemberitahuan. Pada kenyataannya, hal ini kurang jelas yang dapat ditentukan oleh Apigee - performa apa yang dapat diterima dan resource apa yang berbahaya pemanfaatan 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 dengan layanan dan penggunaan infrastruktur. Gunakan Peringatan dan Ambang batas kritis untuk notifikasi dan peringatan.

  • Responsif: Nilai kurang dari nilai minimum peringatan.
  • Masalah: Nilai lebih besar daripada nilai minimum peringatan, tetapi nilainya lebih kecil dari Batas kritis.
  • Kritis: Nilai > Batas kritis.

Pelanggan sebaiknya menggunakan alat yang disediakan untuk menentukan ambang batas yang optimal, baik itu Dasbor Cloud Monitoring yang dapat dibuat pelanggan dengan MQL yang disediakan di bawah atau Analisis Apigee, untuk mengidentifikasi hal yang "normal" lalu sesuaikan nilai minimum pemberitahuan sebagaimana mestinya.

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

Traffic

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

Rasio Permintaan

Jumlah permintaan proxy

Kasus penggunaan: Gunakan proxy/request_count untuk memantau jumlah permintaan proxy. Tujuan Diagram proxy/request_count menampilkan rasio permintaan untuk proxy. Diagram ini berguna untuk mengidentifikasi Proxy mana yang menerima rasio permintaan, pola rasio permintaan, dan lonjakan yang tidak normal dalam panggilan permintaan untuk {i>proxy<i} tertentu. Lonjakan tidak normal yang tidak terduga di API dapat menjadi masalah keamanan seputar {i>bot<i} atau serangan terhadap {i>proxy<i} API. Demikian pula, penurunan pada keseluruhan cloud traffic menunjukkan masalah dengan klien atau konektivitas dari upstream Apigee komponen.

Jenis resource Proxy
Metrik proxy/request_count
Kelompokkan Menurut method dan semua Proxy label jenis resource
Agregator jumlah
Peringatan terkait pertimbangan Peristiwa seperti notifikasi request_count lonjakan/penurunan yang tidak normal
Nilai minimum pemberitahuan Tidak ada
Kueri MQL dasbor Cloud Monitoring: 
fetch apigee.googleapis.com/Proxy
| metric 'apigee.googleapis.com/proxy/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 target/request_count untuk memantau target runtime Apigee jumlah permintaan. Diagram target/request_count menampilkan rasio permintaan yang diterima oleh Apigee target. Diagram ini dapat berguna untuk melihat target mana yang mendapatkan rasio permintaan yang lebih tinggi, pola tingkat dan lonjakan abnormal dalam panggilan permintaan untuk target tertentu.

Jenis resource Target
Metrik target/request_count
Kelompokkan Menurut method dan semua Target label jenis resource
Agregator jumlah
Peringatan terkait pertimbangan Peristiwa seperti notifikasi request_count lonjakan/penurunan yang tidak normal
Nilai minimum pemberitahuan Tidak ada
Kueri MQL dasbor Cloud Monitoring: 
fetch apigee.googleapis.com/Target
| metric 'apigee.googleapis.com/target/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 proxy/response_count untuk memantau respons error proxy besar. Diagram proxy/response_count menampilkan rasio permintaan untuk Proxy API. Bagan ini berguna untuk memahami proxy mana yang mendapatkan tingkat kesalahan permintaan yang lebih tinggi atau kesalahan abnormal lonjakan panggilan permintaan untuk proxy tertentu.

Jenis resource Proxy
Metrik proxy/response_count
Filter Menurut response_code != 200
Kelompokkan Menurut method, response_code, fault_code, fault_source, apigee_fault, dan semua Proxy label jenis resource
Agregator jumlah
Peringatan terkait pertimbangan Rasio error respons Proxy: Total error respons / Total jumlah respons.
  • Total error respons = Jumlah proxy/response_count dengan filter response_code != 200
  • Total jumlah respons = Jumlah proxy/response_count
Nilai minimum pemberitahuan Bergantung pada SLO untuk penginstalan. Instalasi produksi dan non-produksi mungkin memiliki ambang batas yang berbeda. Misalnya: Untuk produksi, picu notifikasi peristiwa jika rasio kesalahan respons proxy 500 adalah 5% selama 5 menit.
Kueri MQL dasbor Cloud Monitoring: 
fetch apigee.googleapis.com/Proxy
| metric 'apigee.googleapis.com/proxy/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/Proxy::apigee.googleapis.com/proxy/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 target/response_count untuk memantau error Target API tingkat respons yang tinggi. Diagram target/response_count menampilkan rasio permintaan dari Target API. Ini mungkin berguna untuk mengidentifikasi target mana yang mendapatkan rasio permintaan lebih tinggi atau lonjakan error dalam panggilan permintaan.

Jenis resource Target
Metrik target/response_count
Filter Menurut response_code != 200
Kelompokkan Menurut method dan semua Target label jenis resource
Agregator jumlah
Peringatan terkait pertimbangan Rasio error respons Proxy, misalnya: Total error respons / Total jumlah respons.
  • Total error respons = Jumlah target/response_count dengan filter response_code != 200
  • Total jumlah respons = Jumlah target/response_count
Nilai minimum pemberitahuan Bergantung pada SLO untuk penginstalan. Misalnya: Untuk produksi, picu sebuah peristiwa pemberitahuan, Jika rasio error respons target adalah 5% selama 3 menit.
Kueri MQL dasbor Cloud Monitoring: 
fetch apigee.googleapis.com/Target
| metric 'apigee.googleapis.com/target/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

Latensi proxy

Kasus penggunaan: Gunakan proxy/latensi untuk memantau latensi dari semua respons proxy API terhadap permintaan. Tujuan diagram proxy/latensi mungkin berguna untuk mengidentifikasi latensi di proxy API Apigee untuk latensi permintaan proxy API Anda secara keseluruhan.

Jenis resource Proxy
Metrik proxy/latensi
Kelompokkan Menurut method dan semua Proxy label jenis resource
Agregator p99 (persentil ke-99)
Peringatan terkait pertimbangan Nilai tinggi persentil latensi 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/Proxy
| metric 'apigee.googleapis.com/proxy/latencies'
| align delta(1m)
| every 1m
| group_by [metric.method],
    [value_latencies_percentile: percentile(value.latencies, 99)]

Latensi target

Kasus penggunaan: Gunakan target/latensi untuk memantau latensi dari semua respons target proxy API terhadap permintaan. Tujuan diagram target/latensi mengidentifikasi jumlah total waktu untuk proxy API Apigee target untuk merespons permintaan. Nilai ini tidak mencakup overhead proxy Apigee API.

Jenis resource Target
Metrik target/latensi
Kelompokkan Menurut method, persentil, dan semua Target label jenis resource
Agregator p99 (persentil ke-99)
Peringatan terkait pertimbangan Nilai tinggi persentil latensi 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/Target
    | metric 'apigee.googleapis.com/target/latencies'
    | align delta(1m)
    | every 1m
    | group_by [metric.method],
        [value_latencies_percentile: percentile(value.latencies, 99)]

Database

Cassandra

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

Rasio permintaan baca Cassandra

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

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 jumlah
Peringatan terkait pertimbangan Untuk setiap potensi masalah atau perubahan signifikan dalam pola kueri klien; misalnya lonjakan atau penurunan yang 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)]

Rasio permintaan tulis Cassandra

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

Jenis resource k8s_container
Metrik cassandra/clientrequest_rate
Filter Menurut scope = Read dan unit = OneMinuteRate
Kelompokkan Menurut scope, unit, dan semua k8s_container label jenis resource
Agregator jumlah
Peringatan terkait pertimbangan Untuk potensi masalah atau perubahan signifikan pada pola kueri klien; untuk contohnya lonjakan atau penurunan tiba-tiba yang tidak terduga dalam permintaan tulis yang memerlukan penyelidikan.
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 scope=Read) menyediakan Cassandra layanan membaca latensi permintaan (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 dari waktu ke waktu.

Jenis resource k8s_container
Metrik cassandra/clientrequest_latency
Filter Menurut scope = Read dan unit = 99thPercentile
Kelompokkan Menurut scope, unit, dan semua k8s_container label jenis resource
Agregator jumlah
Peringatan terkait pertimbangan Jika SLI latensi permintaan baca secara konsisten menampilkan latensi persentil ke-99 yang cenderung meningkat secara terus-menerus.
Nilai minimum pemberitahuan Bergantung pada SLO Anda untuk layanan Cassandra. Misalnya: Dalam produksi, picu notifikasi peristiwa jika nilai clientrequest_latency baca dari 99thPercentile adalah 5 detik untuk 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) menyediakan latensi permintaan tulis layanan Cassandra (pada persentil ke-99, persentil ke-95, atau ke-75 persentil). Metrik ini membantu memberikan gambaran keseluruhan performa {i>Cassandra<i} dan dapat menunjukkan perubahan pola penggunaan atau masalah yang muncul dari waktu ke waktu.

Jenis resource k8s_container
Metrik cassandra/clientrequest_latency
Filter Menurut scope = Write dan unit = 99thPercentile
Kelompokkan Menurut scope, unit, dan semua k8s_container label jenis resource
Agregator jumlah
Peringatan terkait pertimbangan Jika latensi permintaan tulis, SLI konsisten menampilkan latensi persentil ke-99 yang cenderung meningkat secara terus-menerus.
Nilai minimum pemberitahuan Bergantung pada SLO Anda untuk layanan Cassandra. Misalnya: dalam produksi, picu notifikasi peristiwa jika nilai tulis clientrequest_latency pada 99thPercentile adalah 5 detik untuk 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 Sinkronisasi Apigee menyediakan jumlah permintaan dan respons serta latensi antara bidang kontrol Apigee dan bidang runtime Hybrid. Instance sinkronisasi yang berjalan di bidang runtime diharapkan melakukan polling pada bidang kontrol secara rutin, mendownload kontrak, sama tersedia 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 Jenis resource k8s_container label
Agregator jumlah
Peringatan terkait pertimbangan Gunakan ini untuk kelainan lalu lintas, seperti lonjakan request_count yang tidak normal atau hapus pemberitahuan.
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 layanan Sinkronisasi yang diterima dari bidang kontrol Apigee. Bagan ini mungkin berguna untuk identifikasi apakah ada 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 Jenis resource k8s_container label
Kelompokkan Menurut
Agregator jumlah
Peringatan terkait pertimbangan Jika ada error dalam metrik upstream/response_count dengan kode respons non-200 dikembalikan dari bidang Kontrol Apigee, maka diperlukan penyelidikan lebih lanjut terhadap yang sama.
Nilai minimum pemberitahuan Bergantung pada SLO Anda 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 memberikan metrik SLI tingkat sistem. Label metrik SLI dapat difilter dan dikelompokkan untuk dipantau container tertentu dan penggunaan resource-nya. Untuk memantau cluster Runtime Apigee kondisi dan ketersediaan infrastruktur, admin cluster dapat memantau container dan pod seperti CPU, Mem, disk, dan jumlah mulai ulang container. Harap ikuti Dokumentasi GKE untuk detail selengkapnya tentang metrik dan label.

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
Sinkronisasi 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 menyediakan berapa kali container dimulai ulang. Diagram ini dapat berguna untuk mengidentifikasi apakah suatu penampung sering error/dimulai ulang. Penampung layanan tertentu dapat difilter menurut metrik label untuk pemantauan container layanan tertentu.

Berikut ini penggunaan metrik kubernetes.io/container/restart_count untuk Cassandra. Anda dapat menggunakan metrik ini untuk salah satu 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 Jenis resource k8s_container label
Agregator jumlah
Peringatan terkait pertimbangan Jika container sering dimulai ulang, penyelidikan lebih lanjut diperlukan untuk root penyebabnya. Ada beberapa alasan mengapa penampung dapat dimulai ulang, seperti OOMKilled, {i>disk<i} data penuh, dan masalah konfigurasi, sebagai contoh.
Nilai minimum pemberitahuan Bergantung pada SLO untuk penginstalan. Misalnya: Untuk produksi, picu notifikasi peristiwa. Jika penampung memulai ulang lebih sering dari 5 kali dalam 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)]