모니터링

돌아가는 시스템이 내보내는 수치를 실시간으로 모아 사람이 볼 수 있게 하는 일입니다. 시스템이 지금 어떤 상태인지를 숫자로 남깁니다. 재서 화면에 띄우는 데까지가 이 일입니다.

상세

매일 아침 체중계에 올라가는 사람을 떠올려 봅니다. 잰 숫자를 휴대폰에 옮기면 지난 점들과 이어진 선이 하나 그려집니다. 저녁을 줄일지는 그 선을 본 사람이 정합니다.

Google SRE(Site Reliability Engineering, 사이트 신뢰성 엔지니어링) Book 은 모니터링과 얽힌 주제 전반에 두루 통하는 용어가 없다고 먼저 적습니다. 구글 안에서도 쓰임이 갈린다고 덧붙입니다. 그리고 가장 흔한 해석을 적어 둡니다. 그 해석은 이렇습니다. 시스템에 대한 실시간 정량 데이터를 수집하고 처리하고 집계해서 표시하는 일입니다. 질의 수와 종류, 오류 수와 종류, 처리 시간, 서버 수명 같은 것이 여기서 말하는 데이터입니다.

동작이 넷이라는 점이 이 정의의 뼈대입니다. 수집·처리·집계·표시입니다.

재는 자리는 둘로 갈립니다. 화이트박스 모니터링은 시스템 내부가 밖으로 내놓은 지표에 기댑니다. 같은 문서는 로그나 내부 통계를 내보내는 HTTP(HyperText Transfer Protocol, 하이퍼텍스트 전송 규약) 핸들러 같은 것을 그 지표의 예로 듭니다. 블랙박스 모니터링은 반대쪽입니다. 사용자가 보는 대로 밖으로 드러난 동작을 시험합니다.

화이트박스 쪽 지표는 시스템이 알아서 내주는 것이 아닙니다. 무엇을 재서 내보낼지는 만드는 쪽이 골라 코드에 심어야 합니다.

모은 값이 가 닿는 자리에도 이름이 붙어 있습니다. 대시보드는 서비스의 핵심 지표를 요약해 보여주는 응용 프로그램입니다. 대개 웹 기반이라고 적혀 있습니다. 경보는 사람이 읽으라고 보내는 알림입니다. 버그나 티켓 큐, 이메일 별칭, 호출기 같은 곳으로 밀어 보냅니다.

flowchart TD
    A[시스템] --> B[수집]
    B --> C[처리]
    C --> D[집계]
    D --> E[표시]

배경

망을 이루는 장비가 늘어나면 사람이 하나씩 붙어 상태를 확인할 수 없습니다. 호스트, 게이트웨이, 터미널 서버 같은 것들이 여기저기 흩어져 있습니다. 떨어진 자리에서 그 장비의 관리 정보를 들여다볼 방법이 필요했습니다. RFC(Request for Comments) 1157 은 망 요소의 관리 정보를 논리적으로 떨어진 사용자가 들여다보거나 바꿀 수 있게 하는 규약을 정의한다고 적습니다. 이 구조에는 망 관리 스테이션과 망 요소가 함께 있습니다. 관리 스테이션은 망 요소를 감시하고 제어하는 관리 응용을 돌립니다. 망 요소에는 관리 에이전트가 있어서 관리 스테이션이 요청한 관리 기능을 수행합니다. 감시하는 쪽과 감시받는 쪽이 이렇게 갈립니다. 관리 스테이션과 망 요소의 에이전트 사이에서 관리 정보를 주고받는 데 쓰는 것이 SNMP(Simple Network Management Protocol, 간이 망 관리 규약)입니다. 이 문서가 관리 스테이션이 하는 그 일을 가리켜 쓰는 말이 monitor 입니다.

예시

프로메테우스의 메트릭 표기

프로메테우스는 SoundCloud 에서 처음 만들어진 오픈소스 시스템 모니터링·경보 도구 모음입니다. 메트릭을 시계열 데이터로 모아 저장합니다. 기록된 시각을 함께 담습니다. 레이블이라 부르는 선택적인 키-값 쌍을 옆에 붙입니다.

시계열 하나는 메트릭 이름과 레이블 집합으로 이렇게 적습니다.

<metric name>{<label name>="<label value>", ...}

메트릭 이름이 api_http_requests_total 이고 레이블이 method="POST" 와 handler="/messages" 인 시계열은 이렇게 됩니다.

api_http_requests_total{method="POST", handler="/messages"}

메트릭 이름도 안에서는 레이블 쌍으로 다룹니다. __name__="<metric name>" 이라는 특별한 레이블 이름이 그 자리입니다.

모으는 방식도 정해져 있습니다. 시계열 수집은 HTTP 위의 풀 모델로 일어납니다. 밀어 넣는 방식은 중간 게이트웨이를 거쳐 지원합니다. 대상은 서비스 디스커버리나 정적 설정으로 찾습니다. 쌓인 시계열은 프로메테우스가 가진 질의 언어 PromQL 로 묻습니다. 여러 차원을 살리라고 만든 유연한 언어라고 적혀 있습니다.

쿠버네티스의 리소스 메트릭 파이프라인

쿠버네티스 공식 문서는 응용 모니터링이 한 가지 해법에 매이지 않는다고 적습니다. 새 클러스터에서는 리소스 메트릭이나 전체 메트릭 파이프라인으로 통계를 모을 수 있습니다.

리소스 메트릭 파이프라인이 내주는 지표는 범위가 정해져 있습니다. 수평 파드 오토스케일러 컨트롤러 같은 클러스터 구성요소와 kubectl top 유틸리티에 얽힌 지표입니다. 이 지표는 메모리 안에만 두는 단기 수집기인 metrics-server 가 모읍니다. metrics-server 는 클러스터의 모든 노드를 찾아냅니다. 그리고 각 노드의 kubelet 에게 CPU(Central Processing Unit, 중앙처리장치)와 메모리 사용량을 물어봅니다. kubelet 은 쿠버네티스 마스터와 노드 사이의 다리 노릇을 합니다. 그 기계에서 도는 파드와 컨테이너를 관리합니다. 통계가 어느 경로로 도착하든, kubelet 은 모아 놓은 파드 리소스 사용량 통계를 metrics-server 의 리소스 메트릭 API(Application Programming Interface, 응용 프로그램 인터페이스)를 통해 내놓습니다. 밖에서는 metrics.k8s.io API 로 노출됩니다.

flowchart TD
    A[kubelet] -->|CPU·메모리 사용량| B[metrics-server]
    B -->|metrics.k8s.io| C[kubectl top]
    B -->|metrics.k8s.io| D[수평 파드 오토스케일러]

전체 메트릭 파이프라인은 더 풍부한 지표를 내줍니다. 쿠버네티스는 그 지표를 받아 수평 파드 오토스케일러 같은 장치로 지금 상태에 맞춰 클러스터를 자동으로 늘리거나 맞춥니다.

경계

로그를 전부 쌓아 두면 그것이 모니터링인가. 아닙니다.

Google SRE Book 의 정의는 네 동작을 함께 요구합니다. 수집하고 처리하고 집계해서 표시하는 것입니다. 쌓아 두기만 한 것은 첫 동작에서 멈춘 것입니다. 로그 자체는 재료로 인정됩니다. 같은 문서가 화이트박스 모니터링의 근거가 되는 지표에 로그를 명시합니다. 재료가 쌓여 있다는 것과 그 재료로 지금 재고 있다는 것은 다릅니다. 정의에는 실시간 정량 데이터라는 한정도 붙어 있습니다.

같은 선이 이웃 둘도 밖에 둡니다. 경보는 같은 문서가 사람이 읽으라고 보내는 알림으로 따로 정의합니다. 관측성은 OpenTelemetry 공식 문서가 시스템의 출력을 살펴 내부 상태를 이해하는 능력이라고 적습니다. 한쪽은 하는 일이고 한쪽은 성질입니다. 재서 보여주는 데까지가 이 표제어이고, 그 값을 보고 사람을 부르는 것과 그렇게 나온 것으로 안을 얼마나 알아낼 수 있는가는 그 위에 얹힌 다른 이름입니다.

상세

배경

예시

프로메테우스의 메트릭 표기

쿠버네티스의 리소스 메트릭 파이프라인

경계

관련 항목

재서 내보내는 데이터의 종류

데이터를 모으는 방식

값을 묻고 내주는 인터페이스

값을 알리는 통로

실제로 구현·채택한 제품

걸쳐 도는 쿠버네티스 구성 요소

경계를 가르는 이웃 개념