最適な構成：稼働状況、システム負荷、ドライブの健全性には個別のチェックを使う
この3つすべてを適切に処理できるツールは、ほとんどありません。実用的なZimaOSの構成は、「サービスに到達できるか」を確認するUptime Kuma、CPU・RAM・空き容量・温度の推移を確認するNetdata、ディスクのSMART履歴を確認するScrutinyです。これにより、pingチェックだけでドライブの故障を予測できるかのように誤解することなく、役立つアラートを受け取れます。
アプリとポートの可用性にはUptime Kumaを使う
HTTPエンドポイント、TCPポート、DNS、ping対象を監視し、SMTP／メール通知チャンネルを追加します。Uptime Kumaのハードウェアガイドでは、ストレージと監視対象数の拡張について説明しています。Uptime Kumaの公式ドキュメントでは、通知と監視タイプについてプロジェクトドキュメントで説明しています。
リソースのしきい値にはNetdataを使う
空き容量、継続的なCPU負荷、メモリ負荷、温度は、単純な稼働／停止チェックではなく、継続的に測定するメトリクスです。Netdataのアラートエンジンは、しきい値ベースのヘルスチェック向けに設計されています。NetdataのハードウェアガイドとNetdataの通知ドキュメントを参照してください。
SMART履歴にはScrutinyを使うが、実際のドライブをパススルーする
Scrutinyが機能するには、smartctlから物理ディスクが認識できる必要があります。Dockerでは、必要な--deviceマッピングとケイパビリティを設定するという意味です。RAIDコントローラーでは、デバイスタイプに関する特別な設定が必要になる場合があります。公式のScrutinyドキュメントで、これらの要件を確認できます。
アラートは対応につながる内容を定義する
- サービスに2～5分間到達できない → コンテナ／ネットワークを確認する。
- ファイルシステムの使用率が80～90%超 → 不要なデータを削除するか、ストレージを拡張する。
- 温度がハードウェアの安全な動作目標を超える → 冷却とワークロードを確認する。
- SMARTの重要属性の異常、またはデバイスエラーが繰り返し発生する → バックアップを取り、ドライブを交換または診断する。
アプリのサイズ要件をより広く確認するには、ZimaOS App Storeのハードウェアディレクトリを利用してください。
