모니터링 대시보드 문제 해결

이 페이지에서는 Google Kubernetes Engine(GKE)의 문제 관련 모니터링 대시보드를 해결하는 방법을 보여줍니다.

클러스터를 만들면 기본적으로 Monitoring이 사용 설정됩니다. Monitoring에서 제공된 Google Cloud 대시보드를 확인할 때 GKE 대시보드가 표시되지 않으면 선택한 Google Cloud 프로젝트의 클러스터에 Monitoring이 사용 설정되지 않은 것입니다. 이러한 대시보드를 보려면 모니터링을 사용 설정하세요.

대시보드에 Kubernetes 리소스가 없음

GKE 대시보드에 Kubernetes 리소스가 표시되지 않으면 다음을 확인하세요.

선택된 Google Cloud 프로젝트

Google Cloud 콘솔 메뉴 바의 드롭다운 목록에서 올바른 Google Cloud 프로젝트를 선택했는지 확인합니다. 보려는 데이터가 포함된 프로젝트를 선택해야 합니다.

클러스터 활동

클러스터를 방금 전에 만든 경우 데이터가 채워질 때까지 몇 분 정도 기다리세요. 자세한 내용은 GKE의 로깅 및 모니터링 구성을 참조하세요.

기간

선택한 기간이 너무 짧을 수 있습니다. 대시보드 툴바의 시간 메뉴를 사용하여 다른 기간을 선택하거나 커스텀 범위를 정의할 수 있습니다.

대시보드를 볼 수 있는 권한

서비스의 배포 세부정보 또는 Google Cloud 프로젝트의 측정항목을 볼 때 다음과 같은 권한 거부 오류 메시지가 표시되면 Identity and Access Management 역할을 업데이트하여 roles/monitoring.viewer 또는 roles/viewer를 포함하도록 해야 합니다.

  • You do not have sufficient permissions to view this page
  • You don't have permissions to perform the action on the selected resources

자세한 내용을 보려면 사전 정의된 역할로 이동합니다.

Monitoring 및 Logging에 데이터를 쓸 수 있는 클러스터 및 노드 서비스 계정 권한

Google Cloud Console의 사용 설정된 API 및 서비스 페이지에서 오류율이 높을 경우 서비스 계정에 다음 역할이 누락된 것일 수 있습니다.

  • roles/logging.logWriter: Google Cloud Console에서 이 역할의 이름은 로그 작성자입니다. Logging 역할에 대한 자세한 내용은 Logging 액세스 제어 가이드를 참조하세요.

  • roles/monitoring.metricWriter: Google Cloud Console에서 이 역할의 이름은 Monitoring 측정항목 작성자입니다. Monitoring 역할에 대한 자세한 내용은 Monitoring 액세스 제어 가이드를 참조하세요.

  • roles/stackdriver.resourceMetadata.writer: Google Cloud Console에서 이 역할의 이름은 Stackdriver 리소스 메타데이터 작성자입니다. 이 역할은 리소스 메타데이터에 대한 쓰기 전용 액세스를 허용하며 에이전트가 메타데이터를 전송하는 데 필요한 권한을 정확히 제공합니다. Monitoring 역할에 대한 자세한 내용은 Monitoring 액세스 제어 가이드를 참조하세요.

서비스 계정을 나열하려면 Google Cloud console에서 IAM 및 관리자로 이동한 다음 서비스 계정을 선택합니다.

로그를 볼 수 없음

대시보드에 로그가 표시되지 않으면 다음을 확인합니다.

에이전트가 실행 중이고 정상 상태임

GKE 버전 1.17 이상에서는 Fluent Bit를 사용하여 로그를 캡처합니다. Fluent 비트는 Kubernetes 노드에서 실행되는 Logging 에이전트입니다. 에이전트가 올바르게 실행 중인지 확인하려면 다음 단계를 수행하세요.

  1. 다음 명령어를 실행하여 에이전트가 다시 시작되는지 확인합니다.

    kubectl get pods -l k8s-app=fluentbit-gke -n kube-system

    다시 시작되지 않으면 출력은 다음과 비슷합니다.

    NAME                  READY   STATUS    RESTARTS   AGE
fluentbit-gke-6zr6g   2/2     Running   0          44d
fluentbit-gke-dzh9l   2/2     Running   0          44d

  2. 다음 명령어를 실행하여 포드 상태 조건을 확인합니다.

    JSONPATH='{range .items[*]};{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status},{end}{end};'  \
 && kubectl get pods -l k8s-app=fluentbit-gke -n kube-system -o jsonpath="$JSONPATH" | tr ";" "\n"

    배포가 정상이면 출력은 다음과 비슷합니다.

    fluentbit-gke-nj4qs:Initialized=True,Ready=True,ContainersReady=True,PodScheduled=True,
fluentbit-gke-xtcvt:Initialized=True,Ready=True,ContainersReady=True,PodScheduled=True,

  3. 다음 명령어를 실행하여 배포 상태가 정상인지 확인하는 데 유용한 포드 상태를 확인합니다.

    kubectl get daemonset -l k8s-app=fluentbit-gke -n kube-system

    배포가 정상이면 출력은 다음과 비슷합니다.

    NAME            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
fluentbit-gke   2         2         2       2            2           kubernetes.io/os=linux   5d19h

    이 출력 예시에서 원하는 상태는 현재 상태와 일치합니다.

이러한 시나리오에서 에이전트가 실행 중이고 정상 상태이지만 모든 로그가 표시되지 않는 경우 에이전트가 과부하 상태이고 로그가 삭제될 수 있습니다.

에이전트 과부하 및 로그 삭제

모든 로그가 표시되지 않는 한 가지 이유는 노드의 로그 볼륨으로 인해 에이전트에 과부하가 발생했기 때문입니다. GKE의 기본 Logging 에이전트 구성은 각 노드에서 초당 100KiB 속도로 조정되며 볼륨이 이 한도를 초과하면 에이전트에서 로그 삭제가 시작될 수 있습니다.

이 한도에 도달했는지 감지하려면 다음 지표를 찾습니다.

  • container_name=fluentbit-gke 필터로 kubernetes.io/container/cpu/core_usage_time 측정항목을 보고 Logging 에이전트의 CPU 사용량이 100%이거나 100%에 근접했는지 확인합니다.

  • metadata.system_labels.node_name으로 그룹화된 logging.googleapis.com/byte_count 측정항목을 보고 어떤 노드가 초당 100KiB에 도달했는지 확인합니다.

이러한 조건이 발견되면 클러스터에 노드를 추가하여 노드의 로그 볼륨을 줄일 수 있습니다. 모든 로그 볼륨이 단일 Pod에서 발생하는 경우 해당 Pod에서 볼륨을 줄여야 합니다.

Logging 에이전트 튜닝 매개변수를 변경하려면 커스텀 Logging 에이전트 구성 배포에 대한 커뮤니티 튜토리얼을 참조하세요.

GKE 로깅 관련 문제 조사 및 해결에 대한 자세한 내용은 GKE에서 로깅 문제 해결을 참조하세요.

이슈가 GKE 리소스와 일치하지 않나요?

고유 GKE 리소스 간에 측정항목을 집계하는 알림 정책 조건이 있으면 이슈를 특정 항목과 연결하기 위해 더 많은 GKE 계층 라벨을 포함하도록 정책 조건을 수정해야 할 수 있습니다.

예를 들어 프로덕션 및 스테이징을 위해 GKE 클러스터가 2개 있고, 각 클러스터에 고유 서비스 lilbuddy-2 복사본이 포함되어 있을 수 있습니다. 알림 정책 조건이 두 클러스터 모두의 컨테이너에서 측정항목을 수집할 때 GKE Monitoring 대시보드는 프로덕션 서비스 또는 스테이징 서비스와 고유하게 이 이슈를 연결할 수 없습니다.

이 문제를 해결하기 위해서는 namespace, cluster, location을 정책의 그룹화 기준 필드에 추가하여 특정 서비스를 가리키도록 알림 정책 대상을 지정합니다. 알림 이벤트 카드에서 알림 정책 업데이트 링크를 클릭하여 관련 알림 정책에 대해 알림 정책 수정 페이지를 엽니다. 여기에서 대시보드가 관련 리소스를 찾을 수 있도록 추가 정보로 알림 정책을 업데이트할 수 있습니다.

알림 정책을 업데이트한 후에는 GKE Monitoring 대시보드가 모든 이후 이슈를 특정 클러스터의 고유 서비스와 연결하여, 문제 진단을 위한 추가 정보를 제공할 수 있습니다.

사용 사례에 따라 그룹화 기준 필드에 추가하는 것 외에도 이러한 라벨 중 일부에 따라 필터링해야 할 수 있습니다. 예를 들어 프로덕션 클러스터에 대해서만 알림이 필요하면 cluster_name으로 필터링하면 됩니다.