Anthos Service Mesh 1.13은 지원 종료되어 더 이상 지원되지 않습니다. 이전 버전에서 업그레이드를 참조하세요.

최신 문서를 보거나 사용 가능한 다른 버전을 선택합니다.

사용 가능한 버전

Cloud Logging에서 로그 액세스

Anthos Service Mesh 페이지에서는 애플리케이션 로그, 오류 로그, 트래픽 로그와 같이 Cloud Logging에 있는 세 가지 로그 유형에 대한 링크를 제공합니다.

애플리케이션 로그 액세스

지정된 기간 동안 서비스의 애플리케이션 로그를 보려면 다음 단계를 따르세요.

Google Cloud Console에서 Anthos Service Mesh 페이지로 이동합니다.

Anthos Service Mesh 페이지로 이동
서비스에서 검사하려는 서비스의 이름을 선택합니다.
측정항목 페이지로 이동합니다.
기간 드롭다운 메뉴에서 기간을 지정하거나 타임라인으로 커스텀 스팬을 설정합니다.
애플리케이션 로그 보기를 클릭합니다.

애플리케이션 로그는 고유 애플리케이션 코드로 생성된 로그이며, 애플리케이션에서 사용하는 해당 모니터링 리소스(k8s_container 또는 gce_instance)에 연결됩니다.

오류 로그 액세스

지정된 기간 동안 서비스의 오류 로그를 보려면 다음 단계를 따르세요.

Google Cloud Console에서 Anthos Service Mesh 페이지로 이동합니다.

Anthos Service Mesh 페이지로 이동
서비스에서 검사하려는 서비스의 이름을 선택합니다.
진단 페이지로 이동합니다.
기간 드롭다운 메뉴에서 기간을 지정하거나 타임라인으로 커스텀 스팬을 설정합니다.
창 오른쪽 상단에서 Logging에서 열기를 클릭합니다.

트래픽 로그 액세스

지정된 기간 동안 서비스의 트래픽 로그를 보거나 Istio의 로그에 액세스하려면 다음 단계를 따르세요.

Google Cloud Console에서 Anthos Service Mesh 페이지로 이동합니다.

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

Anthos Service Mesh 로그 해석

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

제어 영역 측정항목 해석

클러스터 내 제어 영역으로 Anthos 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

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

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

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

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

구성 지연 진단

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

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

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

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

Google Cloud Observability 액세스 로그 해석

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

Anthos Service Mesh는 다음 유형의 문제를 디버깅하는 데 도움이 되는 Google Cloud Observability 액세스 로그로 데이터를 내보냅니다.

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

Google Cloud Observability 액세스 로그는 기본적으로 Google Kubernetes Engine의 Anthos Service Mesh에 사용 설정됩니다. asmcli install을 다시 실행하여 Google Cloud Observability 액세스 로그를 사용 설정할 수 있습니다. 원래 설치한 것과 동일한 옵션을 사용하되, 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 정보를 포함하는 로그

Google Cloud Observability 액세스 로그에 표시되는 정보는 Istio 구성에서 사용 설정할 때 Envoy 액세스 로그에서 시작됩니다. 여기에는 다음 헤더가 포함됩니다.

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

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

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

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

Anthos 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 액세스 로그는 다음과 같은 문제를 진단하는 데 유용합니다.

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

액세스 로그는 Anthos Service Mesh에서 기본으로 사용 설정되어 있지 않으며 전체 메시에서 전역으로 사용 설정할 수 있습니다.

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

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

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

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

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

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

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

액세스 로그 정책 설정

관리형 Anthos Service Mesh의 프록시 로깅을 구성하려면 Envoy 액세스 로그를 참조하세요.

클러스터 내 제어 영역을 사용하여 Anthos Service Mesh의 액세스 로그 정책을 설정하려면 다음 안내를 따르세요.

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

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

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

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

kubectl exec POD_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 exec POD_NAME -c istio-proxy -- ss -anopim
```

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

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

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

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

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

kubectl logs POD_NAME -c istio-proxy

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

kubectl logs POD_NAME -c istio-init

다음 단계

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