4.5死活監視・リソース監視・運用監視ツール

個々のコマンドでその場の状態を見るだけでは、夜間や休日に起きる障害には気づけません。継続的に見張り、しきい値を超えたら知らせる運用監視の仕組みを整えることが、24時間稼働のサービスを支える土台になります。

4.5.1監視すべき異常とOOMKiller

• 監視で早期検知すべき異常＝リソース枯渇（メモリ・ディスク等が尽きる）・過負荷（CPU/通信量が持続的に高い）・異常停止（プロセス/サービスのクラッシュ）。
• OOMKiller（Out-Of-Memory Killer）＝物理メモリとスワップを使い切りそうになったとき、カーネルが強制的に特定プロセスを選んで終了させる仕組み。想定外のプロセス停止の原因調査でまず疑う対象。

4.5.2SNMP・しきい値と代表的な監視ツール

• SNMP（Simple Network Management Protocol）＝ネットワーク機器やサーバーの状態をリモートから標準化された方法で取得するプロトコル。監視ツールが対象機器の状態を集める土台として使われる。
• 監視の基本設計＝標準管理項目（CPU/メモリ/ストレージ使用率、通信量、死活・ログ・レスポンスなど）ごとにしきい値を定め、超えたらアラートを発報する。死活監視（生きているか）・ログ監視・レスポンス監視・使用率監視は目的が異なる別カテゴリ。
• 代表的な監視ツール＝Icinga2・Nagios（死活監視・サービス監視の代表格）、collectd（メトリクス収集デーモン）、MRTG・Cacti（トラフィック等をグラフ化）、Zabbix（収集・可視化・アラートを統合したプラットフォーム）。

監視設計は「何を・どう測り・いつ知らせるか」の3段で考えると整理しやすくなります。まず対象を死活（生きているか）・ログ（エラーパターンの出現）・レスポンス（応答時間）・使用率（CPU/メモリ/ストレージ/通信量）に分類し、それぞれに標準管理項目としきい値（例：メモリ使用率90%超過が5分継続）を定めます。しきい値を超えたらアラートとして管理者へ通知する、という流れです。実装面ではSNMPがネットワーク機器・サーバーの情報をリモートから標準化された形で取得する土台となり、collectdのような収集デーモンやZabbixのような統合プラットフォームがこれを利用してメトリクスを集めます。死活監視・サービス監視に特化したNagiosや後継のIcinga2はプラグイン方式でチェックを拡張でき、しきい値超過時に多様な通知チャネルへアラートを送れます。MRTGやCactiはSNMPで取得したトラフィック等のデータを時系列グラフとして可視化することに強みがあり、「いつから通信量が増え始めたか」のような傾向把握に向きます。一方OOMKillerはこうした監視の対象というより症状の原因であることが多く、「特定プロセスが理由不明で突然落ちた」という相談を受けたら、まずdmesgやjournalctlのログでOOMKillerの発動記録がないかを確認するのが定石です。メモリのしきい値監視を事前に組んでおけば、OOMKillerが動く前にアラートで気づける、という関係になります。

4.5.3この節のまとめ

• 監視は死活・ログ・レスポンス・使用率を分類し、しきい値超過でアラート。取得の土台はSNMP
• Nagios/Icinga2＝死活・サービス監視／collectd＝収集／MRTG・Cacti＝グラフ化／Zabbix＝統合。OOMKillerはメモリ枯渇時の強制終了（ディスクとは無関係）