관측성

밖으로 나온 것만 보고 안을 얼마나 알아낼 수 있는가 하는 성질입니다. 시스템을 열어 보는 대신 시스템이 내보낸 것을 읽습니다. 있다와 없다가 아니라 높다와 낮다로 갈립니다.

상세

지난달에 쓴 돈은 가계부에 적어 둔 만큼만 남아 있습니다. 날짜와 금액만 적어 둔 달치로는 커피에 얼마를 썼는지 아무리 들여다봐도 나오지 않습니다. 답이 막히는 물음이 늘면 다음 달부터 적는 칸을 늘리는 수밖에 없습니다.

관측성은 밖으로 나온 출력만 보고 안의 상태를 얼마나 알아낼 수 있는가 하는 성질입니다. 안을 직접 들여다보는 것이 아닙니다. 남은 것을 보고 안을 되짚는 것입니다. 그래서 밖으로 나온 것에 없는 사실은 어떤 도구로도 되짚을 수 없습니다.

있다와 없다의 문제가 아니라 높다와 낮다의 문제입니다. 같은 시스템이라도 어떤 물음에는 답이 나오고 어떤 물음에는 안 나옵니다.

정도를 재는 자는 물음의 범위입니다. 코드를 새로 넣지 않고 지금 남은 것만으로 답할 수 있는 물음이 많을수록 관측성이 높습니다. 답을 얻으려고 코드를 고쳐 다시 배포해야 한다면 그 물음에 대해서는 관측성이 낮습니다. 무엇을 밖으로 내보낼지는 코드를 쓰는 자리에서 정해집니다. 관측성은 운영하는 쪽만의 일이 아닙니다.

배경

운영하는 쪽은 무엇이 고장 날지를 먼저 골라 그 수치를 재 왔습니다. 고르는 일이 먼저이므로 골라 두지 않은 것은 볼 수 없습니다. 이미 겪어 본 고장은 이 방식으로 잡힙니다. 처음 보는 고장은 대개 재 두지 않은 자리에서 납니다. 그럴 때 남은 것은 지표가 아니라 짐작뿐입니다.

그래서 요구가 뒤집힙니다. 물음을 먼저 정한 뒤 그 답만 남기는 것이 아닙니다. 나중에 어떤 물음이 와도 답을 꺼낼 수 있을 만큼 밖으로 내보내 두어야 합니다. 무엇을 남길지를 고장이 나기 전에 정해야 한다는 점은 그대로입니다. 다만 고르는 기준이 지표에서 물음의 범위로 옮겨 갑니다.

이름은 제어이론에서 빌려온 말입니다. 제어이론은 밖으로 나온 출력만으로 시스템 안의 상태를 결정할 수 있는가를 그 이름으로 다뤄 왔습니다. 제어이론에서 이 개념을 세운 R. E. Kálmán 은 이 문제를 따로 떼어 형식화한 첫 시도가 1959년에 와서야 이루어진 것으로 보인다고 적습니다. 소프트웨어는 그 뜻을 그대로 가져와 시스템이 내보내는 데이터에 붙였습니다.

경계

대시보드를 100장 만들면 관측성이 높은 것인가. 아닙니다.

Google SRE(Site Reliability Engineering, 사이트 신뢰성 엔지니어링) Book 은 모니터링을 시스템에 대한 실시간 정량 데이터의 수집·처리·집계·표시라고 적습니다. 질의 수와 종류, 오류 수와 종류, 처리 시간, 서버 수명 같은 것입니다. 같은 문서는 사용자 대면 시스템에서 네 가지 지표만 잴 수 있다면 지연·트래픽·오류·포화 넷에 집중하라고 적습니다. 무엇을 잴지를 먼저 고르는 자리입니다.

대시보드 한 장은 미리 던져 둔 물음 하나입니다. 100장을 만들면 미리 던져 둔 물음이 100개가 됩니다. 그 100개 밖의 물음이 오면 화면 수는 답을 주지 않습니다.

OpenTelemetry 공식 문서는 관측성을 시스템의 출력을 살펴 내부 상태를 이해하는 능력이라고 적습니다. 소프트웨어에서는 트레이스·메트릭·로그 같은 텔레메트리 데이터를 분석해 대체로 이것을 얻는다고 적습니다. 시스템을 관측 가능하게 하려면 계측해야 합니다. 코드가 트레이스나 메트릭이나 로그 중 하나를 내보내야 합니다. 그 계측 데이터는 관측성 백엔드로 보내져야 합니다.

flowchart TD
    A[코드] -->|계측| B[텔레메트리 데이터]
    B --> C[관측성 백엔드]

선은 화면 수가 아니라 남은 데이터에 있습니다. 미리 고른 지표를 미리 만든 화면으로 보는 것까지가 모니터링입니다. 미리 정해 두지 않은 물음을 지금 남은 데이터로 답할 수 있으면 그것이 관측성입니다. 대시보드 100장이 전부 같은 지표를 다르게 그린 것이라면 답할 수 있는 물음은 한 개도 늘지 않습니다.

예시

traceparent 헤더

00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

W3C Trace Context 권고의 값입니다. traceparent HTTP(HyperText Transfer Protocol, 하이퍼텍스트 전송 규약) 헤더 필드는 들어오는 요청을 트레이싱 시스템 안에서 식별합니다. 필드는 넷입니다. version 은 8비트 부호 없는 정수를 나타내는 1바이트입니다. trace-id 는 트레이스 숲 전체의 아이디입니다. 분산 트레이스 하나를 시스템을 가로질러 유일하게 식별하는 데 쓰입니다. parent-id 는 호출한 쪽이 아는 이 요청의 아이디입니다. 어떤 트레이싱 시스템에서는 이것을 span-id 라 부릅니다. trace-flags 는 샘플링이나 트레이스 레벨 같은 트레이싱 플래그를 제어하는 8비트 필드입니다.

OpenTelemetry 의 스팬

스팬은 트레이스 안의 연산 하나를 나타냅니다. 스팬은 중첩될 수 있습니다. 그렇게 트레이스 트리를 이룹니다. 명세는 스팬이 다음을 감싼다고 적습니다.

• 스팬 이름
• 그 스팬을 유일하게 식별하는 변경 불가능한 SpanContext
• Span · SpanContext · null 중 하나의 꼴로 오는 부모 스팬
• SpanKind
• 시작 타임스탬프
• 끝 타임스탬프
• 속성
• 다른 스팬으로 가는 Link 의 목록
• 타임스탬프가 붙은 Event 의 목록
• Status

메트릭 스트림의 카디널리티 한도

밖으로 내보낼 수 있는 양에는 자리마다 상한이 걸립니다. OpenTelemetry 공식 블로그는 기본 집계 카디널리티 한도가 메트릭 스트림 하나당 2000 조합이라고 적습니다. 한도에 닿아도 그 뒤의 조합이 버려지지는 않습니다. 값들이 otel.metric.overflow=true 로 표시된 넘침 데이터 포인트 하나로 접힙니다.

otel.metric.overflow=true

접힌 뒤에는 어느 조합에서 온 값인지가 남지 않습니다. 그 물음에 대해서는 관측성이 거기서 끊깁니다.

관련 항목

이것을 얻는 텔레메트리 신호

로그 · 메트릭 · 트레이스 · 스팬 · 분산 트레이싱 · 연속 프로파일링 · 텔레메트리 · 계측

이것이 거치는 처리 단계

수집기 · 샘플링 · 카디널리티 · 보존 기간 · 관측성 백엔드

이것을 정의하는 표준·프로토콜

OpenTelemetry · W3C Trace Context · Prometheus · SRE(Site Reliability Engineering, 사이트 신뢰성 엔지니어링) · HTTP(HyperText Transfer Protocol, 하이퍼텍스트 전송 규약)

이것의 이상 여부를 판단하는 기준

SLO · 오류 예산 · 골든 시그널 · 알림

이것에서 자주 나는 오류·장애

알림 피로 · 카디널리티 폭발

이것과 맞세워지는 대립 개념

모니터링

이것의 이름이 비롯된 분야

제어이론

이것이 낮을 때 다시 거쳐야 하는 절차

배포