Golden Signals（4つのゴールデンシグナル）とは？SREの監視指標と実装・アラート設計を解説

Golden Signals（ゴールデンシグナル）とは、Googleが公開したSRE本『Site Reliability Engineering』の監視章が示す、ユーザー向けシステムでまず観測すべき4つの指標です。レイテンシ・トラフィック・エラー・サチュレーションの4つを指し、数百のメトリクスを並べる前に「この4つだけは常時見る」という優先順位を与えてくれます。この記事では各シグナルの定義と、PrometheusやCloudWatchでの取り方（PromQL例つき）、アラート閾値の決め方、REDメソッド・USEメソッドとの使い分け、そして小規模チームで4信号が過剰になる境界までを実装者の解像度でまとめます。

まとめ：4つのゴールデンシグナルの結論と実務での使い分け

結論を先に置きます。Golden Signalsは「レイテンシ（応答時間）」「トラフィック（需要量）」「エラー（失敗率）」「サチュレーション（逼迫度）」の4指標で、リクエスト駆動のサービスを監視する出発点になります。まずこの4つのダッシュボードとアラートを組めば、詳細メトリクスが未整備でも障害の一次検知は成立するでしょう。

4信号は測る対象で役割が分かれます。レイテンシ・トラフィック・エラーはリクエスト側（ユーザー体験）、サチュレーションはリソース側（キャパシティの余力）を見る指標です。前者はREDメソッド、後者はUSEメソッドとほぼ重なり、Golden Signalsは両者を1セットにまとめた枠組みだと理解すると実装で迷いません。

実務での組み方は、各信号をSLI（サービスレベル指標）の候補に昇格させ、SLOで目標値を敷き、逸脱をアラート化する流れになります。SLI/SLOの設計そのものはサービスレベル指標(SLI)とSLOの基本概念で扱っているため、本記事は「何を観測するか」に絞ります。小規模サービスなら、4信号すべてを揃える前にレイテンシとエラーの2つから始める判断も成り立ちます（詳細は導入判断の章）。

Golden Signalsの定義と出所（Google SRE本の監視章）

Golden Signalsは、Googleが2016年にO’Reillyから公開したSRE本の「Monitoring Distributed Systems（分散システムの監視）」章で提示された考え方です。著者はGoogleのSREチームで、無数のメトリクスに溺れずに済むよう「ユーザー向けシステムを監視するなら、この4つの信号に絞れ」と示しました。SREという職種の考え方自体はSRE（サイト信頼性エンジニアリング）とはで整理しています。

4信号（レイテンシ/トラフィック/エラー/サチュレーション）の定義

各信号が観測する対象は次の通りです。数を4に固定している点が、あれもこれもと指標を増やす監視との違いになります。

SRE本が念を押しているのは、レイテンシで成功リクエストと失敗リクエストの応答時間を分けて測る点です。エラーは即座に返るため、失敗を混ぜた平均レイテンシは実態より速く見え、障害を隠します。サチュレーションは全リソースの平均ではなく、先に天井へ当たるリソースを対象にしてください。

可観測性の3本柱（メトリクス・ログ・トレース）の中での位置づけ

Golden Signalsは「何を測るか（メトリクスの選び方）」の指針であり、メトリクス・ログ・トレースというオブザーバビリティ（可観測性）の3本柱のうち主にメトリクスの層に効きます。4信号でアラートが鳴った後、原因の深掘りにログとトレースを併用する、という分担で考えると監視基盤の設計がぶれません。

各シグナルの取り方とPromQL・CloudWatchでの実装の勘所

PrometheusとGrafanaを前提に、4信号のクエリと計測の勘所を示します。HTTPサーバーが http_requests_total と http_request_duration_seconds_bucket を公開している標準的な構成を想定します。

サービスへのトラフィックとエラー率を計測するPromQLクエリ

トラフィックは秒間リクエスト数、エラーは失敗の割合で取ります。エラーは件数ではなく比率で見るのがSRE本の推奨で、トラフィックが増減しても閾値が安定します。トラフィック（RPS）を取るクエリは sum(rate(http_requests_total[5m])) です。

エラー率は、失敗リクエストのレート sum(rate(http_requests_total{status=~"5.."}[5m])) を全体のRPSで割って求めます。分母にトラフィックのクエリを置く形です。5xxだけでなく、業務上の失敗（決済拒否・在庫切れ等の想定内エラー）を分子に含めるかは事前に定義してください。含めると「システムは正常だが業務エラーで警報」という誤検知につながります。

レイテンシをパーセンタイルで取得するクエリとバケット精度の勘所

レイテンシは平均ではなくパーセンタイルで見ます。平均は一部の遅い応答を薄めてしまい、体感の悪化を捉えられないためです。ヒストグラムからp99を出すクエリは histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) の形になります。

p99だけでなくp50も並べると、全体が遅いのか一部だけ遅いのかを切り分けられます。ヒストグラムのバケット境界（le）が粗いとパーセンタイルの精度が落ちるので、SLOの閾値付近にバケットを厚く置くのが実装の勘所です。

サチュレーションの計測対象と計装でカバーすべきリソースの範囲

サチュレーションは、先に限界へ達するリソースを対象にします。Webサーバーなら同時接続数やワーカー使用率、DBならコネクションプール使用率、コンテナならCPUスロットリング率が候補です。ノードのCPU使用率なら node_exporter のメトリクスから算出します。アプリ側の http_requests_total をコードに埋める計装は、フレームワークのミドルウェアで一括して入れると漏れが出ません。CloudWatchを使う場合は、Amazon CloudWatch Application Signalsが4信号に近い指標（レイテンシ・エラー率・リクエスト数・障害率）を自動収集するため、EKS/ECS上のサービスなら計装コストを抑えて始められます。

症状ベースのアラート設計とREDメソッド・USEメソッドとの使い分け

4信号を集めても、閾値と鳴らし方を誤ると警報疲れを招きます。ここではアラートの組み方と、近縁フレームワークとの棲み分けを示します。

症状ベースのアラート設計と閾値をエラーバジェットから決める方法

SRE本は「原因ではなく症状でアラートする」ことを勧めます。CPU使用率90%それ自体で起こすのではなく、その結果としてレイテンシがSLOを割った／エラー率が上がったという利用者に届く症状で起こす設計です。閾値はSLOのエラーバジェットから逆算し、単発のスパイクで鳴らさないよう「5分間の窓で継続」など持続条件を付けましょう。SLOとエラーバジェットの敷き方はSLO（サービスレベル目標）とはで扱っています。

REDメソッド・USEメソッドとGolden Signalsの違い

Golden Signalsは、REDメソッド・USEメソッドと重なり合う関係にあります。混同されがちなので対象で切り分けます。REDはRate（流量）・Errors（失敗）・Duration（所要時間）、USEはUtilization（使用率）・Saturation（飽和）・Errors（失敗）の頭字語です。

REDはGolden Signalsのリクエスト側3信号（サチュレーションを除く）とほぼ同義、USEはサチュレーション側の深掘りに当たり、リソース単位での詳しい分析手順はUSEメソッドとはで扱っています。実務ではサービス単位はRED、ホストやリソース単位はUSE、両者をまとめた全体像がGolden Signalsと割り振ると、どの層に何を貼るかの判断が速くなります。3つを別物として全部作る必要はありません。

Golden Signalsの導入判断（4信号が過剰になる境界）

ここは独自の判断を言い切ります。4信号を「常に全部揃える」のは、規模によっては過剰投資です。採用条件と、あえて絞る場面を条件付きで示しましょう。

4信号のすべてを最初から揃える価値があるサービスの条件と要件

次のいずれかに当てはまるなら、4信号を最初から揃える価値があります。

• SLOを外部と合意している、または稼働率を対顧客でうたっている
• マイクロサービスで障害の切り分けにサービス横断の共通指標が要る
• オートスケールの判断材料としてサチュレーションを継続監視したい

この場合、4信号をSLI化し、サービスごとに同じダッシュボード雛形を配ると運用が揃います。サチュレーションを持つことで、エラーが出る前の予兆（プール枯渇の手前）で手を打てる点が効いてきます。

あえて2信号から始める・サチュレーションを見送る具体的な場面

逆に、単一サービスの社内ツールや、月間リクエストが小さい初期プロダクトでは、レイテンシとエラーの2信号から始める判断を推奨します。トラフィックが小さいうちはRPSの監視価値が低く、サチュレーションもマネージドサービス側が吸収するため、4信号を律儀に揃える工数がSLOの合意もない段階で先行してしまうからです。ダッシュボードとアラートの保守コストは信号数に比例して増え、警報疲れの原因にもなります。まずレイテンシとエラーで「遅い・失敗している」を掴み、スケールやSLO合意の段階でトラフィックとサチュレーションを足す、という順序が無駄を抑えます。

監視基盤の設計から計装、アラートの継続運用までを内製で抱えきれない場合は、既存システムの保守運用や内製化の伴走を外部に委ねる選択もあります。当社のシステムの保守運用・内製化支援では、Golden Signalsを起点にした監視設計と運用体制づくりの相談を受け付けています。

よくある質問

Golden Signalsの実装でつまずきやすい点をまとめます。

Golden Signalsとオブザーバビリティは何が違いますか？

Golden Signalsは「どのメトリクスを優先して測るか」の指針で、オブザーバビリティは「メトリクス・ログ・トレースで内部状態を推し量れる状態」という広い概念です。4信号は可観測性のメトリクス層に効く出発点であり、鳴った後の原因調査でログとトレースを併用する関係にあります。

Golden SignalsとSLIはどう対応しますか？

4信号はそのままSLI（サービスレベル指標）の候補になります。レイテンシとエラー率は特にSLI化しやすく、SLOで目標値を敷けばアラートの閾値もエラーバジェットから逆算できます。SLI/SLOの設計手順は関連記事をご覧ください。

サチュレーションは具体的に何を測ればよいですか？

そのサービスで最初に天井へ当たるリソースを1つ選びます。Webならワーカー使用率や同時接続数、DBならコネクションプール使用率、コンテナ環境ならCPUスロットリング率が実務的な候補です。全リソースの平均ではなく、ボトルネックになる1点を対象にしてください。

4つ全部を監視しないと意味がないですか？

そうとは限りません。小規模サービスや初期プロダクトでは、レイテンシとエラーの2信号から始めても一次検知は成立します。トラフィックとサチュレーションは、規模拡大やSLO合意の段階で足すと工数の無駄を抑えられます。

REDメソッドとどちらを使うべきですか？

対象で選びます。個々のマイクロサービスの監視はRED（Rate・Errors・Duration）、リソース単位はUSE、両者をまとめた全体像がGolden Signalsです。3つは競合ではなく層の違いなので、サービス層にRED、基盤層にUSEを貼り、SLOの視点で4信号に束ねる組み合わせが扱いやすい構成になります。

関連記事

• サービスレベル指標(SLI)とサービスレベル目標(SLO)とは何か：4信号をSLI化し目標値を敷く次のステップ
• SLOとは？SLA・SLIとの違いと設定方法：アラート閾値を逆算するエラーバジェットの設計
• オブザーバビリティ（可観測性）とは？監視との違い・3本柱：4信号が効くメトリクス層の上位概念
• SREとは？サイト信頼性エンジニアリングの意味：Golden Signalsが提唱された背景と職種の考え方