実際のOpenTelemetry

最近では、OpenTracingとOpenCensusの2つの標準がついに1つに統合されました。分散トレースとモニタリングの新しい標準であるOpenTelemetryが登場しました。しかし、ライブラリの開発が本格化しているにもかかわらず、実際に使用した経験はあまりありません。



8年間開発を続け、MTSでバックエンド開発者として働いているIlya Kaznacheevは、GolangプロジェクトでOpenTelemetryを使用する方法を共有する準備ができています。 Golang Live 2020会議で、彼は、トレースと監視のための新しい標準の使用を設定し、プロジェクトにすでに存在するインフラストラクチャとそれを友達にする方法について話しました。





OpenTelemetryは比較的最近の標準であり、昨年末になりました。同時に、彼はトレースと監視のためのソフトウェアの多くのベンダーから幅広い配布とサポートを受けました。



可観測性、または可観測性は、外部の兆候によってシステムの内部状態をどれだけ判断できるかを決定する制御理論からの用語です。システムアーキテクチャでは、これは実行時にシステムの状態を監視するための一連のアプローチを意味します。これらのアプローチには、ロギング、トレース、および監視が含まれます。







トレースと監視のための多くのベンダーソリューションがあります。最近まで、2016年に登場したCNCFのOpenTracingと2018年に登場したGoogleのOpenCensusの2つのオープンスタンダードがありました。



これらは、2019年に、OpenTelemetryと呼ばれる1つの新しい標準に統合することを決定するまで、しばらくの間互いに競合していた2つの非常に優れた標準です。







この標準には、分散トレースと監視が含まれます。最初の2つと互換性があります。さらに、OpenTracingとOpen Censusは2年以内にサポートを終了しており、必然的にOpenTelemetryへの移行に近づいています。



使用シナリオ



この標準は、すべてをすべてと組み合わせるための十分な機会を想定しており、実際、メトリックとトレースのソースとそのコンシューマーの間のアクティブなレイヤーです。

主なシナリオを見てみましょう。



分散トレースの場合、Jaegerまたは使用しているサービスへの接続を直接設定できます。







トレースが直接ブロードキャストされる場合は、configを使用して、ライブラリを置き換えることができます。



アプリケーションですでにOpenTracingを使用している場合は、OpenTracing Bridgeを使用できます。これは、OpenTracingAPIへのリクエストをトップレベルのOpenTelemetryAPIに変換するラッパーです。







メトリックを収集するために、アプリケーションのメトリックポートに直接アクセスするようにPrometheusを構成することもできます。







これは、単純なインフラストラクチャがあり、メトリックを直接収集する場合に役立ちます。しかし、この規格はさらに柔軟性を提供します。



標準を使用するための主なシナリオは、コレクターを介してメトリックとトレースを収集することです。コレクターは、別のアプリケーションまたはコンテナーによってインフラストラクチャーに起動されます。また、既製の容器を持って自宅に設置することもできます。



これを行うには、アプリケーションでOTLP形式でエクスポーターを構成するだけで十分です。これは、OpenTracing形式でデータを送信するためのgrpcスキームです。コレクター側から、メトリックとトレースをエンドユーザーまたは他の形式にエクスポートするための形式とパラメーターを構成できます。たとえば、OpenCensusでは。







コレクターを使用すると、出力で多数のタイプのデータソースと多くのデータシンクを接続できます。







したがって、OpenTelemetry標準は、多くのオープンソースおよびベンダー標準との互換性を提供します。



標準のマニホールドは拡張可能です。したがって、ほとんどのベンダーは、もしあれば、すでに独自のソリューションの準備ができている輸出業者を持っています。独自のベンダーからメトリックとトレースを収集する場合でも、OpenTelemetryを使用できます。これにより、ベンダーのロックインに関する問題が解決されます。 OpenTelemetryに直接表示されていないものがある場合でも、OpenCensusを介して転送できます。



コレクター自体は、通常のYAML構成を使用して非常に簡単に構成できます







。レシーバーはここで指定されます。アプリケーションには他のソース（Kafkaなど）がある場合があります







。エクスポーター-データ受信者。

プロセッサ-コレクタ内でデータを処理する方法：







そして、コレクター内を流れる各データストリームがどのように処理されるかを直接定義するパイプライン：







1つの実例を見て​​みましょう。







すでにOpenTelemetryをねじ込み、構成したマイクロサービスがあるとします。そして、同様の断片化を伴うもう1つのサービス。



これまでのところ、すべてが簡単です。しかし、次のものがあります。

• OpenCensusを介して実行されるレガシーサービス。
• 独自の形式でデータを送信するデータベース（たとえば、PostgreSQLのように直接Prometheusに）。
• コンテナ内で機能し、独自の形式でメトリックを提供するその他のサービス。このコンテナを再構築してサイドカーを台無しにして、メトリックを再フォーマットすることは望ましくありません。あなたはそれらを拾って送りたいだけです。
• メトリックも収集し、何らかの方法でそれらを使用したいハードウェア。

これらのメトリックはすべて、1つのコレクターに組み合わせることができます。







既存のアプリケーションで使用されるメトリックとトレースの多くのソースをすでにサポートしています。また、エキゾチックなものを使用している場合は、独自のプラグインを実装できます。しかし、これが実際に必要になる可能性は低いです。メトリックまたはトレースを何らかの方法でエクスポートするアプリケーションは、いくつかの一般的な標準またはOpenCensusなどのオープン標準のいずれかを使用するためです。



ここで、この情報を使用します。Jaegerをトレースのエクスポーターとして指定し、メトリックをPrometheusまたは互換性のあるものに送信できます。みんなのお気に入りのVictoriaMetricsとしましょう。



しかし、突然AWSに移行して、ローカルのX-Rayトレーサーを使用することにした場合はどうなるでしょうか。問題ない。これは、X ‑RayのエクスポーターがあるOpenCensusを介して転送できます。



したがって、これらの部分から、メトリックとトレースのためにすべてのインフラストラクチャを組み立てることができます。



理論は終わりました。実際にトレースを使用する方法について話しましょう。



Golangアプリケーションのインストルメンテーション：トレース



最初に、呼び出しツリーが成長するルートスパンを作成する必要があります。

ctx := context.Background()
tr := global.Tracer("github.com/me/otel-demo")
ctx, span := tr.Start(ctx, "root")
span.AddEvent(ctx, "I am a root span!")
doSomeAction(ctx, "12345")
span.End()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

これは、サービスまたはライブラリの名前です。このようにして、アプリケーションのフレームワーク内にあるトレース内のスパンと、インポートされたライブラリに送信されたスパンを定義できます。



次に、ルートスパンが次の名前で作成されます。

ctx, span := tr.Start(ctx, "root")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

トレースレベルを明確に説明する名前を選択してください。たとえば、メソッド（またはクラスとメソッド）の名前またはアーキテクチャ層のいずれかになります。たとえば、インフラストラクチャレイヤー、ロジックレイヤー、データベースレイヤーなどです。



スパンデータもコンテキストに入れられます。

ctx, span := tr.Start(ctx, "root")
span.AddEvent(ctx, "I am a root span!")
doSomeAction(ctx, "12345")

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

したがって、トレースするメソッドをコンテキストに渡す必要があります。



スパンは、コールツリーの特定のレベルのプロセスを表します。発生した場合は、属性、ログ、エラーステータスを含めることができます。スパンは最後に閉じる必要があります。閉じている場合、その期間が計算されます。

ctx, span := tr.Start(ctx, "root")
span.AddEvent(ctx, "I am a root span!")
doSomeAction(ctx, "12345")
span.End()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

これがJaegerでのスパンの外観







です。スパン を展開してログと属性を確認できます。



次に、新しいスパンを設定したくない場合は、コンテキストから同じスパンを取得できます。たとえば、1つのスパンに1つのアーキテクチャレイヤーを記述し、レイヤーが複数のメソッドと複数の呼び出しレベルに分散しているとします。あなたはそれを手に入れ、それに書き込み、そしてそれは閉じます。

func doSomeAction(ctx context.Context, requestID string) {
      span := trace.SpanFromContext(ctx)
      span.AddEvent(ctx, "I am the same span!")
      ...
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

作成時と同じ方法で閉じるため、ここで閉じる必要はありません。私たちはそれを文脈から外しているだけです。



ルートスパンへのメッセージの書き込み：







個別に存在するように、新しい子スパンを作成する必要がある場合があります。

func doSomeAction(ctx context.Context, requestID string) {
   ctx, span := global.Tracer("github.com/me/otel-demo").
      Start(ctx, "child")
   defer span.End()
   span.AddEvent(ctx, "I am a child span!")
   ...
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

ここで、libraryという名前のグローバルトレーサーを取得します。この呼び出しは、サービス全体で同じになるため、何らかのメソッドでラップすることも、グローバル変数を使用することもできます。



次に、コンテキストから子スパンが作成され、最初に行ったのと同じように、名前が割り当てられます。

   Start(ctx, "child")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

作成されたメソッドの最後でスパンを閉じることを忘れないでください。

  ctx, span := global.Tracer("github.com/me/otel-demo"). 
      Start(ctx, "child") 
   defer span.End()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

子スパンに該当するメッセージを書き込みます。







ここでは、メッセージが階層的に表示され、子スパンが親の下にあることがわかります。同期呼び出しだったため、短くなると予想されます。



スパンに書き込むことができる属性を示しています。

func doSomeAction(ctx context.Context, requestID string) {
      ...
      span.SetAttributes(label.String("request.id", requestID))
      span.AddEvent(ctx, "request validation ok")
   span.AddEvent(ctx, "entities loaded", label.Int64("count", 123))
      span.SetStatus(codes.Error, "insertion error")
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

たとえば、リクエストはここにあります。id：







イベントを追加できます：

   span.AddEvent(ctx, "request validation ok")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

また、ここでラベルを追加できます。これは、logrus形式の構造化ログとほぼ同じように機能します。

span.AddEvent(ctx, "entities loaded", label.Int64("count", 123))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

ここでは、スパンログにメッセージが表示されます。展開してラベルを表示できます。この例では、ラベルカウントがここに追加されてい







ます。検索でフィルタリングするときに使用すると便利です。



エラーが発生した場合は、スパンにステータスを追加できます。この場合、無効としてマークされます。

  span.SetStatus(codes.Error, "insertion error")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

OpenCensusからのエラーコードを使用するために使用される標準であり、それらはgrpcからのものでした。これで、OK、ERROR、およびUNSETのみが残ります。 OKがデフォルトで、エラーの場合はERRORが追加されます。



ここでは、エラートレースが赤いアイコンでマークされていることがわかります。エラーコードとそれに関するメッセージがあります







。トレースはログの代わりではないことを忘れてはなりません。重要な点は、分散システムを介した情報の流れを追跡することです。このためには、ネットワーク要求にトレースを入れて、そこから読み取ることができるようにする必要があります。



トレースマイクロサービス



OpenTelemetryには、さまざまなフレームワークとライブラリ用のインターセプターとミドルウェアの多くのセットパーティ実装がすでにあります。それらはリポジトリにあります： github.com/open-telemetry/opentelemetry-go-contrib



インターセプターとミドルウェアが存在するフレームワークのリスト：

• ビーゴ
• 落ち着いて
• ジン
• gocql
• マックス
• エコー
• http
• grpc
• サラマ
• memcache
• モンゴ
• マカロン

例として、標準のhttpクライアントとサーバーを使用してこれを使用する方法を見てみましょう。



ミドルウェアクライアント



クライアントでは、トランスポートとしてインターセプターを追加するだけです。その後、リクエストはtrace.idとトレースを続行するために必要な情報で強化されます。

client := http.Client{
      Transport: otelhttp.NewTransport(http.DefaultTransport),
}
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
resp, err := client.Do(req)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

ミドルウェアサーバー



ライブラリの名前を持つ小さなミドルウェアがサーバーに追加されます。

http.Handle("/", otelhttp.NewHandler(
      http.HandlerFunc(get), "root"))
err := http.ListenAndServe(addr, nil)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

次に、いつものように、コンテキストからスパンを取得し、それを操作し、何かを書き込み、子スパンを作成し、それらを閉じます。



これは、3つのサービスを通過する、単純な要求の外観です







。スクリーンショットは、呼び出しの階層、サービスへの分割、それらの期間、シーケンスを示しています。それぞれをクリックすると、より詳細な情報が表示されます。



そして、これはエラーがどのように見えるかです：







それが起こった場所、いつ、どれくらいの時間が経過したかを追跡するのは簡単です。

スパンでは、エラーが発生したコンテキストに関する詳細情報を確認できます。







さらに、スパン全体を参照するフィールド（さまざまなリクエストID、リクエスト内のテーブルのキーフィールド、配置するその他のメタデータ）は、作成時にスパンにネストできます。大まかに言えば、これらすべてのフィールドをコピーして、エラーを処理するすべての場所に貼り付ける必要はありません。あなたはそれについてのデータをスパンするように書くことができます。



ミドルウェア機能



ここに少しボーナスがあります：ゴリラやジンのようなもののためのグローバルミドルウェアとしてそれを使用できるようにミドルウェアを作る方法：

middleware := func(h http.Handler) http.Handler {
      return otelhttp.NewHandler(h, "root")
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Golang Application Instrumentation：モニタリングモニタリング



について話す時が来ました。



監視システムへの接続は、トレースの場合と同じ方法で構成されます。



測定は2つのタイプに分けられます：



1。同期、ユーザーが呼び出し時に明示的に値を渡す場合：

• カウンター
• UpDownCounter
• ValueRecorder

int64、float64



2.非同期。SDK は、アプリケーションからのデータ収集時に次のように読み取ります。

• SumObserver
• UpDownSumObserver
• ValueObserver

int64、float64



メトリック自体は次のとおりです。

• 正の数を合計し、減少しない加法および単調（Counter、SumObserver）。
• 正と負の数を合計できる、単調ではなく加法（UpDownCounter、UpDownSumObserver）。
• 値のシーケンスを単に記録する非加法（ValueRecorder、ValueObserver）。たとえば、ある種の配布。

プログラムの開始時に、グローバルメーターが作成され、ライブラリまたはサービスの名前が示されます。

meter := global.Meter("github.com/ilyakaznacheev/otel-demo")
floatCounter := metric.Must(meter).NewFloat64Counter(
         "float_counter",
         metric.WithDescription("Cumulative float counter"),
   ).Bind(label.String("label_a", "some label"))
defer floatCounter.Unbind()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

次に、メトリックが作成されます。

floatCounter := metric.Must(meter).NewFloat64Counter(
         "float_counter",
         metric.WithDescription("Cumulative float counter"),
   ).Bind(label.String("label_a", "some label"))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

彼女には名前が付けられています：

   "float_counter",
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

説明：

…
         metric.WithDescription("Cumulative float counter"),
…
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

リクエストをフィルタリングするためのラベルのセット。たとえば、Grafanaでダッシュボードを作成する場合：

…
    ).Bind(label.String("label_a", "some label"))
…

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

プログラムの最後に、メトリックごとにUnbindを呼び出す必要があります。これにより、リソースが解放され、正しく閉じられます。

…
defer floatCounter.Unbind()
…

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

変更の記録は簡単です。

var (
counter metric.BoundFloat64Counter
udCounter metric.BoundFloat64UpDownCounter
valueRecorder metric.BoundFloat64ValueRecorder
)
...
counter.Add(ctx, 1.5)
udCounter.Add(ctx, -2.5)
valueRecorder.Record(ctx, 3.5)

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

これらは、Counterの正の数値、合計されるUpDownCounterの数値、およびValueRecorderの数値です。すべての種類の機器で、Goはint64とfloat64をサポートしています。



これが出力で得られるものです。

# HELP float_counter Cumulative float counter
# TYPE float_counter counter
float_counter{label_a="some label"} 20
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

これは、コメントと特定のラベルが付いたメトリックです。次に、Prometheusから直接取得するか、OpenTelemetryコレクターからエクスポートして、必要な場所で使用できます。



Golang Application Instrumentation：ライブラリ



私が言いたい最後のことは、標準がインストルメンテーションライブラリに提供する機能です。



以前は、OpenCensusとOpenTracingを使用する場合、個々のライブラリ、特にオープンソースライブラリをインストルメント化できませんでした。この場合、ベンダーのロックインが発生したためです。トレースを密接に扱ったことのある人なら誰でも、大規模なクライアントライブラリやクラウドサービス用の大規模なAPIが、説明しにくいエラーでクラッシュすることがあるという事実におそらく注意を払っています。



ここでは、トレースが非常に役立ちます。特に生産性の面では、なんらかの不明確な状況があり、なぜそれが起こったのかを知りたいと思います。ただし、インポートしたライブラリからのエラーメッセージだけが表示されます。



OpenTelemetryはこの問題を解決します。







SDKとAPIは標準で分離されているため、SDKや特定のデータエクスポート設定に関係なく、メトリックトレースAPIを使用できます。さらに、最初にメソッドをインストルメント化してから、このデータの外部へのエクスポートを構成することができます。

このようにして、データをエクスポートする方法と場所を気にすることなく、インポートしたライブラリをインストルメント化できます。これは、内部ライブラリとオープンソースライブラリの両方で機能します。



ベンダーのロックインについて心配する必要はありません。この情報がどのように使用されるか、またはまったく使用されるかどうかについて心配する必要はありません。ライブラリとアプリケーションは事前にインストルメント化されており、データエクスポート構成はアプリケーションの初期化時に指定されます。



したがって、構成設定がSDKアプリケーションで設定されていることがわかります。次に、トレースとメトリックのエクスポーターに対処する必要があります。 OpenTelemetryコレクターにエクスポートする場合は、OTLPを介して1つのエクスポーターにすることができます。次に、必要なすべてのトレースとメトリックがコンテキストに分類され、別のメソッドによって呼び出しツリーに伝播されます。



アプリケーションは、OpenTelemetry APIとコンテキスト内のデータを使用するだけで、残りのスパンをルートスパンから継承します。この場合、インポートされたライブラリは入力としてコンテキストメソッドを受け取り、このメソッドからルートスパンに関する情報を読み取ろうとします。そこにない場合は、独自に作成してから、ロジックに指示します。このようにして、最初にライブラリをインストルメント化できます。



さらに、すべてをインストルメント化することはできますが、データエクスポーターを構成することはできず、デプロイするだけです。



これは本番環境で機能する可能性があり、インフラストラクチャが安定するまで、トレースと監視を構成することはできません。次に、それらを構成し、そこにコレクター、このデータを収集するためのいくつかのアプリケーションをデプロイすると、すべてが機能します。メソッド自体で直接何も変更する必要はありません。



したがって、オープンソースライブラリがある場合は、OpenTelemetryを使用してインストルメント化できます。次に、それを使用する人々がOpenTelemetryを構成し、このデータを使用します。



結論として、OpenTelemetry標準は有望であると言いたいと思います。おそらく、最後に、これは私たち全員が見たかったのと同じ普遍的な標準です。



当社は、OpenCensus標準を積極的に使用して、会社のマイクロサービスランドスケープを追跡および監視しています。リリース後にOpenTelemetryを実装する予定です。