クラウドネイティブの可観測性に関する簡単な講演

背景

現在、デジタル変革のプロセスは加速し続けています。トップレベル設計の指導の下、自社の開発ニーズと組み合わせて、フルスタッククラウドを総合的に推進し、クラウドネイティブエコシステムの構築を深め、マイクロサービスやコンテナなどのクラウドネイティブ技術の業務アプリケーションへの広範な活用を推進します。当社は、DevOps モデルに基づいて研究開発を行い、従来のモノリシック サービスをより細かい粒度のマイクロサービス モジュールに分割することで、システムがコンテナ化された展開に適応し、アジャイルなビジネス反復の研究開発をより適切に実施し、システムのビジネス価値を迅速に出力できるようにします。

クラウドネイティブ構築は、マイクロサービスの再構築、国内の情報技術革新、分散データベース、コンテナクラウド、サービスガバナンスなどの側面を含む包括的なシステムプロジェクトです。システムの規模や複雑さ、データ量は飛躍的に増加しており、起こり得る障害の数や種類も年々増加しています。サービスの継続的かつ安定した運用を総合的かつ効果的に確保することが重要です。クラウドネイティブのセキュリティ運用は、現在私たちが直面している重要な課題です。

課題

サービスの安全な運用を確保するためには、まずシステム運用の状況や動作を十分に把握できなければなりません。これには、最下層から最上層までのネットワーク、ホスト、コンテナ、アプリケーション、ビジネス サービスなどのフルスタックの可観測性が求められます。観測可能性は制御理論の分野から生まれたもので、システムの内部状態を外部出力から推測できる程度を指します。クラウドネイティブ アーキテクチャでは、可観測性はシステム内で何が起こっているかの可視性のレベルを表します。クラウド ネイティブ システムは規模が大きく、複雑で、動的に変化します。これらを包括的かつ効果的に理解し、制御し、安全な運用を確保することは、大きな課題に直面しています。

大規模な動的コンテナ環境におけるアプリケーションの実際の動作を理解する方法:クラウドネイティブ システムは、コンテナ化テクノロジによってインフラストラクチャを標準化し、アプリケーションの展開の利便性を向上させ、動的な拡張と縮小をサポートします。仮想化カプセル化により、インフラストラクチャ層の情報は透過的ではなくなりました。マイクロサービス アーキテクチャにより、アプリケーションによってデプロイされるサービスの数が劇的に増加し、コンテナ クラスターは業務運用状況に基づいて動的にスケジュールされます。サービス間のトラフィックは南北と東西の両方向に流れ、東西のトラフィックが主なトラフィック方向となります。このような大規模で動的なサービス インスタンスの環境では、アプリケーション、コンテナー、ホスト、ネットワークの動作を効果的かつ包括的に理解することが、安全なビジネス運用を確保するための鍵となります。

複雑なサービス呼び出し間の障害を迅速に特定する方法:単一のサービスがマイクロサービスに分割されると、モジュール間の相互作用はプロセス内のメソッド関数呼び出しからプロセス間のサービス呼び出しに変換され、サービス呼び出しパスが長くなり、ネットワーク相互作用を横断するようになります。エラーが発生した場合、いかに迅速に障害箇所を特定し、トラフィックの切り替えやサービスのロールバックなどの対策を適時に講じるかが、サービスの継続的な運用を確保するための鍵となります。異なるサービス モジュールは、システム全体において異なる機能を持ち、要求圧力も異なります。システムがパフォーマンスのボトルネックに遭遇した場合、ボトルネックとなっているサービスを迅速に発見してサービス容量を拡張するか、または適時にヒューズや電流制限措置を講じるかが、サービスの安定した運用を確保するための鍵となります。

リアルタイムの観測機能を確保する方法:クラウド ネイティブ アプリケーションの動的な性質により、観測プラットフォームはリアルタイムまたはほぼリアルタイムである必要があります。アプリケーションのアップグレードまたは拡張が数分で完了する場合、監視システムは数秒以内にフィードバック機能を提供する必要があります。クラウドネイティブ システムによって生成されるメトリック、追跡、ログ、その他のデータは膨大になることが多く、大量のデータをリアルタイムで処理する可観測性プラットフォームの能力に極めて高い要求が課せられます。

複数の運用および保守プラットフォームの有機的な統合を実現する方法:クラウド ネイティブ エコシステムには、複数のサポート システムが含まれます。各システムの有機的な連携動作により、クラウドネイティブな運用プラットフォームを共同で構成できます。しかし、現実には、各運用・保守ツール プラットフォームは、異なる時期、異なる製品、異なるメーカーによって構築されています。これらの運用保守ツール プラットフォームのデータをどのように効果的に管理し、データの相関と統合を実現し、データの価値を十分に発揮させ、運用と保守のパノラマ的な運用と有機的な調整を実現するかは、運用保守データ ガバナンス機能にとって大きな課題です。

上記のクラウドネイティブ アーキテクチャによってもたらされる新たな問題と課題に対応するために、私たちは上記の懸念に対処するための総合的なクラウドネイティブ オブザーバビリティ プラットフォームの設計に取り組みます。

可観測性プラットフォームの設計

可観測性プラットフォーム ソリューションの設計は、観測可能な運用および保守オブジェクト、観測可能なデータ、データ相関、および可観測性ソリューションの実装の 4 つの部分で構成されます。これには、運用および保守オブジェクトの識別、観測可能なデータ標準、およびさまざまなデータ相関の実装が含まれており、全体的な観測可能性ソリューションを形成して最終的に価値出力を実現します。

観測可能なオブジェクト

クラウド ネイティブ システムの可観測性システムは、ネットワーク、ホスト、コンテナー、アプリケーション、ビジネス サービスなど、クラウド ネイティブ システムのすべてのコンポーネントをカバーする必要があります。システム内の監視対象の位置に応じて、可観測性システムは、図 1 に示すように、システム インフラストラクチャ、コンテナー、アプリケーションからビジネスまでの全範囲をカバーする 4 つのレベルに分かれています。

図1 クラウドネイティブ運用保守スタックの概略図

インフラストラクチャ層: IaaS 層とも呼ばれ、この層に含まれる監視対象は、ネットワーク、ストレージ デバイス、ベア メタルなどのシステムの基盤となるリソースです。これらのデバイスとコンポーネントの信頼性は、上位層のアプリケーション サービスの安定性に直接影響します。このレイヤーに関連付けられた可観測性データには、インジケーター (ネットワーク トラフィック、ネットワーク接続数、ホスト パフォーマンス)、ログ (スイッチ ログ、オペレーティング システム ログ)、イベント (システム プラットフォーム イベント、障害、ダウンタイム) などが含まれます。

コンテナ レイヤー: PaaS レイヤーとも呼ばれます。このレイヤーに含まれる監視対象は、Kubernetes サービス、クラスター ノード、CPU、メモリ、ストレージなどの動作状況など、コンテナ内のシステム リソースをカバーします。これは、コンテナ クラウド プラットフォームの監視です。これらのリソースの使用によって、アプリケーション サービスのパフォーマンスと容量が決まります。このレイヤーに関連付けられた可観測性データには、インジケーター (ノードまたはコンテナの CPU 使用率、メモリ使用率、ストレージ使用率など)、ログ (さまざまな Kubernetes コンポーネントのログ)、イベント (Kubernetes イベント) などが含まれます。

アプリケーション層:この層に含まれる監視オブジェクトは、サービス可用性、JVM、ミドルウェアなどのアプリケーション サービスと密接に関連しています。これらの監視オブジェクトの健全性と負荷によって、アプリケーション上で実行されているビジネスの可用性とパフォーマンスが決まります。このレイヤーに関連付けられた可観測性データには、インジケーター (サービスの存続可能性、JVM メモリ使用量、JVM GC 一時停止期間、データベース接続、キャッシュ接続、メッセージ キュー メッセージの蓄積など)、リンク (アプリケーション サービスとミドルウェアを呼び出すアプリケーション間の呼び出しによって形成される分散リンク)、ログ (操作ログ、エラー ログ) などが含まれます。

ビジネス層:この層に含まれる監視対象は、主にトランザクション量、取引金額、サービス要求量、要求遅延、変更率、エラー率などのビジネス運用情報です。これらの監視指標は、ビジネスの運用状況を直接反映し、ユーザー エクスペリエンスと企業の発展を反映します。このレイヤーに関連付けられた可観測性データには、インジケーター (アクセス統計、リクエスト数、エラー数、レイテンシなど) とログ (アクセス ログ、エラー ログ) が含まれます。

観測可能なデータ

システムの稼働状況データを収集・分析することで、システムの稼働状況を把握し、迅速なトラブルシューティングを実現する可観測性システムを構築します。したがって、まず観測可能性データを定義する必要があります。現在主流の業界標準では、観測可能性データを次の 3 つのカテゴリに分類しています。

図 2 メトリクス、トレース、ログとそれらの関係

メトリック:メトリック データは通常、一定期間にわたって測定可能なデータであり、時系列データとも呼ばれ、システムの状態と傾向を観察するために使用され、曲線グラフを描画するためによく使用されます。次の 4 種類のデータがサポートされています。

インジケーターのデータ型

インジケーター効果表示

トレース:分散トレースは、分散システムの実行中に上流および下流の要因とそれらの影響を理解する方法です。フロントエンドからバックエンド サービス、データベースなどのミドルウェアまでのアプリケーション リクエストのフローを追跡し、レイテンシが高くエラー率の高いリクエストのトラブルシューティングをサポートします。同時に、リンク データからサービスの RED (レート、エラー、期間) を抽出して、指標の監視を強化できます。

トレースパスの認識とパフォーマンス分析

トレース効果表示

ロギング:ログ データは個別のイベントの記録であり、システムの動作中に生成された情報を反映し、システムの動作状態を詳細に説明できます。ほとんどの開発言語、アプリケーション フレームワーク、またはライブラリはログ記録をサポートしています。ログは、システム ログ、アプリケーション ログ、セキュリティ ログ、インフラストラクチャ ログなど、さまざまなカテゴリに分類できます。ログに保存される情報はフォーマットされていないテキストであり、後続の分析を容易にするために、対応するフィールド仕様を策定する必要があります。たとえば、ログにはサービス名、トレース ID、および収集された追加のコンテナー情報が含まれます。

ログ表示

データの関連性

観測対象は4つのレイヤーに分かれていますが、実際の使用においては、通常、複数のレイヤーと複数の運用保守ツールプラットフォームからのデータを組み合わせて問題を分析する必要があり、観測データ間に一定の相関関係が必要となります。次の図に示すように:

データの関連性

データの特性に基づいて、次のように分類できます。

同じ操作と保守オブジェクトの関連付け

同じ操作および保守オブジェクトには明確で一意の識別子が必要であり、異なるデータ (インジケーター、リンク、ログ) では統一された識別標準を使用する必要があります。ユーザーは、同じ識別子セットを使用して異なるデータを個別にクエリし、相関分析を容易にすることができます。たとえば、Prometheus アラートのラベルとタイムスタンプに基づいて、ログ内の特定の時間における対応するサービスの動作を見つけたり、リンク内の特定の時間における対応するサービスの実行リンクを見つけたりすることができます。

同じ操作および保守オブジェクトと対応する指標およびログデータ

異なる運用および保守オブジェクト間の関連付け

さまざまな運用および保守オブジェクト間の関係は非常に多様であり、特定の問題を具体的に分析する必要があります。従来の環境では、通常、IP アドレスに基づいてさまざまなホストとネットワーク ノードを識別し、関連付けます。コンテナ クラウド環境では、通常、さまざまな運用および保守オブジェクトとリソースがタグに基づいて識別されます。リソース タイプはそれぞれ異なりますが、組み合わせることができるように同じタグが付いている必要があります。たとえば、Kubernetes のデプロイメントとサービスの定義は、一致して対応する機能を実現するには、対応するラベルと一致する必要があります。

異なる操作および保守オブジェクトはラベル識別に基づいて関連付けられます

リンクIDの関連付け

分散環境では、アプリケーション サービスはさまざまなサービス モジュールに分割されます。サービス リクエストは複数の異なる操作および保守オブジェクトにまたがり、操作および保守オブジェクトも複数の異なるリクエストに対応します。この分散同時実行により、異なるリクエストを区別することが難しくなります。この問題は、TCP が複数の要求を処理する場合の問題に似ています。 HTTP1.1 にはリクエスト識別子がないため、多重化できません。 HTT2 ではこれを可能にするためにストリーム識別子を追加しました。同様に、異なるアプリケーション間のサービス要求も、一意の識別 ID を追加することで区別できます。リンク ID に基づくリンク トラッキングにより、分散要求を呼び出しリンクに復元し、各サービス ノードで消費された時間、要求が具体的にどのマシンに到達したか、各サービス ノードの要求ステータスなど、分散要求の呼び出しステータスを一元的に表示して、呼び出しトポロジの視覚化、上流と下流の依存関係の分析、および迅速な障害箇所の特定を実現できます。

トレースIDに基づいて複数の操作および保守オブジェクトのログとリンクを相関させる

前述の運用保守対象とデータの相関関係を活用し、インフラ、コンテナクラウド基盤、アプリケーション、業務情報など、整理されたフルスタック運用環境（図1）と組み合わせることで、運用保守対象ごとに異なるコンポーネントやレベルの観測データを表示する全体パノラマ観測トポロジマップを構築し、CMDB情報と連携して直感的なトポロジ情報表示を実現します。

フルスタック監視トポロジー図

観測可能な実装

可観測性システムの実装は、可観測性データの収集、可観測性データの分析、および可観測性データ値の出力という 3 つの主要なプロセスに分かれており、可観測性データの生成、収集、処理、分析、保存、および適用の全プロセスをカバーしています。

可観測性データ収集

データ収集

このプロセスでは主に、インジケーター、リンク、ログの 3 種類のデータを含む、観測可能性データの標準化された定義と収集が完了します。収集されたデータの整合性とアプリケーションへの非侵入性をどのように確保するかが、ソリューションで考慮する必要がある重要な問題です。指標データは、比較的固定されたデータ構造を持つ時系列データです。設計時には、インジケータ サーバーのパフォーマンスに影響を与える可能性のある過剰なデータ量を回避するために、ビジネス情報を表すタグの数と値の範囲を制限する必要があります。 Kubernetes プラットフォーム、ビジネス アプリケーション、ミドルウェアなどでは、収集にサーバー プル モードが採用され、独立したインジケーター収集コンポーネントが対応するサーバーに展開されます。これらのコンポーネントは、インジケーター データを収集し、インジケーター サーバー (Prometheus など) によって定期的に呼び出される HTTP プロトコルを介して外部にインジケーター クエリ インターフェイスを提供する役割を担います。ビジネス アプリケーションの場合、Java エージェント テクノロジを使用して、JVM アプリケーションの起動時に JVM バイトコードを強化し、ビジネス コードを変更せずに JVM パフォーマンス インジケーターとビジネス インジケーターを生成することで、監視ロジックをビジネス ロジックから分離し、開発プロセスのスケーラビリティを確保します。上記の収集プロセスは、アプリケーションに侵入することなく実行できます。

データのスケーラビリティを向上させながらリンク データ構造を比較的固定化するために、リンク データ構造は半構造化 JSON 形式を採用しています。リンクデータについては、開発フレームワークにリンクトラッキングライブラリが導入されています。このライブラリは、サービス間呼び出しや主流のミドルウェア (データベース、キャッシュ、メッセージ キューなど) へのサービス呼び出しなどの主要なプログラム実行場所を自動的に追跡し、一般的なリンク収集および追跡ロジックを提供します。この開発ライブラリを導入することで、該当箇所のリンク集が自動的に完了します。また、手動トラッキング機能も提供しており、開発チームは独自のビジネスニーズに基づいてリンクトラッキングコードをカスタマイズし、特定のシナリオでリンク情報を収集できます。非侵入型トラッキングを通じて一般的なリンク収集の問題を解決し、それを手動トラッキングと組み合わせてパーソナライズされたカスタマイズのニーズを満たすことで、コードの侵入を少なくしながら、アプリケーションの包括的なリンク収集のニーズを満たすことができます。

ログ データのその後の分析と処理の統一的な標準化を考慮して、ビジネス チームは標準化されたログ データ構造仕様を策定し、実装する必要があります。ログ データについては、独立したコンポーネント レポート モードを使用して収集します。ローカル ログ データの読み取りを完了し、ログ サーバー (ElasticSearch、Loki、ClickHouse など) に報告するために、対応するサーバーに独立したログ収集コンポーネント (Filebeat や Flunetbit など) を展開します。ログ収集コンポーネントは共通の収集構成テンプレートを使用しているため、運用および保守担当者はそれをすばやく変更してローカル ログを収集し、ログ アクセス監視の効率を向上させ、両者のログ ディレクトリの開発に合意して両者間の分離を実現できます。

可観測性データ分析

インデックス分析と処理

インジケーター収集側 (Prometheus、Grafana Agent など) は、まず、さまざまなインジケーターの特性に応じて、インジケーター収集コンポーネントから収集されたインジケーターをメモリ内にクラスター化します。 2 時間以上メモリに保存されているインジケーター データは、インジケーター データの長期保存の目的を達成するために圧縮されてディスクに保存されます (Thanos を使用)。時間指定トリガー方式（Prometheus レコードルール）を使用して、指標データを時系列データベースから定期的に読み取り、集計および分析し、集計された指標を生成して、高レベルの抽象的な粒度分析をサポートします。さらに、指標監視データの価値は時間の経過とともに減少しますが、ストレージ コストは時間の経過とともに増加するため、履歴データを圧縮してダウンサンプリングする (Thanos ダウンサンプリング) と、より長い履歴データを保持しながらストレージ コストを削減し、クエリの効率を向上させることができます。

リンク/ログの分析と処理

リンク サーバーは、クライアントから報告されたリンク データを受信した後、まずリンク データをメッセージ キュー (Kafka など) にプッシュし、メッセージ キューの高性能ストリーミング処理機能を使用して、リンク データのその後の分析と保存のパフォーマンスを保証します。その後、リンク ストレージ アプリケーションは、メッセージ キュー内のリンク データを読み取り、それをフルテキスト検索ミドルウェア (ElasticSearch など) に直接保存します。一方、リンク解析アプリケーションは、メッセージキュー内のリンクデータを読み取り、メモリ内のリンクデータのクラスター解析を実行して、システムサービストポロジを構築します。サービス トポロジ情報には、システム内の分散リンクを構成するすべてのアプリケーション、アプリケーション間の呼び出しの数と平均遅延、およびアプリケーション内のエラー分布が含まれます。リンク分析アプリケーションは、分析されたデータをフルテキスト検索ミドルウェアにも保存します。フルテキスト検索ミドルウェアを使用してリンク データとサービス トポロジ データを保存すると、後続の豊富なデータ取得シナリオの実装をサポートできます。

ログ サーバーはリンク サーバーに似ています。ログ サーバー (ElasticSearch、Loki など) がログ収集コンポーネントによって報告されたログ データを受信すると、ログ解析コンポーネントは、事前に定義されたログ解析ルールに基づいてログ データに対して形式解析とデータ フィルタリングを実行し、解析されたデータを標準の JSON データ形式に構築します。このデータは、フルテキスト検索ミドルウェア (ElasticSearch など) に分類されて保存されます。ログ解析コンポーネントはクラスターにデプロイされ、並列ストリーミング処理を使用して解析プロセスの高パフォーマンスを保証します。ログ解析ルールは、JSON、Logfmt などの複数のログ解析形式をサポートし、カスタム ログ パーサーもサポートしているため、運用および保守担当者はさまざまなビジネス シナリオのニーズに合わせてログ形式をカスタマイズできます。

可観測性データ値の出力

可観測性値の出力例 - インジケーターダッシュボード

統合された可観測性プラットフォームを通じて、統合され、構成可能で、視覚化された監視、アラーム、トラブルシューティング、およびログ取得機能が提供され、障害アラーム、大画面監視、リンク取得、ログ取得などの可観測性システムの価値出力を実現します。障害アラームは、システム障害に対して自動的にリアルタイムでアラームを発する機能を提供します。この機能は、ユーザーがインジケーターとログ キーワードに基づいてアラーム ルールをカスタマイズし、アラームを自動的にトリガーし、複数のチャネル (電子メール、通信ソフトウェア) を通じてアラーム通知をリアルタイムで送信することをサポートします。これにより、運用および保守担当者はシステムの異常な状況をできるだけ早く発見できます。監視画面では、システムの現在の動作状態を監視チャートで表示する機能を提供します。この機能は、ユーザーが事前に設定された画面テンプレートに基づいて監視画面を作成することをサポートします。監視画面は、インジケーター サーバーのインジケーター データ クエリ インターフェイスをリアルタイムで呼び出して、監視パネルを生成します。監視パネルは、折れ線グラフ、棒グラフ、円グラフ、メーターなどのさまざまなインジケーター表示形式をサポートしており、運用および保守担当者がシステムの現在の状態を直感的かつ効率的に把握したり、開発、テスト、および製造段階で障害の分析と特定を行ったりするのに役立ちます。

可観測性値の出力例 - トラブルシューティング

リンク取得では、リンク データのクエリ、リンクの詳細表示、およびサービス トポロジ分析機能が提供されます。この機能を使用すると、ユーザーはリンク ID または時間範囲に基づいてリンク データを照会できます。分散リンクの詳細ページでは、リクエストがシステムを通過する際に通過するアプリケーション サービスのクリティカル パスと、各処理段階の具体的な時間消費を視覚的に確認できます。開発および運用保守担当者は、リンク検索機能を使用して、障害を迅速に特定したり、各呼び出しリンクのパフォーマンスと可用性を分析したり、ユーザーの動作データ ログ検索に関する統計分析を実行したり、ログ データのクエリと分析機能を提供したりできます。ログ検索機能を利用することで、運用・保守担当者は分散システムの膨大なログから必要なログを素早く見つけ出し、ログベースの障害原因調査や業務データ統計を実施することができます。

可観測性システム設計を通じて、複雑なクラウド ネイティブ システムのさまざまなレベルのオブジェクトを監視するための可観測性データの収集、分析、および値の出力プロセスが実行され、クラウド ネイティブ システムの完全な監視が実現され、システムの現在の動作状態に関する迅速な洞察がサポートされます。システム障害が発生するとリアルタイムのアラームが発行され、多次元監視ツールによって障害の迅速な特定と解決が支援され、システムの可用性が確保されます。システムが提供する監視機能は、システム開発およびテストのフェーズにも適用でき、開発上の問題を迅速にトラブルシューティングし、アプリケーション パフォーマンスの監視を支援し、ビジネス提供の効率と品質を向上させることができます。

今後の展望

可観測性プラットフォーム

プラットフォーム構築の過程で、クラウド ネイティブ システムの可観測性システムに関して、さらに調査できる領域がまだあることがわかりました。

• 継続プロフィルは、CPU 使用率や関数呼び出しの頻度と期間など、プログラムの複雑さとパフォーマンスを詳細に分析するための動的な方法です。継続的なプロファイリングにより、アプリケーションのどの部分がどの時点で最も多くのリソースを消費しているかを正確に特定できるため、コア プログラムの実行パフォーマンスを最適化するための信頼性の高いソリューションが提供されます。
• OpenTelemetry (OTEL) 標準は、OpenCensus プロジェクトと OpenTracing プロジェクトの合併によって形成された CNCF プロジェクトであり、テレメトリ データ (トレース、メトリック、ログ) を計測、生成、収集、エクスポートするためのベンダー中立のオープン ソースの可観測性フレームワークです。観測データのデータ モデル、データ収集、データ処理、データ ガバナンス、およびデータ エクスポートを標準化するための一連の標準仕様とツール セットを提供します。現在、さまざまな主流のオープンソース プロジェクト (Kubernetes や Spring Cloud を含む) が OTEL のサポートや切り替えを開始しており、今後 CNCF が推進する主なソリューションとして注目に値します。
• eBPF (Extended Berkeley Packet Filter) は、BPF (Berkeley Packet Filter) テクノロジを拡張したパケット フィルタリング テクノロジです。 Linux 4.14 カーネル以降、Linux コミュニティは eBPF に複数の新機能と最適化の改善を追加し、トレース分析、可観測性、セキュリティ、ネットワーク アクセラレーションなどのシナリオで eBPF のアプリケーション機能を強化しました。 eBPF はカーネル内での観察とトレースを実装し、非侵襲的な継続的なプロファイリングを可能にし、さまざまなソースに基づいて可視性イベントを生成して、達成可能な可視性の深さを拡張します。

システムレベルでのフルスタック、フルリンク観測機能の拡張 - コレクション

フルスタックおよびフルリンクの観測機能をシステムレベルに拡張 - 展望

今後は、eBPF をベースにオペレーティングシステムのカーネル状態の可観測性を実装し、それをユーザー状態の OpenTelemetry と組み合わせてクラウドネイティブの観測データを収集および処理するための標準パラダイムを確立し、継続的な分析を導入して可観測性の深さと幅を継続的に拡大することが、クラウドネイティブ環境の可観測性を強化するための今後の開発トレンドになるでしょう。

要約する

クラウドネイティブ アーキテクチャはエンタープライズ システム配信の効率を向上させますが、システムの複雑さも飛躍的に増大します。したがって、システムを観測可能にし、システムの内部状態を理解しやすくすることが特に重要になります。システム観測プラットフォームは、クラウドネイティブのトレンドの必然的な産物です。この記事では、データの収集、分析、保存、価値出力、データ間の関係性など、クラウドネイティブシステムの可観測性プラットフォームの主要な技術ソリューションについて説明します。また、可観測性プラットフォームを使用して障害を効率的に特定して解決し、障害の特定と解決の運用と保守のコストを削減し、クラウドネイティブシステムの高性能と高可用性を最大限に確保する方法についても説明します。同時に、オペレーティングシステムのeBPF、Opentelementry、人工知能機械学習などの技術の継続的な発展により、可観測性技術は情報技術の革新とクラウドネイティブのシナリオにおいて確実により大きな役割を果たし、次世代の監視技術の開発を促進します。