本章では、クラウドネイティブ時代におけるObservability（可観測性）の考え方を学習します。
従来の監視ではCPUやメモリ使用率などのメトリクスを確認するだけでしたが、マイクロサービス化が進んだ現在では、それだけでは障害原因を特定することが困難になっています。
Observabilityとは、システム内部の状態を外部から推測・分析できる能力を指し、Metrics・Logs・Tracesの3本柱を中心に構成されます。
1. Observabilityとは
Observability（可観測性）とは、システム内部で何が起きているかを、収集したデータから推測できる能力です。
Application
↓
Metrics
Logs
Traces
↓
分析
↓
障害原因特定
「監視（Monitoring）」は異常を検知する仕組みですが、「Observability」は異常の原因を分析するための考え方です。
2. Monitoringとの違い
| Monitoring | Observability |
|---|---|
| 異常検知 | 原因分析 |
| アラート中心 | データ分析中心 |
| 既知の障害 | 未知の障害 |
3. Observabilityの3本柱
- Metrics（メトリクス）
- Logs（ログ）
- Traces（分散トレーシング）
Application
↓
Metrics
↓
Logs
↓
Trace
↓
Dashboard
4. Metricsとは
数値として継続的に収集されるデータです。
代表例
- CPU使用率
- Memory使用率
- Request数
- Error数
- Latency
- Disk I/O
- Network Traffic
5. Logsとは
アプリケーションやOSが出力するイベント情報です。
2026-01-01 INFO Login Success
2026-01-01 ERROR Database Timeout
2026-01-01 WARN Retry
ログは障害解析の最も基本となる情報です。
6. Tracesとは
1つのリクエストがどのサービスを経由したかを可視化します。
Client
↓
API Gateway
↓
User Service
↓
Order Service
↓
Payment Service
↓
Database
7. Prometheus
Prometheusは時系列データベースを利用した監視システムです。
特徴
- Pull型監視
- 時系列DB
- PromQL
- Kubernetes対応
8. Exporter
PrometheusはExporterを利用してデータを収集します。
Node Exporter
↓
Prometheus
↓
Grafana
代表例
- Node Exporter
- MySQL Exporter
- Redis Exporter
- Blackbox Exporter
9. PromQL
PrometheusではPromQLを利用して分析します。
rate(http_requests_total[5m])
sum(node_cpu_seconds_total)
histogram_quantile()
10. Grafana
Grafanaは監視ダッシュボードを構築するためのツールです。
Prometheus
↓
Grafana
↓
Dashboard
CPU・Memory・Network・Applicationなどを可視化できます。
11. AlertManager
Prometheusのアラート管理を担当します。
Metric
↓
Alert
↓
AlertManager
↓
Slack
↓
Email
↓
PagerDuty
12. ELK Stack
ログ分析ではELK Stackがよく利用されます。
- Elasticsearch
- Logstash
- Kibana
13. Fluentd・Fluent Bit
ログ収集エージェントとして利用されます。
Container
↓
Fluent Bit
↓
Elasticsearch
14. OpenTelemetry
Observabilityデータを収集する標準仕様です。
現在では多くのクラウドサービスが対応しています。
15. Jaeger
Jaegerは分散トレーシングツールです。
Application
↓
OpenTelemetry
↓
Jaeger
↓
Trace表示
16. Zipkin
Zipkinも分散トレーシングツールとして利用されます。
17. SLI・SLO・SLA
SLI（Service Level Indicator）
サービス品質を測定する指標です。
SLO（Service Level Objective）
目標値です。
SLA（Service Level Agreement）
顧客との契約値です。
18. Error Budget
SLOから許容できる障害時間を算出します。
SLO
99.9%
↓
Error Budget
0.1%
19. Four Golden Signals
Google SREで提唱された重要指標です。
- Latency
- Traffic
- Errors
- Saturation
20. RED Method
- Rate
- Errors
- Duration
Web API監視でよく利用されます。
21. USE Method
- Utilization
- Saturation
- Errors
インフラ監視向けの考え方です。
22. Dashboard設計
良いダッシュボードには以下が必要です。
- リアルタイム性
- 重要指標の集約
- 障害原因を追跡できる構成
- ノイズの少ない表示
23. よくある監視ミス
- CPUだけ監視する
- ログを見ない
- Traceを収集しない
- アラートが多すぎる
- 重要指標が分からない
- ダッシュボードだけ見て安心する
24. ベストプラクティス
- Metrics・Logs・Traceを統合する
- SLIを定義する
- SLOを設定する
- Error Budgetを管理する
- 重要アラートのみ通知する
- ダッシュボードを継続改善する
まとめ
Observabilityは単なる監視ではなく、システム全体を理解するための重要な設計思想です。
Prometheus・Grafana・OpenTelemetry・Jaegerなどを組み合わせることで、マイクロサービス環境でも迅速な障害解析を実現できます。
本章のゴール
- Observabilityの概念を説明できる
- Monitoringとの違いを理解する
- Metrics・Logs・Tracesを使い分けられる
- Prometheusを理解する
- Grafanaを利用できる
- PromQLを理解する
- OpenTelemetryを理解する
- JaegerによるTrace解析ができる
- SLI・SLO・SLAを説明できる
- SREの監視設計を理解する
