「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利用率

を理解しましょう。

また、監視設定は「通知を増やすこと」が目的ではありません。
本当に危険な状態を、適切なタイミングで検知することが大切です。

実務では、

  • 継続条件
  • 誤検知対策
  • 通知整理

が運用品質に大きく影響します。

まずは標準テンプレートから始めて、実際のサーバ傾向を見ながら調整していくのがおすすめです。

ABOUT ME
はつゆき
はじめまして、はつゆきと申します。 なんやかんやでシステムエンジニアとして10年務めています。 特に監視系やサーバ関連などを多く携わっています。 初めて監視系の案件に携わるよーって方へなるべくわかってもらえるようにこれまで経験してきたことなど伝えていければと思っています。