Meminta log proxy
Halaman Cloud Service Mesh menyediakan link ke dua jenis log yang berbeda di Cloud Logging: Log akses (juga dikenal sebagai log Envoy) dan Log traffic (juga dikenal sebagai log akses Google Cloud Observability).
Log akses
Mengaktifkan log akses
Langkah-langkah yang diperlukan untuk mengaktifkan log akses bergantung pada jenis Cloud Service Mesh Anda, baik yang terkelola maupun dalam cluster:
Terkelola
Ikuti petunjuk untuk mengaktifkan log akses di Cloud Service Mesh terkelola.
Dalam cluster
Ikuti petunjuk untuk mengaktifkan log akses di Cloud Service Mesh dalam cluster.
Lihat log akses
Untuk melihat log akses di Logs Explorer:
Buka Logs Explorer:
Pilih project Google Cloud yang sesuai.
Jalankan kueri berikut:
resource.type="k8s_container" \ resource.labels.container_name="istio-proxy" resource.labels.cluster_name="CLUSTER_NAME" \ resource.labels.namespace_name="NAMESPACE_NAME" \ resource.labels.pod_name="POD_NAME"
Log lalu lintas
Mengaktifkan log traffic
Log traffic diaktifkan secara default, kecuali jika Cloud Service Mesh diinstal di Google Distributed Cloud Virtual with Istio CA (sebelumnya dikenal sebagai Citadel).
Untuk mengaktifkan log traffic di Google Distributed Cloud Virtual dengan Istio CA
saat menginstal Cloud Service Mesh dalam cluster,
gunakan tanda --option stackdriver
. Atau, Anda dapat mengaktifkan log
traffic di Google Distributed Cloud Virtual dengan Istio CA
setelah menginstal Cloud Service Mesh dalam cluster.
Lihat log traffic
Melihat log traffic di Logs Explorer
Untuk melihat log traffic di Logs Explorer:
Buka Logs Explorer:
Pilih project Google Cloud yang sesuai.
Jalankan kueri berikut, bergantung pada apakah Anda melihat log akses klien atau server:
Log server
resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/server-accesslog-stackdriver"
Log klien
resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/client-accesslog-stackdriver"
Melihat log traffic di halaman Anthos Service Mesh
Untuk melihat log traffic di halaman Cloud Service Mesh untuk Layanan selama rentang waktu yang ditentukan, ikuti langkah-langkah berikut:
Di Konsol Google Cloud, buka halaman Cloud Service Mesh.
Di bagian Layanan, pilih nama Layanan yang ingin Anda periksa.
Buka halaman Metrics.
Tentukan rentang waktu dari menu dropdown Time Span atau tetapkan rentang waktu kustom dengan linimasa.
Klik Lihat log traffic.
Log traffic diberi nama server-accesslog-stackdriver dan terpasang ke resource yang dimonitor (k8s_container atau gce_instance) yang digunakan layanan Anda. Log traffic 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.
Jika perekaman aktivitas diaktifkan, informasi rekaman aktivitas, seperti pengambilan sampel, ID rekaman aktivitas, dan ID span.
Contoh entri log terlihat seperti berikut:
{ insertId: "1awb4hug5pos2qi" httpRequest: { requestMethod: "GET" requestUrl: "YOUR-INGRESS/productpage" requestSize: "952" status: 200 responseSize: "5875" remoteIp: "10.8.0.44:0" serverIp: "10.56.4.25:9080" latency: "1.587232023s" protocol: "http" } resource: { type: "k8s_container" labels: { location: "us-central1-a" project_id: "YOUR-PROJECT" pod_name: "productpage-v1-76589d9fdc-ptnt9" cluster_name: "YOUR-CLUSTER-NAME" container_name: "productpage" namespace_name: "default" } } timestamp: "2020-04-28T19:55:21.056759Z" severity: "INFO" labels: { destination_principal: "spiffe://cluster.local/ns/default/sa/bookinfo-productpage" response_flag: "-" destination_service_host: "productpage.default.svc.cluster.local" source_app: "istio-ingressgateway" service_authentication_policy: "MUTUAL_TLS" source_name: "istio-ingressgateway-5ff85d8dd8-mwplb" mesh_uid: "YOUR-MESH-UID" request_id: "021ce752-9001-4ac6-b6d6-3b15f5d3632" destination_namespace: "default" source_principal: "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account" destination_workload: "productpage-v1" destination_version: "v1" source_namespace: "istio-system" source_workload: "istio-ingressgateway" destination_name: "productpage-v1-76589d9fdc-ptnt9" destination_app: "productpage" } trace: "projects/YOUR-PROJECT/traces/d4197f59b7a43e3aeff3571bac99d536" receiveTimestamp: "2020-04-29T03:07:14.362416217Z" spanId: "43226343ca2bb2b1" traceSampled: true logName: "projects/YOUR-PROJECT/logs/server-accesslog-stackdriver" receiveTimestamp: "2020-04-28T19:55:32.185229100Z" }
Menafsirkan telemetri Anthos Service Mesh
Bagian berikut menjelaskan cara memeriksa status mesh dan meninjau berbagai telemetri yang berisi detail berguna untuk membantu pemecahan masalah Anda.
Menafsirkan metrik bidang kontrol
Saat menginstal Cloud Service Mesh dengan bidang kontrol dalam cluster, istiod
akan mengekspor metrik ke Google Cloud Observability untuk pemantauan secara default.
istiod
memberi awalan metrik ini dengan istio.io/control
dan memberikan insight tentang
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/dashboards && git checkout servicemesh
Instal dasbor Cloud 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 yang diinstal.
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 dalam 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 Google Cloud Observability
Informasi berikut menjelaskan cara menggunakan log akses Google Cloud Observability untuk memecahkan masalah koneksi. Akses/log traffic/akses Observabilitas Google Cloud diaktifkan secara default.
Cloud Service Mesh mengekspor data ke log akses Kemampuan Observasi Google Cloud yang dapat membantu Anda men-debug jenis masalah berikut:
- Arus traffic dan kegagalan
- Perutean permintaan end-to-end
Log akses Google Cloud Observability diaktifkan secara default untuk penginstalan Cloud Service Mesh di Google Kubernetes Engine. Anda dapat mengaktifkan log akses Google Cloud Observability dengan menjalankan ulang asmcli install
. Gunakan opsi yang sama dengan yang Anda instal pertama kali, tetapi hilangkan overlay kustom yang menonaktifkan Stackdriver.
Ada dua jenis log akses:
Log akses server memberikan tampilan permintaan dari sisi server. Modul tersebut berada di
server-accesslog-stackdriver
, yang terpasang ke resource yang dipantauk8s_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 permintaan dari sisi klien. Modul tersebut berada di
client-accesslog-stackdriver
, dan terhubung 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
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 rekaman aktivitas, dan ID span.
Informasi yang ditampilkan dalam log akses Google Cloud Observability berasal dari log akses Envoy, saat Anda mengaktifkannya dalam konfigurasi Istio. Folder 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:
- Melakukan integrasi dengan Cloud Trace, yang merupakan fitur opsional di Cloud Service Mesh.
- Ekspor log traffic ke BigQuery. Di sana, Anda dapat menjalankan kueri seperti memilih semua permintaan memerlukan waktu lebih dari 5 detik.
- Buat 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" }
Buka label di entri log akses. Temukan kolom
response_flag
yang terlihat seperti berikut:response_flag: "NR"
Nilai
NR
adalah akronim dariNoRoute
, yang berarti tidak ada rute yang ditemukan untuk tujuan atau tidak ada rantai filter yang cocok untuk koneksi downstream. Demikian pula, Anda dapat menggunakan labelresponse_flag
untuk memecahkan masalah error503
juga.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 layanan tersebut. Misalnya, jika klien biner golang terhubung ke server golang menggunakan HTTP, tetapi port-nya bernamahttp2
, protokol tidak akan melakukan negosiasi otomatis dengan benar.
Untuk mengetahui informasi selengkapnya, lihat tanda respons.
Menafsirkan log akses
Langkah-langkah berikut menjelaskan cara menggunakan log akses (juga dikenal sebagai log proxy Envoy) untuk menampilkan traffic di antara kedua ujung koneksi untuk tujuan pemecahan masalah.
Log akses berguna untuk mendiagnosis masalah seperti:
- Arus traffic dan kegagalan
- Perutean permintaan end-to-end
Log akses tidak diaktifkan secara default di Cloud Service Mesh dan hanya dapat diaktifkan secara global di seluruh mesh.
Anda dapat memecahkan masalah kegagalan koneksi/permintaan dengan menghasilkan aktivitas di aplikasi yang memicu permintaan HTTP, lalu memeriksa permintaan terkait dalam 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 dan 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, hal 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 terjadi setelah melakukan langkah sebelumnya, Envoy mungkin
tidak dapat menegosiasikan protokol secara otomatis antara file bantuan dan pod
aplikasinya. Pastikan nama port layanan Kubernetes, misalnya http-80
,
cocok dengan protokol yang digunakan aplikasi.
Menggunakan Logs Explorer untuk mengkueri log
Anda dapat menggunakan antarmuka Logs Explorer untuk membuat kueri log akses tertentu. Misalnya, untuk membuat kueri semua permintaan dengan
MULTUAL_TLS
mengaktifkan dan menggunakan protokol grpc
, tambahkan kode berikut ke kueri
log akses server:
labels.protocol="grpc" labels.service_authentication_policy="MULTUAL_TLS"
Menetapkan kebijakan log akses
Guna mengonfigurasi logging proxy untuk Cloud Service Mesh terkelola, lihat Log akses Envoy.
Guna menetapkan kebijakan log akses untuk Cloud Service Mesh dengan bidang kontrol dalam cluster:
Buat file overlay kustom
IstioOperator
yang menyertakan nilaiAccessLogPolicyConfig
yang sesuai untuk skenario Anda.Teruskan file ini ke
asmcli
menggunakan opsi--custom_overlay
untuk mengupdate konfigurasi bidang kontrol dalam cluster. Untuk mengetahui informasi tentang cara menjalankanasmcli install
dengan file overlay kustom, lihat Menginstal dengan fitur opsional.
Melihat informasi khusus layanan atau workload
Jika Anda mengalami masalah dengan layanan atau workload tertentu, bukan masalah seluruh mesh, periksa setiap proxy Envoy dan kumpulkan informasi yang relevan dari proxy tersebut. Untuk mengumpulkan informasi tentang workload tertentu dan proxy-nya, Anda dapat menggunakan pilot-agent
:
kubectl exec POD_NAME -n NAMESPACE_NAME -c istio-proxy -- pilot-agent request GET SCOPE
Dalam contoh, SCOPE adalah salah satu dari berikut ini:
certs
- Sertifikat dalam instance Envoyclusters
- Cluster dengan Envoy yang dikonfigurasiconfig_dump
- Membuang konfigurasi Envoylisteners
- Pemroses dengan Envoy 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 menggunakan proses berikut.
Tampilkan daftar soket yang sudah ada, termasuk soket di status
TIME_WAIT
, yang dapat berdampak negatif terhadap skalabilitas jika jumlahnya tinggi:kubectl exec POD_NAME -n NAMESPACE_NAME -c istio-proxy -- ss -anopim
Menampilkan ringkasan statistik soket:
kubectl exec POD_NAME -n NAMESPACE_NAME -c istio-proxy -- ss -s
Untuk informasi selengkapnya, lihat Pengantar Perintah ss.
Log istio-proxy
dan istio-init
Selain itu, ambil log istio-proxy
dan tinjau kontennya untuk menemukan
error yang mungkin menunjukkan penyebab masalah:
kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy
Anda dapat melakukan hal yang sama untuk penampung init
:
kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-init
Langkah selanjutnya
Berintegrasi dengan Cloud Trace. Cloud Trace adalah fitur opsional di Cloud Service Mesh.