監視から可観測性まで、設計思想、技術選択、責任分担にはどのような変化があるのでしょうか?

多数のクラウドネイティブテクノロジーの適用により、IT システムはますます複雑になっています。障害を積極的に検知、予測し、迅速に特定してトラブルシューティングを行うことの難しさはますます大きくなっています。従来の監視方法では、もはや需要に追いつくことができません。その結果、可観測性が登場し、将来のクラウド環境の実稼働展開に不可欠な技術サポートとして見られるようになりました。

現在、ほとんどの従来型企業はまだ可観測性の理解の初期段階にあり、多くのインターネット企業は可観測性の構築を始めたばかりです。そこで、今回のdbaplusトピックリレーコラムでは、「監視から観測への転換とアップグレードの方法」というテーマを中心に、知湖の全リンク観測システムとアクセス層ネットワークの責任者である熊宝氏、Huya Live SREプラットフォームR＆Dチームの責任者である郭玲軒氏、Haodaifuインフラ部門のシニアエンジニアである方勇氏の3名の講師に特別にインタビューしました。私たちは、可観測性の分野における彼らの研究洞察と実践経験を通じて、大多数の技術実務家が可観測性を正確に理解し、企業が自社の開発に適応した可観測性システムを構築するための提案とインスピレーションを提供できることを願っています。

Q1 監視と観測可能性の関係は何ですか?違いは何ですか?焦点、適用シナリオ、機能、制限などの側面から分析できますか?

クマヒョウ

「何が起こっているのか、そしてなぜなのか」

モニタリングは一般的な運用・保守方法であり、一般的にはシステムの外部リソースの使用状況やインターフェースのパフォーマンスを観察することでシステムの動作状況を推測すること、つまり「何が起こっているか」を感知することを指します。

可観測性とは、システムの現在の動作状態を認識する能力を指す特性です。システムの観察可能な性質を改善すると、「何が起こっているのか」と「なぜこれが起こっているのか」を理解するのに役立ちます。

業界におけるクラウドネイティブ アーキテクチャの段階的な実装により、反復リリースの高速化、ビジネス システムの大規模化、ネットワーク リンクの複雑化、オペレーティング環境の動的化など、安定性の構築に対する新たな課題が増えています。このような混沌としたシステムでは、問題が発生したことを知るだけでは十分ではありません。このような複雑な環境において、私たちが武器を持たずに問題を追跡することは困難です。より立体的でインテリジェントな診断システムを構築するには、階層化された多次元の観測データを活用し、より多様な視点からシステムを観測し、解釈する必要があります。

クアン・リンシュアン

「可観測性は、ビジネス アプリケーション システム自体の要件です」

監視は観測機能の一部であると私は考えています。初期監視は主に、ビジネス アプリケーション システムの外部のプロアクティブな動作に関するものです。従来の監視の主な利用者は、業務プロセスの状態やシステムリソースなどの監視データの分析やアラームによる問題の発見など、運用・保守です。現在、可観測性はビジネス アプリケーション システム自体の要件となっています。より観察可能なアプリケーション ランタイム データを公開し、これらのデータ間の関連付けを確立するには、どのように設計すればよいでしょうか?たとえば、マイクロサービス フレームワークは、リクエスト処理中および RPC 呼び出し中にいくつかの AOP 拡張設計を提供します。これにより、リクエストのメトリック測定とトレース追跡、および異常な状況のコンテキスト関連付けをより便利に実行できます。

ファン・ヨン

「ローカル可用性の視点をグローバルに拡張」

両者の関係: 監視と可観測性はどちらも、可用性の高いサービスの構築と障害処理時間の短縮を支援するために設計されています。両者は密接に連携することが多く、境界は比較的曖昧です。

両者の違い: 監視は、多くの場合、アラームがトリガーされる瞬間的な状態に焦点を当て、一般的にアラーム イベントを中心に展開され、アラーム イベントの生成から緊急対応までの一連のアクションが含まれます。一般的には、CPU 負荷、残りメモリなどの特定の監視項目に注意を払いながら、ローカルの可用性に重点が置かれます。監視は一般的なトピックです。最も一般的なシナリオは、システム リソースの監視と、プロセスまたはサービスのステータスの大まかな監視です。カスタマイズされたビジネス指標の監視にはあまり適していません。さらに、従来の監視システムは、クラウド ネイティブ サポートやマイクロサービス システムの監視にはあまり適していません。

可観測性は、サービスの全体的な可用性に重点を置き、フルリンク分析 (APM)、ビジネス サービス品質 (SLA)、ビジネス キャパシティなど、幅広い側面をカバーする監視の延長として考えることができます。一般的にはグローバルな可用性に重点が置かれ、サービス品質に影響を与えない一部の指標は無視されます。たとえば、CPU 負荷が高く、サービス全体のレイテンシがあまり変動しない場合は、CPU 負荷インジケーターは無視されます。

可観測性のアプリケーション シナリオは、通常、ビジネス機能に結び付けられます。 SLA に影響を与える関連指標 (SLI) は視覚的に集約されて表示され、監視アラームと組み合わせて、可観測性ダッシュボードによるドリルダウン分析によって異常の根本原因が分析されます。さらに、オブザーバビリティがメトリック/トレース/ログを接続すると、サービスの潜在的なリスクをプロアクティブに特定し、ユーザーよりも先に問題を発見できるようになります。

また、ビジネスデータの収集が必要であり、ビジネスに多少の負担がかかることから、可観測性も制限され、視覚化プラットフォームの構築コストも比較的高くなります。さらに、可観測性全体はまだ初期段階にあり、多くのツールチェーンはまだ完璧ではなく、価値の期待値は実際には過大評価されています。

Q2: 監視から可観測性への変更点は何ですか?運用・保守、開発、設計などの職種の人員に対して、どのような新しい要件が提示されますか?

クマヒョウ

「可観測性の概念をアーキテクチャとプログラム設計に統合する必要がある」

目標は異なります。 「何が起こっているのか」を知ることに加えて、「なぜそれが起こっているのか」を説明することも必要です。何かが起こった後や事後に修復するのではなく、可観測性の概念をアーキテクチャとプログラム設計に統合する必要があります。ビジネス指標の相関関係の変化、システム アーキテクチャのデータ ファンネル モデル、プログラム内の論理分岐の動作オーバーヘッド、外部リソース依存関係の健全性状態を観察し、プログラム内のリソースの同時実行性、プールの充填率とヒット率、実行時状態などを公開するためのメカニズムを意識的に設計する必要があります。実行時エラーが発生した場合は、十分なコンテキスト情報がエラー メッセージに含まれていなければなりません。

運用および保守担当者は、観察可能なシナリオに対してより強固なツール基盤を提供し、前述の膨大なデータ圧力下でのデータストレージとクエリのパフォーマンス、リソースのオーバーヘッド、クラスターのスケーラビリティ、安定性などの問題を確実に解決する必要があります。

クアン・リンシュアン

「受動的な監視から能動的な問題の発見と特定への移行」

最大の変化は、アプリケーション システム自体の役割が受動的な監視から能動的な問題の発見と特定へと移行したことだと思います。アプリケーション システム アーキテクチャの設計の初期段階では、システム自体の可観測性を考慮する必要があります。運用、開発、アーキテクトはすべて各リンクの設計に参加しており、コラボレーションの方法にも一定の変更があります。

• 運用と保守: 製品ビジネスとアプリケーション サービスに対する深い理解を持ち、ビジネス指標、アプリケーション サービス指標、システム リソース指標などを定義して関連付けます。
• 開発: フレームワーク層で実行時に分散アプリケーション サービスのメトリック、トレース、およびログ データ収集を設計および実装します。
• アーキテクト: ビジネス アプリケーション システムと可観測性システムの全体的なアーキテクチャ設計では、非侵入的な収集とレポート、多次元の数量集約、エラーの根本分析、全体的な大規模データ処理とストレージなどに重点を置く必要があります。

一般的に、それぞれの役割には、より多くの技術横断的な知識の蓄積、ビジネス思考、およびモデル抽象化能力が必要です。

ファン・ヨン

「責任分担、認知認識、トラブルシューティング効率の変革と向上」

主な変更点は以下の通りだと思います。

• 責任分担の変更により、R&D がサービス品質に重点を置くようになり、一部の責任が運用・保守側から R&D 側に移り始めました。 R&D がオンライン化されると、私たちは率先して不在の上司になることはなくなり、自分たちのサービスに責任を持つようになります。
• 警報に対する受動的な対応からサービス品質の能動的な改善まで、認知認識の向上。
• トラブルシューティングの効率を向上し、元のブラック ボックス トラブルシューティング モードから視覚化へと徐々に移行します。

さまざまな職種の人員に対しても新たな要件があります。

• 運用と保守では、従来の監視の束縛から解放され、クラウドネイティブの監視システムを採用する必要があります。同時に、他の職種の担当者と合意を形成し、共同で高可用性サービスを構築する必要があります。
• 開発部門は、運用と保守の責任の一部を引き継ぎ、サービスの可用性に重点を置き、メトリクス駆動開発 (MDD) アプローチを採用し、回復力の高いサービスを構築する必要があります。
• アーキテクトは、アーキテクチャ設計プロセス中に観測可能な指標を公開し、データ分析機能を向上させ、メトリック/トレース/ログ データをモデル化および分析し、サービスの潜在的なリスクを特定する必要があります。可観測性を中心に、対応するツール チェーンとサービス ガバナンス プラットフォームを構築します。

Q3 可観測性のコアとなる方法論/主要技術は何ですか?

クマヒョウ

「データの収集、保存、分析が主な関心事です」

可観測性構築の中心的な焦点は、依然としてデータの収集、保存、および分析にあります。

データ収集の範囲は、さまざまな角度から見ることができます。端末の開始、ゲートウェイ、ビジネス、インフラストラクチャの各層のコンポーネントをカバーするために、完全なデータ リンクを整理してみることもできます。メトリック、トレース、ログ、例外収集、プロファイラー、デバッガー、変更ログなどのさまざまな観察の観点をカバーでき、その他のデータまたは機能のカテゴリが完全に構築されています。ビジネス ディメンション、リソースのボトルネック、関連コンポーネント、カバレッジのその他のディメンションなど、複数のディメンションからシステムを観察できます。

データ保存段階では、さまざまな種類のデータの保存およびクエリ システムの選択に注意を払う必要があります。最も一般的なストレージ システムは、メトリック、トレース、ログに関連するもので、これらにはすべて、非常に幅広い基本ソフトウェア オプションがあります。比較的扱いにくい問題は、インジケーターのディメンションの急増、ログとトレースのストレージ コスト、パフォーマンス関連の問題であり、これらを解決するには、通常、事前集計、事前サンプリング、事後サンプリング、ストレージ階層化、およびその他の戦略の組み合わせが必要です。

データ分析フェーズでは、さまざまなデータ ソースのメタデータを関連付け、多次元の観点からクエリ インターフェイスを構築する必要があります。同時に、大量の生データの中から目立つ異常なデータをどのように見つけるかにも注意を払う必要があり、そのためには通常、ストリーミング検出機能とクラスター分析機能を構築する必要があります。

クアン・リンシュアン

「データを収集し、関連付けを構築し、モデルを設計する」

可観測性の中心的な考え方: 収集する必要があるデータ、関連付けを確立する方法、モデルを設計する方法。アプリケーション サービスのシナリオを例に挙げてみましょう。

• コレクション: リクエストの量、期間、エラー、容量など、およびスレッド プール、キュー、接続プールなどのリソース インジケーター。
• 関連付け: リクエストの上流および下流のリンクと呼び出しスタックを垂直に関連付け、リクエストとリクエストの処理によって消費されるアプリケーション リソースを水平に関連付けます。
• モデル: データの収集と関連付け、異常の定義と分析、および完全なリンク エラーの根本原因の検出のための統合モデリング設計。

上記は、さまざまなビジネス アプリケーション システムに対して適切な抽象化を行い、より標準化された観測機能を構築するためのガイドとなります。

ファン・ヨン

「MDDコンセプトは指標駆動型開発を提唱する」

一般的に使用される方法論:

1. SLIの選択:

• Google VALET (ボリューム、使用可能、レイテンシ、エラー、チケット) モデルを参照してください。
• Netflix の USE メソッド。USE は、Utilization (使用率)、Saturation (飽和度)、Error (エラー) の略です。
• Weave Cloud の RED メソッド、Request-Rate (1 秒あたりに受信したリクエストの数)/Request-Errors (1 秒あたりに失敗したリクエストの数)/Request-Duration (各リクエストに費やされた時間、時間間隔で表されます)。

2. MDD (メトリクス駆動開発) の概念: MDD では、アプリケーション開発プロセス全体が指標によって駆動され、リアルタイムの指標を使用して高速で正確かつきめ細かいソフトウェアの反復が推進されることを提唱しています。指標駆動開発の概念により、プログラマーは生産状況をリアルタイムで把握し、タイムリーに問題を特定して解決できるだけでなく、製品マネージャーや運用・保守担当者が関連するビジネス指標に注意を払うこともできます。

主な技術:

1. データ収集: Prometheus エコシステムをベースにしている場合は、さまざまなエクスポーターが用意されており、独自の対応するエクスポーターを開発することもできます。ファイルに基づいてログを収集する場合は、Flume、Fluentd などを検討できます。

2. データ分析: ログインジケーターは、Clickhouse SQL 分析に基づいて調整できます。 Prometheus システムであれば、関連する指標を分析するために使用できる豊富な PromQL もあります。トレースとログの分析では、通常、独自に開発した分析エンジンを使用し、それらをメトリックに接続します。

3. データ ストレージ: Prometheus 自体は非常に優れた時系列データベースですが、分散ストレージはサポートしていません。通常、Clickhouse や InfluxDB などのリモート ストレージ エンジンと組み合わせて使用​​されます。トレースとログは通常、Elasticsearch に保存できます。

4. データ表示: データの最終的な表示形式は、視覚化設計計画と一致し、ロールアップ/ドリルダウンをサポートする必要があります。ほとんどの要件は Grafana で提示できます。 Grafana はさまざまなプラグインを提供し、さまざまなデータベース タイプをサポートし、Echarts に基づいて独自に開発することもできます。パブリッククラウドをホストする場合、パブリッククラウド独自のシステムをフル活用できますが、別途料金が必要なものもあります。

Q4 メトリクス、トレース、ログを統合してその価値を最大化するにはどうすればよいですか?

クマヒョウ

「時間範囲に基づく統計関係またはラベルと TraceID の関連付け」

2 つの既知の方法があります。

1. 時間範囲内の統計的関係に基づく: 一般的な使用方法は、メトリックの異常に対応する時間間隔内で異常な動作を示すトレースとログを見つけることです。この方法は、トレースとログのクラスタリング分析機能に依存します。

2. ラベルと TraceID に基づく関連付け: OpenTelemetry Collector の観測可能データ収集フレームワークに基づいて、プラグインとトレース スパンのメタデータ ラベルの形式でアクセス インジケーターを生成し、ログのメタデータにトレース ID を渡すことで、同じトレース ID またはラベル ディメンションに関連付けて表示することができます。さらに、Prometheus は現在、メトリックをトレース ID に関連付けて保存できる典型的な機能を実装しており、これも興味深い設計です。

クアン・リンシュアン

「フルリンクエラールートの発見は、3つを結びつける最大の価値です」

これら 3 つを接続することの最大の価値は、完全なリンク エラーの根本原因特定を実現できることです。つまり、異常なリクエスト メトリックの検出から、メトリック相関分析、レイヤーごとのドリルダウン、詳細なトレース追跡、特定のエラー ログまで、マクロから詳細なエラー検出、根本原因の特定まで、プロセス全体が自動化されます。

Huya は、アプリケーション サービスへの透過的なゼロコスト SDK アクセス、3 つの自動データ収集と関連付け、および Huya の大規模分散システムで完全に実践されているフルリンク エラー ルート検出アルゴリズムを含む、3 つの統合アプリケーション監視モデルを設計しました。全体的な実践的な経験の観点から言えば、究極のビジネス価値は、R&D と運用によるアプリケーション サービスのトラブルシューティングとガバナンスの効率性の向上を支援することにあります。

ファン・ヨン

「接続すると、サービス全体の可用性を3次元かつホログラフィックな方法で分析できるようになります。」

分析は、入力コスト (CapEx)、運用保守コスト (OpEx)、応答性 (Reaction)、問題調査の有効性 (Investigation) の観点から行われます。メトリック、ログ、トレースには次の特性があります。

ログとトレースは通常、trace_id を使用して接続されます。 Trace_id は通常、最後のエントリで生成され、リクエストのライフ サイクル全体にわたって実行されます。業務でログを記録する際に、現在の trace_id を記録して、ログとトレースを関連付けることができます。

タグ モードは通常、メトリックとの接続に使用されます。たとえば、サービス サーバー名によって生成されたメトリックは、Traces 内のサーバー名に関連付けることができます。

接続が確立されると、サービス名の次元に基づいて、サービス全体の可用性を 3 次元かつホログラフィックに分析できます。

Q5 観測ツールの選択方法は？普遍的な基準はあるのでしょうか?

クマヒョウ

「高可用性、拡張性、コスト削減、容易な運用と保守」

私たちは、可観測性ツール システムの次の特性に焦点を当てています。

• 高可用性: 安定性の守護者として、可観測性システム自体には高い信頼性が求められます。
• スケーラビリティ: より大きなデータ量をサポートするために、ストレージ書き込みおよびクエリ機能のスケーラビリティに重点を置いています。
• コストの削減: 観測データは時間の経過とともに徐々に価値を失うため、履歴データは低コストで無効化するか、ストレージ メディアをダウングレードすることが理想的です。
• 操作とメンテナンスが簡単: 一定の自動化機能を備えているか、アーキテクチャが十分にシンプルです。

クアン・リンシュアン

「業界標準に基づいており、拡張が容易ですか？」

Huya は主に OpenTracing 標準に基づいて徹底的な自己研究と拡張を行っています。業界標準を使用することで、十分なオープンソース コードとコミュニティ サポートが得られ、基本的なコード作業を大幅に節約し、独自のビジネス システム特性とモデル設計にさらに集中できるようになります。現在、OpenTelemetry はメトリック、トレース、ログの統一された標準を提供しており、オープンソース コミュニティで非常に人気があります。それは研究と実践に値する方向性です。

可観測性ツールを選択する際に考慮すべき 2 つの側面があります。

1. 業界標準に基づいており、コミュニティとメーカーのサポートが充実しているかどうか。
2. 拡張が容易であり、共通性と個別性を組み合わせやすく、最終的にこれを基に自社のビジネス特性に適合した可観測性システムを構築できるかどうか。

ファン・ヨン

「既存のテクノロジースタックに基づいて選択し、主流に盲目的に従わないでください」

可観測性分析のテクノロジー スタック全体を次の図に示します。

ツールの選択:

• メトリクス: 一般的に使用されるのは、Zabbix、Nagios、Prometheus、および Prometheus-operator や Thanos などの関連する高可用性展開ソリューションです。
• ロギング: ELK Stack、Fluentd、Loki など
• トレース: よく使用されるのは、Jaeger、SkyWalking、Pinpoint、Zipkin、Spring Cloud Sleuth などです。
• 視覚化: Grafana。

実際のところ、技術の選択には特定の基準はありません。各企業は段階によって選択肢が異なる場合があります。あなたに合ったものがベストです。ここにいくつかのヒントがあります:

• コスト予算を管理するには、一般的に、企業は自社の開発段階の実際の状況を考慮する必要があります。フルリンクの可観測性をすぐに統合する必要はありません。おそらく初期段階では、従来の Zabbix だけがニーズを満たすことができます。自分のニーズに基づいて合理的な選択をし、主流に盲目的に従わないでください。
• オープンソースを採用します。初期段階では、通常、すぐに使用できるオープンソース製品を採用し、それを活用します。また、選択する際には周囲の生態系の豊かさも考慮する必要があります。
• チームのテクノロジー スタックの選択に基づいて、ミドルウェア、ビジネス サービス、クラウド ネイティブ、物理マシン監視などの選択は、チームの既存のテクノロジー スタックと一致する必要があります。