측정항목으로 구성 동기화 모니터링
이 페이지에서는 측정항목을 사용하여 구성 동기화 리소스를 모니터링하는 방법을 설명합니다. 구성 동기화 리소스 및 설치 상태의 개요가 필요한 경우 구성 동기화 대시보드를 사용하거나 Google Cloud CLI로 구성 동기화 상태를 확인하세요.
RootSync 및 RepoSync API를 사용 설정하면, 구성 동기화는 OpenCensus를 사용하여 측정항목을 만들어 기록하고, OpenTelemetry를 만들어 측정항목을 Prometheus 및Cloud Monitoring에 내보냅니다. 또한 OpenTelemetry를 사용하여 측정항목을 커스텀 모니터링 시스템으로 내보낼 수 있습니다. 이 프로세스는 세 가지 리소스 모니터링 방법을 제공합니다.
RootSync 및 RepoSync API를 사용 설정하지 않으면 Prometheus로 리소스 모니터링만 가능합니다.
사용 가능한 OpenTelemetry 측정항목
RootSync 및 RepoSync API가 사용 설정되면 구성 동기화 및 리소스 그룹 컨트롤러가 Opencensus로 다음 측정항목을 수집하고 OpenTelemetry 수집기를 통해 사용할 수 있게 합니다. 태그 열에는 각 측정항목에 적용 가능한 구성 동기화 관련 태그가 표시됩니다. 태그가 있는 측정항목은 태그 값의 각 조합에 대해 하나씩 여러 측정을 나타냅니다.
구성 동기화 측정항목
다음 측정항목은 지원되는 모든 Anthos Config Management 버전에서 사용할 수 있습니다.
| 이름 | 유형 | 태그 | 설명 |
|---|---|---|---|
| api_duration_seconds | 분포 | operation, status | API 서버 호출의 지연 시간 분포 |
| apply_duration_seconds | 분포 | status | 신뢰 소스에서 선언된 리소스를 클러스터에 적용할 때의 지연 시간 분포 |
| apply_operations_total | 개수 | operation, status, controller | 신뢰 소스의 리소스를 클러스터에 동기화하기 위해 수행된 총 작업 수 |
| declared_resources | 최종 값 | Git에서 파싱된 선언된 리소스 수 | |
| internal_errors_total | 개수 | source | 구성 동기화에서 발생한 총 내부 오류 수 |
| last_sync_timestamp | 최종 값 | commit, status | Git에서의 최근 동기화의 타임스탬프 |
| parser_duration_seconds | 분포 | status, trigger, source | 정보 소스에서 클러스터로의 동기화와 관련된 여러 단계의 지연 시간 분포 |
| pipeline_error_observed | 최종 값 | name, reconciler, component | RootSync 및 RepoSync 커스텀 리소스의 상태입니다. 값 1은 실패를 나타냅니다. |
| reconcile_duration_seconds | 분포 | status | 조정자 관리자가 처리한 조정 이벤트의 지연 시간 분포입니다. |
| reconciler_errors | 최종 값 | component, errorclass | 신뢰 소스의 리소스를 클러스터에 동기화하는 동안 발생한 오류 수 |
| remediate_duration_seconds | 분포 | status | 교정자 조정 이벤트의 지연 시간 분포 |
| resource_conflicts_total | 개수 | 캐시된 리소스와 클러스터 리소스 사이의 불일치로부터 발생한 총 리소스 충돌 수 | |
| resource_fights_total | 개수 | 너무 자주 동기화되고 있는 리소스의 총 개수. 0보다 큰 결과는 문제가 있음을 나타냅니다. 자세한 내용은 KNV2005: ResourceFightWarning을 참조하세요. |
Anthos Config Management 버전 1.10.1~1.13.1 사이에는 다음 측정항목을 사용할 수 있습니다. 이러한 측정항목은 시스템 성능 또는 상태를 모니터링하는 데 필요하지 않으며 비용을 줄이기 위해 Anthos Config Management 버전 1.14.0에서 삭제됩니다.
| 이름 | 유형 | 태그 | 설명 |
|---|---|---|---|
| rendering_count_total | 개수 | 리소스에 대해 Kustomize 또는 Helm 차트 렌더링이 사용된 동기화 실행 횟수 | |
| skip_rendering_count_total | 개수 | 리소스에 대해 Kustomize 또는 Helm 차트 렌더링이 사용되지 않은 동기화 실행 횟수 | |
| resource_override_count_total | 개수 | container, resource | 리소스 패치에 지정된 리소스 재정의 수 |
| git_sync_depth_override_count_total | 개수 | spec.override.gitSyncDepth 재정의가 설정된 Root/RepoSync 객체 수. Git 깊이를 사용하면 큰 저장소에서 동기화할 때 성능을 높일 수 있습니다. | |
| no_ssl_verify_count_total | 개수 | .spec.git.noSSLVerify 재정의가 설정된 Root/RepoSync 객체 수 |
리소스 그룹 컨트롤러 측정항목
리소스 그룹 컨트롤러는 관리형 리소스를 추적하고 개별 리소스가 준비 또는 조정되었는지 확인하는 구성 동기화의 구성요소입니다. 사용 가능한 측정항목은 다음과 같습니다.
| 이름 | 유형 | 태그 | 설명 |
|---|---|---|---|
| reconcile_duration_seconds | 분포 | stallreason | ResourceGroup CR을 조정하는 데 걸린 시간의 분포 |
| resource_group_total | 최종 값 | ResourceGroup CR의 현재 개수 | |
| resource_count_total | 합계 | 클러스터의 모든 ResourceGroup CR에서 추적하는 총 리소스 수 | |
| resource_count | 최종 값 | resourcegroup | ResourceGroup으로 추적된 총 리소스 수 |
| ready_resource_count_total | 합계 | 클러스터의 모든 ResourceGroup CR에서 준비된 총 리소스 수 | |
| ready_resource_count | 최종 값 | resourcegroup | ResourceGroup의 준비된 총 리소스 수 |
| resource_ns_count | 최종 값 | resourcegorup | ResourceGroup의 리소스에 사용된 네임스페이스의 수 |
| cluster_scoped_resource_count | 최종 값 | resourcegroup | ResourceGroup의 클러스터 범위 지정된 리소스 수 |
| crd_count | 최종 값 | resourcegroup | ResourceGroup의 CRD 수 |
| kcc_resource_count_total | 합계 | 클러스터에 있는 모든 ResourceGroup CR에 대한 Config Connector 리소스 총 수 | |
| kcc_resource_count | 게이지 | resourcegroup | ResourceGroup의 총 KCC 리소스 수 |
| pipeline_error_observed | 최종 값 | name, reconciler, component | RootSync 및 RepoSync 커스텀 리소스의 상태입니다. 값 1은 실패를 나타냅니다. |
구성 동기화 측정항목 라벨
측정항목 라벨을 사용하여 Cloud Monitoring 및 Prometheus의 측정항목 데이터를 집계할 수 있습니다. Monitoring 콘솔의 "그룹별" 드롭다운 목록에서 선택할 수 있습니다.
Cloud Monitoring 라벨과 Prometheus 측정항목 라벨에 대한 자세한 내용은 측정항목 모델 구성요소 및 Prometheus 데이터 모델을 참조하세요.
측정항목 라벨
다음 라벨은 구성 동기화 및 리소스 그룹 컨트롤러 측정항목에서 사용됩니다.
| 이름 | 값 | 설명 |
|---|---|---|
operation |
create, patch, update, delete | 수행된 작업 유형 |
status |
success, error | 작업 실행 상태 |
reconciler |
rootsync, reposync | 조정자 유형 |
source |
parser, differ, remediator | 내부 오류의 소스 |
trigger |
retry, watchUpdate, managementConflict, resync, reimport | 조정 이벤트 트리거 |
name |
조정자 이름 | 조정자 이름 |
component |
parsing, source, sync, rendering, readiness | 현재 조정 중인 구성요소/단계 이름 |
container |
reconciler, git-sync | 컨테이너 이름 |
resource |
cpu, memory | 리소스 유형 |
controller |
applier, remediator | 루트 또는 네임스페이스 조정자에 있는 컨트롤러의 이름 |
type |
모든 Kubernetes 리소스(예: ClusterRole, 네임스페이스, NetworkPolicy, 역할 등) | Kubernetes API의 종류 |
commit |
---- | 가장 최근에 동기화된 커밋의 해시 |
리소스 라벨
Prometheus 및 Cloud Monitoring에 전송된 구성 동기화 측정항목에는 소스 포드를 식별하도록 설정된 다음 측정항목 라벨이 있습니다.
| 이름 | 설명 |
|---|---|
k8s.node.name |
포드의 이름 |
k8s.pod.namespace |
포드의 네임스페이스 |
k8s.pod.uid |
포드의 UID |
k8s.pod.ip |
포드의 IP |
k8s.node.name |
포드를 호스팅하는 노드의 이름 |
k8s.deployment.name |
포드를 소유하는 배포 이름 |
reconciler 포드에서 Prometheus 및 Cloud Monitoring으로 전송되는 구성 동기화 측정항목에는 조정자를 구성하는 데 사용되는 RootSync 또는 RepoSync를 식별하도록 설정된 다음 측정항목 라벨도 있습니다.
| 이름 | 설명 |
|---|---|
configsync.sync.kind |
이 조정자를 구성하는 리소스 종류: RootSync 또는 RepoSync |
configsync.sync.name |
이 조정자를 구성하는 RootSync 또는 RepoSync의 이름 |
configsync.sync.namespace |
이 조정자를 구성하는 RootSync 또는 RepoSync의 네임스페이스 |
Cloud Monitoring 리소스 라벨
Cloud Monitoring 리소스 라벨은 스토리지에서 측정항목의 색인을 생성하기 위해 사용됩니다. 즉, 카디널리티가 중요한 성능 요인인 측정항목 라벨과 달리 카디널리티 효과가 무시 가능한 수준입니다. 자세한 내용은 모니터링 리소스 유형을 참조하세요.
구성 동기화 버전 1.14.0부터는 Cloud Monitoring으로 전송되는 리소스 그룹 컨트롤러 측정항목이 이전 버전에서 사용된 k8s_pod 대신 k8s_container 리소스 유형을 사용합니다.
구성 동기화 버전 1.14.1부터 Cloud Monitoring으로 전송된 구성 동기화 측정항목은 이전 버전에서 사용된 k8s_pod 대신 k8s_container 리소스 유형을 사용합니다.
k8s_container 리소스 유형은 소스 컨테이너를 식별하기 위해 다음 리소스 라벨을 설정합니다.
| 이름 | 설명 |
|---|---|
container_name |
컨테이너 이름 |
pod_name |
포드의 이름 |
namespace_name |
포드의 네임스페이스 |
location |
노드를 호스팅하는 클러스터의 리전 또는 영역 |
cluster_name |
노드를 호스팅하는 클러스터의 이름 |
project |
클러스터를 호스팅하는 프로젝트의 ID |
pipeline_error_observed 측정항목 이해
pipeline_error_observed 측정항목은 동기화되지 않았거나 원하는 상태로 조정되지 않은 리소스를 포함하는 RepoSync 또는 RootSync CR을 빠르게 식별할 수 있게 해주는 측정항목입니다.
RootSync 또는 RepoSync의 동기화 성공에 대해 모든 구성요소(
rendering,source,sync,readiness)를 포함하는 측정항목은 값 0으로 관측됩니다.
최신 커밋으로 자동 렌더링이 실패하면 구성요소가
rendering인 측정항목이 값 1로 관측됩니다.최신 커밋을 체크아웃할 때 오류가 발생하거나 최신 커밋에 잘못된 구성이 포함된 경우 구성요소
source가 포함된 측정항목이 값 1로 관측됩니다.어떤 리소스가 클러스터에 적용되지 않으면 구성요소
sync가 포함된 측정항목이 값 1로 관측됩니다.리소스가 적용되었지만 원하는 상태에 도달하지 못하면
readiness구성요소가 있는 측정항목이 값 1로 관측됩니다. 예를 들어 배포가 클러스터에 적용되지만 해당 포드가 성공적으로 생성되지 않습니다.
Cloud Monitoring으로 리소스 모니터링
구성 동기화가 기본 서비스 계정이 있는 Google Cloud 환경 내에서 실행되는 경우 구성 동기화가 측정항목을 Cloud Monitoring으로 자동으로 내보냅니다.
워크로드 아이덴티티가 사용 설정되어 있으면 다음 단계를 완료하세요.
네임스페이스
config-management-monitoring의 Kubernetes ServiceAccountdefault를 측정항목 작성자 역할이 있는 Google 서비스 계정에 바인딩합니다.gcloud iam service-accounts add-iam-policy-binding \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-monitoring/default]" \ GSA_NAME@PROJECT_ID.iam.gserviceaccount.com다음을 바꿉니다.
PROJECT_ID: 프로젝트 ID입니다.GSA_NAME: 모니터링 측정항목 작성자(roles/monitoring.metricWriter) IAM 역할이 있는 Google 서비스 계정입니다. 이 역할이 있는 서비스 계정이 없는 경우 하나 만들 수 있습니다.
이 작업에는 프로젝트에 대한
iam.serviceAccounts.setIamPolicy권한이 필요합니다.Google 서비스 계정의 이메일 주소를 사용하여 Kubernetes ServiceAccount에 주석을 추가하세요.
kubectl annotate serviceaccount \ --namespace config-management-monitoring \ default \ iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.comotel-collector포드를 다시 시작합니다.kubectl rollout restart deployment otel-collector -n config-management-monitoring
이러한 측정항목을 확인하는 방법에 대한 예시는 다음 디버깅 절차 예시 섹션 및 Cloud Monitoring의 OpenCensus 측정항목 문서를 참조하세요.
Cloud Monitoring 디버깅 절차 예시
다음 Cloud Monitoring 예시는 RootSync 및 RepoSync API를 사용할 때 구성 동기화와 관련된 문제를 검색하고 진단하기 위해 OpenCensus 측정항목을 사용하기 위한 몇 가지 패턴을 보여줍니다.
측정항목 형식
Cloud Monitoring에서 측정항목은 다음 형식을 갖습니다.
custom.googleapis.com/opencensus/config_sync/METRIC.
이 측정항목 이름은 다음 구성요소로 구성됩니다.
custom.googleapis.com: 모든 커스텀 측정항목에 이 프리픽스가 포함됩니다.opencensus: 이 프리픽스는 구성 동기화에 OpenCensus 라이브러리가 사용되기 때문에 추가됩니다.config_sync/: 구성 동기화가 Cloud Monitoring에 내보내는 측정항목에 이 프리픽스가 포함됩니다.METRIC: 쿼리하려는 측정항목의 이름입니다.
조정자로 측정항목 쿼리
RootSync 및 RepoSync 객체는 클러스터에서 구성 동기화의 작동 방법에 대한 유용한 정보를 제공하는 고급 측정항목으로 계측됩니다. 거의 모든 측정항목에 조정자 이름이 태그로 지정되므로, 오류가 발생했는지 확인하고 이에 대한 알림을 Cloud Monitoring에서 설정할 수 있습니다.
조정자는 배포로 배포되는 포드입니다. 정보 소스의 매니페스트를 클러스터에 동기화합니다. RootSync 객체를 만들면 구성 동기화는 RootSync 이름이 root-sync인 경우 root-reconciler-ROOT_SYNC_NAME 또는 root-reconciler라는 조정자를 만듭니다. RepoSync 객체를 만들 때 구성 동기화는 RepoSync 이름이 repo-sync인 경우 ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH 또는 ns-reconciler-NAMESPACE라는 조정자를 만듭니다. 여기서 NAMESPACE는 RepoSync 객체를 만든 네임스페이스입니다.
다음은 조정자 포드의 작동 방식을 보여주는 다이어그램입니다.
예를 들어 Cloud Monitoring을 사용할 때 조정자 이름으로 필터링하려면 다음 태스크를 완료합니다.
Google Cloud 콘솔에서 Monitoring으로 이동합니다.
Monitoring 탐색 창에서 leaderboard 측정항목 탐색기를 클릭합니다.
측정항목 선택 드롭다운 목록에서
custom.googleapis.com/opencensus/config_sync/reconciler_errors를 추가합니다.필터 드롭다운 목록에서 root_reconciler를 선택합니다. 필터 필드 상자가 나타납니다.
필터 필드 상자의 첫 번째 필드에서 =를, 두 번째 필드에서 조정자 이름(예:
root-reconciler)을 선택합니다.적용을 클릭합니다.
이제 RootSync 객체에 대한 측정항목을 확인할 수 있습니다.
특정 데이터 유형으로 필터링하는 방법에 대한 상세 설명은 데이터 필터링을 참조하세요.
구성요소 및 상태별 구성 동기화 작업 쿼리
RootSync 및 RepoSync API를 사용 설정한 경우 정보 소스에서 가져오기 및 소싱과 클러스터로의 동기화는 조정자에 의해 처리됩니다.
reconciler_errors 측정항목에 구성요소별로 라벨이 지정되므로 오류가 발생한 위치를 확인할 수 있습니다.
예를 들어 Cloud Monitoring을 사용할 때 구성요소로 필터링하려면 다음 태스크를 완료합니다.
Google Cloud 콘솔에서 Monitoring으로 이동합니다.
Monitoring 탐색 창에서 leaderboard 측정항목 탐색기를 클릭합니다.
측정항목 선택 드롭다운 목록에서
custom.googleapis.com/opencensus/config_sync/reconciler_errors를 추가합니다.필터 드롭다운 목록에서 구성요소를 선택합니다. 필터 필드 상자가 나타납니다.
필터 필드 상자의 첫 번째 필드에서 =을 선택하고 두 번째 필드에서 source를 선택합니다.
적용을 클릭합니다.
이제 조정자에 대해 정보 소스에서 소싱할 때 발생한 오류를 확인할 수 있습니다.
다음 측정항목을 쿼리하고 status 태그로 필터링하여 소스 및 동기화 프로세스 자체에 대해 측정항목을 확인할 수도 있습니다.
custom.googleapis.com/opencensus/config_sync/parser_duration_seconds
custom.googleapis.com/opencensus/config_sync/apply_duration_seconds
custom.googleapis.com/opencensus/config_sync/remediate_duration_seconds
커스텀 OpenTelemetry 내보내기 구성
측정항목을 다른 모니터링 시스템으로 전송하려면 OpenTelemetry 구성을 수정할 수 있습니다. 지원되는 모니터링 시스템 목록은 OpenTelemetry Collector 내보내기 도구 및 OpenTelemetry Collector-Contrib 내보내기 도구를 참조하세요.
OpenTelemetry 모니터링 리소스는 별도의 config-management-monitoring 네임스페이스에서 관리됩니다. 구성 동기화에 사용하도록 커스텀 OpenTelemetry를 구성하려면 해당 config-management-monitoring 네임스페이스에서 otel-collector-custom 이름으로 ConfigMap을 만들어야 합니다.
ConfigMap은 otel-collector-config.yaml 키를 포함해야 하고, 값은 커스텀 OpenTelemetry Collector 구성의 파일 콘텐츠여야 합니다.
구성 옵션에 대한 상세 설명은 OpenTelemetry Collector 구성 문서를 참조하세요.
다음 ConfigMap은 커스텀 로깅 내보내기 도구를 사용한 ConfigMap 예시입니다.
# otel-collector-custom-cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: otel-collector-custom
namespace: config-management-monitoring
labels:
app: opentelemetry
component: otel-collector
data:
otel-collector-config.yaml: |
receivers:
opencensus:
exporters:
logging:
logLevel: debug
processors:
batch:
extensions:
health_check:
service:
extensions: [health_check]
pipelines:
metrics:
receivers: [opencensus]
processors: [batch]
exporters: [logging]
모든 커스텀 구성은 opencensus 수신기 및 metrics 파이프라인을 정의해야 합니다. 나머지 필드는 선택적이고 구성 가능하지만, 예시와 같이 batch 프로세서 및 상태 확인 확장 프로그램을 포함하는 것이 좋습니다.
ConfigMap을 만든 후 kubectl을 사용하여 리소스를 만듭니다.
kubectl apply -f otel-collector-custom-cm.yaml
OpenTelemetry Collector 배포는 이 ConfigMap을 선택하고 자동으로 재시작되어 커스텀 구성을 적용합니다.
Prometheus로 리소스 모니터링
구성 동기화는 Prometheus를 사용하여 프로세스와 관련된 측정항목을 수집하고 표시합니다.
Prometheus에서 커스텀 측정항목을 가져오도록 Cloud Monitoring을 구성할 수도 있습니다. 그러면 Prometheus와 Monitoring 모두에서 커스텀 측정항목을 확인할 수 있습니다. 자세한 내용은 Prometheus 사용을 참조하세요.
측정항목 스크래핑
모든 Prometheus 측정항목을 포트 8675에서 스크랩할 수 있습니다. 측정항목을 스크랩하기 전에 다음 두 가지 방법 중 하나로 Prometheus용 클러스터를 구성해야 합니다.
Prometheus 문서를 따라 스크랩용 클러스터를 구성합니다. 또는
Prometheus Operator를 다음 매니페스트와 함께 사용합니다. 그러면 모든 Anthos Config Management 측정항목이 10초마다 스크랩됩니다.
매니페스트 파일을 저장할 임시 디렉터리를 만듭니다.
mkdir acm-monitor cd acm-monitor
curl명령어를 사용하여 CoreOS 저장소에서 Prometheus Operator 매니페스트를 다운로드합니다.curl -o bundle.yaml https://raw.githubusercontent.com/coreos/prometheus-operator/master/bundle.yaml
이 매니페스트는 권장되지 않는
default네임스페이스를 사용하도록 구성됩니다. 다음 단계에서는 대신monitoring네임스페이스를 사용하도록 구성을 수정합니다. 다른 네임스페이스를 사용하려면 네임스페이스를 나머지 단계에서 표시되는monitoring으로 대체합니다.파일을 만들어 위 번들에 있는 ClusterRoleBinding의 네임스페이스를 업데이트합니다.
# patch-crb.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: prometheus-operator subjects: - kind: ServiceAccount name: prometheus-operator namespace: monitoring # we are patching from default namespace패치를 적용하고 매니페스트에서 다른 리소스의 네임스페이스를 수정하는
kustomization.yaml파일을 만듭니다.# kustomization.yaml resources: - bundle.yaml namespace: monitoring patchesStrategicMerge: - patch-crb.yamlmonitoring네임스페이스가 없으면 만듭니다. 네임스페이스에 다른 이름을 사용할 수 있지만 이 경우 이전 단계의 YAML 매니페스트에서namespace값도 변경합니다.kubectl create namespace monitoring
다음 명령어를 사용하여 Kustomize 매니페스트를 적용합니다.
kubectl apply -k . until kubectl get customresourcedefinitions servicemonitors.monitoring.coreos.com ; \ do date; sleep 1; echo ""; done
두 번째 명령어는 클러스터에서 CRD를 사용할 수 있을 때까지 차단됩니다.
Anthos Config Management에서 측정항목을 스크랩하는 Prometheus 서버를 구성하는 데 필요한 리소스의 매니페스트를 만듭니다.
# acm.yaml apiVersion: v1 kind: ServiceAccount metadata: name: prometheus-acm namespace: monitoring --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: prometheus-acm rules: - apiGroups: [""] resources: - nodes - services - endpoints - pods verbs: ["get", "list", "watch"] - apiGroups: [""] resources: - configmaps verbs: ["get"] - nonResourceURLs: ["/metrics"] verbs: ["get"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: prometheus-acm roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: prometheus-acm subjects: - kind: ServiceAccount name: prometheus-acm namespace: monitoring --- apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: acm namespace: monitoring labels: prometheus: acm spec: replicas: 2 serviceAccountName: prometheus-acm serviceMonitorSelector: matchLabels: prometheus: config-management podMonitorSelector: matchLabels: prometheus: config-management alerting: alertmanagers: - namespace: default name: alertmanager port: web resources: requests: memory: 400Mi --- apiVersion: v1 kind: Service metadata: name: prometheus-acm namespace: monitoring labels: prometheus: acm spec: type: NodePort ports: - name: web nodePort: 31900 port: 9190 protocol: TCP targetPort: web selector: prometheus: acm --- apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: acm-service namespace: monitoring labels: prometheus: config-management spec: selector: matchLabels: monitored: "true" namespaceSelector: matchNames: # If you are using RootSync and RepoSync APIs, change # config-management-system to config-management-monitoring - config-management-system endpoints: - port: metrics interval: 10s ---다음 명령어를 사용하여 매니페스트를 적용합니다.
kubectl apply -f acm.yaml until kubectl rollout status statefulset/prometheus-acm -n monitoring; \ do sleep 1; done
두 번째 명령어는 포드가 실행될 때까지 차단됩니다.
Prometheus 서버의 웹 포트를 로컬 머신에 전달하여 설치를 확인할 수 있습니다.
kubectl -n monitoring port-forward svc/prometheus-acm 9190
이제
http://localhost:9190에서 Prometheus 웹 UI에 액세스할 수 있습니다.임시 디렉터리를 삭제합니다.
cd .. rm -rf acm-monitor
사용 가능한 Prometheus 측정항목
구성 동기화는 다음과 같은 측정항목을 수집하여 Prometheus에 제공합니다. 라벨 열에는 각 측정항목에 적용 가능한 모든 라벨이 표시됩니다. 라벨이 없는 측정항목은 시간이 지남에 따라 단일 측정을 나타내는 반면 라벨이 있는 측정항목은 라벨 값의 각 조합에 대해 하나씩 여러 측정을 나타냅니다.
이 테이블이 동기화되지 않으면 Prometheus 사용자 인터페이스의 프리픽스로 측정항목을 필터링할 수 있으며 모든 해당 측정항목은 gkeconfig_ 프리픽스로 시작합니다.
| 이름 | 유형 | 라벨 | 설명 |
|---|---|---|---|
gkeconfig_importer_cycle_duration_seconds_bucket |
히스토그램 | status | 임포터가 구성을 클러스터로 가져 오려고 시도한 주기 수(각 주기 동안 버킷으로 분배) |
gkeconfig_importer_cycle_duration_seconds_count |
히스토그램 | status | 임포터가 구성을 클러스터로 가져 오려고 시도한 주기 수(지속 시간 무시) |
gkeconfig_importer_cycle_duration_seconds_sum |
히스토그램 | status | 임포터가 구성을 클러스터로 가져 오려고 시도한 모든 주기 지속 시간의 합계 |
gkeconfig_importer_namespace_configs |
게이지 | 현재 상태의 네임스페이스 구성 수 | |
gkeconfig_monitor_errors |
게이지 | component | 구성 저장소에서 오류가 발생한 구성 요소별로 그룹화된 오류 수 |
gkeconfig_monitor_configs |
게이지 | state | 동기화 상태별로 그룹화된 구성(클러스터 및 네임스페이스) 수 |
gkeconfig_monitor_last_import_timestamp |
게이지 | 최근 가져오기의 타임스탬프입니다. | |
gkeconfig_monitor_last_sync_timestamp |
게이지 | 최근 동기화의 타임스탬프입니다. | |
gkeconfig_monitor_sync_latency_seconds_bucket |
히스토그램 | 가져온 동기화로 가져오기 측정 수(두 항목 사이의 대기 시간에 따라 버킷에 분산됨) | |
gkeconfig_monitor_sync_latency_seconds_count |
히스토그램 | 가져온 동기화로 가져오기 측정 수(둘 사이의 지연 시간 무시) | |
gkeconfig_monitor_sync_latency_seconds_sum |
히스토그램 | 가져온 모든 가져오기 동기 측정의 지연 시간 합계 | |
gkeconfig_syncer_api_duration_seconds_bucket |
히스토그램 | operation, type, status | 동기화 프로그램이 API 서버에 대해 수행한 호출 수(각 호출 기간에 따라 버킷으로 분배) |
gkeconfig_syncer_api_duration_seconds_count |
히스토그램 | operation, type, status | 임포터가 API 서버에 호출한 횟수(지속 시간 무시) |
gkeconfig_syncer_api_duration_seconds_sum |
히스토그램 | operation, type, status | 동기화 프로그램이 API 서버에 대해 수행한 모든 호출 지속 시간의 합계 |
gkeconfig_syncer_controller_restarts_total |
카운터 | source | 네임스페이스 및 클러스터 구성 컨트롤러에 대한 총 재시작 횟수 |
gkeconfig_syncer_operations_total |
카운터 | operation, type, status | 리소스를 구성에 동기화하기 위해 수행된 총 작업 수 |
gkeconfig_syncer_reconcile_duration_seconds_bucket |
히스토그램 | type, status | 동기화 프로그램에서 처리한 조정 이벤트 수(기간별로 버킷으로 분배) |
gkeconfig_syncer_reconcile_duration_seconds_count |
히스토그램 | type, status | 동기화 프로그램에서 처리한 조정 이벤트 수(지속 시간 무시) |
gkeconfig_syncer_reconcile_duration_seconds_sum |
히스토그램 | type, status | 동기화 프로그램에서 처리한 모든 조정 이벤트 기간의 합계 |
gkeconfig_syncer_reconcile_event_timestamps |
게이지 | 유형 | 동기화 조정 이벤트가 발생했을 때의 타임스탬프 |
Prometheus 디버깅 절차 예시
다음 예시는 Prometheus 측정항목, 객체 상태 필드, 객체 주석을 사용하여 구성 동기화와 관련된 문제를 감지하고 진단하는 몇 가지 패턴을 보여줍니다. 이러한 예시는 문제를 발견한 상위 수준 모니터링에서 시작한 다음 점진적으로 상세 검색을 통해 문제의 근본 원인을 파악하는 방법을 보여줍니다.
상태별 구성 쿼리
monitor 프로세스는 클러스터에서 구성 동기화가 작동하는 방식에 대한 전반적인 정보를 제공하는 높은 수준의 측정항목을 제공합니다. 오류가 발생했는지 여부를 알 수 있으며 경고를 설정할 수도 있습니다.
gkeconfig_monitor_errors
조정자로 측정항목 쿼리
구성 동기화 RootSync 및 RepoSync API를 사용하는 경우 RootSync 및 RepoSync 객체를 모니터링할 수 있습니다. RootSync 및 RepoSync 객체는 구성 동기화가 클러스터에서 작동하는 방식에 대한 유용한 정보를 제공하는 상위 수준 측정항목으로 계측됩니다. 거의 모든 측정항목에 조정자 이름이 태그로 지정되므로 오류가 발생했는지 확인하고 이에 대한 알림을 Prometheus에서 설정할 수 있습니다.
조정자는 정보 소스의 매니페스트를 클러스터에 동기화하는 포드입니다.
RootSync 객체를 만들 때 구성 동기화는 root-reconciler라는 조정자를 만듭니다. RepoSync 객체를 만들 때 구성 동기화는 ns-reconciler-NAMESPACE라는 조정자를 만듭니다. 여기서 NAMESPACE는 RepoSync 객체를 만든 네임스페이스입니다.
Prometheus에서 조정자에 다음 필터를 사용할 수 있습니다.
# Querying Root reconciler
config_sync_reconciler_errors{root_reconciler="root-reconciler"}
# Querying Namespace reconciler for a namespace called retail
config_sync_reconciler_errors{ns_reconciler_retail="ns-reconciler-retail"}
nomos status를 사용하여 오류 표시
Prometheus 측정항목을 사용하여 클러스터의 구성 동기화 상태를 모니터링하는 것 외에 명령줄에서 모든 클러스터의 오류를 출력하는 nomos status 명령어를 사용할 수도 있습니다.
상태별 가져오기 및 동기화 작업 쿼리
구성 동기화는 2단계 프로세스를 사용하여 저장소의 구성을 클러스터에 적용합니다. gkeconfig_monitor_errors 측정항목에 구성요소별로 라벨이 지정되므로 오류가 발생한 위치를 확인할 수 있습니다.
gkeconfig_monitor_errors{component="importer"}
gkeconfig_monitor_errors{component="syncer"}
또한 importer 및 syncer 프로세스 자체의 측정항목을 확인할 수도 있습니다.
gkeconfig_importer_cycle_duration_seconds_count{status="error"}
gkeconfig_syncer_reconcile_duration_seconds_count{status="error"}
RootSync 및 RepoSync API를 사용 설정한 경우 Git 저장소에서 가져오기 및 소싱과 클러스터로의 동기화는 조정자에 의해 처리됩니다. reconciler_errors 측정항목에 구성요소별로 라벨이 지정되므로 오류가 발생한 위치를 확인할 수 있습니다.
Prometheus에서 다음 쿼리를 사용할 수 있습니다.
# Check for errors that occurred when sourcing configs.
config_sync_reconciler_errors{component="source"}
# Check for errors that occurred when syncing configs to the cluster.
config_sync_reconciler_errors{component="sync"}
소스 및 동기화 프로세스 자체의 측정항목도 확인할 수 있습니다.
config_sync_parse_duration_seconds{status="error"}
config_sync_apply_duration_seconds{status="error"}
config_sync_remediate_duration_seconds{status="error"}
구성 객체 상태 확인
구성 동기화는 ClusterConfig와 NamespaceConfig, 두 가지 커스텀 Kubernetes 객체를 정의합니다. 이러한 객체는 구성에 마지막으로 적용된 변경과 발생한 오류에 대한 정보가 포함된 상태 필드를 정의합니다. 예를 들어 shipping-dev 네임스페이스에 오류가 있으면 해당 NamespaceConfig의 상태를 확인할 수 있습니다.
kubectl get namespaceconfig shipping-dev -o yaml
객체의 token 주석 확인
구성 동기화를 통해 관리형 Kubernetes 객체가 마지막으로 업데이트된 시기를 알고자 할 수 있습니다. 각 관리형 객체에는 최종 수정 시 Git 커밋의 해시와 수정 사항이 포함된 구성의 경로가 주석으로 지정됩니다.
kubectl get clusterrolebinding namespace-readers
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
annotations:
configmanagement.gke.io/source-path: cluster/namespace-reader-clusterrolebinding.yaml
configmanagement.gke.io/token: bbb6a1e2f3db692b17201da028daff0d38797771
name: namespace-readers
...
자세한 내용은 라벨 및 주석을 참조하세요.
Google Cloud Managed Service for Prometheus로 리소스 모니터링
Google Cloud Managed Service for Prometheus는 Prometheus 측정항목을 위한 Google Cloud의 완전 관리형 멀티 클라우드 솔루션입니다. 관리형 데이터 수집(권장 모드) 또는 자체 배포형 데이터 수집의 두 가지 데이터 컬렉션 모드를 지원합니다. 관리형 데이터 수집 모드에서 Google Cloud Managed Service for Prometheus로 구성 동기화 모니터링을 설정하려면 다음 단계를 수행합니다.
관리형 수집 설정의 안내에 따라 클러스터에서 관리형 Prometheus를 사용 설정합니다.
다음 샘플 매니페스트를
cluster-pod-monitoring-acm-monitoring.yaml로 저장합니다. 이 매니페스트는config-management-monitoring네임스페이스 아래에서otel-collector-*포드의 포트8675에 구성 동기화 측정항목을 스크래핑하도록 ClusterPodMonitoring 리소스를 구성합니다. ClusterPodMonitoring 리소스는 Kubernetes 라벨 선택기를 사용하여otel-collector-*포드를 찾습니다.apiVersion: monitoring.googleapis.com/v1 kind: ClusterPodMonitoring metadata: name: acm-monitoring spec: selector: matchLabels: app: opentelemetry component: otel-collector endpoints: - port: 8675 interval: 10s클러스터에 매니페스트를 적용합니다.
kubectl apply -f cluster-pod-monitoring-acm-monitoring.yaml
Cloud Monitoring의 Managed Service for Prometheus 데이터의 안내에 따라 Google Cloud 콘솔에서 Cloud Monitoring 측정항목 탐색기 페이지를 사용하여 Prometheus 데이터가 노출되는지 확인합니다.
다음 단계
- RootSync 및 RepoSync 객체를 모니터링하는 방법 자세히 알아보기
- 구성 동기화 SLI 사용 방법 알아보기