OpenTelemetry로 컨텍스트 전파 추적하는 방법

OpenTelemetry로 컨텍스트 전파 추적하는 방법

 

추적에 대한 생각

OpenTelemetry용 AWS Distro 사용에 대한 실용적인 참고 사항

Unsplash의 Anne Nygård의 사진

Table of ContentsSummary
Trace context propagation
End to end trace
Dangling AWS Lambda traces
Conclusion
Resources

지금까지는 특정 프로그래밍 언어에 대해 논의하지 않고 OpenTelemetry 및 ADOT에 대해 일반적으로 이야기했습니다. 다음 게시물은 ADOT Python용 AWS 관리형 Lambda 계층을 기반으로 합니다. 결론은 일반적으로 다른 언어에서도 동일하다고 생각합니다.

이 게시물의 목표는 이전 게시물에서 설명한 것과 정확히 같습니다. AWS 서비스가 기본적으로 지원하지 않는 경우(예: AWS Kinesis 스트림을 사용하여) 추적 컨텍스트를 수동으로 전달할 수 있는 방법을 보여줍니다. 이번에는 AWS X-Ray가 아닌 OpenTelemetry를 사용하여 이 작업을 수행합니다(결과 추적을 검토하기 위해 X-Ray 콘솔을 사용할 것입니다).

이제 OpenTelemetry 수집기, 배포판에 대해 알고 ADOT과 ADOT의 차이점을 알 수 있게 되면 마침내 실용적인 부분에 대해 이야기할 수 있습니다.

이 주제에 대한 복습이 필요한 경우 Approaching OpenTelemetry를 검토하십시오.

OpenTelemetry로 추적 컨텍스트 전파를 시연하기 위해 다음과 같은 이유로 ADOT Python Lambda 계층 및 OpenTelemetry Python SDK를 사용할 것입니다.

• 이전 게시물에서 Python을 사용하여 X-Ray SDK로 추적 컨텍스트 전파를 시연했습니다. OpenTelemery에서 동일한 애플리케이션이 어떻게 보이는지 확인하는 것이 도움이 될 것이라고 생각했습니다.
• Python은 자동 계측을 지원하는 언어 중 하나입니다(Java는 또 다른 언어임). 배후에서 무슨 일이 일어나고 있는지 이해하려면 자동 계측과 수동 계측의 차이점을 강조하는 것이 중요합니다.

우리는 이전에 조사한 것과 동일한 애플리케이션 아키텍처를 사용할 것입니다.

OpenTelemetry로 추적하려는 분산 아키텍처

생산자 람다

가장 간단한 Producer 람다부터 시작합니다. 먼저 코드를 보여드리겠습니다.

생산자 람다 구현(자동 계측)

이 의심스러울 정도로 간단한 구현은 람다 함수에 대한 추적을 캡처할 뿐만 아니라 악기 에서 추적을 캡처합니다. boto3 라이브러리, ADOT Collector와의 상호 작용을 처리하고 추적을 AWS X-Ray로 내보냅니다. 이것은 자동 계측이 활성화되었을 때 ADOT Lambda 계층이 제공하는 서비스 수준입니다!

보다 구체적으로, 자동 계측을 활성화하려면 다음을 수행해야 합니다.

• 함수에 ADOT Lambda 계층을 추가합니다. 그러면 OpenTelemetry SDK, ADOT Collector, AWS 관련 확장 등이 설치됩니다.
• 추가하여 자동 계측 활성화 AWS_LAMBDA_EXEC_WRAPPER 변수 /opt/otel-instrument 값

무대 뒤에서 일어나는 모든 일을 이해하지 않더라도 이것은 이미 꽤 좋아 보입니다.

자동화된 계측 — 구조 추적

온전성 검사로 콘솔(모든 페이로드 포함)에서 Producer 기능을 호출하고 X-Ray 콘솔에서 결과 추적을 볼 수 있습니다.

캡처된 X-Ray 추적의 구조를 검토해 보겠습니다. 나중에 수동 계측으로 넘어갈 때 중요한 차이가 있을 것입니다.

X-Ray 서비스는 추적을 구성하는 작업 단위 간의 상위/하위 관계를 나타내기 위해 세그먼트 및 하위 세그먼트의 개념을 사용합니다. OpenTelemetry는 동일한 목적으로 범위 개념을 사용합니다. 상위 및 하위 범위가 있을 수 있습니다.
결과 추적을 보기 위해 X-Ray 콘솔을 사용하지만 이 게시물에서는 OpenTelemetry 용어를 사용할 것입니다.

처음 두 스팬은 AWS Lambda 서비스에 의해 추적에 추가됩니다. 이 두 범위가 캡처되어 X-Ray로 내보내지는 경우에도 ~ 전에 Producer 람다가 호출됩니다.

AWS Lambda는 이 두 범위를 내보냅니다. 곧장 엑스레이에. 작성 당시에는 AWS Lambda를 구성하고 Jaeger, Splunk 등과 같은 다른 원격 분석 백엔드를 지정할 수 있는 방법이 없습니다.
의미 — OpenTelemetry가 다른 원격 분석 백엔드로 구성된 경우 AWS Lambda 관련 스팬은 ~ 아니다 그곳으로 수출됩니다.

다음 producer-function span은 OpenTelemetry에 의해 캡처된 범위입니다. 이것은 자동 계측 시작 스크립트에 의해 생성된 범위입니다(기억 /opt/otel-instrument 우리가 설정한 스크립트 AWS_LAMBDA_EXEC_WRAPPER 환경 변수?).

우리가 선택하면 producer-function 스팬, 우리는 아이를 볼 것입니다 producing_messages 람다 함수에서 수동으로 생성한 span. AWS SQS 및 AWS Kinesis 서비스에도 두 가지 추가 범위가 있습니다. boto3 도서관. 자동 계측이 사용되면 시작 스크립트는 가장 일반적인 Python 라이브러리를 계측하여 해당 라이브러리에서 범위를 자동으로 캡처합니다. 참고 계측기 이것이 작동하려면 람다 함수와 함께 설치되고 패키지되어야 합니다. GitHub에서 지원되는 라이브러리의 전체 목록을 찾을 수 있습니다.

생산자 함수 추적

자동 계측을 사용할 때 어떤 일이 일어나는지 더 잘 알 수 있기를 바랍니다. 다음 람다로 넘어갑시다.

소비자 SQS Lambda 함수

이 함수는 SQS 메시지에서 추적 컨텍스트를 추출하고 함수에 의해 생성된 새 범위가 메시지에 대한 원래 추적을 "계속"하도록 해야 합니다. 다시 말하지만, 우리는 이 람다에 대해 자동 계측을 사용하고 있습니다. 구현은 다음과 같습니다.

Producer 람다와 마찬가지로 OpenTelemetry 구성에 너무 신경 쓸 필요가 없습니다. 우리는 추출 traceId 그리고 spanId SQS 메시지의 필드 — 이 부분은 X-Ray를 사용한 이전 추적 전파 예제와 동일합니다. 그래도 언급할 가치가 있는 몇 가지 사항이 있습니다.

서버 스팬 종류
또 다른 흥미로운 세부 사항은 특별한 SERVER 우리가 할당하는 스팬 종류 consuming_sqs 기간. 이는 X-Ray 서비스 맵에서 이 범위를 별도의 노드로 볼 수 있도록 하기 위해 필요합니다. 문서에 따르면:

종류의 범위만 Server X-Ray 세그먼트로 변환되고 다른 모든 범위는 X-Ray 하위 세그먼트로 변환됩니다.

OpenTelemetry 추적을 AWS X-Ray로 내보낼 계획이라면 이 모호한 세부 사항을 염두에 두십시오. 다른 원격 분석 백엔드를 사용하는 경우 다른 범위 종류가 유용할 수 있습니다.

스팬 링크
우리는 선택 사항을 추가합니다 links 매개변수를 생성할 때 consuming_sqs 기간.

아이디어는 간단합니다. 각 람다 호출은 다수의 추적하고 그것들을 상관시키는 방법을 갖는 것이 유용할 수 있습니다. 우리의 경우 SQS 서비스에 의해 트리거되는 람다 함수가 있습니다. 다음은 N개의 메시지 배치로 함수가 트리거될 때 관련된 추적입니다.

• Lambda 호출 추적. SQS 서비스가 람다 함수를 트리거하면 암시적 추적이 생성됩니다. 이것은 AWS X-Ray 콘솔에서 일반적으로 볼 수 있는 "기본" 추적입니다. AWS Lambda 서비스가 기본적으로 내보내는 두 개의 범위가 있습니다(위에서 자동 계측 추적 구조를 조사할 때 논의했습니다). 이 추적에는 람다 콜드 스타트 또는 SQS 메시지 처리를 시작하기 전에 발생하는 모든 범위가 포함될 수도 있습니다.
• SQS 메시지 추적 — 많으면 그들 중 N. 각 SQS 메시지는 다른 추적에 속할 수 있으며 메시지를 처리할 때 새 추적을 만드는 것이 아니라 원래 추적을 "계속"하기를 원한다는 것을 기억하십시오.

따라서 SQS 메시지를 처리할 때(메시지의 원래 추적에 범위 추가) Lambda 호출 추적에 대한 링크를 유지하려고 합니다. 이는 문제 해결 시나리오에 특히 유용할 수 있습니다.

범위/추적 간의 연결은 인과 관계를 표현하는 강력한 방법일 수 있습니다. X-Ray가 링크를 지원하지 않기 때문에(아직?) AWS X-Ray 콘솔에서 이러한 링크를 시연하기 어려울 것입니다. 다음 게시물에서는 동일한 OpenTelemetry 추적이 다른 원격 측정 백엔드(Jaeger)에서 어떻게 보이는지 보여주고 링크의 유용성을 시연할 것입니다.

소비자 Kinesis Lambda 함수

마지막 Kinesis 소비자 람다는 자동 계측(삭제 AWS_LAMBDA_EXEC_WRAPPER 환경 변수). 이것은 내가 ADOT 마법 없이 OpenTelemetry 지원을 추가하는 방법을 보여줄 것이기 때문에 좋은 것입니다. 주의해야 할 사항이 많이 있습니다.

OpenTelemetry 초기화를 단계별로 살펴보겠습니다.

추적자 공급자 초기화

가장 먼저 해야 할 일은 초기화하는 것입니다. 추적자 제공자 — 이것은 추적 수집을 처리하고 OpenTelemetry Collector로 내보내는 개체입니다. 공급자를 초기화할 때 X-Ray와 호환되는 ID 생성기를 지정하고(X-Ray 지원이 필요하지 않은 경우 필요하지 않음) 범위에 첨부하려는 기타 속성을 지정합니다. 이 예에서는 명시적 서비스 이름을 설정하고 다른 AWS Lambda 관련 속성(함수 ARN, 이름, 메모리/CPU 할당 등)을 캡처합니다.

Tracer Provider는 초기화만 가능합니다. 한번 — 다른 공급자를 설정하려고 하면 두 번째 호출이 무시됩니다.

다음 줄을 풀어 보겠습니다.

• add_span_processor - 범위를 등록합니다. 프로세서 추적자 공급자와 함께. 프로세서는 OpenTelemetry가 데이터를 내보내기 전에 사전 처리(예: 속성 또는 샘플 수정)하거나 데이터가 파이프라인을 성공적으로 통과하는지 확인하는 데 도움이 되는 구성입니다(예: 일괄 처리/재시도). 좋은 요약 OpenTelemetry 프로세서는 Collector GitHub 리포지토리에서 찾을 수 있습니다.
• BatchSpanProcessor — 배치 프로세서는 범위를 허용하고 배치에 배치합니다. 일괄 처리는 데이터를 더 잘 압축하고 데이터를 전송하는 데 필요한 나가는 연결 수를 줄이는 데 도움이 됩니다.
• OTLPSpanExporter — OTLP(OpenTelemetry protocol) 형식으로 스팬을 내보냅니다. 기본적으로 내보내기는 람다 코드와 함께 실행되는 로컬 ADOT 수집기 인스턴스에 연결합니다. 스팬을 추가로 전달하는 것은 ADOT 수집기의 책임입니다. 기본적으로 수집기는 AWS X-Ray 서비스에 전달하도록 구성되어 있습니다.

요약 - Tracer Provider는 다음을 사용하여 ADOT Collector에 대한 추적의 수집 및 내보내기를 관리합니다. BatchSpanProcessor 그리고 OTLPSpanExporter. 자동 계측이 활성화되면 이러한 모든 하위 수준 세부 정보가 숨겨지지만 이제 범위의 처리 및 내보내기를 완전히 제어할 수 있습니다. 향후 게시물에서 이 접근 방식을 사용하여 ADOT 람다 계층에서 제공하는 기능을 확장하고 추가 원격 분석 백엔드에 대한 지원을 추가하는 방법을 보여줍니다.

계속 진행:

이 라인은 다음을 위한 계측을 가능하게 합니다. boto3 API. 수동 계측의 경우 관심 있는 라이브러리를 계측하는 것은 우리의 책임입니다.

마지막으로 (말장난 의도), 다음 코드 블록을 보셨을 것입니다.

이는 처리되지 않은 예외의 경우에도 모든 범위가 ADOT 수집기로 올바르게 내보내지도록 하는 데 필요합니다. 이것은 다음과 같은 경우에 특히 중요합니다. BatchSpanProcessor 사용됨 — 수집기에 전달하기 전에 여러 범위를 함께 일괄 처리한다는 점을 기억하십시오. 없이 force_flush 호출 시 일부 범위가 손실될 수 있습니다(물론 이것이 가장 중요한 범위가 될 것입니다).

이거 야! 이제 OpenTelemetry 초기화 및 기본 구성에 대한 적절한 멘탈 모델이 있어야 하며 ADOT 람다 계층에서 제공하는 자동 및 수동 계측 모드의 차이점을 이해해야 합니다.

마무리하기 전에 Producer 람다 함수를 실행하고 결과적인 종단 간 추적을 확인해야 합니다.

이전 게시물과 달리 이 추적 전파 예제에서 사용한 "해킹"이나 지원되지 않는 API에 대해 알지 못합니다. 이것은 OpenTelemetry 사양에 따른 적절한 구현입니다. 더 좋은 점은 OpenTelemetry를 사용하여 종단 간 X-Ray 추적을 얻을 수 있다는 것입니다.

위에서 AWS Lambda 서비스에서 내보낸 스팬에 대해 간략히 살펴보았습니다. 이러한 범위는 X-Ray에서 전체 서비스 맵을 볼 때 명확하게 표시됩니다.

소비자 람다는 기본 종단 간 추적을 "계속"하는 OpenTelemetry 범위를 내보냅니다. 동시에 이러한 기능에 대해 AWS Lambda 서비스에서 내보낸 추적이 여전히 있습니다. 이러한 추적은 기본 종단 간 추적 또는 "댕글링"에서 분리됩니다. AWS Lambda와 AWS X-Ray 서비스 간의 직접 통합으로 인해 X-Ray 콘솔에서 볼 수 있습니다. OpenTelemetry와 함께 다른 원격 분석 백엔드를 사용하려는 경우 이러한 AWS Lambda 범위는 ~ 아니다 수출된다.

OpenTelemetry를 이벤트 기반 AWS 아키텍처에 통합하고 완전한 종단 간 추적을 얻는 방법을 보여줌으로써 이 게시물에서 많은 내용을 다루었습니다. 우리는 여전히 AWS X-Ray를 주요 원격 분석 백엔드로 사용하고 있지만 그렇게 할 필요는 없습니다. OpenTelemetry를 사용하면 추적을 다른 백엔드로 내보내거나 이벤트를 동시에 여러 백엔드로 내보낼 수 있습니다. 이것이 우리가 다음 게시물에서 할 일입니다. — 인기 있는 오픈 소스 분산 추적 백엔드인 Jaeger와 통합하는 방법을 보여 드리겠습니다.