Anthos Service Mesh 페이지에서는 애플리케이션 로그, 오류 로그, 트래픽 로그와 같이 Cloud Logging에 있는 세 가지 로그 유형에 대한 링크를 제공합니다.
애플리케이션 로그 액세스
지정된 기간 동안 서비스의 애플리케이션 로그를 보려면 다음 단계를 따르세요.
Google Cloud Console에서 Anthos Service Mesh 페이지로 이동합니다.
서비스에서 검사하려는 서비스의 이름을 선택합니다.
측정항목 페이지로 이동합니다.
기간 드롭다운 메뉴에서 기간을 지정하거나 타임라인으로 커스텀 스팬을 설정합니다.
애플리케이션 로그 보기를 클릭합니다.
애플리케이션 로그는 고유 애플리케이션 코드로 생성된 로그이며, 애플리케이션에서 사용하는 해당 모니터링 리소스(k8s_container 또는 gce_instance)에 연결됩니다.
오류 로그 액세스
지정된 기간 동안 서비스의 오류 로그를 보려면 다음 단계를 따르세요.
Google Cloud Console에서 Anthos Service Mesh 페이지로 이동합니다.
서비스에서 검사하려는 서비스의 이름을 선택합니다.
진단 페이지로 이동합니다.
기간 드롭다운 메뉴에서 기간을 지정하거나 타임라인으로 커스텀 스팬을 설정합니다.
창 오른쪽 상단에서 Logging에서 열기를 클릭합니다.
트래픽 로그 액세스
지정된 기간 동안 서비스의 트래픽 로그를 보거나 Istio의 로그에 액세스하려면 다음 단계를 따르세요.
Google Cloud Console에서 Anthos 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 로그 해석
다음 섹션에서는 메시의 상태를 확인하고 문제 해결에 도움이 되는 세부정보가 포함된 다양한 로그를 검토하는 방법을 설명합니다.
제어 영역 측정항목 해석
asm-gcp 프로필을 사용하여 Anthos Service Mesh를 설치할 때 Istiod는 기본적으로 모니터링할 수 있도록 측정항목을 Google Cloud Observability로 내보냅니다. Istiod는 이러한 측정항목에 istio.io/control로 프리픽스를 지정하고 각 제어 영역 인스턴스에 연결된 프록시 수, 구성 이벤트, 푸시, 검사와 같은 제어 영역 상태에 대한 유용한 정보를 제공합니다.
다음 단계에 따라 제어 영역을 관찰하거나 문제 해결합니다.
샘플 대시보드 로드:
git clone https://github.com/GoogleCloudPlatform/monitoring-dashboard-samples && cd monitoring-dashboard-samples && git checkout asm
Anthos Service Mesh 대시보드를 설치합니다.
gcloud monitoring dashboards create --config-from-file=dashboards/servicemesh/anthos-service-mesh-control-plane-monitoring.json
목록에서
Istio Control Plane Dashboard라는 대시보드를 찾습니다. 자세한 내용은 설치된 대시보드 보기를 참조하세요.asm-gcp프로필을 사용하지 않을 경우에도 Istiod 배포에 환경 변수를 추가하여 제어 영역 측정항목을 사용 설정할 수 있습니다.- name: ENABLE_STACKDRIVER_MONITORING value: "true"
또한
components.pilot.k8s.env설치 옵션을 사용하여 이 환경 변수를 추가할 수 있습니다.
사용 가능한 전체 측정항목 목록은 내보낸 측정항목을 참조하세요.
구성 지연 진단
다음 단계에서는 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 액세스 로그를 사용하여 연결 문제를 해결하는 방법을 설명합니다.
Anthos Service Mesh는 다음 유형의 문제를 디버깅하는 데 도움이 되는 Google Cloud Observability 액세스 로그로 데이터를 내보냅니다.
- 트래픽 흐름 및 장애
- 엔드 투 엔드 요청 라우팅
Google Cloud Observability 액세스/트래픽 로그는 기본적으로 전체 메시의 asm-gcp 프로필에 사용 설정되어 있습니다. 하지만 아직 사용 설정되어 있지 않으면 다음 명령어를 사용할 수 있습니다.
istioctl install --set profile=PROFILE_NAME --set revision==ASM_VERSION \
--set values.telemetry.v2.stackdriver.enabled=true \
--set values.telemetry.v2.stackdriver.logging=true
액세스 로그 유형에는 다음 두 가지가 있습니다.
서버 액세스 로그는 서버 측 요청 보기를 제공합니다. 로그는
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
로깅 비용을 줄이기 위해 기본적으로 클라이언트 오류 로그만 사용 설정되지만 다음 명령어를 사용하면 모든 클라이언트 로그(성공 및 오류)를 사용 설정할 수 있습니다.
istioctl install --set profile=PROFILE_NAME --set revision==ASM_VERSION \
--set values.telemetry.v2.stackdriver.enabled=true \
--set values.telemetry.v2.stackdriver.outboundAccessLogging=FUL
액세스 로그에는 다음 정보가 포함됩니다.
- ID, URL, 크기, 지연 시간, 공통 헤더 등 HTTP 요청 속성
- 이름, 네임스페이스, ID, 일반 라벨과 같은 소스 및 대상 워크로드 정보
- 소스 및 대상 표준 서비스와 버전 정보
- 추적이 사용 설정된 경우 샘플링, trace ID, 스팬 ID와 같은 trace 정보를 포함하는 로그
Google Cloud Observability 액세스 로그에 표시되는 정보는 Istio 구성에서 사용 설정할 때 Envoy 액세스 로그에서 시작됩니다. 여기에는 다음 헤더가 포함됩니다.
route_nameupstream_clusterX-Envoy-Original-PathX-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"
액세스 로그 정책 설정
수집하는 정보 유형을 결정하는 프록시 로깅 정책을 설정할 수 있습니다. 이 정책은 문제 해결을 위해 로그 범위를 제어하는 데 유용합니다. 예를 들어 로깅은 오류를 자동으로 캡처하지만 특정 기간 동안 성공한 이벤트를 캡처하도록 logWindowDuration을 설정하거나 기간을 0으로 설정하여 모든 액세스를 로깅할 수 있습니다. 정책은 메시 또는 클러스터 수준에서 설정됩니다.
액세스 로그 정책을 사용 설정하려면 다음 명령어를 사용합니다.
istioctl install --set profile=PROFILE_NAME \
--set values.telemetry.v2.stackdriver.enabled=true \
--set values.telemetry.v2.stackdriver.logging=true \
--set values.telemetry.accessLogPolicy.enabled=true
logWindowDuration과 같은 액세스 로그 구성 옵션에 대한 상세 설명은 AccessLogPolicy 구성을 참조하세요.
서비스 또는 워크로드 관련 정보 보기
메시 전체 문제가 아닌 특정 서비스 또는 워크로드와 관련된 문제인 경우 개별 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의 선택적 기능입니다.