企業の問題点に直接対処するための優れた可観測性データ プラットフォームを構築するにはどうすればよいでしょうか?

可観測性は近年注目されているトピックの 1 つです。可観測性が良好なシステムは、企業の生産効率を向上させ、製品の品質、ユーザー満足度などを向上させることができます。特に、コンテナクラウドネイティブマイクロサービスアーキテクチャ技術の広範な適用により、システムコンポーネントはますます増加し、リクエスト処理リンクはますます長くなり、トラブルシューティングはより困難な課題に直面しています。これは多くの企業にとって共通の問題点でもあります。この記事では、Yanhuang Data が新しい可観測性プラットフォームを通じて企業の IT システムやビジネス システムを監視し、パフォーマンスを視覚化するためにどのように役立つかを紹介します。

1. 体系的な観測システムを構築する方法

まず、観測可能なシステムを構築する方法について簡単に紹介します。

1. 「観測可能な」システムとは何ですか?

企業システムの運用・保守時のトラブルシューティングの効率を向上させるためには、新たな観測可能なデータや機能を導入することが急務となっています。可観測性とは、システムが出力する信号を通じてシステムの状態を測定し、理解するプロセスです。したがって、システムが出力できる信号の種類と品質によって、システムの観測可能性の品質が決まります。

重要な観測可能なシグナルは、メトリック、トレース、ログの 3 つです。これら 3 つの観測信号の応用は比較的成熟しており、選択できるオープン ソース ツールも多数あります。

これら 3 つのデータ タイプは、多くの場合、可観測性の「3 つの柱」と呼ばれますが、CNCF の最新の可観測性ホワイト ペーパーでは、これらを「3 つの主要なシグナル」と呼ぶことを好んでいます。その理由は、「3 つの柱」は、観測可能なシステムを構築するには 3 つすべてが不可欠であるという錯覚を人々に与えやすいからです。しかし実際には、シグナルの選択はユーザーの実際のニーズに基づいて行う必要があります。たとえば、一部のユーザーの場合、メトリックとログを組み合わせることで、システムの可観測性要件を満たすことができます。

ただし、コンテナ クラウド ネイティブおよびマイクロサービス アーキテクチャを使用する場合、高度に監視可能なシステムを構築するには、3 種類のデータすべてが必要になります。障害診断のプロセスでは、これら 3 つはそれぞれ次の役割を果たします。メトリックは、システムの全体的な動作と健全性に関するデータを測定するために使用されるため、システムに問題があるかどうかを監視できます。トレース、特に分散呼び出しチェーン データを使用すると、問題の場所をすばやく特定できます。ログには、発生した問題を記録できます。企業の可観測性システムが適切に構築されていれば、トラブルシューティングの効率が大幅に向上し、生産性と製品の安定性の向上に大きく役立ちます。

これら 3 つの最も重要なシグナルに加えて、ダンプ、プロファイル、イベントなどの他のシグナルもあります。これら 3 つの信号の範囲はそれほど広くなく、成熟度もそれほど高くない可能性があります。ダンプについては後ほど共有の中で触れるので、まずは簡単に紹介しておきましょう。

ダンプは、プログラムがクラッシュしたときに生成されるコアダンプ内の情報です。これらには、通常、メモリ状態など、クラッシュしたときのプログラムの内部状態が含まれているため、ログよりも直接的に問題を特定できる場合があります。したがって、ダンプ データを観測可能なシステムに組み込むことができれば、システムのトラブルシューティングの効率が向上します。ただし、クラウドネイティブのマイクロサービス アーキテクチャでは、ダンプ データの検索と取得が以前よりも困難になっています。

2. システム可観測性の3段階構築

ニーズを特定する

まず、自分のニーズを明確にする必要があります。ほとんどの場合、観測可能なシステムの実装について議論するときは、システムの健全性状態をタイムリーに観測し、問題を迅速に発見してトラブルシューティングする方法について議論しています。実際、観察可能なシステムは、ユーザーの行動習慣を理解し、企業の製品や投資計画をさらに導くなど、他の問題の解決にも使用できます。

前述のように、システムを観測可能にするためにすべての重要な信号を含める必要はありません。したがって、まずシステムの可観測性を向上させることでどのような問題を解決したいのかを明確にする必要があります。需要が明確になって初めて、その需要を満たすためにどのようなデータを収集する必要があるかをさらに検討できるようになります。システムの可観測性を向上させるには、1 つのステップで構築を完了することは期待できません。現時点で最も重要なニーズから始めて、段階的に進めていく必要があります。優れた可観測性システムを構築する際には、考慮すべき問題が数多くあるためです。たとえば、最初にインジケーター データを含め、その後、ログ データや呼び出しチェーン データ、その他のデータを徐々に含めることができます。このアプローチは、エンタープライズ アプリケーション構築の初期段階で現在使用されている方法、つまり迅速な起動、迅速な試行錯誤、正しいフィードバックが得られた場合の継続的な改善とも一致しています。

データソースを見つける

ニーズを明確にした後は、複雑さのレベルが異なる可能性のあるデータ ソースを理解する必要があります。一部のデータはすでに存在しており、収集して分析するだけでよい場合があるためです。また、現在のシステムでは特定のデータを出力する機能が備わっておらず、観測データを出力するために何らかのシステム変更が必要となる可能性もあります。

たとえば、ログは一般に知られているはずです。各システムを構築する際には、ログ記録が必須の要件となります。ログは通常、ローカル ファイルに書き込まれるか、ネットワーク経由で集中ログ サービスに送信されます。現時点ではログ形式に関する普遍的な標準がないため、ログ データを使用してシステムを観察する場合、選択したログ分析ツールのニーズと要件に応じてログ コンテンツをフォーマットする必要がある場合があることに注意してください。

メトリクスに関しては、Prometheus が現在事実上の標準です。ほとんどのオープンソース ツールには Prometheus エクスポーターが組み込まれており、ユーザーはそれを開くだけで使用できます。エンタープライズ開発システムの場合、Prometheus エクスポーターを簡単に実装できるツールもあります。

トレースまたは分散トレースの場合、通常はシステム内のポイントを埋め込むことによって実装する必要があります。

オープンソース ツールの中では、OpenTelemetry 標準が比較的一般的であり、一般的なテクノロジー スタックに非侵入的な追跡方法を提供します。 Yanhuang データ プラットフォームでは、非侵襲的な計測機器である OpenTelemetry もトレース データの生成に使用されます。

• 適切なツールの選択

データ ソースを明確にした後は、データ収集やデータ分析のためのツールなど、適切なツールを選択します。 CNCF ランドスケープでは、可観測性に関する特別なトピックが開かれており、ログ、メトリック、トレースの観点から簡単な分類が行われており、参考になります。たとえば、インジケーター データを処理するために一般的に使用されるツールは Prometheus です。ログ処理には Fluentd と Elasticsearch があります。コールチェーンを処理するツールとしては、Jaeger、OpenTelemetry などがあります。各ツールは、異なるデータ タイプを処理する場合や、異なる使用シナリオで処理する場合に重点を置いています。したがって、それらに基づいて完全な可観測性システムを構築する場合、最終的なニーズを満たすために複数のツールを組み合わせる必要があることがよくあります。

2. 企業が可観測性システムを構築する際の問題点

1. 企業がシステム可観測性システムを構築する際の問題点

調査の結果、観測可能なシステムの構築で直面する課題は、次の側面に要約できます。

（１）複雑性が高い

前述したように、メトリック、トレース、ログ データは、さまざまな次元からシステムの観測可能性を提供できます。したがって、包括的な可観測性システムを構築する場合には、複数の種類のデータを使用し、異なる種類のデータに対して適切なツールを選択する必要があります。これによって直面する問題は、システムの複雑さが非常に高くなることです。

上の写真は、1年以上前のCNCFの調査結果です。データによれば、調査対象となった企業のほとんどが上記の問題に直面しています。たとえば、質問の 1 つは、「可観測性ツールを使用する際に、これまで遭遇した、または今後遭遇すると思われる最大の課題は何ですか?」というものでした。結果によると、最も多かった回答は「システムが複雑すぎて使いにくい」でした。 2 番目の課題は、関連するドキュメント サポートが不足していることです。その根本的な原因は、システムが複雑すぎて使い勝手が悪いことです。システムの複雑さが増すということは、より多くのリソースを投資する必要があることを意味します。開発エンジニアと運用保守エンジニアの両方が、より関連性の高い技術を習得する必要があり、それが最終的には建設コストと運用保守コストの増加につながります。これは、コスト削減と効率向上を実現するために観測可能なシステムを構築するという目的や本来の意図に反するものです。

（２）データサイロ

2 番目の問題点は、データ サイロの問題です。データ ストレージと分析ツールの違いにより、メトリック、トレース、ログをすばやく関連付けて包括的な分析を行うことはできません。まず、このデータを相関させる能力がなぜ重要なのでしょうか?上図に示すように、左側の図はメトリック、トレース、ログ データ間の相関関係を示しています。まず、3 種類のデータはすべて時系列データであり、発生時に相関関係があります。したがって、関連するデータは時間ウィンドウを通じてフィルタリングできます。

データが発生した時間のディメンションに加えて、同じホスト、同じアプリケーション、同じユーザーからのリクエストなど、一部のメタデータを使用して、各観測可能なデータをターゲット ソースにバインドできます。時間ウィンドウをターゲットのソースに関するメタデータと一緒に使用すると、特定のターゲットからの観測を簡単に見つけることができます。

簡単な例として、コール チェーン データとログ データは、メタデータ トレース ID とスパン ID を通じて関連付けることができます。トレース データで遅いリクエストが見つかり、問題の原因となっているスパンを特定すると、トレース ID とスパン ID を関連付けることで、問題が発生しているログをすばやく特定できます。

実際、メトリックと他の 2 種類のデータの間にも同様の関係があります。これらを低レベルで関連付けることで、複数の信号や視点からシステムを観察する際の柔軟性とスムーズさが向上し、異なる信号をすばやく切り替えることでトラブルシューティングの効率が大幅に向上します。

要約すると、異なるデータ ストレージと分析ツールによってデータ サイロが形成されると、複数のデータ タイプを関連付けることが難しくなり、観測可能なデータからより多くの価値を引き出す能力が制限されます。

（３）一般的なユーザーエクスペリエンス

ユーザー エクスペリエンスの低下は、実際には上記の 2 つの問題によって引き起こされます。複雑性が高く、データ関連付け機能が不足しているシステムは、ユーザーに高い要求を課すだけでなく、対象システムの観測可能性の問題を効果的に解決できない可能性もあります。この問題は CNCF の調査文書にも反映されています。

上の図に示すように、左側の質問は「来年の可観測性計画に関する最優先事項は何ですか?」です。回答者の 60% はベスト プラクティスを見つける必要があると示しており、回答者は既存の可観測性システムに概ね満足しておらず、まだ改善の余地が大きいと考えていることが示されています。

右側の質問は、「可観測性システムの使用が義務付けられている場合、どのような懸念がありますか?」です。回答のほとんどは、可観測性システムの統合の難しさや、可観測性システムの使用方法の習得の難しさなど、使用の難しさに焦点を当てていました。

2. ソリューション: 統合型可観測性プラットフォーム

上記の問題点に対して、システムの複雑さを制御し、観測可能なデータ間の迅速なフローと接続をサポートし、ユーザーにとって使いやすく効果的な優れたソリューションはあるでしょうか?その答えは、統合された可観測性プラットフォームです。

（１）統合データ収集ツール

統合された可観測性プラットフォームには、まず、さまざまな種類の観測可能なデータの収集をサポートし、その後のデータの保存と分析を容易にするために、データへのメタデータの追加やデータの内容と形式の処理など、収集の最後にいくつかのデータ処理を完了できる統合されたデータ収集ツールが必要です。たとえば、 OpenTelemetry はこの方向に向けて取り組んでおり、標準となることを目指しています。しかし、現時点では、ログは十分に完璧ではない可能性があります。

（２）統合データストレージ・分析プラットフォーム

統合されたデータストレージおよび分析プラットフォームにより、さまざまな種類のデータのクエリと効率的なデータの関連付けを実現できます。

（３）統一されたユーザーインターフェース

分析クエリ言語、視覚化、アラートを含む統合ユーザー インターフェイス。ユーザーが統一されたインターフェースを使用してデータを照会すると、システムはさまざまな種類のデータ間をすばやく移動でき、統一された分析クエリ言語、統一された視覚化、アラーム機能を通じてシステム使用の複雑さが効果的に軽減されます。一般的に、統一されたユーザー インターフェイスにより、ユーザーの使用しきい値を大幅に下げることができます。

3. Yanhuang Dataとその製品について

1. Yanhuangデータの紹介

2020 年に設立された Yanhuang Data は、新世代のクラウドネイティブ異種ビッグデータリアルタイム分析プラットフォームの研究開発に注力する企業です。 Yanhuang Data Platform (YHP) は当社の製品です。なお、プラットフォームの中核となるビッグデータ分析エンジンは当社が独自に開発し、すべての知的財産権を当社が所有していることは特筆に値します。

Yanhuang データ プラットフォームのアーキテクチャを上の図に示します。

このデータ プラットフォームは、さまざまなデータ ソースからプラットフォームへのデータのインポート、ストレージ エンジンによるデータのインデックス作成、ファイル システムへの保存をサポートします。データ分析エンジンは、ユーザーからのクエリ タスクを実行する役割を担います。このクエリ エンジンに基づいて、プラットフォームは、ビジュアル ダッシュボード、アラート、アドホック クエリなどの機能など、豊富なユーザー インターフェイスを提供し、ユーザーがデータを探索し、データ知識を蓄積できるようにします。ユーザーは、上記のプラットフォーム機能とインターフェースに基づいて、IT 運用と保守、可観測性、生産など、さまざまな使用シナリオに対応できます。

2. Yanhuangデータプラットフォームの機能と特徴

（１）システムアーキテクチャ

このプラットフォームは、クラウドネイティブのマイクロサービス アーキテクチャを採用し、Kubernetes オーケストレーション サービスを使用するほか、Kubernetes のさまざまな拡張および管理方法もサポートしています。

まず、データエンジンに関しては、ストレージとコンピューティングを分離したアーキテクチャにより、コンピューティング層とストレージ層を独立して拡張できます。

2 番目に、スタンドアロンまたはクラスターの展開をサポートします。たとえば、スタンドアロン展開では、プラットフォームのすべてのコンポーネントを同じサーバー上で実行できます。ユーザーがテストを実行している場合、またはクエリ データの量が多くなく、高可用性データが必要ない場合は、ユーザーのデータ分析ニーズを満たすのに 1 台のサーバーのみが必要です。データ量が増えた場合や、高いデータ可用性が必要な場合には、展開方法をクラスターに拡張できます。

3 番目に、外部システムとの統合のための標準 RESTful API インターフェースをサポートします。特定の機能モジュールについては、二次開発フレームワークも提供されます。たとえば、ユーザーは当社のプラットフォーム上で独自の SQL 関数や視覚化コントロールなどを拡張できます。

（２）データ収集

プラットフォームには、データをインポートするための組み込みメソッドがあり、その中で最もよく使用されるのは Syslog、Kafka などです。さらに、エッジ データの収集用に、独自のデータ コレクター DataScale も提供しています。 Yanhuang データ プラットフォーム自体も、観測可能なデータを収集する際に、この独自開発のデータ コレクターに依存しています。

（３）データエンジン

データ エンジンに関して、まず指摘しておく必要があるのは、Yanhuang データ プラットフォームがハイブリッド モデリングをサポートしていること、つまり、読み取り時モデリングと書き込み時モデリングの両方をサポートしていることです。読み取りモデリングにより、非構造化データや半構造化データの処理能力が向上します。データがデータ プラットフォームにインポートされる前に追加の処理は必要ありませんが、データ モデルはクエリ フェーズ中に構築されます。

次に、クエリ言語として標準 SQL を使用します。プラットフォーム内のあらゆるデータは標準 SQL を使用してクエリできるため、多くのユーザーにとって使用しきい値が大幅に削減されます。同時に、ユーザーが SQL を使用してさまざまなデータ計算タスクを完了できるように、さまざまなスカラー関数とテーブル関数も提供しています。

3 番目に、このプラットフォームは、リアルタイムのマテリアライズド ビューなどの事前計算に基づくコンピューティングの高速化もサポートします。

（４）可視化

プラットフォームには、折れ線グラフ、棒グラフなどの豊富なチャートが組み込まれています。チャートは二次開発をサポートしており、ユーザーは必要に応じて開発フレームワークに従って必要なチャートをインポートできます。

豊富なチャートをダッシュ​​ボードに組み込むこともできます。つまり、ユーザーはダッシュボードにチャートを自由に追加し、チャートのサイズとスケールを設定できます。また、ダッシュボードは動的パラメータの導入をサポートしており、クエリ結果に応じてチャート内のコンテンツを動的に表示でき、ドリルダウンやデータジャンプの関連付けなどのインタラクティブなアクションをサポートしていることも特筆に値します。

（５）その他

さらに、アラーム機能やリアルタイム分析機能もあり、データ分析や観測シナリオの分野で非常に実用的な機能です。

4. YHP独自の可観測性構築の実践

次に、Yanhuang Data Platform (YHP) の可観測性の実践について紹介します。

1. 自社開発のデータ収集装置

Yanhuang データ プラットフォームは、独自に開発したデータ コレクター DataScale を通じて観測可能なデータを収集します。DataScale は、メトリック、トレース、ログの 3 種類の観測可能なデータの収集をサポートします。

これまで、ユーザーは通常、OpenTelemetry のコレクターを介してトレース データを収集し、Prometheus のエクスポーターを使用してログ データを取得するなど、さまざまな種類の観測可能なデータを収集するためにさまざまなツールを使用する必要がありました。

市場にはさまざまなデータ ソースをサポートするデータ収集ツールが多数ありますが、当社のデータ コレクターでは、これらの一般的なデータ収集方法がプラットフォームのデータ コレクターに統合されています。それだけでなく、データ コレクターはデータ ソースを構成し、データ ソースに接続した後にデータ処理ロジックを構築することもできます。したがって、OpenTelemetry コレクター、Prometheus エクスポーター スクレーパー、およびその他のさまざまなデータ ソースをデータ コレクターのソースとして構成できます。

2. データ処理

データが収集され、集中された後、データはデータ処理モジュールに転送され、データにメタデータ情報を追加するなどのデータ処理が行われ、その後、データが Yanhuang データ プラットフォームにインポートされます。

統合データ コレクターを使用する主な利点は 2 つあります。1 つ目は、すべてのデータ ソースへのアクセスを統一的に管理でき、優れたユーザー エクスペリエンスを備えた UI が提供されるため、ユーザーは視覚的にデータ アクセスを管理できます。 2 つ目は、データがプラットフォームに保存される前に、メタデータの補足、データの構造と形式の処理など、収集側でデータを処理して、その後の保存と分析を容易にできることです。

3. YHPにおけるデータ収集装置の導入

上の図は、Yanhuang データ プラットフォームにおけるデータ コレクターの展開方法を示しています。通常、データ収集には 2 つのシナリオがあります。1 つはデータ プラットフォームの各ノードでローカル データを収集することであり、もう 1 つは中央ノードを使用してサービス データを収集することです。したがって、Yanhuang Data Platform にデータ コレクターを展開する方法は 2 つあります。 1つは、Kubernetes DaemonSetの形式でデプロイし、各ノードで実行することです。このデータ コレクターは、ローカル ログ ファイルを収集し、ローカル ノード エクスポータからホスト メトリックを取得します。

もう 1 つの方法は、Kubernetes Deployment を使用してデータ コレクターを実行することです。アグリゲータとして、プラットフォーム内のさまざまなアプリケーションからインジケーター データを取得し、Web サービスからトレースを受信する役割を担います。

上記の 2 つの方法により、データが欠落したり、データが重複して収集されたりすることがなくなります。

4. YHP独自の観測データの保存

観測可能なデータが Yanhuang データ プラットフォームに収集された後、メトリック/トレース/ログは異なるデータ セット (データベース内のテーブルの概念に相当) に保存されます。主な理由は、クエリは通常データ セットに基づいているため、パフォーマンスを最適化することです。特定の種類のデータをクエリする場合、パフォーマンスは他の 2 つの種類のデータ量の影響を受けず、低下しません。

記事の冒頭にある 3 つの重要な指標の図からわかるように、異なる種類のデータのデータ量の大きさは異なり、通常はログ データが最大になります。実際の状況では、メトリック データのクエリには比較的高速な応答速度が必要です。したがって、上記の保存方法を使用すると、ログやトレースに大量のデータが含まれていても、メトリックのクエリのパフォーマンスに影響はありません。

複数のデータセットを使用するもう 1 つの利点は、データの種類ごとに異なるライフサイクルを設定できることです。データの種類によって、使用シナリオや特性に応じて必要な保存期間が異なります。たとえば、ログやトレースは通常、より長い保存期間を必要とします。一方、インジケーター データでは最近のデータのみを保存する必要がある場合があります。

右の図からわかるように、データセットごとに容量制限を設定したり、タイムスタンプを使用して時間ウィンドウを使用してデータを制限したりできます。もちろん、ユーザーは特定のシナリオでデータを特別に処理することもできます。たとえば、コンプライアンス上の理由やその他の理由でデータを保持する必要があるが、クエリのパフォーマンスに影響を与えたくない場合は、データを指定したパスにアーカイブすることもできます。

上の図は、収集されたデータのコンテンツ表示形式を示しています。 3 つのグラフには、呼び出しチェーン データ (トレース)、インジケーター データ (メトリック)、およびログ データ (ログ) が表示されます。左上のグラフが指標データです。アンダースコアで始まるフィールドは追加のメタデータ フィールドであり、アンダースコアで始まらないフィールドはインジケーター データの元のフィールドです。たとえば、図の「counter.value」フィールドの値とインジケーターの名前は、どちらも元のフィールドです。さらに、ノード情報、タイプ情報、ホスト情報などの追加情報、これらのメタデータ情報は、後続の関連クエリで使用されます。

右側のグラフはコールチェーンデータを示しています。アンダースコアで始まるフィールドには、どのサービスに属しているか、どの Kubernetes 名前空間から来ているかなどのメタデータも追加されます。以下の元のフィールドも、OpenTelemetry 標準に準拠したタグ フィールドです。

左下の画像は共通ログデータで、ハイライト表示されている部分がトレースIDです。 Yanhuang Data Platform の可観測性関連機能をオンにすると、ログ内の呼び出しチェーンのトレース ID とスパン ID がログに書き込まれるため、トレース ID とスパン ID に基づいてアプリケーションに関連するログ情報を取得しやすくなります。

5. 統合SQL関連クエリ

上の図は、統合 SQL クエリを使用してトレースとログを個別にクエリし、トレース ID に関連付けられたデータをクエリするクエリの例です。

図に示すように、左側の yhp_monitoring_traces はトレースを保存するデータセットです。解析されたフィールドでフィルタリングして、ターゲットの呼び出しチェーン レコードを取得できます。たとえば、対象データは、HTTP 戻り値が 400 以上の異常なリクエスト呼び出しレコードと、kind=2 のルート スパンから始まるトレースです。関連するトレース ID を取得した後、別のクエリを使用して、_internal データ セットからこのトレースに関連するすべてのログをフィルター処理し、サービス内のリクエストに何が起こったかを確認します。これは、関連付けクエリを手動で実行する必要があるシナリオです。 Yanhuang Data Platform のダッシュボードはドリルダウン機能をサポートしており、ダッシュボード上で関連するクエリをクリックしてトレース ID を設定し、ログ クエリの結果に直接ジャンプすることができます。

6. 視覚化された警告統合監視コックピット

上の図は、観測可能なデータに基づいて構築された統合視覚化ダッシュボードとアラートを示しています。インジケーター データとコール チェーン データに基づいて視覚的なダッシュボードを構築し、プラットフォームに異常があるかどうかを直感的に表示します。さらに、アラーム機能は各コンポーネントの検査機能にも反映されており、プラットフォームを数分ごとに定期的にチェックして異常がないか確認します。異常が発生した場合、ダッシュボードに異常ステータスが表示され、下のアラームリストに該当するアラームが表示されます。ログ内の既知の問題に関する警告シナリオも含まれています。

中央の図は、ホストのメトリック データに基づいてホストの現在のシステム ステータスを表示するメトリック ベースのダッシュボードを示しています。右の図は、メトリックとトレースに基づいた Web アプリケーションの健全性を示しています。これらの例は、統合された可観測性プラットフォームを使用して可観測性を構築する大きな利点は、データ サイロの問題を回避できることであることを示しています。アプリケーションの健全性を観察する必要がある場合、関連するすべての観察可能なデータを健全性インジケーター データとして一元的に視覚化できます。

7. Yanhuangデータプラットフォームからのダンプデータの収集

ここでは、システムの可観測性を向上させるために、より多くの可観測性関連のデータ型を使用する試みについて簡単に説明します。自社開発のデータ処理エンジンの開発中、コアダンプのシナリオは非常によく発生します。コアダンプ情報を迅速に分析できれば、開発効率を効果的に向上できます。

ただし、ダンプ情報を収集するための成熟したソリューションは存在しません。また、Linux カーネルのいくつかの制限により、理想的な収集方法はまだ見つかっていません。 Docker コミュニティでは、各コンテナがコアダンプ ファイルのパターンを設定できるようにするなどの解決策がいくつか言及されていますが、この技術は短期的には実現されない可能性があります。

現在、Yanhuang Data Platform がダンプ情報を収集する方法は、共有 Kubernetes PV を使用して各サービスのコアダンプ ファイルを保存することです。各サービスは、専用のディレクトリにコア ダンプ ファイルを生成します。データ コレクターは、共有 PV からすべてのサービスのダンプ データを収集し、コア ダンプ ファイルのパスまたはファイル名をメタ情報識別子に追加して、どのサービスのどのモジュールでコア ダンプが発生したかを示します。

ダンプ データを Yanhuang データ プラットフォームにインポートした後、ダッシュボードと関連アラームを作成することもできます。ダッシュボードには、各サービスのコアダンプ履歴を表示できます。コアダンプ ファイルを解析できる場合、コアダンプが発生した時点のバックトレースをダッシュ​​ボードの下半分に直接表示できるため、開発者は例外の原因をすぐに把握でき、コアダンプ ファイルを自分で探して解析する時間を節約できます。

8. Kubernetes ヘルスモニタリング

最後に、Kubernetes のヘルスモニタリングについて説明します。現在、Yanhuang データプラットフォーム上に Kubernetes のデータ収集システムが構築されていません。しかし、私たちは Kuberhealthy というツールを使用して、ネットワーク リンクの健全性を監視するのと同様のアプローチを採用しました。イメージのプル、ポッドの取得などの一部の Kubernetes 操作をアクティブに実行し、操作の結果を記録します。これらの操作は、 Prometheusエクスポーターを介して出力できます。私たちはデータを Yanhuang データ プラットフォームにインポートし、Kubernetes クラスターの健全性を監視するためのアラートとダッシュボードを構築しました。

まとめると、統合された可観測性プラットフォームの利点は非常に明白です。まず、データの収集、分析、保存という 3 つの主要モジュールのプロセスを統合し、システムの複雑さを大幅に軽減し、システムの運用および保守コストとシステムに必要なリソースを削減しました。同時に、統合された可観測性プラットフォームは、さまざまな種類のデータを関連付ける強力な機能を提供し、観測可能なデータからより多くの価値を掘り出す可能性も提供します。ユーザー エクスペリエンスの面では、統合されたユーザー インターフェイスにより使いやすさも向上します。

9. Yanhuangデータプラットフォームの最新バージョン

Yanhuang Data Platform の最新バージョンは 2.11 です (※ここでの 2.11 バージョンは、2023 年 8 月 5 日に開催される DataFunSummit2023: Cloud Native Big Data Summit の共有バージョンを指します)。エンタープライズ バージョンとコミュニティ バージョンの両方がリリースされています。コミュニティバージョンは完全に無料です。ユーザーはスタンドアロン バージョンをローカルで実行できます。コアデータ分析機能の多くは、エンタープライズ バージョンと変わりません。エンタープライズ バージョンでは、エンタープライズ運用に重点を置いたエンタープライズ関連の機能に重点を置いています。誰でもフォローして体験できます。