Mengakses log di Cloud Logging

Halaman Cloud Service Mesh menyediakan link ke tiga jenis log yang berbeda di Cloud Logging: log aplikasi, log error, dan log traffic.

Mengakses log aplikasi

Untuk melihat log aplikasi untuk Layanan selama jangka waktu tertentu, ikuti langkah-langkah berikut:

  1. Buka halaman Cloud Service Mesh di konsol Google Cloud.

    Buka halaman Cloud Service Mesh

  2. Di bagian Layanan, pilih nama Layanan yang ingin Anda periksa.

  3. Buka halaman Metrics.

  4. Tentukan rentang waktu dari menu dropdown Rentang Waktu atau tetapkan rentang kustom dengan linimasa.

  5. Klik Lihat log aplikasi.

Log aplikasi adalah log yang dihasilkan oleh kode aplikasi Anda sendiri dan disertakan ke resource yang dipantau terkait (k8s_container atau gce_instance) yang digunakan aplikasi Anda.

Mengakses log error

Untuk melihat log error untuk Layanan selama rentang waktu yang ditentukan, ikuti langkah-langkah berikut:

  1. Di konsol Google Cloud, buka halaman Cloud Service Mesh.

    Buka halaman Cloud Service Mesh

  2. Di bagian Layanan, pilih nama Layanan yang ingin Anda periksa.

  3. Buka halaman Diagnostik.

  4. Tentukan rentang waktu dari menu dropdown Rentang Waktu atau tetapkan rentang kustom dengan linimasa.

  5. Di sudut kanan atas jendela, klik Buka di logging.

Mengakses log traffic

Untuk melihat log traffic, atau log akses di Istio, untuk Layanan selama jangka waktu tertentu, ikuti langkah-langkah berikut:

  1. Di konsol Google Cloud, buka halaman Cloud Service Mesh.

    Buka halaman Cloud Service Mesh

  2. Di bagian Layanan, pilih nama Layanan yang ingin Anda periksa.

  3. Buka halaman Metrics.

  4. Tentukan rentang waktu dari menu dropdown Rentang Waktu atau tetapkan rentang kustom dengan linimasa.

  5. 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 pelacakan, seperti sampling, 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 bermanfaat untuk membantu pemecahan masalah Anda.

Menafsirkan metrik bidang kontrol

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

  1. Muat dasbor contoh:

    git clone https://github.com/GoogleCloudPlatform/monitoring-dashboard-samples && cd monitoring-dashboard-samples/dashboards && git checkout servicemesh

  2. Instal dasbor Cloud Service Mesh:

    gcloud monitoring dashboards create --config-from-file=dashboards/servicemesh/anthos-service-mesh-control-plane-monitoring.json

  3. 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

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

  1. 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

  2. Mengakses localhost:15014 dan grep untuk convergence 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. Log akses/traffic Google Cloud Observability diaktifkan secara default.

Cloud Service Mesh mengekspor data ke log akses Google Cloud Observability yang dapat membantu Anda men-debug jenis masalah berikut:

  • Arus dan kegagalan traffic
  • Pemilihan rute permintaan menyeluruh

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 kembali asmcli install. Gunakan opsi yang sama dengan yang awalnya Anda instal, tetapi hapus overlay kustom yang menonaktifkan Stackdriver.

Ada dua jenis log akses:

  • Log akses server memberikan tampilan permintaan sisi server. Atribut ini terletak di bagian server-accesslog-stackdriver, yang dilampirkan ke resource yang dimonitor 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 tersebut berada di bagian client-accesslog-stackdriver, yang dilampirkan ke resource yang dipantau 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 rekaman aktivitas, seperti sampling, ID rekaman aktivitas, dan ID span.

Informasi yang ditampilkan di log akses Google Cloud Observability berasal dari log akses Envoy, saat Anda mengaktifkannya dalam konfigurasi Istio. File tersebut berisi header berikut:

  • route_name
  • upstream_cluster
  • X-Envoy-Original-Path
  • X-Envoy-Original-Host

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.
  • Membuat 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.

  1. 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"
}

  2. 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 rantai filter yang cocok untuk koneksi downstream. Demikian pula, Anda juga dapat menggunakan label response_flag untuk memecahkan masalah error 503.

  3. 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 diberi nama http2, protokol tidak akan menegosiasikan secara otomatis dengan benar.

Untuk mengetahui informasi selengkapnya, lihat flag 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:

  • Arus dan kegagalan traffic
  • Pemilihan rute permintaan menyeluruh

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 membuat aktivitas di aplikasi yang memicu permintaan HTTP, lalu memeriksa permintaan terkait dalam log sumber atau tujuan.

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

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

Menetapkan kebijakan log akses

Untuk mengonfigurasi logging proxy untuk Cloud Service Mesh terkelola, lihat Log akses Envoy.

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

  1. Buat file overlay kustom IstioOperator yang menyertakan nilai AccessLogPolicyConfig yang berlaku untuk skenario Anda.

  2. Teruskan file ini ke asmcli menggunakan opsi --custom_overlay untuk memperbarui konfigurasi bidang kontrol dalam cluster. Untuk informasi tentang cara menjalankan asmcli install dengan file overlay kustom, lihat Menginstal dengan fitur opsional.

Melihat informasi khusus layanan atau beban kerja

Jika Anda mengalami masalah dengan layanan atau beban kerja tertentu, bukan masalah secara menyeluruh, periksa setiap proxy Envoy dan kumpulkan informasi yang relevan darinya. Untuk mengumpulkan informasi tentang workload 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 berikut ini:

  • certs - Sertifikat dalam instance Envoy
  • clusters - Cluster dengan Envoy yang dikonfigurasi
  • config_dump - Menghapus konfigurasi Envoy
  • listeners - Pemroses dengan Envoy yang dikonfigurasi
  • logging - Melihat dan mengubah setelan logging
  • stats - Statistik Envoy
  • stats/prometheus - Statistik Envoy sebagai data Prometheus

Melihat status soket proxy

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

  1. Menampilkan daftar soket yang dibuat, termasuk soket dalam status TIME_WAIT, yang dapat memengaruhi skalabilitas secara negatif jika jumlahnya tinggi:

    kubectl exec POD_NAME -c istio-proxy -- ss -anopim

  2. Menampilkan ringkasan statistik soket:

    kubectl exec POD_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 -c istio-proxy

Anda dapat melakukan hal yang sama untuk penampung init:

kubectl logs POD_NAME -c istio-init

Langkah selanjutnya