オンプレ時代、「監視」といえばZabbixやNagiosでサーバーのCPUやメモリを閾値監視することでした。アラートが鳴ったら該当サーバーにログインしてログを確認する、というサイクルが当たり前でした。ところがクラウドやマイクロサービス環境では、その「監視」だけでは原因特定が難しくなってきています。そこで登場したのが「オブザーバビリティ（Observability）」という考え方です。
この記事では、監視とオブザーバビリティの違い、オブザーバビリティを構成する3本柱（メトリクス・ログ・分散トレーシング）の役割、そしてAWSとAzureの主要サービス対応表と現場への導入ステップを解説します。
監視とオブザーバビリティ — 何が違うのか？
「監視」と「オブザーバビリティ」は混同されがちですが、目的と思想が根本的に異なります。
監視（Monitoring）は、「何かがおかしい」ことを通知するしくみです。あらかじめ想定できる問題（CPU高騰、レスポンスタイム超過など）を閾値として設定し、それを超えたらアラートを上げます。オンプレ時代の監視はこれが中心でした。
オブザーバビリティ（Observability）は、「なぜおかしいのか」を調査できる状態のことです。システムの内部状態を外から観察可能にする設計思想であり、想定外の問題が起きたときでも根本原因を突き止められることを目指します。
| 観点 | 監視（Monitoring） | オブザーバビリティ（Observability） |
|---|---|---|
| 問いかけ | 何かおかしくないか？ | なぜおかしいのか？ |
| アプローチ | 既知の失敗を閾値で検知 | 未知の失敗を内部状態から探索 |
| 前提条件 | 何を監視するか事前に決める | 事前に決めずアドホックに調査できる |
| 主な適用 | 単一サーバー・モノリスアプリ | マイクロサービス・分散システム |
マイクロサービス構成では、1つのAPIリクエストが10以上のサービスをまたいで処理されます。CPU監視だけでは「どのサービスで遅延が発生したか」を追跡できません。オブザーバビリティが必要とされる背景はここにあります。
オブザーバビリティの3本柱
オブザーバビリティは、メトリクス・ログ・分散トレーシングの3種類のデータを組み合わせて実現します。
1. メトリクス（Metrics）
数値で表現されるシステムの状態データです。CPUやメモリの使用率、HTTPリクエスト数、エラーレートなどが代表的です。時系列で収集して可視化し、傾向分析やアラートのトリガーとして使います。
・特徴: 軽量・高速で大量収集しやすい
・弱点: 「何が起きているか」は分かるが「なぜか」は分からない
・オンプレ相当: Zabbixの数値グラフ、Prometheusによるscrape収集
・クラウド例: Amazon CloudWatch Metrics、Azure Monitor Metrics
2. ログ（Logs）
イベントの発生記録です。エラーメッセージ、アクセスログ、アプリケーションの詳細出力など、「その時何が起きたか」をテキストで残します。
・特徴: 詳細な文脈情報を含む
・弱点: 大量になるとコストと検索コストが増大する（Amazon CloudWatch Logsの費用がかさむ原因の一つ）
・オンプレ相当: syslog、/var/log/配下のファイル、ELKスタック
・クラウド例: Amazon CloudWatch Logs、Azure Monitor Logs（Log Analytics Workspace）
3. 分散トレーシング（Distributed Tracing）
1つのリクエストがマイクロサービスをまたいでどのように流れたかを追跡するデータです。各サービス間の呼び出しを「スパン」という単位で記録し、「トレース」として全体像を可視化します。
・特徴: マイクロサービスのボトルネックや障害連鎖を正確に特定できる
・弱点: 計装（instrumentation）コストが高く、各サービスにSDKを組み込む必要がある
・オンプレ相当: 概念自体が比較的新しく、オンプレでは限定的（Jaegerを自前運用するケースが多い）
・クラウド例: AWS X-Ray、Azure Application Insights（分散トレース機能）
これら3本柱を連携させることで、「メトリクスでエラーレート上昇を検知 → ログで該当リクエストの詳細を確認 → トレースでどのサービスで遅延が発生したか特定」という調査フローが完成します。
オンプレ監視とクラウドのオブザーバビリティを比べると
| 項目 | オンプレ監視（従来型） | クラウドオブザーバビリティ |
|---|---|---|
| メトリクス収集 | Zabbix、MRTG | Amazon CloudWatch、Prometheus + Grafana |
| ログ管理 | ELKスタック（自前運用） | Amazon CloudWatch Logs、Azure Log Analytics |
| 分散トレース | Jaeger（自前構築） | AWS X-Ray、Azure Application Insights |
| 統合ダッシュボード | Grafana（自前構築） | Amazon Managed Grafana、Azure Monitor ワークブック |
| 標準化仕様 | ベンダー依存 | OpenTelemetry（OTel）が業界標準として普及 |
オンプレ時代は「ツールを自前で建てて管理する」手間がありましたが、クラウドではマネージドサービスとして提供されているため、構築コストが大幅に下がっています。一方でクラウドサービス固有のコスト（ログ取込料金、メトリクス数課金）には注意が必要です。
AWSとAzureの主要オブザーバビリティサービス対応表
| 役割 | AWSサービス | Azureサービス |
|---|---|---|
| メトリクス収集・アラート | Amazon CloudWatch Metrics | Azure Monitor Metrics |
| ログ収集・検索 | Amazon CloudWatch Logs | Azure Monitor Logs（Log Analytics） |
| 分散トレーシング | AWS X-Ray | Azure Application Insights |
| 統合ダッシュボード | Amazon Managed Grafana | Azure Monitor Workbooks |
| セキュリティイベント | Amazon GuardDuty / AWS Security Hub | Microsoft Sentinel |
| サービス正常性確認 | AWS Health Dashboard | Azure Service Health |
| コスト異常検知 | AWS Cost Anomaly Detection | Azure Cost Management アラート |
AWSでは、Amazon CloudWatch がメトリクス・ログ・アラームを一元管理し、AWS X-Rayが分散トレーシングを担います。Azureでは Azure Application Insights がトレーシングとAPM（Application Performance Monitoring）を統合しており、バックエンドにAzure Monitor Logs（Log Analytics Workspace）を使う構成が標準です。
OpenTelemetryでベンダーロックインを回避する
クラウドネイティブな観測データの標準仕様として「OpenTelemetry（OTel）」が急速に普及しています。AWS X-RayもAzure Application InsightsもOpenTelemetryのデータ形式を受け付けており、1つの計装コードで複数のバックエンドにデータを送ることができます。
・ベンダーロックイン回避: AWSからAzureに移行しても計装コードを書き直さなくてよい
・標準SDK: Go、Python、Java、Node.jsなど主要言語のSDKが揃っている
・OTLP（OpenTelemetry Protocol）: メトリクス・ログ・トレースを統一プロトコルで送信できる
現場ではまず Amazon CloudWatch や Azure Application Insights から始めて、規模が大きくなったら OTel Collector を挟んでマルチバックエンド構成に移行するのが現実的なパスです。
現場での導入ステップ
1. まずメトリクスとアラートを整備する
Amazon CloudWatch や Azure Monitor のデフォルトメトリクスを有効化し、CPU・メモリ・HTTPエラーレートのダッシュボードを作成します。アラームを設定してAmazon SNS経由でSlackに通知する仕組みを整えるだけで、オンプレ監視の水準はクリアできます。
2. 構造化ログに切り替える
アプリケーションのログ出力をJSON形式（構造化ログ）に変更します。CloudWatch Logs InsightsやAzure Log Analyticsでのクエリ効率が格段に上がります。
# 構造化ログの例（Python） import json, logging logging.info(json.dumps({ "event": "order_created", "order_id": "ORD-1234", "user_id": "USR-9876", "amount": 4980, "duration_ms": 42 }))
3. 分散トレーシングを段階的に導入する
最初から全サービスに入れようとすると工数がかかりすぎます。まず「レイテンシが問題になっているサービス」から優先的に計装します。AWS X-Rayの場合、AWS LambdaやAmazon ECSタスクへの統合はSDKを追加するだけで始められます。
# AWS X-Ray SDK（Python）の基本設定 from aws_xray_sdk.core import xray_recorder, patch_all xray_recorder.configure(service='order-service') patch_all() # boto3・requestsなどを自動計装
よくある誤解とトラブル
「ログを全件保存すれば安心」は危険
Amazon CloudWatch Logsはデータ取込料（$0.76/GB、2026年3月時点）と保管料が別途かかります。不要なデバッグログを本番環境に出し続けると月額が跳ね上がります。ログレベルを適切に設定し、保存期間ポリシーを必ず設定しましょう。
アラートが多すぎてアラート疲れになる
閾値を厳しくしすぎると、重要でないアラートが大量に届いてエンジニアが慣れてしまいます（アラートファティーグ）。まずP1（サービス停止）とP2（パフォーマンス劣化）を分けて、P1のみ即時通知・P2はダッシュボード確認の運用から始めるのが現実的です。
AWS X-Rayのサンプリングレートをデフォルトのままにしてコストが増大
AWS X-Rayはデフォルトで全リクエストの5%と毎秒1リクエストをサンプリングします。高トラフィック環境では意図せずデータ量が増えることがあります。本番では意図的にサンプリングレートを調整してください。
Linuxサーバー上でのログ管理やsyslogの基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。
本記事のまとめ
・監視とオブザーバビリティの違い: 監視は「何がおかしいか」の通知、オブザーバビリティは「なぜおかしいか」を調査できる状態
・3本柱: メトリクス（数値）・ログ（イベント記録）・分散トレーシング（リクエスト追跡）を組み合わせる
・AWS対応: Amazon CloudWatch（メトリクス・ログ）+ AWS X-Ray（トレーシング）
・Azure対応: Azure Monitor Logs + Azure Application Insights（トレーシング含む）
・導入順序: メトリクス → 構造化ログ → 分散トレーシングの順で段階的に整備する
・標準化: OpenTelemetryでベンダーロックインを回避しながら将来の拡張に備える
オンプレ時代のZabbix監視からクラウドのオブザーバビリティへの移行は、ツールを変えるだけでなく「設計思想」を変えることを意味します。まずはメトリクスとアラートを整備し、構造化ログ → トレーシングと段階的に積み上げることで、現場への負担を最小化しながら本格的なオブザーバビリティを実現できます。
クラウド移行後の監視設計、どこから手をつければいいか迷っていませんか？
クラウド実務に役立つ「Glossary Comparison」カテゴリの記事を他にもまとめています。あわせて読みたい関連記事はこちらからどうぞ。
