Vector と Honhu を使用してマイクロサービス アプリケーション用の可観測性プラットフォームを構築する

1. 背景

1.1 マイクロサービス アプリケーションとは

マイクロサービス アプリケーションは、一連の自律サービスで構成されており、それぞれが 1 種類のサービスのみを提供し、これらのサービスが連携して複雑なビジネス機能を提供します。従来のモノリシック アプリケーションと比較して、マイクロサービス アプリケーションは高度に分散されています。次の図に示すように、これは典型的なマイクロサービス アプリケーションです。

写真

上の図に示されているように、マイクロサービスには一般に次のような大きな特徴があります。

自律性

堅牢性(復元力)

透明性

オートメーション

位置合わせ

この記事では、透明性機能に焦点を当てます。マイクロサービス アプリケーションでは、エラーが発生したときにエンジニアにタイムリーに通知する必要があります。マイクロサービス アプリケーションでは、リクエストは複数のマイクロサービスにまたがり、これらのマイクロサービスは異なるチームによって開発される場合があります。

そのためには、エンジニアが運用中に問題を観察して診断できるように、各マイクロサービスが透過的で観察可能であることが必要です。実際のシステム開発および運用プロセスでは、通常、マイクロサービスの健全性を確保するために次のような大量のデータを収集する必要があります。

(1) ビジネス、オペレーション、インフラストラクチャーの指標 

(2) アプリケーションログ 

(3) リクエスト追跡

1.2 可観測性

可観測性プラットフォームの 4 つの柱には、メトリクス、トレース、ロギング、視覚化が含まれます。

1.2.1 インデックスデータ

インジケーター データは通常、定期的に収集されるデータの種類を指します。データ タイプは数値です。通常、最小値、最大値、平均値、およびパーセンタイル値に焦点を当てます。インジケーター データは通常、システムやアプリケーションのパフォーマンスを反映することができ、たとえば、特定のマイクロサービスのリソース使用率がしきい値を超えた場合、アラームをトリガーして、DevOps 担当者が問題を診断し、さらなるアクションを実行できるようにすることができます。

1.2.2 追跡

トレースは、関連する分散イベントのシーケンスです。一般に、ゲートウェイ層で一意のリクエスト ID を生成します。このリクエスト ID はすべてのリクエスト参加者に及ぶため、追跡は実際にはリクエスト ID を持つ一連のログの組み合わせになります。各レコードには、エントリ時間、待ち時間情報などのトレース情報とデバッグ情報が含まれます。

1.2.3 ログ

ログとは、タイムスタンプ付きのイベントを指します。ログには、リクエストの確認情報、失敗したリクエストによって生成されたエラー情報など、さまざまな情報が含まれる場合があります。

1.2.4 視覚化

視覚化は、収集されたデータをより深く理解するのに役立ち、システムについての洞察を得る能力を最大限に高めることができます。エンジニアリングチームにとって、業務効率化のための自動化に加え、多くの問題の発見には手動介入が必要となるため、データをリアルタイムに表示する関連ダッシュボードは非常に便利な機能です。

一般に、マイクロサービス アプリケーションの下で可観測性プラットフォームを構築するのは困難な作業です。私たちは世界的な情報を知る必要があります。運用保守担当者が全体的な状況を把握できるように、独立した情報から全体的な視野を構築する必要があります。この記事では、国内のビッグデータ分析プラットフォームHonghuを使用して、可観測性プラットフォームを構築する方法を段階的に説明します。

2. 紅胡の紹介

Honhu は、データのインポート、分析、保管、分析、計算からデータの視覚化に至るまで、すぐに使える一連のサービスを提供します。各データ処理段階の機能は比較的完全かつ強力です。

データ収集・インポート部分はVector/Kafkaなどのデータソースに簡単に接続でき、標準のREST APIやHTTPなどの各種APIからのデータプッシュも受け取ることができます。

データ分析部分は標準 SQL クエリ言語を採用しており、ほとんどの技術者にとって使いやすく、共通のスキルを備えています。プラットフォームには 100 を超える組み込みのスカラー関数とテーブル関数、ビュー、ルックアップ テーブルなどがあり、サポートされています。ライブラリ間および異種データの関連付けにより、さまざまなビジネス分析のニーズに対応できます。

視覚化部分では、すぐに使用できる多数のチャート タイプ、豊富な入力選択とドリル機能、および多様なチャートの共同編集エクスペリエンスが提供されます。

注目に値するのは、Honghu が独自に開発した時間読み取りモデリング エンジンは、異種データを迅速にインポートして保存でき、モデルと分析プロセスを固定することなくデータ モデルと分析パラメーターの動的な調整をサポートしていることです。ビジネス分析シナリオが変化した場合、迅速に対応できるように SQL 分析ステートメントを調整するだけで済みます。

予備調査と理解の後、Honghu は基本的に可観測性シナリオを構築するというニーズを満たします。

3. 解決策

3.1 システムアーキテクチャ

写真

Honhu のシンプルで使いやすいデータ収集機能に基づいて、上記のログ収集システムを非常に簡単に構築できます。

各マイクロサービスは Kubernetes ノードに動的にデプロイされ、各マイクロサービスの出力は kubernetes_logs の形式で実行中のノードに保存されます。

Vector Agent は DaemonSet の形式で各ノードにデプロイされます

Honhu には Vector インターフェイスが組み込まれており、設定を開くだけです

Vector Agent はログを解析、強化、変換した後、最終的にログを継続的に Honhu にプルします。

3.2 データアクセス

Honhu にはさまざまなデータ アクセス機能があり、組み込まれた Vector および Kafka データ アクセス機能により、企業によるデータ収集が大幅に容易になり、Honghu 分析プラットフォームをインポートしてデータの価値をさらに掘り出すことが容易になります。上記の取得システムに基づいて、具体的な操作手順は次のとおりです。

3.2.1 Honhu データ収集インターフェイスを有効にする

3.2.1.1 「Honghu」→「データインポート」→「外部データソースからインポート」と入力します。

写真

3.2.1.2 Vector インターフェイスを設定し、データ セット範囲を選択します (この記事ではデータログ データ セットを作成します)

写真

3.2.1.3 データ セットとデータ ソース タイプを選択し、その後の Vector 構成用の Vector 構成テンプレートを生成およびダウンロードします。

写真

3.2.2 Vector の設定とインストール

写真

Vector の設計 (上図を参照) によれば、データ パイプラインは、データ ソースの決定、データの変換、データの収集の 3 つの段階に分かれています。以下は実際に実行されている設定ファイルです(情報セキュリティを考慮し、一部のファイルは感度を下げています)。この構成には主に、収集されたデータ ソースの決定、データの処理と変換の方法 (複数行の処理、データをさらに分析して抽出する方法、Honghu のニーズを満たすようにデータを強化する方法)、そして最終的にデータを収集してホンフ:誰にとっても理解するのは難しくないと思います。

写真

Vector の構成ファイルが適切に配置されたら、Vector をインストールします。この記事のソリューションでは、Kubernetes 上で実行されているマイクロサービスのログを収集する必要があります。Vector は Helm コマンドでインストールされます。具体的なコマンドは次のとおりです。

写真

Vector Helm チャートについて詳しく知りたい場合は、Vector Helm Chart (https://github.com/vectordotdev/helm-charts/tree/develop/charts/vector) を参照してください。

3.2.3 データの検証

データがHonghuに入ると、以下の図に示すように、システムはデータにインデックスを付けて元のデータを保存し、ユーザーはダッシュボードを作成してリアルタイムで分析できるようになります。

写真

データがHonghuに入ると、クエリを確認するためにHonghuを開くことができます。

Honhu-「Query-」Advanced Query を開き、簡単な SQL を実行すると、リアルタイム データを確認できます。

写真

写真

3.3 応用シナリオ

3.3.1 各サービスで発生するすべてのイベントの統計

写真

3.3.2 外部リクエストの統計

いくつかの指標をカウントする場合、多くの場合、統計を期間ごとに分類する必要があります。ここでのHonghuの処理ロジックは非常に便利で、時間をある程度変換すれば、変換された時間を基に直接クラスタリング分析を行えば十分です。

写真

3.3.3 統計リクエストの処理時間

マイクロサービス アプリケーションに基づいて、各リクエストは 1 つ以上のコンテナーにまたがり、リクエストの処理時間は 1 つ以上のコンテナーの処理時間に重ねる必要があります。私たちのアプリケーションは最初からこれを考慮しており、リクエストがアプリケーション ゲートウェイに入ると request_id が割り当てられ、その request_id がさまざまなアプリケーションのログに記録されます。この実装に基づいて、Honghu が提供するウィンドウ関数を使用して、request_id に基づいてイベントをクラスタリングした後、各リクエストの処理時間を大まかに計算できます。

写真

3.3.4 API Gatewayのログ出力

マイクロサービス システムでは、ゲートウェイが非常に重要です。現在主流のゲートウェイは、Nginx と Envoy のさまざまな実装に基づいています。当社のビジネス展開では、両方のタイプのゲートウェイが関係します。この記事では Nginx ゲートウェイを監視する方法についてのみ説明しますが、今後は、Honghu を使用して Envoy ベースのゲートウェイを監視する方法について説明します。Nginx については、Honghu が既製のケースを用意しており、ダッシュボードを作成するには、ダッシュボードの Nginx 設定ファイルをインポートするだけで済みます。

「Honghu」と入力 --> ダッシュボード --> 新しいダッシュボード --> 構成ファイルのインポート

写真

3.3.5 最終レンダリング

3.3.5.1 Nginx ゲートウェイの監視

写真

3.3.5.2 アプリケーションの監視

写真

4. 使用体験

インストール、データインポート、データ分析、データ視覚化の全プロセスを経た後、Honghu System は、ローカライズされたビッグデータ製品の中で人々に新鮮な感覚を与えます。他の同様の製品と比較した場合、Honghu の利点は次の点に反映されます。

KISS 製品の原則: Honhu ビッグ データ システムは設計がシンプルで、ユーザーにとって使いやすいです。データのインポート、分析、視覚化の観点から見ると、システムの一貫性は高く、ほとんどの場合、ユーザーはドキュメントを見なくてもデータの分析を開始できます。

強力な分析機能:Honghu は拡張 SQL ステートメントを採用して構造化データ、半構造化データ、非構造化データを処理し、スカラー関数とテーブル関数を使用して元のデータを強化および変換できるため、ユーザーがデータの価値を深く掘り下げることができます。

データ分析ビジネスのニーズに適応:Honghuシステムは、ビジネスの観点から元のデータを満たし、さまざまなビジネス部門の分析ニーズを満たすことができる時間読み取りモデリング機能を提供します。

Honhuビッグデータ分析プラットフォームは、コミュニティバージョンのリリースとユーザーとエコロジーの継続的な拡大により、製品の機能は必然的にますます豊富になります-初心を忘れずにHonghuの野望を達成してください。

おすすめ

転載: blog.csdn.net/Yhpdata888/article/details/131962861