오픈트레이싱이란 무엇이며 왜 중요한가?

이전에 분산 시스템에서 시스템 통합 가시성이 중요한 이유와 이를 통해 극복할 수 있는 과제에 대해 설명한 적이 있는데, 이를 놓치셨다면 다음을 참조하시기 바랍니다. 매트 인젠트론의 소개 여기서 문제. 다음으로, 카우치베이스 SDK 팀이 선택한 이유에 대해 설명하겠습니다. 오픈트레이싱 를 추적 API로 사용하는 이유와 이것이 중요한 이유에 대해 설명합니다. 또한 SDK에 대한 간략한 소개도 다룹니다. 임계값 로깅 추적기 (OpenTracing에서 .NET은 트레이서를 시연하기 위한 수단으로 사용되며, 각 SDK에서 유사한 기능을 사용할 수 있습니다).

왜 오픈트레이싱인가?

오픈트레이싱 는 분산 시스템 환경 내에서 추적 정보를 구조화하는 방법과 요청이 프로세스 경계를 넘나드는 방법을 설명하는 표준화된 API입니다. OpenTracing을 사용하면 수집되는 데이터와 해당 데이터를 수집하고 해당 데이터로 무언가를 수행하는 메커니즘을 분리할 수 있습니다. 또 다른 주요 장점은 OpenTracing이 공급업체에 구애받지 않기 때문에 규정된 네트워크 프로토콜이나 전송 중 데이터 구조를 고수하지 않고도 사용자 지정 또는 타사 분산 추적 구현을 최대한 유연하게 사용할 수 있다는 점입니다.

카우치베이스에서는 통합 가시성과 OpenTracing 통합을 중요하게 생각합니다. 우리는 우리가 더 큰 고객 솔루션의 일부라는 것을 알고 있으며, 우리가 알고 있는 요소에 대해 무슨 일이 일어나고 있는지에 대한 뷰를 제공하는 데 도움을 주고자 합니다. 카우치베이스 SDK의 경우, 요청(Get, Upsert 등)이 제출된 후 응답이 준비될 때까지의 여정을 설명하는 단계 모음을 정의했습니다. 오픈트레이싱 세계에서는 이러한 단계를 **Span**이라고 하며, 타이밍 정보(시작/종료)가 있습니다. 또한 스팬에는 ID, 엔드포인트 이름, 네트워크 세부 정보 등의 추가 정보로 '태그'를 지정할 수 있습니다. 이 모든 정보는 당시 상황을 파악하는 데 유용합니다.

각 SDK는 요청에 대해 다음과 같은 스팬을 정의합니다:

참고: 요청 인코딩 및 응답 디코딩은 일부 작업에만 필요합니다. 예: Get은 '요청 인코딩'을 생략합니다*.

모든 SDK 관련 작업 외에도, 카우치베이스 서버는 N1QL, FTS, 애널리틱스 등 다른 서비스와 일치하도록 KV 응답의 일부로 작업 기간을 반환하도록 개선되었습니다. 이는 응답 패킷에 직접 인코딩되며 처리 중에 SDK를 사용하여 파싱됩니다. 이를 통해 작업 서비스에 비정상적으로 오랜 시간이 소요되었는지 확인할 수 있으며, 느린 작업(예: 디스크에서 읽기)의 원인을 파악하는 데 도움이 될 수 있습니다.

다음으로, OpenTracing API는 트레이서를 스팬을 생성 및 수집하고 스팬으로 무언가를 수행하는 것으로 설명합니다. 카우치베이스 SDK는 기본적으로 트레이서 구현을 제공하는데, 이 트레이서 구현은 임계값 로깅 추적기 (아래 참조). 이것은 서비스 특정 임계값을 초과하는 요청을 집계한 다음 총 수와 최악의 위반자 샘플을 포함하여 주어진 간격으로 로그에 기록하는 겸손하고 기본으로 제공되는 추적기입니다. 물론 Couchbase가 배포되는 환경이 매우 다양하기 때문에 그 수와 임계값은 조정할 수 있습니다.

여기서 언급해야 할 핵심 사항은 Couchbase SDK가 의도적으로 Tracer 구현을 교체할 수 있도록 허용한다는 점입니다. 이를 통해 내부 로직을 수정할 필요 없이 트레이서 구현(사용자 지정 또는 제품)을 교체할 수 있는 이점을 제공합니다.

오픈트레이싱 사양에 대한 자세한 내용은 다음과 같습니다. 여기.

C# .NET을 사용하는 임계값 로깅 추적기

자, 지금까지 이론적인 이야기는 많이 했으니 이제 실제로 보여드리겠습니다. 다음은 간단한 예시입니다. 임계값 로깅 추적기 .NET SDK에서 작동합니다.

저희는 합리적인 기본값을 선택하려고 노력했습니다. 임계값 로깅 추적기 를 사용하여 중요한 세부 정보를 캡처하는 것과 로그 파일을 스팸으로 채우지 않는 것의 균형을 맞출 수 있습니다. 또한 각 SDK의 다음 마이너 릴리스부터는 이 모든 기능이 기본적으로 활성화됩니다. 즉, 별도의 추가 작업 없이 이 모든 기능을 무료로 이용할 수 있습니다!

로그 출력의 예는 다음과 같습니다(이 형식은 DP, 베타 및 GA 간에 변경될 수 있습니다. 피드백 필요!):

위의 예에서 "kv"와 같이 유형별로 작업을 그룹화하고 서비스 정의 임계값을 초과한 작업의 총 수를 표시한 것을 볼 수 있습니다. 또한 추가 세부 정보를 제공하는 가장 느린 작업의 샘플도 있습니다. 이 정보는 문제를 진단할 때 매우 유용할 수 있습니다. 샘플에는 서버가 해당 작업을 처리한 시간을 나타내는 "server_us" 속성도 포함되어 있습니다.

CNCF

클라우드 네이티브 컴퓨팅 재단(CNCF)는 컨테이너로 구축된 오픈 소스 소프트웨어 프로젝트 커뮤니티로, 처음부터 마이크로서비스 에코시스템의 일부를 형성하고 있습니다. 프로젝트가 성장하는 동안 재능 있는 엔지니어와 협업하고 가시성을 확보할 수 있는 귀중한 리소스입니다. 이는 소규모 프로젝트가 지원을 받고 야생으로 진출할 수 있는 발판을 마련하는 데 매우 중요합니다.

오픈트레이싱은 이 프로그램에 참여하게 되었으며, 이 프로그램은 인큐베이팅 프로젝트에 참여하세요. 이는 프로젝트의 가시성과 도달 범위를 개선하는 데 도움이 되며, 프로젝트가 성장함에 따라 그들과 우리 모두에게 좋은 일이 될 수 있습니다.

물론 아직 인큐베이팅 중이고 OpenTracing 표준이 아직 1.0에 도달하지 않았기 때문에, Couchbase SDK에서 제공할 인터페이스는 표준이 발전함에 따라 추적할 것입니다. 즉, 인터페이스는 다음과 같이 표시될 것입니다. 커밋되지 않음 현재로서는 마이크로 릴리스에서도 변경될 수 있습니다. 다음과 같이 업그레이드하는 것을 목표로 하고 있습니다. committed OpenTracing이 1.0에 도달하면.

다음 단계

이제 카우치베이스가 추적 API로 OpenTracing을 선택한 이유와 이를 통해 사용자에게 제공할 수 있는 기능에 대해 살펴보고, 즉시 사용 가능한 추적기를 사용하는 방법과 다른 추적 솔루션과 통합하는 방법에 대해 알아보았습니다. 마이클 니칭거 에 대해 더 자세히 알아보고자 합니다. Couchbase Java SDK를 통한 응답 시간 관찰 가능성 와 통합하는 방법을 보여줍니다. Jaeger 추적 시스템.