オブザーバビリティの要件
エンタープライズITにおける「オブザーバビリティ（Observability：可観測性）」とは、エンタープライズシステムを構成するIT機器やアプリケーション、サービスなどが観測可能な状態にあることを指す言葉です。オブザーバビリティをエンタープライズシステムに持たせるために不可欠な要素として「メトリクス（Metrics）」「ログ（Logs）」「トレース（Trace）」の3つが位置づけられています。
前回も解説したとおり、上記3要素のうちメトリクスとは、システムを構成するリソースの状況（CPU使用率、メモリ使用率、ディスク使用率など）やサービスの状況（レスポンスの遅延、トランザクション量、エラー発生率など）を表す数値データ（数値指標）を意味しています。また、ログは、システムで起きたイベントの履歴情報のことです。さらに、トレースとは、複数のサービスコンポネントにまたがるリクエストの処理フローを可視化し、アプリケーションパフォーマンス管理（APM）を実現することを指しています。
オブザーバビリティは、障害発生時にトレースとログから原因を調査。効率的にデバッグを行うための要素として使い、メトリクスをシステムの信頼性やサービスレベルを保つための情報ソースとして使用されています。
オブザーバビリティにおけるデータ収集の仕組み
オブザーバビリティにおける重要な要素技術の一つは、上述したメトリクス、ログ、トレース情報（これらを総称して「テレメトリデータ」と呼ぶ）を観測対象から収集する仕組みとなります。そこでまずは、メトリクスとログを収集する仕組みについて説明したいと思います。
メトリクス収集の仕組み
メトリクスを収集する仕組みには、「プル型」と「プッシュ型」の2タイプがあります。プル型の代表格は「Prometheus」と呼ばれるオープンソースソフトウェア（OSS）の監視ツールで、Prometheusのサーバーが観測対象からメトリクスを収集（プル）して、バックエンドのサーバー（ストレージ）に格納する仕組みになっています。
一方のプッシュ型は、観測（監視）対象にエージェントをインストールしておき、そのエージェントがメトリクスを収集してバックエンドのサーバーに送出（プッシュ）するというものです。ただし近年では、エンタープライズシステムの構成要素としてパブリッククラウドサービスが含まれることが一般的になっており、パブリッククラウドサービスの環境には利用者側のエージェントをインストールすることができないケースがあります。そのようなケースでは、エージェントのサーバーを用意し、そのエージェントがAPIを経由してパブリッククラウドサービスの環境からメトリクスを収集してバックエンドのサーバーにプッシュするという方式がとられています。
ログ収集の仕組み
ログの場合も、監視対象にエージェントをインストールして収集するという方式が一般的でしたが、メトリクスと同様にパブリッククラウドサービスには適用できないケースがあります。そのようなケースでは、メトリクスの場合と同様に、サーバー上のエージェントが、パブリッククラウドサービスの“ログサービス”からログを収集する（プルする）方式がとられるようになってきました。
また、最近では「エージェントレス（＝エージェントを使わない）」方式でパブリッククラウドサービスのログを収集する仕組みも使われるようになっています。これはたとえば、AWS（Amazon Web Services）の「AWS Lambda」を使ってログをバックエンドのサーバーに転送する仕組みを稼働させたり、GCP（Google Cloud Platform）の場合であれば、「Dataflow」といったネイティブサービスを使ってログをバックエンドのサーバーに転送したりといった方式です。
このほか、OSSのコンテナ運用管理ツール「Kubernetes」で管理されたコンテナ環境からログを収集する方式も標準化されつつあります。これは、Kubernetesの「DaemonSet」を使いエージェントをすべてのコンテナノード（「Worker」ノード）で動作させ、ログを収集するというものです。
