Menyelesaikan masalah kemampuan observasi 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
  • Edge (tampilan Context API/Topologi): laporan inkremental setiap ~1 menit, dengan laporan lengkap setiap ~10 menit.
  • Pelacakan: 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.

Tidak ada layanan di dasbor layanan

Dasbor hanya menampilkan layanan HTTP(S)/gRPC. Jika layanan Anda seharusnya ada dalam daftar tersebut, 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 dalam namespace tertentu:

kubectl get services -n YOUR_NAMESPACE

Metrik layanan tidak ada atau salah

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

Memastikan proxy file bantuan ada dan telah dimasukkan dengan benar

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

kubectl -n YOUR_NAMESPACE get pods

Memverifikasi bahwa konfigurasi telemetri sudah ada

Gunakan EnvoyFilters di namespace istio-system untuk mengonfigurasi telemetri. Tanpa konfigurasi tersebut, Cloud Service Mesh tidak akan melaporkan data ke Google Cloud Observability.

Pastikan konfigurasi Kemampuan Observasi Google Cloud (dan konfigurasi pertukaran metadata) sudah ada:

kubectl -n istio-system get envoyfilter

Output yang diharapkan terlihat mirip dengan yang berikut ini:

NAME                        AGE
metadata-exchange-1.4       13d
metadata-exchange-1.5       13d
stackdriver-filter-1.4      13d
stackdriver-filter-1.5      13d
...

Untuk mengonfirmasi lebih lanjut bahwa filter Kemampuan Observasi Google Cloud dikonfigurasi dengan benar, kumpulkan dump konfigurasi dari setiap proxy dan cari keberadaan filter Google Cloud Observability:

kubectl exec YOUR_POD_NAME -n YOUR_NAMESPACE -c istio-proxy curl localhost:15000/config_dump

Pada 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": "{....}"
}

Memverifikasi bahwa Cloud Service Mesh mengidentifikasi layanan HTTP

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

Memastikan Cloud Monitoring API sudah diaktifkan untuk project

Pastikan Cloud Monitoring API diaktifkan di dasbor APIs & Services di Konsol Google Cloud, yang merupakan setelan default.

Memverifikasi bahwa tidak ada pelaporan error ke Cloud Monitoring API

Di dasbor API & Layanan Konsol Google Cloud, 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 ini adalah masalah yang memerlukan penyelidikan lebih lanjut. Secara khusus, cari pesan error 429 dalam jumlah besar, yang menunjukkan adanya potensi masalah kuota. Baca bagian selanjutnya untuk mengetahui langkah-langkah pemecahan masalahnya.

Memverifikasi kuota yang benar untuk Cloud Monitoring API

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

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

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

Memverifikasi bahwa tidak ada log error di proxy Envoy

Tinjau log untuk proxy yang dimaksud, lalu telusuri instance pesan error:

kubectl -n YOUR_NAMESPACE logs YOUR_POD_NAME -c istio-proxy

Namun, abaikan pesan peringatan seperti berikut, yang merupakan hal 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

Pastikan metric.mesh_uid disetel 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-nya 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 untuk layanan tidak ada atau salah

Secara default, Cloud Monitoring dan Cloud Logging diaktifkan di project Google Cloud Anda saat Anda menginstal Cloud Service Mesh. Untuk melaporkan data telemetri, setiap proxy file bantuan yang dimasukkan ke pod layanan Anda akan memanggil Cloud Monitoring API dan Cloud Logging API. Setelah men-deploy workload, perlu waktu sekitar satu atau dua menit agar data telemetri ditampilkan di Konsol Google Cloud. Cloud Service Mesh terus memperbarui dasbor layanan secara otomatis:

  • Untuk metrik, proxy file bantuan memanggil Cloud Monitoring API kira-kira setiap menit.
  • Untuk memperbarui grafik Topology, proxy file bantuan mengirim laporan inkremental kira-kira setiap menit dan laporan lengkap setiap sepuluh menit.
  • Untuk logging, proxy file bantuan memanggil Cloud Logging API kira-kira setiap sepuluh detik.
  • Untuk pelacakan, Anda harus mengaktifkan Cloud Trace. Rekaman aktivitas 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 bahwa proxy file bantuan dimasukkan ke semua pod di namespace untuk layanan aplikasi Anda:

kubectl get pod -n YOUR_NAMESPACE --all

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

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