VPSでUptime Kumaをセルフホストする方法

VoyraCloud VPS上でUptime Kumaを自己ホストするには、プリインストールされたアプリケーションイメージを選択し、プライベートSSHトンネルを通じて最初の管理者を作成し、運用しているサービスのモニターを追加します。このイメージは持続的なUptime Kumaの出発点を提供し、パブリックアクセス、信頼されたHTTPS、通知、バックアップ、更新、キャパシティプランニング、インシデントレスポンスはすべてあなたの管理下にあります。

TL;DR

VoyraCloud Uptime Kumaアプリケーションイメージは、Cloud VPSおよびResidential IP VPS上にプリインストールされた監視ダッシュボードを提供します。
ポート3001はデフォルトで127.0.0.1にバインドされているため、未初期化のセットアップページをインターネットに公開するのではなく、SSHトンネルを通じて最初の管理者を作成してください。
Uptime Kumaは、HTTP、HTTPS、TCP、ping、DNS、WebSocket、プッシュ、キーワード、JSONクエリモニターなど、プロジェクトによって文書化された他のモニタータイプをサポートしています。
パブリックダッシュボードまたはステータスページへのアクセスには、自分のドメイン、WebSocketアップグレードをサポートするリバースプロキシ、およびブラウザが信頼するHTTPSが必要です。
設定、ユーザー、監視履歴、通知、ステータスページは、ローカルの持続的ストレージの/app/dataに保存されます。再起動の持続性はバックアップではありません。
20モニター、60秒間隔のワークロードは、イメージの初期検証プロファイルであり、無制限のモニター保証や自分のワークロードを測定するための代替ではありません。
同じVPSからの監視には重要な盲点があります：そのVPS、地域、またはネットワークパスが失敗した場合、Uptime Kumaはアラートを送信できない可能性があります。

Uptime Kumaとは何ですか？

Uptime Kumaは、ウェブサイト、API、ネットワークサービス、およびあなたが管理するダッシュボードから到達可能なエンドポイントをチェックするためのオープンソースの自己ホスト型監視アプリケーションです。チェック結果と応答情報を記録し、サービス履歴を表示し、管理者が設定した統合を通じて通知を送信できます。

公式Uptime Kumaプロジェクトは、HTTP(S)、TCP、HTTP(S)キーワード、HTTP(S) JSONクエリ、WebSocket、ping、DNSレコード、プッシュ、Dockerコンテナ監視などのモニタータイプのサポートをリストしています。また、複数のステータスページ、証明書情報、pingチャート、二要素認証、プロキシサポート、および幅広い通知統合を提供します。

自己ホスティングは、次のような場合に便利です：

自分のサーバー管理下にある監視ダッシュボード。
モニター設定、ユーザー、履歴、ステータスページの管理。
複数のウェブサイト、API、またはネットワークサービスをチェックするための簡単な方法。
すでに使用している通知プロバイダーに接続するオプション。
小型VPS上で継続的に実行できる監視ツール。

この方法でデプロイされたUptime Kumaは、管理された監視サービスではありません。あなたはVPS、アクセス制御、アップグレード、バックアップ、通知資格情報、および応答プロセスを所有します。また、1つの監視場所があなたにとって重要なサービスの可視性を十分に提供するかどうかを決定する必要があります。

VoyraCloudアプリケーションイメージでの開始方法は？

Uptime Kumaを自己ホストする最も早い方法は、アプリケーションイメージを使用してサポートされたVoyraCloud VPSを作成し、ローカルSSHトンネルを通じて最初のセットアップを完了することです。 Uptime Kumaを手動でインストールする必要はありませんが、モニターを設定する前に管理者を安全に作成する必要があります。

VoyraCloudのUptime Kumaページを開き、VPS購入フローに進みます。
対象となるCloud VPSまたはResidential IP VPSプランを選択し、その製品で現在提供されている任意の地域を選択します。
イメージセクションでUptime Kumaが選択されていることを確認し、VPSを作成します。
VPSリソースとアプリケーションが準備できるまで待ちます。
リソースの詳細を開き、アプリケーションセクションを見つけます。
表示されたSSHトンネルコマンドをコピーします。次のパターンに従います：

ssh -p <ssh-port> -L 3001:127.0.0.1:3001 <ssh-user>@<server-ip>

7. そのSSHセッションを開いたままにし、次のURLにアクセスします：

http://127.0.0.1:3001

8. 公式Uptime Kumaセットアップページを完了し、ユニークな管理者ユーザー名と強力なパスワードを作成します。

9. サインインし、1つのテストモニターを作成し、ダッシュボードにチェックが表示されることを確認します。

10. VPSを1回再起動し、Uptime Kumaが自動的に戻り、アカウント、モニター、および履歴が利用可能であることを確認します。

ブラウザのアドレスはローカルですが、アプリケーションはVPS上で実行されています。SSHは、ローカルポート3001を暗号化された接続を通じてサーバーの127.0.0.1:3001に転送します。SSHセッションを閉じるとトンネルが閉じますが、Uptime Kumaは停止しません。

コンピュータがすでにローカルポート3001を使用している場合は、リモートの宛先を変更せずに別のローカルポートを選択してください：

ssh -p <ssh-port> -L 33001:127.0.0.1:3001 <ssh-user>@<server-ip>

その場合、ブラウザでhttp://127.0.0.1:33001を開きます。リモート側は127.0.0.1:3001のままにします。

SSHユーザー名とポートは、rootやポート22を仮定するのではなく、自分のリソースに表示されているものを使用してください。

アプリケーションイメージには何が含まれていますか？

アプリケーションイメージには、プリインストールされた持続的なUptime Kumaインスタンスが含まれていますが、VPSを管理された監視サービスには変換しません。生産用途を計画する際には、次の境界が重要です。

アプリケーションイメージによって提供されるもの	ユーザー管理または含まれていないもの
イメージ用に承認されたUptime Kumaの安定版リリース	自動アプリケーションアップグレード
Cloud VPSまたはResidential IP VPSの運用環境	管理されたサーバー管理
通常のVPS再起動後のサービス回復	高可用性または自動フェイルオーバー
`127.0.0.1:3001`へのローカル専用アクセス	パブリックポート`3001`の公開
公式な最初の管理者セットアップフロー	事前作成された管理者または固定パスワード
持続的なローカル`/app/data`ストレージ	自動オフサーバーバックアップ
監視ダッシュボード、履歴、通知、およびステータスページ機能	事前設定されたサードパーティ通知アカウント
リソース詳細におけるSSHトンネルの指示	ドメイン登録、リバースプロキシ、または信頼されたHTTPS
ユーザー制御のモニター設定	検出精度またはアラート配信の保証
オープンソースライセンスの下のUptime Kuma	納品後のUptime KumaのVoyraCloudによるメンテナンス

このイメージには固定された管理者資格情報、無認証モード、通知シークレット、ドメイン、証明書、またはパブリック管理エンドポイントは含まれていません。これにより、最初のアクセスがプライベートに保たれ、未初期化のアカウント作成ページがインターネット上に直接公開されることを避けることができます。

どのモニタータイプを使用すべきですか？

成功したpingがウェブサイト、API、またはアプリケーションが正しく機能していることを証明しないため、テストする必要があるレイヤーに応じて各Uptime Kumaモニタータイプを選択してください。有用な監視セットは、一般的なハートビートに依存するのではなく、ユーザー向けのレイヤーと選択された依存関係をチェックします。

モニタータイプ	検証できる内容	重要な制限
HTTPまたはHTTPS	URLが応答し、期待されるステータスを返す	成功した応答が不正確なコンテンツを含む可能性がある
キーワード	応答に期待されるテキストが含まれているか除外されているか	テキストチェックはすべてのビジネス機能を検証しない
JSONクエリ	API応答に期待される値が含まれている	クエリは実際の応答構造と一致する必要がある
TCPポート	ネットワークサービスが接続を受け入れる	オープンポートはアプリケーションが正常であることを証明しない
Ping	ホストがICMPに応答する	ICMPがフィルタリングされる可能性があり、応答はアプリが機能していることを証明しない
DNSレコード	リゾルバが期待されるレコードを返す	1つのリゾルバビューがグローバルな伝播を表さない可能性がある
WebSocket	WebSocketエンドポイントに到達できる	すべてのメッセージフローを検証しない
プッシュ	ジョブまたはリモートプロセスが自分のハートビートを報告する	プッシュが欠けている場合、そのジョブ用に設計されたアラートウィンドウが必要
証明書情報	証明書の状態と有効期限情報	更新は依然としてあなたの証明書プロセスに依存する

パブリックウェブサイトの場合、実用的なセットにはHTTPSチェック、意味のあるコンテンツのためのキーワードまたはJSONチェック、および証明書の有効期限チェックが含まれる場合があります。VPSから到達可能な内部サービスの場合、TCPまたはHTTPチェックがインフラの可視性を追加できます。スケジュールされたジョブの場合、プッシュモニターは期待されるハートビートが届かないときに検出できます。

すべてのモニターが同じ理由で失敗し、それらを独立した証拠として扱うことを避けてください。モニターデザインは、実際の失敗モードを反映する必要があります：DNS、TLS、ネットワーク到達性、アプリケーション応答、コンテンツの正確性、バックグラウンドジョブの完了。

20モニター検証プロファイルとは何ですか？

20モニタープロファイルは、初期イメージ構成のための保守的な受け入れワークロードであり、最大容量の約束ではありません。 計画された検証では、24時間にわたり60秒間隔で20モニターを使用し、その後VPSを再起動し、持続性を確認します。

その検証は、狭い質問に答えることを目的としています：対象となるエントリー構成は、メモリ不足のイベント、データベースロック、予期しないコンテナ再起動、または定義されたワークロードの下でのデータ損失なしに、小型のUptime Kumaインストールを実行できますか？これは、同じプランが次のことをサポートできることを証明するものではありません：

無制限のモニター。
非常に短いチェック間隔。
大きな応答ボディまたは高価なJSONクエリ。
多くの同時ユーザーまたはパブリックステータスページの訪問者。
ストレージの成長なしに長期間の保持。
大量の通知ボリューム。
ホストソケットへのアクセスを持つDocker監視。
同じVPSを共有する追加のアプリケーション。

実際のリソース使用は、モニタータイプ、間隔、タイムアウト、応答サイズ、履歴保持、通知動作、ダッシュボードアクティビティ、およびサーバー上の他のソフトウェアに依存します。測定されたセットから始め、CPU、メモリ、ディスク使用、データベースの動作、チェックの期間を監視し、実際のワークロードが必要なときにより大きなVoyraCloud VPS構成に移行してください。

購入フローの最小値を普遍的なサイズ推奨と解釈しないでください。それは検証された開始プロファイルのための適格性ゲートです。

Uptime Kumaを安全に公開するにはどうすればよいですか？

Uptime Kumaを専用のドメインまたはサブドメイン、WebSocket対応のリバースプロキシ、およびブラウザが信頼するHTTPSを通じて公開し、ポート3001をlocalhostにバインドしたままにします。長期的なSSHトンネルアクセスも有効ですが、ダッシュボードが必要なのは管理者のみで、パブリックステータスページが必要ない場合です。

公式のUptime Kumaリバースプロキシガイドは、アプリケーションがWebSocketを使用し、プロキシがUpgradeおよびConnectionヘッダーを通過させる必要があることを説明しています。また、Uptime Kumaは/uptime-kumaのような通常のURLサブディレクトリの下でホストされることをサポートしていないことも指摘しています。status.example.comのような専用のホスト名を使用してください。

典型的なNginxロケーションブロックには以下が含まれます：

location / {
    proxy_pass http://127.0.0.1:3001;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

このスニペットはプロキシパスのみをカバーしています。ホスト名、信頼されたTLS証明書、証明書の更新、HTTPからHTTPSへのリダイレクト、ファイアウォール、およびアクセスポリシーを別途構成する必要があります。適用する前に、選択したリバースプロキシの現在の公式例を確認してください。

この生産チェックリストを使用してください：

専用のホスト名のDNSレコードを作成します。
3001/tcpをパブリックインターネットから利用できないようにします。
リバースプロキシが127.0.0.1:3001に到達できるように構成します。
WebSocketアップグレードヘッダーを保持します。
通常のブラウザが信頼する証明書をインストールします。
プレーンHTTPをHTTPSにリダイレクトします。
ダッシュボードがWebSocketエラーなしで更新されることを確認します。
サインイン、サインアウト、モニターの更新、ステータスページをテストします。
パブリックアクセスが不要な場合は、管理ホスト名を制限します。
プロキシとファイアウォールのパスが正しい場合のみ、信頼されたプロキシ設定を確認します。

信頼されたHTTPSは、資格情報とセッショントラフィックを転送中に保護しますが、弱い管理者パスワードや古いサーバーを保護するものではありません。SSHを強化し、特権を制限し、適切な場合は二要素認証を有効にし、オペレーティングシステムとリバースプロキシを維持してください。

通知とステータスページはどのように機能しますか？

通知とステータスページは、初期化後に構成する機能であり、イメージにはサードパーティアカウント、資格情報、配信保証、またはパブリックドメインは含まれていません。 Uptime Kumaは多くの通知方法をサポートしていますが、各プロバイダーには独自のアカウント、可用性、価格、制限、および配信動作があります。

公式の通知方法のドキュメントは、プロバイダー固有のセットアップリファレンスを提供します。チームが所有する統合のみを追加し、資格情報を慎重に保管し、依存する前にテスト通知を送信してください。成功したテストは、その瞬間に1つのメッセージが機能したことを証明しますが、将来の配信を保証するものではありません。

各重要なモニターについて：

誰がアラートを受け取るべきかを決定します。
サービスに適したチェック間隔と再試行ポリシーを設定します。
1つ以上のユーザー所有の通知方法を構成します。
障害と回復通知をテストします。
オンコールの人がメッセージに対応できることを確認します。
モニターが障害を報告した場合の対処方法を文書化します。

ステータスページを使用すると、選択したモニターの状態とインシデント情報を共有できます。すべての内部モニターを公開する必要はありません。顧客が理解できる方法でサービスをグループ化し、機密のホスト名や内部トポロジーを公開することを避け、パブリックアクセス用に独自のドメインと安全なプロキシパスを使用してください。

すべての通知統合が無料であると仮定しないでください。一部のサービスは料金を請求したり、使用を制限したり、APIを変更したり、追加の構成を必要とする場合があります。VoyraCloudはこれらのサードパーティアカウントを提供せず、プロバイダーがメッセージを受け入れたり配信したりすることを保証することはできません。

Uptime Kumaのデータはどのように保存され、バックアップされますか？

Uptime Kumaは、そのアプリケーション状態を/app/dataの下に保持し、これは持続的なローカルストレージに残り、実行中のVPSとは別にバックアップされる必要があります。公式のインストールガイダンスでは、POSIXファイルロックのためのファイルシステムサポートが必要であり、NFSに一般的に関連するファイルロックの問題に対して警告しています。

持続的データには、次のような項目に必要なデータベースとアプリケーション状態が含まれます：

管理者およびユーザー設定。
モニター定義。
監視履歴。
通知設定。
ステータスページ。
メンテナンススケジュール。
その他のインスタンス設定。

通常のVPS再起動は、そのデータを保持し、アプリケーションを再起動するはずです。その動作は持続性であり、災害復旧ではありません。偶発的な削除、データベースの破損、資格情報の侵害、アップグレードの失敗、ストレージの損失、またはVPSの削除は、唯一のコピーを削除する可能性があります。

より安全なバックアップルーチンは次のとおりです：

/app/dataにマッピングされた実際のローカルDockerボリュームまたはローカルディレクトリを特定します。
VPSの外部にバックアップをスケジュールします。
選択したバックアップ方法が一貫したデータベースコピーを必要とする場合、Uptime Kumaを静止または停止します。
完全なデータセットをコピーし、エクスポートされたモニターリストだけでなくします。
バックアップを暗号化し、運用の詳細や通知資格情報を含む可能性があるため、保護します。
1つ以上のリカバリポイントを保持します。
別のテストインスタンスに復元し、アカウント、モニター、履歴、通知、ステータスページを確認します。
バックアップに関連するアプリケーションバージョンを記録します。

このイメージのライブ/app/dataディレクトリをNFSに置かないでください。リモートバックアップ先は、コピーされたバックアップアーティファクトに適しています。これは、ネットワークファイルシステム上でアクティブなデータベースを直接実行することとは異なります。

同じサーバー監視の盲点とは何ですか？

Uptime Kumaインスタンスは、自身のコンピュート、ネットワーク、または通知パスを削除する障害を信頼性高く報告することができません。 Uptime Kumaが監視するウェブサイトと同じVPS上で実行されている場合、VPSの障害は、アラートが送信される前にウェブサイトとモニターの両方を停止させる可能性があります。

監視対象のサービスが別のサーバーにある場合でも、1つのUptime Kumaの場所は、1つのネットワークと1つの地域からそれを観察します。ローカルISPルート、地域のネットワーク問題、DNSリゾルバの違い、またはファイアウォールポリシーは、そのビューに影響を与える可能性があり、すべてのユーザーの体験を表すわけではありません。

結果に応じてデプロイメントを使用してください：

監視の必要性	適切なアプローチ
小規模サービスの便利なダッシュボード	1つの自己ホスト型Uptime Kumaインスタンスで十分かもしれません
別のVPS上のサービスを監視する	実用的な場合、監視対象のサーバーの障害ドメインの外にUptime Kumaを配置します
地域の到達性の違いを検出する	複数の場所から独立したチェックを使用します
監視VPSの障害時にアラートを出す	外部ハートビートまたは独立した監視サービスを追加します
高可用性監視	別のマルチシステム監視アーキテクチャを設計します

アプリケーションイメージは、分散監視、高可用性、または独立した外部チェッカーを提供しません。これを1つの監視ポイントとして扱い、見逃したアラートが重大なビジネス影響を持つ場合は独立したカバレッジを追加してください。

Uptime Kumaをどのように更新すべきですか？

Uptime Kumaを意図的に更新し、公式リリースガイダンスを確認し、/app/dataをバックアップし、新しいバージョンを信頼する前に検証します。 VoyraCloudは、VPSが作成された後に顧客インスタンスを自動的にアップグレードしません。

公式のUptime Kuma更新ガイダンスに従って、インストールされたメジャーバージョンとデプロイメント方法に適用されます。更新前に：

リリースノートと移行要件を読みます。
現在実行中のアプリケーションバージョンを記録します。
/app/dataのオフサーバーバックアップを作成し、確認します。
十分な空きディスクスペースを確認します。
重要な監視インスタンスのためのメンテナンスウィンドウを計画します。
レビューされていない浮動タグではなく、特定の承認されたバージョンを使用します。
更新されたインスタンスを起動し、そのログを確認します。
管理者サインイン、いくつかのモニタータイプ、通知、ステータスページ、および再起動の回復をテストします。
リリースによって説明されているデータベースの変更に互換性のあるロールバックプランを保持します。

コンテナイメージを元に戻すだけでは常に十分であるとは限りません。メジャーバージョンの移行はアプリケーションデータを変更する可能性があるため、回復には更新前のデータバックアップと以前のイメージバージョンが必要になる場合があります。

オペレーティングシステムの更新、Dockerの更新、リバースプロキシの更新、および証明書の更新は別々の責任です。現在のUptime Kumaコンテナは、サーバーの残りの部分を最新にするものではありません。

避けるべき一般的な間違い

ほとんどのUptime Kumaデプロイメントの間違いは、初期化を公開したり、1つの監視場所を過大評価したり、持続的ストレージを完全な運用計画として扱ったりすることから来ます。これらのエラーを避けてください：

管理者を作成する前にポート3001を公開する。 localhostに留め、SSHトンネルを使用します。
ダッシュボードをパブリックHTTPに残す。 すべてのパブリックアクセスには信頼されたHTTPSを使用します。
WebSocketプロキシヘッダーを忘れる。 インターフェースは読み込まれるかもしれませんが、正しく更新されない可能性があります。
サブディレクトリの下でホストする。 専用のドメインまたはサブドメインを使用します。
アクティブな/app/dataをNFSで実行する。 互換性のあるローカルストレージに保持します。
再起動の持続性をバックアップと呼ぶ。 テストされたコピーをVPSの外に保存します。
ステータスページが独立した監視を作成すると仮定する。 同じUptime Kumaインスタンスによって提示されます。
VPSを自分自身からのみ監視する。 サーバー全体の障害は、サービスとそのモニターの両方を沈黙させる可能性があります。
20モニターを保証された最大または最小と見なす。 それは定義された検証ワークロードであり、普遍的な容量結果ではありません。
通知配信が保証されると期待する。 プロバイダーの可用性、資格情報、クォータ、ルーティング、および監視ホストはすべて重要です。
所有者なしですべての統合を有効にする。 誰かがテストし、応答するチャネルのみを構成します。
復元可能なデータコピーなしで更新する。 バージョンを変更する前に、完全なアプリケーションデータをバックアップします。

FAQ

Uptime Kumaを手動でインストールせずに自己ホストできますか？

はい。VoyraCloudアプリケーションイメージは、対象となるCloud VPSまたはResidential IP VPS上にプリインストールされたUptime Kumaインスタンスを提供します。それでも最初の管理者を作成し、モニターを追加し、通知を構成し、セキュリティ、更新、バックアップ、およびパブリックアクセスを管理します。

なぜ`http://127.0.0.1:3001`がサーバーIPの代わりに表示されるのですか？

ローカルアドレスは、未初期化の管理者セットアップページがインターネットに直接公開されるのを防ぎます。 コンピュータからSSHトンネルを確立し、セッションを開いたままにしてから、ローカルURLにアクセスします。トンネルは、ブラウザの接続をVPS上のUptime Kumaに安全に転送します。

ポート`3001`をインターネットに直接公開できますか？

直接公開は推奨される生産パスではありません。 サービスをlocalhostにバインドし、専用のホスト名、WebSocketサポート、信頼されたHTTPS、および適切なアクセスポリシーを持つリバースプロキシを使用してください。アプリケーションイメージは、そのパブリックパスを自動的に構成しません。

Uptime Kumaには無料のSMS、メール、Slack、または他の通知サービスが含まれていますか？

いいえ。Uptime Kumaは多くの通知プロバイダーと統合できますが、プロバイダーアカウントと資格情報を提供し、管理するのはあなたです。 サードパーティの価格、クォータ、可用性、およびメッセージ配信はアプリケーションイメージの外にあり、変更される可能性があります。

1 GBのVPSはUptime Kumaに十分ですか？

定義されたイメージ検証が通過した後のみ、適格な出発点となる可能性がありますが、実際の容量はあなたのワークロードに依存します。 初期プロファイルは、24時間にわたり60秒間隔で20モニターを使用します。より多くのモニター、短い間隔、大きな応答、長い履歴、追加のサービス、または重いダッシュボード使用は、より多くのメモリ、CPU、およびストレージを必要とする場合があります。

Uptime Kumaは高可用性または外部監視を提供しますか？

いいえ。このイメージは、1つのVPS上に1つの自己ホスト型Uptime Kumaインスタンスを提供します。 高可用性、分散チェック、および独立した外部監視には、追加のシステムとアーキテクチャが必要であり、これらは含まれていません。

Uptime Kumaは自分のVPSが失敗した場合にアラートを出しますか？

それは出さないかもしれません。アラートを送信するプロセスは、VPSまたはそのネットワークパスとともに失敗する可能性があります。 Uptime Kumaホストの障害を検出することが重要な場合は、外部ハートビートまたは独立した監視場所を使用してください。

何をバックアップする必要がありますか？

完全な持続的データをバックアップし、/app/dataにマッピングされ、リカバリコピーをVPSの外に保存します。 バックアップを保護してください。監視設定や通知シークレットを含む可能性があるため、コピーされたファイルセットが使用可能であると仮定するのではなく、復元をテストしてください。

VoyraCloudはUptime Kumaを自動的に更新しますか？

いいえ。新しいVPSリソースは、作成時にイメージに承認されたアプリケーションバージョンを受け取り、その後の更新は顧客管理となります。 公式のアップグレード指示を確認し、/app/dataをバックアップし、依存する前に更新されたインスタンスをテストしてください。

結論

自己ホスト型Uptime Kumaを使用して、シンプルな監視ダッシュボード、構成可能なチェック、通知、およびステータスページを自分の管理下で実現したい場合に使用してください。 SSHトンネルを通じてプライベートに開始し、実際の失敗モードに基づいてモニターを設計し、/app/dataを持続的なローカルストレージに保持し、VPSの外でバックアップし、パブリックアクセスが必要な場合にのみ信頼されたHTTPSを持つWebSocket対応のリバースプロキシを追加してください。

1つのインスタンスは多くの小規模な監視ニーズに役立ちますが、それは1つの観察ポイントであり、1つの障害ドメインに留まります。Uptime Kumaホスト自体、地域の到達性、またはアラートの継続性もカバーする必要がある場合は、独立した監視を追加してください。

VoyraCloudのUptime Kumaアプリケーションイメージを使用して、アクセス、データ、通知、および操作をあなたの管理下に保ちながら、プリインストールされたVoyraCloud VPS環境から始めてください。