SLO管理比較：Pyrra vs Sloth vs OpenSLO でSLI/SLOを自動化する
オープンソースラボ編集部 ・ 2026年6月17日
SLO管理比較：Pyrra vs Sloth vs OpenSLO でSLI/SLOを自動化する
📊 サービスレベル目標（SLO）をコードで管理するツール。Pyrra・Sloth・OpenSLOの特徴と選択基準を解説します。
SLO管理ツールとは
サービスレベル指標（SLI）とサービスレベル目標（SLO）を宣言的に定義し、Prometheusのアラートルールを自動生成するツールです。エラーバジェットの可視化でSREチームの意思決定を支援します。
主要ツール比較表
| 項目 | Pyrra | Sloth | OpenSLO |
|---|---|---|---|
| ライセンス | Apache 2.0 | Apache 2.0 | Apache 2.0 |
| 出力 | PrometheusRule | PrometheusRule | 各種形式 |
| UI | ◎ 組み込み | △ | △ |
| Kubernetes CRD | ◎ | ◎ | ○ |
| 複数ウィンドウ | ◎（5m/1h/1d） | ◎ | ◎ |
| エラーバジェット表示 | ◎ | △ | △ |
| YAML仕様 | 独自 | 独自 | 標準仕様 |
| Grafana統合 | ◎ | ◎ | ○ |
各ツールの特徴
Pyrra
SLOをKubernetes CRDで定義し、PrometheusRuleを自動生成するコントローラー。組み込みUIでエラーバジェットをリアルタイム表示できます。
主な特徴:
- Kubernetes Operatorとして動作
- 組み込みWebUIでSLO状態・エラーバジェットを可視化
- マルチウィンドウアラーティング（5分/1時間/1日）を自動設定
- SLOの達成率をPrometheusメトリクスとして公開
# Pyrra SLO定義
apiVersion: pyrra.dev/v1alpha1
kind: ServiceLevelObjective
metadata:
name: api-availability
namespace: monitoring
spec:
target: "99.9" # 99.9%の可用性目標
window: 28d # 28日間のウィンドウ
description: "APIサーバーの可用性"
indicator:
ratio:
errors:
metric: http_requests_total{job="api",code=~"5.."}
total:
metric: http_requests_total{job="api"}
---
# レイテンシーSLO
apiVersion: pyrra.dev/v1alpha1
kind: ServiceLevelObjective
metadata:
name: api-latency
spec:
target: "99"
window: 28d
indicator:
latency:
success:
metric: http_request_duration_seconds_bucket{job="api",le="0.5"}
total:
metric: http_request_duration_seconds_count{job="api"}
# Helmでインストール
helm repo add pyrra https://pyrra-dev.github.io/pyrra/helm-chart
helm install pyrra pyrra/pyrra --namespace monitoring --set apiServer.enabled=true
向いているケース: UI重視・エラーバジェット可視化・Kubernetes環境
Sloth
CLIとKubernetes Operatorの両方で使えるSLOジェネレーター。YAMLからPrometheusRuleを1コマンドで生成します。
主な特徴:
- CLIモードとKubernetes Operatorモードを選べる
- カスタムSLIプラグインで独自指標に対応
- Grafanaダッシュボードの自動生成
- OpenSLO仕様への変換が可能
# sloth.yaml
version: "prometheus/v1"
service: "my-api"
slos:
- name: "requests-availability"
description: "APIリクエストの可用性"
objective: 99.9
sli:
events:
error_query: sum(rate(http_requests_total{job="api",code=~"5.."}[{{.window}}]))
total_query: sum(rate(http_requests_total{job="api"}[{{.window}}]))
alerting:
name: MyAPIHighErrorRate
labels:
team: backend
annotations:
summary: "APIエラー率がSLOを超過しています"
page_alert:
labels:
severity: critical
ticket_alert:
labels:
severity: warning
# CLIで PrometheusRule を生成
sloth generate -i sloth.yaml -o rules.yaml
# Kubernetes に適用
kubectl apply -f rules.yaml
# Operatorとして常時稼働
helm repo add sloth https://slok.github.io/sloth
helm install sloth sloth/sloth --namespace monitoring
向いているケース: CLI中心・CI/CDでPrometheusRule生成・非K8s環境も
OpenSLO
ベンダー中立のSLO仕様標準。Dynatrace・Datadog・SumoLogic等が採用している共通フォーマットで、複数ツールへの変換が目的です。
主な特徴:
- ベンダー中立の標準仕様（CNCF Sandboxプロジェクト）
- osl CLIで複数バックエンド（Prometheus/Datadog/Dynatrace）へ変換
- SlothのOpenSLOフォーマット入力をサポート
- コミュニティ主導の拡張仕様
# OpenSLO仕様
apiVersion: openslo/v1
kind: SLO
metadata:
name: api-availability
displayName: APIサーバー可用性
spec:
description: "HTTPリクエストの成功率"
service: my-api
indicator:
metadata:
name: api-good-requests
spec:
ratioMetric:
counter: true
good:
metricSource:
type: Prometheus
spec:
query: http_requests_total{job="api",code!~"5.."}
total:
metricSource:
type: Prometheus
spec:
query: http_requests_total{job="api"}
timeWindow:
- duration: 28d
isRolling: true
objectives:
- displayName: "99.9%可用性"
target: 0.999
向いているケース: マルチプロバイダー・将来の移植性・標準仕様重視
選択ガイド
| 状況 | 推奨 |
|---|---|
| エラーバジェットUI・K8s | Pyrra |
| CLI/CI統合・Prometheus生成 | Sloth |
| マルチプロバイダー・標準仕様 | OpenSLO |
内部リンク
外部リソース
FAQ
Q. SLOを設定するには何のメトリクスが必要ですか？
最低でも「リクエスト総数」と「エラー数」のPrometheusメトリクスが必要です。latency SLOにはヒストグラム（_bucket）が必要です。
Q. エラーバジェットとは何ですか？
SLOを達成するために許容できるエラーの総量です。例：99.9%SLOなら28日間で約40分のダウンタイムが許容されます。このバジェットを使い切ると新機能リリースを止める等の判断に使います。
Q. アラートのPagerDuty連携はどうやりますか？
Pyrra/SlothはPrometheusRuleを生成するため、AlertManagerのPagerDutyレシーバーに繋ぐことで自動的に連携できます。
Q. 複数サービスのSLOを一元管理したい場合は？
Pyrraは複数SLOの一覧UIを提供しています。Grafanaダッシュボードと組み合わせて「SLOダッシュボード」を作るのが一般的なアプローチです。