Cloud Logging에서 로그 액세스
Cloud Service Mesh 페이지에서는 애플리케이션 로그, 오류 로그, 트래픽 로그와 같이 Cloud Logging에 있는 세 가지 로그 유형에 대한 링크를 제공합니다.
애플리케이션 로그 액세스
지정된 기간 동안 서비스의 애플리케이션 로그를 보려면 다음 단계를 따르세요.
Google Cloud 콘솔에서 Cloud Service Mesh 페이지로 이동합니다.
서비스에서 검사하려는 서비스의 이름을 선택합니다.
측정항목 페이지로 이동합니다.
기간 드롭다운 메뉴에서 기간을 지정하거나 타임라인으로 커스텀 스팬을 설정합니다.
애플리케이션 로그 보기를 클릭합니다.
애플리케이션 로그는 고유 애플리케이션 코드로 생성된 로그이며, 애플리케이션에서 사용하는 해당 모니터링 리소스(k8s_container 또는 gce_instance)에 연결됩니다.
오류 로그 액세스
지정된 기간 동안 서비스의 오류 로그를 보려면 다음 단계를 따르세요.
Google Cloud 콘솔에서 Cloud Service Mesh 페이지로 이동합니다.
서비스에서 검사하려는 서비스의 이름을 선택합니다.
진단 페이지로 이동합니다.
기간 드롭다운 메뉴에서 기간을 지정하거나 타임라인으로 커스텀 스팬을 설정합니다.
창 오른쪽 상단에서 Logging에서 열기를 클릭합니다.
트래픽 로그 액세스
지정된 기간 동안 서비스의 트래픽 로그를 보거나 Istio의 로그에 액세스하려면 다음 단계를 따르세요.
Google Cloud 콘솔에서 Cloud Service Mesh 페이지로 이동합니다.
서비스에서 검사하려는 서비스의 이름을 선택합니다.
측정항목 페이지로 이동합니다.
기간 드롭다운 메뉴에서 기간을 지정하거나 타임라인으로 커스텀 스팬을 설정합니다.
filter_list 필터 옵션 선택에서 트래픽 로그 보기를 클릭합니다.
트래픽 로그는 이름이 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 원격 분석 해석
다음 섹션에서는 메시의 상태를 확인하고 문제 해결에 도움이 되는 세부정보가 포함된 다양한 원격 분석을 검토하는 방법을 설명합니다.
컨트롤 플레인 측정항목 해석
클러스터 내 컨트롤 플레인으로 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
라는 대시보드를 찾습니다. 자세한 내용은 설치된 대시보드 보기를 참조하세요.
사용 가능한 전체 측정항목 목록은 내보낸 측정항목을 참조하세요.
구성 지연 진단
다음 단계에서는 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 액세스/트래픽 로그는 기본적으로 사용 설정되어 있습니다.
Cloud Service Mesh는 다음 유형의 문제를 디버깅하는 데 도움이 되는 Google Cloud Observability 액세스 로그로 데이터를 내보냅니다.
- 트래픽 흐름 및 장애
- 엔드 투 엔드 요청 라우팅
Google Cloud Observability 액세스 로그는 기본적으로 Google Kubernetes Engine의 Cloud 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 }
이 로그는 다양한 방법으로 사용할 수 있습니다.
- 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 액세스 로그는 다음과 같은 문제를 진단하는 데 유용합니다.
- 트래픽 흐름 및 장애
- 엔드 투 엔드 요청 라우팅
액세스 로그는 Cloud Service Mesh에서 기본으로 사용 설정되어 있지 않으며 전체 메시에서 전역으로 사용 설정할 수 있습니다.
애플리케이션에서 HTTP 요청을 트리거하는 작업을 생성한 후 소스 또는 대상 로그에서 연관된 요청을 조사하여 연결/요청 오류를 문제 해결할 수 있습니다.
요청을 트리거하고 요청이 소스 프록시 로그에 표시되면 iptables
트래픽 리디렉션이 올바르게 작동 중이고 Envoy 프록시가 트래픽을 처리 중임을 나타냅니다. 로그에 오류가 표시되면 Envoy 구성 덤프를 생성하고 envoy 클러스터 구성을 검사하여 올바른지 확인합니다. 요청이 표시되지만 로그에 오류가 없는 경우 대신 대상 프록시 로그를 확인합니다.
요청이 대상 프록시 로그에 표시되면 메시 자체가 올바르게 작동되고 있음을 나타냅니다. 대신 오류가 표시되면 Envoy 구성 덤프를 실행하고 리스너 구성에 설정된 트래픽 포트에 대해 올바른 값을 확인합니다.
이전 단계를 수행한 후에도 문제가 지속되면 Envoy가 사이드카 및 해당 애플리케이션 포드 사이에 프로토콜을 자동 협상하지 못하는 것일 수 있습니다. Kubernetes 서비스 포트 이름(예: http-80
)이 애플리케이션에 사용되는 프로토콜과 일치하는지 확인합니다.
로그 탐색기를 사용하여 로그 쿼리
로그 탐색기 인터페이스를 사용하여 특정 액세스 로그를 쿼리할 수 있습니다. 예를 들어 MULTUAL_TLS
가 사용 설정된 모든 요청을 쿼리하고 프로토콜 grpc
를 사용하려면 서버 액세스 로그 쿼리에 다음을 추가합니다.
labels.protocol="grpc" labels.service_authentication_policy="MULTUAL_TLS"
액세스 로그 정책 설정
관리형 Cloud Service Mesh의 프록시 로깅을 구성하려면 Envoy 액세스 로그를 참조하세요.
클러스터 내 컨트롤 플레인을 사용하여 Cloud Service Mesh의 액세스 로그 정책을 설정하려면 다음 안내를 따르세요.
시나리오에 적용 가능한
AccessLogPolicyConfig
값을 포함하는IstioOperator
커스텀 오버레이 파일을 만듭니다.클러스터 내 제어 영역 구성을 업데이트하려면
--custom_overlay
옵션을 사용하여 이 파일을asmcli
에 전달합니다. 커스텀 오버레이 파일로asmcli install
을 실행하는 방법은 선택적 기능으로 설치를 참조하세요.
서비스 또는 워크로드 관련 정보 보기
메시 전체 문제가 아닌 특정 서비스 또는 워크로드와 관련된 문제인 경우 개별 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는 Cloud Service Mesh의 선택적 기능입니다.