コミュニティソリューション

CasaOSにUptime Kumaをインストールしてセルフホスト型サービスを監視する

A September 2023 CasaOS post introducing Uptime Kuma as a self-hosted availability monitor. The forum body contains little installation detail, so current Uptime Kuma Docker settings are needed for a durable setup page.

2023年のIceWhaleコミュニティにあるUptime Kumaのスレッドは、インストール手順というより紹介に近い内容です。投稿ではCasaOSへのインストールを扱うチュートリアルだと説明されていますが、返信では、停止通知、重要度の低いサービスの本番監視、プッシュモニターなど、なぜUptime Kumaが評価されているのかに焦点が当てられています。フォーラム本文には、インストーラーの設定手順は段階的に保存されていません。

そのため、現在のページではCasaOSの背景とコミュニティでの利用例を残しつつ、実際のデプロイにはUptime Kumaが現在メンテナンスしているDocker要件を使用するのが適切です。

Uptime Kumaがホームサーバーにもたらすもの

Uptime Kumaはセルフホスト型の監視ダッシュボードです。ウェブサイト、TCPサービス、DNSエンドポイント、ping対象、Docker関連サービス、プッシュベースのジョブが正常かどうかを確認し、ステータスが変化したときに通知を送信できます。

元の返信では、実用上の価値として通知が繰り返し強調されていました。ダッシュボードも便利ですが、主なメリットは、家庭内の誰かに報告される前にサービスの停止を知ることです。

現在のUptime Kumaコンテナを使用する

現在のUptime Kumaのデプロイ手順では、メンテナンスされているlouislam/uptime-kuma:2イメージを使用します。ウェブアプリケーションはポート3001で待ち受け、永続化するデータベースと設定を/app/dataに保存します。

現在のCasaOSカスタムアプリでは、2023年の動画にある古いイメージタグを使うのではなく、Uptime KumaがメンテナンスしているDockerの設定をCasaOSのアプリフォームに反映してください。

ダッシュボードをポート3001で公開する

コンテナ側のウェブサービスはTCPポート3001を使用します。そのホストポートがすでに使用されている場合は、別のホストポートをコンテナのポート3001に割り当て、選択したホストポートからCasaOSアプリを開いてください。

ホストポートを変更しても、上流のアプリケーションがその変更に対応しており、変更が必要な場合を除き、Uptime Kumaの内部ポートを変更する必要はありません。

/app/dataを永続化する

CasaOSのホストフォルダーまたはDockerボリュームを/app/dataにマッピングします。ここには監視設定、ユーザーデータ、SQLiteデータベースが含まれるため、重要なバックアップ対象です。

永続ボリュームなしでコンテナを再作成すると、新規のUptime Kumaインストールとして動作します。

信頼性の高いロック機能を持つファイルシステムにデータベースを保存する

現在のUptime Kumaのガイダンスでは、SQLiteデータベースに信頼性の高いPOSIXファイルロックが必要であり、データディレクトリに多くのNFS構成などのファイルシステムを使用しないよう明確に注意しています。

ホームサーバーでは、/app/dataをローカルストレージに置くのが最も簡単です。そのうえで、そのローカルディレクトリを別のディスクやリモート保存先にバックアップできます。

利用体験に合ったモニターを選ぶ

pingモニターで確認できるのは、マシンがICMPに応答することだけです。本当の要件が「Jellyfinが読み込めること」であれば、Jellyfinのエンドポイントに対するHTTPモニターのほうが意味があります。

実用的な構成には、次のようなモニターを含められます。

  • ウェブアプリケーション用のHTTPチェック
  • 有用なウェブエンドポイントを持たないサービス用のTCPチェック
  • Pi-holeまたはAdGuard Home用のDNSチェック
  • ホストの基本的な到達性を確認するpingチェック
  • 完了を報告すべき定期ジョブ用のプッシュモニター

スレッドで言及されたプッシュモニターが重要な理由

コミュニティの参加者の1人は、プッシュモニターを頻繁に使用していると具体的に述べていました。Uptime Kumaがサービスをポーリングする代わりに、バックアップスクリプトや定期ジョブが成功時に一意のURLを呼び出します。期待される時間内にそのハートビートが届かなければ、Uptime Kumaはモニターを異常と判定します。

これは、「サーバーがオンラインである」だけではジョブが実際に実行されたことを証明できないタスクに役立ちます。

最初の障害が発生する前に通知をテストする

少なくとも1つの通知チャンネルを設定し、意図的にテストアラートを発生させてください。通知の送信にひそかに失敗する監視システムは、過去の履歴を表示するだけのダッシュボードにすぎません。

家庭内のサービスでは、通知疲れについても考慮してください。小さなエンドポイントすべてを即時通知の対象にすると、本当の障害を無視しやすくなる可能性があります。

リモートアクセスを意図していない限り、監視ダッシュボードを非公開にする

Uptime Kumaには、内部ホスト名、サービス名、ネットワークアドレス、障害履歴が表示される可能性があります。リモート監視が便利だからといって、直接パブリックインターネットに公開しないでください。リモートアクセスが必要な場合は、VPN、プライベートオーバーレイネットワーク、または認証付きリバースプロキシを使用してください。

2023年のCasaOSスレッドを現在のバージョン固定として扱わない

元の議論では、よくメンテナンスされたアプリケーションが評価されていますが、イメージのバージョンは保存されていません。これは利点です。2023年9月に存在した正確なコンテナを再現しようとするのではなく、現在の上流リリースを使用してください。

CasaOS上のUptime Kumaに関するよくある質問

現在のUptime Kumaが使用するポートはどれですか?

ウェブインターフェースにはポート3001を使用します。

どのディレクトリを永続化する必要がありますか?

/app/dataです。

データディレクトリをローカルストレージに置くべき理由は何ですか?

SQLiteデータベースには信頼性の高いファイルロックが必要であり、現在の上流ガイダンスでは、適さないネットワークファイルシステムの使用に注意しています。

元のコミュニティが最も評価していたものは何ですか?

返信では、通知とプッシュモニター機能が繰り返し高く評価されていました。