Monitors と SLOs

Monitors

モニターは 1 分ごとにクエリを評価し、しきい値を超えると通知します。Observability → Monitors、API、またはリポジトリ内のファイルで作成します。

各モニターには、期間(既定は 5 分)、頻度(1 分)、遅れて届くデータのための評価の遅延(60 秒)、アラートと警告のしきい値、そして任意の回復しきい値があります。回復しきい値により、境界付近を行き来する値で状態が何度も切り替わることを防ぎます。groupBy は、すべてに対して 1 つではなく、グループごと(たとえばルートごと)に 1 つのアラートを送ります。noData は、空の期間を何とみなすかを決めます。無視する(既定)、アラートする、解決するのいずれかです。行のないカウントは 0 なので、失敗しなくなったルートは回復します。

メッセージはテンプレートです。{{value}}、{{threshold}}、{{state}}、{{monitor.name}}、{{project}}、{{link}}、そして {{route}} のような各グループの次元を使えます。

モニターはプロジェクトあたり Free プランで 10 件、Pro プランで 500 件です。

通知先

モニターは、Runlot Errors と同じプロジェクトのアラート通知先に通知します。メール、Slack、Webhook、PagerDuty、Opsgenie です。Slack や Webhook の URL、PagerDuty のルーティングキー、Opsgenie の API キー(EU インスタンスの場合は先頭に eu:)は保存時に暗号化して保存され、二度と表示されません。外部の通知先は、有効にしてアラートのデータを受け取ることを承認するまでオフのままです。モニターが回復すると、PagerDuty のインシデントは自動的に解決し、Opsgenie のアラートは自動的に閉じます。

モニターに頼る前に、モニターのページからテスト通知を送ってください。

ダウンタイム

ダウンタイムは、ID またはタグでモニターを一度だけ、あるいは毎日・毎週のスケジュールでミュートします。モニターは、デプロイのたびに N 分間自分自身をミュートすることもできます(muteAfterDeployMinutes)。ミュートは通知を捨てるのではなく、後回しにします。ダウンタイムの終了時にまだアラート中のグループがあれば、そのときにアラートが送られます。すでに送ったアラートの回復は、ミュートされることがありません。

SLOs

SLO は、7 日、30 日、または 90 日にわたる目標です。

• リクエストベース: 5xx でなく、レイテンシの目標内に完了したリクエストを正常とみなします。目標は 50、100、200、300、500、750、1000、1500、2000、3000、5000、10000 ms のいずれかで、件数は推定ではなく正確な値です。対象は最大 50 ルートに絞れます。
• モニターベース: モニターがすべてのグループで OK だった時間の割合です。

各 SLO には、残りのエラーバジェットとバーンのグラフが表示されます。slo_burn モニターは 2 つの期間を同時に使ってバーンレートでアラートするため、速いバーンは呼び出しを行い、遅いバーンで誰かを起こすことはありません。既定では、1 時間と 5 分で 14.4 倍がアラート、6 時間と 30 分で 6 倍が警告です。

SLO はプロジェクトあたり Free プランで 1 件、Pro プランで 50 件です。リクエストベースの SLO は、作成した時点からリクエストを数えます。

合成チェック

合成チェックは、スケジュールに従ってコントロールプレーンからプロジェクト自身の HTTPS アドレスの 1 つを呼び出し、応答を確認します。パーク中のアプリはウェイクされますが、それがこの機能の目的です。

runlot errors uptime add https://my-app.me.runlot.app/health 5
runlot errors uptime list
runlot errors uptime runs <id>

• 1 分、5 分、15 分ごとに実行します。Free プラン: チェック 1 件、最短 15 分ごと。Pro プラン: チェック 20 件、1 分ごと。
• ステータス、ヘッダー、本文、JSON パス($.status)、レイテンシに対するアサーションを指定できます。リダイレクトはたどりません。3xx がそのまま応答になります。
• 複数ステップのチェックは最大 10 個のリクエストを順に実行し、値を引き継ぎます。あるステップで JSON パスやヘッダーからトークンを取り出し、次のステップで {{token}} として使えます。secret としたヘッダーは暗号化して保存されます。
• 2 回続けて失敗するとイシューが 1 件開き、次の成功で解決します。uptime モニターは結果をアラートに、モニターベースの SLO は稼働率の目標に変えます。
• チェックのトラフィックには synthetic のタグが付き、既定で APM の数値から除外されます。

Pro プランでは、込みの 20 件を超えて 1 分間隔で実行するチェックは、チェックあたり月 $1.00 で日割り課金されます。

コードとしてのモニター

モニターはリポジトリの .runlot/monitors/ の下で管理できます。そこにある各 .json ファイルには 1 つのモニターまたはモニターの配列を書き、デプロイが公開されるときに適用されます。

{
  "name": "Checkout 5xx",
  "type": "apm",
  "query": { "metric": "error_rate", "filter": { "route": "/checkout" } },
  "options": {
    "windowMinutes": 5,
    "thresholds": { "alert": 5, "warn": 2 },
    "groupBy": ["route"]
  },
  "message": "Checkout errors at {{value}}% on {{route}}. {{link}}",
  "destinations": ["on-call"]
}

• key のない単独のモニターは、ファイル名(checkout-5xx)をキーにします。配列では、それぞれに固有の key が必要です。次のデプロイは、このキーで同じモニターを見つけます。
• 通知先は ID ではなく名前で指定するため、ファイルに秘密情報は含まれません。
• 空の .runlot/monitors/ ディレクトリは、リポジトリから作られたすべてのモニターを削除します。ディレクトリがなければ何も変わりません。
• リポジトリから作られたモニターはダッシュボードでは読み取り専用です。ファイルを変更してデプロイしてください。プレビューデプロイではモニターは適用されません。
• Monitors ページの Export、または GET …/observability/monitors/export で、ダッシュボードで作ったモニターをこのファイル形式で取得でき、そのままコミットできます。