Seguimiento Distribuido Con OpenTelemetry, Spring Cloud Sleuth, Kafka

El seguimiento distribuido le brinda información sobre el rendimiento de un servicio en particular como parte del todo en un sistema de software distribuido. Realiza un seguimiento y registra las solicitudes desde su punto de origen hasta su destino y los sistemas por los que pasan.

En este artículo, implementaremos el rastreo distribuido en tres microservicios Spring Boot usando OpenTelemetry, Spring Cloud Sleuth, Kafka y Jaeger.

Primero echemos un vistazo a algunos de los términos básicos en el rastreo distribuido.

Span: Representa una sola unidad de trabajo dentro del sistema. Los tramos se pueden anidar unos dentro de otros para modelar la descomposición del trabajo. Por ejemplo, un tramo podría estar llamando a un extremo REST y otro tramo secundario podría ser ese extremo llamando a otro, y así sucesivamente en un servicio diferente.

Seguimiento: una colección de tramos que comparten el mismo tramo raíz o, más simplemente, poner todos los tramos que se crearon como resultado directo de la solicitud original. La jerarquía de tramos (cada uno con su propio tramo principal junto con el tramo raíz) se puede utilizar para formar gráficos acíclicos dirigidos que muestren la ruta de la solicitud a medida que avanza a través de varios componentes.

OpenTelemetry

OpenTelemetry , también conocido como OTel para abreviar, es un marco de observabilidad de código abierto independiente del proveedor para instrumentar, generar, recopilar y exportar datos de telemetría, como seguimientos , métricas y registros . Como proyecto de incubación de Cloud Native Computing Foundation (CNCF), OTel tiene como objetivo proporcionar conjuntos unificados de bibliotecas y API independientes del proveedor, principalmente para recopilar datos y transferirlos a algún lugar. OTel se está convirtiendo en el estándar mundial para generar y administrar datos de telemetría, y se está adoptando ampliamente.

Detective de nubes de primavera

Sleuth es un proyecto administrado y mantenido por el equipo de Spring Cloud destinado a integrar la funcionalidad de rastreo distribuido dentro de las aplicaciones Spring Boot. Se incluye como un paquete típico Spring Starter, por lo que con solo agregarlo como una dependencia, la configuración automática maneja toda la integración y la instrumentación en toda la aplicación. Aquí hay algunos instrumentos de Sleuth listos para usar:

  • solicitudes recibidas en los controladores Spring MVC (puntos finales REST)
  • solicitudes sobre tecnologías de mensajería como Kafka o MQ
  • solicitudes realizadas con RestTemplate, WebClient, etc.

Sleuth agrega un interceptor para garantizar que toda la información de rastreo se transmita en las solicitudes. Cada vez que se realiza una llamada, se crea un nuevo Span. Se cierra al recibir la respuesta.

Sleuth puede rastrear sus solicitudes y mensajes para que pueda correlacionar esa comunicación con las entradas de registro correspondientes. También puede exportar la información de seguimiento a un sistema externo para visualizar la latencia.

Jaeger

Jaeger fue creado originalmente por equipos de Uber y luego fue abierto en 2015. Fue aceptado como un proyecto de incubación nativo de la nube en 2017 y se graduó en 2019. Como parte de CNCF, Jaeger es un proyecto reconocido en arquitecturas nativas de la nube. Su código fuente está escrito principalmente en Go. La arquitectura de Jaeger incluye:

  • Bibliotecas de instrumentación
  • Coleccionistas
  • Servicio de consultas e interfaz de usuario web
  • Almacenamiento de base de datos

Similar a Jaeger, Zipkin también proporciona el mismo conjunto de componentes en su arquitectura. Aunque Zipkin es un proyecto más antiguo, Jaeger tiene un diseño más moderno y escalable. Para este ejemplo, hemos elegido a Jaeger como backend.

Diseño del sistema de rastreo

Diseñemos tres microservicios Spring Boot:

  • customer-service-bff: usando backend for frontendun patrón, este servicio se encuentra entre la interfaz de usuario y el backend. Lo llama una aplicación web de interfaz de usuario, que a su vez llama al servicio de atención al cliente de back-end a través de llamadas API REST.
  • customer-service: un simple servicio CRUD al cliente. Además de conservar los datos en su base de datos sobre las operaciones CRUD, también publica eventos en Kafka al crear, actualizar o eliminar un registro de cliente.
  • order-service: escucha el tema de Kafka, consume eventos creados/actualizados/eliminados por el cliente.

Los tres microservicios están diseñados para:

  • comunicarse a través de la API REST ( customer-service-bffy customer-service)
  • comunicarse a través de pub/sub basado en eventos a través de Kafka ( customer-servicey order-service)

Esto es para observar cómo OpenTelemetry combinado con Spring Cloud Sleuth maneja la instrumentación automática del código y genera y transmite los datos de seguimiento. Las líneas punteadas de arriba capturan la ruta de los datos de rastreo, exportados por los microservicios, viajan a OpenTelemetry Collector a través de OTLP (OpenTelemetry Line Protocol) y, a su vez, Collector procesa y exporta los datos de rastreo al backend Jaeger para almacenarlos y consultarlos.

Usando un monorepo, tenemos la estructura del proyecto de la siguiente manera:

Paso 1: agregar dependencias de POM

Esta es la clave para implementar el rastreo distribuido utilizando OTel y Spring Cloud Sleuth. Nuestro objetivo es no tener que instrumentar manualmente nuestro código, por lo que confiamos en estas dependencias para hacer aquello para lo que están diseñadas: instrumentar automáticamente nuestro código, además de rastrear la implementación, exportar datos de telemetría a OTel Collector, etc.


<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>${spring-cloud.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-sleuth-otel-dependencies</artifactId>
            <version>${spring-cloud-sleuth-otel.version}</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-sleuth</artifactId>
        <exclusions>
            <exclusion>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-sleuth-brave</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-sleuth-otel-autoconfigure</artifactId>
    </dependency>
    <dependency>
        <groupId>io.opentelemetry</groupId>
        <artifactId>opentelemetry-exporter-otlp-trace</artifactId>
    </dependency>
</dependencies>
  • spring-cloud-dependencies: Dependencias de Spring Cloud
  • spring-cloud-sleuth-otel-dependencies: Spring Cloud Sleuth Dependencias de OpenTelemetry
  • spring-cloud-starter-sleuth: Sleuth se integra con el rastreador OpenZipkin Brave a través del puente que está disponible en el spring-cloud-sleuth-bravemódulo. Como no estamos usando Zipkin para el back-end, tenemos que excluir spring-cloud-sleuth-bravede la spring-cloud-starter-sleuthdependencia y, en su lugar, agregar la spring-cloud-sleuth-otel-autoconfiguredependencia. Esto reemplaza la implementación de seguimiento predeterminada basada en Brave con la implementación basada en OpenTelemetry.
  • opentelemetry-exporter-otlp-trace: este es el componente en Spring Cloud Sleuth OTel que envía rastros a un OpenTelemetry Collector.

Paso 2: Configuración de OpenTelemetry

Extremo de OpenTelemetry Collector

Para cada microservicio, debemos agregar la siguiente configuración application.yml(consulte el fragmento de código de muestra en la sección a continuación). spring.sleuth.otel.exporter.otlp.endpointes principalmente para configurar el punto final de OTel Collector. Le dice al exportador, Sleuth en nuestro caso, que envíe los datos de seguimiento a través de OTLP al punto final del recopilador especificado http://otel-collector:4317. El aviso otel-collectoren la URL del punto final proviene del servicio docker-compose para la otel-collectorimagen.

Muestreo probabilístico de datos de rastreo

spring.sleuth.otel.config.trace-id-ratio-basedLa propiedad define la probabilidad de muestreo de los datos de rastreo. Muestrea una fracción de trazas en función de la fracción entregada al muestreador. El muestreo de probabilidad permite a los usuarios de seguimiento de OpenTelemetry reducir los costos de recopilación de tramos mediante el uso de técnicas de muestreo aleatorio. Si la proporción es inferior a 1,0, algunos rastros no se exportarán. Para este ejemplo, configuraremos el muestreo para que sea 1.0, 100%.

Para conocer las propiedades adicionales de OTel Spring Cloud Sleuth, consulte las propiedades comunes de la aplicación .

spring:
  application:
    name: customer-service
  sleuth:
    otel:
      config:
        trace-id-ratio-based: 1.0
      exporter:
        otlp:
          endpoint: http://otel-collector:4317

Archivo de configuración de OpenTelemetry

Necesitamos un archivo de configuración de OTel otel-config.yamlen la raíz del proyecto. El contenido es el siguiente. Este archivo de configuración define los comportamientos de los receptores, procesadores y exportadores de OTel. Como podemos ver, definimos nuestros receptores para escuchar en gRPC y HTTP, procesadores que usan lote y exportadores como jaeger y registro.

extensions:
  memory_ballast:
    size_mib: 512
  zpages:
    endpoint: 0.0.0.0:55679

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:

exporters:
  logging:
    logLevel: debug
  jaeger:
    endpoint: jaeger-all-in-one:14250
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [ otlp ]
      processors: [ batch ]
      exporters: [ logging, jaeger ]
  extensions: [ memory_ballast, zpages ]

Paso 3: docker-compose para unir todo

Veamos los contenedores docker que necesitamos activar para ejecutar estos tres microservicios y observemos su seguimiento distribuido, los primeros tres microservicios se explican en la sección anterior.

  • customer-service-bff
  • customer-service
  • order-service
  • postgres-customer: base de datos paracustomer-service
  • postgres-order: base de datos paraorder-service
  • jaeger-all-in-one: imagen única que ejecuta todos los componentes back-end y la interfaz de usuario de Jaeger
  • otel-collector: el motor de seguimiento de OpenTelemetry, recibe, procesa y exporta los datos de seguimiento al backend
  • zookeeper: realice un seguimiento del estado de los nodos en el clúster de Kafka y mantenga una lista de temas y mensajes de Kafka
  • kafka: plataforma de procesamiento de transmisión de eventos pub/sub
services:

  customer-service-bff:
    image: customer-service-bff:0.0.1-SNAPSHOT
    ports:
      - "8080:8080"
    depends_on:
      - zookeeper
      - kafka

  customer-service:
    image: customer-service:0.0.1-SNAPSHOT
    ports:
      - "8081:8081"
    depends_on:
      - zookeeper
      - kafka
      - postgres-customer
    environment:
      - SPRING_DATASOURCE_JDBC-URL=jdbc:postgresql://postgres-customer:5432/customerservice
      - SPRING_DATASOURCE_USERNAME=postgres
      - SPRING_DATASOURCE_PASSWORD=postgres
      - SPRING_JPA_HIBERNATE_DDL_AUTO=update

  order-service:
    image: order-service:0.0.1-SNAPSHOT
    ports:
      - "8082:8082"
    depends_on:
      - zookeeper
      - kafka
      - postgres-order
    environment:
      - SPRING_DATASOURCE_JDBC-URL=jdbc:postgresql://postgres-order:5432/orderservice
      - SPRING_DATASOURCE_USERNAME=postgres
      - SPRING_DATASOURCE_PASSWORD=postgres
      - SPRING_JPA_HIBERNATE_DDL_AUTO=update

  postgres-customer:
    image: postgres
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_USER=postgres
      - POSTGRES_DB=customerservice

  postgres-order:
    image: postgres
    ports:
      - "5431:5431"
    environment:
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_USER=postgres
      - POSTGRES_DB=orderservice

  jaeger-all-in-one:
    image: jaegertracing/all-in-one:latest
    ports:
      - "16686:16686"
      - "14268"
      - "14250"

  otel-collector:
    image: otel/opentelemetry-collector:0.47.0
    command: [ "--config=/etc/otel-collector-config.yaml" ]
    volumes:
      - ./otel-config.yaml:/etc/otel-collector-config.yaml
    ports:
      - "1888:1888"   # pprof extension
      - "13133:13133" # health_check extension
      - "4317"        # OTLP gRPC receiver
      - "55670:55679" # zpages extension
    depends_on:
      - jaeger-all-in-one

  zookeeper:
    image: confluentinc/cp-zookeeper:latest
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000
    ports:
      - 22181:2181

  kafka:
    image: confluentinc/cp-kafka:latest
    depends_on:
      - zookeeper
    ports:
      - 29092:29092
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092,PLAINTEXT_HOST://localhost:29092
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT
      KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1

Corre docker-compose up -dpara que aparezcan los nueve contenedores:

Paso 4: Seguimiento de datos en acción

camino feliz

Ahora, lancemos nuestro customer-service-bff, el punto de entrada al flujo, para crear un nuevo cliente.

Inicie la interfaz de usuario de Jaeger http://localhost:16686/, busque por servicio customer-service-bff, haga clic en el Find Tracesbotón, esto es lo que vemos para crear el seguimiento del cliente: abarcó tres servicios, un total de seis, una duración de 82,35 ms.

Además de la vista de línea de tiempo de seguimiento (captura de pantalla anterior), Jaeger también proporciona una vista de gráfico (seleccione Trace Graphen el menú desplegable superior derecho):

El resultado del registro en la ventana acoplable para tres microservicios muestra el mismo ID de seguimiento, resaltado en rojo, y un ID de tramo diferente según el nombre de la aplicación (los nombres de las aplicaciones y sus ID de tramo correspondientes se resaltan en colores coincidentes). En el caso de customer-service, se pasa el mismo ID de intervalo desde la solicitud de la API de REST a la solicitud del editor de Kafka.

Escenario de error

Hagamos una pausa en nuestra customer-servicebase de datos PostgreSQL en la ventana acoplable y repitamos el flujo de creación de clientes desde customer-service-bff. Lo conseguimos 500 internal server error, como era de esperar. Al verificar en Jaeger, vemos el siguiente seguimiento, con la excepción de stacktrace quejándose SocketTimeoutException, nuevamente como se esperaba.

Identificación de tramos de larga duración

La interfaz de usuario de Jaeger nos permite buscar rastros que superen la duración máxima especificada. Por ejemplo, podemos buscar todas las trazas que hayan tardado más de 1000 ms. Luego, podemos profundizar en los rastros de ejecución prolongada para investigar sus causas principales.

Resumen

Desempaquetamos el rastreo distribuido en la lente de OpenTelemetry, Spring Cloud Sleuth y Jaeger en esta historia, verificando la instrumentación automática del rastreo distribuido en las llamadas API REST y Kafka pub/sub. Espero que esta historia le brinde una mejor comprensión de estos marcos y herramientas de seguimiento, especialmente OpenTelemetry, y cómo cambia fundamentalmente la forma en que hacemos la Observabilidad en los sistemas distribuidos.

El código fuente de esta historia se puede encontrar en mi repositorio de GitHub .

¡Feliz codificación!

Esta historia se publicó originalmente en https://betterprogramming.pub/distributed-tracing-with-opentelemetry-spring-cloud-sleuth-kafka-and-jaeger-939e35f45821

#jaeger #opentelemetry #spring #cloud #kafka 

Seguimiento Distribuido Con OpenTelemetry, Spring Cloud Sleuth, Kafka

OpenTelemetry、Spring Cloud Sleuth、Kafka、およびJaegerを使用した分散トレース

分散トレースは、特定のサービスが分散ソフトウェアシステム全体の一部としてどのように実行されているかについての洞察を提供します。発信元から宛先、および通過するシステムまでのリクエストを追跡および記録します。

この記事では、OpenTelemetry、Spring Cloud Sleuth、Kafka、およびJaegerを使用して、3つのSpringBootマイクロサービスに分散トレースを実装します。

まず、分散トレースの基本的な用語のいくつかを見てみましょう。

スパン:システム内の単一の作業単位を表します。スパンを相互にネストして、作業の分解をモデル化できます。たとえば、あるスパンがRESTエンドポイントを呼び出し、別の子スパンがそのエンドポイントが別のエンドポイントを呼び出すようにし、以下同様に別のサービスで行うことができます。

トレース:すべてが同じルートスパンを共有するスパンのコレクション、またはより単純に、元のリクエストの直接の結果として作成されたすべてのスパンを配置します。スパンの階層(それぞれがルートスパンに沿って独自の親スパンを持つ)を使用して、さまざまなコンポーネントを通過する際のリクエストのパスを示す有向非巡回グラフを作成できます。

OpenTelemetry

OpenTelemetryは、略してOTelとも呼ばれ、トレースメトリックログなどのテレメトリデータを計測、生成、収集、およびエクスポートするための、ベンダーに依存しないオープンソースの可観測性フレームワークです。Cloud Native Computing Foundation(CNCF)のインキュベーションプロジェクトとして、OTelは、主にデータを収集してどこかに転送するために、ベンダーに依存しないライブラリとAPIの統合セットを提供することを目指しています。OTelは、テレメトリデータを生成および管理するための世界標準になりつつあり、広く採用されています。

Spring Cloud Sleuth

Sleuthは、SpringBootアプリケーション内に分散トレース機能を統合することを目的としたSpringCloudチームによって管理および保守されているプロジェクトです。これは一般的なものとしてバンドルされているSpring Starterため、依存関係として追加するだけで、自動構成がアプリ全体のすべての統合とインストルメンテーションを処理します。すぐに使用できるSleuthインストゥルメントは次のとおりです。

  • Spring MVCコントローラー(RESTエンドポイント)で受信したリクエスト
  • KafkaやMQなどのメッセージングテクノロジーを介したリクエスト
  • RestTemplateWebClientなどで行われたリクエスト

Sleuthはインターセプターを追加して、すべてのトレース情報がリクエストで確実に渡されるようにします。呼び出しが行われるたびに、新しいスパンが作成されます。応答を受信すると閉じられます。

Sleuthはリクエストとメッセージを追跡できるため、その通信を対応するログエントリに関連付けることができます。トレース情報を外部システムにエクスポートして、遅延を視覚化することもできます。

イエーガー

Jaegerは元々Uberのチームによって構築され、2015年にオープンソースになりました。2017年にクラウドネイティブインキュベーションプロジェクトとして受け入れられ、2019年に卒業しました。CNCFの一部として、Jaegerはクラウドネイティブアーキテクチャで認められたプロジェクトです。そのソースコードは主にGoで書かれています。イエーガーのアーキテクチャには次のものが含まれます。

  • インストルメンテーションライブラリ
  • コレクター
  • クエリサービスとWebUI
  • データベースストレージ

Jaegerと同様に、Zipkinもそのアーキテクチャで同じコンポーネントのセットを提供します。Zipkinは古いプロジェクトですが、Jaegerはよりモダンでスケーラブルなデザインになっています。この例では、バックエンドとしてJaegerを選択しました。

トレースシステムの設計

3つのSpringBootマイクロサービスを設計しましょう。

  • customer-service-bffbackend for frontendパターンを使用して、このサービスはUIとバックエンドの間に配置されます。これはUIWebアプリによって呼び出され、UIWebアプリはRESTAPI呼び出しを介してバックエンドカスタマーサービスを呼び出します。
  • customer-service:シンプルなカスタマーCRUDサービス。CRUD操作時にデータベースにデータを保持するだけでなく、顧客レコードを作成、更新、または削除するときにイベントをKafkaに公開します。
  • order-service:Kafkaトピックをリッスンし、顧客が作成/更新/削除したイベントを消費します。

3つのマイクロサービスは次のように設計されています。

  • REST APIを介して通信する(customer-service-bffおよびcustomer-service
  • customer-serviceKafka(およびorder-service)を介したイベント駆動型のpub/subを介した通信

これは、OpenTelemetryとSpring Cloud Sleuthを組み合わせて、コードの自動インストルメンテーションを処理し、トレースデータを生成して送信する方法を観察するためのものです。上記の点線は、マイクロサービスによってエクスポートされたトレースデータのパスをキャプチャし、OTLP(OpenTelemetry Line Protocol)を介してOpenTelemetry Collectorに移動し、コレクターはトレースデータを処理してバックエンドJaegerにエクスポートし、保存してクエリを実行します。

モノレポを使用すると、次のようなプロジェクト構造になります。

ステップ1:POMの依存関係を追加する

これは、OTelとSpringCloudSleuthを使用して分散トレースを実装するための鍵です。私たちの目標は、コードを手動でインストルメントする必要がないため、これらの依存関係に依存して、設計されていることを実行します。実装のトレースに加えて、コードの自動インストルメンテーション、テレメトリデータのOTelコレクターへのエクスポートなどです。


<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>${spring-cloud.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-sleuth-otel-dependencies</artifactId>
            <version>${spring-cloud-sleuth-otel.version}</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-sleuth</artifactId>
        <exclusions>
            <exclusion>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-sleuth-brave</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-sleuth-otel-autoconfigure</artifactId>
    </dependency>
    <dependency>
        <groupId>io.opentelemetry</groupId>
        <artifactId>opentelemetry-exporter-otlp-trace</artifactId>
    </dependency>
</dependencies>
  • spring-cloud-dependencies:SpringCloudの依存関係
  • spring-cloud-sleuth-otel-dependencies:Spring CloudSleuthOpenTelemetryの依存関係
  • spring-cloud-starter-sleuth:Sleuthは、モジュールで使用可能なブリッジを介してOpenZipkinBraveトレーサーと統合されspring-cloud-sleuth-braveます。バックエンドにZipkinを使用していないため、依存関係から除外spring-cloud-sleuth-braveし、spring-cloud-starter-sleuth代わりに依存関係を追加する必要がありspring-cloud-sleuth-otel-autoconfigureます。これにより、 Braveに基づくデフォルトのトレース実装がOpenTelemetryに基づく実装に置き換えられます。
  • opentelemetry-exporter-otlp-trace:これは、OpenTelemetryCollectorにトレースを送信するSpringCloudSleuthOTelのコンポーネントです。

ステップ2:OpenTelemetryの構成

OpenTelemetryCollectorエンドポイント

マイクロサービスごとに、次の構成をに追加する必要がありますapplication.yml(以下のセクションのサンプルスニペットを参照)。spring.sleuth.otel.exporter.otlp.endpoint主にOTelCollectorエンドポイントを構成するためのものです。これは、エクスポーター(この場合はSleuth)に、OTLPを介して指定されたコレクターエンドポイントにトレースデータを送信するように指示しますhttp://otel-collector:4317。エンドポイントURLの通知otel-collectorは、画像のdocker-composeサービスからのotel-collectorものです。

データ確率サンプリングのトレース

spring.sleuth.otel.config.trace-id-ratio-basedプロパティは、トレースデータのサンプリング確率を定義します。サンプラーに与えられたフラクションに基づいて、トレースのフラクションをサンプリングします。確率サンプリングにより、OpenTelemetryトレースのユーザーは、ランダム化されたサンプリング手法を使用してスパン収集コストを削減できます。比率が1.0未満の場合、一部のトレースはエクスポートされません。この例では、サンプリングを1.0、100%に構成します。

その他のOTelSpringCloud Sleuthプロパティについては、一般的なアプリケーションプロパティを参照してください。

spring:
  application:
    name: customer-service
  sleuth:
    otel:
      config:
        trace-id-ratio-based: 1.0
      exporter:
        otlp:
          endpoint: http://otel-collector:4317

OpenTelemetry構成ファイル

otel-config.yamlプロジェクトルートにOTel構成ファイルが必要です。内容は以下の通りです。この構成ファイルは、OTelレシーバー、プロセッサー、およびエクスポーターの動作を定義します。ご覧のとおり、gRPCとHTTPでリッスンするようにレシーバーを定義し、バッチとエクスポーターをイェーガーとロギングとして使用するプロセッサーを定義しました。

extensions:
  memory_ballast:
    size_mib: 512
  zpages:
    endpoint: 0.0.0.0:55679

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:

exporters:
  logging:
    logLevel: debug
  jaeger:
    endpoint: jaeger-all-in-one:14250
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [ otlp ]
      processors: [ batch ]
      exporters: [ logging, jaeger ]
  extensions: [ memory_ballast, zpages ]

ステップ3:docker-すべて一緒に文字列を作成する

これらの3つのマイクロサービスを実行して分散トレースを観察するためにスピンアップする必要のあるDockerコンテナーを見てみましょう。最初の3つのマイクロサービスについては、上記のセクションで説明しています。

  • customer-service-bff
  • customer-service
  • order-service
  • postgres-customer:データベースcustomer-service
  • postgres-order:データベースorder-service
  • jaeger-all-in-one:すべてのJaegerバックエンドコンポーネントとUIを実行する単一のイメージ
  • otel-collector:OpenTelemetryトレースのエンジンであり、トレースデータを受信、処理、およびバックエンドにエクスポートします
  • zookeeper:Kafkaクラスター内のノードのステータスを追跡し、Kafkaトピックとメッセージのリストを維持します
  • kafka:pub/subイベントストリーミング処理プラットフォーム
services:

  customer-service-bff:
    image: customer-service-bff:0.0.1-SNAPSHOT
    ports:
      - "8080:8080"
    depends_on:
      - zookeeper
      - kafka

  customer-service:
    image: customer-service:0.0.1-SNAPSHOT
    ports:
      - "8081:8081"
    depends_on:
      - zookeeper
      - kafka
      - postgres-customer
    environment:
      - SPRING_DATASOURCE_JDBC-URL=jdbc:postgresql://postgres-customer:5432/customerservice
      - SPRING_DATASOURCE_USERNAME=postgres
      - SPRING_DATASOURCE_PASSWORD=postgres
      - SPRING_JPA_HIBERNATE_DDL_AUTO=update

  order-service:
    image: order-service:0.0.1-SNAPSHOT
    ports:
      - "8082:8082"
    depends_on:
      - zookeeper
      - kafka
      - postgres-order
    environment:
      - SPRING_DATASOURCE_JDBC-URL=jdbc:postgresql://postgres-order:5432/orderservice
      - SPRING_DATASOURCE_USERNAME=postgres
      - SPRING_DATASOURCE_PASSWORD=postgres
      - SPRING_JPA_HIBERNATE_DDL_AUTO=update

  postgres-customer:
    image: postgres
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_USER=postgres
      - POSTGRES_DB=customerservice

  postgres-order:
    image: postgres
    ports:
      - "5431:5431"
    environment:
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_USER=postgres
      - POSTGRES_DB=orderservice

  jaeger-all-in-one:
    image: jaegertracing/all-in-one:latest
    ports:
      - "16686:16686"
      - "14268"
      - "14250"

  otel-collector:
    image: otel/opentelemetry-collector:0.47.0
    command: [ "--config=/etc/otel-collector-config.yaml" ]
    volumes:
      - ./otel-config.yaml:/etc/otel-collector-config.yaml
    ports:
      - "1888:1888"   # pprof extension
      - "13133:13133" # health_check extension
      - "4317"        # OTLP gRPC receiver
      - "55670:55679" # zpages extension
    depends_on:
      - jaeger-all-in-one

  zookeeper:
    image: confluentinc/cp-zookeeper:latest
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000
    ports:
      - 22181:2181

  kafka:
    image: confluentinc/cp-kafka:latest
    depends_on:
      - zookeeper
    ports:
      - 29092:29092
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092,PLAINTEXT_HOST://localhost:29092
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT
      KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1

docker-compose up -d9つのコンテナすべてを起動するために実行します。

ステップ4:実際のデータのトレース

ハッピーパス

customer-service-bffそれでは、フローへのエントリポイントであるを起動して、新しい顧客を作成しましょう。

Jaeger UIを起動し、サービスhttp://localhost:16686/検索し、ボタンcustomer-service-bffをクリックしFind Tracesます。これが、顧客トレースの作成で表示されるものです。これは、3つのサービスにまたがり、合計で6にまたがり、期間は82.35ミリ秒です。

トレースタイムラインビュー(上のスクリーンショット)に加えて、イエーガーはグラフビュー(Trace Graph右上のドロップダウンで選択)も提供します。

3つのマイクロサービスのDockerのログ出力には、同じトレースIDが赤で強調表示され、アプリ名に応じてスパンIDが異なります(アプリケーション名と対応するスパンIDは一致する色で強調表示されます)。の場合customer-service、同じスパンIDがRESTAPIリクエストからKafkaパブリッシャーリクエストに渡されます。

エラーシナリオ

customer-serviceDockerでPostgreSQLデータベースを一時停止し、から顧客の作成フローを繰り返しますcustomer-service-bff500 internal server errorさすがに手に入れた。Jaegerをチェックインすると、次のトレースが表示されますが、例外のstacktraceがSocketTimeoutException、再び予想どおりに文句を言っています。

長期的なスパンの特定

Jaeger UIを使用すると、指定した最大期間よりも長いトレースを検索できます。たとえば、1000ミリ秒より長くかかったすべてのトレースを検索できます。次に、長時間実行されているトレースにドリルダウンして、それらの根本原因を調査できます。

概要

このストーリーでは、OpenTelemetry、Spring Cloud Sleuth、およびJaegerのレンズで分散トレースを解凍し、RESTAPI呼び出しとKafkapub/subの両方で分散トレースの自動インストルメンテーションを検証しました。このストーリーが、これらのトレースフレームワークとツール、特にOpenTelemetryについての理解を深め、分散システムでの可観測性の方法を根本的に変える方法を理解してくれることを願っています。

このストーリーのソースコードは、私のGitHubリポジトリにあります。

ハッピーコーディング!

このストーリーは、もともとhttps://betterprogramming.pub/distributed-tracing-with-opentelemetry-spring-cloud-sleuth-kafka-and-jaeger-939e35f45821で公開されました

#jaeger #opentelemetry #spring #cloud #kafka 

OpenTelemetry、Spring Cloud Sleuth、Kafka、およびJaegerを使用した分散トレース
Saul  Alaniz

Saul Alaniz

1654008564

Trace La Propagación Del Contexto Con OpenTelemetry

El objetivo de esta publicación es exactamente como se describe en la anterior : demostrar cómo podemos pasar manualmente el contexto de rastreo cuando los servicios de AWS no lo admiten de forma nativa (por ejemplo, con transmisiones de AWS Kinesis). Esta vez haremos esto con OpenTelemetry, no con AWS X-Ray (aunque vamos a usar la consola de X-Ray para revisar los rastros resultantes).

Seguimiento de la propagación del contexto

Ahora, cuando sepa acerca de los recopiladores y las distribuciones de OpenTelemetry y pueda distinguir la diferencia entre ADOT y ADOT , finalmente podemos hablar sobre aspectos prácticos.

Para demostrar la propagación del contexto de rastreo con OpenTelemetry, usaré la capa ADOT Python Lambda y OpenTelemetry Python SDK por las siguientes razones:

  • Usé Python en la publicación anterior para demostrar la propagación del contexto de seguimiento con X-Ray SDK. Pensé que sería beneficioso ver cómo se ve la misma aplicación con OpenTelemery
  • Python es uno de los lenguajes (Java es otro) que soporta la instrumentación automática . Es importante resaltar las diferencias entre la instrumentación automática y manual para comprender lo que sucede detrás de escena.

Usaremos la misma arquitectura de aplicación que examinamos antes:

La arquitectura distribuida que queremos rastrear con OpenTelemetry

Productor lambda

Comenzamos con Producer lambda, el más sencillo. Déjame mostrarte el código primero:

import os, json, uuid, logging
import boto3
# 1. Import 'trace' from 'opentelemetry' package
from opentelemetry import trace

# 2. Get the tracer for the current module
tracer = trace.get_tracer(__name__)

QUEUE_NAME = os.environ["QUEUE_NAME"]
STREAM_NAME = os.environ["STREAM_NAME"]

sqs = boto3.resource('sqs')
queue = sqs.get_queue_by_name(QueueName=QUEUE_NAME)
kinesis = boto3.client('kinesis')

def handler(event, context):
    # 3. Create a new span for the function
    with tracer.start_as_current_span('producing_messages'):
        data = str(uuid.uuid4())
        message = create_message(data)
        
        # 5. Create a child span for sending SQS message
        with tracer.start_as_current_span('producing_sqs'):
            queue.send_message(
                MessageBody=message
            )
        # 6. Create a child span for sending Kinesis record
        with tracer.start_as_current_span('producing_kinesis'):
            kinesis.put_record(
                StreamName=STREAM_NAME,
                Data=message,
                PartitionKey='string'
            )

def create_message(data):
    # 4. Serialize current span context and pass it along with the message
    context = trace.get_current_span().get_span_context()

    return json.dumps({
        # payload to support trace context propagation
        'traceId': context.trace_id,
        'spanId': context.span_id,
        # main payload of the message
        'data': data
    })

Implementación del productor lambda (instrumentación automática)

Esta implementación sospechosamente simple no solo captura los rastros de la función lambda, sino que también instrumenta y captura los rastros de boto3la biblioteca, maneja las interacciones con ADOT Collector y exporta los rastros a AWS X-Ray. ¡ Este es el nivel de servicio que brindan las capas ADOT Lambda cuando la instrumentación automática está habilitada!

Más específicamente, debe hacer lo siguiente para habilitar la instrumentación automática:

Incluso sin entender todo lo que sucede detrás de escena, esto ya se ve bastante bien.

Instrumentación automatizada: estructura de seguimiento

Como verificación de cordura, podemos invocar la función Producer en la consola (con cualquier carga útil) y ver el seguimiento resultante en la consola de X-Ray:

Revisemos la estructura de la traza de rayos X capturada: habrá una diferencia importante cuando pasemos a la instrumentación manual más adelante.

El servicio de rayos X utiliza los conceptos de segmento y subsegmento para denotar las relaciones padre/hijo entre las unidades de trabajo que componen la traza. OpenTelemetry utiliza un concepto de tramo con el mismo propósito: puede haber tramos primarios y secundarios.
Aunque usamos la consola X-Ray para ver los rastros resultantes, voy a usar los términos de OpenTelemetry en esta publicación.

El servicio AWS Lambda agrega los dos primeros intervalos al seguimiento. Es importante comprender que estos dos intervalos se capturan y exportan a X-Ray incluso antes de que se invoque nuestro Producer lambda.

AWS Lambda exporta estos dos tramos directamente a X-Ray. En el momento de escribir este artículo, no hay forma de configurar AWS Lambda y especificar otro backend de telemetría como Jaeger, Splunk, etc.
Una implicación: si OpenTelemetry está configurado con otro backend de telemetría, los intervalos específicos de AWS Lambda no se exportarán allí.

El siguiente producer-functionlapso es el lapso capturado por OpenTelemetry: este es el lapso que crea el script de inicio de instrumentación automática (¿recuerda ese /opt/otel-instrumentscript que configuramos como AWS_LAMBDA_EXEC_WRAPPERvariable de entorno?).

Si seleccionamos producer-functionintervalo, veremos el producing_messagesintervalo secundario que creamos manualmente en nuestra función lambda. También hay dos tramos adicionales para los servicios de AWS SQS y AWS Kinesis: estos se capturan de boto3la biblioteca. Cuando se utiliza la instrumentación automática, el script de inicio instrumenta las bibliotecas de Python más comunes para capturar automáticamente intervalos de ellas. Tenga en cuenta que los instrumentos deben instalarse y empaquetarse con su función lambda para que esto funcione. Puede encontrar la lista completa de bibliotecas admitidas en GitHub .

Rastreo de la función del productor

Espero que tenga una mejor idea de lo que sucede cuando se utiliza la instrumentación automática. Pasemos a la siguiente lambda.

Consumidor SQS Función Lambda

Esta función necesita extraer el contexto de seguimiento del mensaje de SQS y asegurarse de que los nuevos tramos generados por la función "continúen" el seguimiento original del mensaje. Nuevamente, estamos usando instrumentación automática para esta lambda. Aquí está la implementación:

import json, os
import boto3
from opentelemetry import trace
from opentelemetry.trace import NonRecordingSpan, SpanContext, SpanKind, TraceFlags, Link

# Initialize OpenTelemetry tracer
tracer = trace.get_tracer(__name__)

TOPIC_ARN = os.environ["TOPIC_ARN"]
sns = boto3.client('sns')

def handler(event, context):
    # Get current span context
    lambda_context = trace.get_current_span().get_span_context()

    for record in event["Records"]:
        body = json.loads(record["body"])
        # Extract trace context from SQS message fields
        ctx = get_parent_context(body["traceId"], body["spanId"])

        # Create a new span, passing extracted context as a parent.
        # This is the way to "continue" the original trace for the message.
        with tracer.start_as_current_span(
            'consuming_sqs',             # name of the span
            context=ctx,                 # context of the parent span
            kind=SpanKind.SERVER,        # kind of the span
            links=[Link(lambda_context)] # links to other spans
        ):
            sns.publish(
                TargetArn=TOPIC_ARN,
                Message=f"Data {body['data']} consumed from SQS queue"
            )

def get_parent_context(trace_id, span_id):
    parent_context = SpanContext(
        trace_id=trace_id,
        span_id=span_id,
        is_remote=True,
        trace_flags=TraceFlags(0x01)
    )
    return trace.set_span_in_context(NonRecordingSpan(parent_context))

Al igual que con Producer lambda, no necesitamos preocuparnos demasiado por la configuración de OpenTelemetry. Extraemos traceIdy spanIdcampos del mensaje SQS: esta parte es idéntica a nuestro ejemplo anterior de propagación de trazas con X-Ray . Sin embargo, hay algunas cosas que vale la pena mencionar.

Tipo de tramo del servidor
Otro detalle interesante es un SERVERtipo de tramo especial que asignamos al consuming_sqstramo. Esto es necesario para poder ver este tramo como un nodo separado en el mapa del servicio de rayos X. Según la documentación :

Tenga en cuenta que solo los tramos de tipo Serverse convierten en segmentos de rayos X, todos los demás tramos se convierten en subsegmentos de rayos X.

Tenga en cuenta este oscuro detalle si planea exportar seguimientos de OpenTelemetry a AWS X-Ray. Si usa otro backend de telemetría, otros tipos de tramos pueden ser útiles.

Enlaces
de tramo Tenga en cuenta que agregamos un linksparámetro opcional cuando creamos el consuming_sqstramo.

La idea es simple: cada invocación de lambda puede contribuir a múltiples rastros y puede ser útil tener una forma de correlacionarlos. En nuestro caso, tenemos una función lambda activada por el servicio SQS. Estos son los rastros involucrados cuando la función se activa con un lote de N mensajes:

  • Seguimiento de invocación de Lambda . Cuando el servicio SQS activa la función lambda, se crea un seguimiento implícito. Esta es la traza "predeterminada", la traza que normalmente ve en la consola de AWS X-Ray. Habrá dos intervalos que el servicio AWS Lambda emite de manera predeterminada (los discutimos anteriormente cuando examinamos la estructura de rastreo de instrumentación automática). Este seguimiento también puede incluir intervalos para el arranque en frío de lambda o cualquier cosa que suceda antes de que comencemos a procesar los mensajes de SQS.
  • Seguimientos de mensajes de SQS : como máximo N de ellos. Recuerde que cada mensaje SQS puede pertenecer a un seguimiento diferente y queremos "continuar" ese seguimiento original cuando procesamos el mensaje, no crear uno nuevo.

Por lo tanto, cuando procesamos el mensaje de SQS (agregando intervalos al seguimiento original del mensaje), nos gustaría mantener el enlace al seguimiento de invocación de Lambda; puede ser particularmente útil para escenarios de solución de problemas.

Los vínculos entre tramos/trazas pueden ser una forma poderosa de expresar la causalidad. Será difícil demostrar estos enlaces en la consola de AWS X-Ray, ya que X-Ray no admite enlaces (¿todavía?). En la próxima publicación, mostraré cómo se ve el mismo seguimiento de OpenTelemetry en un backend de telemetría diferente (Jaeger) y luego demostraré la utilidad de los enlaces.

Consumidor Función Kinesis Lambda

El último lambda del consumidor de Kinesis es el más complicado, principalmente debido al problema en la capa de Lambda administrada por AWS para ADOT Python que me obligó a abandonar la instrumentación automática (eliminar AWS_LAMBDA_EXEC_WRAPPERla variable de entorno). Esto es algo bueno, ya que demostraré cómo agregar compatibilidad con OpenTelemetry sin la magia de ADOT. Cuidado, hay muchas cosas para absorber:

import base64, json, os
import boto3
from opentelemetry import trace
from opentelemetry.trace import NonRecordingSpan, SpanContext, SpanKind, TraceFlags, Link

## Configures the Global Tracer Provider
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.resources import Resource, SERVICE_NAME
from opentelemetry.sdk.extension.aws.trace import AwsXRayIdGenerator
from opentelemetry.sdk.extension.aws.resource import AwsLambdaResourceDetector
trace.set_tracer_provider(TracerProvider(
    id_generator=AwsXRayIdGenerator(), 
    resource=Resource.create({ SERVICE_NAME: "consumer-kinesis-function" }).merge(AwsLambdaResourceDetector().detect())
))
## Export traces to ADOT collector (to support X-Ray)
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
trace.get_tracer_provider().add_span_processor(BatchSpanProcessor(OTLPSpanExporter()))
## Instrument
from opentelemetry.instrumentation.botocore import BotocoreInstrumentor
BotocoreInstrumentor().instrument()

tracer = trace.get_tracer(__name__)

TOPIC_ARN = os.environ["TOPIC_ARN"]
sns = boto3.client('sns')

def handler(event, context):
    try:
        lambda_context = trace.get_current_span().get_span_context()

        for record in event["Records"]:
            body = json.loads(base64.b64decode(record["kinesis"]["data"]))
            ctx = get_parent_context(body["traceId"], body["spanId"])

            with tracer.start_as_current_span(
                'consuming_kinesis', 
                context=ctx, 
                kind=SpanKind.SERVER, 
                links=[Link(lambda_context)]
            ):                
                sns.publish(
                    TargetArn=TOPIC_ARN,
                    Message=f"Data {body['data']} consumed from Kinesis stream"
                )
    finally:
        # This is necessary to send traces to the ADOT collector
        trace.get_tracer_provider().force_flush()

def get_parent_context(trace_id, span_id):
    # Parent Span Context
    parent_context = SpanContext(
        trace_id=trace_id,
        span_id=span_id,
        is_remote=True,
        trace_flags=TraceFlags(0x01)
    )
    return trace.set_span_in_context(NonRecordingSpan(parent_context))

Veamos la inicialización de OpenTelemetry paso a paso:

trace.set_tracer_provider(TracerProvider(
    id_generator=AwsXRayIdGenerator(), 
    resource=Resource.create({ SERVICE_NAME: "consumer-kinesis-function" }).merge(AwsLambdaResourceDetector().detect())
))

Inicializar proveedor de seguimiento

Lo primero que debemos hacer es inicializar el Proveedor de seguimiento : este es el objeto que maneja la recopilación de los seguimientos y la exportación a OpenTelemetry Collector. Cuando inicializamos el proveedor, especificamos un generador de ID compatible con X-Ray (no es necesario si no se necesita el soporte de X-Ray) y otros atributos que nos gustaría adjuntar a los intervalos. Para este ejemplo, establecemos un nombre de servicio explícito y capturamos otros atributos específicos de AWS Lambda (ARN de función, nombre, asignación de memoria/CPU, etc.)

El proveedor de Tracer se puede inicializar solo una vez ; si intenta configurar otro proveedor, se ignorará la segunda llamada.

Vamos a desenvolver la siguiente línea:

trace.get_tracer_provider().add_span_processor(BatchSpanProcessor(OTLPSpanExporter()))
  • add_span_processor: registra un procesador de intervalo con el proveedor de Tracer. El procesador es una construcción que OpenTelemetry introduce para preprocesar los datos antes de exportarlos (p. ej., modificar atributos o muestras) o ayuda a garantizar que los datos pasen con éxito por una canalización (p. ej., lote/reintento). Un buen resumen de los procesadores de OpenTelemetry se puede encontrar en el repositorio de Collector GitHub .
  • BatchSpanProcessor— el procesador por lotes acepta tramos y los coloca en lotes. El procesamiento por lotes ayuda a comprimir mejor los datos y reduce la cantidad de conexiones salientes necesarias para transmitir los datos
  • OTLPSpanExporter— exporta tramos en formato de protocolo OpenTelemetry (OTLP). De forma predeterminada, el exportador se conecta a la instancia local de ADOT Collector que se ejecuta junto con su código lambda. Es responsabilidad del recopilador ADOT reenviar más los tramos; de forma predeterminada, el recopilador está configurado para pasarlos al servicio AWS X-Ray.

Para recapitular: Tracer Provider gestiona la recopilación y exportación de los seguimientos a ADOT Collector mediante BatchSpanProcessory OTLPSpanExporter. Con la instrumentación automática habilitada, todos estos detalles de bajo nivel están ocultos, pero ahora tenemos un control total sobre el procesamiento y la exportación de los tramos. Usaré este enfoque en publicaciones futuras para demostrar cómo podemos ampliar las capacidades proporcionadas por las capas lambda de ADOT y agregar soporte para backends de telemetría adicionales.

Hacia adelante:

BotocoreInstrumentor().instrument()

Esta línea habilita la instrumentación para boto3API. Con la instrumentación manual es nuestra responsabilidad instrumentar las bibliotecas que nos interesan.

Finalmente (el juego de palabras pretendía), es posible que haya notado este bloque de código:

try:
    # ...
    # Removed for clarity
    # ...
finally:
    # This is necessary to send traces to the ADOT collector
    trace.get_tracer_provider().force_flush()

Esto es necesario para garantizar que todos los intervalos se exporten correctamente al recopilador ADOT, incluso en el caso de una excepción no controlada. Esto es particularmente importante cuando BatchSpanProcessorse usa; recuerde que agrupa varios tramos antes de enviarlos al recolector. Sin force_flushllamada, se pueden perder algunos de los tramos (y, por supuesto, estos serán los más importantes)

¡Eso es todo! Ahora debe tener un modelo mental decente de inicialización y configuración básica de OpenTelemetry y comprender las diferencias entre los modos de instrumentación automáticos y manuales proporcionados por la capa lambda de ADOT.

Seguimiento de extremo a extremo

Antes de terminar, debemos ejecutar la función Producer lambda y verificar el seguimiento de extremo a extremo resultante:

A diferencia de mi publicación anterior , no tengo conocimiento de ningún "hackeo" o API no compatible que haya usado en este ejemplo de propagación de seguimiento. Esta es una implementación adecuada de acuerdo con la especificación de OpenTelemetry. Aún mejor: podemos obtener trazas de rayos X de extremo a extremo con OpenTelemetry.

Trazas colgantes de AWS Lambda

Anteriormente mencionamos brevemente los tramos exportados por el servicio AWS Lambda. Estos tramos son claramente visibles cuando miramos el mapa de servicio completo en X-Ray:

Las lambdas de consumo emiten tramos de OpenTelemetry que "continúan" nuestro rastro principal de extremo a extremo. Al mismo tiempo, todavía tenemos rastros emitidos por el servicio AWS Lambda para estas funciones. Estos trazos están separados del trazo principal de extremo a extremo o "colgando". Son visibles en la consola de X-Ray debido a la integración directa entre AWS Lambda y los servicios de AWS X-Ray. Tenga en cuenta que si va a utilizar un backend de telemetría diferente con OpenTelemetry, estos intervalos de AWS Lambda no se exportarán.

Conclusión

Hemos cubierto mucho terreno en esta publicación al mostrar cómo integrar OpenTelemetry en arquitecturas de AWS basadas en eventos y obtener seguimientos completos de un extremo a otro. Seguimos usando AWS X-Ray como nuestro principal backend de telemetría, pero no tenemos que hacerlo: con OpenTelemetry tenemos una forma de exportar rastros a otro backend o evento a varios backends al mismo tiempo. Esto es lo que haremos en la próxima publicación: le mostraré cómo integrarse con Jaeger , un popular backend de rastreo distribuido de código abierto.

Fuente del artículo original en: https://betterprogramming.pub/trace-context-propagation-with-opentelemetry-b8816f2f065e

#jaeger 

Trace La Propagación Del Contexto Con OpenTelemetry

OpenTelemetryを使用したトレースコンテキストの伝播

この投稿の目的は、前の投稿で概説したとおりです。AWSサービスがこれをネイティブにサポートしていない場合(たとえば、AWS Kinesisストリームを使用)にトレースコンテキストを手動で渡す方法を示します。今回は、AWS X-RayではなくOpenTelemetryを使用してこれを行います(ただし、X-Rayコンソールを使用して結果のトレースを確認します)。

トレースコンテキストの伝播

OpenTelemetryのコレクター、ディストリビューションについて知っていて、ADOTADOTの違いがわかると、ついに実用的なビットについて話すことができます。

OpenTelemetryを使用したトレースコンテキストの伝播を示すために、次の理由でADOTPythonLambdaレイヤーOpenTelemetryPythonSDKを使用します。

  • 前回の投稿でPythonを使用して、X-RaySDKを使用したトレースコンテキストの伝播を示しました。OpenTelemeryで同じアプリケーションがどのように見えるかを確認することは有益だと思いました
  • Pythonは、自動インストルメンテーションをサポートする言語の1つです(Javaは別の言語です)。舞台裏で何が起こっているかを理解するには、自動計測と手動計測の違いを強調することが重要です。

以前に調べたものと同じアプリケーションアーキテクチャを使用します。

OpenTelemetryでトレースしたい分散アーキテクチャ

プロデューサーラムダ

私たちはプロデューサーラムダから始めます—最も簡単なものです。最初にコードをお見せしましょう:

import os, json, uuid, logging
import boto3
# 1. Import 'trace' from 'opentelemetry' package
from opentelemetry import trace

# 2. Get the tracer for the current module
tracer = trace.get_tracer(__name__)

QUEUE_NAME = os.environ["QUEUE_NAME"]
STREAM_NAME = os.environ["STREAM_NAME"]

sqs = boto3.resource('sqs')
queue = sqs.get_queue_by_name(QueueName=QUEUE_NAME)
kinesis = boto3.client('kinesis')

def handler(event, context):
    # 3. Create a new span for the function
    with tracer.start_as_current_span('producing_messages'):
        data = str(uuid.uuid4())
        message = create_message(data)
        
        # 5. Create a child span for sending SQS message
        with tracer.start_as_current_span('producing_sqs'):
            queue.send_message(
                MessageBody=message
            )
        # 6. Create a child span for sending Kinesis record
        with tracer.start_as_current_span('producing_kinesis'):
            kinesis.put_record(
                StreamName=STREAM_NAME,
                Data=message,
                PartitionKey='string'
            )

def create_message(data):
    # 4. Serialize current span context and pass it along with the message
    context = trace.get_current_span().get_span_context()

    return json.dumps({
        # payload to support trace context propagation
        'traceId': context.trace_id,
        'spanId': context.span_id,
        # main payload of the message
        'data': data
    })

プロデューサーラムダの実装(自動インストルメンテーション)

この疑わしいほど単純な実装は、ラムダ関数のトレースをキャプチャするだけでなく、ライブラリからトレースを計測してキャプチャboto3し、ADOT Collectorとの相互作用を処理し、トレースをAWSX-Rayにエクスポートします。これは、自動インストルメンテーションが有効になっている場合にADOTLambdaレイヤーが提供するサービスのレベルです。

具体的には、自動インストルメンテーションを有効にするには、次のことを行う必要があります。

舞台裏で起こっていることすべてを理解していなくても、これはすでにかなり良さそうです。

自動計装—トレース構造

健全性チェックとして、コンソールで(任意のペイロードを使用して)Producer関数を呼び出し、X線コンソールで結果のトレースを確認できます。

キャプチャされたX線トレースの構造を確認しましょう。後で手動計測に移るときに重要な違いがあります。

X線サービスは、セグメントサブセグメントの概念を使用して、トレースを構成する作業単位間の親子関係を示します。OpenTelemetryは、同じ目的でスパンの概念を使用します。親スパンと子スパンが存在する場合があります。X線コンソールを使用して結果のトレースを表示しますが、この投稿ではOpenTelemetryの用語を使用します。
 

最初の2つのスパンは、AWSLambdaサービスによってトレースに追加されます。プロデューサーラムダが呼び出されるであっても、これら2つのスパンがキャプチャされてX線にエクスポートされることを理解することが重要です。

AWS Lambdaは、これら2つのスパンをX-Rayに直接エクスポートします。執筆時点では、AWS Lambdaを設定し、Jaeger、Splunkなど
の別のテレメトリバックエンドを指定する方法はありません。含意— OpenTelemetryが別のテレメトリバックエンドで設定されている場合、AWSLambda固有のスパンはそこにエクスポートされません。

次のproducer-functionスパンは、OpenTelemetryによってキャプチャされたスパンです。これは、自動インストルメンテーション起動スクリプトによって作成されたスパンです(環境変数/opt/otel-instrumentとして設定したスクリプトを覚えていますか?)。AWS_LAMBDA_EXEC_WRAPPER

spanを選択すると、ラムダ関数で手動で作成しproducer-functionた子スパンが表示されます。producing_messagesAWSSQSサービスとAWSKinesisサービスにも2つの追加スパンがあります—これらはboto3ライブラリからキャプチャされます。自動インストルメンテーションを使用する場合、起動スクリプトは最も一般的なPythonライブラリをインストルメントして、それらからスパンを自動的にキャプチャします。これを機能させるには、インストルメンタをラムダ関数とともにインストールしてパッケージ化する必要があることに注意してください。サポートされているライブラリの包括的なリストはGitHubにあります。

プロデューサー関数トレース

自動計装が使用されたときに何が起こっているかについて、より良い理解が得られることを願っています。次のラムダに移りましょう。

コンシューマーSQSラムダ関数

この関数は、SQSメッセージからトレースコンテキストを抽出し、関数によって生成された新しいスパンがメッセージの元のトレースを「継続」することを確認する必要があります。繰り返しになりますが、このラムダには自動計測を使用しています。実装は次のとおりです。

import json, os
import boto3
from opentelemetry import trace
from opentelemetry.trace import NonRecordingSpan, SpanContext, SpanKind, TraceFlags, Link

# Initialize OpenTelemetry tracer
tracer = trace.get_tracer(__name__)

TOPIC_ARN = os.environ["TOPIC_ARN"]
sns = boto3.client('sns')

def handler(event, context):
    # Get current span context
    lambda_context = trace.get_current_span().get_span_context()

    for record in event["Records"]:
        body = json.loads(record["body"])
        # Extract trace context from SQS message fields
        ctx = get_parent_context(body["traceId"], body["spanId"])

        # Create a new span, passing extracted context as a parent.
        # This is the way to "continue" the original trace for the message.
        with tracer.start_as_current_span(
            'consuming_sqs',             # name of the span
            context=ctx,                 # context of the parent span
            kind=SpanKind.SERVER,        # kind of the span
            links=[Link(lambda_context)] # links to other spans
        ):
            sns.publish(
                TargetArn=TOPIC_ARN,
                Message=f"Data {body['data']} consumed from SQS queue"
            )

def get_parent_context(trace_id, span_id):
    parent_context = SpanContext(
        trace_id=trace_id,
        span_id=span_id,
        is_remote=True,
        trace_flags=TraceFlags(0x01)
    )
    return trace.set_span_in_context(NonRecordingSpan(parent_context))

プロデューサーラムダと同様に、OpenTelemetryの構成をあまり気にする必要はありません。SQSメッセージからフィールドを抽出traceIdします—この部分は、X線を使用した以前のトレース伝播の例と同じです。ただし、言及する価値のあることがいくつかあります。spanId

サーバースパンの種類
もう1つの興味深い詳細は、SERVERスパンに割り当てる特別なスパンの種類consuming_sqsです。これは、このスパンをX線サービスマップの個別のノードとして表示できるようにするために必要です。ドキュメントによると:

種類のスパンのみがX線セグメントに変換され、他のすべてのスパンはX線サブセグメントに変換されることに注意してください。Server

OpenTelemetryトレースをAWSX-Rayにエクスポートする場合は、このあいまいな詳細に注意してください。別のテレメトリバックエンドを使用する場合—他の種類のスパンが役立つ場合があります。

スパンリンクスパン
を作成するときにオプションのlinksパラメータを追加することに注意してくださいconsuming_sqs

考え方は単純です。各ラムダ呼び出しは複数のトレースに寄与する可能性があり、それらを相互に関連付ける方法があると便利な場合があります。この例では、SQSサービスによってトリガーされるラムダ関数があります。N個のメッセージのバッチで関数がトリガーされたときに関係するトレースは次のとおりです。

  • ラムダ呼び出しトレース。SQSサービスがラムダ関数をトリガーすると、暗黙のトレースが作成されます。これは「デフォルト」のトレースであり、AWSX-Rayコンソールに通常表示されるトレースです。AWS Lambdaサービスがデフォルトで出力するスパンは2つあります(自動インストルメンテーショントレース構造を調べたときに、上記で説明しました)。このトレースには、ラムダコールドスタートのスパンや、SQSメッセージの処理を開始する前に発生するすべてのスパンも含まれる場合があります
  • SQSメッセージトレース最大でN個。各SQSメッセージは異なるトレースに属している可能性があり、メッセージを処理するときに、新しいトレースを作成するのではなく、元のトレースを「継続」する必要があることに注意してください。

したがって、SQSメッセージを処理するとき(メッセージの元のトレースにスパンを追加するとき)、Lambda呼び出しトレースへのリンクを保持したいと思います。これは、シナリオのトラブルシューティングに特に役立つ場合があります。

スパン/トレース間のリンクは、因果関係を表現するための強力な方法である可能性があります。X-Rayはリンクをサポートしていないため(まだ?)、AWSX-Rayコンソールでこれらのリンクを示すことは困難です。次の投稿では、同じOpenTelemetryトレースが別のテレメトリバックエンド(Jaeger)でどのように見えるかを示し、リンクの有用性を示します。

コンシューマーキネシスラムダ関数

最後のKinesisコンシューマーラムダは、主にADOT PythonのAWSマネージドLambdaレイヤー問題により、自動インストルメンテーション(環境変数の削除)を放棄せざるを得なかったため、最もトリッキーなものです。ADOTマジックなしでOpenTelemetryサポートを追加する方法を示すので、これは良いことです。注意してください、吸収することがたくさんあります:AWS_LAMBDA_EXEC_WRAPPER

import base64, json, os
import boto3
from opentelemetry import trace
from opentelemetry.trace import NonRecordingSpan, SpanContext, SpanKind, TraceFlags, Link

## Configures the Global Tracer Provider
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.resources import Resource, SERVICE_NAME
from opentelemetry.sdk.extension.aws.trace import AwsXRayIdGenerator
from opentelemetry.sdk.extension.aws.resource import AwsLambdaResourceDetector
trace.set_tracer_provider(TracerProvider(
    id_generator=AwsXRayIdGenerator(), 
    resource=Resource.create({ SERVICE_NAME: "consumer-kinesis-function" }).merge(AwsLambdaResourceDetector().detect())
))
## Export traces to ADOT collector (to support X-Ray)
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
trace.get_tracer_provider().add_span_processor(BatchSpanProcessor(OTLPSpanExporter()))
## Instrument
from opentelemetry.instrumentation.botocore import BotocoreInstrumentor
BotocoreInstrumentor().instrument()

tracer = trace.get_tracer(__name__)

TOPIC_ARN = os.environ["TOPIC_ARN"]
sns = boto3.client('sns')

def handler(event, context):
    try:
        lambda_context = trace.get_current_span().get_span_context()

        for record in event["Records"]:
            body = json.loads(base64.b64decode(record["kinesis"]["data"]))
            ctx = get_parent_context(body["traceId"], body["spanId"])

            with tracer.start_as_current_span(
                'consuming_kinesis', 
                context=ctx, 
                kind=SpanKind.SERVER, 
                links=[Link(lambda_context)]
            ):                
                sns.publish(
                    TargetArn=TOPIC_ARN,
                    Message=f"Data {body['data']} consumed from Kinesis stream"
                )
    finally:
        # This is necessary to send traces to the ADOT collector
        trace.get_tracer_provider().force_flush()

def get_parent_context(trace_id, span_id):
    # Parent Span Context
    parent_context = SpanContext(
        trace_id=trace_id,
        span_id=span_id,
        is_remote=True,
        trace_flags=TraceFlags(0x01)
    )
    return trace.set_span_in_context(NonRecordingSpan(parent_context))

OpenTelemetryの初期化を段階的に説明しましょう。

trace.set_tracer_provider(TracerProvider(
    id_generator=AwsXRayIdGenerator(), 
    resource=Resource.create({ SERVICE_NAME: "consumer-kinesis-function" }).merge(AwsLambdaResourceDetector().detect())
))

トレーサープロバイダーの初期化

最初に行う必要があるのは、トレーサープロバイダーを初期化することです。これは、トレースの収集を処理し、OpenTelemetryコレクターにエクスポートするオブジェクトです。プロバイダーを初期化するときに、X線と互換性のあるIDジェネレーター(X線サポートが必要ない場合は不要)およびスパンにアタッチするその他の属性を指定します。この例では、明示的なサービス名を設定し、他のAWS Lambda固有の属性(関数ARN、名前、メモリ/ CPU割り当てなど)をキャプチャします

トレーサープロバイダーは一度だけ初期化できます—別のプロバイダーを設定しようとすると、2番目の呼び出しは無視されます。

次の行をアンラップしましょう:

trace.get_tracer_provider().add_span_processor(BatchSpanProcessor(OTLPSpanExporter()))
  • add_span_processor-スパンプロセッサをトレーサプロバイダに登録します。プロセッサーは、OpenTelemetryがデータをエクスポートする前に前処理するために導入する構成(属性やサンプルの変更など)、またはデータがパイプラインを正常に通過することを保証するのに役立ちます(バッチ/再試行など)。OpenTelemetryプロセッサの概要は、CollectorGitHubリポジトリにあります。
  • BatchSpanProcessor—バッチプロセッサはスパンを受け入れ、それらをバッチに配置します。バッチ処理は、データをより適切に圧縮し、データの送信に必要な発信接続の数を減らすのに役立ちます
  • OTLPSpanExporter—スパンをOpenTelemetryプロトコル(OTLP)形式でエクスポートします。デフォルトでは、エクスポーターはラムダコードと一緒に実行されているローカルADOTコレクターインスタンスに接続します。スパンをさらに転送するのはADOTコレクターの責任です。デフォルトでは、コレクターはスパンをAWSX-Rayサービスに渡すように設定されています。

BatchSpanProcessor要約すると—トレーサープロバイダーは、とを使用してトレースの収集とADOTコレクターへのエクスポートを管理しOTLPSpanExporterます。自動インストルメンテーションを有効にすると、これらの低レベルの詳細はすべて非表示になりますが、スパンの処理とエクスポートを完全に制御できるようになりました。今後の投稿でこのアプローチを使用して、ADOTラムダレイヤーによって提供される機能を拡張し、追加のテレメトリバックエンドのサポートを追加する方法を示します。

次に進む:

BotocoreInstrumentor().instrument()

この行により、boto3APIのインストルメンテーションが可能になります。手動インストルメンテーションでは、関心のあるライブラリをインストルメント化するのは私たちの責任です。

最後に(しゃれが意図した)、あなたはこのコードのブロックに気づいたかもしれません:

try:
    # ...
    # Removed for clarity
    # ...
finally:
    # This is necessary to send traces to the ADOT collector
    trace.get_tracer_provider().force_flush()

これは、未処理の例外が発生した場合でも、すべてのスパンがADOTコレクターに適切にエクスポートされるようにするために必要です。これは、を使用する場合に特に重要BatchSpanProcessorです。コレクターに転送する前に、複数のスパンをまとめてバッチ処理することに注意してください。電話をかけないforce_flushと、一部のスパンが失われる可能性があります(もちろん、これらが最も重要なスパンになります)

これです!これで、OpenTelemetryの初期化と基本構成の適切なメンタルモデルが得られ、ADOTラムダレイヤーによって提供される自動インストルメンテーションモードと手動インストルメンテーションモードの違いを理解する必要があります。

エンドツーエンドのトレース

まとめる前に、Producerラムダ関数を実行し、結果のエンドツーエンドトレースを確認する必要があります。

以前の投稿とは異なり、このトレース伝播の例で使用した「ハッキング」やサポートされていないAPIを認識していません。これは、OpenTelemetry仕様に従った適切な実装です。さらに良い—OpenTelemetryを使用してエンドツーエンドのX線トレースを取得できます。

ぶら下がっているAWSLambdaトレース

上記のAWSLambdaサービスによってエクスポートされたスパンについて簡単に触れました。X線で完全なサービスマップを見ると、これらのスパンがはっきりとわかります。

コンシューマーラムダは、メインのエンドツーエンドトレースを「継続」するOpenTelemetryスパンを放出します。同時に、これらの関数に対してAWSLambdaサービスによって発行されたトレースがまだあります。これらのトレースは、メインのエンドツーエンドトレースまたは「ぶら下がり」から切り離されます。AWSLambdaとAWSX-Rayサービスが直接統合されているため、X-Rayコンソールに表示されます。OpenTelemetryで別のテレメトリバックエンドを使用する場合、これらのAWSLambdaスパンはエクスポートされないことに注意してください。

結論

この投稿では、OpenTelemetryをイベント駆動型AWSアーキテクチャに統合し、完全なエンドツーエンドのトレースを取得する方法を示すことで、多くのことを説明しました。引き続きAWSX-Rayをメインのテレメトリバックエンドとして使用していますが、その必要はありません。OpenTelemetryを使用すると、トレースを別のバックエンドにエクスポートしたり、イベントを複数のバックエンドに同時にエクスポートしたりできます。これは、次の投稿で行うことです—人気のあるオープンソースの分散トレースバックエンドであるJaegerと統合する方法を紹介します。

元の記事のソース:https ://betterprogramming.pub/trace-context-propagation-with-opentelemetry-b8816f2f065e

#jaeger

OpenTelemetryを使用したトレースコンテキストの伝播
Saul  Alaniz

Saul Alaniz

1653994800

Introducción Al Inicio Rápido De Jaeger: Implementación En AWS

 Un problema con OpenTelemetry y X-Ray

En la publicación anterior , analizamos AWS Distro for OpenTelemetry (ADOT) y cómo usarlo para producir seguimientos en arquitecturas basadas en eventos. ADOT exporta los rastros a AWS X-Ray de forma predeterminada; lamentablemente, existen algunas limitaciones:

Como suele ser el caso en el mundo de OpenTelemetry, es posible cambiar la configuración predeterminada y exportar los seguimientos a un backend de seguimiento diferente . ¿Pero cuál usar?

Jaeger

Hay muchos backends de seguimiento que puede considerar para su plataforma de seguimiento, tanto comerciales como de código abierto. En esta publicación, me gustaría llamar su atención sobre Jaeger , un proyecto graduado de Cloud Native Computing Foundation (CNCF). Este es un sello de aprobación respetable, considerando otros proyectos graduados de CNCF. Solo por nombrar algunos: Kubernetes , Helm , Prometheus , Fluentd .

Jaeger es una plataforma de rastreo distribuida de extremo a extremo de código abierto. Al estilo nativo de la nube, Jaeger se puede implementar de varias maneras, por ejemplo:

El equipo de Jaeger creó una guía de implementación detallada que responde muchas preguntas sobre las funciones de los diferentes componentes de Jaeger ( servicios de agente , recopilador y consulta ), puntos de integración con otros servicios (Elasticsearch, Cassandra) y consideraciones de escala. Sin embargo, incluso con ese nivel de documentación técnica disponible, implementar una plataforma Jaeger lista para producción no es una hazaña menor.

Para implementaciones a gran escala, especialmente en el contexto de AWS, esperamos mucho de una solución bien diseñada, entre otras cosas:

  • Resistencia
  • Elasticidad
  • Observabilidad
  • Integración nativa con otros servicios de AWS
  • Implementaciones de IaC reproducibles y completamente automatizadas

El operador Jaeger Kubernetes ayuda con algunas de estas características, pero, de nuevo, necesita un clúster de Kubernetes para comenzar. ¿Qué pasa si no tienes uno? Poner en marcha (¡y mantener!) un nuevo clúster para albergar una plataforma de rastreo puede ser demasiado difícil y costoso (tanto en términos de costo como de experiencia).

Aquí va la pregunta principal de esta publicación: ¿cómo sería un "inicio rápido" de Jaeger en AWS?

Guías de inicio rápido de AWS: 101

Utilicé "inicio rápido" arriba por una razón: los inicios rápidos de AWS son " implementaciones de referencia automatizadas... [que] lo ayudan a implementar tecnologías populares en AWS de acuerdo con las prácticas recomendadas de AWS ". Esto es exactamente lo que busco con Jaeger en AWS.

AWS incluso proporciona la Guía del colaborador de inicio rápido para ayudar con la creación de los nuevos inicios rápidos. Sin profundizar demasiado en los detalles, permítanme decir que un inicio rápido es un conjunto de plantillas de CloudFormation .

Y debo admitir que estas plantillas tienen que ser sólidas . Citando la documentación, los requisitos arquitectónicos mínimos para un inicio rápido son:

  • Arquitectura Multi-AZ ( detalles )
  • Compatibilidad con la mayoría de las regiones de AWS ( detalles )
  • Nuevas VPC y opciones de implementación de VPC existentes ( detalles )
  • Instancias de productos en subredes privadas ( detalles )
  • Puertas de enlace NAT para acceso a Internet saliente desde subredes privadas ( detalles )
  • AMI de Marketplace siempre que sea posible; sin AMI preconfiguradas ( detalles )
  • asignaciones de AMI; sin AMI codificadas ( detalles )
  • Etiquetas y grupos de parámetros fáciles de usar ( detalles )
  • Bloqueo de bloque CIDR para acceso de administrador externo ( detalles )
  • Grupos de seguridad con principio de mínimo privilegio ( detalles )
  • Sin bits de software con implementación ( detalles )
  • Sin contraseñas codificadas ( detalles )
  • No hay datos confidenciales en los datos de usuario de la instancia EC2 u otro texto claro ( detalles )
  • No se usa 0.0.0.0/0 para el acceso de administración remota abierta ( detalles )
  • No se crean recursos automáticamente fuera de la pila ( detalles )

Una lista impresionante de hecho. Si usa cualquier Inicio rápido para implementar su infraestructura, puede estar seguro de que las plantillas son bastante buenas.

Otra cosa que me gusta especialmente del ecosistema Quick Starts es la modularidad . Si hay un inicio rápido que implementa una parte de la infraestructura que desea usar en su arquitectura (como el inicio rápido de VPC o el inicio rápido de Aurora PostgreSQL ), puede hacer referencia a una implementación existente. Es como hacer referencia a una biblioteca en Python o NodeJS, solo para sus plantillas de CloudFormation. Esta característica por sí sola es lo suficientemente innovadora como para cambiar su enfoque de IaC con CloudFormation.

Seamos honestos: ¿cuántas veces ha creado una plantilla para aprovisionar VPC, subredes, tablas de enrutamiento, puertas de enlace de Internet, puertas de enlace NAT, puntos finales...? ¿No me diga que no ha soñado con una implementación lista para usar que podría reutilizar sin reinventar esta rueda nuevamente? Ahora usted puede.

Una última cosa sobre los inicios rápidos (promesa). Las arquitecturas de inicio rápido pueden ser muy complejas, especialmente si considera el aspecto de modularidad que cubrimos anteriormente. Desarrollar y mantener plantillas de CloudFormation para un inicio rápido grande puede ser una tarea seria sin un marco sólido de pruebas automatizadas. El equipo de AWS Quick Start reconoció este desafío y presentó TaskCat :

TaskCatautomatiza el linting y las implementaciones de plantillas de CloudFormation en varias regiones de AWS. Significa que puede asegurarse de que sus plantillas, por complejas que sean, puedan implementarse con éxito en las regiones de destino (y eliminarse; este aspecto a menudo se descuida durante el desarrollo de CloudFormation).

Con TaskCatél es posible definir "pruebas", proporcionando diferentes parámetros a CloudFormation en el momento del despliegue. La herramienta también genera un informe de aprobación/rechazo que se puede integrar en su herramienta de CI/CD, para que pueda ejecutar las pruebas como parte de su proceso de validación de relaciones públicas.

Incluso si no va a utilizar AWS Quick Starts para su IaC, le recomiendo incorporar TaskCat en su flujo de trabajo para automatizar las pruebas de sus plantillas de CloudFormation.

Inicio rápido de Jaeger

NOTA: Este NO es un inicio rápido oficial de AWS . El proyecto está construido de acuerdo con la Guía del colaborador de inicio rápido, pero aún NO está aprobado por los equipos de AWS y Jaeger.

Ahora, una vez que definimos qué es un inicio rápido de AWS, permítanme finalmente presentarles el inicio rápido de Jaeger .

Jaeger Quick Start lo ayuda a implementar una Jaeger de alta disponibilidad : una plataforma de seguimiento distribuida integral y de código abierto en la nube de Amazon Web Services (AWS).

Puede utilizar las plantillas de AWS CloudFormation incluidas con el inicio rápido para implementar Jaeger en su cuenta de AWS en aproximadamente 10 a 30 minutos.

Este inicio rápido es para usuarios que desean una implementación de referencia repetible y personalizable para Jaeger mediante AWS CloudFormation . También puede utilizar las plantillas de AWS CloudFormation proporcionadas como punto de partida para su propia implementación.

Aquí hay un diagrama de arquitectura de alto nivel del inicio rápido:

Arquitectura sin servidor de Jaeger (con backend de Elasticsearch)

Los aspectos más destacados:

  • En lugar de ejecutar contenedores Jaeger en el clúster de Kubernetes (con la complejidad operativa asociada), Quick Start utiliza AWS Fargate , un motor informático sin servidor.
  • El inicio rápido implementa todos los componentes necesarios de Jaeger ( recopilador , consulta , trabajo de chispa de dependencia ) y los configura adecuadamente
  • Quick Start es compatible con dos backends de almacenamiento diferentes: clúster de Amazon OpenSearch para implementaciones de producción a gran escala y almacenamiento en memoria adecuado para experimentos y cargas de trabajo de prueba de concepto
  • El Quick Start implementa Network Load Balancer en subredes públicas de VPC para distribuir el tráfico y exponer los puertos Jaeger necesarios. El balanceador de carga puede estar orientado a Internet o interno, accesible solo para clientes de VPC
  • El inicio rápido proporciona opciones para asignar nombres DNS para la instancia de Jaeger. Se admiten las zonas alojadas públicas y privadas de Amazon Route 53 .
  • Quick Start se integra con AWS Certificate Manager para agregar TLS al Network Load Balancer
  • Quick Start admite la integración con Amazon Managed Service para Prometheus para exponer las métricas de Jaeger
  • El inicio rápido agrega una integración opcional con CloudWatch Container Insights para monitorear las métricas de los contenedores Jaeger que se ejecutan en Fargate

Puede encontrar una explicación detallada de las funciones, las decisiones arquitectónicas y la referencia completa de parámetros en la Guía de implementación de inicio rápido de Jaeger .

¿Que sigue?

Jaeger Quick Start es un proyecto nuevo: para la versión inicial me concentré en admitir dos backends de almacenamiento (OpenSearch e in-memory) y, por lo tanto, arquitecturas ligeramente diferentes. Preparé una hoja de ruta de inicio rápido de Jaeger y planteé una serie de problemas de GitHub para indicar a dónde quiero ir a continuación. Mi enfoque para el próximo hito sería la evaluación del rendimiento, el ajuste de los parámetros predeterminados y las mejoras en la documentación. Eventualmente, planeo agregar soporte para otro backend de almacenamiento Jaeger popular: Cassandra o, en el mundo de servicios administrados de AWS, Amazon Keyspaces .

Si tiene experiencia con la implementación y ejecución de Jaeger en AWS o desea contribuir de alguna manera, comuníquese con nosotros. ¡Las anécdotas y cualquier punto de dolor que encuentres son especialmente bienvenidos!

Sin embargo, antes de terminar la publicación, permítanme ubicar a Jaeger Quick Start en un contexto más amplio de esta serie , es decir, ¿cómo podría ser útil para nuestro viaje de OpenTelemetry con arquitecturas basadas en eventos?

Con una forma sencilla de implementar Jaeger en el entorno de AWS, puede complementar (o incluso reemplazar ) AWS X-Ray como su back-end de telemetría de destino para los seguimientos de aplicaciones. De hecho, puede usar Jaeger y AWS X-Ray juntos, ejecutarlos uno al lado del otro; de hecho, realmente recomendaría este enfoque para ver ambas plataformas en acción y tomar una decisión informada sobre cuál se adapta mejor a sus necesidades.

Y esto es exactamente lo que vamos a cubrir en la siguiente publicación: ejecutar ambas plataformas en paralelo, analizar los cambios de configuración de ADOT necesarios para admitir Jaeger, comparar los rastros resultantes y describir las principales diferencias entre las plataformas.

Recursos

Fuente del artículo original en: https://betterprogramming.pub/introducing-jaeger-quick-start-deploying-on-aws-f0ee5d398e8a

#jaeger #aws 

Introducción Al Inicio Rápido De Jaeger: Implementación En AWS

Jaegerクイックスタートの紹介—AWSへのデプロイ

 OpenTelemetryとX線の問題

前回の投稿では、AWS Distro for OpenTelemetry(ADOT)と、それを使用してイベント駆動型アーキテクチャでトレースを生成する方法について説明しました。ADOTはデフォルトでトレースをAWSX-Rayにエクスポートします—残念ながら、いくつかの制限があります。

OpenTelemetryの世界ではよくあることですが、デフォルトの構成を変更して、トレースを別のトレースバックエンドにエクスポートすることができます。しかし、どちらを使用しますか?

イエーガー

商用およびオープンソースの両方で、トレースプラットフォーム用に検討する必要のあるトレースバックエンドが多数あります。この投稿では、Cloud Native Computing Foundation(CNCF)を卒業したプロジェクトであるJaegerに注目したいと思います。これは、他のCNCF卒業プロジェクトを考慮すると、立派な承認の印です。ほんの数例を挙げると、 KubernetesHelmPrometheusFluentdです。

Jaegerは、オープンソースのエンドツーエンドの分散トレースプラットフォームです。真のクラウドネイティブ方式では、Jaegerは次のようなさまざまな方法で展開できます。

Jaegerチームは、さまざまなJaegerコンポーネント( AgentCollector、およびQueryサービス)の役割、他のサービス(Elasticsearch、Cassandra)との統合ポイント、およびスケーリングの考慮事項に関する多くの質問に答える詳細なデプロイメントガイドを作成しました。ただし、そのレベルの技術ドキュメントが利用可能であっても、本番環境に対応したJaegerプラットフォームを展開することは簡単なことではありません。

大規模なデプロイの場合、特にAWSのコンテキストでは、適切に設計されたソリューションに多くのことが期待されます。

  • 弾力性
  • 弾性
  • 可観測性
  • 他のAWSサービスとのネイティブ統合
  • 再現性のある、完全に自動化されたIaC展開

Jaeger Kubernetesオペレーターは、これらの特性のいくつかを支援しますが、それでも、最初にKubernetesクラスターが必要です。持っていない場合はどうなりますか?トレースプラットフォームをホストするために新しいクラスターをスピンアップ(および維持)することは、非常に困難で費用がかかる可能性があります(コストと経験の両方の観点から)。

この投稿の主な質問は次のとおりです。AWSでのJaegerの「クイックスタート」はどのようになりますか?

AWSクイックスタート— 101

上記の「クイックスタート」を使用した理由は、AWSクイックスタートは「自動化されたリファレンスデプロイ…[AWSのベストプラクティスに従ってAWSに人気のあるテクノロジーをデプロイするのに役立ちます」です。これはまさに私がAWSのJaegerで目指していることです。

AWSは、新しいクイックスタートのオーサリングに役立つクイックスタートコントリビューターガイドも提供しています。詳細を深く掘り下げることなく、クイックスタートはCloudFormationテンプレートのセットであると言わせてください。

そして、私はこれらのテンプレートがしっかりしている必要があることを認めなければなりません。ドキュメントを引用すると、クイックスタートの最小アーキテクチャ要件は次のとおりです。

  • マルチAZアーキテクチャ(詳細
  • 大部分のAWSリージョンのサポート(詳細
  • 新しいVPCと既存のVPC展開オプション(詳細
  • プライベートサブネット内の製品インスタンス(詳細
  • プライベートサブネットからのアウトバウンドインターネットアクセス用のNATゲートウェイ(詳細
  • 可能な限りマーケットプレイスAMI。プリベークされたAMIはありません(詳細
  • AMIマッピング; ハードコードされたAMIはありません(詳細
  • ユーザーフレンドリーなパラメータラベルとグループ(詳細
  • 外部管理者アクセスのCIDRブロックロックダウン(詳細
  • 最小特権の原則を持つセキュリティグループ(詳細
  • 展開にソフトウェアビットはありません(詳細
  • ハードコードされたパスワードはありません(詳細
  • EC2インスタンスのユーザーデータまたはその他のクリアテキストに機密データはありません(詳細
  • オープンリモート管理アクセスに0.0.0.0/0を使用しない(詳細
  • スタックの外部に自動的に作成されたリソースはありません(詳細

確かに印象的なリスト。クイックスタートを使用てインフラストラクチャを展開する場合は、テンプレートが非常に優れていることを確認できます。

クイックスタートエコシステムについて私が特に気に入っているもう1つの点は、モジュール性です。アーキテクチャで使用するインフラストラクチャの一部をデプロイするクイックスタート(VPCクイックスタートAurora PostgreSQLクイックスタートなど)がある場合は、既存の実装を参照できます。これは、CloudFormationテンプレートに対してのみ、PythonまたはNodeJSでライブラリを参照するようなものです。この機能だけでも、CloudFormationを使用したIaCへのアプローチを変えるのに十分な画期的です。

正直に言うと、VPC、サブネット、ルートテーブル、インターネットゲートウェイ、NATゲートウェイ、エンドポイントなどをプロビジョニングするためのテンプレートを何回作成しましたか?このホイールを再発明せずに再利用できる既製の実装を夢見ていないと言ってはいけませんか?今、あなたはできます。

クイックスタート(約束)についての最後のこと。クイックスタートアーキテクチャは、特に上記で説明したモジュール性の側面を考慮すると、非常に複雑になる可能性があります。大規模なクイックスタート用のCloudFormationテンプレートの開発と保守は、堅固な自動テストフレームワークがなければ深刻な作業になる可能性があります。AWSクイックスタートチームはこの課題を認識し、TaskCatを導入しました:

TaskCat複数のAWSリージョンにわたるCloudFormationテンプレートのリンティングとデプロイを自動化します。これは、テンプレートがどんなに複雑であっても、ターゲットリージョンに正常にデプロイできることを保証できることを意味します(そして削除されます。この側面はCloudFormation開発中に無視されることがよくあります)

これによりTaskCat、「テスト」を定義して、展開時にCloudFormationにさまざまなパラメーターを提供することができます。このツールは、CI / CDツールに統合できる合格/不合格レポートも生成するため、PR検証プロセスの一部としてテストを実行できます。

IaCにAWSクイックスタートを使用しない場合でも、ワークフローにTaskCatを組み込んで、CloudFormationテンプレートのテストを自動化することをお勧めします。

イエーガークイックスタート

注:これは公式のAWSクイックスタートではありません。プロジェクトはクイックスタートコントリビューターガイドに従って構築されていますが、AWSおよびJaegerチームによってまだ承認されていません。

ここで、AWSクイックスタートとは何かを定義したら、最後にJaegerクイックスタートを紹介します。

Jaeger Quick Startは、アマゾンウェブサービス(AWS)クラウド上のオープンソースのエンドツーエンド分散トレースプラットフォームである、可用性の高いJaegerをデプロイするのに役立ちます。

クイックスタートに含まれているAWSCloudFormationテンプレートを使用すると、約10〜30分でJaegerをAWSアカウントにデプロイできます。

このクイックスタートは、 AWSCloudFormationを使用してJaegerの繰り返し可能でカスタマイズ可能なリファレンスデプロイを希望するユーザーを対象としています。提供されているAWSCloudFormationテンプレートを、独自の実装の開始点として使用することもできます。

クイックスタートの概要アーキテクチャ図は次のとおりです。

Jaegerサーバーレスアーキテクチャ(Elasticsearchバックエンドを使用)

主なハイライト:

  • クイックスタートでは、KubernetesクラスターでJaegerコンテナーを実行する代わりに(関連する操作の複雑さを伴う)、サーバーレスコンピューティングエンジンであるAWSFargateを使用します
  • クイックスタートは、必要なすべてのJaegerコンポーネント(コレクタークエリ依存関係スパークジョブ)を展開し、それらを適切に構成します
  • クイックスタートは、2つの異なるストレージバックエンドをサポートします。大規模な本番環境展開用のAmazon OpenSearchクラスターと、実験や概念実証ワークロードに適したメモリ内ストレージです。
  • クイックスタートは、ネットワークロードバランサーをパブリックVPCサブネットにデプロイして、トラフィックを分散し、必要なJaegerポートを公開します。ロードバランサーはインターネットに接続することも内部にすることもでき、VPCクライアントのみがアクセスできます
  • クイックスタートには、JaegerインスタンスにDNS名を割り当てるためのオプションがあります。パブリックとプライベートの両方のAmazonRoute53ホストゾーンがサポートされています。
  • クイックスタートはAWSCertificateManagerと統合して、ネットワークロードバランサーにTLSを追加します
  • クイックスタートは、Amazon Managed Service for Prometheusとの統合をサポートして、 Jaegerメトリックを公開します
  • クイックスタートは、 CloudWatch Container Insightsとのオプションの統合を追加して、Fargateで実行されているJaegerコンテナーのメトリクスをモニターします

機能、アーキテクチャ上の決定、および完全なパラメータリファレンスの詳細な説明は、Jaeger Quick StartDeploymentGuideにあります。

次は何ですか?

Jaeger Quick Startは新しいプロジェクトです。初期バージョンでは、2つのストレージバックエンド(OpenSearchとインメモリ)のサポートに集中していたため、アーキテクチャが少し異なります。Jaegerクイックスタートロードマップをまとめ、次に行きたい場所を示すためにGitHubの問題をいくつか提起しました。次のマイルストーンの焦点は、パフォーマンスの評価、デフォルトパラメータの微調整、およびドキュメントの改善です。最終的には、別の人気のあるJaegerストレージバックエンドであるCassandra、またはAWSのマネージドサービスの世界ではAmazonKeyspacesのサポートを追加する予定です。

AWSでのJaegerのデプロイと実行の経験がある場合、または何らかの形で貢献したい場合は、ぜひご連絡ください。逸話や遭遇した問題点は特に歓迎されます!

ただし、投稿をまとめる前に、Jaeger Quick Startをこのシリーズのより広いコンテキスト、つまり、イベント駆動型アーキテクチャを使用したOpenTelemetryの旅にどのように役立つかを説明します。

JaegerをAWS環境にデプロイする簡単な方法で、アプリケーショントレースのターゲットテレメトリバックエンドとしてAWS X-Rayを補完(または置き換える)できます。実際、JaegerとAWS X-Rayを一緒に使用して、それらを並べて実行できます。実際、両方のプラットフォームが実際に動作していることを確認し、どちらがニーズに最も適しているかについて知識に基づいた決定を行うには、このアプローチを強くお勧めします。

そして、これはまさに次の投稿で取り上げる内容です。両方のプラットフォームを並べて実行し、Jaegerをサポートするために必要なADOT構成の変更について説明し、結果のトレースを比較し、プラットフォーム間の主な違いを概説します。

資力

元の記事のソース:https ://betterprogramming.pub/introducing-jaeger-quick-start-deploying-on-aws-f0ee5d398e8a 

#jaeger #aws 

Jaegerクイックスタートの紹介—AWSへのデプロイ

Jaeger Quick Start v0.2の最新の更新

私たちは分散トレースとOpenTelemetryコミュニティにとってエキサイティングな時代に生きています。物事は急速に進んでおり、最新の変更に追いつくのは難しいかもしれません。

これは、Jaeger Quick Startの最新の更新と、間もなく発生する可能性のあるエコシステムの変更に関するヒントを共有するための投稿の状態です。

簡単な要約— Jaeger Quick Startは、可用性の高いJaeger —オープンソースのエンドツーエンドの分散トレースバックエンドをアマゾンウェブサービス(AWS)クラウドにデプロイするのに役立ちます。あなたは前の投稿でもっと見つけることができます。

展開アーキテクチャ

インメモリストレージバックエンド

トレースをJaegerにエクスポートする方法は複数あります。最も基本的な方法は、OpenTelemetrySDKとJaegerExporter(JavaPythonJavaScript.NETなどの言語固有のパッケージを参照)を使用して、アプリケーションから直接トレースをエクスポートすることです。

最も基本的なJaegerデプロイメント(メモリ内ストレージバックエンド)

デフォルト構成でデプロイされたJaegerQuickStartは、すべてのトレースをメモリに保持する最も単純なJaegerAll-In-Oneインスタンスを作成します。ただし、それでも完全な機能を備えたJaegerです。トレースの収集、検索の使用、サービス間の依存関係の確認などを行うことができます。

ただし、Jaegerインスタンスが停止するか再起動すると、すべてのデータが失われます。このモードは、評価、テスト環境、および概念実証作業に最適です。

次のポートが統合用に公開されています。

  • 14250(gRPC)
    protobuf形式のトレーススパンを受け入れます
  • 14268(HTTP)
    Thrift形式のトレーススパンを受け入れます
  • 80 / 443(HTTP)
    /api/*エンドポイントとJaeger UI/
  • [オプション] 14269 (HTTP)
    管理ポート:でのヘルスチェック/とでのメトリック/metrics

Elasticsearchストレージバックエンド

実稼働環境のより実質的なセットアップが必要になる場合があります。できれば、トレースデータが耐久性のあるストレージに保持され、復元力のために複数のアベイラビリティーゾーンに分散されたJaegerインスタンスを備えた高可用性アーキテクチャが必要です。

Jaeger Quick Startは、ロードバランサーと自動スケーリンググループの背後で複数のコレクターおよびクエリサービスFargateタスクを使用することにより、この展開シナリオをサポートします。これにより、トレーストラフィックの急増の場合に回復力と弾力性が提供されます。Amazon OpenSearchサービスは、耐久性のあるストレージとして使用されます。これも、複数のアベイラビリティーゾーンに分散されています。

Elasticsearchストレージバックエンドを備えたJaeger

次のポートが統合用に公開されています。

  • 14250(gRPC)
    protobuf形式のトレーススパンを受け入れます
  • 14268(HTTP)
    Thrift形式のトレーススパンを受け入れます
  • 80 / 443(HTTP)
    /api/*エンドポイントとJaeger UI/
  • [オプション] 14269(HTTP)
    コレクター管理ポート:でのヘルスチェック/とでのメトリック/metrics
  • [オプション] 16687(HTTP)
    クエリサービス管理ポート:でのヘルスチェック/とでのメトリック/metrics

イエーガーの前にあるOpenTelemetryコレクター

前の2つのオプションでは、標準のOTLPポートが公開されていないことに気付いたかもしれません。トレースをJaegerに送信するには、Jaegerクライアントライブラリ(廃止中)、Jaeger Agent、またはJaegerOpenTelemetryCollectorエクスポーターのいずれかを使用する必要があります。

これは、一部のシナリオでは実行できない場合があります。たとえば、 AWS Distro for OpenTelemetryの場合のように、変更できないOTLPに依存する大規模なアプリケーションがすでにあるか、Jaeger OpenTelemetryCollectorエクスポーターを簡単にインストールできない場合があります( ADOT)-JaegerエクスポーターはADOTコレクターに含まれていません。

これを克服するために、Jaeger Quick Startは、高可用性OpenTelemetryCollectorをJaegerCollectorの前にデプロイするオプションを提供します。OTLPを使用してトレースを受け入れ、それらをJaegerにエクスポートするように事前構成されています。コレクターインスタンスはアベイラビリティーゾーン全体に分散され、高可用性とスケーラビリティーの原則に従って自動スケーリンググループによってサポートされます。

これは、アプリケーションが引き続きOTLPを使用してトレースをJaegerにエクスポートできるようにするターンキーソリューションです。すぐにわかるように、この統合により、追加の興味深いオプションも可能になります。

フロントOpenTelemetryコレクターを備えたイエーガー

OpenTelemetryコレクターは、構成されているストレージに関係なく、Jaegerの前にデプロイできます—インメモリーとElasticsearchの両方のオプションがサポートされています。

次のポートは、統合のために公開されています(上記ですでに説明したJaeger固有のポートに加えて)。

OpenTelemetryCollectorおよびJaegerの運用メトリック

Jaeger Collector、Jaeger Queryサービス、およびOpenTelemetry Collectorは、監視およびアラートを行うために、運用ダッシュボードで収集および公開する可能性のある多数の運用メトリックを公開します。

すべてのインスタンスにわたってメトリクスを収集するこのタスクを簡素化するために、Jaeger Quick Startは、メトリクスをスクレイプして、一元化されたAmazon Managed ServiceforPrometheusワークスペースにエクスポートするオプションを提供します。新しいワークスペースの作成をリクエストするか、既存のワークスペースを使用することができます。

PrometheusのAmazonマネージドサービスとのオプションの統合を備えたJaeger

このセットアップは、テレメトリプラットフォームの運用面が重要である本番品質の環境に不可欠です。

サービスパフォーマンスモニタリング(SPM)

イエーガーの歴史を持つSPM

前のセクションで要約した展開オプションにより、Jaegerを使用して分散トレースプラットフォームを設計する際に多くの柔軟性が得られます。あなたの興味を刺激し、分散トレースがどれほど強力であるかを示すために、私がカバーしたい別のオプションがあります。

logz.ioの人々が2021年4月に提案し、2021年12月にその可用性を発表したという興味深いアイデアがありました。

分散トレースからAPMへ:OpenTelemetryとJaegerをレベルアップ| Logz.io

この機能の背後にある高レベルの考え方は次のとおりです。

  • OpenTelemetry Collectorは、さまざまなサービスからのすべてのトレースの焦点です
  • トレースには、エラーコードやレイテンシなど、多くの情報が含まれています
  • 着信トレースを使用し、各サービス(レート、エラー、期間)のREDメトリックを計算するようにOpenTelemetry Collectorを構成するとどうなりますか?

実際、これはまさに、OpenTelemetryCollectorにSpanMetricsProcessorを導入することでJaegerコミュニティが行ったことです。OpenTelemetryスタックを利用することにより、プロセッサは、Jager UIが使用できるメトリックを生成し、すべてのサービスにわたってREDメトリックを提示します。この機能は、JaegerのドキュメントにService Performance Monitoringとして文書化されており、Logz.ioの商用製品の一部です。

Jaegerのドキュメントに示されているように、サービスパフォーマンスモニタリングはまだ実験的な機能です。構成のOpenTelemetry側とJaeger側の両方でさらに変更が行われる可能性があります。

JaegerクイックスタートのSPM

前のセクションで説明したように、Jaeger Quick Startは、SPMに必要なすべてのコンポーネントの展開をサポートします。

  • イエーガーコレクター/クエリサービス+UI
  • OpenTelemetryコレクター
  • Prometheusワークスペース用のAmazonマネージドサービス

したがって、SPMを有効にするには、これらすべてのコンポーネントを適切に構成する必要があります(Span Metrics Processorを使用してメトリックをPrometheusに公開するように、Otel Collectorを構成し、PrometheusからメトリックをプルするようにJaegerを構成します)。

Jaeger Quick Startは、これらの手順を自動化し、単純なオン/オフ構成オプションを介してSPMサポートを提供します。これにより、サービスからの実際のトレースを使用して、ご使用の環境でSPMを低摩擦で評価できます。

サービスパフォーマンスモニタリングをサポートするイエーガー

JaegerクイックスタートのSPM—デモ

Jaeger Quik Startには、この投稿で取り上げたさまざまなJaegerアーキテクチャをデプロイするために作成された多数のテストを含む.taskcat.ymlファイルが付属しています。このファイルは、以下で使用する展開を自動化するためにTaskCatに依存しています。手動のデプロイ手順を参照して、AWSコンソールを使用してクイックスタートをデプロイすることもできます。

次のコマンドを使用して、AWS環境にJaeger Quick StartwithSPMをデプロイします。

taskcat test run -n -t inmemory-with-spm

デプロイされると、スタックの出力パラメーターからJaegerQueryエンドポイントを取得できます。

クイックスタートCloudFormationスタックのJaegerURL出力パラメーター

Jaeger Quick Startは、サンプルトレースを生成し、Jaegerの前にあるOpenTelemetry Collectorにエクスポートするために使用できるシンプルなスパンジェネレータアプリケーションも提供します(REDメトリックをキャプチャするSpan MetricsプロセッサはOpenTelemetryコレクタのコンテキストで実行されていることに注意してください)。 。次のコマンドを使用して、ジェネレーターアプリケーションを起動できます({otel-collector-domain}上記で説明したスタック出力パラメーターのドメイン名に置き換えます)。

OTEL_COLLECTOR_HOST={otel-collector-domain} docker-compose up

ここでJaegerQueryURLに移動すると、アプリケーションによって生成されたトレースが表示されます。

イエーガートレース詳細ビュー

ただし、これはすべて標準の配布トレース機能です。新機能は、すべてのサービスと操作にわたって計算されたSPMメトリックを表示する[監視]タブです。

JaegerSPMモニタータブ

このアプリケーションを自由に試して、キャプチャされたメトリックを確認してください。この機能の詳細については、トピックに関するJaegerの公式ドキュメントを参照してください。

次のステップ

Jaeger Quick Start v0.2は、多くの一般的な展開シナリオを可能にし、OpenTelemetryとJaegerの共同コミュニティ(SPM)の主要な実験機能を紹介するため、大きなマイルストーンです。ただし、プロジェクトはまだ始まったばかりであり、このセクションでは明らかな次のステップに焦点を当てます。

イエーガーでのOTLPサポート

Jaegerがトレース送信用のOTLPプロトコルをサポートしていないことに気付いたかもしれません。一部の環境では、これが制限要因となる可能性があり、Jaeger Quick Startは、OpenTelemetry CollectorをJaegerの前に配置してOTLPトレースを受け入れ、SPMなどの追加機能を提供することでこれを回避します。

イエーガーチームは制限を認識し、それに対処するために取り組んでいます:

OTLPを介してOpenTelemetryトレースデータを受け入れる・Issue#3625・jaegertracing / jaeger

執筆時点で、OTLPサポートは1.35Jaegerリリースで予定されています。この機能が利用可能になったら、クイックスタートを調整してOTLPの直接統合を利用します。

ApacheKafkaのサポート

もう1つの非常に一般的なJaegerアーキテクチャには、JaegerCollectorとElasticsearchなどの長期耐久性ストレージ間のApacheKafkaストリームが含まれます。これは、コレクターとストレージの間に中間バッファーが必要な場合に、大量の取り込みに役立つことがよくあります。このパターンの詳細については、 Jaegerのドキュメントを参照してください。

ElasticsearchストレージバックエンドとKafkaストリームを備えたJaeger

現時点では、JaegerQuickStartはApacheKafkaストリーミングアーキテクチャをサポートしていません。この作業を追跡するための未解決の問題がGitHubにあります。GitHubページにアクセスして確認してください。

結論

ご使用の環境でSPMを試してみてください。これは、分散トレースの上にインテリジェンスを構築する興味深い実験プロジェクトです。SPMは、生のトレースデータで構築されたツールとプロセスの可能性を示しています。Logz.ioが最近証明したように、分散トレーススペースの商用製品の重要な部分になる可能性のあるツールとプロセスです。

資力

元の記事のソース:https ://betterprogramming.pub/jaeger-quick-start-v0-2-adce4d1bfe64

#jaeger #kafka #github 

Jaeger Quick Start v0.2の最新の更新
Saul  Alaniz

Saul Alaniz

1653984000

Inicio Rápido De Jaeger V0.2

Vivimos tiempos emocionantes para el rastreo distribuido y la comunidad de OpenTelemetry. Las cosas se mueven rápido y puede ser difícil mantenerse al día con los últimos cambios.

Esta es una publicación sobre el estado de la situación para compartir las últimas actualizaciones de Jaeger Quick Start y una pista sobre los cambios en el ecosistema que probablemente ocurran pronto.

Un resumen rápido: Jaeger Quick Start lo ayuda a implementar un Jaeger de alta disponibilidad: backend de seguimiento distribuido de código abierto y de extremo a extremo en la nube de Amazon Web Services (AWS). Puedes encontrar más en la publicación anterior.

Arquitecturas de implementación

Backend de almacenamiento en memoria

Hay varias formas de exportar sus trazas a Jaeger. El más básico es usar OpenTelemetry SDK y Jaeger Exporter (consulte los paquetes específicos del idioma, por ejemplo, Java , Python , JavaScript , .NET , etc.) para exportar las trazas directamente desde la aplicación:

La implementación más básica de Jaeger (backend de almacenamiento en memoria)

Jaeger Quick Start implementado con la configuración predeterminada crea la instancia más simple de Jaeger All-In-One que mantiene todos los rastros en la memoria. Sin embargo, sigue siendo un Jaeger con todas las funciones: puede recopilar los rastros, usar la búsqueda, ver las dependencias entre servicios, etc.

No obstante, perderá todos los datos si la instancia de Jaeger muere o se reinicia. Este modo es perfecto para evaluaciones, entornos de prueba y trabajo de prueba de concepto.

Los siguientes puertos están expuestos para integraciones:

  • 14250(gRPC)
    Acepta tramos de rastreo en formato protobuf
  • 14268(HTTP)
    Acepta intervalos de seguimiento en formato Thrift
  • 80 / 443(HTTP)
    /api/*puntos finales y la interfaz de usuario de Jaeger en/
  • [opcional] 14269 (HTTP)
    Puerto de administración: verificación de estado en /y métricas en/metrics

Back-end de almacenamiento de Elasticsearch

Es posible que desee una configuración más sustancial para su entorno de producción, preferiblemente una arquitectura de alta disponibilidad con los datos de rastreo persistentes en un almacenamiento duradero e instancias de Jaeger distribuidas en múltiples zonas de disponibilidad para mayor resistencia.

Jaeger Quick Start es compatible con este escenario de implementación mediante el uso de múltiples tareas de Fargate del servicio Collector y Query detrás de un balanceador de carga y grupos de escalado automático. Esto proporciona resiliencia y elasticidad en caso de picos de tráfico de rastreo. Amazon OpenSearch Service se utiliza como almacenamiento duradero, de nuevo, distribuido en varias zonas de disponibilidad.

Jaeger con backend de almacenamiento de Elasticsearch

Los siguientes puertos están expuestos para integraciones:

  • 14250(gRPC)
    Acepta tramos de rastreo en formato protobuf
  • 14268(HTTP)
    Acepta intervalos de seguimiento en formato Thrift
  • 80 / 443(HTTP)
    /api/*puntos finales y la interfaz de usuario de Jaeger en/
  • [opcional] 14269(HTTP)
    Puerto de administración del recopilador: verificación de estado en /y métricas en/metrics
  • [opcional] 16687(HTTP)
    Puerto de administración del servicio de consultas: verificación de estado en /y métricas en/metrics

Colector OpenTelemetry frente a Jaeger

Es posible que haya notado que las dos opciones anteriores presentadas no exponen un puerto OTLP estándar: debe usar las bibliotecas de cliente de Jaeger (en proceso de retiro), el agente de Jaeger o el exportador de Jaeger OpenTelemetry Collector para enviar los seguimientos a Jaeger.

Esto puede no ser factible en algunos escenarios; tal vez ya tenga una aplicación grande que se basa en OTLP que no puede modificar o no puede instalar fácilmente el exportador Jaeger OpenTelemetry Collector como, por ejemplo, el caso de AWS Distro for OpenTelemetry ( ADOT): el exportador Jaeger no está incluido en ADOT Collector .

Para superar esto, Jaeger Quick Start ofrece una opción para implementar un OpenTelemetry Collector de alta disponibilidad frente a Jaeger Collector, preconfigurado para aceptar seguimientos mediante OTLP y exportarlos a Jaeger. Las instancias de recopilador se distribuyen en zonas de disponibilidad y están respaldadas por un grupo de escalado automático que sigue principios de alta disponibilidad y escalabilidad .

Esta es una solución llave en mano que garantiza que su aplicación pueda continuar usando OTLP para exportar los rastros a Jaeger. Como veremos en un momento, esta integración también permite opciones adicionales interesantes.

Jaeger con un OpenTelemetry Collector frontal

El recopilador OpenTelemetry se puede implementar frente a Jaeger, independientemente del almacenamiento configurado; se admiten las opciones In-memory y Elasticsearch.

Los siguientes puertos están expuestos para integraciones (además de los puertos específicos de Jaeger que ya cubrimos anteriormente):

Métricas operativas de OpenTelemetry Collector y Jaeger

Jaeger Collector, Jaeger Query service y OpenTelemetry Collector exponen una serie de métricas operativas que quizás desee recopilar y exponer en paneles operativos para monitorear y alertar.

Para simplificar esta tarea de recopilar las métricas en todas las instancias, Jaeger Quick Start ofrece una opción para extraer y exportar métricas a un espacio de trabajo centralizado de Amazon Managed Service para Prometheus . Puede solicitar la creación de un nuevo espacio de trabajo o utilizar uno existente.

Jaeger con integración opcional con Amazon Managed Service para Prometheus

Esta configuración es esencial para entornos de calidad de producción donde los aspectos operativos de la plataforma de telemetría son cruciales.

Supervisión del rendimiento del servicio (SPM)

SPM con historia de Jaeger

Las opciones de implementación resumidas en la sección anterior le brindan mucha flexibilidad en la arquitectura de una plataforma de seguimiento distribuida con Jaeger. Hay otra opción que me gustaría cubrir para despertar su interés y demostrar cuán poderoso puede ser el rastreo distribuido.

Hubo una idea interesante que la gente de logz.io propuso en abril de 2021 y anunció su disponibilidad en diciembre de 2021:

Del rastreo distribuido a APM: llevando OpenTelemetry y Jaeger a un nivel superior | logz.io

Aquí está el pensamiento de alto nivel detrás de esta función:

  • OpenTelemetry Collector es un punto focal de todos los rastros de diferentes servicios
  • Los rastros contienen mucha información, como códigos de error y latencias, entre otras cosas.
  • ¿Qué sucede si configuramos OpenTelemetry Collector para usar los seguimientos entrantes y calcular las métricas RED para cada servicio (tasa, errores, duración)?

De hecho, esto es exactamente lo que hizo la comunidad de Jaeger al presentar Span Metrics Processor para OpenTelemetry Collector. Al utilizar la pila OpenTelemetry, el procesador genera métricas que Jager UI puede usar para presentar métricas RED en todos sus servicios. Esta función está documentada como Supervisión del rendimiento del servicio en la documentación de Jaeger y forma parte de la oferta comercial de Logz.io.

Service Performance Monitoring es todavía una función experimental, como se indica en la documentación de Jaeger. Puede haber más cambios en los lados OpenTelemetry y Jaeger de la configuración.

Inicio rápido de SPM en Jaeger

Como cubrimos en la sección anterior, Jaeger Quick Start admite la implementación de todos los componentes necesarios para el SPM:

  • Coleccionista Jaeger / Servicios de consulta + IU
  • Colector de OpenTelemetry
  • Servicio administrado de Amazon para el espacio de trabajo de Prometheus

Por lo tanto, habilitar SPM es una cuestión de configuración adecuada de todos estos componentes (configurar Otel Collector para usar Span Metrics Processor y exponer las métricas a Prometheus, configurar Jaeger para extraer las métricas de Prometheus, etc.)

Jaeger Quick Start automatiza estos pasos y proporciona compatibilidad con SPM a través de una sencilla opción de configuración de encendido/apagado. Permite una forma sencilla de evaluar SPM en su propio entorno con seguimientos reales de los servicios:

Jaeger con soporte de supervisión del rendimiento del servicio

Inicio rápido de SPM en Jaeger: demostración

Jaeger Quik Start viene con un archivo .taskcat.yml que contiene una serie de pruebas diseñadas para implementar diferentes arquitecturas de Jaeger que cubrimos en esta publicación. Este archivo se basa en TaskCat para automatizar las implementaciones que usaré a continuación. También puede consultar las instrucciones de implementación manual para implementar el inicio rápido mediante la consola de AWS.

Utilice el siguiente comando para implementar Jaeger Quick Start con SPM en su entorno de AWS:

taskcat test run -n -t inmemory-with-spm

Una vez implementado, puede obtener el punto final de Jaeger Query desde los parámetros de salida de la pila:

Parámetro de salida JaegerURL de la pila Quick Start CloudFormation

Jaeger Quick Start también proporciona una aplicación generadora de intervalos simple que se puede usar para generar seguimientos de muestra y exportarlos a OpenTelemetry Collector que se encuentra frente a Jaeger (recuerde que el Procesador de métricas de intervalo que captura las métricas RED se ejecuta en el contexto de OpenTelemetry Collector) . Puede iniciar la aplicación del generador usando el siguiente comando (reemplace {otel-collector-domain}con el nombre de dominio del parámetro de salida de la pila que discutimos anteriormente):

OTEL_COLLECTOR_HOST={otel-collector-domain} docker-compose up

Si ahora navega a la URL de consulta de Jaeger, verá los rastros generados por la aplicación:

Vista de detalles de seguimiento de Jaeger

Sin embargo, esta es toda la funcionalidad de rastreo de distribución estándar. Lo que es nuevo es la pestaña Supervisar que presenta métricas de SPM calculadas en todos los servicios y operaciones:

Pestaña Supervisión de Jaeger SPM

Siéntete libre de jugar con esta aplicación y revisar las métricas capturadas. Para obtener información más detallada sobre la función, consulte la documentación oficial de Jaeger sobre el tema .

Próximos pasos

Jaeger Quick Start v0.2 es un gran hito, ya que permite una serie de escenarios de implementación comunes y muestra una característica experimental importante de una comunidad conjunta de OpenTelemetry y Jaeger (SPM). Sin embargo, el proyecto aún está en sus inicios y esta sección destaca los próximos pasos obvios.

Soporte OTLP en Jaeger

Es posible que haya notado que Jaeger no admite el protocolo OTLP para el envío de seguimiento. En algunos entornos, puede ser un factor limitante y Jaeger Quick Start soluciona este problema al implementar OpenTelemetry Collector frente a Jaeger para aceptar seguimientos de OTLP y proporcionar características adicionales como SPM.

El equipo de Jaeger reconoció la limitación y está trabajando para abordarla:

Aceptar datos de seguimiento de OpenTelemetry a través de OTLP · Edición n.º 3625 · jaegertracing/jaeger

En el momento de escribir este artículo, la compatibilidad con OTLP está programada para la versión 1.35 de Jaeger . Una vez que la función esté disponible, ajustaré el inicio rápido para hacer uso de la integración directa de OTLP.

Soporte de Apache Kafka

Otra arquitectura Jaeger muy común involucra una transmisión de Apache Kafka entre Jaeger Collector y el almacenamiento duradero a largo plazo como Elasticsearch. Esto suele ser útil para la ingesta de gran volumen cuando se necesita un búfer intermedio entre el colector y el almacenamiento. Consulte la documentación de Jaeger para obtener detalles adicionales sobre este patrón.

Jaeger con el backend de almacenamiento de Elasticsearch y el flujo de Kafka

Por el momento, Jaeger Quick Start no es compatible con la arquitectura de transmisión de Apache Kafka. Hay un problema abierto en GitHub para rastrear este trabajo. Visite la página de GitHub para verlo.

Conclusión

Pruebe SPM en su entorno: este es un proyecto experimental interesante que genera inteligencia además del rastreo distribuido. SPM muestra el potencial de las herramientas y los procesos creados con datos de rastreo sin procesar: las herramientas y los procesos que pueden convertirse rápidamente en una parte importante de las ofertas comerciales en el espacio de rastreo distribuido, como lo demostró recientemente Logz.io.

Recursos

Fuente del artículo original en: https://betterprogramming.pub/jaeger-quick-start-v0-2-adce4d1bfe64

#jaeger 

Inicio Rápido De Jaeger V0.2
高橋  花子

高橋 花子

1653651780

Using AWS Distro for OpenTelemetry with Jaeger

これまで、分散アーキテクチャでOpenTelemetryを実行するさまざまな側面について話し、AWS環境でのこのトレースプラットフォームのデプロイを簡素化するためにJaegerクイックスタートを導入しました。次に、すべてをまとめて、AWS Distro for OpenTelemetry(ADOT)とJaegerをトレースバックエンドとして使用する完全な例を示します。

シリーズの目標

この一連の投稿の目標を明確に述べるのは、長い間遅れています。でも、遅くなるよりはましだ。

トレースは、理論的に興味深いだけでなく、実用的で価値のある概念であることを説得したいと思います。私は、インフラストラクチャの展開と初期構成のDevOpsyの角度からこれに取り組んでいます。これは、より有用なことに移る前に解決する必要のある退屈なトピックです。

特に、AWS環境に精通し、AWSの公式トレースオファリングであるAWSX -Rayの経験があるオーディエンスを対象としています。OpenTelemetryやJaegerなどの他のオープンソース製品を通じて、さまざまなトレースプラットフォームを評価するオプションがあることを示しています。OpenTelemetryを採用することで、複数のトレースプラットフォームを並べて実行し、それらを調べて、組織に最適なものを意識的に決定することもできると私は主張しています。

OpenTelemetry +Jaeger=❤️

先に進む前に、OpenTelemetry Collectorアーキテクチャーについて簡単に説明します(詳細については、OpenTelemetryへのアプローチを参照してください)。

OpenTelemetryCollectorアーキテクチャ

OpenTelemetry Collectorは、テレメトリ信号(トレース、メトリック、ログ)の受信処理、およびエクスポートを保証する主要コンポーネントです。OpenTelemetryユーザーは、コレクターパイプラインを担当します。使用可能なレシーバー、プロセッサー、およびエクスポーターのレジストリーから選択して、必要なパイプラインを正確に構築できます。

OpenTelemetryは、推奨されるプロセッサのリストを定義しています—一見の価値があります。

JaegerアーキテクチャもCollectorを中心に構築されています。同様の名前はここでは偶然ではありません—Jaegerの創設者であるYuriShkuroは、OpenTelemetryの共同創設者であり、コミュニティの活発なメンバーでもあります。Jaeger Collectorは、さまざまな形式のトレーススパンを受信し、サポートされているストレージバックエンドの1つを使用して、データの効率的なストレージを処理できます。これを書いている時点では、Elasticsearch、Cassandra、Kafkaです。

すべてをまとめると、OpenTelemetryパイプラインがトレースをJaegerプラットフォームにエクスポートするように構成されている場合、トレースフローは次のようになります。

トレースバックエンドとしてJaegerを使用したOpenTelemetryトレースフロー。

この時点で、有効な質問をすることができます—なぜ別のコレクターが必要なのですか?これは運用上大きな問題であることを思い出してください。展開、スケーリング、パッチ適用、監視、およびトラブルシューティングについて考えてください。OpenTelemetry Collectorから直接Jaegerストレージバックエンドにトレースをエクスポートすると、より簡単になりませんか?

Jaegerバックエンドトレースストレージに直接エクスポートするOpenTelemetryトレースフロー(架空)。

JaegerはOpenTelemetryの前に作成されました。これは、Jaeger Collectorがありますが、JaegerストレージバックエンドをサポートするOpenTelemetryエクスポーターが(まだ)ない理由を説明しています。

実際、これはまさにイエーガーチームが考えている方向です。ただし、まだそこにいないため、両方のコレクターが存在する必要があります。挫折のように思えるかもしれませんが、AWS DistroforOpenTelemetryがどのように適合するかを理解するためにさらに一歩進んでみましょう。

参照されているGitHubの問題は、OpenTelemetryとJaegerの関係、およびそれらの間の機能の重複をよりよく理解するのに役立つ非常に興味深い読み物です。

ADOT +イエーガー=?

上で説明したように、OpenTelemetry Collectorは、Jaegerエクスポーターを使用して構成ファイルを介してトレースをJaegerCollectorにエクスポートするように構成できます。ADOTでも同じことができますか?

In theory, it should be the same thing — ADOT is just an OpenTelemetry distribution, tailored for the AWS environment. Right?..

Not quite. Remember that an OpenTelemetry distribution can both add and remove certain OpenTelemetry components and ADOT is not an exception. It adds AWS-specific components but it also removes some from the base distro, mainly to keep the distro compact and reduce the testing surface. What’s important for today’s post — there is no Jaeger exporter available in AWS Distro for OpenTelemetry.

OpenTelemetry用のJaegerエクスポーターが利用可能であるという事実にもかかわらず、それはADOTに含まれていません(まだ?)。したがって、スパンをJaegerにエクスポートするようにADOTベースのアプリケーションを構成する組み込みの方法はありません。

これは、ADOT->Jaegerトレース処理パイプラインを直接構築できないことを意味します。これに最初に遭遇したときはがっかりするかもしれませんが、これは実際には(非常に)悪いことではないことを以下で議論します。

この障害に対処し、OpenTelemetryトレースをADOT対応アプリケーションからJaegerにエクスポートする方法は複数あります。

  • イエーガーの前にあるOpenTelemetryコレクター
  • Jaegerエクスポーターにパッケージ化されたカスタムADOTコレクター

この投稿では、 opentelemetry-collector-contribリポジトリからのすべてのプロセッサ/エクスポータを含む最新のOTEL Collectorリリースで使用できるため、主に最初のアプローチに焦点を当てています。カスタムADOTコレクターを構築するプロセスについては、今後の投稿で説明します。

ゲートウェイOTELコレクタアーキテクチャ

ADOTから直接Jaegerにスパンをエクスポートする代わりに、Jaegerプラットフォームの前に別のOpenTelemetryCollectorを導入しましょう。

トレースバックエンドとしてADOTCollector、Gateway Collector、およびJaegerを使用したトレースフロー

上記のアーキテクチャは間違っていると感じるかもしれません—現在、 2つのOpenTelemetryコレクターがあり、ADOTにJaegerエクスポーターが含まれていないという事実を回避しているようです。単一のサービスがある場合は確かにそうかもしれませんが、数十または数百のサービスがある場合はどうでしょうか。

GatewayCollectorを使用した大規模アーキテクチャ

突然、OpenTelemetryCollectorをゲートウェイとしてデプロイしたアーキテクチャがはるかに賢明に見えます。Gateway Collectorは、各サービスで同じ構成を繰り返し複製するのではなく、テレメトリ処理パイプラインを標準化する方法です。このアーキテクチャを導入すると、ADOTコレクターは「ダム」エージェントとして機能し、テレメトリ信号をゲートウェイコレクターに転送し、ゲートウェイコレクターがメイン処理を実行します。

このアーキテクチャを使用してできることは次のとおりです。

  • テールベースのサンプリングを含む、分散アーキテクチャ全体に高度なサンプリングポリシーを実装する
  • サービス全体で収集されたスパンに基づいてメトリックをキャプチャします。これは、サンプリングルールによって削除されるスパンに基づいてメトリックをキャプチャできるため、特に価値があります。
  • テレメトリ信号のエクスポートを(シークレット管理とともに)外部バックエンド(JaegerやDataDogなど)に一元化します
  • 効率的なスケーリング— ADOT Collectorはサービスの近くで実行されているため、アプリケーションのパフォーマンスがトレースの影響を受けないようにするために、非常に軽量であると想定されています。対照的に、ゲートウェイOpenTelemetry Collectorは、すべてのサービスの合計テレメトリボリュームに基づいて、個別に展開およびスケーリングできます。
  • Gateway Collectorは、組織全体のセキュリティ/ネットワーキング制御を実施し、テレメトリプロデューサー(通常はサービスチーム)をテレメトリ管理(プラットフォームチーム)から切り離す方法です。

このアーキテクチャの明らかな欠点—テレメトリパイプラインに別のホップが追加され、特に運用の観点から、より複雑になります。

私は、あなたが得る利点は、分散アーキテクチャでより多くのサービスを持っているという欠点をはるかに上回っていると主張します。

朗報—Jaegerクイックスタート

あなたが深くため息をつき、しぶしぶ重要だと聞きました。

わかった。そのゲートウェイのことは理にかなっています。これを試して、イエーガーとX線を比較します。しかし、これには多くの作業が必要であり、私は今これに投資する準備ができていないように感じます。

前回の投稿では、このユースケースに対応するJaegerクイックスタートプロジェクトを紹介しました。クイックスタートは、AWSでの初期のJaegerのデプロイと設定を適切なデフォルトで自動化するため、「すばやく開始」できます。このブログ投稿の目的で、Jaeger Quick Startは、Jaeger自体だけでなく、その前に事前構成されたOpenTelemetryCollectorをデプロイするオプションを提供します。

Jaegerクイックスタートの境界とADOTコレクターとの統合

これは、実際には、Jaeger Quick Startを環境にデプロイすると、すぐに使用できることを意味します。ADOTサービスでコードを変更する必要はありません(イェーイ!)。必要なのは、ADOT Collectorの構成を調整して、トレースをJaegerの前にあるゲートウェイCollectorに転送することだけです。

ADOTコレクター構成

この投稿のデモンストレーション部分では、前の投稿で詳細に説明した単純なイベント駆動型アーキテクチャを使用します。

OpenTelemetryでトレースしたい分散アーキテクチャ

このアプリケーションの完全なソースコードと必要なデプロイ手順は、GitHubのkolomiets/tracing-playgroundリポジトリにあります。

デモアプリケーションでADOTCollectorを使用しているため、OPENTELEMETRY_COLLECTOR_CONFIG_FILE環境変数を使用して、デフォルトのCollector構成をオーバーライドし、トレース処理パイプラインを調整したカスタム構成を追加できます(これをデフォルトの構成と比較してください変更はわずかです)。

receivers:
  otlp:
    protocols:
      grpc:
      http:

exporters:
  logging:
  awsxray:
  otlp:
    endpoint: "${JAEGER_OTLP_ENDPOINT}"
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [awsxray, otlp]
    metrics:
      receivers: [otlp]
      exporters: [logging]

追加のOTLPエクスポーターを使用したADOTコレクター構成

この設定を行ったら、同じトレースをAWSX-RayバックエンドJaegerバックエンドの両方にエクスポートします。これは、両方のプラットフォームを評価するのに非常に役立ちます。

上記の構成では、OTLPエンドポイントに環境変数拡張を使用します。これは、コレクター構成ファイルを単純かつ静的に保つための優れた手法です。拡張では、JAEGER_OTLP_ENDPOINT変数を更新してエンドポイントを再構成することもできます。構成ファイルを変更して、サービス全体を再デプロイする必要はありません。

それで、私は痕跡を見ることができますか?

はい!

これで、すべての構成ビットが邪魔にならない状態で、デモアプリケーションを実行し(GitHubリポジトリの手順を参照)、最後にAWSX-RayとJaegerの両方でトレースを確認できます。AWSX-Rayから始めましょう:

AWSX線トレース

これは、OpenTelemetryを使用してコンテキスト伝播を調べたときに見たおなじみのトレースです。ここでは特に新しいことはありません。イエーガーに切り替えましょう:

Jaeger UI with recent traces

Jaeger shows a number of captured traces — note different colour codes for services involved. If we dive deeper and open a trace, we’ll get span details:

Jaeger — Trace details

Each span contains OpenTelemetry span attributes — the main source of information about a span. For example, here are the attributes for Kinesis.PutRecord span:

Jaeger — Span attributes

Jaeger has an analogue of AWS X-Ray Service Map feature available at System Architecture tab:

Jaeger — System Architecture

The numbers on the edges show the total number of traces captured along the edge

Jaegerのシステムアーキテクチャは、AWSX-Rayで見たものとは異なることに気付くかもしれません。ラムダ関数のノードは存在しますが、AWSサービスのノード(Lambda、SQS、Kinesis、SNS)は表示されません。ラムダ関数で明示的に作成されたすべてのスパンをキャプチャできたようですが、AWSサービスによって発行されたスパンはありません。ここで何が起こっているのですか?

その答えは、AWSサービスがAWSX-Rayとどのように統合されているかにあります。ドキュメントに記載されているように、一部のサービス(AWSLambdaやAmazonAPI Gatewayなど)は、サービスマップにノードを追加します。つまり、特定のAWSサービスとAWS X-Rayの間に組み込みの統合があり、OpenTelemetryはこれらの追加のスパンを支援できません。これが、Jaegerでそれらが表示されない理由です(JaegerはOpenTelemetry Collectorが取得するスパンのみを受信するため)。

これは、AWS X-RayとJaegerによってキャプチャされたトレースの違いだけではありませんが、おそらく最も目に見えるものです。ここでの議論を一時停止し、さらなる分析を次の投稿に延期したいと思います—これはそれ自体が大きなトピックです。

結論

まとめる前に、この投稿で取り上げた主なアイデアを要約しておきましょう。

ゲートウェイモードのOpenTelemetryCollectorは、特に多数のサービスを備えたシステムの場合に検討するのに適したパターンです。これは、テレメトリ処理パイプラインを標準化および強化して、個々のサービスのテレメトリオーバーヘッドを削減するのに最適な方法です。

AWS Distro for OpenTelemetryは、トレースをAWS X-Ray(デフォルトの動作)だけでなく、他のバックエンドにもエクスポートするように設定できます。これにより、複数のトレースバックエンドを並べて実行できます。これは、移行、評価、およびPOCに非常に役立ちます。

Jaeger Quick Startは、AWS環境でのJaegerテレメトリプラットフォームのプロビジョニングを簡素化し、OpenTelemetryパイプラインにプラグインできるようにします。

ADOTによってキャプチャされ、Jaegerにエクスポートされたトレースは、AWSX -Rayで観察されるトレースと異なります。部分的にこれは、特定のAWSサービスとAWSX-Rayが直接統合されているためです。これらの違いの分析については、このシリーズの今後の投稿で取り上げます。

そして最後に、主な成果— Jaegerクイックスタートデモアプリケーションですべての基礎がカバーされ、体系化されているので、Jaegerの展開と構成について話すのをやめます:)次の投稿では、トレース自体とOpenTelemetryの利点について説明します。提供します。 

ソース:https ://betterprogramming.pub/using-aws-distro-for-opentelemetry-with-jaeger-acf4df3a8e37

#jaeger  #aws 

Using AWS Distro for OpenTelemetry with Jaeger

Uso de AWS Distro para OpenTelemetry con Jaeger

Hasta ahora, he estado hablando sobre diferentes aspectos de la ejecución de OpenTelemetry en arquitecturas distribuidas y presenté Jaeger Quick Start para simplificar la implementación de esta plataforma de seguimiento en el entorno de AWS. Ahora es el momento de reunir todo y mostrar un ejemplo completo del uso de AWS Distro for OpenTelemetry (ADOT) y Jaeger como backend de seguimiento.

El objetivo de la serie.

Hace mucho tiempo que se debe establecer claramente el objetivo de esta serie de publicaciones . Aunque más vale tarde que nunca.

Quiero persuadirte de que el rastreo es un concepto práctico y valioso, no solo teóricamente interesante. Estoy abordando esto desde el ángulo de DevOpsy de implementación de infraestructura y configuración inicial: los temas aburridos que debemos resolver antes de pasar a cosas más útiles.

En particular, me dirijo a la audiencia que está familiarizada con el entorno de AWS y tiene algo de experiencia con AWS X-Ray , la oferta de seguimiento oficial de AWS. A través de OpenTelemetry y otros productos de código abierto como Jaeger , demuestro que tiene una opción para evaluar diferentes plataformas de rastreo. Estoy argumentando que al adoptar OpenTelemetry incluso puede ejecutar varias plataformas de seguimiento en paralelo , examinarlas y tomar una decisión consciente sobre lo que funciona mejor para su organización.

OpenTelemetry + Jaeger = ❤️

Antes de continuar, un recordatorio rápido de la arquitectura de OpenTelemetry Collector (para una discusión más detallada, consulte Enfoque de OpenTelemetry ):

Arquitectura del recopilador OpenTelemetry

OpenTelemetry Collector es el componente principal que garantiza que las señales de telemetría (rastros, métricas, registros) se reciban , procesen y exporten . Como usuario de OpenTelemetry, usted es responsable de las canalizaciones de Collector : puede elegir de un registro de receptores, procesadores y exportadores disponibles para crear las canalizaciones exactas que necesita.

OpenTelemetry define una lista de procesadores recomendados ; vale la pena echarle un vistazo.

La arquitectura Jaeger también se basa en Collector . Los nombres similares no son una coincidencia aquí: el fundador de Jaeger, Yuri Shkuro, también es cofundador de OpenTelemetry y miembro activo de la comunidad. Jaeger Collector puede recibir intervalos de rastreo en varios formatos y maneja el almacenamiento eficiente de los datos, utilizando uno de los backends de almacenamiento admitidos ; en el momento de escribir este artículo, estos son Elasticsearch, Cassandra y Kafka.

Reuniéndolo todo, cuando la canalización de OpenTelemetry está configurada para exportar seguimientos a la plataforma Jaeger, el flujo de seguimiento se ve así:

Flujo de seguimiento de OpenTelemetry con Jaeger como backend de seguimiento.

En este punto, puede hacer una pregunta válida: ¿por qué necesitamos otro recopilador? Recuerde que esto es un gran problema desde el punto de vista operativo: piense en implementar, escalar, parchear, monitorear y solucionar problemas. ¿No sería más fácil si exportáramos las trazas a los backends de almacenamiento de Jaeger directamente desde OpenTelemetry Collector?

Flujo de seguimiento de OpenTelemetry (imaginario) con exportación directa al almacenamiento de seguimiento de back-end de Jaeger.

Jaeger fue creado antes de OpenTelemetry. Esto explica por qué tenemos Jaeger Collector pero (todavía) no tenemos OpenTelemetry Exporters que admitan backends de almacenamiento Jaeger.

De hecho, esta es exactamente la dirección en la que está pensando el equipo de Jaeger . Sin embargo, todavía no hemos llegado y ambos Coleccionistas tienen que estar presentes. Puede parecer un contratiempo, pero demos un paso más para entender cómo encaja AWS Distro for OpenTelemetry.

El problema de GitHub al que se hace referencia es una lectura muy interesante que ayuda a comprender mejor las relaciones entre OpenTelemetry y Jaeger, así como la superposición de funciones entre ellos.

ADOT + Jaeger = ?

Como comentamos anteriormente, OpenTelemetry Collector se puede configurar para exportar los seguimientos a Jaeger Collector a través del archivo de configuración mediante el exportador de Jaeger. ¿Se puede hacer lo mismo con ADOT?

En teoría, debería ser lo mismo: ADOT es solo una distribución de OpenTelemetry , adaptada para el entorno de AWS. ¿Derecha?..

No exactamente. Recuerde que una distribución de OpenTelemetry puede agregar y eliminar ciertos componentes de OpenTelemetry y ADOT no es una excepción. Agrega componentes específicos de AWS, pero también elimina algunos de la distribución base, principalmente para mantener la distribución compacta y reducir la superficie de prueba. Lo que es importante para la publicación de hoy: no hay un exportador de Jaeger disponible en AWS Distro for OpenTelemetry .

A pesar de que hay un exportador de Jaeger para OpenTelemetry disponible, no está incluido en ADOT (¿todavía?) y, por lo tanto, no hay una forma integrada de configurar aplicaciones basadas en ADOT para exportar tramos a Jaeger.

Significa que no podemos construir directamente ADOT -> Canalización de procesamiento de seguimiento de Jaeger. Puede ser decepcionante cuando te encuentras con esto por primera vez, pero voy a argumentar a continuación que en realidad no es algo (muy) malo.

Hay varias formas de abordar este obstáculo y exportar seguimientos de OpenTelemetry desde la aplicación habilitada para ADOT a Jaeger:

  • Colector OpenTelemetry frente a Jaeger
  • Colector ADOT personalizado empaquetado con exportador Jaeger

Esta publicación se enfoca principalmente en el primer enfoque, ya que se puede usar con las últimas versiones de OTEL Collector, incluidos todos los procesadores/exportadores del repositorio opentelemetry-collector-contrib . Cubriremos el proceso de creación de un recopilador ADOT personalizado en publicaciones futuras.

Gateway OTEL Collector arquitectura

En lugar de intentar exportar tramos a Jaeger directamente desde ADOT, presentemos otro OpenTelemetry Collector frente a la plataforma Jaeger:

Flujo de seguimiento con ADOT Collector, Gateway Collector y Jaeger como backend de seguimiento

La arquitectura anterior puede parecer incorrecta: ahora tenemos dos OpenTelemetry Collectors, aparentemente solo para solucionar el hecho de que ADOT no incluye el exportador de Jaeger. De hecho, puede ser el caso si tiene un solo servicio, pero ¿qué sucede si tiene decenas o cientos de ellos?

Arquitectura a gran escala con Gateway Collector

De repente, la arquitectura con OpenTelemetry Collector implementada como puerta de enlace parece mucho más sensata. Gateway Collector es una forma de estandarizar sus canalizaciones de procesamiento de telemetría, en lugar de replicar la misma configuración una y otra vez en cada servicio. Con esta arquitectura implementada, los recopiladores de ADOT actúan como agentes "tontos" y envían señales de telemetría al recopilador de puerta de enlace que, a su vez, realiza el procesamiento principal.

Esto es lo que puede hacer con esta arquitectura en su lugar:

  • Implemente políticas de muestreo avanzadas en su arquitectura distribuida, incluido el muestreo basado en la cola
  • Capture métricas basadas en los intervalos recopilados en sus servicios. Esto es especialmente valioso ya que puede capturar métricas basadas en los tramos que sus reglas de muestreo eliminarán.
  • Centralice la exportación de señales de telemetría (junto con la gestión secreta) a backends externos, como Jaeger o DataDog
  • Escalamiento eficiente: ADOT Collector se está ejecutando cerca del servicio y, por lo tanto, se supone que es muy liviano para garantizar que el rendimiento de la aplicación no se vea afectado por el seguimiento. Por el contrario, la puerta de enlace OpenTelemetry Collector se puede implementar y escalar de forma independiente, en función del volumen total de telemetría en todos los servicios.
  • Gateway Collector es una forma de aplicar controles de red/seguridad en toda la organización y desvincular a los productores de telemetría (normalmente, equipos de servicio) de la gestión de telemetría (equipo de plataforma).

La desventaja obvia de esta arquitectura: agrega otro salto a la tubería de telemetría y la hace más compleja, especialmente desde el punto de vista operativo.

Yo diría que las ventajas que obtiene superan con creces las desventajas cuantos más servicios tenga en su arquitectura distribuida.

Buenas noticias: inicio rápido de Jaeger

Te escucho suspirar profundamente y de mala gana importa:

ESTÁ BIEN. Eso de la puerta de enlace tiene sentido. Probaría esto y compararía Jaeger con X-Ray. Sin embargo, parece que esto requiere mucho trabajo y no estoy listo para invertir en esto ahora.

En la publicación anterior , presenté el proyecto Jaeger Quick Start que aborda este caso de uso. El inicio rápido automatiza la implementación y configuración inicial de Jaeger en AWS con valores predeterminados razonables, para que pueda "comenzar rápidamente". A los efectos de esta publicación de blog, Jaeger Quick Start ofrece una opción para implementar no solo el propio Jaeger, sino también un OpenTelemetry Collector preconfigurado frente a él:

Límites de Jaeger Quick Start e integración con ADOT Collector

En realidad, esto significa que una vez que haya implementado Jaeger Quick Start en su entorno, puede usarlo de inmediato; no es necesario realizar cambios de código en sus servicios ADOT (¡sí!). Todo lo que se necesita es ajustar la configuración del recopilador ADOT para reenviar las trazas al recopilador de puerta de enlace frente a Jaeger.

Configuración del recopilador ADOT

Para la parte de demostración de esta publicación, usaré una arquitectura simple basada en eventos que cubrimos en detalle en la publicación anterior :

La arquitectura distribuida que queremos rastrear con OpenTelemetry

El código fuente completo de esta aplicación junto con las instrucciones de implementación necesarias se pueden encontrar en el repositorio kolomiets/tracing-playground en GitHub.

Como usamos ADOT Collector en la aplicación de demostración, podemos usar la variable de entorno OPENTELEMETRY_COLLECTOR_CONFIG_FILE para anular la configuración predeterminada de Collector y agregar una personalizada con las canalizaciones de procesamiento de seguimiento ajustadas (compare esto con la configuración predeterminada ; los cambios son marginales):

receivers:
  otlp:
    protocols:
      grpc:
      http:

exporters:
  logging:
  awsxray:
  otlp:
    endpoint: "${JAEGER_OTLP_ENDPOINT}"
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [awsxray, otlp]
    metrics:
      receivers: [otlp]
      exporters: [logging]

Configuración de ADOT Collector con exportador OTLP adicional

Con esta configuración en su lugar, exportamos los mismos rastros a los backends de AWS X-Ray y Jaeger. Esto es muy útil para evaluar ambas plataformas.

Usamos la expansión de variables de entorno para el extremo OTLP en la configuración anterior. Esta es una buena técnica para mantener los archivos de configuración de Collector simples y estáticos. La expansión también le permite reconfigurar el punto final actualizando la variable JAEGER_OTLP_ENDPOINT; no es necesario cambiar el archivo de configuración y volver a implementar todo el servicio.

Entonces, ¿puedo ver las huellas, por favor?

¡Sí!

Ahora, con todos los bits de configuración fuera del camino, podemos ejecutar nuestra aplicación de demostración (consulte las instrucciones en el repositorio de GitHub ) y finalmente ver los rastros en AWS X-Ray y Jaeger. Comencemos con AWS X-Ray:

Seguimiento de rayos X de AWS

Este es el rastro familiar que hemos visto cuando examinamos la propagación del contexto con OpenTelemetry . Nada particularmente nuevo aquí. Pasemos a Jaeger:

Interfaz de usuario de Jaeger con rastros recientes

Jaeger muestra varios rastros capturados; tenga en cuenta los diferentes códigos de color para los servicios involucrados. Si nos sumergimos más profundamente y abrimos un seguimiento, obtendremos detalles de tramo:

Jaeger — Detalles del rastro

Cada tramo contiene atributos de tramo de OpenTelemetry , la principal fuente de información sobre un tramo. Por ejemplo, estos son los atributos de Kinesis.PutRecord span:

Jaeger — Atributos de tramo

Jaeger tiene un análogo de la función AWS X-Ray Service Map disponible en la pestaña Arquitectura del sistema :

Jaeger — Arquitectura del sistema

Los números en los bordes muestran el número total de trazas capturadas a lo largo del borde.

Puede notar que la arquitectura del sistema de Jaeger es diferente de lo que hemos visto en AWS X-Ray. Los nodos para las funciones lambda están presentes, pero no vemos los nodos para los servicios de AWS: Lambda, SQS, Kinesis, SNS. Parece que pudimos capturar todos los intervalos creados explícitamente en las funciones lambda, pero los servicios de AWS no emiten intervalos. ¿Que esta pasando aqui?

La respuesta radica en cómo se integran los servicios de AWS con AWS X-Ray. Como se menciona en la documentación , algunos servicios (como AWS Lambda o Amazon API Gateway) agregan nodos adicionales al mapa de servicios. En otras palabras, existe una integración integrada entre ciertos servicios de AWS y AWS X-Ray y OpenTelemetry no pueden ayudarnos con estos lapsos adicionales. Es por eso que no los vemos en Jaeger (ya que Jaeger recibe solo los tramos que obtiene OpenTelemetry Collector).

Esta no es la única diferencia entre los rastros capturados por AWS X-Ray y Jaeger, pero probablemente sea la más visible. Me gustaría hacer una pausa en la discusión aquí y posponer el análisis para la próxima publicación; este es un gran tema en sí mismo.

Conclusión

Antes de terminar, permítanme resumir las ideas principales que hemos cubierto en esta publicación.

OpenTelemetry Collector en modo de puerta de enlace es un buen patrón a considerar, especialmente para sistemas con una gran cantidad de servicios. Esta es una manera perfecta de estandarizar y enriquecer sus canalizaciones de procesamiento de telemetría, reduciendo la sobrecarga de telemetría para cada servicio individual.

AWS Distro for OpenTelemetry se puede configurar para exportar los seguimientos no solo a AWS X-Ray (que es el comportamiento predeterminado), sino también a otros backends. Esto le permite ejecutar varios backends de seguimiento en paralelo, algo invaluable para migraciones, evaluaciones y pruebas de concepto.

Jaeger Quick Start simplifica el aprovisionamiento de la plataforma de telemetría de Jaeger en su entorno de AWS, lista para conectarse a sus canalizaciones de OpenTelemetry.

Los rastros capturados por ADOT y exportados a Jaeger son diferentes de los rastros que observa en AWS X-Ray. En parte, esto se debe a las integraciones directas entre ciertos servicios de AWS y AWS X-Ray . El análisis de estas diferencias se tratará en publicaciones posteriores de esta serie.

Y, finalmente, el logro principal: con todo el trabajo preliminar cubierto y codificado en Jaeger Quick Start y aplicaciones de demostración , dejo de hablar sobre la implementación y configuración de Jaeger :) En las próximas publicaciones, hablaremos sobre los seguimientos en sí mismos y los beneficios que OpenTelemetry proporciona. 

Fuente: https://betterprogramming.pub/using-aws-distro-for-opentelemetry-with-jaeger-acf4df3a8e37

 #jaeger #aws 

Uso de AWS Distro para OpenTelemetry con Jaeger
Elian  Harber

Elian Harber

1651213020

Jaeger: CNCF Jaeger, A Distributed Tracing Platform

Jaeger - a Distributed Tracing System

Jaeger, inspired by Dapper and OpenZipkin, is a distributed tracing platform created by Uber Technologies and donated to Cloud Native Computing Foundation. It can be used for monitoring microservices-based distributed systems:

  • Distributed context propagation
  • Distributed transaction monitoring
  • Root cause analysis
  • Service dependency analysis
  • Performance / latency optimization

See also:

Jaeger is hosted by the Cloud Native Computing Foundation (CNCF) as the 7th top-level project (graduated in October 2019). If you are a company that wants to help shape the evolution of technologies that are container-packaged, dynamically-scheduled and microservices-oriented, consider joining the CNCF. For details about who's involved and how Jaeger plays a role, read the CNCF Jaeger incubation announcement and Jaeger graduation announcement.

Get Involved

Jaeger is an open source project with open governance. We welcome contributions from the community, and we would love your help to improve and extend the project. Here are some ideas for how to get involved. Many of them do not even require any coding.

Features

High Scalability

Jaeger backend is designed to have no single points of failure and to scale with the business needs. For example, any given Jaeger installation at Uber is typically processing several billions of spans per day.

Native support for OpenTracing

Jaeger backend, Web UI, and instrumentation libraries have been designed from the ground up to support the OpenTracing standard.

  • Represent traces as directed acyclic graphs (not just trees) via span references
  • Support strongly typed span tags and structured logs
  • Support general distributed context propagation mechanism via baggage

OpenTelemetry

Jaeger project recommends OpenTelemetry SDKs for instrumentation, instead of Jaeger's native SDKs that are now deprecated.

The OpenTracing and OpenCensus projects have merged into a new CNCF project called OpenTelemetry. The Jaeger and OpenTelemetry projects have different goals. OpenTelemetry aims to provide APIs and SDKs in multiple languages to allow applications to export various telemetry data out of the process, to any number of metrics and tracing backends. The Jaeger project is primarily the tracing backend that receives tracing telemetry data and provides processing, aggregation, data mining, and visualizations of that data. The Jaeger client libraries do overlap with OpenTelemetry in functionality. OpenTelemetry natively supports Jaeger as a tracing backend and makes Jaeger native clients unnecessary. For more information please refer to a blog post Jaeger and OpenTelemetry.

Multiple storage backends

Jaeger supports two popular open source NoSQL databases as trace storage backends: Cassandra and Elasticsearch. There is also embedded database support using Badger. There are ongoing community experiments using other databases, such as ScyllaDB, InfluxDB, Amazon DynamoDB. Jaeger also ships with a simple in-memory storage for testing setups.

Modern Web UI

Jaeger Web UI is implemented in Javascript using popular open source frameworks like React. Several performance improvements have been released in v1.0 to allow the UI to efficiently deal with large volumes of data and to display traces with tens of thousands of spans (e.g. we tried a trace with 80,000 spans).

Cloud Native Deployment

Jaeger backend is distributed as a collection of Docker images. The binaries support various configuration methods, including command line options, environment variables, and configuration files in multiple formats (yaml, toml, etc.) Deployment to Kubernetes clusters is assisted by Kubernetes templates and a Helm chart.

Observability

All Jaeger backend components expose Prometheus metrics by default (other metrics backends are also supported). Logs are written to standard out using the structured logging library zap.

Security

Third-party security audits of Jaeger are available in https://github.com/jaegertracing/security-audits. Please see Issue #1718 for the summary of available security mechanisms in Jaeger.

Backwards compatibility with Zipkin

Although we recommend instrumenting applications with OpenTelemetry, if your organization has already invested in the instrumentation using Zipkin libraries, you do not have to rewrite all that code. Jaeger provides backwards compatibility with Zipkin by accepting spans in Zipkin formats (Thrift or JSON v1/v2) over HTTP. Switching from Zipkin backend is just a matter of routing the traffic from Zipkin libraries to the Jaeger backend.

Version Compatibility Guarantees

Occasionally, CLI flags can be deprecated due to, for example, usability improvements or new functionality. In such situations, developers introducing the deprecation are required to follow these guidelines.

In short, for a deprecated CLI flag, you should expect to see the following message in the --help documentation:

(deprecated, will be removed after yyyy-mm-dd or in release vX.Y.Z, whichever is later)

A grace period of at least 3 months or two minor version bumps (whichever is later) from the first release containing the deprecation notice will be provided before the deprecated CLI flag can be deleted.

For example, consider a scenario where v1.28.0 is released on 01-Jun-2021 containing a deprecation notice for a CLI flag. This flag will remain in a deprecated state until the later of 01-Sep-2021 or v1.30.0 where it can be removed on or after either of those events. It may remain deprecated for longer than the aforementioned grace period.

Related Repositories

Documentation

Instrumentation Libraries

Jaeger project recommends OpenTelemetry SDKs for instrumentation, instead of Jaeger's native SDKs that are now deprecated.

Deployment

Components

Building From Source

See CONTRIBUTING.

Project Status Meetings

The Jaeger maintainers and contributors meet regularly on a video call. Everyone is welcome to join, including end users. For meeting details, see https://www.jaegertracing.io/get-in-touch/.

Roadmap

See https://www.jaegertracing.io/docs/roadmap/

Get in Touch

Have questions, suggestions, bug reports? Reach the project community via these channels:

Adopters

Jaeger as a product consists of multiple components. We want to support different types of users, whether they are only using our instrumentation libraries or full end to end Jaeger installation, whether it runs in production or you use it to troubleshoot issues in development.

Please see ADOPTERS.md for some of the organizations using Jaeger today. If you would like to add your organization to the list, please comment on our survey issue.

Author: jaegertracing
Source Code: https://github.com/jaegertracing/jaeger 
License: Apache-2.0 License

#go #golang #observability 

Jaeger: CNCF Jaeger, A Distributed Tracing Platform
Mireille  Von

Mireille Von

1625757660

Istio on EKS in 30minutes | Istio Service Mesh | Zero to Hero | Kiali and Jaeger usage

This video covers the usage of Istio on EKS with a hands-on example provided by the Istio team. We also look at Kiali Dashboard and Jaeger for Distributed tracing.

📌Links:

🔗 Istio Getting Started: https://istio.io/latest/docs/setup/getting-started/

📌 Related Videos

🔗AWS Primer: https://www.youtube.com/playlist?list=PLTyWtrsGknYdyi0JR7c1wsuv-Plrwrzqj
🔗 System Design Primer: https://www.youtube.com/playlist?list=PLTyWtrsGknYeX_wV9ysDuuAxvxfSBfVSI
🔗 Containers Primer: https://www.youtube.com/watch?v=yo2g_CZZWL4&list=PLTyWtrsGknYf_Oee7YOvom5Ev0F3-E2zB
🔗 Kubernetes Primer: https://www.youtube.com/playlist?list=PLTyWtrsGknYfanKF33E12LdJvl5q5PZGp

💥 Join TechPrimers Slack Community: https://bit.ly/JoinTechPrimers
💥 Telegram: https://t.me/TechPrimers
💥 TechPrimer HindSight (Blog): https://medium.com/TechPrimers
💥 Website: http://techprimers.com
💥 Slack Community: https://techprimers.slack.com
💥 Twitter: https://twitter.com/TechPrimers
💥 Facebook: http://fb.me/TechPrimers
💥 GitHub: https://github.com/TechPrimers or https://techprimers.github.io/

🎬Video Editing: FCP


🔥 Disclaimer/Policy:
The content/views/opinions posted here are solely mine and the code samples created by me are open sourced.
You are free to use the code samples in Github after forking and you can modify it for your own use.
All the videos posted here are copyrighted. You cannot re-distribute videos on this channel in other channels or platforms.
#Istio #EKS #ServiceMesh

#istio #eks #kiali #jaeger

Istio on EKS in 30minutes | Istio Service Mesh | Zero to Hero | Kiali and Jaeger usage
Mireille  Von

Mireille Von

1625305560

Jaeger Tracing with Spring Boot | Distributed Log Tracing in Spring Boot | Tech Primers

This video covers the usage of Jaeger with Spring Boot with jaeger-client and jaeger-server microservices.

📌 Related Links

🔗 Jaeger: https://www.jaegertracing.io/
🔗 Numbers API: http://numbersapi.com/
🔗 Github code: https://github.com/TechPrimers/spring-boot-jaeger-example

📌 Related Videos

🔗 What is Spring Cloud Sleuth - https://youtu.be/VHTli6KQO54
🔗 Distributed log tracing in Microservices using Spring Cloud Sleuth https://youtu.be/gPKJkY2t7Pc

📌 Related Playlist

🔗Spring Boot Primer - https://www.youtube.com/playlist?list=PLTyWtrsGknYegrUmDZB6rcqMotOFZKvbn
🔗Spring Cloud Primer - https://www.youtube.com/playlist?list=PLTyWtrsGknYeOJHtd3Ll93GRf28hrjlHV
🔗Spring Microservices Primer - https://www.youtube.com/playlist?list=PLTyWtrsGknYdZlO7LAZFEElWkEk59Y2ak
🔗Spring JPA Primer - https://www.youtube.com/playlist?list=PLTyWtrsGknYdt079e1pyvpgLrJ48RQ1LK
🔗Java 8 Streams - https://www.youtube.com/playlist?list=PLTyWtrsGknYdqY_7lwcbJ1z4bvc5yEEZl
🔗Spring Security Primer - https://www.youtube.com/playlist?list=PLTyWtrsGknYe0Sba9o-JRtnRlkl4gXMQl

💥 Join TechPrimers Slack Community: https://bit.ly/JoinTechPrimers
💥 Telegram: https://t.me/TechPrimers
💥 TechPrimer HindSight (Blog): https://medium.com/TechPrimers
💥 Website: http://techprimers.com
💥 Slack Community: https://techprimers.slack.com
💥 Twitter: https://twitter.com/TechPrimers
💥 Facebook: http://fb.me/TechPrimers
💥 GitHub: https://github.com/TechPrimers or https://techprimers.github.io/

🎬Video Editing: FCP


🔥 Disclaimer/Policy:
The content/views/opinions posted here are solely mine and the code samples created by me are open sourced.
You are free to use the code samples in Github after forking and you can modify it for your own use.
All the videos posted here are copyrighted. You cannot re-distribute videos on this channel in other channels or platforms.
#Jaeger #SpringBoot #TechPrimers

#jaeger #spring boot

Jaeger Tracing with Spring Boot | Distributed Log Tracing in Spring Boot | Tech Primers
Nat  Grady

Nat Grady

1625127226

Microservices on Knative with Spring Boot and GraalVM

In this article, you will learn how to run Spring Boot microservices that communicate with each other on Knative. I also show you how to prepare a native image of the Spring Boot application with GraalVM. Then we will run it on Kubernetes using Skaffold and the Jib Maven Plugin.

This article is the second in a series of my article about Knative. After publishing the first of them, Spring Boot on Knative, you were asking me about a long application startup time after scaling to zero. That’s why I resolved this Spring Boot issue by compiling it to a native image with GraalVM. The problem with startup time seems to be an important thing in a serverless approach.

On Knative you can run any type of application – not only a function. In this article, when I’m writing “microservices”, in fact, I’m thinking about service to service communication.

Source Code

If you would like to try it by yourself, you may always take a look at my source code. In order to do that you need to clone my GitHub repository. Then you should just follow my instructions

As the example of microservices in this article, I used two applications callme-service and caller-service. Both of them exposes a single endpoint, which prints a name of the application pod. The caller-service application also calls the endpoint exposed by the callme-service application.

On Kubernetes, both these applications will be deployed as Knative services in multiple revisions. We will also distribute traffic across those revisions using Knative routes. The picture visible below illustrates the architecture of our sample system.

1. Prepare Spring Boot microservices

2. Prepare Spring Boot native image with GraalVM

3. Run native image on Knative with Buildpacks

4. Run native image on Knative with Jib

5. Communication between microservices on Knative

6. Configure tracing with Jaeger

#kubernetes #microservices #spring boot #jaeger

Microservices on Knative with Spring Boot and GraalVM

Introducing : Tracing Cassandra with Jaeger

Monitoring and debugging microservices and distributed systems is not trivial. With the rise of containers and ephemeral infrastructure, it is even more critical to have all the data available for the applications. The monitoring as of today is usually done across three axes: metric monitoring, logs, and distributed tracing

Stop reverse engineering applications and start monitoring from the inside.

—Kelsey Hightower, Monitorama 2016

#jaeger #cassandra #observability

Introducing : Tracing Cassandra with Jaeger