Panduan pemantauan cluster

Ringkasan

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

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

Cluster Hybrid Apigee 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 terkait. 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: Pada dasarnya, nilai minimum pemberitahuan akan terlihat jelas dan dokumentasi yang diberikan akan mencantumkan nilai yang harus memicu pemberitahuan. Kenyataannya, kurang jelas bagi Apigee untuk menentukan definisi seperti apa performa yang dapat diterima dan apa yang termasuk pemanfaatan resource berbahaya dari layanan dan infrastruktur. Nilai minimum pemberitahuan akan sangat bervariasi, bergantung pada pola traffic dan perjanjian SLO/SLA tertentu.

Pengoptimalan dan penentuan batas 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 penting.
  • Kritis: Nilai > Nilai minimum penting.

Pelanggan sebaiknya menggunakan alat yang disediakan untuk menentukan batas yang optimal, baik itu dasbor Cloud Monitoring yang dapat dibuat pelanggan dengan MQL yang disediakan di bawah atau analisis Apigee, untuk mengidentifikasi tampilan "normal", lalu menyesuaikan batas pemberitahuan tersebut.

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

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 memberikan cakupan untuk memantau traffic Apigee API.

Rasio Permintaan

Jumlah permintaan proxy

Kasus penggunaan: Gunakan proxy/request_count untuk memantau jumlah permintaan proxy. 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 abnormal pada panggilan permintaan untuk proxy tertentu. Setiap 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 masalah dengan klien atau konektivitas dari komponen upstream Apigee.

Jenis resource Proxy
Metrik proxy/request_count
Kelompokkan Menurut method dan semua label jenis resource Proxy
Agregator jumlah
Pertimbangan notifikasi 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)]

Target jumlah permintaan

Kasus penggunaan: Gunakan target/request_count untuk memantau jumlah permintaan target runtime Apigee. Diagram target/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 yang tidak wajar dalam panggilan permintaan untuk target tertentu.

Jenis resource Target
Metrik target/request_count
Kelompokkan Menurut method dan semua label jenis resource Target
Agregator jumlah
Pertimbangan notifikasi 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 tingkat respons error proxy. Diagram proxy/response_count menampilkan rasio 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 Proxy
Metrik proxy/response_count
Filter Menurut response_code != 200
Kelompokkan Menurut method, response_code, fault_code, fault_source, apigee_fault, dan semua label jenis resource Proxy
Agregator jumlah
Pertimbangan notifikasi 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 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/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 kebijakan Pemberitahuan operasi Google Cloud MQL: 
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'%'

Target jumlah respons error

Kasus penggunaan: Gunakan target/response_count untuk memantau tingkat respons error Target API. Diagram target/response_count menampilkan rasio 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 Target
Metrik target/response_count
Filter Menurut response_code != 200
Kelompokkan Menurut method dan semua label jenis resource Target
Agregator jumlah
Pertimbangan notifikasi 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 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/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/latencies untuk memantau latensi semua respons proxy API terhadap permintaan. Diagram proxy/latensi mungkin berguna untuk mengidentifikasi latensi dalam proxy API Apigee terhadap keseluruhan latensi permintaan proxy API Anda.

Jenis resource Proxy
Metrik proxy/latensi
Kelompokkan Menurut method dan semua label jenis resource Proxy
Agregator p99 (persentil ke-99)
Pertimbangan notifikasi Nilai tinggi persentil latensi p99.
Nilai minimum pemberitahuan Tergantung 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 semua respons target proxy API terhadap permintaan. Diagram target/latency mengidentifikasi jumlah total waktu bagi target proxy API Apigee untuk merespons permintaan. Nilai ini tidak termasuk overhead proxy Apigee API.

Jenis resource Target
Metrik target/latensi
Kelompokkan Menurut method, persentil, dan semua label jenis resource Target
Agregator p99 (persentil ke-99)
Pertimbangan notifikasi Nilai tinggi persentil latensi p99.
Nilai minimum pemberitahuan Tergantung SLO untuk penginstalan. Misalnya: Untuk produksi, picu notifikasi peristiwa. Jika nilai persentil latensi target p99 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 Cassandra SLI. 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 mengetahui kondisi layanan Cassandra.

Rasio permintaan baca Cassandra

Kasus penggunaan: Metrik SLI cassandra/clientrequest_rate (dengan scope=Read) memberikan insight tentang tarif 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 label jenis resource scope, unit, dan semua k8s_container
Agregator jumlah
Pertimbangan notifikasi Untuk kemungkinan 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 penulisan Cassandra

Kasus penggunaan: Metrik SLI cassandra/clientrequest_rate (dengan scope=Write) 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 setiap 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 SLI cassandra/clientrequest_Latency (dengan scope=Read) memberikan 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 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, SLI secara konsisten menampilkan tren latensi persentil ke-99 ke atas 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 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 tampilan keseluruhan performa Cassandra dan dapat menunjukkan perubahan pola penggunaan atau masalah yang muncul 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 menampilkan latensi persentil ke-99, yang cenderung naik 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 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 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 berkala, 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 label jenis resource k8s_container
Agregator jumlah
Pertimbangan notifikasi Gunakan ini untuk ketidaknormalan traffic, seperti pemberitahuan 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 Synchronizer 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 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 Runtime Apigee, admin cluster dapat memantau penggunaan container dan resource umum pod seperti jumlah mulai ulang CPU, Mem, disk, dan container. Silakan 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
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 memberikan berapa kali container dimulai ulang. Diagram ini dapat berguna untuk mengidentifikasi apakah container mengalami error/memulai ulang terlalu sering. 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 cluster_name, namespace_name, pod_name, container_name, dan semua label jenis resource 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, seperti OOMKilled, disk data penuh, dan masalah konfigurasi.
Nilai minimum pemberitahuan Bergantung pada SLO untuk penginstalan. Misalnya: Untuk produksi, picu notifikasi peristiwa. Jika container 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)]