Anthos Service Mesh와 Traffic Director가 이제 Cloud Service Mesh로 통합되었습니다. 자세한 내용은 Cloud Service Mesh 개요를 참조하세요.

이 페이지는 Cloud Translation API를 통해 번역되었습니다.

프록시 로그 요청

Cloud Service Mesh는 Cloud Logging에서 트래픽 로그(Google Cloud Observability 액세스 로그라고도 함) 및 Envoy 액세스 로그 등 두 가지 유형의 액세스 로그를 지원합니다. 이 페이지에서는 이러한 로그를 사용 설정, 중지, 보기, 해석하는 방법을 보여줍니다. 트래픽 로그는 기본적으로 사용 설정되어 있습니다.

액세스 로그 사용 설정 및 중지

관리형 Cloud Service Mesh

Envoy 액세스 로그

다음 명령어를 실행하여 Envoy 액세스 로그를 사용 설정하고 트래픽 로그를 중지합니다.

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

트래픽 로그 제공자 이름은 stackdriver입니다.

트래픽 로그

기본적으로 트래픽 로그는 사용 설정되고 Envoy 액세스 로그는 중지되어 있습니다. 이전에 Envoy 액세스 로그를 사용 설정했고 트래픽 로그를 사용 설정하고 Envoy 액세스 로그를 중지하려면 다음 명령어를 실행합니다.

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

둘 다

Envoy 액세스 로그와 트래픽 로그 모두 사용 설정하려면 다음 명령어를 실행합니다.

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

Envoy 액세스 로그와 트래픽 로그 모두 중지하려면 다음 명령어를 실행합니다.

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

관리형 `istiod`

Envoy 액세스 로그

다음 명령어를 실행하여 Envoy 액세스 로깅을 사용 설정합니다.

다음 명령어를 실행하여 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

여기서 release-channel은 출시 채널입니다(asm-managed, asm-managed-stable, asm-managed-rapid).

다음 명령어를 실행하여 구성 맵을 확인합니다.

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

액세스 로깅이 사용 설정되었는지 확인하려면 accessLogFile: /dev/stdout 줄이 mesh: 섹션에 표시되는지 확인합니다.
```
...
apiVersion: v1
data:
  mesh: |
    ....
    accessLogFile: /dev/stdout
...
```

트래픽 로그

트래픽 로그는 기본적으로 사용 설정되어 있습니다.

클러스터 내

Envoy 액세스 로그

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

자세한 내용은 Envoy의 액세스 로깅 사용 설정을 참조하세요.

트래픽 로그

Cloud Service Mesh가 Istio CA가 포함된 Google Distributed Cloud(이전의 Citadel)에 설치된 경우가 아니면 트래픽 로그는 기본적으로 사용 설정되어 있습니다.

클러스터 내 Cloud Service Mesh를 설치할 때 Istio CA가 포함된 Google Distributed Cloud에서 트래픽 로그를 사용 설정하려면 --option stackdriver 플래그를 사용합니다. 또는 클러스터 내 Cloud Service Mesh를 설치한 후 Istio CA가 포함된 Google Distributed Cloud에서 트래픽 로그를 사용 설정할 수 있습니다.

액세스 로그 보기

Envoy 액세스 로그

명령줄

istio-proxy 로그에서 Envoy 액세스 로그를 보려면 다음 명령어를 실행합니다.

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

로그 탐색기

로그 탐색기에서 Envoy 액세스 로그를 보려면 다음 안내를 따르세요.

로그 탐색기로 이동합니다.

로그 탐색기로 이동
적합한 Google Cloud 프로젝트를 선택합니다.
다음 쿼리를 실행합니다.

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"

트래픽 로그

로그 탐색기에서 트래픽 로그를 보려면 다음 안내를 따르세요.

로그 탐색기로 이동합니다.

로그 탐색기로 이동
적합한 Google Cloud 프로젝트를 선택합니다.

보고 있는 로그가 클라이언트 또는 서버 액세스 로그인지에 따라 다음 쿼리를 실행합니다.

서버 로그

resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/server-accesslog-stackdriver"

클라이언트 로그

resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/client-accesslog-stackdriver"

지정된 기간 동안 서비스의 Cloud Service Mesh 페이지에서 트래픽 로그를 보려면 다음 단계를 수행합니다.

Google Cloud 콘솔에서 Cloud Service Mesh 페이지로 이동합니다.

Cloud Service Mesh 페이지로 이동
서비스에서 검사하려는 서비스의 이름을 선택합니다.
측정항목 페이지로 이동합니다.
시간 범위 드롭다운 메뉴에서 기간을 지정하거나 타임라인으로 커스텀 스팬을 설정합니다.
필터 옵션 선택에서 트래픽 로그 보기를 클릭합니다.

트래픽 로그 이름은 server-accesslog-stackdriver이고 트래픽 로그는 서비스에서 사용하는 해당 모니터링 리소스(k8s_container 또는 gce_instance)에 연결됩니다. 트래픽 로그에는 다음 정보가 포함됩니다.

ID, URL, 크기, 지연 시간, 공통 헤더와 같은 HTTP 요청 속성
이름, 네임스페이스, ID, 일반 라벨과 같은 소스 및 대상 워크로드 정보
추적이 사용 설정된 경우 샘플링, 추적 ID, 스팬 ID와 같은 추적 정보

로그 항목의 예시는 다음과 같습니다.

{
  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"
}

Cloud Service Mesh 원격 분석 해석

다음 섹션에서는 메시 상태를 확인하고 문제 해결에 도움이 되는 유용한 세부정보가 포함된 다양한 원격 분석을 검토하는 방법을 설명합니다.

제어 영역 측정항목 해석

관리형 Cloud Service Mesh

관리형 Cloud Service Mesh 컨트롤 플레인을 사용하는 Cloud Service Mesh에서는 컨트롤 플레인 측정항목을 지원하지 않습니다.

관리형 `istiod`

관리형 istiod 컨트롤 플레인을 사용하는 Cloud Service Mesh에서는 이 섹션의 컨트롤 플레인 측정항목을 검사할 수 없습니다.

클러스터 내

클러스터 내 컨트롤 플레인으로 Cloud Service Mesh를 설치할 때 istiod는 기본적으로 모니터링할 수 있도록 측정항목을 Google Cloud Observability로 내보냅니다. istiod는 이러한 측정항목에 istio.io/control로 프리픽스를 지정하고 각 컨트롤 플레인 인스턴스에 연결된 프록시 수, 구성 이벤트, 푸시, 검사와 같은 컨트롤 플레인 상태에 대한 유용한 정보를 제공합니다.

다음 단계에 따라 컨트롤 플레인을 관찰하거나 문제 해결합니다.

샘플 대시보드 로드:

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

Cloud Service Mesh 대시보드를 설치합니다.

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

목록에서 Istio Control Plane Dashboard라는 대시보드를 찾습니다. 자세한 내용은 설치된 대시보드 보기를 참조하세요.

사용 가능한 전체 측정항목 목록은 내보낸 측정항목을 참조하세요.

구성 지연 진단

관리형 Cloud Service Mesh

관리형 Cloud Service Mesh 컨트롤 플레인을 사용하는 Cloud Service Mesh에서는 구성 지연을 진단할 수 없습니다.

관리형 `istiod`

관리형 istiod 컨트롤 플레인을 사용하는 Cloud Service Mesh에서는 구성 지연을 진단할 수 없습니다.

클러스터 내

다음 단계에서는 pilot_proxy_convergence_time 측정 항목을 사용하여 구성 변경과 모든 프록시 수렴 사이의 지연을 진단하는 방법을 설명합니다.

포드에서 셸 명령어를 실행합니다.

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

측정항목에서 convergence의 localhost:15014 및 grep에 액세스합니다.
```
curl http://localhost:15014/metrics | grep convergence
```

트래픽 로그 해석

다음 정보에서는 트래픽 로그를 사용하여 연결 문제를 해결하는 방법을 설명합니다. 트래픽 로그는 기본적으로 사용 설정되어 있습니다.

Cloud Service Mesh는 다음 유형의 문제를 디버깅하는 데 도움이 되는 데이터를 트래픽 로그로 내보냅니다.

트래픽 흐름 및 장애
엔드 투 엔드 요청 라우팅

트래픽 로그는 기본적으로 Google Kubernetes Engine의 Cloud Service Mesh 설치에 사용 설정되어 있습니다. asmcli install을 다시 실행하여 트래픽 로그를 사용 설정할 수 있습니다. 원래 설치한 옵션과 동일한 옵션을 사용하되 Stackdriver를 중지한 커스텀 오버레이를 생략합니다.

트래픽 로그에는 두 가지 유형이 있습니다.

서버 액세스 로그는 서버 측 요청 보기를 제공합니다. 로그는 k8s_container 모니터링 리소스에 연결되어 server-accesslog-stackdriver 아래에 있습니다. 다음 URL 문법을 사용하여 서버 측 액세스 로그를 표시합니다.
```
https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"&project=PROJECT_ID
```
클라이언트 액세스 로그는 클라이언트 측 요청 보기를 제공합니다. 로그는 k8s_pod 모니터링 리소스에 연결되어 client-accesslog-stackdriver 아래에 있습니다. 다음 URL 문법을 사용하여 클라이언트 측 액세스 로그를 표시합니다.
```
https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/client-accesslog-stackdriver"&project=PROJECT_ID
```

액세스 로그에는 다음 정보가 포함됩니다.

ID, URL, 크기, 지연 시간, 공통 헤더 등 HTTP 요청 속성
이름, 네임스페이스, ID, 일반 라벨과 같은 소스 및 대상 워크로드 정보
소스 및 대상 표준 서비스와 버전 정보
추적이 사용 설정된 경우 샘플링, trace ID, 스팬 ID와 같은 trace 정보가 포함된 로그

트래픽 로그에는 다음 라벨이 포함될 수 있습니다.

route_name
upstream_cluster
X-Envoy-Original-Path

다음은 예시 로그 항목입니다.

{
  "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
}

이 로그를 다양한 방법으로 사용할 수 있습니다.

Cloud Service Mesh의 선택적 기능인 Cloud Trace와 통합
트래픽 로그를 BigQuery로 내보내기. 이때 모든 요청 선택과 같은 쿼리를 실행하는 경우 5초 넘게 걸립니다.
로그 기반 측정항목 만들기
404 및 503 오류 문제 해결

`404` 및 `503` 오류 문제 해결

다음 예시에서는 404 또는 503 응답 코드로 요청이 실패할 때 문제 해결을 위해 이 로그를 사용하는 방법을 설명합니다.

클라이언트 액세스 로그에서 다음과 같이 항목을 검색합니다.

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

액세스 로그 항목의 라벨로 이동합니다. 다음과 같이 response_flag 필드를 찾습니다.
```
response_flag: "NR"
```
NR 값은 NoRoute의 약어입니다. 즉, 대상에 대한 경로를 찾을 수 없거나 다운스트림 연결에 일치하는 필터 체인이 없음을 의미합니다. 마찬가지로 response_flag 라벨을 사용하여 503 오류도 문제 해결할 수 있습니다.
클라이언트 및 서버 액세스 로그 모두에 503 오류가 표시된 경우 각 서비스에 설정된 포트 이름이 둘 사이에 사용 중인 프로토콜의 이름과 일치하는지 확인합니다. 예를 들어 golang 바이너리 클라이언트가 HTTP를 사용하여 golang 서버에 연결되지만 포트 이름이 http2이면 프로토콜이 올바르게 자동 협상되지 않습니다.

자세한 내용은 응답 플래그를 참조하세요.

Envoy 액세스 로그 해석

다음 단계에서는 Envoy 액세스 로그를 사용하여 문제 해결을 위해 연결의 양 끝단 사이의 트래픽을 표시하는 방법을 설명합니다.

Envoy 액세스 로그는 다음과 같은 문제를 진단하는 데 유용합니다.

트래픽 흐름 및 장애
엔드 투 엔드 요청 라우팅

Envoy 액세스 로그는 기본적으로 Cloud Service Mesh에서 사용 설정되어 있지 않으며 메시의 클러스터에 사용 설정될 수 있습니다.

HTTP 요청을 트리거하는 애플리케이션에서 작업을 생성한 후 소스 로그나 대상 로그에서 연관된 요청을 조사하여 연결 오류나 요청 오류를 해결할 수 있습니다.

요청을 트리거하고 요청이 소스 프록시 로그에 표시되면 iptables 트래픽 리디렉션이 올바르게 작동 중이고 Envoy 프록시가 트래픽을 처리 중임을 나타냅니다. 로그에 오류가 표시되면 Envoy 구성 덤프를 생성하고 envoy 클러스터 구성을 검사하여 올바른지 확인합니다. 요청이 표시되지만 로그에 오류가 없는 경우 대신 대상 프록시 로그를 확인합니다.

요청이 대상 프록시 로그에 표시되면 메시 자체가 올바르게 작동되고 있음을 나타냅니다. 대신 오류가 표시되면 Envoy 구성 덤프를 실행하고 리스너 구성에 설정된 트래픽 포트에 대해 올바른 값을 확인합니다.

이전 단계를 수행한 후에도 문제가 지속되면 Envoy가 사이드카 및 해당 애플리케이션 포드 사이에 프로토콜을 자동 협상하지 못하는 것일 수 있습니다. Kubernetes 서비스 포트 이름(예: http-80)이 애플리케이션에 사용되는 프로토콜과 일치하는지 확인합니다.

로그 탐색기를 사용하여 로그 쿼리

로그 탐색기 인터페이스를 사용하여 특정 Envoy 액세스 로그를 쿼리할 수 있습니다. 예를 들어 MULTUAL_TLS가 사용 설정된 모든 요청을 쿼리하고 grpc 프로토콜을 사용하려면 서버 액세스 로그 쿼리에 다음을 추가합니다.

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

액세스 로그 정책 설정

관리형 Cloud Service Mesh

관리형 Cloud Service Mesh 컨트롤 플레인을 사용하는 Cloud Service Mesh의 액세스 로그를 구성하려면 액세스 로그 사용 설정을 참조하세요.

관리형 `istiod`

관리형 istiod 컨트롤 플레인을 사용하는 Cloud Service Mesh의 액세스 로그를 구성하려면 액세스 로그 사용 설정을 참조하세요.

클러스터 내

클러스터 내 컨트롤 플레인을 사용하여 Cloud Service Mesh의 액세스 로그 정책을 설정하려면 다음 안내를 따르세요.

시나리오에 적용 가능한 AccessLogPolicyConfig 값을 포함하는 IstioOperator 커스텀 오버레이 파일을 만듭니다.
클러스터 내 제어 영역 구성을 업데이트하려면 --custom_overlay 옵션을 사용하여 이 파일을 asmcli에 전달합니다. 커스텀 오버레이 파일로 asmcli install을 실행하는 방법은 선택적 기능으로 설치를 참조하세요.

주의: 이전 설치를 맞춤설정한 경우 AccessLogPolicyConfig 설정으로 파일을 포함하도록 컨트롤 플레인을 다시 설치할 때 동일한 맞춤설정이 필요합니다. 오버레이 파일을 생략하면 성공적으로 설치됩니다. 하지만 서비스 메시는 생략된 값이 컨트롤 플레인이 다시 배포될 때 기본값으로 재설정되기 때문에 의도한 구성과 다릅니다.

서비스 또는 워크로드 관련 정보 보기

메시 전체 문제가 아닌 특정 서비스 또는 워크로드와 관련된 문제인 경우 개별 Envoy 프록시를 검사하고 관련 정보를 수집합니다. 특정 워크로드 및 해당 프록시에 대한 정보를 수집하려면 pilot-agent를 사용하면 됩니다.

kubectl exec POD_NAME -n NAMESPACE_NAME -c istio-proxy -- pilot-agent request GET SCOPE

이 예시에서 SCOPE는 다음 중 하나입니다.

certs - Envoy 인스턴스 내의 인증서
clusters - Envoy가 구성된 클러스터
config_dump - Envoy 구성 덤프
listeners - Envoy가 구성된 리스너
logging - 로깅 설정 확인 및 변경
stats - Envoy 통계
stats/prometheus - Prometheus 레코드인 Envoy 통계

프록시 소켓 상태 보기

다음 프로세스를 사용하여 Envoy 프록시 소켓의 상태를 직접 확인할 수 있습니다.

TIME_WAIT 상태의 소켓을 포함하여 설정된 소켓의 목록을 표시합니다. 개수가 많으면 확장성에 부정적인 영향을 미칠 수 있습니다.
```
kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -anopim
```

소켓 통계의 요약을 표시합니다.

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

자세한 내용은 ss 명령어 소개를 참조하세요.

`istio-proxy` 및 `istio-init` 로그

또한 istio-proxy 로그를 검색하고 문제 원인을 나타낼 수 있는 오류가 있는지 해당 콘텐츠를 검토합니다.

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

init 컨테이너에도 동일한 작업을 수행할 수 있습니다.

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-init

다음 단계

Cloud Trace와 통합하기. Cloud Trace는 Cloud Service Mesh의 선택적 기능입니다.
BigQuery로 트래픽 로그 내보내기
로그 기반 측정항목 만들기

프록시 로그 요청

액세스 로그 사용 설정 및 중지

관리형 Cloud Service Mesh

Envoy 액세스 로그

트래픽 로그

둘 다

관리형 istiod

Envoy 액세스 로그

트래픽 로그

클러스터 내

Envoy 액세스 로그

트래픽 로그

액세스 로그 보기

Envoy 액세스 로그

명령줄

로그 탐색기

트래픽 로그

서버 로그

클라이언트 로그

Cloud Service Mesh 원격 분석 해석

제어 영역 측정항목 해석

관리형 Cloud Service Mesh

관리형 istiod

클러스터 내

구성 지연 진단

관리형 Cloud Service Mesh

관리형 istiod

클러스터 내

트래픽 로그 해석

404 및 503 오류 문제 해결

Envoy 액세스 로그 해석

로그 탐색기를 사용하여 로그 쿼리

액세스 로그 정책 설정

관리형 Cloud Service Mesh

관리형 istiod

클러스터 내

서비스 또는 워크로드 관련 정보 보기

프록시 소켓 상태 보기

istio-proxy 및 istio-init 로그

다음 단계

관리형 `istiod`

관리형 `istiod`

관리형 `istiod`

`404` 및 `503` 오류 문제 해결

관리형 `istiod`

`istio-proxy` 및 `istio-init` 로그