アラートルール
コンテナ終了、ヘルスチェック、リソース閾値、再起動バーストのための型付きアラートルールを作成します。
アラートルールはDockerイベントとリソースメトリクスを通知チャンネルに接続します。ルールが発火すると、Dockermanはそのルールにバインドされたすべてのチャンネルにメッセージをブロードキャストします。
プリセットルール
すぐに役立つカバレッジを 1 クリックで利用できるよう、2 つのルールが事前設定されて同梱されています。
| プリセット | 種別 | 動作 |
|---|---|---|
| Restart loop | restart_burst | 任意のコンテナが 5 分以内に 3 回以上再起動したときに発火します。 |
| Container crash (non-zero exit) | container_exit_non_zero | 任意のコンテナが 0 以外のステータスで終了するたびに発火します。 |
両プリセットは 無効状態 で同梱されています — 対象範囲と通知チャンネルが環境に合うことを確認してから、アラートページで有効化してください。有効化後は他のルールと同じように動作し、フィールドの編集、ターゲットの変更、チャンネルのバインド、再度の無効化が可能です。
プリセットは誤った削除から保護されています。削除した場合でも、アラートページの デフォルトにリセット アクションで出荷時と同じ状態に戻せます。
両プリセットはデフォルトで すべてのコンテナ を対象とします。環境が騒がしい場合は、有効化する前にターゲットを Compose プロジェクトや特定のコンテナに絞り込んでください。
ルールタイプ
Dockermanには4つの型付きルール種別が同梱されています。それぞれがUIに専用のフォームを持ち、自由形式の式ではないため、セットアップは迅速で間違いは起きにくくなっています。
コンテナ終了（0以外）
コンテナのdieイベントが0以外の終了コードを報告したときに発火します。
データソース： Dockerイベント
ユースケース： 予期しないクラッシュ、失敗したエントリーポイント、またはOOMキルを捕捉します。
ターゲットセレクター以外の追加フィールドは必要ありません。
ヘルス異常
コンテナのヘルスチェックステータスが他の状態からunhealthyに遷移したときに発火します。
データソース： Dockerイベント
ユースケース： まだ実行中だがヘルスチェックに合格しなくなった劣化サービスを検出します。
ターゲットセレクター以外の追加フィールドは必要ありません。
リソース閾値
メトリクスが持続的な期間、閾値を超えたときに発火します。
データソース： Stats時系列ストア
フィールド：
| フィールド | 説明 |
|---|---|
| メトリクス | cpu または mem_percent |
| 演算子 | > または >= |
| 閾値 | 比較対象のパーセンテージ値 |
| 期間 | メトリクスが発火前に閾値を超え続ける必要がある秒数 |
ユースケース： メモリリーク、暴走CPU、またはリソース制限に達しているコンテナを発見します。
再起動バースト
単一のコンテナが時間ウィンドウ内で閾値回数を超えて再起動したときに発火します。
データソース： Dockerイベント
フィールド：
| フィールド | 説明 |
|---|---|
| カウント | トリガーする最小再起動回数 |
| ウィンドウ | 秒単位の時間ウィンドウ |
ユースケース： コンテナが再起動と失敗を繰り返すクラッシュループシナリオを検出します。
ターゲットセレクター
4つのルールタイプすべてが同じターゲットセレクターを共有するため、一貫した方法で監視対象を選択できます。
| スコープ | 動作 |
|---|---|
| すべてのコンテナ | ルールは接続されたホスト上のすべてのコンテナに適用されます |
| Composeプロジェクト | ルールは特定のComposeプロジェクトに属するすべてのコンテナに適用されます |
| 特定のコンテナ | ルールは選択したコンテナのみに適用されます |
ルールの作成
アラートページを開く
サイドバーまたはSpotlightからアラートページに移動します。
ルールを追加をクリック
ルールタイプを選択し、フォームフィールドに入力します。
ターゲットを設定
このルールがすべてのコンテナ、Composeプロジェクト、または特定のコンテナを監視するか選択します。
通知チャンネルをバインド
アラートを受信する通知チャンネルを1つ以上選択します。
クールダウンと重大度を設定
繰り返しアラートを防ぐためのクールダウン期間を設定し、フィルタリング用の重大度レベルを選択します。
保存して有効化
ルールは即座に評価を開始します。
クールダウンとサイレンスウィンドウ
クールダウン
ルールが発火した後、クールダウン期間（ルールごとに設定可能）に入ります。クールダウン中は、条件が真のままでもルールは再度発火しません。これにより、複数のコンテナが同時に失敗したときの通知ストームを防ぎます。
サイレンスウィンドウ
ルールが発火すべきでない時間ウィンドウを設定します。例えば、計画メンテナンスウィンドウの「02:00 - 05:00」などです。ルールはサイレンスウィンドウ中も評価を続けますが、通知を抑制します。
重大度レベル
各ルールには重大度：info、warning、または criticalがあります。重大度はフィルタリングと履歴検索用のメタデータです。ルーティングには影響しません。重大度に関係なく、すべてのバインドされたチャンネルがすべてのアラートを受信します。
最近のアラートフィード
アラートページには、ルールが発火したすべての履歴を示す最近のアラートフィードが含まれます。
- コンテナ名
- 発火のローカル時刻
- ルール名と種別
- コンテキスト（メトリクス値、終了コードなど）
- どのチャンネルが通知を受信したか
リストは標準化されたデータテーブルパターンを使用しているため、列幅はセッション間で維持され、上部のツールバーからすべてのフィールドを横断検索できます。
ルーティングモデル
各ルールは通知チャンネルのリストに直接バインドされます。ルールが発火すると、メッセージはそのリストのすべてのチャンネルに送信されます。このバージョンにはグローバルなルーティングテーブルや重大度ベースのチャンネルマッピングはありません。
ヒント
すべてのコンテナを対象とし、プライマリ通知チャンネルにバインドされたcontainer_exit_non_zeroルールから始めてください。これはゼロ設定で最も一般的な失敗モードを捕捉します。
- 誤検出を避けるため、少なくとも60秒の期間を持つ
resource_thresholdを使用してください。 - 低いカウント（例：300秒で3回の再起動）で
restart_burstを組み合わせて、クラッシュループを早期に捕捉してください。 - クールダウン期間を調整するために定期的にアラート履歴を確認してください。同じインシデントの繰り返しエントリが見られる場合は、クールダウンを増やしてください。