分散トレーシングの概要

プログラムログは、コード実行プロセスのパンくずリストです。これらのパンくずリストを検索すると、コードに隠されたバグが見つかるだけではありません: fontawesome-solid-bug: さらに重要なのは、継続的なプログラムログ追跡により、監視可能なプログラム実行プロセスを構築する方法が提供されることです。

ログから始める¶

存在するのはログファイルだけです

追跡システムが登場する前は、システムの稼働状況を取得する唯一の方法はローカルログを介することでした。実際、追跡システムが導入される前は、ログサービスはさまざまな種類の製品について数世代の反復を経ていました。

標準出力と標準エラー出力をローカルファイルに配置し、魔法のオペレーティングシステムの力を利用することで、理想的には無限のプログラム実行ログを取得できます。システムがクラッシュせず、単一点エラーがなく、ファイル書き込みフローを中断するプロセスがない限り、いつでもプロセス実行ファイルのコピーを取得して、非常に大きなファイル内で関心のあるイベントを検索できます。

トレーシング登場以前¶

ログサーバー

プログラムにとってプログラムログの重要性により、独立したログサーバーが誕生しました。はい、SPoF について心配する必要はありません。ログサーバーは固定ポートで待機し、プロセスによって送信されるプログラムログを継続的に記録します。

ログサーバーの初期段階では、操作インターフェイスが端末からブラウザに変わり、取得できるログが単一のプログラムから複数のプログラムに変わったことを除けば、ファイルサーバーに似た働きをしていました。しかし、記録されるログは、プロセスの実行順序の記録が山積みされた同じログです。以下は、ログインサーバー上のログをシミュレートします。

classDiagram
  class LoginAPI {
    name: login server
    host: localhost
    port: 8080
    dscp: print some descriptive information
    ...
    1978-03-12 xx:xx:xx file:api.js line:232 call checkToken()
    1978-03-12 xx:xx:xx file:api.js line:178 call parseParameters()
    1978-03-12 xx:xx:xx file:api.js line:348 call validate()
    1978-03-12 xx:xx:xx file:api.js line:456 call callRedis()
    1978-03-12 xx:xx:xx file:api.js line:79 call callMysql()
    1978-03-12 xx:xx:xx file:api.js line:914 call writeBack()
  }

ログテキストには孤立したプログラムイベントのみが表示され、実行ドキュメントからプログラムの実行状況を把握することは困難です。ファイルサーバーの後段では、ログの表示と一連のプログラム実行環境ステータスパラメーターに特化した UI が登場しました。この段階のログサービスは、ログファイルに基づくデータベースサービスに似ています。はい、気になるプログラムイベントをよりスムーズに検索することができます。

トレーシングシステム¶

オブザーバビリティの台頭

プログラムトレースシステムは、より高度なログサービスではありません。これはロギングカテゴリにも属しませんが、本物のパンくずリストです。トレースシステムは、プロセスの実行中に実行ステータスデータ構造 (Span) を生成します。処理フローが段階的に進むにつれて、多数のスパンが実行順序に従って接続され、現在のプロセスのトレース (Tracing) が形成されます。複数のプロセスが呼び出し順序に従って接続され、現在のシステムの観察可能な実行ステータスが形成されます。

架空のログインサービスを例に挙げてみましょう。

graph LR
  A(UserInterface) -->|input| B{LoginAPI};
  B -->|check token| C{RedisServer};
  B -->|update database probably| D{MysqlServer};

上の図は、マルチプロセスの下で追跡システムによって生成されたトレース図のみを示しています。実際、追跡システムでは、各実行プロセスのステータスをログのように確認することもできます。必要に応じて、レポートされたステータスデータ構造 (Span) の各フィールドをカスタマイズし、意味を与えることができます。トレースシステムはデバッグには使用されません。もちろん、トレースシステムではバグは逃れられません。トレースシステムは、システムの実行ステータスを詳細に記述することでシステムの問題を発見し、それによってバージョンの反復を促進し、システムを継続的に改善するための正のフィードバックメカニズムを提供します。

追跡システムは主に 2 つのレベルの問題を解決します

ステータスデータの収集方法

監視対象システムが依存するテクノロジースタックに基づいて、市場で一般的な追跡システムソリューションは、完全自動データ収集方法と手動データ収集方法を提供します。システムトレースは、NodeJS、JAVA、C# などのプログラムのランタイムを監視することによって完了します。このタイプのテクノロジスタックに基づくすべてのシステム実装は、完全に自動化されたシステムトレースを実行できます。同時に、トレースシステムはすべてのテクノロジスタックにトレースライブラリを提供し、プロジェクトに依存関係を導入し、簡単なコード編集を実行することで、完全に手動でシステムトレースを実行できるようになります。

状態データを整理する方法

プログラム実行中の自然な呼び出しと呼び出しの関係により、市場のすべての追跡システムが状態データ構造定義を親子関係で接続できるようになります。 ParentID と ID を使用して、呼び出し元と呼び出し先によって生成されたスパンを関連付けます。同じプロセス内の異なる呼び出しプロセス (同時環境内のスレッドを含む) は、呼び出し元 ID を含むコンテキストを渡すことによって、親プロセスと子プロセスを接続します。異なるプロセス間では、呼び出し元は、異なるプロセス間で (プロセス間で通信できるネットワークやパイプなどを介して) 独自の ID を含むコンテキストを送信することで、親プロセスを子プロセスに関連付けます。

トレーシングシステムのソリューション¶

プログラムパフォーマンスモニタリング（APM）市場において、プログラムを追跡する機能は不可欠であると言えます。ここでは、市場にあるいくつかの一般的なソリューションを簡単に紹介します。

DataDog

: 現在最も完全な APM ソリューションプロバイダーであり、運用環境のプログラムの監視と詳細な視覚化機能を提供します。ネットワークサービス、メッセージキュー、データベースのすべてのプログラムイベントを監視するための、すぐに使用できるパフォーマンス監視ダッシュボードを提供します。トレーストレースデータは、サービスおよびコンテナ全体で、セッション、ログ、システムプロファイル、包括的な検出、ネットワーク、プロセス、および基本的なシステムメトリクスセットとシームレスに関連付けることができます。 DataDog では、システムのボトルネックによって引き起こされる低速トレースを調査するときに、問題の原因となっているコードを直接見つけることができます。

Jaeger

：Jaeger は、Dapper と OpenZipkin からインスピレーションを受け、Uber Technologies によってリリースされたオープンソースの分散プログラムトレースシステムです。特にマイクロサービスアーキテクチャに基づいたシステムの監視に適しており、次の機能を提供します。 : - 分散コンテキストの伝播 : - 分散トランザクション監視 : - 根本原因を追跡する分析能力 : - サービスの依存関係の分析 : - パフォーマンスの最適化 : Jaeger に興味がある場合は、Uber 技術チームの社内慣行を参照してください。

OpenTelemetry

: OpenTelemetry (OTel) は、トレース、メトリクス、ログなどのテレメトリデータを生成、収集、エクスポートするための API、SDK、仕様、およびツールを提供するベンダー中立の可観測性フレームワークです。 OpenTelemetry 自体は可観測性バックエンドではないため、収集されたデータは処理と保存のために DataKit などの受信側に送信される必要があります。

SkyWalking

: SkyWalking は、分散クラウドシステムの監視、トレース、診断、その他の機能を提供するオープンソース APM システムです。コア機能は次のとおりです。 : - サーバー側メトリクスセット分析 : - 根本原因を追跡する分析能力 : - サービストポロジ分析 : - サービスの依存関係の分析 : - サービス検出が遅い : - パフォーマンスの最適化 :- キャッシュの監視、読み取りおよび書き込みのパフォーマンス、低速アクセスの検出 : - データベース監視、クエリ検出が遅い : - メッセージキューのパフォーマンス監視 : - ブラウザのパフォーマンステスト、ルート追跡機能 : - インフラストラクチャ監視は、主流のクラウドプロバイダーをサポートします。 : - システムアラーム

Zipkin

: Zipkin は、システム監視を完了し、サービスレベルのシステム問題を発見するために連続データを収集するために使用される分散トレースシステムです。 Zipkin は、データ収集とデータクエリを含む統合ソリューションを提供します。 TraceID に基づいて Zipkin の UI でログからトレースに直接ジャンプでき、さまざまなデータに基づいた検索機能を提供します。

DataKit

: DataKit が提供するソリューションは、上記の追跡システムとは異なり、プログラムの実行状況データ (Span) を生成したり、データの構成形式を変更したりすることはありません。 DataKit はネットワークポートをリッスンして、主要な追跡システムから送信されたトレースデータを受信します。 DataKit の追跡モジュールは、すぐに使える機能を提供するだけでなく、構成をほとんど必要としません。ユーザーは他の追跡システムから DataKit にスムーズに移行できます。

: DataKit は連携データ処理・分析ネットワークサービスです。 DataKitはネットワークアプリケーションとして以下のような特徴を持っています。

: - DataKit は高負荷のトラフィックデータを継続的に処理できます。 DataKit 内で使用されるマルチチャネルローカルキャッシュテクノロジは、実際にフラッディングレベルのトレースデータに直面しても、低い CPU 負荷で良好な動作を維持できます。 : - DataKit は、同時性の高いネットワークリクエスト環境でも動作し続けることができます。 DataKit は内部でアクセスポリシーとスレッドプールを使用して、高度な同時ネットワーク要求に対処し、CPU 負荷を低い範囲に制御します。 : - DataKit は、市場のさまざまな主流の追跡システムに摩擦なく接続でき、現在も拡張されています。

：DataKitは分析・計算ツールとして以下のような特徴を持っています。

: - 柔軟性と構成可能性が高く、DataKit のトレースデータ機能を構成なしで使用できます。また、サンプリング、まれなトレースの選択、リソースのクローズなど、DataKit が提供するさまざまなトレースコンピューティング機能を簡単な構成でカスタマイズすることもできます。 : - 効率的で分散された一貫したサンプリングアルゴリズム。 : - データ処理のフロントエンドにあるさまざまなデータ処理フィルターは、日々のデータ処理ニーズを満たします。 : - データ処理バックエンド Pipeline サポート。Guance が提供する強力なPipeline スクリプトを使用して、センターに送信される前にデータをカスタマイズできます。

まとめ¶

トレースシステムは、システムの実行状況を多次元かつ詳細に可視化する機能を提供し、システムの保守開発の形を変えるだけでなく、開発コストと運用コストを大幅に削減します。また、システムのボトルネックを発見し、その後のシステムバージョンの反復のための貴重な手がかりを提供するためのさまざまな分析ツールも提供します。