現代のDevOpsでは、オブザーバビリティとモニタリングという2つの用語がよく取り上げられ、同じ意味で使用されることもあります。多くの場合、これらは似たような概念で、境界線があいまいであるように見えるかもしれません。ただし、この2つには明確な違いがあります。

モニタリングとは、エンジニアリングチームや運用チームがシステムの現状をモニタリングして把握するために行う作業を指します。これは、事前定義されたメトリックの収集に依存しており、コンピューティング自体と同じくらい長い歴史があります。

オブザーバビリティは、はるかに新しい概念です。定義するのは少し難しいですが、明確な目標が関連付けられています。これは、単なる空虚なDevOpsの流行語ではありません。

この記事では、この2つの用語の意味と、相互の関連について説明します。また、オブザーバビリティとモニタリングの実装に利用できるいくつかのツールについても詳しく見ていきます。

まず、モニタリングの定義を深く掘り下げることから始めましょう。

モニタリングとは

モニタリングの目的は、効果的なコミュニケーションを促進することです。現代のITでは、モニタリングは、観察可能なシステムがどの程度うまく機能しているかをDevOpsチームやサイト信頼性エンジニアリング (SRE) チームに伝えます。

モニタリングプロセスを実装する前に、モニタリングするメトリックを定義する必要があります。その後、事前定義された一連のメトリック（および場合によってはログ）を関連するモニタリング対象システムから収集できます。次に、データを集約し、傾向を特定して明らかにし、中断、問題、またはその他のエラーを指摘する必要があります。

どのような問題がモニタリングツールからの警告の原因となる可能性があるでしょうか。複数の可能性がありますが、次に例をいくつか示します。

• ネットワークレイテンシー
• アプリケーションの対応時間が遅い
• I/Oパフォーマンスの低下
• データベース操作の失敗

最新のWebアプリケーションでは、合成モニタリングとリアルユーザーモニタリング (RUM) の2種類のモニタリングが使用されます。合成モニタリングは一般的に短期的な傾向をモニタリングするために使用され、RUMは長期的な傾向をモニタリングするのに適しています。合成モニタリングでは、自動化ツールを使用してシステムの機能を測定します。例えば、サンプル値を使用して、Webアプリケーションが期待どおりに動作しているかどうかを判断します。RUMでは、ユーザーとアプリケーションの実際のインタラクションを記録し、アプリケーションが期待どおりに動作または機能しているかどうかを確認します。

モニタリングは新しい手法や概念ではありません。パーソナルコンピューティング時代の幕開けまでさかのぼり、常に現代のコンピューティング環境の一部となってきました。モニタリングの初期の例としては、Norton Disk Doctorがあります。このプログラムは、PCのディスクドライブをスキャンし、見つかった問題を報告します。

今日のDevOps環境では、SREチームはモニタリングを使用して、個々のサーバー、ネットワーク、データストレージの全体的な正常性を確認します。モニタリングは、環境の全体的なオブザーバビリティ目標のサブセットとして機能します。

オブザーバビリティとは

ウィキペディアによると、「オブザーバビリティとは、システムの外部出力に関する知識から、システムの内部状態をどれだけうまく推測できるかを示す尺度である」とのことです。

患者がしつこい痛みを経験した後に定期的な医療を受けるという観点から考えてみてください。ITの観点から見ると、オブザーバビリティの目標は、システムが内部でどのように機能しているかを知るための手がかりとなる（症状のような）外部出力を分析することです。オブザーバビリティは、影響を調査し、それを特定の原因に関連付けます。

オブザーバビリティがITの世界でこれほど注目される概念になったのはなぜでしょうか。2005年以降、クラウドコンピューティングと分散アプリケーションの使用が爆発的に普及しました。VMの1つのクラスターをモニタリングするだけで済む時代は終わりました。現代のITの世界では、アプリケーションはコンテナやマイクロサービスを使用して、複数のクラウドにまたがる可能性があります。これらのサービスは、分散型と多層型の両方があります。

これが、単純なモニタリングとオブザーバビリティの必要性の主な違いです。多層環境を実現するには、インフラストラクチャ全体を包括的に把握する必要がありますが、これはオブザーバビリティだけが提供できる視点です。

オブザーバビリティの目的は、個々のシステムモニタリングが提供できる以上のインフラストラクチャの包括的な視点を提供することです。これは、特に分散した複雑なシステムにおいて、問題の根本原因をより確実に特定するのに役立ちます。

観察可能なシステムの外部出力には、メトリック、イベント、トレース、ログが含まれます。DevOpsエンジニアがオブザーバビリティを活用する方法の例としては、次のようなものがあります。

• セキュリティ異常検知
• クラウドリソースのコスト分析
• 特定の入力値がプログラムの障害にどのように影響しているかを判断するためのコールトレース分析
• システム負荷の季節的な急増を特定し、それを最適でないロードバランサーに結び付ける

ほとんどのオブザーバビリティプラットフォームは、ユーザーが問題の根本原因を簡単に特定するために必要な詳細情報を提供します。問題の修正方法を提案できるものもあります。いくつかのプラットフォームは、それ自体が是正措置を実行することにより、さらに一歩進んでいます。

オブザーバビリティとモニタリングが似ているように見える理由

では、何がオブザーバビリティとモニタリングの混同につながるのでしょうか。1つは、用語自体が似ており、最終目標が似ていることです。どちらもシステムの信頼性を向上させ、問題の原因を特定して全体的なパフォーマンスを向上させることを目的としています。

また、どちらも同じデータに依存しています。観察可能なシステムとモニタリング対象システムのどちらを作成する場合も、最初に適切な出力をキャプチャする必要があります。これには、コレクターとエージェントをインストールし、場合によってはアプリケーションコードをインストルメント化する必要があります。

2つのタスクは共存することもできます。前述のように、モニタリングはオブザーバビリティのサブセットです。実際、多くのオブザーバビリティプラットフォームには、インターフェースにモニタリングツールが組み込まれています。つまり、モニタリングとオブザーバビリティの両方を処理するために2つの別々のツールセットは必要なく、すべてが一緒に含まれています。

オブザーバビリティとモニタリングの違い

オブザーバビリティとモニタリングには多くの共通点がありますが、いくつかの重要な違いがあります。1つには、モニタリングはどちらかというと運用上の機能です。システムの内部パフォーマンスを調査し、問題を報告します。モニタリングでは、問題の原因となっている可能性のある複数の要因は報告されません。問題の存在についてDevOpsチームに警告するのみです。

例えば、モニタリングでは、応答しないサーバーについてSREチームに警告できます。システムのメモリ、ネットワークパフォーマンス、CPUメトリックに関するデータは提供できますが、これらのスパイクの原因は提供できません。しかし、オブザーバビリティプラットフォームはさらに一歩進んでいます。サーバーのログ、トレース、イベント、メトリックを調べ、データを関連付けて、暴走したプロセスがCPU使用率の急増につながっているかどうかを判別します。その後、オブザーバビリティプラットフォームはそのプロセスについて報告します。

モニタリングは、何か問題があることを示します。オブザーバビリティは、データ収集を使用して、何が問題で、なぜそれが起こったのかを示します。

モニタリングではメトリックが収集されますが、DevOpsチームは依然として手動で情報を分析し、それを問題に関連付けて、エラーを特定する必要があります。オブザーバビリティではこれらの面倒なタスクが自動化され、チームが問題を特定して修正するのがはるかに簡単になります。

オブザーバビリティには、データの相関付けなどの高度な機能が備わっており、AIを使用してコンテキスト表示、分散トレース、高度な異常検知をサポートすることもあります。

もう1つの大きな違いは、オブザーバビリティは「知らないことを知っていないこと」を明らかにできることです。これらは、DevOpsチームが気づいていなかった問題です。一方、モニタリングはシステムの状態を調査することに重点を置いています。

オブザーバビリティとモニタリングの連携方法

この2つの機能は異なり、目的も異なりますが、これは「どちらか一方」の議論ではありません。両者は共存することができ、また共存すべきであり、互いに補完し合い、より強固な問題解決体験を実現します。

モニタリングでは、小さな既知の問題を把握して報告できます。アラートを通じてこれらの問題を強調し、重大度が高まる前に対処に必要な基本情報をSREチームに提供できます。

モニタリングは、システムに対する計画的な変更を確認するのにも役立ちます。サーバーのディスク領域が不足するシナリオを想像してみてください。モニタリングはそれを浮き彫りにすることができます。DevOpsチームは、計画された変更を実装してディスク領域を追加し、モニタリングシステムのアラートを停止させることができます。この場合、より複雑な観察を必要とせずに修正が完了したと見なすことができます。

しかし、明確な根本原因がないまま、同じ問題のインシデントが繰り返し発生した場合はどうなるでしょうか。その場合、モニタリングでは不十分な分野である、観察とより深いレベルの分析が必要になる可能性があります。オブザーバビリティツールは、1つまたは場合によっては複数の根本原因を特定できます。これが完了すると、DevOpsエンジニアは、追加のメトリックセット用にモニタリングツールを再設定したり、追加のアラートを送信したり、特定のアラーム条件を無視したりすることができます。

オブザーバビリティは、容量計画、コスト最適化、パッチ適用、アップグレード、修正プログラムの開発などの作業を支援するのに最適です。モニタリングでは、これらの同じタスクを実行できない場合がありますが、アクションの結果が成功したかどうかを確認できます。

次世代SIEMおよびログ管理のための世界をリードするAIネイティブプラットフォームをお試しください

SIEMとログ管理のための最高水準のAIネイティブプラットフォーム、CrowdStrike Falcon^®プラットフォームでサイバーセキュリティを強化しましょう。ペタバイト規模でのセキュリティログを体験してみてください。クラウドネイティブ型または自己ホスト型での展開が可能です。ボトルネックの生じない、強力でインデックスフリーのアーキテクチャを利用してデータをロギングすれば、1日あたり1PB以上のデータを取り込んで脅威ハンティングに役立てることができます。リアルタイムの検索機能により攻撃者をしのぐスピードで対策を実施できます。複雑なクエリを実行しても、そのレイテンシーは1秒未満です。360度の可視性によりデータを統合してサイロ化を解消し、セキュリティ、IT、DevOpsチームがシームレスに脅威のハンティング、パフォーマンスのモニタリング、コンプライアンスの確保を行うことができます。30億件ものイベントにわたる作業でも1秒未満で実施できます。