Anthos Service Mesh dan Traffic Director kini bergabung menjadi Cloud Service Mesh. Untuk mengetahui informasi selengkapnya, lihat ringkasan Cloud Service Mesh.

Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Log proxy permintaan

Cloud Service Mesh mendukung dua jenis log akses yang berbeda di Cloud Logging: Log traffic (juga dikenal sebagai log akses Google Cloud Observability) dan log akses Envoy. Halaman ini menunjukkan cara mengaktifkan, menonaktifkan, melihat, dan menafsirkan log ini. Perhatikan bahwa log traffic diaktifkan secara default.

Mengaktifkan dan menonaktifkan log akses

Managed Traffic Director

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

Log akses Envoy

Jalankan perintah berikut untuk mengaktifkan log akses Envoy dan menonaktifkan log traffic:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: enable-envoy-disable-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
  - providers:
      - name: stackdriver
    disabled: true
EOF

Perhatikan bahwa nama penyedia untuk log traffic adalah stackdriver.

Log traffic

Secara default, log traffic diaktifkan dan log akses Envoy dinonaktifkan. Jika sebelumnya Anda mengaktifkan log akses Envoy dan ingin mengaktifkan log traffic serta menonaktifkan log akses Envoy, jalankan perintah berikut:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: disable-envoy-enable-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
    disabled: true
  - providers:
      - name: stackdriver
EOF

Keduanya

Untuk mengaktifkan log akses Envoy dan log traffic, jalankan perintah berikut:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: enable-envoy-and-sd-access-log
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
      - name: stackdriver
EOF

Untuk menonaktifkan log akses Envoy dan log traffic, jalankan perintah berikut:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: disable-envoy-and-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
    disabled: true
  - providers:
      - name: stackdriver
    disabled: true
EOF

Log akses khusus selektor

Di saluran cepat, untuk mengaktifkan pencatatan akses hanya untuk workload tertentu, Anda harus menonaktifkannya terlebih dahulu di tingkat seluruh mesh dengan menerapkan Konfigurasi Telemetri di namespace root (karena pencatatan traffic diaktifkan secara default). Kemudian, Anda menerapkan konfigurasi terpisah dengan pemilih untuk mengaktifkannya hanya untuk workload tersebut.

# 1. Disable mesh-wide access logging
cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: disable-mesh-wide-telemetry
  namespace: istio-system
spec:
  accessLogging:
  - providers:
    - name: stackdriver
    disabled: true
EOF

# 2. Enable access logging for a specific workload
cat <<EOF | kubectl apply -n NAMESPACE -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: workload-specific-telemetry
  namespace: NAMESPACE
spec:
  selector:
    matchLabels:
      app: YOUR_APP_LABEL
  accessLogging:
  - providers:
    - name: stackdriver
EOF

Dikelola `istiod`

Log akses Envoy

Jalankan perintah berikut untuk mengaktifkan logging akses Envoy:

Jalankan perintah berikut untuk menambahkan accessLogFile: /dev/stdout:

cat <<EOF | kubectl apply -f -
apiVersion: v1
data:
  mesh: |-
    accessLogFile: /dev/stdout
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
EOF

dengan release-channel adalah saluran rilis Anda (asm-managed, asm-managed-stable, atau asm-managed-rapid).

Jalankan perintah berikut untuk melihat configmap:

 kubectl get configmap istio-release-channel -n istio-system -o yaml

Untuk memverifikasi bahwa logging akses diaktifkan, pastikan baris accessLogFile: /dev/stdout muncul di bagian mesh:.
```
...
apiVersion: v1
data:
  mesh: |
    ....
    accessLogFile: /dev/stdout
...
```

Log traffic

Log traffic diaktifkan secara default.

Dalam cluster

Log akses Envoy

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: "/dev/stdout"

Untuk mengetahui informasi selengkapnya, lihat Mengaktifkan logging akses Envoy.

Log traffic

Log traffic diaktifkan secara default, kecuali jika Cloud Service Mesh diinstal di Google Distributed Cloud dengan Istio CA (sebelumnya dikenal sebagai Citadel).

Untuk mengaktifkan log traffic di Google Distributed Cloud dengan CA Istio saat menginstal Cloud Service Mesh dalam cluster, gunakan flag --option stackdriver. Atau, Anda dapat mengaktifkan log traffic di Google Distributed Cloud dengan Istio CA setelah menginstal Cloud Service Mesh dalam cluster.

Menyesuaikan format dan encoding log akses Envoy

Anda dapat menyesuaikan konten dan struktur log akses Envoy yang dikeluarkan ke output standar (/dev/stdout). Dengan begitu, Anda dapat menyertakan kolom tertentu untuk audit atau kepatuhan (seperti cipher suite TLS) untuk memilih antara output teks biasa atau JSON terstruktur.

Batasan

Konfigurasi format logging akses hanya tersedia di saluran rilis Rapid.

Kolom konfigurasi

Konfigurasi kolom berikut di MeshConfig:

accessLogEncoding: Menentukan struktur log, baik TEXT atau JSON. Nilai defaultnya adalah TEXT.
accessLogFormat: String format log akses Envoy atau definisi JSON (opsional jika TEXT dipilih).

Terapkan konfigurasi:

Cara Anda menerapkan setelan ini bergantung pada bidang kontrol Anda:

Managed Traffic Director

Perbarui ConfigMap istio-asm-managed-rapid di namespace istio-system (meskipun Anda menggunakan saluran selain cepat). Tambahkan accessLogEncoding dan accessLogFormat di bagian kolom mesh.

cat <<EOF | kubectl apply -f -
apiVersion: v1
data:
  mesh: |-
    accessLogFile: /dev/stdout
    accessLogEncoding: JSON
    accessLogFormat: '{"time": "%START_TIME%","code": "%RESPONSE_CODE%","upstream_cluster": "%UPSTREAM_CLUSTER%"}'
kind: ConfigMap
metadata:
  name: istio-asm-managed-rapid
  namespace: istio-system
EOF

Melihat log akses

Log akses Envoy

Command line

Untuk melihat log akses Envoy di log istio-proxy, jalankan perintah berikut:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

Logs Explorer

Untuk melihat log akses Envoy di Logs Explorer:

Buka 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 traffic

Untuk melihat log traffic di Logs Explorer:

Buka 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"

Untuk melihat log traffic di halaman Cloud Service Mesh untuk Layanan selama rentang waktu tertentu, ikuti langkah-langkah berikut:

Di konsol Google Cloud , buka halaman Cloud Service Mesh.

Buka halaman Cloud Service Mesh
Di bagian Layanan, pilih nama Layanan yang ingin Anda periksa.
Buka halaman Metrik.
Tentukan rentang waktu dari menu drop-down Rentang Waktu atau tetapkan rentang kustom dengan linimasa.
Di bagian Pilih opsi filter, klik Lihat log traffic.

Log traffic diberi nama server-accesslog-stackdriver dan dilampirkan ke resource yang dimonitor yang sesuai (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 pelacakan diaktifkan, informasi rekaman aktivitas, seperti pengambilan sampel, ID rekaman aktivitas, dan ID rentang.

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 Cloud Service Mesh

Bagian berikut menjelaskan cara memeriksa status mesh dan meninjau berbagai telemetri yang berisi detail bermanfaat untuk membantu pemecahan masalah Anda.

Menafsirkan metrik bidang kontrol

Managed Traffic Director

Cloud Service Mesh dengan bidang kontrol Traffic Director terkelola tidak mendukung metrik bidang kontrol.

Dikelola `istiod`

Cloud Service Mesh dengan bidang kontrol istiod terkelola tidak mendukung pemeriksaan metrik bidang kontrol di bagian ini.

Dalam cluster

Saat menginstal Cloud Service Mesh dengan bidang kontrol dalam cluster, istiod mengekspor metrik ke Google Cloud Observability untuk pemantauan, secara default. istiod memberi awalan istio.io/control pada metrik ini 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.

Memuat 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 mengetahui informasi selengkapnya, lihat Melihat dasbor yang terinstal.

Untuk mengetahui daftar lengkap metrik yang tersedia, lihat Metrik yang diekspor.

Mendiagnosis penundaan konfigurasi

Managed Traffic Director

Cloud Service Mesh dengan bidang kontrol Traffic Director terkelola tidak mendukung diagnosis penundaan konfigurasi.

Dikelola `istiod`

Cloud Service Mesh dengan bidang kontrol istiod terkelola tidak mendukung diagnosis penundaan konfigurasi.

Dalam cluster

Langkah-langkah berikut menjelaskan cara menggunakan metrik pilot_proxy_convergence_time untuk mendiagnosis penundaan antara perubahan konfigurasi dan semua proxy yang menyatu.

Menjalankan perintah shell di pod:

kubectl debug --image istio/base --target istio-proxy -it $(kubectl get pod -l app=pilot -o jsonpath='{.items[0].metadata.name}' -n istio-system) -n istio-system -- curl -s

Akses localhost:15014 dan grep untuk convergence dalam metrik:
```
curl http://localhost:15014/metrics | grep convergence
```

Menafsirkan log traffic

Informasi berikut menjelaskan cara menggunakan log traffic untuk memecahkan masalah koneksi. Log traffic diaktifkan secara default.

Cloud Service Mesh mengekspor data ke dalam log traffic yang dapat membantu Anda men-debug jenis masalah berikut:

Alur dan kegagalan traffic
Perutean permintaan end-to-end

Log traffic diaktifkan secara default untuk penginstalan Cloud Service Mesh di Google Kubernetes Engine. Anda dapat mengaktifkan log traffic dengan menjalankan kembali asmcli install. Gunakan opsi yang sama dengan yang Anda instal sebelumnya, tetapi hilangkan overlay kustom yang menonaktifkan Stackdriver.

Ada dua jenis log traffic:

Log akses server memberikan tampilan permintaan sisi server. Log ini berada di bawah server-accesslog-stackdriver, yang dilampirkan ke resource yang dipantau k8s_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 sisi klien. Metrik ini berada di bagian client-accesslog-stackdriver, yang dilampirkan ke resource yang dimonitor k8s_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 pelacakan diaktifkan, log akan berisi informasi pelacakan, seperti pengambilan sampel, ID pelacakan, dan ID rentang.

Log traffic dapat berisi label berikut:

route_name
upstream_cluster
X-Envoy-Original-Path

Berikut 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:

Berintegrasi dengan Cloud Trace, yang merupakan fitur opsional di Cloud Service Mesh.
Mengekspor log traffic ke BigQuery, tempat Anda dapat menjalankan kueri seperti memilih semua permintaan yang memerlukan waktu lebih dari 5 detik.
Buat metrik berbasis log.
Memecahkan masalah error 404 dan 503

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, cari 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 untuk NoRoute, yang berarti tidak ada rute yang ditemukan untuk tujuan atau tidak ada rangkaian filter yang cocok untuk koneksi downstream. Demikian pula, Anda dapat menggunakan label response_flag untuk memecahkan masalah error 503 juga.
Jika Anda melihat error 503 di log akses klien dan server, periksa apakah 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 portnya diberi nama http2, protokol tidak akan bernegosiasi otomatis dengan benar.

Untuk mengetahui informasi selengkapnya, lihat tanda respons.

Menafsirkan log akses Envoy

Langkah-langkah berikut menjelaskan cara menggunakan log akses Envoy untuk menampilkan traffic di antara kedua ujung koneksi untuk tujuan pemecahan masalah.

Log akses Envoy berguna untuk mendiagnosis masalah seperti:

Alur dan kegagalan traffic
Perutean permintaan end-to-end

Log akses Envoy tidak diaktifkan secara default di Cloud Service Mesh dan dapat diaktifkan untuk cluster dalam mesh.

Anda dapat memecahkan masalah kegagalan koneksi atau permintaan dengan membuat aktivitas di aplikasi yang memicu permintaan HTTP, lalu memeriksa permintaan terkait di log sumber atau tujuan.

Jika permintaan dipicu 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 memastikan 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 setelan port traffic dalam konfigurasi listener.

Jika masalah berlanjut setelah melakukan langkah-langkah sebelumnya, Envoy mungkin tidak dapat melakukan negosiasi otomatis protokol antara sidecar dan pod aplikasi. 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 Envoy tertentu. Misalnya, untuk membuat kueri semua permintaan yang mengaktifkan MULTUAL_TLS dan menggunakan protokol grpc, tambahkan berikut ke kueri log akses server:

labels.protocol="grpc" labels.service_authentication_policy="MULTUAL_TLS"

Menetapkan kebijakan log akses

Managed Traffic Director

Untuk mengonfigurasi log akses untuk Cloud Service Mesh dengan bidang kontrol Traffic Director terkelola, lihat Mengaktifkan log akses.

Dikelola `istiod`

Untuk mengonfigurasi log akses untuk Cloud Service Mesh dengan bidang kontrol istiod terkelola, lihat Mengaktifkan log akses.

Dalam cluster

Untuk menetapkan kebijakan log akses untuk Cloud Service Mesh dengan bidang kontrol dalam cluster:

Buat file overlay kustom IstioOperator yang menyertakan nilai AccessLogPolicyConfig yang berlaku untuk skenario Anda.
Teruskan file ini ke asmcli menggunakan opsi --custom_overlay untuk memperbarui konfigurasi bidang kontrol dalam cluster. Untuk mengetahui informasi tentang cara menjalankan asmcli install dengan file overlay kustom, lihat Menginstal dengan fitur opsional.

Perhatian: Jika Anda menyesuaikan penginstalan sebelumnya, Anda memerlukan penyesuaian yang sama saat menginstal ulang bidang kontrol untuk menyertakan file dengan setelan AccessLogPolicyConfig. Menghilangkan file overlay akan menghasilkan penginstalan yang berhasil; namun, mesh layanan Anda memiliki konfigurasi yang berbeda dari yang Anda inginkan karena nilai yang dihilangkan direset kembali ke default saat bidang kontrol di-deploy ulang.

Melihat informasi khusus layanan atau beban kerja

Jika Anda mengalami masalah dengan layanan atau beban kerja tertentu, bukan masalah di seluruh mesh, periksa setiap proxy Envoy dan kumpulkan informasi yang relevan dari proxy tersebut. Untuk mengumpulkan informasi tentang workload tertentu dan proksinya, 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 Envoy
clusters - Cluster dengan Envoy yang dikonfigurasi
config_dump - Mencetak konfigurasi Envoy
listeners - Pemroses dengan Envoy yang dikonfigurasi
logging - Melihat dan mengubah setelan logging
stats - Statistik Envoy
stats/prometheus - Statistik Envoy sebagai rekaman Prometheus

Melihat status soket proxy

Anda dapat memeriksa status soket proxy Envoy secara langsung menggunakan proses berikut.

Menampilkan daftar soket yang sudah dibuat, termasuk soket dalam status TIME_WAIT yang dapat memengaruhi skalabilitas secara negatif jika jumlahnya tinggi:
```
kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -anopim
```

Menampilkan ringkasan statistik soket:

kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -s

Untuk mengetahui informasi selengkapnya, lihat Pengantar Perintah ss.

Log `istio-proxy` dan `istio-init`

Selain itu, ambil log istio-proxy dan tinjau isinya 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 berikutnya

Integrasikan dengan Cloud Trace. Cloud Trace adalah fitur opsional di Cloud Service Mesh.
Mengekspor log traffic ke BigQuery.
Membuat metrik berbasis log.

Log proxy permintaan

Mengaktifkan dan menonaktifkan log akses

Managed Traffic Director

Log akses Envoy

Log traffic

Keduanya

Log akses khusus selektor

Dikelola istiod

Log akses Envoy

Log traffic

Dalam cluster

Log akses Envoy

Log traffic

Menyesuaikan format dan encoding log akses Envoy

Batasan

Kolom konfigurasi

Terapkan konfigurasi:

Managed Traffic Director

Melihat log akses

Log akses Envoy

Command line

Logs Explorer

Log traffic

Log server

Log klien

Menafsirkan telemetri Cloud Service Mesh

Menafsirkan metrik bidang kontrol

Managed Traffic Director

Dikelola istiod

Dalam cluster

Mendiagnosis penundaan konfigurasi

Managed Traffic Director

Dikelola istiod

Dalam cluster

Menafsirkan log traffic

Memecahkan masalah error 404 dan 503

Menafsirkan log akses Envoy

Menggunakan Logs Explorer untuk mengkueri log

Menetapkan kebijakan log akses

Managed Traffic Director

Dikelola istiod

Dalam cluster

Melihat informasi khusus layanan atau beban kerja

Melihat status soket proxy

Log istio-proxy dan istio-init

Langkah berikutnya

Dikelola `istiod`

Dikelola `istiod`

Dikelola `istiod`

Memecahkan masalah error `404` dan `503`

Dikelola `istiod`

Log `istio-proxy` dan `istio-init`