サービスヘルスチェック

スタンドアロンモード

部分的な機能異常やシステム全体のアクセス障害が発生した場合、以下の手順で順番にトラブルシューティングを行います。

docker logs $(docker ps -a | grep -E 'mingdaoyun-community|mingdaoyun-hap' | awk '{print $1}')

docker logs $(docker ps -a | grep mingdaoyun-sc | awk '{print $1}')

ログ分析およびトラブルシューティング方法:

正常時: ログは主にINFOレベルで、安定して継続的に更新されます。
異常時: ERRORログが継続的に出力されたり、スタックトレース情報が表示される場合は、該当事象の分析が必要です。
Kafkaエラー: ストレージコンポーネントのログにKafkaの起動失敗が記録されている場合は、Kafka起動失敗時のトラブルシューティング手順を参照してください。
MongoDBエラー: ログにMongoDBの自動再起動が記録されている場合、主な原因はサーバーのメモリ逼迫です。一時的にHAPサービスを再起動することで復旧する場合があります。
マイクロサービスエラー: ストレージコンポーネントログが正常で、マイクロサービスアプリケーション側のログが異常な場合は、HAPサービスの再起動を試行してください。

インストーラを展開したディレクトリで、以下のコマンドを実行してください。

bash service.sh restartall

find / -path /proc -prune -o -name "service.sh" -print

top -c

スタンドアロンモードでは、16コアのCPUでほとんどの運用環境に対応できます。もしCPUが常にフル稼働し、mongodプロセスの利用率が最も高い場合は、スロークエリが原因の可能性が高いです。スロークエリ最適化ドキュメントを参照してください。
topコマンドのCPU指標でwaフィールドはディスク待ち時間を示します。通常は0または0.xの値が推奨されます。5以上の場合はディスク性能が低く、SSDディスクへの移行を強く推奨します。

free -h

メモリ使用率が上限に近い場合、システム異常を招きやすく、CPU利用率が異常に高くなることもあります。
64GB以上の環境でもメモリ利用率が過度に高い場合は、top -co %MEMコマンドでメモリ使用率順にプロセスを並べ、問題のあるプロセスを特定してください。

df -Th

データパーティションが満杯になると、システム機能が利用不可になります。
古いイメージのクリーンアップや不要なログデータの削除、ディスクの拡張についてはドキュメントを参照してください。対応完了後は、サービスを再起動して機能復旧を図ります。

システム異常は潜在的な遅延が見られる場合があるため、時系列でのリソース傾向の確認が必要です。

既存監視ツール: サーバーにZabbixやPrometheus等の監視ツールが導入されている場合は、障害発生時刻のCPU・メモリ・I/O指標を優先的に確認してください。
追加導入推奨: 監視機構が未導入の場合は、Ops プラットフォームのインストールにより、システムリソースのリアルタイム監視・履歴データ分析が可能です。