LogicMonitor は、800 億ドルの評価額で 2.4 億ドルの戦略的投資を行い、データ センターに革命を起こすことで AI 環境を破壊しようとしています。

もっと詳しく知る

ベストプラクティス

監視と可観測性: 違いは何ですか?

監視は可観測性の重要な機能の 1 つですが、可観測性には、チームが事後的な問題解決から事前の運用に移行できるようにする追加のコンポーネントがあります。

監視と O11y 両方が必要な理由

監視はかつて、IT の健全性に関する直接的な洞察を提供していました。つまり、データを収集し、監視する指標を特定し、問題が発生すると診断していました。しかし、IT インフラストラクチャがクラウド、コンテナ化、分散アーキテクチャとともに進化するにつれ、従来の監視では対応が難しくなる可能性があります。可視性を高めるだけでなく、問題をプロアクティブに検出してトラブルシューティングできるようにする方法論である可観測性の登場です。

可観測性は単なる流行語なのでしょうか、それとも IT 運用の根本的な変化を表しているのでしょうか。この記事では、監視と可観測性の違い、それらの補完的な役割、そして可観測性が今日の IT チームにとって不可欠である理由について説明します。

このブログでは、以下について説明します。 

主要な取り組み

チェックマーク
監視は既知の問題を追跡してアラートを提供し、可観測性は出力を分析して問題が発生する理由を理解します。
チェックマーク
監視、ログ分析、機械学習を組み合わせたオブザーバビリティにより、問題が深刻化する前にプロアクティブに検出して防止します。
チェックマーク
モニタリングは特定の指標に焦点を当てた反応的なものであるのに対し、可観測性はデータを実用的な洞察に変えて全体的な視点を提供する。
チェックマーク
監視と観測性を組み合わせることで、システムの回復力、運用効率、プロアクティブなトラブルシューティングが向上します。

監視とは

監視とは、IT システムからデータを体系的に収集して分析し、パフォーマンスの問題や障害を検出して警告する手法です。従来の監視ツールは、CPU 使用率やメモリ使用量などの既知のメトリックに依存しており、しきい値を超えたときに警告を生成することがよくあります。このデータは通常、時系列メトリックの形式で提供され、事前定義されたパラメータに基づいてシステムの健全性のスナップショットを提供します。

監視の主な特徴:

  • 成熟した反応: 監視によってアラートがトリガーされるのは、多くの場合、問題がすでにユーザーに影響を与えた後です。
  • しきい値ベースのアラート: メトリックが指定された制限を超えた場合 (例: メモリ使用量が多い場合) に通知が生成されます。
  • 主な目標: 既知の問題を検出して警告し、迅速な対応を可能にします。

監視の例としては、CPU 使用率アラートが挙げられます。このアラートは、サーバーに負荷がかかっていることを通知しますが、追加のコンテキストがなければ、複雑なインフラストラクチャ内の他の場所にある可能性のある根本原因を特定することはできません。

可観測性とは何ですか?

可観測性 監視の枠を超え、データ分析、機械学習、高度なログ記録を組み合わせて複雑なシステムの動作を把握します。可観測性は、ログ、メトリック、トレースの 3 つの中核となる柱に依存してシステム パフォーマンスの総合的なビューを提供し、チームが未知の問題を特定し、パフォーマンスを最適化し、将来の中断を防ぐことを可能にします。 

可観測性の主な特徴:

  • 積極的な取り組み: 可観測性により、チームはユーザーに影響を与える前に問題を予測して防止できます。
  • 統合データ収集: ログ、メトリック、トレースを組み合わせることで、システムの動作に関する詳細な分析情報が得られます。
  • 根本原因分析: 可観測性ツールは機械学習を活用してデータを相関させ、症状だけでなく原因を特定するのに役立ちます。

可観測性の例: マイクロサービス アーキテクチャでは、応答時間が遅くなると、問題が数層の深い依存関係から発生した場合でも、可観測性によって問題の原因となっているマイクロサービスを正確に特定できます。 

O11y は、observability の略語で、「observability」の「O」と「Y」の間にある 11 文字を削除したものです。これは、Kubernetes が一般に K8s と呼ばれるのと似ています。

可観測性の意味をより深く理解するには、以下の記事をご覧ください。 O11y とは何ですか? 可観測性について説明します。 

監視と可観測性の主な違い

監視と可観測性は互いに補完し合いますが、その目的は異なります。監視は既知のイベントを追跡してシステムが定義済みの標準を満たしていることを確認しますが、可観測性は出力を分析してシステムの健全性を推測し、未知の問題に事前に対処します。

側面監視可観測性
目的 既知の問題を検出する未知の問題と根本原因についての洞察を得る
データフォーカス時系列メトリックログ、メトリクス、トレース
アプローチ反応性先を見越した
問題の範囲症状を特定する診断原因
ユースケースの例CPU使用率が高い場合の警告マイクロサービス全体で遅いリクエストをトレースする

監視 vs. 可観測性 vs. テレメトリ vs. APM

監視と可観測性は互換性のある用語ではありませんが、共通の目標を達成するために連携して機能します。監視は、システムとサービスの状態をアクティブに追跡できるため、可観測性ワークフローの重要な側面です。ただし、監視だけでは、可観測性が提供する完全な画像を提供することはできません。

可観測性には監視とテレメトリの両方が含まれており、これらのコンポーネントを利用してデータを収集し、それを分析してシステムの動作に関する洞察を得ます。 テレメトリー 分析プロセスに供給される生データを提供する一方で、監視によってこのデータが継続的に収集され、システムの変更や問題について常に情報が得られるようになります。テレメトリと監視がなければ、観測可能性は存在できません。

アプリケーションパフォーマンス監視 (APM) ツール 開発者と運用チームにアプリケーションのパフォーマンスに関するリアルタイムの洞察を提供し、問題を迅速に特定してトラブルシューティングできるようにします。従来の監視とは異なり、APM はアプリケーション コードと依存関係をより深く可視化します。

可観測性は監視の単なる拡張ではなく、問題が発生する前にチームが解決できるようにするプロアクティブな変化です。

監視と観測可能性がどのように連携するか

監視と可観測性は相互に補完し合う力であり、これらを併用することで、IT システムの管理と最適化のための完全なエコシステムを構築できます。ここでは、これら 2 つの機能が実際のシナリオでどのように相互作用してシステムの健全性を維持し、対応能力を強化するかを段階的に説明します。

監視は既知の指標を追跡することで基礎を築く

監視は、可観測性の基盤となる重要なベースライン データを提供します。既知のメトリックを継続的に追跡することで、予想されるパフォーマンスからの逸脱についてチームに警告が送信されます。

  • : 監視ツールは、CPU 使用率、メモリ消費量、応答時間などの主要な指標を追跡します。これらの指標のいずれかが設定されたしきい値を超えると、アラートが生成されます。これは、何か問題がある可能性があることを IT チームに伝える最初のシグナルとして機能します。

可観測性により、コンテキストの深さで監視アラートを強化

監視によってアラートが生成されると、オブザーバビリティ ツールが介入して必要なコンテキストを提供します。単にしきい値を超えたことを報告するのではなく、オブザーバビリティはログ、トレース、および複数のデータ ソース間の相関関係を使用してインシデントの詳細を掘り下げ、アラートが発生した理由を明らかにします。

  • : 特定のサービスで応答時間が長いために監視によってアラートがトリガーされた場合、可観測性トレースにより、要因となっている可能性のある他のサービスとの依存関係や相互作用が明らかになることがあります。これらの依存関係を分析すると、遅延の原因がデータベースのボトルネック、ネットワークの輻輳、または別の基盤サービスにあるかどうかを特定するのに役立ちます。

監視レイヤーと観測レイヤー間でデータを相関させ、トラブルシューティングを迅速化

監視データは不可欠ですが、複雑なマルチサービスの問題のトラブルシューティングに必要な詳細で相関性のある洞察が欠けていることがよくあります。可観測性は、アプリケーション ログ、ユーザー トランザクション、インフラストラクチャ メトリックなど、さまざまなレイヤーからのデータを統合して、イベントを相関させ、根本原因をより迅速に特定します。

  • : 電子商取引アプリケーションでチェックアウトの失敗が急増したとします。監視ではエラー アラートでこれをフラグ付けしますが、可観測性により、チームはエラーを最近のデプロイメント、構成の変更、またはチェックアウト プロセスに関係する特定のマイクロサービスと相関させることができます。この相関関係により、たとえば、問題が特定のデプロイメントの直後に始まったことがわかり、チームはそのリリースの潜在的なバグに集中できるようになります。

機械学習はアラートの精度を高め、ノイズを削減します

監視により多数のアラートが生成されますが、その中には重要ではないものや誤検知のものもあります。可観測性プラットフォーム、特に機械学習 (ML) を備えたプラットフォームは、履歴データを分析してアラートの品質を向上させ、しきい値を動的に調整して真の異常を特定することでノイズを抑制します。

  • : 監視によって CPU 使用率の一時的な急増が検出された場合、可観測性プラットフォーム内の ML は、過去の動作に基づいてそれを予想される一時的な増加として認識し、アラートを抑制します。逆に、異常なパターン (サービス間で CPU 使用率が持続しているなど) が特定された場合は、問題をエスカレーションします。このフィルタリングにより、ノイズが削減され、重要なアラートのみが IT チームに届くようになります。

可観測性により監視のプロアクティブな機能が強化される

監視は本質的にリアクティブ(しきい値を超えたときに警告する)ですが、可観測性は、将来的に問題を引き起こす可能性のあるパターンと傾向を特定することで、プロアクティブな姿勢をとります。予測分析機能を備えた可観測性プラットフォームは、監視データを使用して、問題が完全に顕在化する前に予測します。

  • : 可観測性は、メモリ使用量の傾向に関する監視データを分析することで、特定のサーバーのリソース枯渇を予測できます。時間の経過と共にメモリ使用量が着実に増加していることが検出されると、サーバーが最大容量に達する前にチームに警告を発し、予防措置を講じることができます。

統合ダッシュボードは監視アラートと観測可能性の洞察を組み合わせた

効果的なインシデント対応には、多くの場合、統合ダッシュボードを通じて、リアルタイムの監視アラートと詳細な観測可能性の洞察の両方を可視化する必要があります。これらのデータ ポイントを一元化することで、IT チームは信頼できる単一の情報源を手に入れ、より迅速かつ調整された対応が可能になります。

  • : 単一のダッシュボードで、監視データによってサービス停止がフラグ付けされ、可観測性分析によって、影響を受けるサービス全体の詳細なログ、トレース、メトリックが提供されます。この統合ビューにより、チームはシステム全体にわたる停止の影響を調査でき、診断と対応にかかる時間を短縮できます。

継続的な改善のための監視と観測可能性の間のフィードバックループ

可観測性によって新たな障害モードや根本原因が明らかになると、これらの洞察によって監視構成が改良され、継続的なフィードバック ループが作成されます。可観測性に基づく洞察によって新しい監視ルールとしきい値が作成され、将来のインシデントがより正確かつ早期に検出されるようになります。

  • : トラブルシューティング中に、特定のログ イベント パターンがメモリ リークの兆候を示していることが観測によって明らかになる場合があります。これらのログ パターンに基づいて新しい監視アラートを設定すると、メモリ リークが重大になる前にチームにプロアクティブに警告し、回復力を高めることができます。

監視と観測の相乗効果の主な成果

監視と観測可能性により、システムの健全性に対する包括的なアプローチが提供され、次のような効果が得られます。

  • より迅速な問題解決: 監視により、IT チームに問題が即座に警告され、可観測性によりコンテキストと相関関係が提供され、根本原因の分析が加速されます。
  • 回復力の強化: 可観測性に基づく洞察により監視ルールが洗練され、より正確でプロアクティブなアラートが生成され、複雑性が増してもシステムの安定性が維持されます。
  • 運用効率: 統合ダッシュボードによりワークフローが合理化され、チームは効率的に対応し、平均解決時間 (MTTR) を短縮し、サービスの中断を最小限に抑えることができます。

つまり、監視と可観測性は、事後的なトラブルシューティングと事前の最適化の両方をサポートする強力な相乗効果を生み出し、IT チームが潜在的な問題に先手を打つと同時に、高いレベルのシステム パフォーマンスと信頼性を維持できるようにします。

監視から可観測性への移行手順

従来の監視から完全な可観測性戦略に移行するには、新しいツールだけでなく、考え方や実践の転換も必要です。チームがシームレスで効果的な移行を実現できるように、ステップバイステップのガイドをご紹介します。

1. 包括的な監視基盤の構築から始める

監視は、可観測性が洞察を提供するために必要な重要なデータ基盤を提供します。安定した監視がなければ、可観測性はその潜在能力を最大限に発揮できません。

オンプレミス、クラウド、ハイブリッドなど、すべての環境をカバーする集中監視を設定します。すべてのシステムとアプリケーションにわたって、CPU、メモリ、ディスク使用量、ネットワーク遅延などの重要なメトリックがすべてカバーされるようにします。ハイブリッド環境では、仮想資産と物理資産の両方を含むさまざまなデータ ソースを処理できる監視ツールを使用することが特に重要です。

プロヒント:
詳細なアラートしきい値の設定と誤検知の抑制に時間をかけて、アラート疲労を最小限に抑えます。初期の監視精度によりノイズが削減され、観測可能性を構築するための強固な基盤が構築されます。

2. ログ集約を活用して詳細な可視性を獲得する

可観測性は、サービス全体で何が起こっているかを詳細に把握することに依存しており、この目的にはログが不可欠です。集約されたログにより、チームはシステム間でパターンを相関させることができるため、根本原因をより迅速に特定できます。

さまざまなソースからの大量のログ データを処理できるログ集約ソリューションを選択します。このソリューションは、リアルタイムのインデックス作成をサポートし、柔軟なクエリを実行できる必要があります。手動でログを解析しなくても実用的な洞察が得られるように、構造化ログと非構造化ログの処理を提供するツールを探してください。

プロヒント:
複雑な環境では、すべてを無差別にログに記録すると、すぐに膨大な量のデータになってしまいます。動的なログレベルを実装し、問題が疑われる場合にのみ一時的に詳細をログに記録し、システムが安定したらレベルを下げます。これにより、ログ データを管理しやすくしながら、必要に応じて詳細な調査をサポートできます。

3. トレースを追加してメトリックとログを接続し、全体像を把握する

分散環境では、トレースによってサービス間の点がつながり、依存関係と因果関係を特定して理解するのに役立ちます。トレースによってリクエストの経路が表示され、マイクロサービスとサードパーティの統合全体の遅延とボトルネックが明らかになります。

多くの可観測性プラットフォームと統合され、幅広くサポートされている OpenTelemetry など、既存のアーキテクチャと互換性のあるトレース フレームワークを採用します。トレースを構成して、サービス全体のリクエストを追跡し、各段階でのレイテンシ、エラー率、処理時間に関するデータをキャプチャします。

プロヒント:
まず、チェックアウト フローや主要な API リクエストなどの重要なユーザー ジャーニーをトレースすることから始めます。これらのフローは、ビジネス メトリックや顧客満足度と直接相関していることが多いため、関係者に可観測性の価値を示すことが容易になります。自信がついたら、トレース範囲を追加のサービスに拡張します。

4. 異常検出を強化するために機械学習とAIOpsを導入する

従来の監視は静的なしきい値に依存しているため、インシデントの見逃しやアラート疲れにつながる可能性があります。可観測性ツールの機械学習 (ML) はこれらのしきい値を動的に調整し、静的なルールでは見逃される可能性のある異常を特定します。

を展開する AIOps(IT運用のための人工知能)プラットフォーム ML を使用して、ログ、メトリック、トレースのパターンを検出します。これらのシステムは履歴データを継続的に分析し、新たな問題を示す逸脱を簡単に見つけられるようにします。

プロヒント:
ML は強力ですが、万能のソリューションではありません。まず、履歴データに基づいて正常パターンと異常パターンを識別することで、教師あり学習を使用して AIOps プラットフォームを調整します。これらの洞察を使用して、特定の環境に適した ML モデルをカスタマイズします。時間の経過とともに、システムは季節性や負荷の変化に対応できるように適応し、異常検出の精度が向上します。

5. 統合された監視と観測性のための単一の画面を確立する

複数のダッシュボードを管理するのは非効率であり、インシデントへの対応時間が長くなります。単一のダッシュボードに監視データと観測データが統合されるため、問題を総合的かつリアルタイムで特定しやすくなります。

さまざまなシステム、クラウド プロバイダー、アプリケーションからのテレメトリ (ログ、メトリック、トレース) を統合する統合型可観測性プラットフォームを選択します。理想的には、このプラットフォームはリアルタイム分析と履歴データのレビューの両方をサポートし、チームが過去のインシデントを詳細に調査できるようにする必要があります。

Protip:
実際には、単一ペインのダッシュボードをさまざまな役割に合わせてカスタマイズすることを目指します。たとえば、SRE に詳細なトレースとログの可視性を提供し、経営陣にはシステムの健全性に関するエグゼクティブ サマリーを提供します。これにより、運用効率が向上するだけでなく、あらゆるレベルの関係者が可観測性の価値を実際に確認できるようになります。

6. 自動化されたワークフローでインシデント対応を最適化する

可観測性は、応答時間を短縮し、より迅速な解決を促進する場合にのみ価値があります。自動化されたワークフローは、可観測性の洞察をインシデント対応プロセスと統合し、適切な人に関連性のあるコンテキスト化されたデータが通知されるようにします。

観測ツールが異常や重大なインシデントを検出したときに自動的にトリガーされるインシデント対応ワークフローを構成します。これらのワークフローを Slack、Teams、PagerDuty などのコラボレーション プラットフォームと統合して、関連するチームに即座に通知します。

Protip:
時間をかけてインテリジェントなインシデント トリアージを設定してください。さまざまな種類のインシデントを、それぞれ独自のプロトコルを持つ専門チーム (ネットワーク、アプリケーション、データベースなど) にルーティングします。この専門化により、インシデント処理がより効率的になり、チーム間の引き継ぎによって発生する可能性のある遅延を防ぐことができます。

7. フィードバックループを作成し、観測性に関する洞察を活用して監視を改善する

観測可能性により、繰り返し発生する問題や潜在的なリスクが明らかになり、監視の改善に役立ちます。観測可能性データに基づいて監視を継続的に改善することで、IT チームは問題をより適切に予測し、システムの信頼性と回復力を高めることができます。

定期的に可観測性の分析情報を確認して、新しいパターンや潜在的な障害点を特定します。最近のインシデントの可観測性データを分析し、学んだ教訓に基づいて監視構成を調整する定期的な振り返りを設定します。

プロヒント:
正式なフィードバック ループを確立し、観測エンジニアと監視管理者が毎月協力して洞察を確認し、監視ルールを改良します。観測性により、これまで不明だったしきい値を特定し、監視ツールでそのしきい値をプロアクティブに追跡して、将来のインシデントを削減できます。

8. 可観測性がビジネス成果に与える影響を伝える

可観測性の具体的な価値を実証することは、利害関係者の支持を維持し、継続的な投資を確保するために不可欠です。

MTTR、インシデント頻度、システム稼働時間などの主要業績評価指標 (KPI) を追跡し、これらの指標を可観測性の取り組みと相関させます。これらの結果を関係者と共有して、可観測性によって運用コストが削減され、ユーザー エクスペリエンスが向上し、収益が増加する仕組みを強調します。

プロヒント:
可観測性の技術的な指標をビジネス用語に翻訳することは非常に重要です。たとえば、可観測性が停止の防止に役立った場合、システムの 1 時間あたりのダウンタイム コストに基づいて節約できる潜在的な収益を定量化します。可観測性を収益指標にリンクすることで、IT を超えた価値が強化されます。

可観測性と監視の力を活用する

可観測性は監視の単なる延長ではなく、IT チームの運営方法の根本的な変化です。監視は既知の問題を追跡し、可視性を提供するために不可欠ですが、可観測性はシステム診断に対するより深くプロアクティブなアプローチを提供し、チームがダウンタイムを最小限に抑えながら革新できるようにします。

可観測性のメリットを最大限に実現するには、監視ツールと可観測性ツールの両方を統合した総合的なアプローチに統合することが重要です。そうすることで、企業はシステムが常に進化するデジタル環境において、運用可能であるだけでなく、回復力と適応性も確保できるようになります。

著者
ソフィア・バートン
LogicMonitor シニア コンテンツ マーケティング マネージャー
免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。

私たちのブログを購読する

このような記事をあなたの受信箱に直接お届けします