分散リンク トレースの使用方法は?

分散リンク トレースの使用方法は?

この記事はWeChatの公開アカウント「Invincible Coder」から転載したもので、著者はInvincible Coderです。この記事を転載する場合は、Wudi Coder の公開アカウントにご連絡ください。

2021年も心構えを整え、引き続き価値ある技術コンテンツをご提供してまいります。今後、私が執筆する技術コンテンツは、主に DevOps、Kubernetes、Service Mesh などの「クラウド ネイティブ」技術に関するものになる予定です。私がこうしたコンテンツを好んで書く理由は、一方では私自身の興味があり、他方では近年、Kubernetes を基盤とする「クラウドネイティブ」な技術体系が主流になってきたからです。開発者として、ビジネス コードの開発にのみ注力し、プログラム動作の基本的な環境とアーキテクチャ システムに関する十分な知識と理解が不足していると、成長と進歩につながりません。

もちろん、役に立つプログラミングテクニックや、プログラミング言語に関連する技術（Java 並行プログラミング、I/O、ネットワークなど）など、プログラミング技術に関する内容は引き続きお伝えしていきますが、市場で何度も書かれて繰り返されている技術的な内容や、さまざまなチキンスープ記事については書かないように努めます。皆様の時間を無駄にしないために！

はい、もうナンセンスはやめましょう！今回は「分散リンクトレーシング」の内容を紹介します。現在マイクロサービス アーキテクチャを採用しているほとんどの企業にとって、従来のマイクロサービス システムであれ、新世代のサービス メッシュ マイクロサービス アーキテクチャであれ、分散リンク トレーシングは必須です。紹介する具体的な内容については、この記事は完全に理論に関するものではなく、理論から実践へと操作できるように皆様を導くことを目的としています。そうすることでのみ、技術的なレベルから真に深い理解と認識を得ることができるからです。

分散リンク トレーシングの概要

分散リンクトラッキングシステムを詳しく紹介する前に、まずリンクトラッキングとは何かを理解する必要があります。このコラムの前のセクションで監視システムを紹介したところから、監視システムの観測データは主に統計指標、ログ、リンク追跡の 3 つの側面から得られることがわかります。これらのデータは、リクエスト レベルと集約レベルの 2 つのタイプに分けられます。

リクエスト レベルのデータは、主に HTTP 呼び出し、RPC 呼び出しなどの実際のリクエストから取得されます。この記事で紹介するリンク トラッキングは、このタイプです。集約レベルは、インターフェース要求のメトリック、または QPS、CPU 使用率、その他の値などの一部のパラメータ データの集約です。ログおよび統計インジケータ データは、実際のリクエストまたはシステム自体の診断中に記録された情報から取得される可能性があるため、リクエスト レベルまたは集計レベルのいずれかになります。

リンク トラッキングに関しては、その主なロジックは、要求されたリンクの完全な動作を記録し、リンク クエリ、パフォーマンス分析、依存関係、トポロジ マップなどの分散リンク トラッキング関連機能を視覚的な形式で実装できるようにすることです。次の図に示すように:

上の図では、マイクロサービス システム内のインターフェース呼び出しに関与するマイクロサービスが 2 つあり、それらの呼び出し関係は A->B->C であると想定されています。サービス B は Redis などのサードパーティ サービスとの呼び出し関係も持っており、サービス C も MySQL データベース サービスを呼び出す必要があります。したがって、実際にリンク トラッキングが行うことは、インターフェイス応答結果、時間消費など、完全なリンク A->B (B->Redis)->C (C->MySQL) の詳細な呼び出し情報を詳細に記録することです。

では、この通話リンクのデータはどのように記録されるのでしょうか?次に、上記の呼び出しチェーンを例として、リンク追跡情報の具体的な構成と伝送形式を分析し、分散リンク追跡システムの原理と概念をさらに理解します。具体的なロジック図は次のとおりです。

上図に示すように、分散リンクトラッキングで監視する対象は、繰り返し呼び出しによって生成されるリンクです。図の 1-8 は完全なリンク (Trace) を示しており、システムはそれを一意の識別子 (TraceId) を通じて記録します。リンク内の各依存呼び出しは、呼び出しトレース情報 (Span) を生成します。最初に生成される Span はルート Span と呼ばれます。後続の Span では、前の Span の識別子 (Sid) が Span 情報の親 ID (Pid) として使用されます。

同様に、リンクが実行されると、Span 情報はプロセス内またはプロセス間でコンテキスト内で渡されます。各リンク呼び出しによって生成されたトレース情報は、Span データ チェーンを通じて連続的に接続することができ、各 Span に添付されたログ情報 (アノテーション) が呼び出しチェーンの監視と分析のデータ ソースとなります。これが分散リンクトラッキングの基本原理です。

この時点で、「これほど大量のデータを監視すると、システム リソースが大量に消費されるのではないか」という疑問が生じるかもしれません。実際、ほとんどのリンク追跡システムには、システムによって収集されるリンク情報の割合を制御するためのサンプリング レートと呼ばれる設定があり、それによってシステムのパフォーマンスが向上します。多くの場合、大量のリンク情報は同一であり、比較的時間がかかり、エラーが多いリンクにのみ焦点を当てる必要があるかもしれませんが、100％を収集する必要はありません。

スカイウォーキング入門

先ほど、リンクトラッキングとは何かを基本原理の観点から説明しました。次に、最も人気のある分散リンク追跡システムである SkyWalking を紹介します。

SkyWalking は優れたオープンソース APM (アプリケーション パフォーマンス管理) システムであり、リンク トレースやリンク分析などの分散トレース機能を提供するだけでなく、パフォーマンス指標分析、アプリケーションとサービスの依存関係分析、サービス トポロジ分析、アラームなどの一連のアプリケーション パフォーマンス監視関連機能もサポートしており、問題を効果的に特定するのに役立ちます。

データ収集の観点から見ると、SkyWalking は、Java、.NET Core、NodeJS、PHP、Python などのさまざまな言語をサポートする非侵入型エージェント プローブや、サービス メッシュ アーキテクチャのサポートなど、さまざまなデータ ソースと形式をサポートしています。具体的な構造は以下の図の通りです。

上図に示すように、SkyWalking の中核は、リンク収集サーバー (Receiver Cluster) と集約サーバー (AggregatorCluster) で構成されています。レシーバー クラスターは、バックエンド サービス全体へのアクセス ポイントであり、特にさまざまなサービス インジケーターとリンク情報を収集するために使用されます。

AggregatorCluster は、コレクターによって収集されたデータを要約および集約し、最終的に集約されたデータをデータベースに保存するために使用されます。一般的な ElasticSearch、MySQL、TIDB など、具体的なストレージ方法は多数あり、実際のニーズに応じて選択できます。これらの集約されたデータは、後でアラーム設定に使用できるほか、GUI/CLI などの可視化システムから HTTP 形式でアクセスして可視化することもできます。

さらに、データ収集ロジックの観点から、SkyWalking は複数の言語プローブとプロジェクト プロトコルをサポートしており、現在主流の分散テクノロジ スタックのほとんどをカバーできます。具体的には、次の 3 つのタイプがあります。

  • メトリクス システム: 統計システム。 Prometheus から SkyWalking へのメトリック データの直接プルをサポートし、プログラム自体が micrometer を介してデータをプッシュすることもサポートします。
  • エージェント: ビジネス調査。各種業務システムにプローブサービスを統合し、リンクトラッキング、つまりリンクデータ収集を行うことを指します。 SkyWalking は、Java、Go、.NET、PHP、NodeJS、Python、Nginx LUA など、複数の言語のプローブをサポートしています。さらに、gRPC または HTTP 経由のデータ転送もサポートしています。
  • サービス メッシュ: SkyWalking は、新世代のマイクロサービス アーキテクチャ サービス メッシュの監視もサポートします。特定のサービス メッシュ プロトコルを介してデータ プレーンとコントロール プレーンからデータを収集し、サービス メッシュ リンク データを監視できます。

上記の内容では、SkyWalking の基本的な状況を簡単に紹介し、そのシステム アーキテクチャを簡単に分析します。実際、SkyWalking は過去 2 年間で急速に発展し、コミュニティも非常に活発になっています。マイクロサービス リンク トラッキングやアプリケーション パフォーマンス モニタリングの分野でますます広く使用されています。スペースの都合上、ここでさらに詳細を共有することは不可能です。興味のある読者は、公式文書やコミュニティを通じてさらに詳しく知ることができます。

SkyWalkingのインストールと展開

前回のコンテンツでは、分散リンク トレーシングの基本原理を紹介し、SkyWalking に焦点を当てました。当然、この記事がここで終わってしまうと価値がなくなります。なぜなら、正しいナンセンスをたくさん述べているだけであり、読んだ後に忘れてしまうからです。これは明らかに私の共有スタイルと一致しません。次に、実験的な観点から SkyWalking を試してみることにします。

以下の内容は実際に実験操作が必要となります。地下鉄で不便な場合は、まず保存して、時間があるときに試してみるのもよいでしょう。

SkyWalking の展開には主にバックエンド OAP サーバーとフロントエンド UI が含まれ、実際のニーズに応じて物理マシン、仮想マシン、または Kubernetes クラスターに展開できます。環境の一貫性を示すために、SkyWalking のバックエンド サービスと UI をそれぞれ Kubernetes クラスターにデプロイすることを選択します。

SkyWalking をインストールする具体的な方法は、公式の Kubernetes デプロイメント ファイルを使用して Helm でインストールするか、Kubernetes デプロイメント ファイルを手動で書き込むことです。ここでは、学習のしやすさを考慮して後者の方法を使用します。具体的な手順は次のとおりです。

1) Kubernetes クラスターに名前空間を作成し、別の SkyWalking コンテナを実行します。コマンドは次のとおりです。

  1.  #kubectl経由でKubernetesクラスターに接続し、名前空間コマンドを作成する
  2. $ kubectl作成ns スカイウォーキング

コマンドを実行した後、名前空間が正常に作成されたかどうかを確認できます。コマンドは次のとおりです。

  1.  # 名前空間の作成ステータスを確認する
  2. $ kubectl get ns
  3. 名前ステータス 年齢
  4. デフォルトアクティブ10d
  5.  kube-node-lease アクティブ 10d
  6.  kube-パブリックアクティブ 10d
  7.  kube システム アクティブ 10d
  8.  kubernetes-dashboard アクティブ 10d
  9. スカイウォーキング アクティブ46

空中歩行空間がうまく構築されていることがわかります！

2) SkyWalking-UIとOAP ServerサービスのKubernetesデプロイメントファイルを作成する

特定の Kubernetes デプロイメント ファイルを作成するときは、SkyWalking-UI と OAP Server のコンテナ イメージを指定する必要があります。一般的に言えば、ソース コードを通じて手動でパッケージ化することも、公式にパッケージ化されたイメージを直接使用することもできます。デモンストレーションの便宜上、ここでは Docker 公式イメージ リポジトリにパッケージ化されたイメージを使用します。図に示すように:

上記の 2 つの画像に示すように、Docker Hub の公式イメージ リポジトリで、SkyWalking-UI と OAP Server の公式リリースされたコンテナー イメージ バージョンが見つかりました。次に、特定のデプロイメントファイルを作成します。

SkyWalking サーバーの Kubernetes デプロイメント ファイル (skywalking-aop.yml) を記述します。具体的な内容は以下のとおりです。

  1.  APIバージョン: アプリ/v1
  2. 種類: デプロイメント
  3. メタデータ:
  4. 名前:oap
  5.   名前空間: スカイウォーキング
  6. 仕様:
  7.   レプリカ: 1
  8.   セレクタ：
  9.     一致ラベル:
  10.       アプリ: oap
  11.       リリース: スカイウォーキング
  12.   テンプレート：
  13.     メタデータ:
  14.       ラベル:
  15.         アプリ: oap
  16.         リリース: スカイウォーキング
  17.     仕様:
  18.       コンテナ:
  19.         -名前:oap
  20.           #OAPサーバーコンテナイメージとバージョン情報を指定します
  21.           イメージ: apache/skywalking-oap-server:8.3.0-es7
  22.           イメージプルポリシー: IfNotPresent
  23.           ポート:
  24.             - コンテナポート: 11800
  25. 名前: grpc
  26.             - コンテナポート: 12800
  27. 名前: レスト
  28. ---  
  29.  APIバージョン: v1
  30. 種類: サービス
  31. メタデータ:
  32. 名前:oap
  33.   名前空間: スカイウォーキング
  34.   ラベル:
  35.     サービス: oap
  36. 仕様:
  37.   ポート:
  38.     #安らかなポート
  39.     - ポート: 12800
  40. 名前: レスト
  41.      #rpc ポート
  42.     - ポート: 11800
  43. 名前: grpc
  44.     - ポート: 1234
  45. 名前: ページ
  46.   セレクタ：
  47.     アプリ: oap

上記は標準の Kubernetes デプロイメント ファイルです。ファイル内の関連命令の具体的な意味については、Kubernetes 関連の資料を参照してください。

SkyWalking-UI デプロイメント ファイル (skywalking-ui.yml) を記述します。具体的な内容は次のとおりです。

  1.  APIバージョン: アプリ/v1
  2. 種類: デプロイメント
  3. メタデータ:
  4. 名前: ui-deployment
  5.   名前空間: スカイウォーキング
  6.   ラベル:
  7.     アプリ:ui
  8. 仕様:
  9.   レプリカ: 1
  10.   セレクタ：
  11.     一致ラベル:
  12.       アプリ:ui
  13.   テンプレート：
  14.     メタデータ:
  15.       ラベル:
  16.         アプリ:ui
  17.     仕様:
  18.       コンテナ:
  19.         -名前: ui
  20.           イメージ: apache/skywalking-ui:8.3.0
  21.           ポート:
  22.             - コンテナポート: 8080
  23. 名前: ページ
  24.           環境:
  25.             -名前: SW_OAP_ADDRESS
  26.               値: oap:12800
  27.  ---  
  28.  APIバージョン: v1
  29. 種類: サービス
  30. メタデータ:
  31. 名前: ui
  32.   名前空間: スカイウォーキング
  33.   ラベル:
  34.     サービス: ui
  35. 仕様:
  36.   ポート:
  37.     - ポート: 8080
  38. 名前: ページ
  39.       ノードポート: 31234
  40.   タイプ: NodePort
  41.   セレクタ：
  42.     アプリ:ui

3) 記述したデプロイメントファイルに従ってKubernetesデプロイメントコマンドを実行する

前の手順で記述した Kubernetes リリース ファイルに従って、ここでは次のように記述したリリース ファイルに従ってデプロイメント コマンドを直接実行します。

  1.  #リリースファイルの保存ディレクトリに入り、すべてのファイル展開コマンドを一度に実行します
  2. kubectl を適用します。
  3. デプロイメント.apps/oap が作成されました
  4. サービス/OAPが作成されました
  5. デプロイメント.apps/ui-deployment が作成されました
  6. サービス/UIが作成されました

実行が完了したら、コマンドを使用して特定のデプロイメント ステータスを表示します。コマンドは次のとおりです。

  1.  #スカイウォーキングスペースでポッドとサービスオブジェクトの実行状態を確認する
  2. $ kubectlすべてを取得-n スカイウォーキング
  3. 名前準備完了 ステータス 再起動 年齢
  4. pod/oap-5f6d6bc4f6-k4mvv 1/1 実行中 0 36時間
  5. pod/ui-deployment-868c66449d-fffrt 1/1 実行中 0 36 時間
  6.  
  7. 名前タイプ クラスター IP 外部 IP ポート 年齢
  8. service/oap ClusterIP 10.110.112.244 <なし> 12800/TCP、11800/TCP、1234/TCP 36h
  9.  service/ui NodePort 10.100.154.93 <なし> 8080:31234/TCP 36h 
  10.  
  11. 名前準備完了最新利用可能年齢
  12. デプロイメント.apps/oap 1/1 1 1 36時間
  13. デプロイメント.apps/ui-deployment 1/1 1 1 36時間
  14.  
  15. 名前希望現在の年齢
  16. レプリカセット.apps/oap-5f6d6bc4f6 1 1 1 36時間
  17. レプリカセット.apps/ui-deployment-868c66449d 1 1 1 36時間

デプロイされた SkyWalking サービスが正常に実行されていることがわかります。初めてのデプロイメントの場合、イメージをプルするプロセスが遅くなる可能性があります。デプロイメント プロセス中に問題が発生した場合は、Pod オブジェクトの実行ログを表示することもできます。次に例を示します。

  1.  #aopの起動ログを表示できます
  2. $ kubectl ログ pod/oap-5f6d6bc4f6-k4mvv -n スカイウォーキング

4) SkyWalking-UIのWebアクセスアドレスを確認する

上記の手順を実行すると、Kubernetes クラスターで SkyWalking-UI および OAP サーバー サービスが正常に実行されます。次に、SkyWalking-UI サービスのマッピング ポート (ポート 31234 は k8s デプロイメント ファイルで定義されています) を介して Web UI にアクセスします。たとえば、http://NodeIP:31234 からアクセスできます。

  1.  #ここでのIPはKubernetesクラスタの外部に公開されるノードエントリIPです
  2. http://10.211.55.12:31234/

Kubernetes クラスター ノード エントリの IP アドレスがわからない場合は、次のコマンドで表示できます。

  1.  #SkyWalking-UI によってデプロイされた Kubernetes クラスター ノードの IP アドレスを照会する
  2. $ kubectl ノードを記述します kubernetes
  3. 名前: kubernetes
  4. 役割: マスター
  5. ...
  6. 住所:
  7.   内部IP: 10.211.55.12
  8.   ホスト名: kubernetes
  9.  ...

アクセス後のインターフェース表示効果は以下のとおりです。

上図の通り、SkyWalkingが正常に実行されていることがわかります。まだサービスにアクセスできないため、当面は監視データは表示されません。

追記

前述の通り、Kubernetes 環境に分散リンク追跡システムを導入することに成功しました。実験中に K8s 環境がない場合には、このコラムの関連記事を参照してください。そこでは、Kubernetes をインストールしてデプロイする複数の方法を紹介しました。

なお、サービスアクセスがないため、リンクトラッキングデータは当面見ることができません。ただし、スペースの都合上、Java マイクロサービスを SkyWalking に接続する方法については、これ以上紹介しません。しかし、このアクセス プロセスは、R&D 担当者である私たちにとって、マイクロサービス プログラムと分散リンク追跡システム間の統合と相互作用をさらに理解するための鍵となるため、非常に興味深いものです。この部分は、次の記事の続編として皆さんにお伝えします。それほど時間はかかりません。引き続きご注目ください！

<<:  Windows 10 環境向け VMware Horizo​​n サイジング ガイド

>>:  クラウドコンピューティングが分析に最適なプラットフォームである理由

推薦する

ウェブサイトの運営とプロモーションにおける検索エンジン最適化の役割

検索エンジン最適化 (SEO) は、Web サイトの運用、プロモーション、さらには企業のマーケティン...

有名になる裏にある考え方：素朴な味わいを持つ人気のネットセレブ6人

月給5,000～50,000のこれらのプロジェクトはあなたの将来です抖音の美しさはどれも同じだが、快...

ステーション全体の最適化のパフォーマンスと効果

ユーザーから「サイト全体の最適化とは何ですか？料金はどのようにかかりますか？」という問い合わせをよく...

Baiduスナップショットの停滞に対する解決策の簡単な分析

スナップショットが更新されないと、含まれているコンテンツがリリースされないことを意味し、重量も増加し...

ソーシャル マーケティング: 位置情報マーケティングを活用する 10 の方法

編集者: @effyinはじめに：Foursquareがリリースされて間もなく、LBSはソーシャルマ...

Kafka サービスを監視する方法

みなさんこんにちは。Hua Zaiです。またお会いできて嬉しいです。監視は常に Kafka にとって...

安全で安定した運用は、ウェブサイト構築とマーケティングコンバージョンを確実にするための基礎です

最近、中国最大のウェブサイトホスティングおよびドメイン名登録サービスプロバイダーであるHiChina...

エッジコンピューティングは単なる誇大宣伝でしょうか?

エッジ コンピューティングに関して、Edge Computing Industry Alliance...

2020年、わが国のクラウドコンピューティング市場の規模は1,781億元に達し、成長率は33.6%でした。

中国インターネット協会主催の2021年（第20回）中国インターネット会議が北京国家会議センターで開幕...

本当のプログラミングの達人はどのように学ぶのでしょうか?何を学ぶべきか？

みなさんこんにちは。私はNezhaです。数日前、私の友人が面接に行き、K8S について多くの詳細な質...

ウェブサイトのホームページエクスポートリンクの最適化に関する誤解についての簡単な説明

コンテンツが王様で、外部リンクが王様だということは、誰もが聞いたことがあるでしょう。この一文は、多く...

Qutoutiaoのコンテンツブレイクスルー

12月17日、 Qutoutiaoは新四半期の財務報告を発表した。インターネット業界では、大手企業で...

SEOブランドを素早く強調する方法

市場競争はますます激化しており、オンラインマーケティングは戦火に包まれています。ブランドを構築し、S...

ウェブサイトの最適化とユーザーエクスペリエンスに関する調査と分析

最適化に関して言えば、数年前までは「コンテンツが王様、外部リンクが王様」としか認識されていませんでし...

地域コミュニティフォーラムでの私の考え、行動、問題

私はHaimen Forumのウェブマスターです。海門フォーラムは江蘇省の県級市です。なぜ地域フォー...