Posted inMonitoring

Pyrraのインストール：Google SREスタイルのSLO管理とアラート運用

Monitoring tutorial - IT technology blog
Monitoring tutorial - IT technology blog

逆説：ダッシュボードは正常（緑色）なのに顧客から苦情が来る理由

PrometheusのダッシュボードでCPUやRAMの使用率が非常に安定しているのに、ユーザーから「アプリが重い」という苦情が出てSlackの通知が鳴り止まない、という状況に陥ったことはありませんか？以前、私は15台のサーバーを管理し、基本的なアラートをすべて設定していました。しかし、実際にはユーザーの体験ではなく、マシンの状態ばかりを測定していることに気づきました。

そこで鍵となるのがSLO（Service Level Objectives：サービスレベル目標）です。サーバーの死活監視だけでなく、「過去30日間でリクエストの何%が成功したか？」を測定します。しかし、Error BudgetやBurn Rateを計算するために何百行ものPromQLを自分で書くのは苦行です。Pyrraは、まさにこの複雑さを解決するために誕生しました。

システム運用における4つの重要な概念

Pyrraを効果的に使うには、以下の4つの用語を明確に区別する必要があります。

  • SLI (Indicator): 実際の測定指標。例：ステータスコード200を返したリクエストの割合。
  • SLO (Objective): 目指すべき目標。例：リクエストの99.9%が成功すること。この基準では、月間のダウンタイムは43.2分まで許容されます。
  • Error Budget (エラー予算): 許容されるエラーの範囲（0.1%）。これは、メンテナンスや新機能のテストに使用できる「枠」です。
  • Burn Rate (燃焼率): エラー予算を消費するスピード。Burn Rateが14.4の場合、1ヶ月分の予算をわずか2日間で使い果たしてしまうことになります。

Pyrraを使用すると、簡潔なYAMLファイルでSLOを定義できます。その後、Pyrraが非常に複雑なPrometheusのRecording Rulesを自動的に生成してくれます。

Docker ComposeによるPyrra deデプロイ

最も素早く試す方法は、Docker Composeを使用することです。PyrraはPrometheusサーバーに直接接続する必要があります。

version: '3.8'
services:
  pyrra:
    image: ghcr.io/pyrra-dev/pyrra:v0.7.0
    container_name: pyrra
    ports:
      - "9099:9099"
    command:
      - api
      - --prometheus-url=http://prometheus:9090
    restart: always

  pyrra-filesystem:
    image: ghcr.io/pyrra-dev/pyrra:v0.7.0
    container_name: pyrra-filesystem
    volumes:
      - ./slo-definitions:/etc/pyrra/slo
    command:
      - filesystem
      - --prometheus-url=http://prometheus:9090
      - --config-files=/etc/pyrra/slo/*.yaml
    restart: always

この構成では、apiコンポーネントがUIインターフェースを担当します。filesystemコンポーネントは、ローカルディレクトリからSLO定義ファイルをスキャンして読み込みます。

最初のSLOを定義する

例えば、http_requests_totalメトリクスを返すサービスがあるとします。リクエスト成功率99%のSLOを設定したい場合、slo-definitions/api-success-rate.yamlファイルを作成します。

apiVersion: pyrra.dev/v1alpha1
kind: ServiceLevelObjective
metadata:
  name: api-success-rate
  labels:
    service: backend-api
spec:
  description: バックエンドAPIの成功率は99%以上である必要があります。
  target: "99"
  window: 28d
  indicator:
    ratio:
      errors:
        metric: http_requests_total{job="backend", code=~"5.."}
      total:
        metric: http_requests_total{job="backend"}

この構造は、手動でPromQLを書いて28日間のレートを計算するよりもはるかに明快です。

統合と実際のモニタリング

Pyrraはデータを保存せず、Ruleを生成するだけです。Kubernetesを使用している場合、PyrraはOperatorを介してPrometheusRuleオブジェクトを自動生成します。従来のサーバー構成では、PyrraのUIからRuleをコピーしてPrometheusの設定ファイルに貼り付けるだけです。

http://localhost:9099にアクセスすると、以下の重要な指標が表示されます。

  • Objective: 目標値（99%）。
  • Availability: 現在稼働しているシステムの実際のパフォーマンス。
  • Error Budget Remaining: SLAに違反するまでに残っているエラー予算の割合。

この仕組みにより、障害を早期に発見できるようになります。Burn Rateを確認するだけで、システムが完全にダウンしていなくても、予算が「流出」していることがすぐにわかります。

Google標準に基づいたアラートの自動化

PyrraはGoogleの「Multi-window Multi-burn-rate」の哲学を採用しています。1つのリクエストエラーで即座にアラートを出すのではなく、予算の消費速度に基づいてアラートを送信します。

  • Critical Alert: 予算の消費が非常に速く、対処しないと数時間以内に予算を使い果たしてしまう場合.
  • Warning Alert: 消費速度は遅いものの、数日以内にSLOに影響を与える可能性がある場合。

このアプローチにより、オンコールエンジニアを疲弊させる「フラッピングアラート（頻繁に発生・解消を繰り返す不要なアラート）」を完全に排除できます。

終わりに

SLOを導入することで、DevチームとOpsチームが共通の言語で話せるようになります。「CPU使用率80%は重要か？」と議論する代わりに、Error Budgetを確認しましょう。予算が残っていれば自信を持ってデプロイし、枯渇しそうであれば一旦止めてシステムの最適化に注力します。

Pyrraは、PromQLに精通していなくても運用を標準化できる強力なツールです。10個以上のマイクロサービスを管理しているなら、ぜひ今日から試してみてください。

Share:
Tags: