SLO の作成¶
SLO を作成すると、サービスに測定方法、評価期間、目標を設定し、達成率が低下したときにアラートを受け取ることができます。作成には SLO 設定管理権限が必要です。モニタータイプを選択する場合は、先に対応するモニターを作成してください。メトリクスタイプを選択する場合は、先にビジネス数量メトリクスを現在のワークスペースに収集してください。
モニター > SLO に移動し、SLO を作成をクリックします。
SLO の設定¶
- SLI タイプを選択します。モニタータイプはSLI モニターを関連付け、メトリクスタイプは合計数と成功数のクエリを設定します。
- 評価期間、検出頻度、達成率の目標と最低目標を設定します。
- 必要に応じてタグを追加し、アラートポリシーを関連付けてから保存します。
評価期間と検出頻度¶
評価期間は各評価ラウンドの対象期間を決定し、直近 7 日間または 30 日間に対応しています。検出頻度は SLO の再計算と検出の間隔を決定し、5 分または 10 分に対応しています。たとえば、30 日間と 5 分を選択した場合、5 分ごとに過去 30 日間のサービスパフォーマンスを評価することを意味します。参照元モニターは、それぞれの検出頻度で引き続き実行されます。
達成率：目標と最低目標¶
目標と最低目標は、同じ実際の達成率に対して設定する 2 つのしきい値で、同じ評価期間を共有します。
- 目標：サービスに期待する信頼性の水準です。たとえば、目標が 99.9% の場合、モニタータイプではアップタイムの割合が 99.9% に達することが求められ、メトリクスタイプでは合計数に占める成功数の割合が 99.9% に達することが求められます。モニタータイプの初期エラーバジェットもこの目標から計算されます。
- 最低目標：サービスが許容できる達成率の下限です。この下限を下回ると緊急イベントが生成され、より深刻なサービス品質の低下を検知するために使用されます。
設定は 0 < 最低目标 < 目标 < 100 を満たす必要があります。たとえば、目標が 99.9%、最低目標が 99.5% の場合：
| 実際の達成率 | 検出結果 |
|---|---|
| ≥ 99.9% | 目標を達成。 |
| ≥ 99.5% かつ < 99.9% | 警告イベントを生成。 |
| < 99.5% | 緊急イベントを生成。 |
SLO は自身の達成率に基づいてイベントを生成します。通知を送信する必要がある場合は、アラートポリシーを関連付け、ポリシーで対応するイベントレベルの通知先を設定してください。通知時間や繰り返し通知などの動作はポリシーに従って実行されます。
名前、SLI タイプ、目標、最低目標は保存後に固定されます。その他の設定の編集方法については、SLO の管理を参照してください。
タグ¶
ページ左上隅のTags を追加でグローバルタグを関連付けると、ビジネスやチームなどで SLO を分類・フィルタリングできます。これらのタグは、この SLO がその後生成する検出イベントの df_label フィールドに書き込まれ、イベントのフィルタリングやデータ連携に使用できます。
タグは SLO とそのイベントを識別するために使用します。以下のグループ化ディメンションは、参照元モニターのイベント内のフィールド値に基づいて達成率を個別に計算するために使用します。
モニタータイプ：SLI の関連付け¶
SLI（サービスレベル指標）は、サービスの品質を測定する指標です。モニタータイプでは、SLI 設定項目で 1 つ以上の既存モニターを選択します。システムは、これらのモニターに対応するアップタイムの割合でサービス品質を測定します。
同じ評価対象を代表できるモニターを選択してください。たとえば、決済サービスを評価する場合は、「決済 API の応答が遅い」と「決済リクエストのエラー率が高い」という 2 つのモニターを関連付けることができます。いずれかのモニターで異常が発生すると、対応する異常時間が SLO に計上されます。同じ時間帯の複数の異常は合算されます。減点、達成率、エラーバジェットの関係については、モニタータイプの計算説明を参照してください。
グループ化ディメンション¶
グループ化ディメンションは、どのビジネスオブジェクトごとに評価するかを決定します。project（プロジェクト）、env（環境）、service（サービス）に対応しており、1 つ以上のフィールドを選択できます。
| 設定方法 | 統計結果と適用シーン |
|---|---|
| 空欄 | 関連付けた SLI を 1 つのまとまりとして扱い、異常時間を合算して 1 つの達成率を計算します。サービスやビジネス全体のパフォーマンスを評価する場合に適しています。 |
service を選択 |
サービスごとに計算します。たとえば、payment-api と order-api にそれぞれ達成率が算出され、あるサービスの異常はそのサービスの結果に計上されます。 |
env、service を選択 |
実際のフィールド値の組み合わせごとに計算します。たとえば、prod + payment-api、staging + payment-api のように、同じサービスを環境別に評価する場合に適しています。 |
グループ化する前に、参照元モニターが生成する異常イベントに選択したフィールドとその値が含まれていることを確認してください。たとえば、モニターの検出ディメンションで env、service を渡します。システムはこれらのフィールドに基づいて異常を分類します。選択したフィールドのいずれかが欠落しているイベントは無視され、統計の完全性に影響します。正常なグループの補完には、アプリケーションパフォーマンスモニタリング（APM）の直近のトレースデータが使用されます。対応するビジネスディメンションがトレースとともに報告されていることを確認する必要があります。
SLO 詳細または SLO チャートで、各グループ化ディメンションの具体的な値を選択すると、対応する組み合わせの結果を確認できます。各組み合わせは独立して異常時間を累積します。プロジェクト全体を評価する必要がある場合は、project のみでグループ化した SLO を作成してください。グループ化設定を変更すると、次の検出周期から有効になり、履歴データは元のグループ化のまま保持されます。
メトリクスタイプ：合計数と成功数の設定¶
合計数と成功数にそれぞれクエリを設定します。ビジュアルメトリクスクエリ、DQL、PromQL に対応しています。2 つのクエリは、同じビジネス範囲、計量単位、評価期間をカバーする必要があります。成功数は合計数のうち成功条件を満たす数で、总数 > 0、0 ≤ 成功数 ≤ 总数 を満たす必要があります。
各クエリでは、各時系列を 1 つの期間数量値に集約する必要があります。複数の時系列が返された場合、システムはその数量を合算します。異なるビジネス範囲を個別に評価する必要がある場合は、それぞれ SLO を作成してください。
DQL の例：決済リクエスト成功率¶
メジャーメント payment_requests において、request_count が各収集間隔で新規に発生したリクエスト数を記録し、service がサービスを識別し、result がリクエスト結果を識別するとします。payment-api のリクエスト成功率を評価するには、次のように設定できます。
合計数：
成功数：
メジャーメント、フィールド、タグを実際に収集した内容に置き換えてください。時間範囲は SLO の評価期間によって制御されます。直近 30 日間の合計数が 100,000、成功数が 99,950 の場合、達成率は 99,950 ÷ 100,000 × 100% = 99.95% となります。
PromQL の例：累積カウンター¶
PromQL はインスタントクエリとして実行されるため、式内で期間の統計を完了する必要があります。たとえば、payment_requests_total がリクエスト数を累積し続ける場合、評価期間が 30 日のときは increase を使用してその期間の増分を計算できます。
合計数：
成功数：
メトリクス名とタグを実際に収集した内容に置き換えてください。評価期間を変更する場合は、2 つの式の時間範囲も合わせて調整してください。たとえば、[30d] を [7d] に変更します。
合計数と成功数には、期間内のビジネス数量を使用してください。所要時間、パーセンタイル、計算済みの成功率は、他の検出方法に適しています。
作成後、検出が有効な結果を生成するまで待つ必要があります。データなし、合計数が 0、クエリ失敗が発生した場合は、SLO 詳細の説明に従ってデータを確認できます。