ZabbixでLinuxメモリ監視を設定する方法【初心者向け】
「Zabbixでメモリ監視を設定したいけど、何を監視すればいいのか分からない」
監視運用を始めたばかりの新人エンジニアだと、ここで悩むことが多いです。
CPU監視はイメージしやすいですが、メモリ監視は少し厄介です。
Linuxは空きメモリをキャッシュとして使うため、単純に「空きメモリが少ない=異常」とは限りません。
そのため、意味を理解せずに設定すると、
- アラートが鳴りっぱなしになる
- 本当に危険な状態を見逃す
- 運用負荷だけ増える
という失敗が起きやすくなります。
この記事では、Zabbixでのメモリ監視設定について、初心者向けに実務目線で解説します。
単なる設定手順だけではなく、
- なぜその監視をするのか
- 実務でどの閾値を使うのか
- よくある誤検知
- 運用で困りやすいポイント
まで含めて説明します。
Zabbixでメモリ監視が重要な理由
メモリ不足は障害につながりやすい
メモリ不足は、サーバ障害の原因になりやすい項目です。
例えば以下のような問題が発生します。
- アプリケーション停止
- レスポンス低下
- swap大量発生
- OOM Killerによるプロセス強制終了
特にLinuxでは、メモリ不足時に「OOM Killer」という仕組みが動作し、重要なプロセスが停止する場合があります。
監視していないと、突然サービス停止につながることもあります。
Linuxはメモリをキャッシュとして使う
ここは初心者がかなり混乱しやすいポイントです。
Linuxは余ったメモリをキャッシュとして積極的に利用します。
つまり、
- 空きメモリが少ない
- 使用率が高い
だけでは異常とは限りません。
メモリ使用率95%なんだけど障害かな?
Linuxはキャッシュを使うから、使用率だけでは判断できないよ。swap発生や継続時間も確認しよう。
この考え方を知らずに監視すると、誤検知だらけになります。
実務では「空きメモリ」だけ見ない
実務では以下を組み合わせて監視することが多いです。
- メモリ使用率
- availableメモリ
- swap利用率
- 継続時間
- プロセス増加傾向
単発の高騰ではなく、「継続的に逼迫しているか」を見るのが重要です。
Zabbixでメモリ監視を設定する基本構成
Zabbix Agentを利用する
メモリ監視では通常、Zabbix Agentを利用します。
Zabbix Agentは監視対象サーバにインストールする監視用プログラムです。
Linuxなら以下コマンドで状態確認できます。
systemctl status zabbix-agent
稼働していないと、監視データが取得できません。
使用する主な監視アイテム
代表的なアイテムは以下です。
| 監視項目 | キー |
|---|---|
| メモリ使用率 | vm.memory.size[pused] |
| 空きメモリ | vm.memory.size[available] |
| 総メモリ | vm.memory.size[total] |
| swap空き容量 | system.swap.size[,free] |
初心者はまず vm.memory.size[pused] を覚えると理解しやすいです。
これはメモリ使用率を取得するキーです。
監視対象ホストを確認する
まず対象ホストにテンプレートが適用されているか確認します。
一般的には以下テンプレートを利用します。
- Linux by Zabbix agent
テンプレートを使う理由は、標準監視をまとめて利用できるためです。
ゼロから作るより、運用負荷を減らせます。
テンプレート作成についてはこちらの記事もあわせてみればいいかと思います。
→Zabbixテンプレート作成を初心者向けに完全解説
Zabbixでメモリ監視を設定する手順
メモリ使用率アイテムを確認する
以下メニューから確認します。
データ収集
→ ホスト
→ アイテム
Memory utilization が存在するか確認します。
存在しない場合はテンプレート未適用の可能性があります。
トリガーを設定する
例として、80%以上で警告を出します。
last(/Linux server/vm.memory.size[pused])>80
90%以上なら障害レベルにするケースもあります。
ただし、いきなり厳しい閾値にしない方が安全です。
なぜか?
サーバによって通常使用率が違うためです。
例えば、
- DBサーバ → 常時高め
- Webサーバ → 比較的低め
など特徴があります。
まずは通常値を観測してから調整しましょう。
グラフで推移を確認する
ここは実務でかなり重要です。
単発アラートだけでは原因が分かりません。
グラフを見ると、
- 徐々に増えている
- 特定時間だけ増える
- リリース後から増加した
など傾向分析ができます。
メモリリーク調査でも役立ちます。
Zabbixの実務でよく使うメモリ監視設定例
使用率80%で警告
よくある初期設定です。
理由は、まだ余裕があり調査時間を確保できるためです。
ただし全サーバ共通にすると誤検知が増えることがあります。
使用率90%で障害レベル
90%以上が継続する場合は注意です。
特に以下状況は危険です。
- swap増加
- 応答遅延
- プロセス異常終了
単純な数値だけでなく、サーバ状態全体を確認しましょう。
swap利用率監視も重要
実務ではswap監視もかなり重要です。
swap利用が増えると、ディスクI/Oが発生して性能低下しやすくなります。
例えば以下のように監視します。
system.swap.size[,pfree]
swap使用が常態化しているなら、
- メモリ不足
- アプリ異常
- メモリリーク
を疑います。
Zabbixのメモリ監視で初心者がハマりやすいポイント
Linuxのキャッシュを誤解する
これは本当に多いです。
「空きメモリが少ない=危険」
ではありません。
free -m コマンドの available を見る習慣を付けましょう。
free -m
閾値を厳しくしすぎる
監視を頑張ろうとして、
- 70%で警告
- 75%で障害
などにすると、通知だらけになります。
結果として、
「またいつものアラートか」
となり、本当に危険な通知を見逃します。
これは運用現場でかなり問題になります。
一時的なスパイクで誤検知する
バックアップやバッチ処理で、一時的に使用率が上がることがあります。
そのため実務では、
5分継続したら通知
のように設定することが多いです。
夜中だけ毎日アラートが鳴るんだけど…?
バックアップ処理かもしれないね。継続条件を付けてみよう。
Zabbixの運用現場での注意点
メモリリーク監視を意識する
長時間かけて徐々にメモリ使用率が増える場合があります。
これはメモリリークの可能性があります。
特にJavaアプリや常駐プロセスで発生しやすいです。
グラフ監視が役立ちます。
アラート疲れを防ぐ
監視で大切なのは「必要な通知だけ出す」ことです。
通知が多すぎると、誰も見なくなります。
そのため、
- 継続条件
- 時間帯制御
- 除外設定
を適切に使いましょう。
アラートについてはこちらで更に詳しく書いてみます。
→Zabbixアラート設定を初心者向けに完全解説【通知設定の基本】
障害対応時はCPUとセットで確認する
メモリだけ見ても原因特定できないことがあります。
例えば、
- CPU高騰
- swap大量発生
- ディスクI/O逼迫
も同時発生する場合があります。
そのため、CPU監視やディスク監視と合わせて確認するのが基本です。
CPU監視につきましてはこちらの記事もご確認ください
→Zabbix CPU監視設定を初心者向けに完全解説
まとめ
Zabbixのメモリ監視では、「使用率だけ見ない」ことが重要です。
初心者はまず、
- メモリ使用率
- availableメモリ
- swap利用率
を理解しましょう。
また、監視設定は「通知を増やすこと」が目的ではありません。
本当に危険な状態を、適切なタイミングで検知することが大切です。
実務では、
- 継続条件
- 誤検知対策
- 通知整理
が運用品質に大きく影響します。
まずは標準テンプレートから始めて、実際のサーバ傾向を見ながら調整していくのがおすすめです。







