クラウドネイティブフルスタックモニタリングの詳細な説明

序文

現在、世界中の企業のクラウド化とデジタル化のプロセスは加速し続けており、コンテナやマイクロサービスなどのクラウドネイティブテクノロジーはソフトウェアアーキテクチャに急速に浸透しており、ITアーキテクチャのクラウド化と複雑化がパフォーマンス監視市場を牽引し続けています。企業のクラウドとデジタル化への継続的な変革、およびシステムの弾力性と効率性を考慮してエンタープライズソフトウェア開発に多数のクラウドネイティブテクノロジを適用したことで、世界のIT監視市場に急速な変化がもたらされました。コンテナ、K8、マイクロサービスを包括的かつ効果的に監視する方法は、今日のクラウドネイティブ テクノロジーが直面している重要な課題です。

背景と課題

クラウド製品では通常、一連のマイクロサービスで構成されるサービス指向フレームワークが使用されます。マイクロサービスは独立して実行できるプロセスです。異なるサービスでは異なる開発言語が使用される可能性があり、数千台のサーバーや複数のデータセンターに展開される場合もあります。サービス間では軽量な通信メカニズムが使用されます。サービス間の呼び出し関係は複雑であり、運用および保守担当者がシステムの動作を理解したり、システム パフォーマンスを分析したりする際には、次のような大きな課題が生じます。

（１）コンテナは正常に動作していますか？

（２）K8Sが正常に動作しているかどうか

（３）マイクロサービスは当たり前

（５）ビジネスコールで問題が発生した場合、どのサービスに障害が発生したかをすぐに見つけるにはどうすればよいでしょうか？

（６）ビジネス電話は時間がかかります。パフォーマンスのボトルネックを素早く見つけるにはどうすればよいでしょうか?

（７）分析と位置付けのために特定の通話のビジネスログを素早く取得するにはどうすればいいですか？

解決

概要

クラウドネイティブ監視システムには、ヘルスチェック、メトリック、ログ記録、トレースが含まれます。ヘルスチェック: ヘルスチェックは、アプリケーションの生存ステータスを定期的にチェックできます。メトリクス: メトリクスの監視、個別の時点における数値ポイントの生成。ログ記録: ログ監視。トレース: 呼び出しチェーンの監視。

さまざまな監視ツールの適用可能なシナリオを次の図に示します。

健康チェック

マイクロサービスアーキテクチャでは、すべてのサービスが利用可能であることを保証し、問題が発生したときに問題のあるサービスを迅速に削除するために、定期的にサービスの可用性を確認する、いわゆるヘルスチェックが必要です。通常、ヘルス チェックには TCP と HTTP が含まれます。つまり、TCP または HTTP 要求が定期的に送信され、その応答に基づいてサービスの可用性が決定されます。一般的に、TCP 定期リクエストはネットワーク層が正常かどうかを判断するために使用され、Http リクエストはアプリケーション層が正常かどうかを判断するために使用されます。サービスはリクエスト インターフェイスを構成する必要があります。検出サービスは、指定されたインターフェースに定期的に http リクエストを送信し、インターフェースの応答コードと応答時間に基づいて判断を行います。 Spring Boot のエンド ポート /health は、アプリケーションのヘルス状態を確認できます。たとえば、http://localhost:8088/health にアクセスすると、HealthEndPoint がディスク検出やデータベース検出などのデフォルトの監視結果を提供していることがわかります。

 {

 「ステータス」 : 「UP」 、

 「ディスクスペース」 : {

 「ステータス」 : 「UP」 、

 「合計」 : 398458875904 ,

 「無料」 : 315106918400 ,

 「しきい値」 : 10485760

 } 、

 「デシベル」 : {

 「ステータス」 : 「UP」 、

 「データベース」 : 「MySQL」 、

 「こんにちは」 ： 1

 }

 }

コンテナ監視

コンテナの監視には Prometheus-cAdvisor が使用されます。 cAdvisor は、コンテナのパフォーマンス状態を監視するために Google が特別に設計したオープンソース ツールです。 cAdvisor は、パフォーマンス データを取得するための 2 つのインターフェイス (Push と Pull) を提供します。プッシュ インターフェイスとは、cAdvisor がデータを定期的にリモート ストレージ サービスにアクティブにプッシュすることを指します。 Influxdb と cAdvisor 間の接続は、このインターフェースを通じて完了します。プル インターフェイスを使用すると、外部アクセス サービスはいつでも cAdvisor から現在のパフォーマンス データを積極的に取得し、独自に処理することができます。この方法は、Prometheus と cAdvisor を接続するために使用されます。

サービスインスタンスのライフサイクルは非常に短く、コンテナは数分で誕生したり消滅したりする可能性があるため、コンテナベースのマイクロサービス監視と元の監視には大きな違いがあります。マイクロサービス コンテナーとホストの監視は、CPU、メモリ、ディスク、ネットワーク カードなどの基本的なパフォーマンス インジケーターと切り離せません。ホストの監視については、従来の監視方法を引き続き使用できます。各ホストは、サーバーのパフォーマンス指標を収集するためのエージェントをインストールします。パフォーマンス インジケーターを収集する場合、エージェントはタイムスタンプと対応するラベルを追加して、さまざまなパフォーマンス インジケーターのデータ ディメンション (メトリック) を区別し、監視データを時系列データベースに集約できます。データベース内のデータは、視覚的に表示するために現在のオープンソース コンポーネントに接続することができ、アラームのためにアラーム サービスに接続することもできます (アラーム サービスのアラーム ポリシーと組み合わせて)。

コンテナの監視は、当然ながらホストマシンの監視とは異なります。各コンテナ イメージに監視エージェントを統合することはできません。これはあまりにも侵襲的であり、維持するのが困難です。 Prometheus には、監視データを収集するために使用できるエクスポーターが多数あります。たとえば、Kubernetes 上のすべてのコンテナ (ポッド) のパフォーマンス インジケーターを収集する場合、Promethus は複数の Kubernetes ApiServer エンドポイントを直接構成することで、Kubernetes クラスター全体を監視できます。

K8Sモニタリング

Prometheus は K8S クラスター レベルで選択されます。クラスター レベルの監視は、ノード、K8S 基本コンポーネント、K8S リソース オブジェクトの 3 つのカテゴリに分かれています。

1. ノード監視のために、Prometheus は CPU、メモリ、ディスク IO、ディスク使用量、ネットワーク パケット量、帯域幅などのデータを収集できるノード エクスポーターを提供します。

2. kubelet、kube-apiserver、kube-controller-manager、kube-scheduler などの K8S 基本コンポーネントはすべて、独自のランタイム監視データを公開するためのメトリック インターフェースを提供しており、K8S クラスターにデプロイされた Prometheus によって直接プルできます。

3. cadvisor と kube-state-metrics を組み合わせることで、K8S 内の Pod の CPU、メモリ、ディスク IO、ネットワーク IO などのデータを直接収集できます。 CoreOS によってオープンソース化された Kube-Prometheus プロジェクトは、Prometheus のインストール、展開、およびメンテナンスを大幅に簡素化します。

Kubernetes に基づいて実装されたマイクロサービス アプリケーション レベルの監視プラグインを次の図に示します。

監視プラグインは、Kubernetes のマスター ノード、つまり、apiserver がインストールされているサーバー上で実行されます。プラグインは、Kubernetes が提供する公式クライアントを通じて API サーバーにアクセスできます。まず、どの名前空間のどのサービスを監視するかをプラグインに伝える必要があります。次に、プラグインは API サーバーと対話して、特定のサービス下にあるすべての Pod インスタンスを取得します。プラグインは、すべてのポッドによって提供される /metrics インターフェイスに同時にアクセスし (パスは構成可能)、各ポッドの戻りデータ (特定のデータ形式契約に準拠した json 形式) に pod_name ラベルのタグを付けて、各ポッドによって返されるメトリックを識別します。 pod_name ラベルと同時に、監視データがどの特定のサービスに属しているかを区別するために、service_name ラベルも追加されます。

Kubernetes は主に、Node、Pod、Endpoints、Service、Ingress の 5 つのサービス検出モードと統合用の Prometheus を提供します。 K8S の監視では、Prometheus フェデレーションの形式が使用されます。 k8s クラスターの外部の Prometheus は、k8s クラスター内の Prometheus から監視データを取得し、外部の Prometheus は監視データのストレージとなります。 k8s クラスターにデプロイされた Prometheus のデータ ストレージ レイヤーでは、emptyDir を使用するだけで済み、データは 24 時間 (またはそれ以下) のみ保持されます。障害が発生した場合でも、k8s クラスターにデプロイされた Prometheus インスタンスは、クラスター ノード間で安全にドリフトすることができます。

1) ns-monitorという名前の名前空間を作成する

2) k8sにノードエクスポーターをデプロイする

Node-exporter は、メモリ、CPU など、Kubernetes クラスター内の各ノードの物理インジケーターを収集するために使用されます。各物理ノードに直接インストールできます。ここでは、DaemonSet を使用して各ノードにデプロイし、hostNetwork: true と hostPID: true を使用してノードの物理インジケーター情報を取得し、マスター ノードでポッドを起動するための許容値を設定します。

#node-exporter.yml ファイルを作成します:

3-1) rabc.yml を作成して編集します。

rbac.yml は、Prometheus コンテナが k8s apiserver にアクセスするために必要な ServiceAccount、ClusterRole、および ClusterRoleBinding を定義します。

3-2) configmap.yml を作成して編集し、configmap で Prometheus 構成ファイルを設定します。

3-3) prometheus-deploy.yml は Prometheus のデプロイメントを定義します。

3-4) prometheus-svc.yml は Prometheus サービスを定義します。

外部の Prometheus がアクセスできるように、Prometheus を NodePort、LoadBalancer、または Ingress 経由でクラスターの外部に公開する必要があります。

3-5) yml ファイルを使用してオブジェクトを作成します。

 kubectl 作成-f rbac .yml
 kubectl 作成-f構成マップ.yml
 kubectl 作成- f prometheus - .ymlをデプロイ
 kubectl 作成-fプロメテウス-svc .yml

4) Prometheusフェデレーションを構成する

Kubernetes クラスターへの Prometheus のデプロイが完了したら、クラスター外部の Prometheus を構成して、クラスター内の Prometheus からデータをプルします。実際には、静的構成の形式でジョブを追加するだけで済みます。

5) プッシュゲートウェイを構成する

ログ監視

Fluentd は、情報を収集、整理、転送するための一般的なストリーミング データ処理ツールです。デフォルトでは、Docker はシステム コンソールへのすべてのコンテナ出力を、コンテナ ID にちなんで名付けられたローカル ディレクトリにリダイレクトします。コンテナの出力を逐語的にキャプチャするには、これらすべてのディレクトリの内容を定期的に収集するだけで済みます。この方法は侵襲性が低いですが、定期的な収集のため、集約側（Kibana など）でのログの表示に一定の遅延が生じます。遅延の長さはログ収集期間に関連します。逆に、Docker のログ ドライバー (Docker バックグラウンド サービスを起動するときにパラメーター --log-driver=fluentd を指定) を使用すると、パフォーマンスの良いリアルタイムの集計終了ログ表示が得られます。ただし、ログはリモート Fluentd サービスに直接送信されるため、ローカル ホスト上の docker logs コマンドは無効になります。

2 つの方法の共通点は、どちらの方法を使用しても、収集されたログをコンテナ名、イメージ、ラベルなど、コンテナの使用に非常に便利なディメンションで検索できることです。 Kubernetes クラスター自体はログ収集ソリューションを提供しません。 fluentd-->kafka-->logstash-->elasticsearch-->kibana メソッドを使用して、ログ情報をアプリケーションのコレクション バックエンドに直接プッシュします。

コールチェーン監視

コール チェーンの定義: システムがビジネス コールを完了すると、サービス間のコール情報 (時間、インターフェイス、レベル、結果) がログに記録され、ログに記録されたすべてのデータがツリー チェーンに接続されてコール チェーンが生成されます。追跡システムは、プロセス中に生成されたログ情報を分析および処理し、ビジネス コール プロセスの完全なエンドツーエンドの実行を復元し、さまざまなディメンションに基づいて統計分析を実行します。これにより、異常なサービス呼び出しを識別し、異常なサービスを迅速に分析して識別できるようになります。同時に、データ統計に基づいてシステムパフォーマンスのボトルネックを分析することもできます。

大規模分散システム トレース インフラストラクチャである Dapper では、その原理と一般的なメカニズムについて説明します。モデルには多くの用語がありますが、最も重要な 2 つの用語を理解するだけで十分です。

トレース: 完全な分散呼び出しトレース リンク。

スパンは、サービス間の呼び出しです。複数のスパンがトレース レコードに結合されます。

以下は、ユーザー サービス要求による呼び出しチェーン プロセスのシミュレーションです。

左の図は、フロントエンド (A)、2 つの中間層 (B と C)、および 2 つのバックエンド (D と E) を含む 5 つのサーバーに関連付けられたサービスを示しています。ユーザー (このユース ケースの開始者) がリクエストを開始すると、リクエストは最初にフロントエンドに到達し、フロントエンドは 2 つの RPC をサーバー B と C に送信します。B はすぐに応答しますが、C はバックエンドで D および E と対話してから A に返す必要があり、A は元のリクエストに応答します。右側には対応するスパンの管理関係が表示されます。各ノードは呼び出しを表す Span です。少なくともスパン名、親 spanId、spanId が含まれます。ノード間の接続線は、スパンとその親スパンの関係を表します。すべてのスパンは 1 つのトレースに属し、1 つの TraceId を共有します。図から、フロントエンド A への呼び出しスパンの 2 つのサブスパンはそれぞれ B と C を呼び出すためのスパンであり、2 つのバックエンド サービス D と E を呼び出すためのスパンは両方とも C のサブスパンであることがわかります。トレース システムは、ユーザー要求ごとにグローバルに一意の ID (TraceId) を生成します。 TraceId はスパン間で渡され、さまざまなサービスの「分離された」ログを連結し、より価値のある情報を再編成して復元します。現在、コール チェーン システムの実装は数多く存在し、最も一般的に使用されているものには Zipkin と Jaeger があり、これらは CNCF Foundation に加わり、ますます使用されるようになっています。

呼び出しチェーンモデルの形式

一連の追跡ポイントを完全な呼び出しチェーンに接続し、異なるリクエストの呼び出しチェーン ログ情報を区別するには、情報にリクエストのステータスと期間を含める必要があります。さまざまなビジネス アプリケーションでは、ログに特別な情報を記録する必要がある場合があります。したがって、呼び出しチェーン ログ情報 (Span) には次の内容が含まれている必要があります。

ビジネス リクエスト呼び出しチェーン モデル:

Trace の最も基本的な機能は、複数のサービス間のリクエストの伝播と依存関係を記録し、視覚化できることです。 Trace 自体のデータ特性としては、依存関係を持つ正規化・標準化されたアクセス ログであるため、Trace に基づいてより多くの価値を計算およびマイニングできます。以下は、SLS OpenTelemetry Trace の実装アーキテクチャです。コアとなるのは、データオーケストレーションを通じて元のトレースデータを計算し、集約されたデータを取得し、SLS が提供するインターフェースに基づいてさまざまなトレースの追加機能を実装することです。例えば：

1. 依存関係: これは、ほとんどのトレース システムに付属する機能です。トレース内の親子関係に基づいて、集計計算を実行することでトレースの依存関係が取得されます。

2. サービス/インターフェースのゴールデン インジケーター: トレースは、サービス/インターフェースの呼び出し遅延、ステータス コード、その他の情報を記録します。このデータに基づいて、QPS、レイテンシ、エラー率などの重要な指標を計算できます。

3. 上流と下流の分析：計算された依存情報に基づいて、特定のサービスごとに集計し、サービスが依存する上流と下流の指標を統合します。

4. ミドルウェア分析: Trace では、ミドルウェア (データベース/MQ など) への呼び出しは通常、スパンとして記録されます。これらのスパンの統計に基づいて、ミドルウェアの QPS、レイテンシ、エラー率を取得できます。

アラーム関連: 通常、監視とアラームはサービス/インターフェースのゴールデン インジケーターに基づいて設定されますが、サービス エントリ全体のアラームのみを考慮できます (通常、親スパンが空のスパンはサービス エントリ コールと見なされます)。

メトリクス:

• 通常、これは範囲クエリであり、毎回単一のメトリック/タイムラインをクエリするか、特定のアプリケーションのすべてのマシンの平均CPUを統合するなど、集計のためにタイムラインのグループをクエリします。
• 時系列クエリは一般に QPS が高くなります (主にアラーム ルールが多いため)。高 QPS クエリに適応するには、データ集約を適切に行う必要があります。
• このタイプのデータをサポートするために専用の時系列エンジンが用意されます。現在、主流の時系列エンジンは、基本的にLSMツリーに似たアイデアで実装されており、高スループットの書き込みとクエリに適応しています（更新と削除の操作はまれです）。
• 同時に、可観測性データには、高スループット書き込み（高トラフィック、QPS、バースト）、超大規模クエリ特性、時間アクセス特性（コールド特性とホット特性、アクセスの局所性など）などの共通の特性もあります。

ビジネスコールリンク監視

Skywalking は、分散システムの監視、追跡、診断をサポートする優れたオープンソース アプリケーション パフォーマンス監視ツールです。主な機能は次のとおりです。

サービストポロジ監視

コールリンクの監視は 2 つの観点から見ることができます。サービスにプローブを追加し、実際の呼び出しを生成すると、Skywalking のフロントエンド UI を通じてサービス間の呼び出し関係を表示できます。サービス間の通話を単純にシミュレートします。 2 つの新しいサービス (サービス プロバイダーとサービス コンシューマー) を作成し、Feign Client を介してサービス間のリモート呼び出しをシミュレートします。

図から次のことがわかります。

• サービスノードにはプロバイダーとコンシューマーの2つがある
• データベースノードがあります: localhost [mysql]
• 登録センターノード

コンシューマーはプロバイダーによって提供されるインターフェースを使用します。

システム トポロジ ダイアグラムを使用すると、システム間のアプリケーション依存関係と現在の状態のビジネス フロー プロセスを明確に理解できます。注意深く観察すると、図の消費者ノードの一部が赤になっていることに気付くでしょう。赤は何を意味しますか?

赤は、現在コンシューマー ノードを通過しているリクエストが一定期間異常な応答を示していることを意味します。すべてのノードが赤に変わると、この段階ではサービスが完全に利用できないことを意味します。運用および保守担当者は、トポロジを使用してサービスの潜在的な問題を迅速に発見し、さらに調査と予防を行うことができます。

スカイウォーキングの痕跡モニタリング

Skywalking は、ビジネス コール モニタリングを通じて依存関係分析を実行し、サービス間のサービス コール トポロジ関係と各エンドポイントのトレース レコードを提供します。

以前、コンシューマー ノード サービスでエラーが発生しました。エラーが発生した場所とその原因を特定してみましょう。

各トレース情報では、現在のリクエスト時間、GloableId、リクエストが呼び出された時間を確認できます。正しい通話と異常な通話を別々に見てみましょう。

トレースコールリンク監視

図は正常な応答を示しています。この応答の合計時間は 19 ミリ秒で、4 つのスパンがあります。

• span1 /getStore = 19ms 合計応答時間
• span2 /demo2/stores = 14ms 偽クライアントがリモートサービスの呼び出しを開始してから応答するまでにかかる合計時間
• span3 /stores = 14ms 合計インターフェースサービス応答時間
• span4 Mysql = 1ms サービスプロバイダーがデータベースを照会するのにかかる時間

ここで、span2 と span3 の時間表現は同じですが、ここでは時間が整数に丸められているため、実際には異なります。

各スパンでは、現在のスパンの関連プロパティを表示できます。

• コンポーネントタイプ: SpringMVC、Feign
• スパンステータス: false
• HTTPメソッド: GET
• URL:

http://192.168.16.125:10002/demo2/stores

これは、トレース ログを呼び出す通常の要求です。おそらく私たちは通常の状態を気にしていないのでしょう。結局のところ、すべてが正常なときに私たちが期待するのはそれではないでしょうか?異常な状況での Trace と Span がどのようになるかを見てみましょう。

エラーが発生した呼び出しチェーン内の Span の is error フラグが true になり、エラーの具体的な原因が Logs というタブで確認できます。異常な状況に基づいて、ビジネスに影響を与える具体的な原因を簡単に特定できるため、問題を迅速に特定して解決できます。ログを見ると、接続が拒否されたことがわかります。これは、ネットワークの問題が原因である可能性があります (実際には、ネットワークに問題がある場合はこのトレースを表示できないため、可能性は低いです)。または、サーバー上の構成の問題が原因で、接続を正しく確立できない可能性があります。例外ログを通じて、問題の鍵をすぐに見つけました。

サービスパフォーマンス監視

サービス パフォーマンスでは、次の主要な指標を達成できます。

1. 主要なビジネス指標: 応答時間、Apex、スループット、エラー率

2. トランザクション: 時間消費率、応答時間、スループット、Apdex、エラー率、呼び出し回数

3. データベース: SQL 消費時間、平均応答時間、スループット、SQL ステートメント実行プラン、コード スタック

4. NoSQL: Memcached/Redis/MogooDB の合計操作時間、平均応答時間、スループット

5. 外部アプリケーション: HTTP/Thrif/Dubbo/Web サービスの応答時間の割合、平均応答時間、合計応答時間、スループット率、エラー率

6.MQ: メッセージの総数、1分あたりのメッセージ数、平均メッセージ送信時間、RabbitMQ/JMS/ActiveMQプロデューサーとコンシューマーの合計トラフィック

7.JVM: メモリ使用量、スレッド、HTTP セッション