ハードウェアを軽視することの隠れた代償
6ヶ月前のある土曜日の夜、NVMeドライブが何の前触れもなく寿命を迎えたため、私はデータベースの復旧作業に追われていました。ログには標準的な I/Oエラーが記録されていましたが、その時にはすでにファイルシステムは読み取り専用になっていました。私たちはNginxのチューニングやカーネルパラメータのデバッグに時間を費やしがちですが、すべては物理的なシリコンや回転する（あるいはフラッシュされる）ビットの上で動いていることを忘れがちです。ハードウェアを監視していないのは、計器盤のない飛行機を操縦しているのと同じです。
その事件の後、私はすべてのノードに3つのユーティリティ（smartmontools、lm-sensors、dmidecode）を使用した軽量な監視戦略を導入しました。リソースを消費せず、かつシステムの状態を明確に把握できるものを求めていました。それ以来、この構成を本番環境で運用していますが、すでに少なくとも2回の深刻なトラブルを未然に防ぐことができました。
ローカル監視の3つの柱
コマンドの解説に入る前に、これら3つのツールがどのように連携するかを明確にしておきます。それぞれがハードウェアスタックの異なるレイヤーを担当しています。
1. dmidecode：システムインベントリ
このユーティリティは、Desktop Management Interface (DMI) テーブルから情報を抽出します。BIOSのバージョン、使用されているRAMスロットの数、サポートされている最大メモリ容量、さらにはコンポーネントのシリアル番号まで、どのようなハードウェアが接続されているかを正確に教えてくれます。私は主にインベントリ管理や、ハードウェアがベンダーの仕様と一致しているかを確認するために使用しています。
2. lm-sensors：熱の番犬
サーバー室のエアコンが故障したり、ファンが止まったりした場合、それを検知するのがlm-sensorsです。マザーボード上のI2CおよびSMBusインターフェースを介して、電圧、温度、ファンの回転数を監視します。本番環境では、ハードウェアが実際に故障するずっと前に、サーマルスロットリングによってパフォーマンスが低下することがあります。
3. smartmontools：ディスクの主治医
これは間違いなく最も重要です。ほぼすべての現代的なHDDおよびSSDドライブに組み込まれているSelf-Monitoring, Analysis, and Reporting Technology (S.M.A.R.T.) システムを制御します。SSDの「代替セクタ数（Reallocated Sector Count）」や「ウェアレベリング回数（Wear Leveling Count）」などの属性を追跡することで、故障を予測します。
実践：スタックの導入
私は通常、OSをインストールした直後にこれらのツールを導入します。4GBのRAMを搭載した本番環境のUbuntu 22.04サーバーでは、このアプローチにより、数個のメトリクスを収集するためだけに頻繁にCPU負荷を高める重いJavaベースの監視エージェントを実行する場合と比較して、処理時間が大幅に短縮されることがわかりました。
インストール
Debian/UbuntuやRHEL系のシステムへの導入は非常に簡単です：
# Ubuntu/Debianの場合
sudo apt update
sudo apt install smartmontools lm-sensors dmidecode -y
# RHEL/AlmaLinux/CentOSの場合
sudo dnf install smartmontools lm_sensors dmidecode -ydmidecodeによるハードウェアの特定
dmidecodeの出力は膨大であるため、私は常に-t（タイプ）フラグを使用して必要な情報をフィルタリングしています。以下は、将来のアップグレードのために空きスロットがあるかどうかメモリ構成を確認する方法です：
sudo dmidecode -t memory | grep -Ei "Size|Type|Speed"サポートチケットのためにシャーシのシリアル番号が必要な場合は、以下を実行します：
sudo dmidecode -s system-serial-numberlm-sensorsの設定
インストール後、lm-sensorsはマザーボード上のチップを検出する必要があります。これには検出スクリプトを実行します。ハードウェアに特有の癖があることがわかっている場合を除き、ほとんどのプロンプトでデフォルトを適用することをお勧めします。
sudo sensors-detect検出が完了し、推奨されたモジュールをロード（または再起動）した後は、いつでも簡単なコマンドで温度を確認できます：
sensors私の経験では、CPUについては「Package id 0」の温度に注目しています。通常の負荷時に常に80°Cを超えている場合は、サーマルペーストの状態やサーバーのエアフローを確認すべき時です。
smartmontoolsによるディスク監視
私が最も時間を割くのはここです。まず、ユーティリティがドライブを認識しているか確認するために、ドライブを一覧表示します：
sudo smartctl --scan特定のドライブ（例えば/dev/sda）の完全な健全性レポートを取得するには、次を使用します：
sudo smartctl -a /dev/sda特に「SMART overall-health self-assessment test result」に注目してください。もし「PASSED」以外が表示されている場合は、すぐにデータを移行する必要があります。SSDの場合、私はPercentage_Used属性を注意深く監視しています。これが90%に達したら、交換の計画を立て始めます。
また、重大な電気的または機械的な問題をチェックするために、cron経由で毎晩「Short」セルフテストをスケジュールしています：
sudo smartctl -t short /dev/sdaアラートの自動化
個人のホームサーバーなら手動チェックでも十分ですが、本番環境ではsmartmontoolsに付属しているsmartdデーモンを使用します。これはバックグラウンドで動作し、ドライブに異常が発生した瞬間にメールを送信できます。設定は/etc/smartd.confを編集して行います。
私の典型的なドライブ設定行は以下の通りです：
/dev/sda -a -m [email protected] -s (S/../.././02)これはデーモンに対し、すべての属性を監視し（-a）、メールを送信し（-m）、毎日午前2時にショートセルフテストを実行する（-s）よう指示するものです。
6ヶ月を振り返って
この軽量でネイティブなツールセットに移行したことで、インフラの管理方法が変わりました。何かがおかしいと気づくために、システムがクラッシュするのを待つ必要はもうありません。3ヶ月前、ゲートウェイノードの故障しかけていたファンを見つけることができました。温度はまだ許容範囲内（ただし上昇中）でしたが、sensorsがRPM 0を示していたからです。
これらのツールの素晴らしさは、そのシンプルさにあります。Webサーバーもデータベースも、複雑な依存関係も必要ありません。ハードウェアから直接読み取るため、抽象化されることのない真実を教えてくれます。Linuxサーバーを管理しているなら、1時間かけてこれら3つのユーティリティを設定することは、データに対する最高の保険となるでしょう。
