Bagian berikut menjelaskan cara memeriksa status mesh dan meninjau berbagai log yang berisi detail berguna untuk membantu Anda memecahkan masalah.
Menafsirkan metrik bidang kontrol
Saat menginstal Anthos Service Mesh menggunakan profil asm-gcp
, Istiod mengekspor
metrik ke Kemampuan Observasi Google Cloud untuk pemantauan secara default. Istiod memberi awalan pada metrik ini dengan istio.io/control
dan memberikan insight mengenai status bidang kontrol, seperti jumlah proxy yang terhubung ke setiap instance bidang kontrol, peristiwa konfigurasi, push, dan validasi.
Amati atau pecahkan masalah bidang kontrol menggunakan langkah-langkah berikut.
Muat dasbor contoh:
git clone https://github.com/GoogleCloudPlatform/monitoring-dashboard-samples && cd monitoring-dashboard-samples && git checkout asm
Instal dasbor Anthos Service Mesh:
gcloud monitoring dashboards create --config-from-file=dashboards/servicemesh/anthos-service-mesh-control-plane-monitoring.json
Cari dasbor bernama
Istio Control Plane Dashboard
dalam daftar. Untuk informasi selengkapnya, lihat Melihat dasbor terinstal.Jika tidak menggunakan profil
asm-gcp
, Anda masih dapat mengaktifkan metrik bidang kontrol dengan menambahkan variabel lingkungan ke deployment Istiod:- name: ENABLE_STACKDRIVER_MONITORING value: "true"
Selain itu, Anda dapat menambahkan variabel lingkungan ini menggunakan opsi penginstalan,
components.pilot.k8s.env
.
Untuk mengetahui daftar lengkap metrik yang tersedia, lihat Metrik yang diekspor.
Mendiagnosis penundaan konfigurasi
Langkah-langkah berikut menjelaskan cara menggunakan metrik pilot_proxy_convergence_time
untuk mendiagnosis penundaan antara perubahan konfigurasi dan semua konvergensi proxy.
Jalankan perintah shell di pod:
kubectl exec -it $(kubectl get pod -l app=pilot -o jsonpath='{.items[0].metadata.name}' -n istio-system) -n istio-system -c istio-proxy -- curl -s
Akses
localhost:15014
dangrep
untukconvergence
dalam metrik:curl http://localhost:15014/metrics | grep convergence
Menafsirkan log akses Kemampuan observasi Google Cloud
Informasi berikut menjelaskan cara menggunakan log akses Kemampuan observasi Google Cloud untuk memecahkan masalah koneksi.
Anthos Service Mesh mengekspor data ke log akses Kemampuan observasi Google Cloud yang dapat membantu Anda men-debug jenis masalah berikut:
- Kegagalan dan arus traffic
- Pemilihan rute permintaan end-to-end
Log traffic/akses kemampuan observasi Google Cloud diaktifkan secara default di profil asm-gcp
di seluruh mesh. Namun, jika belum diaktifkan, Anda dapat menggunakan perintah berikut:
istioctl install --set profile=PROFILE_NAME --set revision==ASM_VERSION \ --set values.telemetry.v2.stackdriver.enabled=true \ --set values.telemetry.v2.stackdriver.logging=true
Ada dua jenis log akses:
Log akses server memberikan tampilan permintaan dari sisi server. Objek tersebut berada di
server-accesslog-stackdriver
, yang dilampirkan ke resource yang dimonitork8s_container
. Gunakan sintaksis URL berikut untuk menampilkan log akses sisi server:https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"&project=PROJECT_ID
Log akses klien memberikan tampilan dari sisi klien terhadap permintaan. Objek tersebut berada di
client-accesslog-stackdriver
, yang dilampirkan ke resource yang dimonitork8s_pod
. Gunakan sintaksis URL berikut untuk menampilkan log akses sisi klien: .https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/client-accesslog-stackdriver"&project=PROJECT_ID
Hanya log error klien yang diaktifkan secara default untuk mengurangi biaya logging, tetapi Anda dapat mengaktifkan semua log klien (keberhasilan dan error) menggunakan perintah berikut:
istioctl install --set profile=PROFILE_NAME --set revision==ASM_VERSION
--set values.telemetry.v2.stackdriver.enabled=true
--set values.telemetry.v2.stackdriver.outboundAccessLogging=FULL
Log akses berisi informasi berikut:
- Properti permintaan HTTP, seperti ID, URL, ukuran, latensi, dan header umum.
- Informasi workload sumber dan tujuan, seperti nama, namespace, identitas, dan label umum.
- Informasi revisi dan layanan kanonis sumber dan tujuan.
- Jika perekaman aktivitas diaktifkan, log akan berisi informasi rekaman aktivitas, seperti pengambilan sampel, ID trace, dan ID span.
Informasi yang ditampilkan di log akses Kemampuan observasi Google Cloud berasal dari log akses Envoy, saat Anda mengaktifkannya di konfigurasi Istio. Header tersebut berisi header berikut:
route_name
upstream_cluster
X-Envoy-Original-Path
X-Envoy-Original-Host
Ini adalah contoh entri log:
{ "insertId": "1j84zg8g68vb62z", "httpRequest": { "requestMethod": "GET", "requestUrl": "http://35.235.89.201:80/productpage", "requestSize": "795", "status": 200, "responseSize": "7005", "remoteIp": "10.168.0.26:0", "serverIp": "10.36.3.153:9080", "latency": "0.229384205s", "protocol": "http" }, "resource": { "type": "k8s_container", "labels": { "cluster_name": "istio-e2e22", "namespace_name": "istio-bookinfo-1-68819", "container_name": "productpage", "project_id": "***", "location": "us-west2-a", "pod_name": "productpage-v1-64794f5db4-8xbtf" } }, "timestamp": "2020-08-13T21:37:42.963881Z", "severity": "INFO", "labels": { "protocol": "http", "upstream_host": "127.0.0.1:9080", "source_canonical_service": "istio-ingressgateway", "source_namespace": "istio-system", "x-envoy-original-path": "", "source_canonical_revision": "latest", "connection_id": "32", "upstream_cluster": "inbound|9080|http|productpage.istio-bookinfo-1-68819.svc.cluster.local", "requested_server_name": "outbound_.9080_._.productpage.istio-bookinfo-1-68819.svc.cluster.local", "destination_version": "v1", "destination_workload": "productpage-v1", "source_workload": "istio-ingressgateway", "destination_canonical_revision": "v1", "mesh_uid": "cluster.local", "source_principal": "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account", "x-envoy-original-dst-host": "", "service_authentication_policy": "MUTUAL_TLS", "destination_principal": "spiffe://cluster.local/ns/istio-bookinfo-1-68819/sa/bookinfo-productpage", "response_flag": "-", "log_sampled": "false", "destination_service_host": "productpage.istio-bookinfo-1-68819.svc.cluster.local", "destination_name": "productpage-v1-64794f5db4-8xbtf", "destination_canonical_service": "productpage", "destination_namespace": "istio-bookinfo-1-68819", "source_name": "istio-ingressgateway-6845f6d664-lnfvp", "source_app": "istio-ingressgateway", "destination_app": "productpage", "request_id": "39013650-4e62-9be2-9d25-78682dd27ea4", "route_name": "default" }, "logName": "projects/***/logs/server-accesslog-stackdriver", "trace": "projects/***t/traces/466d77d15753cb4d7749ba5413b5f70f", "receiveTimestamp": "2020-08-13T21:37:48.758673203Z", "spanId": "633831cb1fda4fd5", "traceSampled": true }
Anda dapat menggunakan log ini dengan berbagai cara:
- Mengintegrasikan dengan Cloud Trace, yang merupakan fitur opsional di Anthos Service Mesh.
- Ekspor log traffic ke BigQuery, tempat Anda dapat menjalankan kueri, seperti memilih semua permintaan, memerlukan waktu lebih dari 5 detik.
- Membuat metrik berbasis log.
- Memecahkan masalah error
404
dan503
Memecahkan masalah error 404
dan 503
Contoh berikut menjelaskan cara menggunakan log ini untuk memecahkan masalah saat
permintaan gagal dengan kode respons 404
atau 503
.
Di log akses klien, telusuri entri seperti berikut:
httpRequest: { requestMethod: "GET" requestUrl: "://IP_ADDRESS/src/Util/PHP/eval-stdin.php" requestSize: "2088" status: 404 responseSize: "75" remoteIp: "10.168.0.26:34165" serverIp: "10.36.3.149:8080" latency: "0.000371440s" protocol: "http" }
Pilih label di entri log akses. Temukan kolom
response_flag
yang terlihat seperti berikut:response_flag: "NR"
Nilai
NR
adalah akronim untukNoRoute
, yang berarti tidak ada rute yang ditemukan untuk tujuan atau tidak ada rantai filter yang cocok untuk koneksi downstream. Anda juga dapat menggunakan labelresponse_flag
untuk memecahkan masalah error503
.Jika Anda melihat error
503
di log akses klien dan server, pastikan nama port yang ditetapkan untuk setiap layanan cocok dengan nama protokol yang digunakan di antara keduanya. Misalnya, jika klien biner golang terhubung ke server golang menggunakan HTTP, tetapi port bernamahttp2
, protokol tidak akan dinegosiasikan secara otomatis dengan benar.
Untuk mengetahui informasi selengkapnya, lihat tanda respons.
Menafsirkan log Envoy
Langkah-langkah berikut menjelaskan cara menggunakan log akses proxy Envoy untuk menampilkan traffic di antara kedua ujung koneksi untuk tujuan pemecahan masalah.
Log akses Envoy berguna untuk mendiagnosis masalah seperti:
- Kegagalan dan arus traffic
- Pemilihan rute permintaan end-to-end
Log akses tidak diaktifkan secara default di Anthos Service Mesh dan hanya dapat diaktifkan secara global di seluruh mesh.
Anda dapat memecahkan masalah kegagalan koneksi/permintaan dengan membuat aktivitas di aplikasi Anda yang memicu permintaan HTTP, lalu memeriksa permintaan terkait di log sumber atau tujuan.
Jika Anda memicu permintaan muncul dan muncul di log proxy sumber, hal ini
menunjukkan bahwa pengalihan traffic iptables
berfungsi dengan benar dan proxy
Envoy menangani traffic. Jika Anda melihat error di log, buat dump konfigurasi Envoy
lalu periksa konfigurasi cluster envoy untuk memastikannya
sudah benar. Jika Anda melihat permintaan tetapi log tidak memiliki error, periksa log proxy tujuan.
Jika permintaan muncul di log proxy tujuan, ini menunjukkan bahwa mesh itu sendiri berfungsi dengan benar. Jika Anda melihat error, jalankan dump konfigurasi Envoy dan verifikasi nilai yang benar untuk port traffic yang ditetapkan dalam konfigurasi pemroses.
Jika masalah terus berlanjut setelah melakukan langkah-langkah sebelumnya, Envoy mungkin
tidak dapat menegosiasikan secara otomatis protokol antara file bantuan dan pod
aplikasinya. Pastikan nama port layanan Kubernetes, misalnya http-80
, cocok dengan protokol yang digunakan aplikasi.
Menggunakan Logs Explorer untuk membuat kueri log
Anda dapat menggunakan antarmuka Logs Explorer untuk mengkueri log akses tertentu. Misalnya, untuk mengkueri semua permintaan yang telah mengaktifkan MULTUAL_TLS
dan menggunakan protokol grpc
, tambahkan perintah berikut ke kueri log akses server:
labels.protocol="grpc" labels.service_authentication_policy="MULTUAL_TLS"
Menetapkan kebijakan log akses
Anda dapat menetapkan kebijakan logging proxy yang menentukan jenis informasi yang
dikumpulkan. Hal ini berguna untuk mengontrol cakupan log Anda guna memecahkan masalah. Misalnya, logging akan otomatis menangkap error, tetapi Anda dapat menetapkan logWindowDuration
untuk merekam peristiwa yang berhasil selama durasi waktu tertentu atau menyetel durasi periode ke nol untuk mencatat semua akses ke dalam log. Kebijakan ini
ditetapkan pada tingkat mesh atau cluster.
Untuk mengaktifkan kebijakan log akses, gunakan perintah berikut:
istioctl install --set profile=PROFILE_NAME \ --set values.telemetry.v2.stackdriver.enabled=true \ --set values.telemetry.v2.stackdriver.logging=true \ --set values.telemetry.accessLogPolicy.enabled=true
Untuk mengetahui informasi selengkapnya tentang opsi konfigurasi log akses, seperti
logWindowDuration
, lihat
Konfigurasi AccessLogPolicy.
Melihat informasi khusus layanan atau workload
Jika Anda memiliki masalah dengan layanan atau beban kerja tertentu, bukan masalah di seluruh mesh, periksa setiap proxy Envoy dan kumpulkan informasi yang relevan dari setiap proxy tersebut. Untuk mengumpulkan informasi tentang beban kerja tertentu dan proxy-nya,
Anda dapat menggunakan pilot-agent
:
kubectl exec POD_NAME -c istio-proxy -- pilot-agent request GET SCOPE
Dalam contoh, SCOPE adalah salah satu dari yang berikut:
certs
- Sertifikat dalam instance Envoyclusters
- Cluster dengan Envoy yang dikonfigurasiconfig_dump
- Membuang konfigurasi Envoylisteners
- Pemroses dengan Envoy yang dikonfigurasilogging
- Melihat dan mengubah setelan loggingstats
- Statistik Envoystats/prometheus
- Statistik Envoy sebagai catatan Prometheus
Melihat status soket proxy
Anda dapat langsung memeriksa status soket proxy Envoy dengan menggunakan proses berikut.
Tampilkan daftar soket yang ditetapkan, termasuk soket dalam status
TIME_WAIT
, yang dapat berdampak negatif pada skalabilitas jika jumlahnya tinggi:kubectl exec POD_NAME -c istio-proxy -- ss -anopim
Menampilkan ringkasan statistik soket:
kubectl exec POD_NAME -c istio-proxy -- ss -s
Untuk informasi selengkapnya, lihat Pengantar Perintah ss.
istio-proxy
dan istio-init
log
Selain itu, ambil log istio-proxy
dan tinjau kontennya untuk menemukan error yang mungkin menyarankan penyebab masalah:
kubectl logs POD_NAME -c istio-proxy
Anda dapat melakukan hal yang sama untuk penampung init
:
kubectl logs POD_NAME -c istio-init