이전 튜토리얼에서는 스팬 링크를 사용하여 분산 시스템 내 상호 작용을 추적하는 방법을 배웠습니다
이 튜토리얼에서는 스팬 링크 및 고급 사용 사례 사용에 대한 모범 사례를 구현하는 방법을 살펴보겠습니다
복잡한 분산 시스템을 다룰 때 명확성과 성능을 유지하려면 올바른 추적 전략을 선택하는 것이 필수적입니다.
OpenTelemetry에서 사용할 수 있는 두 가지 기본 도구는 상위-하위 관계와 스팬 링크입니다. 특히 보다 일반적인 상위-하위 관계와 비교하여 스팬 링크를 효과적으로 사용하는 시기와 방법을 살펴보겠습니다.
상위-하위 추적이 아닌 스팬 링크를 사용해야 하는 경우를 이해하는 것은 서비스 통신 방식을 올바르게 매핑하는 데 중요합니다.
부모-자녀 관계: 표준 추적 모델
추적에서 부모-자식 관계는 간단합니다. 한 서비스가 다른 서비스를 호출하면 추적은 두 범위 사이에 직접적인 상위-하위 링크를 생성합니다. 하위 스팬은 상위 스팬에 종속되어 작업 흐름을 명확하게 보여줍니다.
이 모델은 하나의 작업이 다른 작업을 직접 트리거하고 다음과 같은 선형 진행을 따르는 동기 작업에서 잘 작동합니다.
스팬 링크
실제 시스템, 특히 마이크로서비스나 비동기 프로세스를 사용하는 시스템에서는 모든 작업이 이 깔끔한 계층적 흐름을 따르지는 않습니다. 이것이 스팬 링크의 가치가 되는 곳입니다.
스팬 링크를 사용하면 직접적인 원인과 결과 패턴을 따르지 않을 수 있는 두 스팬을 연결할 수 있습니다. 예:
비동기 작업: 메시지 대기열은 처리 서비스에 요청을 보낼 수 있지만 해당 요청을 요청을 트리거한 원래 서비스에 연결할 수도 있습니다.
일괄 작업: 데이터를 일괄 처리하는 시스템이 있을 수 있습니다. 여기서 여러 하위 작업이 단일 트리거 이벤트에 다시 연결되지만 이러한 작업은 순차적으로 실행되지 않습니다.
분리형 또는 비동기식 시스템:
한 프로세스가 다른 프로세스를 시작하지만 직접적인 호출은 없습니다.
다중 상위: 여러 프로세스가 하나의 결과에 기여하는 경우(예: 여러 서비스의 데이터가 하나의 보고서로 집계됨) 스팬 링크를 사용하면 관련된 모든 스팬을 연결할 수 있습니다.
상관 이벤트: 한 서비스의 실패로 인해 다른 서비스에 간접적으로 오류가 발생하는 경우와 같이 다양한 추적의 범위를 연결해야 할 때 스팬 링크가 이상적입니다.
동기식 작업: 작업 간의 관계가 직접적이고 동기식인 경우 스팬 링크는 실제 가치를 추가하지 않고 추적 시각화를 복잡하게 만들 수 있습니다. 이 경우 단순성을 위해 부모-자식 관계를 고수하십시오.
트래픽이 많은 시스템에서는 모든 범위 또는 링크를 캡처할 필요가 없습니다. 샘플링은 추적의 일부만 기록하여 시스템에 부담을 주지 않으면서 분석에 충분한 데이터를 캡처하는 전략입니다.
헤드 기반 샘플링: 시스템의 진입점(헤드)에서 트레이스를 캡처합니다. 이를 주요 서비스에 적용하여 우선 순위가 높거나 중요한 추적에 대해서만 스팬 링크가 생성되도록 할 수 있습니다.
테일 기반 샘플링: 오류가 발생한 트레이스만 캡처하는 등 결과를 기반으로 트레이스를 샘플링합니다. 이를 사용하면 실패와 같이 심층적인 조사가 필요할 가능성이 가장 높은 경우에 스팬 링크가 사용되도록 할 수 있습니다.
완벽한 관찰 가능성 데이터를 얻으려면 좋은 명명 규칙과 구조화된 추적이 중요합니다. 특히 스팬 링크가 관련된 경우 스팬 이름은 그것이 나타내는 내용을 명확하게 설명해야 합니다. 범위 간의 관계가 항상 시각적으로 명확하지는 않기 때문에 이는 범위 링크를 사용할 때 더욱 중요해집니다.
일관적인 명명 규칙:
서비스 이름, 함수 또는 작업을 포함하는 등 스팬 이름에 일관된 패턴을 사용하세요.
예를 들어 결제 처리 서비스의 스팬 이름은 Payment-service.processPayment로 지정될 수 있습니다.연결된 스팬의 역할 표시:
해당되는 경우 스팬 이름에 연결된 스팬의 역할을 표시하세요. 예를 들어 user-authentication.request를 session-creation.init에 연결하여 둘 사이의 연결을 명확하게 만들 수 있습니다.
그룹 관련 스팬:
논리적인 그룹 스팬 예를 들어 여러 마이크로서비스가 하나의 더 큰 프로세스에 기여하는 경우 스팬 링크와 이름 지정이 각 부분을 담당하는 서비스를 식별하는 데 도움이 되는지 확인하세요.링크 이유 문서화:
가능하다면 추적 자체(메타데이터를 통해) 또는 문서에 스팬 링크가 존재하는 이유를 문서화하세요. 이는 두 범위 간의 관계를 설명하는 추적 코드의 간단한 설명만큼 간단할 수 있습니다.스팬 링크를 사용하여 서비스 간 오류 흐름을 추적하는 방법
수많은 마이크로서비스가 포함된 복잡한 웹 애플리케이션을 관리한다고 가정해 보세요. 각 마이크로서비스는 사용자 경험의 서로 다른 부분을 담당합니다.
사용자가 주문을 하면 결제 서비스, 재고 서비스, 배송 서비스가 실행될 수 있습니다. 이 체인 어딘가에서 오류가 발생하면 오류가 발생한 위치와 다른 서비스에 어떤 영향을 미쳤는지 아는 것이 중요합니다. 여기가 스팬 링크가 들어오는 곳입니다.
스팬 링크를 사용하면 직접적인 상위-하위 관계는 아니지만 여전히 문맥적 관련성을 갖는 추적을 연결할 수 있습니다. 오류 추적을 위해 스팬 링크를 사용하면 한 서비스의 오류와 다른 서비스에 대한 후속 영향을 연관시킬 수 있습니다. , 비록 직접적인 관계를 공유하지 않더라도.
사용 사례: 귀하의 결제 서비스에서 거래를 처리하는 동안 오류가 발생했고 이러한 오류가 배송 서비스에 간접적인 영향을 미친다고 가정해 보겠습니다. 스팬 링크를 사용하면 결제 서비스의 오류 스팬과 문제를 감지한 배송 서비스의 스팬 간의 관계를 생성할 수 있습니다.
이는 서비스 전반에서 오류의 흐름을 시각화하고 파급 효과를 이해하는 데 도움이 됩니다.
마이크로서비스 전체에서 오류 범위를 캡처하고 연결하기 위한 코드 예제
OpenTelemetry를 사용하여 이러한 오류를 캡처하고 오류 사이에 스팬 링크를 만드는 방법을 살펴보겠습니다. 다음은 Python을 사용한 간단한 예입니다.
from opentelemetry import trace # Initialize tracer tracer = trace.get_tracer("order-service") # Create a span in the payment service with tracer.start_as_current_span("payment-processing") as payment_span: try: # Simulate a payment process that raises an error process_payment() except Exception as e: payment_span.record_exception(e) payment_span.set_status(trace.Status(trace.StatusCode.ERROR, str(e))) # Capture the error trace and create a span link error_link = trace.Link(payment_span.get_span_context()) # Now in the shipping service, you can link this error trace with tracer.start_as_current_span("shipping-service", links=[error_link]) as shipping_span: # Handle the impact of the payment error here process_shipping()
위 코드 스니펫 설명
결제 처리 기간은 결제 실패 시 오류를 포착합니다.
결제 처리 기간의 컨텍스트를 사용하여 기간 링크(error_link)가 생성됩니다.
이 링크는 배송 서비스 범위에 추가되어 결제 오류가 배송 프로세스에 어떤 영향을 미치는지 추적할 수 있습니다.
SigNoz와 같은 도구를 사용하여 이러한 오류를 시각화하면 문제의 근본 원인을 훨씬 쉽게 식별할 수 있습니다.
실제 사용 사례: Span Link를 사용하여 다중 서비스 아키텍처 전반에서 고객 상호 작용 추적
실제 시나리오를 살펴보겠습니다. 주문과 같은 고객 작업이 주문 서비스, 재고 서비스, 결제 서비스, 배송 서비스
등 여러 서비스에 의해 처리되는 전자상거래 플랫폼을 상상해 보세요.단일 주문을 하는 사용자는 각 서비스마다 하나씩 여러 범위를 생성할 수 있습니다.
이제 이러한 범위는 일반적으로 주문 서비스가 결제 서비스의 상위가 될 수 있는 상위-하위 관계로 배열됩니다. 하지만 좀 더 복잡한 관계를 추적하고 싶다면 어떻게 해야 할까요?
예를 들어 Inventory Service가 결제 확인 후 독립적으로 재고 수준을 확인하는 경우 Payment Service의 직계 하위 서비스가 아닙니다. 스팬 링크를 사용하면 이러한 서비스를 직접 연결할 수 있으므로 서비스가 상호 작용하는 방식을 보다 정확하게 파악할 수 있습니다.
복잡한 아키텍처에서 스팬 링크가 중요한 이유
스팬 링크는 이러한 비선형 상호 작용을 캡처할 수 있는 유연성을 제공하여 서비스 전반에 걸친 사용자 작업에 대한 포괄적인 보기를 제공합니다. 이는 재고 확인으로 인한 배송 지연과 같은 사용자 경험 문제를 해결하는 데 특히 유용합니다.
Span Link가 서버리스 또는 이벤트 기반 시스템에서 관측성을 향상시키는 방법
서버리스 또는 이벤트 기반 시스템에서 서비스는 분리된 방식으로 상호 작용하는 경우가 많습니다. 이벤트는 서비스가 서로 직접 알지 못하는 상태에서 작업을 트리거합니다.
예를 들어 결제 서비스의 이벤트는 이벤트 버스를 통해 재고 업데이트 서비스를 트리거할 수 있습니다. 이러한 서비스는 부모-자식 관계가 없기 때문에 전통적인 방법으로 추적하는 것이 어려울 수 있습니다.
서버리스용 스팬 링크 사용 방법
스팬 링크는 분리된 서비스 사이를 연결하는 역할을 할 수 있습니다. 이벤트가 한 서비스에서 생성되어 다른 서비스에서 소비되는 경우 원래 이벤트의 범위와 소비 서비스의 범위를 연결하는 범위 링크를 생성할 수 있습니다.
이렇게 하면 서버리스 기능이 독립적으로 실행되더라도 상호 작용의 전체 내용을 얻을 수 있습니다.
예: 결제 서비스가 결제 처리 후 대기열에 메시지를 보내고 이 메시지가 서버리스 아키텍처에서 주식 업데이트 기능을 트리거한다고 가정해 보겠습니다.
다음은 이러한 범위를 연결하는 방법에 대한 코드 조각입니다
from opentelemetry import trace # Initialize tracer tracer = trace.get_tracer("order-service") # Create a span in the payment service with tracer.start_as_current_span("payment-processing") as payment_span: try: # Simulate a payment process that raises an error process_payment() except Exception as e: payment_span.record_exception(e) payment_span.set_status(trace.Status(trace.StatusCode.ERROR, str(e))) # Capture the error trace and create a span link error_link = trace.Link(payment_span.get_span_context()) # Now in the shipping service, you can link this error trace with tracer.start_as_current_span("shipping-service", links=[error_link]) as shipping_span: # Handle the impact of the payment error here process_shipping()
이 설정을 사용하면 비동기식으로 작동하더라도 결제 처리부터 재고 업데이트까지 흐름을 추적할 수 있습니다.
시각화하면 서버리스 애플리케이션의 다양한 부분이 어떻게 상호 작용하는지 명확해 지므로 병목 현상이나 예상치 못한 지연을 진단하는 능력이 향상됩니다.
이 접근 방식이 관찰 가능성에 중요한 이유
기존 모니터링에서는 재고 업데이트가 느리다는 사실을 보여줄 수 있지만, 스팬 링크를 사용하면 업데이트를 촉발한 특정 결제 이벤트까지 지연을 추적할 수 있습니다.
이러한 수준의 통찰력은 시스템을 최적화하고 원활한 사용자 경험을 보장하는 데 매우 중요합니다.
스팬 링크는 분산 시스템에서 추적 상관 관계를 크게 향상시킬 수 있는 OpenTelemetry의 활용도가 낮은 강력한 기능입니다.
그렇다면 정확히 무엇을 의미하며 왜 관심을 가져야 합니까?
애플리케이션이 사용자 요청을 이행하기 위해 서로 통신하고 협력하는 다양한 서비스 및 프로세스의 네트워크라고 상상해 보십시오. 추적 간의 직접적인 상위-하위 관계가 현재 발생하는 복잡성을 제대로 포착하지 못하는 시나리오에 자주 직면하게 될 것입니다.
예를 들어, 백그라운드 작업이 사용자 작업에 의해 트리거된 이벤트를 처리하고 있거나 여러 서비스가 비동기적으로 함께 작동하는 경우 어떻게 될까요? 문제를 쉽게 해결하기 위해 스팬 링크가 필요한 곳입니다.
그럼 스팬 링크를 사용하면 어떤 이점이 있나요?
상위-하위 제약을 넘어서는 범위 관계:
스팬 링크를 사용하면 상위 및 하위 스팬의 일반적인 계층 구조에 얽매이지 않고 서비스 전반에 걸쳐 추적을 연결할 수 있습니다.
이 기능은 동시에 발생하는 이벤트를 연관시키거나 공통 컨텍스트를 공유하지만 직접적인 상위-하위 관계가 없는 경우에 특히 유용합니다. 예를 들어, 사용자 대상 서비스의 추적을 백그라운드 프로세스에 연결하면 사용자 작업이 시스템 성능에 어떤 영향을 미치는지 더 전체적으로 볼 수 있습니다.
디버깅 및 문제 해결을 개선하는 데 도움이 됩니다.
스팬 링크를 사용하면 특히 복잡한 워크플로 중에 다양한 서비스가 상호 작용하는 방식에 대해 더 풍부한 관점을 얻을 수 있습니다. 링크를 통해 어떤 범위가 관련되어 있는지 확인함으로써 다른 방법으로는 발견하기 어려울 수 있는 병목 현상, 오류 패턴 또는 성능 문제를 식별할 수 있습니다. 이는 스팬 링크를 여러 서비스에 걸쳐 있는 문제를 디버깅하기 위한 강력한 도구로 만듭니다.
비동기 시스템에서 더 나은 가시성을 제공합니다.
메시지 대기열이나 이벤트 기반 아키텍처를 사용하는 애플리케이션과 같이 비동기 처리에 의존하는 애플리케이션의 경우 스팬 링크는 매우 중요합니다.
작업이나 메시지가 다양한 서비스를 통해 흐르는 동안 수명 주기를 추적할 수 있습니다. 이를 통해 단일 이벤트가 전체 시스템에 미치는 영향을 이해하고 프로세스를 더 쉽게 최적화하고 개선할 수 있습니다.
간단히 말하면, 스팬 링크를 사용하면 애플리케이션 동작에 대해 더 연결되고 의미 있는 그림을 만들 수 있으므로 분산 시스템이 작동하는 방식에 대한 더 나은 관찰과 더 깊은 이해가 가능합니다.
스팬 링크를 효과적으로 활용하면 추적 상관관계를 강화하여 문제 해결 속도를 높이고 시스템 성능을 더욱 완벽하게 파악할 수 있습니다.
스팬 링크 및 관련 개념에 대한 공식 지침에 대해 더 자세히 알아보고 싶은 경우 다음 리소스가 연구에 유용할 것입니다.
OpenTelemetry Span 링크 문서
스팬 링크 생성 및 관리 방법을 이해하기 위한 참고 자료입니다. 지원되는 다양한 프로그래밍 언어의 예와 함께 범위 연결을 위한 API 사양을 다룹니다. 이는 스팬 링크가 내부적으로 어떻게 작동하는지에 대한 기술적 세부 사항을 이해하기 위한 훌륭한 출발점입니다.
OpenTelemetry 컨텍스트 전파
스팬 링크를 최대한 활용하려면 컨텍스트 전파를 이해하는 것이 중요하며, 이 문서에서는 추적 전반에 걸쳐 컨텍스트가 관리되는 방법에 대한 철저한 개요를 제공합니다. 분산된 서비스 전체에서 추적 데이터의 일관성을 보장하려는 경우 특히 유용합니다.
OpenTelemetry 샘플링 전략
스팬 링크를 구현할 때 샘플링이 추적에 어떤 영향을 미치는지 아는 것이 중요합니다. 문서의 이 섹션에서는 다양한 샘플링 전략을 구성하는 방법에 대한 자세한 지침을 제공하여 데이터 세분성과 성능 간의 올바른 균형을 맞추는 데 도움을 줍니다.
이러한 링크는 참조 및 실제 적용을 위한 귀중한 리소스이므로 OpenTelemetry의 추적 기능을 숙달하려는 모든 사람에게 필수적입니다. 이러한 리소스를 북마크에 추가하고 보다 복잡한 관찰 가능성 설정을 구축할 때 가이드로 사용하세요.
질문이나 추가 설명이 있으면 댓글로 남겨주세요.
위 내용은 openTelemetry 및 Signoz를 사용하여 스팬 링크로 추적 분석 마스터하기(실용 가이드, 2부)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!