스택에 Zipkin을 구현하고자합니다. Zipkin을 살펴보면 일반 플래그도 처리 할 수 있도록 Zipkin 시스템을 확장하는 것이 좋습니다.일반 기능 플래그를 전달하려면 zipkin 서비스 라이브러리를 수정해야합니까?
관찰 :
는결론 :
TL; B3 propagation은 원래 고정 된 크기의 데이터 용으로 설계 되었기 때문에 추적에 보조 데이터를 운반하는 것이 범위에 있지 않으며 이러한 이유로 B3을 확장하는 솔루션은 기존 코드와 호환되지 않습니다.
그래서이 모든 솔루션은 헤더를 전달하는 내용 인 instrumented apps에서 맞춤 처리를 의미하는 확장이 될 것입니다. 서버는 이러한 헤더를 결코 볼 수 없으므로 신경 쓰지 않습니다.
사람들은 대개 지프킨이있는 플래그와 같은 다른 것들을 통합하기 위해 값 (보통 루트 스팬)을 포함하는 이진 주석을 태그에 추가합니다. 이렇게하면 오프라인으로 쿼리하거나 검색 할 수 있지만 응용 프로그램의 기내 검색은 처리하지 않습니다.
linkerd 또는 플랫폼 관련 전파 된 컨텍스트와 같은 중개를 사용하는 대신 추적 레이어에 책임을 전달하고 싶다고 가정 해 보겠습니다. 첫째, 어떤 데이터가 문제없이 작동 할 수 있습니까? 가장 쉬운 방법은 set-once (zipkin의 추적 ID처럼)입니다. 그것을 돌연변이시키지 않고 설정되고 확산 된 것은 무엇보다 적은 기계공입니다. 다음으로 어려움을 겪고있는 중간에 새로운 항목을 추가하는 것이 가장 어렵고 항목을 변경/병합하는 것이 가장 어렵습니다.
이것은 요청/추적 트리를 통해 절대로 변경되지 않는 인바운드 플래그에 대한 것입니다. 우리는 추적 데이터를 처리 할 때 헤더를보고 저장하고 다운 스트림으로 전달합니다. 이 값을 추적 시스템에서 읽을 필요가없는 경우, 전송/전파 문제가 대부분이므로 추적 시스템에서 가장 쉽습니다. 예를 들어 다른 미들웨어가 헤더를 읽었을 때 추적자에게 전달할 특정 사항을 기억하는 것이 "부작용"일뿐입니다. 이 작업이 단일 헤더에서 완료되면 추가 될 각 장소의 패턴보다 코드가 적습니다. 플래그가 숫자로 인코딩 될 수 있다면 코드가 더 적지 만 비현실적 일 수 있습니다.
예를 들어 "baggage" from brownsys 및 OpenTracing (일부 라이브러리는 zipkin을 지원함)과 같이 전파 된 컨텍스트를 수동으로 조작 할 수있는 API가있는 라이브러리가 있습니다. 전자는 모든 계측 (예 : 모니터링, 차지백, 추적 등)의 일반적인 레이어를 목표로하고 후자는 추적에만 해당됩니다. OpenTracing은 injector and extractor과 같은 추상 유형을 정의하며 다른 필드를 포함하도록 사용자 정의 할 수 있습니다.그러나 이것을 수행하기 위해서는 여전히 구체적인 구현 (헤더 형식 등을 알고 있어야 함)이 필요합니다. 응용 프로그램에서이 데이터를 읽지 않으려면 해당 구현에 대한 세부 정보 (특히 추적 컨텍스트)가 필요합니다.
Spring Cloud Sleuth와 Brave와 같은 특정 zipkin 특정 라이브러리는 B3 변형 또는 새 또는 사이트 특정 추적 형식을 지원하기 위해 customize how headers are parsed을 의미합니다. 현재 모든 사용자가이 기능을 지원하지는 않지만 이러한 유형의 기능이 더 많이 사용되기를 기대합니다. 즉, 지원해야 할 수도있는 모든 플랫폼을 지원하려면 수술을해야 할 수도 있습니다.
짧은 이야기가 짧기 때문에 전파와 관련하여 몇 가지 라이브러리가 있으며이 라이브러리를 사용하여이 사용 사례를 지원하기에 가장 쉽게 수정할 수 있습니다. B3가 현재 이와 같은 표현식을 정의하지 않기 때문에 일부 코드가 필요합니다.