OpenTelemetry 섹션 2: 기기 재제작

Sinatra와 함께 OpenTelemetry(Otel)를 사용하는 두 번째 부분에서 나는 Otel 버전으로 나의 Lightstep 기기를 교체할 것이다.기기를 업데이트하는 것 외에 Otel Collector와 Jaeger의 생산 실례도 배치했다.두 번째 부분의 목표는 제 세 개의 응용 프로그램이 테스트와 생산에서 로컬 Jaeger 실례와 Lightstep에 추적을 동시에 보내고 Jaeger를 개발 기간에 사용하는 Docker compose 작업 흐름에 포함시키는 것입니다.

Note: Be sure to also see part 3 of this series as some limitations talked about here no longer exist. I am leaving them in this part because they are a relevant part of my journey.

현재의 현실을 되새기다
이 단계를 준비하기 위해 상황을 되돌아보고 싶습니다.

내 테스트 GKE 환경에 미리 존재하는 Jaeger 실례를 배치했는데 이것은 1년여 전에 다른 프로젝트

의 일부로 설치된 것이다.

Otel collector 1대도 배치해 테스트를 진행하고 있으며, 현재 현지 Jaeger

만 운송

genebean/sinatra-otel-demo 테스트용으로 배치되었고 Otel collector

로 추적 운송 중

CITH는 Lightstep 기기를 설치하고 Lightstep proxy를 통해 테스트와 생산에서 Lightstep로 운송한다. 이 기기는 CITH Helm 도표

의 일부로 배치된다.

ABS와 NSPooler는 Lightstep 계기를 추가했지만 아직 어느 곳에서도 발송되지 않았다

아직 정식 Lightstep satellites

Otel collector를 프로덕션에 배치하지 않음

ABS와 NSPooler는 여전히 Apache Mesos에서 실행 중...그들은 곧 쿠베르네트스로 이사할 것이지만, 내가 추적을 실시하기 전

은 아니다.

도시.
처음에 했던 것처럼 CI Triage Helper(CITH) 애플리케이션을 사용하여 새로운 테스트를 시작하겠습니다.내가 이렇게 하는 이유는 그것이 우리의 가장 간단한 응용 프로그램이고 CI 파이프 밖에 있기 때문이다.이것은 실험을 직접 CI의 일부분으로 하는 것보다 훨씬 안전하게 한다.

보석.
이 전환의 첫 번째 단계는 ls-trace 의 Gemfile 를 OpenTelemetry의 위치로 바꾸는 것입니다.CITH의 경우 다음과 같은 내용이 추가됩니다.

gem 'opentelemetry-api', '~> 0.5.1'
gem 'opentelemetry-exporters-jaeger', '~> 0.5.0'
gem 'opentelemetry-instrumentation-restclient', '~> 0.5.0'
gem 'opentelemetry-instrumentation-sinatra', '~> 0.5.0'
gem 'opentelemetry-sdk', '~> 0.5.1'

프로비저닝config.ru의 첫 번째 변화는 수요를 간단한 ddtrace에서 모든 OTEL 구성 요소로 업데이트하는 것이다.

require 'opentelemetry-api'
require 'opentelemetry/exporters/jaeger'
require 'opentelemetry-instrumentation-restclient'
require 'opentelemetry-instrumentation-sinatra'
require 'opentelemetry-sdk'

config.ru의 변경 사항은 Lightstep의 구성 블록을 OTEL에 필요한 구성 블록으로 대체하는 것입니다.

가볍게 걷다

if ENV['CITH_LIGHTSTEP_TRACING_TOKEN']
  puts "CITH_LIGHTSTEP_TRACING_TOKEN was passed so tracing will be enabled."
  Datadog.configure do |c|
    c.use :sinatra
    c.use :mongo
    c.use :rest_client


    c.distributed_tracing.propagation_inject_style = [Datadog::Ext::DistributedTracing::PROPAGATION_STYLE_B3]
    c.distributed_tracing.propagation_extract_style = [Datadog::Ext::DistributedTracing::PROPAGATION_STYLE_B3]

    c.tracer tags: {
      'lightstep.service_name' => 'cith-api',
      'lightstep.access_token' => ENV['CITH_LIGHTSTEP_TRACING_TOKEN'],
      'service.version' => version,
        service_name: 'cith', host: jaeger_host, port: 6831
    }
  end
else
  puts 'No CITH_LIGHTSTEP_TRACING_TOKEN passed. Tracing is disabled.'
end

오텔 호텔

jaeger_host = ENV['JAEGER_HOST'] || 'localhost'

OpenTelemetry::SDK.configure do |c|
  c.use 'OpenTelemetry::Instrumentation::Sinatra'
  c.use 'OpenTelemetry::Instrumentation::RestClient'

  c.add_span_processor(
    OpenTelemetry::SDK::Trace::Export::SimpleSpanProcessor.new(
      OpenTelemetry::Exporters::Jaeger::Exporter.new(
        service_name: 'cith', host: jaeger_host, port: 6831
      )
    )
  )
end

이 구성 블록에는 MongodB에 대한 내용이 없습니다.이것은 ddtrace에서 위치를 이식하지 않았기 때문이다issue #257.

걸출하다
여기서 또 다른 차이점은 경계가 Jaeger 에이전트로 출력되는 것이다.UDP를 통해지금까지 OpenTelemetry for ruby가 보유한 유일한 수출 업체다.현재 다른 조치를 적극적으로 실시하고 있지만, 동시에 이것은 UDP 데이터를 처리하는 추가 절차를 취해야 한다는 것을 의미한다. 왜냐하면 이것은 실제적으로 로컬 호스트로 전송되는 것으로 설계되었기 때문이다.나중에 자세히 설명할게요.

docker compose를 통해 로컬 개발을 진행합니다.yml
우리의 많은 응용 프로그램과 마찬가지로 CITH는 로컬 개발과 테스트를 편리하게 하기 위해 docker-compose.yml 응용 프로그램을 제공했다.CITH의 경우 Lightstep에서 Otel로 전환하려면 파일을 변경해야 합니다.

수신된 환경 변수 목록이 Jaeger 호스트 주소로 업데이트됨

Lightstep 에이전트가 Jaeger 올인원 인스턴스

로 교체

완성근데 진짜 아니에요.
이로써 CITH에 대한 모든 코드 변경이 완료되었고 로컬에서 테스트하기 쉽다.문제는 CITH를 OpenTelemetry로 이전하는 데 있어서 이 길은 이미 끝났다는 것이다. 키맵은 여전히 업데이트가 필요하고 더 많은 인프라 시설을 배치해야 한다.

도표
새로운 버전의 CITH를 배치하고 모든 것이 예상대로 작동하는지 검증하기 위해서, Lightstep에 종적을 발사하기 위해, 헬멧 도표를 통해 Lightstep 위성을 배치해야 한다.Jaeger 인스턴스와 함께 프로덕션 환경에 배포해야 합니다.이 문제를 해결하는 방법은 CITH의 도표를 업데이트하는 것이다. 이렇게 하면 데이터를 Otel collector로 전송한 다음에 위성을 배치한 다음에 Lightstep의 collector를 업데이트하고, 마지막으로 현재의 Jaeger를 업그레이드하고, 최초의 Jaeger를 생산에 배치할 수 있다.

도시 조타도
CITH의 도표는 사실 매우 간단하다. Lightstep과 관련된 모든 부분을 삭제하고 API의pod에 Jaeger sidecar를 추가하기만 하면 된다.sidecar는localhost에 보내는 기록도를 수집한 후 gRPC를 통해 OTEl 수집기에 보낼 수 있습니다.다음은 제가 Jaeger 에이전트에 추가한 플래그입니다.

args:
  - --reporter.grpc.host-port={{ .Values.jaeger_host }}:14250
  - --reporter.type=grpc
  - --jaeger.tags=helm_chart={{ include "dio-cith.chart" . }},service.version={{ .Chart.AppVersion }}

이러한 args 항목을 분해하려면 다음과 같이 하십시오.

첫 번째와 두 번째 조합은 gRBC를 통해 기록도를 OTEL 수집기

의 Jaeger 입력단에 전송한다

세 번째는 OTEL 속성으로 변환된 탭

을 추가했습니다.

왜 옆차를 하나 더 넣어야 합니까?
제가 전에 말씀드렸던 Jaeger exporter가 실제로localhost에 보내는 데만 사용되는 거 기억나세요?이것이 바로 우리가 옆차를 필요로 하는 원인 중의 하나다.또 다른 이유는 옆차를 사용하지 않고 service.version라는 라벨을 추가할 수 있는 방법이 없다는 것이다.이 기능은 복구할 작업#312에 따라 이루어졌지만, 지금부터 그때까지 내가 할 수 있는 일이다.

위성 배치
내가 이 단계를 시작했을 때, Lightstep의 키맵 #1 은 저장소가 없었다.다행히도 Lightstep의 우수한 직원들이 이 점을 바로잡기를 원해서 현재Artifact HUB와 Helm Hub 모두 사용할 수 있다.나는 기본적으로'방금 작용했다'는 그들의 도표를 배치했다. 유일한 예외는 프로메테우스 statsd 수출 업체와 합작하기 위해statsd 지표를 얻지 못했다는 것이다.지금은 위성을 감시하는 쪽을 포기하고 프로메테우스의 현지 지표를 실시하기를 바랄 뿐이다.이러한 모든 문서를 찾을 수 있습니다here.

컬렉터 출력
위성이 가동되고 운행됨에 따라, 내 수집기 설정에 Lightstep을 목적지로 추가할 때가 되었다.이렇게 하면 my exporters 부분에 추가하고 otlp/lightstep 파이프의 exporters 부분에 열거된 위치 그룹에 추가하는 것이 간단합니다.

otlp/lightstep:
  endpoint: "lightstep.lightstep.svc:8184"
  insecure: true
  headers:
    "lightstep-access-token": {{ .Values.lightstepAccessToken }}

OTLP 형식의 데이터를 포트 8184lightstep의 명칭 공간에 lightstep라는 서비스로 보내고 Lightstep에 필요한 항목과 일치하는 접근 영패를 포함하는 헤더를 추가하려면 내보내기를 설정하십시오.다행히도, 이것은 데이터를 Lightstep로 전송하는 데 필요한 모든 내용이다. 사용자 정의 내보내기나 다른 해커가 전혀 없다.

제이그 다시 하기
실제로 나는 이 단계가 두려웠지만 한 동료의 힌트 덕분에 이 단계는 매우 간단해졌다. 왜냐하면 Jaeger가 현재 jaeger 도표를 제공하여 창고viahttps://jaegertracing.github.io/helm-charts/를 배치하는 데 사용했기 때문이다.내 설정에 있어서 내가 해야 할 일은 바로 얕은 키맵을 만드는 것이다. 이 그림은 jaeger 도표를 의존항으로 하고 다음과 같은 values.yaml 파일을 포함한다.

jaeger:
  provisionDataStore:
    cassandra: false
    elasticsearch: true
  storage:
    type: elasticsearch
  agent:
    enabled: false
  collector:
    autoscaling:
      enabled: true
      minReplicas: 1
      maxReplicas: 3
  query:
    ingress:
      enabled: true
      annotations:
        certmanager.k8s.io/cluster-issuer: letsencrypt-prod
        kubernetes.io/ingress.class: nginx
        kubernetes.io/tls-acme: "true"
      hosts:
        - jaeger-test.k8s.example.net
      tls:
        - hosts:
            - jaeger-test.k8s.example.net
          secretName: jaeger-test.k8s.example.net-tls

전체 배포
이 모든 것이 준비된 후에, 나는 모든 것을 배치하여 테스트를 하고, 생산을 진행하였으며, Jaeger와 Lightstep에서 CITH에서 온 데이터를 볼 수 있었다🎉

ABS 및 NSPooler
이 점을 달성하는 데 걸리는 시간은 예상보다 길지만, 매우 효과가 있다. 왜냐하면 그것은 내가 계획한 모든 다른 일에 좋은 기초를 제공했기 때문이다.ABS와 NSPooler를 업데이트해서 사용합니다. 이것은 기본적으로 CITH에 대한 씻기와 중복이기 때문에 저는 여기서 세부 사항을 중복하지 않습니다.유일한 예외는, 그것들은 여전히 우리 Mesos 성단에서 운행하고 있기 때문에, 나는 그들의 종적을 보낼 곳이 필요하다.나는 이전에 정적 Docker 호스트로 설정된 호스트를 이용하여 이 문제를 해결했다.나는 단지 포트 6831/udp에서 감청하는 호스트에 Jaeger Agent를 간단하게 배치하고 CITH의Helm 도표에서 사용하는 기본과 같은 시작 파라미터를 제공할 뿐이다.이러한 작업은 puppetlabs/docker module 및 Hiera의 다음 항목에서 Puppet 코드를 사용하여 수행됩니다.

---
docker::run_instance::instance:
  jaeger-agent:
    image: 'jaegertracing/jaeger-agent:latest'
    ports:
      - '6831:6831/udp'
    command: '--reporter.grpc.host-port=otel-jgrpc-prod.k8s.example.net:443 --reporter.type=grpc --reporter.grpc.tls.enabled=true --reporter.grpc.tls.skip-host-verify=true'

이를 실현하기 위해서, 나는 Otel collector의 배치에 입구 자원을 추가해야 한다.입구는 이렇게 보인다.

{{- if .Values.ingress.enabled -}}
{{- $fqdn := .Values.ingress.protocol.jaegerGrpc.fqdn -}}
{{- $nameSuffix := .Values.ingress.protocol.jaegerGrpc.nameSuffix -}}
{{- $svcPortNumber := .Values.ingress.protocol.jaegerGrpc.svcPortNumber -}}
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: {{ include "dio-otel-collector.fullname" . }}-{{ $nameSuffix }}
  labels:
    {{- include "dio-otel-collector.labels" . | nindent 4 }}
  {{- with .Values.ingress.annotations }}
  annotations:
    {{- toYaml . | nindent 4 }}
    nginx.ingress.kubernetes.io/backend-protocol: "GRPC"
  {{- end }}
spec:
  tls:
    - hosts:
        - {{ $fqdn | quote }}
      secretName: {{ $fqdn }}-tls
  rules:
    - host: {{ $fqdn | quote }}
      http:
        paths:
          - path: /
            backend:
              serviceName: otel-collector
              servicePort: {{ $svcPortNumber }}
{{- end }}

이 입구의 유일한 특별한 점은 바로 이 선이다.

nginx.ingress.kubernetes.io/backend-protocol: "GRPC"

포털은 내 values.yaml 파일의 포털과 쌍을 이룹니다.

ingress:
  enabled: true
  annotations:
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
    kubernetes.io/ingress.class: nginx
    kubernetes.io/tls-acme: "true"
  protocol:
    jaegerGrpc: 
      fqdn: otel-jgrpc-test.k8s.example.net
      nameSuffix: jaeger-grpc
      svcPortNumber: 14250

이 회선은 gRPC를 실제 작업에 연결하는 데 필수적이다.그 외에도 다음과 같은 작업을 수행합니다.

스니퍼 포트 443

에서 TLS의 gRPC 연결

TLS 연결 수신 즉시 종료 및

암호화되지 않은 트래픽을 포트 14250의 otel-collector 서비스로 전달합니다.

이런 것들이 있으면 데이터도 ABS와 NSPooler에서 유출되기 시작한다!

다음은요?
이 시리즈의 3부는 opentelemetry-*gems의 0.6.0판이 발표될 때 어떻게 상황이 바뀌었고 더욱 좋아졌는지 소개할 것이다.추가 학습을 논의하고 추적 데이터를 보내는 것에 VMPooler를 추가할 것이다.