Panduan pemantauan cluster

Ringkasan

Panduan ini memberikan panduan tentang apa yang harus dipantau dan cara memantau deployment Apigee Hybrid. Panduan ini ditujukan untuk administrator cluster campuran 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 layanan aplikasi dan 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 tersedia untuk digunakan, selain label metrik. Kombinasi label Jenis Resource dan label metrik harus digunakan untuk memantau kondisi dan performa cluster secara efektif.

Batas pemberitahuan: Dalam kondisi ideal, batas pemberitahuan akan jelas dan dokumentasi yang diberikan akan mencantumkan nilai yang akan memicu pemberitahuan. Pada kenyataannya, Apigee tidak dapat menentukan dengan jelas apa yang dimaksud dengan performa yang dapat diterima dan apa yang dimaksud dengan penggunaan resource layanan dan infrastruktur yang berbahaya. Nilai nilai minimum pemberitahuan akan sangat bervariasi bergantung pada pola traffic tertentu dan perjanjian SLO/SLA.

Pengoptimalan dan penentuan nilai minimum pemberitahuan adalah proses yang sedang berlangsung karena dapat berubah seiring dengan penggunaan layanan dan infrastruktur. Gunakan nilai minimum Peringatan dan Penting 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.
  • Penting: Nilai > Nilai minimum penting.

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 tampilan "normal", lalu menyesuaikan nilai minimum pemberitahuan yang sesuai.

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:

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 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 frekuensi permintaan yang lebih tinggi, pola frekuensi permintaan, dan lonjakan abnormal dalam panggilan permintaan untuk proxy tertentu. Lonjakan abnormal yang tidak terduga dalam traffic API dapat menjadi masalah keamanan terkait bot atau serangan pada proxy API. Demikian pula, penurunan traffic cloud secara keseluruhan menunjukkan masalah pada klien atau konektivitas dari komponen upstream Apigee.

Jenis resource Proxy
Metrik proxy/request_count
Kelompokkan Menurut method dan semua label jenis resource Proxy
Aggregator sum
Pertimbangan pemberitahuan Peristiwa seperti notifikasi lonjakan/penurunan request_count abnormal
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 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 abnormal dalam panggilan permintaan untuk target tertentu.

Jenis resource Target
Metrik target/request_count
Kelompokkan Menurut method dan semua label jenis resource Target
Aggregator sum
Pertimbangan pemberitahuan Peristiwa seperti notifikasi lonjakan/penurunan request_count abnormal
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 rasio respons error proxy. Diagram proxy/response_count menampilkan rasio permintaan untuk Proxy API. Diagram ini berguna untuk memahami proxy mana yang mendapatkan rasio error permintaan yang lebih tinggi atau lonjakan error abnormal 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
Aggregator sum
Pertimbangan pemberitahuan 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. 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/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 rasio 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 yang lebih tinggi atau lonjakan error abnormal dalam panggilan permintaan.

Jenis resource Target
Metrik target/response_count
Filter Menurut response_code != 200
Kelompokkan Menurut method dan semua label jenis resource Target
Aggregator sum
Pertimbangan pemberitahuan 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 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/latency untuk memantau latensi semua respons proxy API terhadap permintaan. Diagram proxy/latensi mungkin berguna untuk mengidentifikasi latensi di proxy API Apigee untuk latensi permintaan proxy API secara keseluruhan.

Jenis resource Proxy
Metrik proxy/latencies
Kelompokkan Menurut method dan semua label jenis resource Proxy
Aggregator p99 (persentil ke-99)
Pertimbangan pemberitahuan Nilai persentil latensi p99 yang tinggi.
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)]

Target latensi

Kasus penggunaan: Gunakan target/latencies untuk memantau latensi semua respons target proxy API terhadap permintaan. Diagram target/latensi mengidentifikasi jumlah total waktu yang diperlukan target proxy API Apigee untuk merespons permintaan. Nilai ini tidak mencakup overhead proxy Apigee API.

Jenis resource Target
Metrik target/latencies
Kelompokkan Menurut method, persentil, dan semua label jenis resource Target
Aggregator p99 (persentil ke-99)
Pertimbangan pemberitahuan Nilai persentil latensi p99 yang tinggi.
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 Cassandra Apigee 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 mengetahui kondisi layanan Cassandra.

Rasio permintaan baca Cassandra

Kasus penggunaan: Metrik SLI cassandra/clientrequest_rate (dengan cakupan=Read) memberikan insight tentang kecepatan rata-rata permintaan baca layanan Cassandra pada waktu tertentu. Metrik ini membantu pemahaman 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
Aggregator sum
Pertimbangan pemberitahuan 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 cakupan=Tulis) memberikan insight tentang kecepatan 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 scope, unit, dan semua label jenis resource k8s_container
Aggregator sum
Pertimbangan pemberitahuan 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 SLI cassandra/clientrequest_latency (dengan cakupan=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 apa pun dalam 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 label jenis resource k8s_container
Aggregator 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: 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 cakupan=Tulis) 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 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 label jenis resource k8s_container
Aggregator 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: dalam produksi, picu notifikasi peristiwa jika nilai clientrequest_latency tulis 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 di platform runtime diharapkan untuk melakukan polling pada platform 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
Aggregator sum
Pertimbangan pemberitahuan Gunakan ini untuk mengetahui kelainan traffic, seperti lonjakan atau pemberitahuan penurunan request_count yang tidak wajar.
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 platform Runtime Apigee Hybrid dan Platform 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
Aggregator sum
Pertimbangan pemberitahuan Jika ada error dalam metrik upstream/response_count dengan kode respons non-200 yang ditampilkan dari panel 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 Sinkronisasi 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 jumlah CPU, Mem, disk, dan 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
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 jumlah kali penampung dimulai ulang. Diagram ini mungkin berguna untuk mengidentifikasi apakah penampung sering mengalami error/memulai ulang. Penampung layanan tertentu dapat difilter menurut label metrik untuk pemantauan penampung layanan tertentu.

Berikut ini menunjukkan penggunaan metrik kubernetes.io/container/restart_count untuk penampung Cassandra. Anda dapat menggunakan metrik ini untuk setiap 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
Aggregator sum
Pertimbangan pemberitahuan Jika penampung sering dimulai ulang, penyelidikan lebih lanjut diperlukan untuk mengetahui penyebab utamanya. Ada beberapa alasan penampung dapat dimulai ulang, seperti OOMKilled, disk data penuh, dan masalah konfigurasi, untuk beberapa nama.
Nilai minimum pemberitahuan Bergantung pada SLO untuk penginstalan. Misalnya: Untuk produksi, picu notifikasi peristiwa, Jika penampung dimulai ulang lebih 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)]