OpenTelemetry 지표란 무엇인가요?

OpenTelemetry 로그 및 추적과 마찬가지로 OTel 지표는 공통적이고 언어에 구애받지 않는 데이터 모델 및 전송 프로토콜(정확히는 OpenTelemetry Protocol(OTLP))을 사용하여 다양한 소스, 시스템 및 형식의 데이터를 수집하고 관측 가능성 백엔드로 전송하는 표준화된 텔레메트리 신호를 제공합니다. 

OTel 지표는 OpenTelemetry 계측을 사용하여 애플리케이션 및 인프라 구성 요소가 실행되는 동안 CPU 및 메모리 사용량, 처리량, 오류율, 요청 횟수 및 응답 시간과 같은 시계열 데이터를 수집합니다. 개발자가 필요한 정보를 기록하기 위해 코드를 계측한 후, OTel은 계측을 변경하지 않고도 이러한 지표를 집계하고 모든 백엔드 관측 가능성 도구로 내보내어 계측, 쿼리 및 시각화를 수행할 수 있도록 합니다.

지표는 일반적으로 시스템 문제를 나타내는 최초의 원격 측정 신호입니다. OTel 프레임워크에서 이러한 요소들은 동일한 개념과 메타데이터를 기반으로 하는 로그(개별 시스템 이벤트의 변경 불가능한 기록) 및 추적(데이터 요청의 전체 여정)과 통합됩니다.

이러한 역학 관계 덕분에 개발자와 사이트 신뢰성 엔지니어(SRE)는 지표를 고수준의 조기 경보 시스템으로 활용할 수 있습니다. 사용자는 장애 발생 경로 전체(장애 구성 요소가 상호 작용한 각 서비스에 대한 지표 포함)를 하나의 일관된 보기에서 추적하고 근본 원인 분석을 위해 추적 및 로그로 신속하게 전환할 수 있습니다.

실제로 IT 팀은 "이 엔드포인트가 느리다"에서 "특정 요청과 의존성이 문제다"로 몇 번의 클릭만으로 전환할 수 있습니다.

또한 OTel의 표준화 프로토콜은 관측 가능성 공급업체 간의 자동화된 신호 상관 관계를 용이하게 하여 기업이 여러 도구를 동시에 선택하거나 사용할 때마다 관측 가능성 도구를 전환할 수 있는 유연성을 제공합니다.

OpenTelemetry 지표는 OpenTelemetry의 기본 구성 요소입니다. OpenTelemetry는 소프트웨어 개발 키트(SDK), 벤더 중립 애플리케이션 프로그래밍 인터페이스(API) 및 애플리케이션, 시스템 및 장치 계측을 위한 기타 도구들을 포함하는 오픈 소스 관측 가능성 프레임워크입니다.

계측 코드는 매우 다양했으며, 네트워크상의 모든 앱과 서비스에서 데이터를 수집할 수 있는 도구를 제공하는 상용 업체는 없었습니다. 이러한 기능 격차로 인해 팀이 다양한 프로그래밍 언어, 형식 및 런타임 환경에서 데이터를 수집하는 것이 어렵고 불가능한 경우가 많았습니다.

기존 관측 가능성 접근 방식에서는 백엔드 인프라 및 구성 요소를 변경하는 작업이 시간과 노동이 많이 드는 과정이었습니다.

개발팀이 백엔드 도구를 교체하고 싶다고 가정해 봅시다. 그들은 코드를 완전히 재구성하고 새로운 서버로 원격 측정 데이터를 전송하기 위해 새로운 에이전트(자동화된 빌드 및 릴리스 작업을 실행하는 소프트웨어 구성 요소)를 구성해야 할 것입니다. 단편화된 접근 방식은 데이터 사일로와 혼란을 야기하여 성능 문제를 효과적으로 해결하기가 어려웠습니다.

OpenTelemetry는 텔레메트리 데이터를 수집, 분석, 백엔드 플랫폼으로 전송하는 방식을 표준화함으로써 관측 가능성 도구에서 중요한 발전을 의미했습니다. 이것은 커뮤니티 주도 표준을 기반으로 하는 오픈 소스 솔루션을 제공하여 시스템 동작 및 보안에 대한 데이터를 수집하고, 분산된 에코시스템에서 모니터링 및 관측 가능성을 간소화하는 데 도움을 주었습니다.

OpenTelemetry 지표는 지표가 생성, 설명 및 관측 가능성 백엔드로 전달되는 방식을 함께 정의하는 관련 구성 요소 그룹에 의존합니다. 여기에는 다음이 포함됩니다.

계측은 코드가 지표 값을 기록하는 데 사용하는 도구입니다. 동기식(코드가 실행될 때 실행 경로에 직접)과 비동기식(SDK가 코드에서 값을 요청할 때마다)의 두 가지 방법으로 값을 기록합니다.

동기식 계측은 작업과 함께 인라인으로 실행되므로 이벤트에 대한 현재 추적 컨텍스트와 속성을 캡처할 수 있으므로 수집하는 지표를 로그 및 추적과 더 쉽게 연관시킬 수 있습니다.

비동기식 계측은 SDK가 미리 정해진 수집 간격으로 호출하는 풀 기반 콜백 함수에 의해 업데이트됩니다. 이러한 계측은 각 사용자 요청(예: CPU 사용량 또는 메모리)이 아닌 주기적으로 샘플링되는 값을 기록하는 데 유용합니다. 

OTel 계측은 애플리케이션 로직과 지표 파이프라인 사이에 위치하며, 'HTTP 요청 완료'와 같은 이벤트를 SDK가 집계하고 내보낼 수 있는 구조화된 측정으로 전환합니다. 각 유형의 지표 계측은 특정 측정 패턴에 최적화되어 있으며 SDK가 개별 측정치를 내보낸 지표에 결합하는 방법을 설명하는 관련 집계 전략을 가지고 있습니다.

일반적인 계측 유형은 다음과 같습니다.

• 카운터는 시간에 따라 증가하는 증분을 기록하는 동기식 도구입니다(예: 프로세스 시작 이후 총 요청 수 또는 총 전송 바이트 수). 카운터는 또한 단조적이므로 새로운 측정값을 기록할 때마다 기존 값을 대체하는 대신 기존 값에 더합니다.

• 업다운 카운터는 시간에 따라 증가하거나 감소할 수 있는 값(예: 활성 사용자 수 또는 대기열 크기)을 기록하는 동기식 도구입니다. 일반 카운터와 달리 업다운 카운터는 비단조적이므로 기존 값을 대체하여 합계를 늘리거나 줄입니다.

• 비동기식 카운터와 비동기 업다운 카운터는 동기식 카운터와 유사하지만, 코드 실행 시 값을 수집하는 대신 내보내기마다 한 번씩 기록합니다.

• 게이지는 매 데이터 푸시마다 임의로 증가하거나 감소할 수 있는 값을 기록하는 동기식 계측으로, 코드에서 수집된 순간의 값을 나타냅니다. 동기 게이지 외에도 지표 수집에는 지표 백엔드가 데이터를 수집할 때마다 현재 값을 가져오는 비동기식 계측기인 관찰 가능한 게이지가 필요합니다.
  
  게이지는 카메라가 의도한 대상의 스냅샷을 캡처하는 것과 거의 동일한 방식으로 값의 스냅샷을 캡처합니다. 게이지는 누적이 아니기 때문에, 보통 합산이 의미가 없는 비가법 값(예: 메모리 사용량이나 온도 등)에 적용됩니다.  

• 히스토그램은 단일 수치(예: 총합 또는 현재 값)를 추적하는 대신, 측정값이 서로 다른 값 범위에 속하는지 여부를 나타내는 동기식 도구입니다. 값을 '버킷'으로 분류하여 IT 팀이 요청 시간, 지연 시간 및 페이로드 크기와 같은 지표에 대한 백분위수를 계산하고 값 분포를 이해할 수 있도록 합니다.

OTel은 표준화된 지표 데이터 모델 및 시계열을 정의하여 개별 지표 이벤트를 깔끔하고 쿼리 가능한 시간 기반 숫자 시리즈로 변환하여 IT 팀이 관측 가능성 플랫폼에 저장하고 분석할 수 있습니다.

OpenTelemetry는 이벤트 모델(계측의 원시 측정값), OTLP 스트림 모델(해당 측정값을 번들로 묶어 전송하는 방법), 시계열 모델(백엔드가 측정값을 저장하는 방법)의 세 가지 관련 모델을 사용하여 지표를 설명합니다.

실제로 애플리케이션 코드는 이벤트 모델을 사용하여 이벤트를 기록하고, SDK/컬렉터는 이벤트를 OTLP 스트림으로 변환하며, 백엔드 플랫폼은 이를 시간 경과에 따른 '상태 200의 서비스 X에 대한 초당 요청 수'와 같은 시계열로 저장합니다.

명명 규칙이라고도 하는 시맨틱 규칙은 공통 지표에 대한 표준화된 이름, 단위 및 속성 키를 정의하여 다양한 서비스와 라이브러리가 일관된 원격 분석을 생성할 수 있도록 합니다. 예를 들어, 규칙은 'http.server.duration'와 같은 이름을 규정합니다. HTTP Server 요청 지연 시간을 지정하고 지속 시간을 초 또는 밀리초와 같은 권장 단위로 지정합니다.

OTel의 시맨틱 규칙을 사용하면 팀은 특정 스키마가 필요한 사전 구축된 대시보드 및 알림 시스템에 지표를 연결할 수 있으므로 사용자 지정 구성 작업에 소요되는 시간을 줄일 수 있습니다. 또한 모든 팀 구성원이 마이크로서비스 전반에 걸쳐 동일한 '측정 지표 언어'를 사용하기 때문에 팀 간 협업이 더 쉬워집니다.

또한 컨텍스트 전파 기능은 서비스 경계를 넘어 추적 또는 스팬 식별자와 같은 공유 컨텍스트를 전달하여 지표를 관련 추적(예시 사용) 및 로그와 연결할 수 있습니다.

예를 들어, OTel 전파기는 요청 처리기에서 들어오는 컨텍스트를 추출하고, 이를 사용하여 추적 범위를 시작하고, 동일한 컨텍스트를 사용하여 지연 시간 지표를 기록하고 로그 항목을 작성할 수 있습니다. 이렇게 하면 지표 포인트와 로그 선 모두 현재 추적으로 태그가 지정됩니다.

앱 코드가 하위 코드로 호출할 때, 전파기는 동일한 컨텍스트를 나가는 요청에 주입합니다. 코드는 이를 추출하고 자체 하위 범위를 시작하며 자체 지표와 로그에 해당 컨텍스트를 사용하여 두 서비스의 모든 것을 동일한 엔드투엔드 추적에 연결합니다.

속성은 라벨, 태그 또는 차원이라고도 하며, 개별 측정값이나 집계된 데이터 포인트에 부착된 키-값 쌍입니다. 이들은 지표 이름, 집계 유형 및 단위와 함께 시계열을 전체 또는 부분적으로 정의합니다. 속성이 없다면, 특정 지표에 대한 모든 측정값은 구별할 수 없는 하나의 계열로 축소될 것입니다.

서비스 이름, 엔드포인트, HTTP 상태 코드, 지역 또는 테넌트 ID와 같은 속성을 추가하면 단순한 지표가 팀에서 관측 가능성 도구로 분석할 수 있는 차원적이고 특화된 지표 스트림으로 변환됩니다. 팀은 원하는 기준으로 필터링하거나 그룹화하여 고해상도 보기를 얻을 수 있습니다.

또한 좋은 속성 설계는 세부 정보와 지표 카디널리티(속성이 취할 수 있는 고유 값의 수)의 균형을 유지하므로 팀은 유용한 쿼리를 실행하면서 레이블 폭발을 방지할 수 있습니다.

측정은 특정 시점에 계측기가 취한 단일 이벤트 수준 판독값으로, 종종 속성이 수반됩니다. 예를 들어, 하나의 HTTP 요청이 완료되면 경로와 상태 코드를 나타내는 route=”/login” 및 status_code=200과 같은 속성과 함께 120밀리초의 지연 시간을 기록할 수 있습니다.

각각의 기록은 해당 작업 중에 발생한 상황을 설명하는 별도의 측정값입니다.

측정값은 SDK에 간단히 저장되며, SDK는 원시 측정값을 더 큰 지표 스트림 내의 데이터 포인트로 변환합니다. 모든 요청을 개별적으로 보여주는 대신, 집계된 데이터는 "route /login에 대해 상태 코드 200으로 10:00:00부터 10:00:10까지 총 500건의 요청이 있었고, 총 소요 시간은 25초였습니다."와 같이 표시될 수 있습니다. 결국 관측 가능성 백엔드로 내보내지고 저장되는 것은 바로 이러한 데이터 포인트입니다.

OpenTelemetry 지표 API는 애플리케이션 코드가 지표를 생성하기 위해 호출하는 인터페이스 세트입니다. 이는 벤더에 구애받지 않도록 설계되었으며, 계측 기능을 구체적인 SDK 구현과 분리합니다. IT 팀은 표준 API를 사용하여 계측을 한 번 작성한 다음 추가 단계를 거치지 않고도 SDK, 익스포터 및 백엔드를 교체할 수 있습니다.

OTel 지표 API의 구조는 미터 공급자, 미터 및 지표 계측이라는 세 가지 핵심 인터페이스로 구성됩니다.

미터 공급자는 API의 진입점이며 미터 인스턴스를 생성하는 역할을 담당합니다. 어떤 지표 리더와 익스포터를 사용할지, 어떤 보기 및 집계 방식을 적용할지, 그리고 데이터를 얼마나 자주 수집하고 내보낼지를 결정합니다. 미터 공급자는 일반적으로 애플리케이션 시작 시 한 번 로드되므로(종종 글로벌 공급자로) 모든 미터와 계측이 일관된 리소스 정의 및 내보내기 파이프라인을 공유합니다.

미터는 애플리케이션 코드가 카운터, 히스토그램 및 게이지를 만드는 데 사용하는 객체입니다. 각 미터는 일반적으로 라이브러리 또는 서비스의 이름을 따서 명명되므로(예: "bank.payment"), 해당 코드에서 생성되는 지표를 일관되게 그룹화하고 식별할 수 있습니다.

미터는 자체적으로 데이터를 저장하지 않습니다. 대신 계측의 작동을 위한 데이터 팩토리 역할을 하며, 기록된 측정값을 집계 및 내보내기를 위해 기본 SDK로 전달합니다. 미터는 미터 공급자로부터 받기 때문에 항상 공급자가 정의한 구성, 보기 및 익스포터로 작동합니다.

그러면 계측이 지침을 제공하므로 코드가 속성을 사용하여 측정값을 보고할 수 있습니다.

OpenTelemetry SDK는 API 호출을 실제 원격 측정 데이터 포인트로 전환하는 OpenTelemetry API의 구체적인 구현입니다. 이 라이브러리는 언어별 라이브러리(예: Java™ 또는 Python)를 제공하여 지표 데이터를 수집, 집계 및 내보내기 위해 준비합니다.

SDK는 계측 수명 주기를 관리하고, 측정값의 스토리지 저장을 처리하고, 비동기식 계측에 대한 콜백을 실행하고, 구성된 집계 및 보기를 적용하고, 지표 수집 간격(일반적으로 10~60초)을 제어합니다.

SDK 내에서 프로세서는 지표 스트림을 전송하기 전에 필터링, 속도 제한 또는 변환을 포함한 집계 및 추가 로직을 적용합니다.

익스포터는 처리된 지표 데이터 포인트를 백엔드별 형식으로 변환하고 지원되는 프로토콜(예: OTLP)을 사용하여 외부 백엔드 또는 관측 가능성 플랫폼으로 전송합니다.

팀은 고가용성과 중복성이 필요한 환경에서 다중 백엔드 지원을 위해 SDK에서 여러 익스포터를 함께 연결하도록 선택할 수 있습니다. 이러한 경우 OpenTelemetry Collectors는 여러 백엔드에 동시에 지표를 전송하거나, 내보내기 시도를 다시 시도하거나, 대규모로 데이터를 인증할 수 있는 스마트 프록시 역할을 합니다. 

집계는 개별 측정값을 수학적으로 결합하여 요약된 통계로 변환하고, 백엔드가 시계열 데이터 포인트로 저장하고 쿼리하는 방식을 정의합니다. 원시 데이터는 SDK의 집계기가 각 고유한 시계열에 대해 수집 구간마다 단일 데이터 포인트로 축적합니다.

일반적인 집계 패턴은 다음과 같습니다.

• Sum은 누적량(예: 전송된 바이트)에 대한 모든 값을 더하는 값입니다.

• LastValue는 가장 최근 측정값만 유지하고 이전 측정값은 무시합니다.

• Histogram aggregation은 팀에서 백분위수를 계산하고 이상값을 탐지할 수 있도록 값을 버킷으로 그룹화합니다.

• Drop은 고유값이 많은 데이터(고유값 데이터)로부터 보호하기 위해 모든 값을 버립니다.

집계에는 시간 경과에 따른 지표 값을 해석하는 방법을 백엔드에 알려주는 임시 메타데이터도 포함됩니다. 두 가지 주요 유형은 다음과 같습니다.

• 누적 값은 프로세스 시작 이후의 총합을 나타냅니다. 이 값들은 프로세스가 다시 시작될 때만 초기화되며, 백엔드는 데이터 포인트의 차이를 계산하여 비율을 산출합니다.

• 델타 값은 마지막 데이터 수집 이후의 변화를 반영합니다. 백엔드는 델타를 직접 합산하여 요금을 결정할 수 있습니다.

SDK는 계측 유형에 따라 자동으로 올바른 집계를 적용합니다. 또한 이를 통해 IT 팀은 계측을 변경하지 않고 간단한 합계에서 풍부한 히스토그램 또는 기타 알고리즘으로 전환할 수 있습니다.

지표는 추세를 보여주고 경고를 보내고, 추적은 요청 경로를 표시하고, 로그는 풍부한 이벤트 수준 컨텍스트를 제공합니다. 지표를 추적 및 로그와 상호 연관시키면 세 가지 주요 관측 가능성 신호("관측 가능성의 핵심 요소"라고 함)가 연결되어 팀이 시스템 동작에 대한 계층화된 보기를 얻을 수 있습니다.

예를 들어, 지표는 "오후 2시 15분에 급증한 오류율"과 같은 집계된 추세를 표시할 수 있지만 어떤 요청이 실패했는지 또는 그 이유는 밝힐 수 없습니다. 추적은 서비스 전반에서 문제가 있는 개별 요청 경로를 밝혀주지만, 지표가 없으면 팀이 잘못된 요청이 이상치인지 시스템 문제인지 판단하는 데 도움이 될 수 없습니다. 로그는 자세한 오류 메시지와 이벤트를 제공하지만, 맥락이 없으면 단순한 잡음에 불과합니다.

세 가지 신호를 모두 연관시키면 IT 팀은 개략적인 지표 트렌드에서 영향을 받는 추적 및 관련 로그로 몇 초 만에 원활하게 이동할 수 있습니다.

OTel 지표는 기존 지표와 근본적으로 다릅니다. 기존 지표는 일반적으로 리소스 사용량에 대해 사전 정의된 간단한 카운터에 초점을 맞춘 레거시 모니터링 접근 방식을 나타냅니다. 이러한 지표는 호스트 수준 또는 애플리케이션별 측정을 강조합니다. 

OpenTelemetry 지표는 반면에 분산된 IT 환경을 위해 추적, 로그 및 지표 전반의 수집을 표준화하는 통합된 공급업체에 구애받지 않는 관측 가능성 프레임워크의 일부를 형성합니다. 양방향 변경을 위한 UpDownCounters와 지수 버킷을 지원하는 히스토그램을 포함하여 보다 유연한 데이터 모델 및 계측을 제공함으로써 기존 지표를 기반으로 구축됩니다. 또한 지표를 강화하기 위해 명시적인 속성, 단위 및 타임스탬프를 제공합니다.

OTel 지표는 설계, 수집 방법 및 최신 시스템에의 적용 가능성 측면에서도 기존 지표과 다릅니다.

기존 지표는 수집, 스토리지 및 쿼리를 긴밀하게 결합하는 경직된 풀 스택 모델을 특징으로 하며, 종종 기본 카운터, 게이지, 요약 및 히스토그램의 누적 전용 값을 명시적 버킷(수동 버킷팅 필요)과 함께 사용합니다.

OpenTelemetry 지표는 신호 생성과 처리 및 내보내기를 구분하는 API, SDK 및 프로토콜을 포함하는 모듈식 3계층 설계를 사용합니다. 이 구성을 통해 OTel 지표는 델타 시간, 정수 값, 히스토그램의 최소 및 최대 메타데이터, 동적 스케일링을 위한 지수 히스토그램과 같은 고급 기능을 지원할 수 있습니다.

기존 접근 방식은 주로 격리된 지표에 대해 노출된 API 엔드포인트의 풀 기반 데이터 스크래핑에 의존합니다. 수동 계측을 사용하고 추적 또는 로그에 대한 지원이 제한적이므로 텔레메트리 및 관측 가능성 파이프라인이 단편화됩니다.

OpenTelemetry는 푸시 기반 데이터 수집에 OTLP(바이너리 프로토콜)를 사용하여 자동 및 수동 계측을 통해 추적, 지표 및 로그를 통합 수집할 수 있습니다. 또한 OTel은 데이터 변환, 일괄 처리 및 백엔드 도구로의 라우팅을 용이하게 하는 Collector를 제공하여 IT 팀이 애플리케이션 스토리지 문제를 해결하는 데 도움을 줍니다.

기존 원격 측정 데이터는 단순하고 단일화된 시스템에 적합합니다. 하지만 추적 기능 부족, 벤더 종속성 문제, 그리고 종속성을 모호하게 하고 연쇄적인 오류를 발견하지 못하게 하는 분산된 신호 때문에 마이크로서비스 환경에서는 제대로 작동하지 못합니다.

OpenTelemetry는 클라우드 네이티브 분산 환경에서 탁월한 성능을 발휘합니다. 서비스 전반에 걸친 요청 흐름, 지연 병목 현상 및 리소스 진단에 대한 엔드 투 엔드 가시성을 제공하는 상관 관계가 있는 벤더 독립적인 원격 측정 데이터를 제공하기 때문입니다. 또한 OTel은 샘플링 및 하이브리드 도구 통합을 지원하므로 IT 환경과 함께 원격 측정 및 계측을 확장할 수 있습니다. 

OpenTelemetry 지표는 최신 아키텍처에서 관측 가능성을 개선하는 데 도움이 되는 표준화된 정량적 측정값을 제공합니다. 시스템 성능에 대한 자세한 인사이트를 제공하여 개발자와 엔지니어가 사전 예방적 문제 해결 및 최적화 전략을 구현할 수 있도록 지원합니다.

그 외에도 다음과 같은 이점이 있습니다.