Memecahkan masalah observabilitas dan telemetri di Cloud Service Mesh

Bagian ini menjelaskan masalah umum Cloud Service Mesh dan cara mengatasinya. Jika Anda memerlukan bantuan tambahan, lihat Mendapatkan dukungan.

Dalam telemetri Cloud Service Mesh, proxy Envoy memanggil Google Cloud Observability API secara berkala untuk melaporkan data telemetri. Jenis panggilan API menentukan frekuensinya:

  • Logging: setiap ~10 detik
  • Metrik: setiap ~1 menit
  • Edges (Context API/Topology view): laporan inkremental setiap ~1 menit, dengan laporan lengkap setiap ~10 menit.
  • Traces: ditentukan oleh frekuensi pengambilan sampel yang Anda konfigurasi (biasanya, satu dari setiap 100 permintaan).

Dasbor telemetri mengumpulkan data dari Confluence dan Google Cloud Observability untuk menampilkan berbagai dasbor yang berfokus pada layanan.

Memastikan bahwa konfigurasi Istio telemetry API paling banyak satu

Bagian ini hanya berlaku untuk bidang kontrol Traffic Director terkelola.

Jika Anda sudah memiliki CR Istio telemetry API yang ada, untuk mempertahankan setelan penyesuaian sebelumnya di CR Istio telemetry yang ada, Anda harus menyertakannya dalam CR Istio telemetry API baru.

Untuk mencantumkan konfigurasi telemetry API, jalankan perintah berikut. Pastikan bahwa konfigurasi Istio telemetry API paling banyak satu.

kubectl -n istio-system get telemetry

Dasbor layanan tidak memiliki layanan

Dasbor hanya menampilkan layanan HTTP(S)/gRPC. Jika layanan Anda harus ada dalam daftar, pastikan telemetri Cloud Service Mesh mengidentifikasinya sebagai layanan HTTP.

Jika layanan Anda tetap tidak ada, pastikan konfigurasi layanan Kubernetes ada di cluster Anda.

  • Tinjau daftar semua layanan Kubernetes:

    kubectl get services --all-namespaces
  • Tinjau daftar layanan Kubernetes di namespace tertentu:

    kubectl get services -n YOUR_NAMESPACE

Metrik tidak ada atau salah untuk layanan

Jika ada metrik yang tidak ada atau salah untuk layanan di dasbor Layanan, lihat bagian berikut untuk mengetahui kemungkinan resolusi.

Memastikan proxy Sidecar ada dan telah disuntikkan dengan benar

Namespace mungkin tidak memiliki label untuk injeksi otomatis, atau injeksi manual gagal. Pastikan pod di namespace memiliki setidaknya dua container dan salah satu container tersebut adalah container istio-proxy:

kubectl -n YOUR_NAMESPACE get pods

Memastikan konfigurasi telemetri ada

Untuk memastikan filter Google Cloud Observability dikonfigurasi, kumpulkan dump konfigurasi dari setiap proxy dan cari keberadaan filter Google Cloud Observability:

kubectl debug --image istio/base --target istio-proxy -it YOUR_POD_NAME -n YOUR_NAMESPACE curl localhost:15000/config_dump

Dalam output perintah sebelumnya, cari filter Google Cloud Observability, yang terlihat seperti berikut:

"config": {
    "root_id": "stackdriver_inbound",
    "vm_config": {
        "vm_id": "stackdriver_inbound",
        "runtime": "envoy.wasm.runtime.null",
        "code": {
            "local": {
                "inline_string": "envoy.wasm.null.stackdriver"
             }
         }
     },
     "configuration": "{....}"
}

Memastikan Cloud Service Mesh mengidentifikasi layanan HTTP

Metrik tidak akan muncul di antarmuka pengguna jika port layanan untuk layanan Kubernetes tidak diberi nama http atau nama apa pun dengan awalan http-. Pastikan layanan memiliki nama yang tepat untuk portnya.

Memastikan Cloud Monitoring API diaktifkan untuk project

Pastikan Cloud Monitoring API diaktifkan di dasbor API & Layanan di Google Cloud konsol, yang merupakan default.

Memastikan tidak ada error yang dilaporkan ke Cloud Monitoring API

Di dasbor API & Layanan Google Cloud konsol, buka URL grafik Traffic By Response Code:

https://console.cloud.google.com/apis/api/monitoring.googleapis.com/metrics?folder=&organizationId=&project=YOUR_PROJECT_ID

Jika Anda melihat pesan error, mungkin ada masalah yang memerlukan penyelidikan lebih lanjut. Secara khusus, cari sejumlah besar pesan error 429, yang menunjukkan potensi masalah kuota. Lihat bagian berikutnya untuk langkah-langkah pemecahan masalah.

Memastikan kuota yang benar untuk Cloud Monitoring API

Di Google Cloud konsol, buka menu IAM & Admin dan pastikan ada opsi Kuota. Anda dapat mengakses halaman ini langsung menggunakan URL:

https://console.cloud.google.com/iam-admin/quotas?project=YOUR_PROJECT_ID

Halaman ini menampilkan kumpulan kuota lengkap untuk project, tempat Anda dapat menelusuri Cloud Monitoring API.

Memastikan tidak ada log error di proxy Envoy

Tinjau log untuk proxy yang dimaksud, dengan menelusuri instance pesan error:

kubectl -n YOUR_NAMESPACE logs YOUR_POD_NAME -c istio-proxy

Namun, abaikan pesan peringatan seperti berikut, yang normal:

[warning][filter] [src/envoy/http/authn/http_filter_factory.cc:83]
mTLS PERMISSIVE mode is used, connection can be either plaintext or TLS,
and client cert can be omitted. Please consider to upgrade to mTLS STRICT mode
for more secure configuration that only allows TLS connection with client cert.
See https://istio.io/docs/tasks/security/mtls-migration/ [warning][config]
[bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91]
gRPC config stream closed: 13

Memastikan metric.mesh_uid ditetapkan dengan benar

Buka Metrics Explorer dan jalankan kueri MQL berikut:

fetch istio_canonical_service
| metric 'istio.io/service/server/request_count'
| align delta(1m)
| every 1m
| group_by [metric.destination_canonical_service_namespace, metric.destination_canonical_service_name, metric.mesh_uid]

Pastikan semua layanan yang diharapkan melaporkan metrik, dan metric.mesh_uid dalam format proj-<Cloud Service Mesh fleet project number>.

Jika metric.mesh_uid memiliki nilai lain, dasbor Cloud Service Mesh tidak akan menampilkan metrik. metric.mesh_uid ditetapkan saat Cloud Service Mesh diinstal di cluster, jadi selidiki metode penginstalan Anda untuk melihat apakah ada cara untuk menetapkannya ke nilai yang diharapkan.

Data telemetri tidak ada atau salah untuk layanan

Secara default, Cloud Monitoring dan Cloud Logging diaktifkan di Google Cloud project Anda saat Anda menginstal Cloud Service Mesh. Untuk melaporkan data telemetri, setiap proxy sidecar yang disuntikkan ke pod layanan Anda memanggil Cloud Monitoring API dan Cloud Logging API. Setelah men-deploy beban kerja, perlu waktu sekitar satu atau dua menit agar data telemetri ditampilkan di Google Cloud konsol. Cloud Service Mesh otomatis memperbarui dasbor layanan:

  • Untuk metrik, proxy sidecar memanggil Cloud Monitoring API kira-kira setiap menit.
  • Untuk memperbarui grafik Topologi, proxy sidecar mengirim laporan inkremental kira-kira setiap menit dan laporan lengkap sekitar setiap sepuluh menit.
  • Untuk logging, proxy sidecar memanggil Cloud Logging API kira-kira setiap sepuluh detik.
  • Untuk tracing, Anda harus mengaktifkan Cloud Trace. Trace dilaporkan sesuai dengan frekuensi pengambilan sampel yang telah Anda konfigurasi (biasanya, satu dari setiap 100 permintaan).

Metrik hanya ditampilkan untuk layanan HTTP di halaman Metrik Cloud Service Mesh. Jika Anda tidak melihat metrik apa pun, pastikan semua pod di namespace untuk layanan aplikasi Anda memiliki proxy sidecar yang disuntikkan:

kubectl get pod -n YOUR_NAMESPACE --all

Dalam output, perhatikan bahwa kolom READY menampilkan dua container untuk setiap beban kerja Anda: container utama dan container untuk proxy sidecar.

Selain itu, dasbor Layanan hanya menampilkan metrik server, sehingga data telemetri mungkin tidak muncul jika klien tidak berada di mesh atau jika dikonfigurasi untuk hanya melaporkan metrik klien (seperti gateway ingress).