Anda sedang melihat dokumentasi Service Mesh v1.22.

Versi yang tersedia

Cloud Service Mesh
arsip 1.22
arsip 1.21
arsip 1.20
arsip 1.19
arsip 1.18

Halaman ini diterjemahkan oleh Cloud Translation API.

Menyelesaikan masalah visibilitas dan telemetri di Cloud Service Mesh

Bagian ini menjelaskan masalah umum Cloud Service Mesh dan cara menyelesaikannya. 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.
Rekaman aktivitas: ditentukan oleh frekuensi pengambilan sampel yang Anda konfigurasikan (biasanya, satu dari setiap 100 permintaan).

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

Memverifikasi bahwa tidak ada lebih dari satu konfigurasi API telemetri Istio

Bagian ini hanya berlaku untuk bidang kontrol Cloud Service Mesh terkelola.

Untuk menampilkan konfigurasi API telemetri, jalankan perintah berikut. Pastikan ada maksimal satu konfigurasi API telemetri Istio.

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 bahwa 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 untuk layanan tidak ada atau salah

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

Memverifikasi bahwa proxy Sidecar ada dan telah dimasukkan dengan benar

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

kubectl -n YOUR_NAMESPACE get pods

Memverifikasi bahwa konfigurasi telemetri ada

Untuk mengonfirmasi bahwa 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

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 diberi nama http atau nama apa pun dengan awalan http-. Pastikan layanan memiliki nama yang tepat untuk port-nya.

Memverifikasi bahwa Cloud Monitoring API diaktifkan untuk project

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

Memverifikasi bahwa tidak ada error yang dilaporkan ke Cloud Monitoring API

Di dasbor Layanan & API 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 ada masalah yang memerlukan penyelidikan lebih lanjut. Secara khusus, cari pesan error 429 dalam jumlah besar, yang menunjukkan potensi masalah kuota. Lihat bagian berikutnya untuk mengetahui langkah-langkah pemecahan masalah.

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 secara langsung menggunakan URL:

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

Halaman ini menampilkan kumpulan lengkap kuota 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 merupakan hal yang wajar:

[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 bahwa 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 tidak ada atau salah untuk layanan

Secara default, Cloud Monitoring dan Cloud Logging diaktifkan di project Google Cloud saat Anda menginstal Cloud Service Mesh. Untuk melaporkan data telemetri, setiap proxy file bantuan yang dimasukkan ke dalam pod layanan Anda akan 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 konsol Google Cloud. Cloud Service Mesh secara otomatis memperbarui dasbor layanan:

Untuk metrik, proxy sidecar memanggil Cloud Monitoring API kira-kira setiap menit.
Untuk memperbarui grafik Topologi, proxy sidecar mengirimkan laporan inkremental kurang lebih setiap menit dan laporan lengkap sekitar setiap sepuluh menit.
Untuk logging, proxy sidecar 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 konfigurasikan (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 telah memasukkan proxy file bantuan:

kubectl get pod -n YOUR_NAMESPACE --all

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

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