メトリクス、ダッシュボード、SLI/SLO

メトリクスの収集は最初の一歩にすぎません。信頼性の高いシステムを運用するには、数値をダッシュボードと、実際のユーザー体験を反映したサービスレベル目標に変換する必要があります。

Google SRE では、あらゆる Service について4つのシグナルを監視することを推奨しています。それはレイテンシ、トラフィック、エラー、飽和度です。これらで、ユーザーに影響する問題の大半を把握できます。

一般的なメトリクスの形には、増加するだけのカウンター（処理したリクエスト数）、増減するゲージ（使用中のメモリ量）、値を区間に分けるヒストグラム（リクエスト時間）があります。

Prometheus のような時系列データベースでは、クエリ言語を使ってメトリクスを切り分けます。ここでは、5分間における1秒あたりのリクエストレートを計算します。

Grafana などのツールは、クエリをパネルに変換します。優れたダッシュボードは、サービスが今健全かどうかという問いに、一目で答えられます。

• 最上段：ゴールデンシグナル
• 下段：詳細を確認するパネル
• 一貫した時間範囲

Service Level Indicator（SLI）は、ユーザーの満足度を反映する測定値です。たとえば、リクエストが成功し、かつ迅速に処理された割合などが該当します。

Service Level Objective（SLO）は、一定期間における SLI の目標値です。たとえば、30日間でリクエストの99.9%を成功させる、といった目標です。どの程度なら十分に良いかを定義します。

SLAは顧客に対する契約上の約束で、多くの場合、達成できなかったときのペナルティを伴います。SLO は社内向けの、通常は SLA より厳しいエンジニアリング目標です。

SLO が99.9%なら、残りの0.1%がエラーバジェット、つまり許容できる失敗の範囲です。それをリスクのあるデプロイに使い、使い果たしたら速度を落として安定化に取り組みます。

CPU の一時的な変動すべてではなく、ユーザーが感じる問題（高いエラー率や遅い応答）に対して担当者へ通知します。症状ベースのアラートにより、ノイズと疲労を減らせます。

ダッシュボードが多すぎるのは、まったくないのと同じくらい悪い状態です。古いまま放置されたものを何十個も作るのではなく、SLO に結び付いた、信頼できる少数の担当付きダッシュボードを維持します。

SLO とエラーバジェットはどのように関係しますか。

これで、監視を意味のあるものにできるようになりました。

• 4つのゴールデンシグナルを監視します
• カウンター、ゲージ、ヒストグラムを理解し、rate() でクエリします
• 測定値であるSLIと、目標値であるSLOを定義します
• エラーバジェットをデプロイのペース配分に活用し、症状に対してアラートを出します

信頼性は、ただ願うものではなく、測定して方向付けるものになります。