アラート
関数が誤動作したときに通知される方法: 監視できるメトリクス、ルールのチェック方法、HTTP 経由でのルールの管理方法。
5 分 読み取り·レベル 中間·2026/10/12 に改訂
この英語のテキストはフランス語のオリジナルから自動的に生成されたもので、まだレビューされていません。
このページは自動翻訳されました。英語版が正式です。
#
作成
1. ルールを作成する
アラート ルールは、service_role キーを使用して HTTP 経由で管理されます。 SDK にはそれらに対するメソッドがありません。
#
参考資料
2. メトリクス、条件、チャネル
| フィールド | 許可される値 |
|---|---|
metric | error_rate、 latency_p95、 job_failures、 low_disk、 ai_quota、 anomaly_detection、または log_pattern:<service>:<regex> |
condition | gt、 lt、 eq、 match、 auto |
channel | email、 webhook、 slack |
threshold | 数字 |
destination | 電子メール アドレス、または Webhook または Slack フックの URL |
log_pattern は、1 つのサービスのログで正規表現 log_pattern:functions:timeoutを監視します。不明な値は 400 を返し、受け入れられる値をリストします。 metric: "cpu"の実際の答え:
#
行動
3. ルールのチェック方法
- サービスは、有効なすべてのルールを 1 分に 1 回チェックします。
- 数値メトリクスは Prometheus から読み取られます。
log_patternルールは Loki をクエリします。各クエリには 5 秒の制限があります。 1 つのプロジェクトが失敗しても、他のプロジェクトは引き続きチェックされます。 - ルールが起動すると、サービスは
last_triggered_atを設定し、イベントを記録し、選択したチャネルで配信するためにイベントを公開します。 - 無効にしたルールは保持されますが、チェックはされません。
配信は展開に応じて異なります
アラートには関数サービスから到達できる Prometheus と Loki が必要で、電子メール チャネルには電子メール プロバイダーが必要です。これらのない開発スタックでは、ルールは保存されますが、起動できません。
#
操作する
4. ルールと履歴の管理
| アクション | リクエスト |
|---|---|
| リストルール | GET /v1/functions/alerts |
| 有効または無効にする | PATCH /v1/functions/alerts/{id} と {"enabled": false} |
| 削除 | DELETE /v1/functions/alerts/{id} |
| 1 つのルールの履歴 | GET /v1/functions/alerts/{id}/events |
| すべてのルールの履歴 | GET /v1/functions/alerts/events |
イベントには alert_rule_id、 event_type、 triggered_value、 message および created_atがあります。履歴ルートは limit および offsetを受け入れます。すべてのルートには service_role キーが必要です。
最終更新日 · 2026/10/12