お問い合わせ

コミュニティに参加

WeChat でスキャン
公式コミュニティグループに参加

Guance を体験

オンラインで従量課金のクラウドサービスを開始できます。

無料で始める

Guance エディションを選択

コードリポジトリ

Full-stack Monitoring

フルリンクモニタリングプラットフォームと観測可能性プラットフォームの違いは何ですか?

フルリンク監視は通常、単一のリクエスト、トランザクション、アクセス体験から始まり、リンクが完了しているか、どこで速度が落ちるか、どの依存関係エラーが発生するかに焦点を当てています。この基盤に基づき、この観測可能性プラットフォームはメトリクス、ログ、リンク、RUM、Kubernetes、クラウドリソース、アラート、ビジネスデータを相関し続け、例外の原因、影響範囲、アクションの処理をチームが説明するのを支援します。

Direct Answer

フルリンク監視は「リンクは見えるか?」を解決し、観測可能性プラットフォームは「異常の解釈方法」を解決します。

フルチェーンモニタリングは、アプリ、Web、APIゲートウェイ、マイクロサービス、データベース、メッセージキュー、サードパーティの依存関係を連携させることにより重点を置き、チームがリクエストがどこで処理され、どこに時間が費やされ、どこでエラーが発生するかを把握できるようにします。

このオブザーバビリティプラットフォームはリクエストチェーンだけでなく、ログ、メトリクス、Kubernetesイベント、クラウドリソース、リリース変更、RUM体験、ビジネスメトリクスとトレースを同じ文脈に配置し、R&D、SRE、オペレーション、ビジネスチームが同じ証拠に関する課題に対処できるようにします。

Compare

フルリンクモニタリング、APM、観測可能性プラットフォームをどう区別しますか?

コンセプト 主な焦点 典型的な問題
フルリンク監視 単一のリクエスト、トランザクション、またはアクセスパスの連続的なビュー インターフェースが遅いのか、呼び出しが失敗したときにどの依存関係が失敗するのか、リンクが切れているのか
APM アプリケーションサービス、トレース、エラー、遅いリクエスト、プロファイリング、サービストポロジー なぜJavaサービスは遅くなり、データベース呼び出しはインターフェースを遅くし、リリース後のエラーは増えるのでしょうか?
観測可能性プラットフォーム メトリクス、ログ、リンク、RUM、Kubernetes、クラウドリソース、アラート、ビジネスデータの統一された関連付け どのサービスやユーザーが例外の影響を受けるのか、根本原因の証拠はどこにあるのか、そして誰がそれを担当すべきか

Scenarios

どのシナリオでフルリンク監視から観測性プラットフォームへのアップグレードが必要ですか?

リンクは見られますが、リソースやログは手動で確認する必要があります

トレースを見るとサービスに時間がかかっていることがわかりますが、チームは依然としてELK、Prometheus、クラウドコンソール、Kubernetesコンソールを使ってログ、メトリクス、イベントを蓄積しなければなりません。

通話の連鎖は正常ですが、ユーザー体験は依然として低下しています

バックエンドリンクに明らかなエラーがない場合、フロントエンドはページの読み込み遅延、JSエラー、リソースの障害、ローカルアクセス異常が発生し、RUMの解析、APM、ログ、ダイヤルテストが必要となります。

アラートは複数のシステムに向けられており、責任の境界が曖昧です

APIゲートウェイ、アプリケーション、データベース、メッセージキュー、Kubernetesが同時にアラートを発する場合、優先度を決めるためにタイムライン、オブジェクト関係、チームタグを統一する必要があります。

ビジネスへの影響を定量化する必要があります

遅延リクエストやインターフェースエラーがログイン、注文、支払い、決済、コア顧客に影響を与えるかどうかは、技術的なシグナルとビジネス指標を同じ視点で捉える必要があります。

Workflow

故障とは、観測可能性プラットフォーム内のトラブルシューティング経路のことです

  1. 現象から始めて

    エントリーポイントには、アラート、遅いインターフェース、ページ体験の低下、異常なビジネス指標、顧客からのフィードバックなどがあり、どのツールを最初に開くかを推測するのではなく、

  2. 関連性と文脈

    トレース沿いのサービス、依存関係、データベース、メッセージキューを表示し、ログ、リソースメトリクス、ポッドイベント、バージョン、リージョンを相関させます。

  3. 影響と責任の評価

    RUM、ビジネス指標、アラートイベント、チームタグを組み合わせることで、影響の範囲を評価し、対応するチームに対応するアクションを割り当ててレビューと保持を行います。

FAQ

よくある質問

フルリンクの監視プラットフォームと観測可能性プラットフォームは同じ概念なのでしょうか?

いいえ。フルチェーン監視は、リクエスト、トランザクション、アクセスパスの継続的なビューに重点を置いています。観測可能性プラットフォームは、異常の原因と影響を説明するために、相関した指標、ログ、リンク、RUM、Kubernetes、クラウドリソース、アラート、ビジネス指標も必要です。

フルリンク監視はAPMと同等ですか?

APMはフルリンク監視の重要な構成要素であり、アプリケーションサービス、トレース、エラー、遅い要求、サービストポロジーに焦点を当てています。 完全なフルチェーントラブルシューティングには、ログ、メトリクス、フロントエンドの経験、クラウドリソース、ビジネスコンテキストも必要です。

リンクトレーシングツールがあっても、まだ観測可能性プラットフォームは必要ですか?

チームがトレースのみを表示する必要がある場合は、リンクトレースツールが利用可能です。トレースをログ、メトリクス、Kubernetesイベント、リリース変更、アラート、ビジネスインパクトと関連付けたい場合は、観測可能性プラットフォームが必要です。

フルリンク監視プラットフォームと統一監視プラットフォームはどのように分けるべきでしょうか?

フルリンク監視プラットフォームはリクエスト、トランザクション、アクセスパスに重点を置く一方、統合監視プラットフォームは複数の監視データの集中管理に重点を置きます。可観測性プラットフォームは両者を同じ文脈に置き、根本原因、影響範囲、対応責任を引き続き説明する必要があります。

どのシステムがフルリンク監視に適したのでしょうか?

ログイン、注文、支払い、コアAPI、アプリ/ウェブアクセスパス、APIゲートウェイ、データベース、キャッシュ、メッセージキュー、主要なサードパーティ依存関係から始め、高頻度障害や高付加価値ビジネスチェーンのカバーを優先することが推奨されます。