スポンサードリンク
ゴールデンシグナルとは何か
SRE（Site Reliability Engineering）が提唱する 「ゴールデンシグナル」 は、サービスの健康状態を瞬時に把握できる 4 つの指標です。
以下の外部リファレンスで概念が整理されています。
| シグナル | 定義 | 代表的な障害シナリオ |
|---|---|---|
| レイテンシ | リクエスト完了までに要した時間（例：95 th パーセンタイル） | バックエンド DB のボトルネック、ネットワーク遅延 |
| トラフィック (スループット) | 単位時間あたりの成功リクエスト数 | 突発的なアクセス急増によるキャパシティ不足 |
| エラー率 | 全リクエストに対する失敗（5xx、例外等）の比率 | コードバグ、外部依存サービスの障害 |
| 飽和状態 | CPU・メモリ・ディスク I/O など資源使用率が上限付近になること | リソース枯渇によるスローダウンやクラッシュ |
これらを 「常時監視」かつ 「数値化」 することで、サービスが 健全 / 異常 のどちらにあるかを即座に判断でき、SLO（Service Level Objective）達成度の評価基盤となります。
SLI／SLO への落とし込み方
1. シグナルごとの SLI 定義例
| ゴールデンシグナル | 推奨 SLI（測定方法） | ビジネス指標との紐付け |
|---|---|---|
| レイテンシ | latency_95p ≤ 200 ms（Prometheus の histogram_quantile） |
ユーザー体験の「ページ表示時間」目標 |
| トラフィック | requests_per_min ≥ 10,000 rps（rate 関数） |
売上につながる「取引件数」確保 |
| エラー率 | error_rate ≤ 0.1 %（(errors / total) ×100） |
SLA に基づく「サービス停止時間」削減 |
| 飽和状態 | cpu_util ≤ 80 % && memory_util ≤ 75 %（node_exporter） |
スケーリングタイミングの判断材料 |
2. SLO の設定例
- レイテンシ：99.9 % のリクエストが 200 ms 以下
- トラフィック：24 時間中 99.5 % が目標スループットを維持
- エラー率：99.95 % の期間で上限 0.1 % を下回ること
- 飽和状態：CPU・メモリが閾値を超える時間は月間 0.5 % 未満
ポイント：SLO は ビジネス要件 と 技術的限界 のバランスで決めるべきです。CloudNative Labs では、四半期ごとにステークホルダーとレビューし、必要に応じて調整しています。
主要ツール別実装手順
Prometheus ＋ Grafana での実装
1. 構成イメージ
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
+-------------------+ +--------------------+ | アプリ / DB | ---> | Exporter (node, | | (metrics) | | cAdvisor, etc.) | +-------------------+ +--------------------+ ^ | | HTTP GET /metrics | v v +-------------------------------------------+ | Prometheus | | - scrape_configs.yml | | - alerts.yml (AlertRule) | +-------------------------------------------+ | v (PromQL) +-------------------------------------------+ | Grafana | | - ダッシュボード JSON | | - アラート通知（Slack, PagerDuty） | +-------------------------------------------+ |
2. prometheus.yml のサンプル
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
global: scrape_interval: 15s evaluation_interval: 30s scrape_configs: - job_name: 'node_exporter' static_configs: - targets: ['localhost:9100'] - job_name: 'my_service' metrics_path: '/metrics' static_configs: - targets: ['localhost:8080'] |
3. アラートルール（alerts.yml）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
groups: - name: golden-signals rules: # レイテンシ (95th percentile > 200ms) - alert: HighLatency expr: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{job="my_service"}[5m])) by (le)) > 0.2 for: 2m labels: severity: critical annotations: summary: "High latency detected on {{ $labels.instance }}" description: "95th percentile latency > 200 ms" # エラー率 (>0.1%) - alert: ErrorRateTooHigh expr: (sum(rate(http_requests_total{status=~"5..",job="my_service"}[5m])) / sum(rate(http_requests_total[5m]))) * 100 > 0.1 for: 3m labels: severity: warning annotations: summary: "Error rate exceeds 0.1 % on {{ $labels.instance }}" |
4. Grafana ダッシュボード例（JSON は GitHub リポジトリで共有）
- Panel A：
histogram_quantile(0.95, …)→ レイテンシ折れ線 + 200 ms 閾値 - Panel B：
rate(http_requests_total[1m])→ RPS（スループット） - Panel C：エラー率計算式の Timeseries
- Panel D：CPU・メモリ使用率 Gauges
CloudNative Labs の推奨：ダッシュボードは「チームごとにテンプレート化」し、
grafana-cli plugins install grafana-polystat-panel等で可視性を向上させる。
Datadog Agent での実装
参考記事
Qiita 記事: https://qiita.com/yourname/items/abcdef1234567890
| 手順 | 内容 |
|---|---|
| 1. Agent インストール | bash<br>DD_AGENT_MAJOR_VERSION=7 DD_API_KEY=<YOUR_API_KEY> bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script.sh)" |
| 2. 標準チェック有効化 | /etc/datadog-agent/conf.d/system.yaml に collect_cpu_time: true, collect_memory_metrics: true を追加 |
| 3. カスタムメトリクス送信 | アプリ側で StatsD ライブラリを利用し、statsd.histogram('http.request.latency', latency_ms) のように送出 |
| 4. ダッシュボード作成 | Datadog UI → Create Dashboard → Timeseries に system.cpu.user, http.request.latency.avg 等を追加 |
| 5. アラート設定 | Monitors → Metric Alert、例: avg(last_5m):avg:http.request.error_rate > 0.001 |
ベストプラクティス（Datadog 編）
- タグ付け徹底：
env:prod, service:orders, team:sreのように統一し、全モニタリングでフィルタ可能に。 - 自動検出：Kubernetes 環境では
DD_KUBERNETES_INTEGRATION=trueを有効化すると、Pod 毎のメトリクスが自動取得されます。
Google Cloud Run での実装
参考ブログ
PharmaX Blog: https://pharmax.jp/blog/google-cloud-run-golden-signals
Cloud Run は 標準メトリクス を Cloud Monitoring に自動送信します。追加エージェントは不要です。
| メトリクス | Cloud Monitoring 名称 |
|---|---|
| レイテンシ | run.googleapis.com/request_latencies（p50/p95/p99） |
| トラフィック | run.googleapis.com/request_count |
| エラー率 | run.googleapis.com/request_count にステータスコード別集計を適用 |
| 飽和状態 | run.googleapis.com/container/cpu/utilization、run.googleapis.com/container/memory/bytes_used（プレビュー） |
アラートポリシー作成手順
- Monitoring → Alerting → Create Policy
- 条件例（レイテンシ p95 が 300 ms 超過）
text
resource.type = "cloud_run_revision"
metric.type = "run.googleapis.com/request_latencies"
aggregation.alignmentPeriod = "60s"
aggregation.perSeriesAligner = "ALIGN_PERCENTILE_95"
- 通知チャネル：Slack、PagerDuty、メールを同時設定し、重大度別に振り分け。
- SLO の定義（サービス画面の Service タブ）で
request_latenciesの 95th percentile ≤ 200 ms を目標に追加。
CloudNative Labs のヒント：SLO ダッシュボードは「サービス」機能を使うと自動的に可視化され、レポート作成が楽になります。
eBPF による高度計測
1. なぜ eBPF が必要か
- 粒度：アプリケーション層だけでなく、カーネルレベルのネットワーク遅延やシステムコール実行時間も取得可能。
- 低オーバーヘッド：ユーザー空間へのデータ転送が最小化され、リアルタイム性が高い。
- 統合容易性：
ebpf_exporter→ Prometheus のフローで既存の可観測基盤にシームレスに組み込めます。
参考情報（Qiita）: https://qiita.com/yourname/items/abcdef1234567890
2. 実装サンプル：HTTP リクエストレイテンシ計測
a. ソースコード (http_latency.c)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
#include <uapi/linux/ptrace.h> struct start_t { u64 ts; }; BPF_HASH(start, u32, struct start_t); BPF_HISTOGRAM(latency_hist); int trace_http_start(struct pt_regs *ctx) { u32 pid = bpf_get_current_pid_tgid() >> 32; struct start_t v = {.ts = bpf_ktime_get_ns()}; start.update(&pid, &v); return 0; } int trace_http_end(struct pt_regs *ctx) { u32 pid = bpf_get_current_pid_tgid() >> 32; struct start_t *s = start.lookup(&pid); if (s) { u64 delta_ns = bpf_ktime_get_ns() - s->ts; latency_hist.increment(bpf_log2l(delta_ns / 1000000)); // ms → bucket start.delete(&pid); } return 0; } |
b. ビルド & ロード
|
1 2 3 |
clang -O2 -target bpf -c http_latency.c -o http_latency.o sudo bpftool prog load http_latency.o /sys/fs/bpf/http_latency type tracepoint |
c. ebpf_exporter 設定例 (ebpf.yaml)
|
1 2 3 4 5 6 7 8 9 10 |
programs: - name: http_latency path: /sys/fs/bpf/http_latency metrics: - name: http_latency_seconds_bucket type: histogram help: "HTTP request latency in seconds" buckets: [0.01, 0.05, 0.1, 0.2, 0.5, 1, 2, 5] bpf_map: latency_hist |
d. Prometheus での SLI 計算
|
1 2 3 |
histogram_quantile(0.95, sum(rate(http_latency_seconds_bucket[5m])) by (le)) |
3. 導入上の注意点
| 項目 | ポイント |
|---|---|
| 権限 | CAP_SYS_ADMIN が必要。Kubernetes 環境では securityContext: privileged: true を検討 |
| パフォーマンス | トレースポイントは最低限に絞る（例：HTTP ハンドラだけ） |
| 互換性 | カーネル 5.10 以上を推奨。CI パイプラインで bpftool prog show を自動検証すると安心 |
運用ベストプラクティス & リソース提供
1. アラート設計の原則（Alert Fatigue 防止）
| フェーズ | 推奨アクション |
|---|---|
| 閾値設定 | - for: 条件で 5 分以上 の継続を必須に- 重大度別に通知チャネル（Slack‑info, PagerDuty‑critical）を分離 |
| 一次応答 | Runbook に「自動スケールアウト」や「キャッシュクリア」の手順を記載し、オンコールが即実行可能な状態に |
| エスカレーション | 1 回目は Slack → 3 回連続で未解決なら PagerDuty に自動昇格 |
2. ポストモーテム標準テンプレート
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
# インシデント概要 - 発生日: YYYY/MM/DD HH:mm (JST) - 影響範囲: ユーザー数、サービス名、SLO 達成率 # 発生原因 - 根本原因（5 Whys） # 対応経緯 1. アラート受信 → 〇分で対応開始 2. 障害切り分け → xxx コマンド実行 3. 復旧手順 → スケールアウト # 再発防止策 - SLO 閾値の見直し（例: latency p95 を 180 ms に変更） - アラート条件に `for: 5m` を追加 - eBPF で HTTP 接続遅延計測を導入（GitHub #12） # 学び - xxx の監視が抜けていた → 今後はテンプレート化 |
CloudNative Labs の運用文化：ポストモーテムは 必ず Confluence に格納し、全チームで月例レビュー会議を開催。改善項目は JIRA の
SRE-Improvementエピックに紐付けてトラッキングします。
3. GitHub リポジトリで提供するサンプル構成
| ディレクトリ | 内容 |
|---|---|
prometheus/ |
alerts.yml, scrape_configs.yaml |
grafana/ |
golden-signals-dashboard.json（インポート用） |
datadog/ |
datadog.yaml（Agent 設定・カスタムメトリクス例） |
cloudrun/ |
slo_config.yaml（Monitoring SLO 定義サンプル） |
ebpf/ |
http_latency.c, ebpf_exporter.yaml |
リポジトリ URL: https://github.com/cloudnative-labs/sre-golden-signals-template
- CI 用 GitHub Actions が
promtool check rules、grafana-cli plugins install、go test ./...を自動実行し、プルリクエスト時に品質を保証します。
まとめ
- ゴールデンシグナルは SRE の羅針盤
-
レイテンシ・トラフィック・エラー率・飽和状態の 4 つで、サービス全体の健康度を即座に把握できます。
-
SLI／SLO に落とし込むだけで可観測性が実務レベルへ
-
ビジネス目標と技術指標を結び付け、数値化された SLO が運用判断の根拠になります。
-
主要ツールは選択肢が豊富
- Prometheus + Grafana：完全オープンソースでカスタマイズ自由。
- Datadog Agent：即時可視化と高度なタグ管理が強み。
-
Google Cloud Run：サーバーレスでも標準メトリクスだけで完結。
-
eBPF がもたらす“見えない”領域の可視化
-
カーネルレベルの遅延やリソース使用を低オーバーヘッドで取得し、既存パイプラインに統合可能です。
-
運用は「ノイズ除去」＋「学習サイクル」
- アラート閾値は慎重に設計し、ポストモーテムを標準化。GitHub テンプレートと CI による自動品質管理で継続的改善を実現します。
CloudNative Labs のメッセージ：
「可観測性はツールだけで完結しません。組織の文化・プロセス・コードベースが一体となって初めて、信頼できるサービスを提供できます。」
このガイドと公開リポジトリを活用すれば、SRE ゴールデンシグナルの導入から運用改善まで、一貫したフローで実装可能です。ぜひ自社環境に合わせてカスタマイズし、サービス信頼性を次のレベルへ引き上げましょう。
スポンサードリンク