プラットフォームは自分自身を何で測るのか

한 줄 요약

플랫폼 팀이 재야 할 것은 노드의 CPU 가 아니라 플랫폼이 사용자에게 한 약속입니다. 셀프서비스 요청이 성공하는 비율, 배포가 끝나기까지 걸리는 시간, 되돌려야 했던 배포의 비율이 그 약속입니다.

왜 자원 지표로는 모자라나

노드 지표만 보는 대시보드는 사고가 나도 초록불입니다. 셀프서비스 발급이 전부 실패해도 노드의 CPU 는 오히려 한가하기 때문입니다. 반대로 노드가 바빠도 사용자 입장에서는 아무 문제가 없을 수 있습니다.

그래서 플랫폼도 하나의 서비스로 놓고 봅니다. 사용자는 개발팀이고, 요청은 청구 생성이나 배포이며, 성공과 실패가 있고 소요 시간이 있습니다. 이렇게 놓으면 잴 것이 분명해집니다.

무엇을 재는가	왜 그것인가
발급 요청의 성공 비율	셀프서비스가 실제로 셀프서비스인지
요청부터 사용 가능까지의 시간	골든 패스가 실제로 빠른지
배포 빈도와 되돌린 비율	배포가 두려운 일인지 아닌지
사고 복구까지 걸린 시간	문제를 아는 데 걸리는 시간과 고치는 데 걸리는 시간

어떻게 동작하나

기록 규칙이 먼저이고 알림이 그다음입니다

비율을 알림 조건 안에서 매번 계산하면 같은 식이 여러 알림에 흩어집니다. 한 곳을 고치고 다른 곳을 잊는 사고가 여기서 납니다. 그래서 비율은 기록 규칙으로 한 번 정의하고, 알림은 그 이름을 참조합니다.

groups:
  - name: platform-slo
    rules:
      - record: platform:provision_success:ratio5m
        expr: |
          sum(rate(platform_provision_total{result="success"}[5m]))
          /
          sum(rate(platform_provision_total[5m]))

이름에 5m 이 들어 있으면 식의 구간도 5분이어야 합니다. 이름과 내용이 어긋나면 그 지표를 쓰는 모든 사람이 틀린 전제로 판단하게 됩니다.

발화 지연은 목적에 맞게 정합니다

for는 조건이 유지되는 시간을 요구합니다. 이 실습은 10분을 쓰지만 즉시 대응해야 하는 사건에는 생략할 수도 있습니다. 이 시간은 Alertmanager의 전송·반복 간격과 다릅니다. 알림 식은 거짓일 때 계열을 제거해야 합니다. vector(0)이나 비율 < bool 0.95는 값이 0이어도 계열이 남아 알림이 활성화되는 함정입니다. 공식 알림 규칙 설명에서 pending과 firing을 구별해 읽으세요.

runbook_url 이 없는 알림도 마찬가지입니다. 새벽 세 시에 받은 알림에 다음 행동이 적혀 있지 않으면 그것은 정보가 아니라 소음입니다. severity 라벨은 라우팅이 갈리는 기준이라, 없으면 모든 알림이 같은 경로로 갑니다.

검증한 것과 배포한 것이 같아야 합니다

규칙 파일은 promtool check rules 로 검증할 수 있습니다. 사람이 읽어서는 표현식의 괄호 하나를 못 잡습니다. 다만 검증한 파일과 클러스터에 올라간 PrometheusRule 이 다른 물건이면 그 검증은 아무것도 보장하지 않습니다. 파일에서 CR을 만들고, 올린 뒤 spec.groups 전체를 대조합니다. 이름만 같고 식이 바뀌었다면 다른 규칙입니다. API가 저장했다고 Operator가 선택했거나 Prometheus가 로드했다고 단정하지 않습니다. 이번 환경은 Operator를 실행하지 않으므로 저장 일치까지 검증하며 알림 전달을 시험했다고 주장하지 않습니다.

현장에서 만나는 모습

가상 사례를 생각해 봅시다. 실패 경로가 지표를 남기지 않는 발급 서비스를 만들었다면 대시보드에는 성공률 100%만 보일 수 있습니다. 분모가 성공만 세고 있으면 비율은 언제나 1 입니다.

비율 하나만으로는 이런 계측 누락을 구별하기 어렵습니다. 무엇을 세고 있는지를 식에서 직접 읽어야 보입니다. 그래서 새 지표를 만들 때는 실패를 일부러 한 번 내 보고 그 값이 움직이는지 확인해야 합니다. 알림도 마찬가지입니다.

문법 뒤에는 사건을 넣습니다

위의 단순 비율은 두 결과 계열이 모두 존재하는 경우의 출발점입니다. 실패 계열만 있으면 분자가 비고, 트래픽이 없으면 분모가 0이 됩니다. 이어질 실습에서는 실패만 있을 때 분자를 0으로 보충하되 전체 rate가 양수일 때만 비율을 남깁니다. 관측 공백은 성공 100%가 아니라 별도의 계측 이상으로 조사해야 합니다. 인스턴스별 성공률을 단순 평균하면 요청 1건인 서버와 1만 건인 서버를 같은 무게로 세는 오류가 생깁니다.

rate 공식 설명에 따라 카운터별 rate를 먼저 계산하고 합칩니다. 합계를 먼저 만든 뒤 rate를 계산하면 한 계열의 재시작이 다른 계열의 증가와 섞여 리셋 해석이 달라집니다. 실습은 성공 카운터만 재시작하는 사건을 리셋 구간 안에서도 검사합니다.

이 과정에서 사용할 13개 사건은 정상 99%, 지속 실패 80%, 경계 95%와 양옆, 3분 장애, 장애 후 회복, 무트래픽, 관측 없음, 성공만 있음, 실패만 있음, 카운터 리셋, 요청량이 다른 두 인스턴스입니다. 회복 17분의 성공률과 19분의 해제도 확인하여 5분 구간을 10분으로 바꾸는 오류를 구별합니다. 이는 학습용 고정 데이터 시험이며 모든 운영 트래픽에 대한 증명은 아닙니다.

promtool check rules는 문법을, promtool test rules는 가상 시계열에서의 값을 검사합니다. 공식 시험 형식의 input_series와 eval_time을 읽고 실제 대기 시간과 구별하세요. 이미지의 3.0.1은 최신 문서의 fuzzy_compare를 지원하지 않아, 도우미는 비율 오차를 1e-9 미만으로 직접 검사합니다.

그다음 읽을 것

지표가 이상을 알려 준 다음, 그 이상을 무엇부터 세어 분류할지를 이어서 봅니다.