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

Cloud Service Mesh의 관측 가능성 및 원격 분석 문제 해결

이 섹션에서는 일반적인 Cloud Service Mesh 문제와 해결 방법을 설명합니다. 추가 지원이 필요하면 지원 받기를 참조하세요.

Cloud Service Mesh 원격 분석에서 Envoy 프록시는 주기적으로 Google Cloud Observability API를 호출하여 원격 분석 데이터를 보고합니다. API 호출 유형에 따라 실행 빈도가 결정됩니다.

로깅: 약 10초 간격
측정항목: 약 1분 간격
에지(Context API/토폴로지 뷰): 증분 보고서는 약 1분 간격, 전체 보고서는 약 10분 간격
Trace: 구성한 샘플링 빈도에 따라 결정(일반적으로 100개의 요청 중 1개)

원격 분석 대시보드는 Confluence 및 Google Cloud Observability에서 데이터를 수집하여 다양한 서비스 중심 대시보드를 표시합니다.

Istio 원격 분석 API 구성이 최대 1개 있는지 확인

이 섹션은 관리형 Cloud Service Mesh 컨트롤 플레인에만 적용됩니다.

원격 분석 API 구성을 나열하려면 다음 명령어를 실행합니다. Istio 원격 분석 API 구성이 최대 1개 있는지 확인합니다.

kubectl -n istio-system get telemetry

서비스 대시보드에 서비스가 없음

대시보드에 HTTP(S)/gRPC 서비스만 표시됩니다. 서비스가 목록에 있다면 Cloud Service Mesh 원격 분석에서 이를 HTTP 서비스로 식별하는지 확인합니다.

서비스가 누락된 경우 클러스터에 Kubernetes 서비스 구성이 있는지 확인합니다.

모든 Kubernetes 서비스 목록을 검토합니다.
```
kubectl get services --all-namespaces
```
특정 네임스페이스의 Kubernetes 서비스 목록을 검토합니다.
```
kubectl get services -n YOUR_NAMESPACE
```

서비스에 대한 측정항목이 누락되거나 잘못됨

서비스 대시보드에 서비스에 대한 측정항목이 누락되거나 잘못된 경우 다음 섹션에서 가능한 해결 방법을 참조하세요.

사이드카 프록시가 있으며 제대로 삽입되었는지 확인

네임스페이스에 자동 삽입 라벨이 없거나 수동 삽입에 실패한 경우일 수 있습니다. 네임스페이스의 포드에 컨테이너가 2개 이상 있고 이 중 1개가 istio-proxy 컨테이너인지 확인합니다.

kubectl -n YOUR_NAMESPACE get pods

원격 분석 구성이 있는지 확인하기

Google Cloud Observability 필터가 구성되어 있는지 확인하려면 각 프록시에서 구성 덤프를 수집하고 Google Cloud Observability 필터가 있는지 확인합니다.

kubectl debug --image istio/base --target istio-proxy -it YOUR_POD_NAME -n YOUR_NAMESPACE curl localhost:15000/config_dump

이전 명령어 출력에서 다음과 같은 Google Cloud Observability 필터를 찾습니다.

"config": {
    "root_id": "stackdriver_inbound",
    "vm_config": {
        "vm_id": "stackdriver_inbound",
        "runtime": "envoy.wasm.runtime.null",
        "code": {
            "local": {
                "inline_string": "envoy.wasm.null.stackdriver"
             }
         }
     },
     "configuration": "{....}"
}

Cloud Service Mesh가 HTTP 서비스를 식별하는지 확인

Kubernetes 서비스의 서비스 포트가 http 또는 http- 프리픽스가 있는 이름으로 지정되지 않으면 사용자 인터페이스에 측정항목이 표시되지 않습니다. 서비스의 포트 이름이 올바른지 확인합니다.

프로젝트에 Cloud Monitoring API가 사용 설정되었는지 확인

Google Cloud 콘솔의 API 및 서비스 대시보드에서 Cloud Monitoring API가 기본으로 사용 설정되어 있는지 확인합니다.

Cloud Monitoring API에 대한 오류 보고가 없는지 확인

Google Cloud 콘솔 API 및 서비스 대시보드에서 응답 코드별 트래픽 그래프 URL을 엽니다.

https://console.cloud.google.com/apis/api/monitoring.googleapis.com/metrics?folder=&organizationId=&project=YOUR_PROJECT_ID

오류 메시지가 표시되는 경우 추가 조사가 필요할 수 있습니다. 특히 잠재적인 할당량 문제를 나타내는 다수의 429 오류 메시지를 찾습니다. 문제 해결 단계는 다음 섹션을 참조하세요.

Cloud Monitoring API의 올바른 할당량 확인

Google Cloud 콘솔에서 IAM & Admin 메뉴를 열고 할당량 옵션이 있는지 확인합니다. URL을 사용하여 이 페이지에 직접 액세스할 수 있습니다.

https://console.cloud.google.com/iam-admin/quotas?project=YOUR_PROJECT_ID

이 페이지는 프로젝트의 전체 할당량 집합을 보여주며, 여기서 Cloud Monitoring API를 검색할 수 있습니다.

Envoy 프록시에 오류 로그가 없는지 확인

해당 프록시의 로그를 검토하여 오류 메시지 인스턴스를 검색합니다.

kubectl -n YOUR_NAMESPACE logs YOUR_POD_NAME -c istio-proxy

그러나 다음과 같은 경고 메시지는 정상이므로 무시해도 됩니다.

[warning][filter] [src/envoy/http/authn/http_filter_factory.cc:83]
mTLS PERMISSIVE mode is used, connection can be either plaintext or TLS,
and client cert can be omitted. Please consider to upgrade to mTLS STRICT mode
for more secure configuration that only allows TLS connection with client cert.
See https://istio.io/docs/tasks/security/mtls-migration/ [warning][config]
[bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91]
gRPC config stream closed: 13

`metric.mesh_uid`가 올바르게 설정되었는지 확인

측정항목 탐색기를 열고 다음 MQL 쿼리를 실행합니다.

fetch istio_canonical_service
| metric 'istio.io/service/server/request_count'
| align delta(1m)
| every 1m
| group_by [metric.destination_canonical_service_namespace, metric.destination_canonical_service_name, metric.mesh_uid]

예상되는 모든 서비스가 측정항목을 보고하고 있는지, metric.mesh_uid가 proj-<Cloud Service Mesh fleet project number> 형식인지 확인합니다.

metric.mesh_uid에 다른 값이 있으면 Cloud Service Mesh 대시보드에 측정항목이 표시되지 않습니다. Cloud Service Mesh가 클러스터에 설치되면 metric.mesh_uid가 설정되므로 설치 방법을 조사하여 예상 값으로 설정할 방법이 있는지 확인합니다.

서비스에 대한 원격 분석 데이터가 누락되거나 잘못됨

기본적으로 Cloud Service Mesh를 설치할 때 Google Cloud 프로젝트에서 Cloud Monitoring 및 Cloud Logging이 사용 설정됩니다. 원격 분석 데이터를 보고하기 위해 서비스 포드에 삽입되는 각 사이드카 프록시가 Cloud Monitoring API 및 Cloud Logging API를 호출합니다. 워크로드를 배포한 후 Google Cloud Console에 원격 분석 데이터가 표시되는 데 1~2분 정도 걸립니다. Cloud Service Mesh는 서비스 대시보드를 자동으로 최신 상태로 유지합니다.

측정항목의 경우 사이드카 프록시는 약 1분 간격으로 Cloud Monitoring API를 호출합니다.
토폴로지 그래프를 업데이트하기 위해 사이드카 프록시는 약 1분 간격으로 증분 보고서를, 약 10분 간격으로 전체 보고서를 전송합니다.
로깅의 경우 사이드카 프록시는 약 10초 간격으로 Cloud Logging API를 호출합니다.
추적의 경우 Cloud Trace를 사용 설정해야 합니다. Trace는 구성한 샘플링 빈도(일반적으로 100개의 요청 중 1개)에 따라 보고됩니다.

측정항목은 Cloud Service Mesh 측정항목 페이지에 있는 HTTP 서비스에만 표시됩니다. 측정항목이 표시되지 않으면 애플리케이션 서비스의 네임스페이스에 있는 모든 포드에 사이드카 프록시가 삽입되어 있는지 확인합니다.

kubectl get pod -n YOUR_NAMESPACE --all

출력의 READY 열에서 각 워크로드마다 컨테이너가 2개(기본 컨테이너와 사이드카 프록시 컨테이너)가 있다는 것을 확인할 수 있습니다.

또한 서비스 대시보드에는 서버 측정항목만 표시되므로 클라이언트가 메시에 있지 않거나 클라이언트 측정항목(인그레스 게이트웨이 등)만 보고하도록 구성된 경우 원격 분석 데이터가 표시되지 않을 수 있습니다.