アラート監視の対象範囲

このページでは、Dockerman のコンテナアラートが監視しているタイミング、各エンジンで検出できる内容、通知について Dockerman が把握できること・できないことを説明します。

アラートルールの評価は、Dockerman のウィンドウではなく、このコンピュータ上の Dockerman バックグラウンドサービス（デーモン）が行います。1 つのホスト上の 1 つのコンテナで続いている障害が インシデント です。インシデントは開始時に一度だけ通知し、開いている間はリマインダーを送ることがあり、コンテナが再び安定したと確認されたとき、意図的に停止されたとき、削除されたとき、またはルールがオフになったときに終了します。0 以外の終了コードのような単発の事実は アラートイベント です。

組み込みルールは、オンにするまですべてオフです。例外は、古い通知設定のバージョンからのアップグレードです。そこでデスクトップ通知がオンだった場合、Container Unexpected Exit は「コンテナクラッシュ」をオンにし、Container Health Check Failed は「サービス応答なし」をオンにします。

概要

監視が途切れても、それを復旧とみなすことはありません。未監視のインシデントは開いたままで、リマインダーも続きます。Dockerman がコンテナを再び確認できるようになってから、ルールの安定間隔の全期間にわたって安定した状態が続いて初めて、インシデントは復旧します。

監視対象のホスト

デーモンは、次のホストにあるすべてのコンテナを監視します。

• LOCALHOST（Dockerman が動作しているコンピュータ）
• 保存済みホストのうち、（Fleet ページの）この Host を観測 スイッチがオンのもの

保存済みの SSH ホストは、デーモンが何も尋ねずに接続できるよう、保存済みの認証情報と固定済み（信頼済み）のホストキーの両方がある場合にのみ監視されます。プレーンな TCP ホストにはどちらも不要です。デーモンはこれらのホストに自力で接続するため、Dockerman のウィンドウを開いておく必要はありません。

それ以外のホストは、まったく監視されません。アラートページの ホストのカバー範囲 には、各ホストの状態が「監視中」「一部制限付きで監視中」「非対応」「監視対象外」のいずれかで、理由とともに表示されます。

Dockerman のウィンドウとデーモン

ウィンドウを閉じてトレイに常駐

メインウィンドウを閉じると、Dockerman はメニューバーまたはシステムトレイに隠れます。アプリは動作し続けるため、監視とシステム通知は通常どおり機能します。通知をクリックすると、Dockerman が前面に表示されます。

トレイのないデスクトップ（一部の Linux デスクトップ）では、ウィンドウを閉じるとアプリが終了します。次のセクションを参照してください。

Dockerman を終了したがデーモンは動作中

デーモンは別のプロセスです。Dockerman を終了しても（トレイメニューの Dockerman を終了 またはアプリの終了コマンド）デーモンは動作し続けるため、監視、インシデントの開始・終了、外部チャンネル（Telegram、Ntfy、Gotify、Discord、Webhook）への通知送信は続きます。

システム通知にはアプリが必要です。アプリが終了している間、システム通知はそれぞれ、インシデントまたはアラートイベントの配信ステータスに 未配信：アプリが起動していません と記録されます。Dockerman を再び開いても、見逃したシステム通知は再送されません。開いているインシデントは、アラートページ、コンテナ一覧、コンテナの詳細ページに表示されます。

Dockerman の終了中にも障害の通知を受け取るには、ルールに外部チャンネルを追加してください。

デーモンの停止、再起動、ログアウト

Dockerman を開くとデーモンが起動します（dockerman コマンドラインツールでも起動します）。Dockerman はログイン時に自動起動しません。コンピュータの再起動後、ログアウト後、またはデーモンの停止後は、Dockerman を再び開くまで何も監視されません。その空白期間中に始まって終わった障害は、報告されません。

デーモンが起動すると、次のことを行います。

• まだ開いているインシデントをすべて、最後の確認時点から未監視としてマークします。
• 各ホストのすべてのコンテナを、あらゆる状態で一度だけ一覧取得し、実行中のものを inspect して、新しい基準にします。
• コンテナがホスト上に存在しなくなった、開いているインシデントは、通知なしで「削除」として終了します（停止中のコンテナはホスト上に残るため、インシデントも維持されます）。
• クラッシュを繰り返しているコンテナは、見ていない再起動のタイムスタンプを作り出すことなく、再び検出されます（Docker では継続的な再起動サイクルによります。エンジン対応状況を参照）。

スリープ

コンピュータのスリープ中、デーモンは一時停止し、何も監視しません。

復帰時に、デーモンは壁時計が単調時計より 1 回のサンプリング間隔（5 秒）を超えて進んでいることに気づきます。すると、すべてのホストをいったん失い、その後復旧したものとして扱います。開いているインシデントはスリープ前の最後の確認時点から未監視としてマークされ、復旧には復帰後の安定間隔の全期間が必要です。システム時計を手動で変更した場合も、同じ扱いになります。

この検出は、スリープ中に単調時計が止まることを前提としています。これは macOS と Linux での動作です。Windows では検証していません。

ホストの切断

デーモンがホストのイベントストリームを失った場合、またはホストをサンプリングできない場合は、次のようになります。

• そのホストの開いているインシデントは未監視としてマークされます（詳細のバナーに「… から未監視」と表示されます）。
• 障害を復旧とみなすことはありません。
• ホスト単位のアラートは出ず、障害そのものに対するコンテナのインシデントも開始されません。Dockerman にはホストの接続性アラートがありません。

イベントストリームが復旧すると、デーモン起動時と同じ基準により、空白期間中に削除されたコンテナのインシデントが「削除」として終了します。

空白期間中に起きた再起動は、デーモンが再び inspect したときに読み取るコンテナの再起動回数からのみ把握できます。2 回の inspect の間隔がルールの期間内に収まる場合にのみ、再起動ループルールのカウントに含まれます。そうでない場合は「未監視中に N 回再起動」と表示され、ルールは発火しません。

インシデントが未監視の間も、リマインダーは続きます。

エンジン対応状況

Kubernetes クラスターはアラートの対象外です。

Docker

再起動ループは、次の 2 種類の根拠のどちらかで開始されます。

• カウントされた再起動。 期間内に設定した回数の再起動があること。タイムスタンプ付きのイベント、または、間隔が期間以内の 2 回の inspect の間での再起動回数の増加によって裏付けられます。
• 継続的な再起動サイクル。 コンテナが、安定間隔のあいだ稼働し続けることなく、設定した時間（デフォルトは 120 秒）以上再起動を繰り返しているのが確認されること。監視開始時にすでにクラッシュを繰り返していたコンテナも検出できます。

SIGHUP のようなリロードシグナルが、次の本当のクラッシュを隠すことはありません。

Podman

• 継続的な再起動サイクルのトリガーはありません。 Podman の Docker 互換 inspect は再起動中の状態を報告しません。再起動ループは、カウントされた再起動からのみ検出されます。
• すべての kill が意図的なものとして扱われます。 Podman の kill イベントにはシグナルが含まれないため、podman kill 後の終了はすべて意図的な停止として扱われ、上記のリロードシグナルに関する保証は Docker のみです。
• podman stop がインシデントを「停止」として終了するのは、再起動ポリシーが always または unless-stopped の場合のみです。 Podman は停止を、停止イベントではなく、終了に続くクリーンアップとして報告します。これらのポリシーではエンジンがあらゆる終了のたびに再起動するため、再起動ではなくクリーンアップが起きた場合はコンテナが停止されたことを意味します。on-failure や no では、エンジンが再起動しないクラッシュの後にも同じイベントが続くことがあるため、コンテナが再び安定して動作するか、削除されるか、ルールがオフになるまで、インシデントは開いたままです。
• ヘルスは inspect で取得します。 Podman はヘルスチェックの実行ごとに結果なしで報告するため、デーモンはコンテナを inspect してヘルスの状態を確認します。同じ状態の繰り返しの報告は、1 回の変化として数えます。

Apple Container

Apple Container にはイベントストリームがありません。デーモンは Apple Container のホストを監視せず、アラートページでは「非対応」と表示されます。

障害とみなされるもの

• 意図的な操作は、予期しない再起動として数えられません。 Dockerman、Docker CLI、スクリプトからのコンテナの再起動、停止とその後の起動、再起動ポリシーのないクラッシュ済みコンテナの起動が該当します。
• 意図的な停止は、開いているインシデントを「停止」として終了します。 復旧通知は送りません。Docker では docker restart が意図的な停止から始まるため、そのコンテナの開いているインシデントは「停止」として終了します。
• 実行中のコンテナに対する docker rm -f は、インシデントを「削除」ではなく「停止」として終了します。 削除の前に強制 kill が確認されるためです。
• 再作成されたコンテナは新しいインスタンスです。 同じ名前で再作成されたコンテナは、インシデントやクールダウンの履歴なしで始まります。
• アイドルはハングではありません。 CPU 使用率が低いことや、ログが静かなことは、応答なしとはみなされません。応答状況はエンジンのヘルスチェックまたはサービスプローブからのみ判断されます。どちらもないコンテナは、詳細ページに「応答状況は不明」と表示され、監視を有効にする方法が案内されます。
• サービス応答なし は、エンジン自身のヘルスチェックの再試行回数と開始猶予期間を、猶予期間として使います。任意の最短異常時間（デフォルトはなし）は、連続した監視のあいだだけ計測されます。デーモンの再起動、ホストの切断、スリープの後は、最初からやり直しです。
• サービス応答なしのインシデントは、正常の報告があって初めて復旧します。 コンテナが実行中のまま、ヘルスチェックが正常を報告するか、サービスプローブが成功する状態が、安定間隔（デフォルトは 60 秒）のあいだ続く必要があります。実行中でもまだ異常、または起動中の状態は、安定とはみなされません。どちらも残っていないコンテナ（サービスプローブが削除された場合）は、実行中であり続けるだけで構いません。

サービスプローブはこのコンピュータから実行されます

サービスプローブは、エンジンのヘルスチェックがないコンテナに対する TCP 接続または HTTP GET（2xx または 3xx の応答を期待）です。コンテナの詳細ページで設定します。デーモンは、ローカルとリモートのどちらのホストでも、このコンピュータから実行します。コンテナ内や、SSH 経由のリモートホスト上では実行されません。

• リモートホストの場合、失敗はサービスが応答していないことを意味する場合と、このコンピュータから到達できない（ネットワーク経路、ファイアウォール、VPN）ことを意味する場合があります。
• HTTP のサービスプローブは到達性の確認のみです。ステータスコードだけを読み取ります。システムプロキシを経由せず（このコンピュータ自身からサービスまでの経路をテストするため）、リダイレクトをたどらず（3xx は成功扱い）、自己署名証明書を受け入れます。
• コンテナが実行中のときだけ動作します。チェック間隔ごとに、チェックの前に、デーモンはホスト上でコンテナを名前で検索し、実行中かどうかと起動時刻（猶予期間のため）を確認します。ホストに接続できないときは、チェックは実行されません。
• コンテナの起動後の猶予期間中の失敗は数えません。
• Dockerman がホストを見失っている間（イベントストリームまたはサンプラーが接続できない間）の失敗は数えません。これはホストの切断であり、サービスのハングではありません。連続失敗のカウントは、ホストが復旧すると最初からやり直しです。
• 設定した回数の連続失敗で「サービス応答なし」のインシデントが開始されます。これは、エンジンのヘルスチェックの異常で開始されるものと同じです。チェックが成功するとカウントはリセットされます。インシデントは、ルールの安定間隔のあいだチェックが成功し続けると復旧します。
• デフォルトは、30 秒ごと、タイムアウト 5 秒、連続失敗 3 回、起動後の猶予 60 秒です。すべて変更できます。
• 設定はホストとコンテナ名に紐づくため、コンテナを再作成しても維持されます。再作成されたコンテナは、自身の失敗を 0 からカウントします。
• サービスプローブを削除すると、その結果は破棄されます。デーモンが動作していないときに削除した場合も同様です。その後、開いているインシデントは、エンジンのヘルスチェックが異常を報告していない限り、コンテナがルールの安定間隔のあいだ実行中であり続けると復旧します。
• ここにある他のすべてと同様に、デーモンが動作していて、コンピュータが起きている間だけ実行されます。

通知

各通知には、ホスト、コンテナ、理由、観測した再起動回数と期間または障害の継続時間、わかっている場合は終了コードが含まれます。ログの本文や環境変数の値は含まれません。システム通知は Dockerman の言語を使い、外部チャンネルには英語のテキストが送られます。

各インシデントとアラートイベントには、チャンネルごとの結果が記録されます。

コンテナのミュートとサイレント時間帯が抑制するのは通知の配信だけです。インシデントは引き続き開始・終了し、抑制された通知が再送されることはありません。

ステータスが「システムに引き渡し済み」でもシステム通知が表示されない場合は、システムの通知設定で Dockerman の通知がオフになっている（macOS では システム設定 > 通知 > Dockerman）か、集中モードやおやすみモードで非表示になっていることがほとんどです。Dockerman はこの権限を読み取れません。通知をクリックすると、Dockerman が前面に表示されるだけです。