Azure 監視とクラウドの観測性の違いは何ですか?

これはAzure監視シリーズの最初のブログです。まずは監視と可観測性の本質的な違い、その重要性、Azure Monitorの欠点、そしてCloudOpsチームがその違いを埋めて、より迅速に行動し、よりスマートにトラブルシューティングを行い、大規模な問題に先手を打つ方法について解説します。さらに詳しく知りたい方は、こちらをご覧ください。 フルシリーズ.

重要なアプリケーションが突然遅くなったと想像してみてください。 Azureの監視 ダッシュボード、CPU使用率、メモリ使用量、ネットワークスループットなど、すべて正常に見えます。しかし、ユーザーからは深刻なレイテンシーの問題が報告されています。これが現代のクラウド運用の現実です。データは氾濫しているものの、真の根本原因を洞察できる情報は限られています。

クラウド環境では毎分数百万ものデータポイントが生成されます。数百ものサービスとメトリクスを備えたマイクロサービスベースのアーキテクチャでは、いわゆるカーディナリティ爆発と呼ばれる現象が急速に発生し、従来の監視ではコストがかさみ、多くの場合、効果を発揮しなくなります。

TL; DR

監視により症状が明らかになります。可観測性によりストーリーが明らかになります。

モニタリングは、何か問題が発生した時に通知します。オブザーバビリティは、メトリクス、イベント、ログ、トレースの完全なコンテキストに基づいて、問題の原因を示します。

Microsoft の Azure Monitor は基本的な機能は処理しますが、複雑な環境、ハイブリッドな環境、または変化の激しい環境では不十分です。

現代の CloudOps チームには、問題をより早く解決し、アラートノイズを減らし、次に何が起こるかを先取りするために、サービスを考慮した可観測性が必要です。

LogicMonitor Envision はこれらすべてを統合し、事後対応型のトラブルシューティングから事前対応型の運用に移行できるようにします。

監視と可観測性の違い

アラートではすべて正常と表示されているのに、ユーザーからアプリケーションのクロールに関する苦情が寄せられるという、イライラした経験はありませんか？これは監視と可観測性の間にあるギャップです。監視は何かが壊れていることを知らせてくれます。可観測性は なぜ。

既知の未知と未知の未知

従来の監視は、監視すべき対象が明確であれば有効に機能します。例えば、CPU使用率の上昇、メモリリーク、ディスク容量の不足などです。しきい値を設定し、トリガーを待ってから対応します。これらは既知の未知数、つまりトリガーが明確な予測可能な問題です。

しかし、今日の環境はルール通りには機能しません。マイクロサービス間の競合状態、断続的なAPIタイムアウト、そしてパターンに当てはまらない連鎖的な障害など、様々な問題が発生します。こうした未知の事象は、そもそもアラートの設定方法を知らなかったため、標準アラートをトリガーしません。

ここで、可観測性が重要になります。可観測性は、サービスとテレメトリ全体の点と点を結び付けて異常を検出し、隠れたパターンを明らかにし、アラートで見逃された問題を表面化させます。

Microsoft Azure Monitor が適している点と適していない点

Azure Monitorは、確かな出発点となります。Azureネイティブのワークロードを実行している場合、メトリック、アラート、ログ、そして一部のトレースといった基本的な機能を提供します。パフォーマンスの追跡、インフラストラクチャの問題の特定、既知の問題に対するアラームの設定に役立ちます。

あなたは：

• メトリクスとアラート: CPUのスパイク、メモリの逼迫、ディスク使用率。確かに効果はありますが、しきい値の調整が必要になることが多く、アラートがうるさくなることがあります。
• ログ分析: すべてのAzureログを1か所に集約し、Kustoクエリ言語（KQL）で検索できます。強力ですが、直感的ではありません。
• 検査に対応 運用を: アプリ用の組み込みリクエスト トレースおよびテレメトリですが、完全な APM ソリューションほどの深みはありません。
• ネットワーク監視: 接続モニターなどのツールは、ユーザーが苦痛を感じる前に遅延やパケット損失を見つけるのに役立ちます。

LogicMonitor Envision の Azure 監視の概要をご覧ください。

さあ行こう→

しかし、問題は、現代のCloudOpsにはそれだけでは不十分だということです。

環境が複雑になると (マルチリージョン、ハイブリッド、マルチクラウド)、Azure Monitor のパフォーマンスが低下し始めます。

1. サービス間の相関関係が限られている

Azure Monitor では何が起こったかは表示されますが、それがどのように関連しているかは表示されません。多くの場合、ダッシュボード間を行き来し、複数のサービスにわたるログとメトリックを手動でつなぎ合わせて根本原因を突き止めることになります。

たとえば、データベースの遅延によりAPI応答が遅くなり、フロントエンドのレイテンシが急増します。Azure MonitorはCPU負荷に関するアラートを通知しますが、データベース層まで問題を遡って追跡することはできません。

2. 表面レベルの異常検出

Azure Monitor の異常検出機能をご利用の場合、動的なしきい値やスマートな検出機能が利用できることにお気づきでしょう。ただし、これらの機能は適用範囲が限定されており、多くの場合、手動での設定や KQL の深い専門知識が必要になります。メトリック、ログ、インフラストラクチャ テレメトリ全体のパターンを自動認識するといった、より高度な機能は組み込まれていません。つまり、早期の警告サインを見逃してしまう可能性が高くなります。

3. ハイブリッドクラウドとマルチクラウドの可視性が限られている

Azure Monitor は主に Azure ネイティブのワークロード向けに設計されています。マルチクラウド アーキテクチャやオンプレミス システムを実行している場合は、統合の課題に直面することになります。

たとえば、 ある小売企業は、Azure、AWS、オンプレミスのデータセンターを横断的に運用しています。複数の環境を異なるダッシュボードや連携機能で監視していると、状況を明確に把握することが困難です。エンジニアは統一されたビューを利用できないため、作業が困難になり、時間の浪費につながっています。

4. スケールしないトレース

Application Insightsはリクエストのトレースに役立ちますが、すべてのサービスが適切にインストルメント化されている場合に限ります。一時的なサービスや頻繁な変更を伴う動的な環境では、トレースデータにギャップが生じることが常態化します。

CloudOpsチームに監視以上のものが必要な理由

監視は個々の症状を示します。可観測性は全体像を示します。この違いは、大規模な分散サービスを運用する場合、特に稼働時間、顧客体験、そしてコストが重要になる場合には重要です。

だからこそ、多くのチームがAzure MonitorからLogicMonitor Envisionのようなプラットフォームに移行しつつあります。監視を置き換えるのではなく、監視を拡張するのです。サービス間でMELTシグナルを相関させ、根本原因をより迅速に特定し、アラートだけでなくコンテキストに基づいてよりスマートな意思決定を行うためです。

結局のところ、可観測性とは単に問題をより早く解決することだけではありません。ビジネスを支えるサービスのネットワークという、環境の真の姿を把握することです。

Azure Monitor を超えて: 可観測性が新たな基準となる理由

クラウド環境は静止したままではいられません。サービスは日々拡張され、トラフィックは急増し、新規導入は減少します。ユーザーが既に苦痛を感じている状態になってから、アラートが発報されたりダッシュボードが点灯したりするのを待つ余裕はありません。

可観測性は、そのような事態が発生する前に行動するためのコンテキストを提供します。これにより、次のようなことが可能になります。

• パフォーマンスデータと現実世界への影響を結び付ける
• 相関性のあるマルチソーステレメトリで根本原因をより早く特定
• CPU グラフだけでなく、サービスの健全性に基づいて重要なものを優先します
  

ハイブリッドクラウドやマルチクラウド環境で運用している場合、可観測性は単なるおまけではありません。チームを疲弊させることなく、常に最前線に立つための手段なのです。

だからこそ、多くのCloudOpsチームがLogicMonitor Envisionのようなプラットフォームを活用しています。インフラストラクチャの監視だけでなく、サービスの理解にも役立ちます。リアクティブからプロアクティブへ、断片的なシグナルから完全なコンテキストに基づくインサイトへとシフトしていくのです。

Azure監視シリーズの次のブログでは、 5つの最大の課題 Azure の拡張時に発生する問題と、それが収益に影響を及ぼす前に解決する方法について説明します。