監視設計の項目一覧｜死活・リソース・ログ監視のしきい値例とテンプレート

監視設計とは、「何を・どの方法で・どの間隔で測り、いくつを超えたら・誰に知らせ・最初に何をするか」を項目ごとに決めて一覧にする作業です。 監視ツールを選ぶ前にこの一覧があると、どのツールを使っても同じ設定に落とし込めます。

この記事では、死活・リソース・プロセス・ポート・URL・ログ・証明書期限・ジョブの8分類、50項目の監視項目一覧を、しきい値の例つきで掲載します。表計算ソフトに貼れるTSV、各項目をLinuxのコマンドで確かめた実行結果、しきい値を決める手順、重要度別の通知ルール表のひな形もあわせて載せています。しきい値はすべて出発点としての例なので、平常時の値を見て調整してください。

確認環境：Ubuntu 24.04 / iputils ping 20240117 / iproute2 6.1.0（ss）/ curl 8.5.0 / OpenSSL 3.0.13 / procps-ng 4.0.4（free・vmstat・pgrep）/ GNU coreutils 9.4（df）/ Python 3.11.15。journalctl と systemctl（systemd 255）は、ヘルプ表示で書式を確かめた範囲を載せています。

監視項目の早見表（8分類）

内側（リソース・プロセス）だけでなく、利用者に近い外側（URL）も見るのが設計のこつです。 プロセスが動いていても画面が表示されないことはあり、その逆もあります。8分類を組み合わせると、どこで止まっているかを切り分けやすくなります。

監視項目一覧（50項目・しきい値例つき）

列の意味は次のとおりです。

死活監視（5項目）

リソース監視（12項目）

プロセス監視（6項目）

ポート監視（5項目）

URL監視（6項目）

ログ監視（7項目）

証明書・期限の監視（4項目）

ジョブ監視（5項目）

「―」は、警告の段階を置かず、異常だけを見る項目です。 プロセスの有無やポートの接続可否のように、結果が「できる・できない」の2つしかない項目は、異常だけで足ります。

表計算ソフトに貼れるTSV（全12列）

上の一覧に「分類」と「通知先」の列を加えたものです。コピーして A1 セルに貼り付けると、そのまま監視項目一覧のひな形として使えます。

No  分類  監視項目    対象  取得方法    間隔  警告のしきい値 異常のしきい値 継続回数    重要度 通知先 一次対応
1   死活  ping応答  全サーバー   ping -c 3   1分  応答時間 100ms以上    3回とも応答なし    2回  高   当番へ電話＋チャット  コンソールから状態確認、ネットワーク経路を確認
2   死活  ping損失率 全サーバー   ping -c 10  5分  損失 10%以上    損失 50%以上    2回  中   チャット（運用チャンネル）   経路上の機器と回線の状態を確認
3   死活  再起動の検知  全サーバー   uptime  5分  稼働時間 10分未満  ―   1回  中   チャット（運用チャンネル）   再起動の理由をログで確認、サービスの起動を確認
4   死活  時刻のずれ   全サーバー   時刻同期サービスの状態表示   10分 0.5秒以上  5秒以上    3回  中   チャット（運用チャンネル）   時刻同期サービスの状態と同期先を確認
5   死活  監視エージェントの応答 全サーバー   監視サーバーからの最終受信時刻 1分  3分間受信なし 10分間受信なし    1回  高   当番へ電話＋チャット  エージェントの再起動、サーバー自体の死活を確認
6   リソース    CPU使用率  全サーバー   vmstat 1 2  1分  80%以上   95%以上   5回  中   チャット（運用チャンネル）   top で使用率の高いプロセスを特定
7   リソース    ロードアベレージ    全サーバー   /proc/loadavg   1分  コア数 × 1.0 以上    コア数 × 2.0 以上    5回  中   チャット（運用チャンネル）   実行待ちのプロセスと入出力待ちを確認
8   リソース    入出力待ち（iowait）   DB・ファイルサーバー vmstat 1 2  1分  20%以上   40%以上   5回  中   チャット（運用チャンネル）   ディスクの読み書きが多いプロセスを確認
9   リソース    メモリ使用率  全サーバー   free -m 1分  85%以上   95%以上   5回  中   チャット（運用チャンネル）   メモリを多く使うプロセスを確認
10  リソース    スワップ使用量 全サーバー   free -m 5分  物理メモリの10%以上 物理メモリの50%以上 3回  中   チャット（運用チャンネル）   スワップの出入り（vmstat の si / so）を確認
11  リソース    ディスク使用率 全ファイルシステム   df -h   5分  80%以上   90%以上   2回  高   当番へ電話＋チャット  大きなファイルと増え方を確認、不要ファイルを整理
12  リソース    ディスクが満杯になるまでの日数 データ領域   日次の使用量の差から計算    1日  30日以内   7日以内    1回  中   チャット（運用チャンネル）   増設または保存期間の見直しを計画
13  リソース    iノード使用率 全ファイルシステム   df -i   10分 80%以上   90%以上   2回  中   チャット（運用チャンネル）   小さなファイルが大量にあるディレクトリを確認
14  リソース    開いているファイル数  全サーバー   /proc/sys/fs/file-nr    5分  上限の70%以上    上限の90%以上    3回  中   チャット（運用チャンネル）   ファイルを多く開いているプロセスを確認
15  リソース    ネットワーク帯域の使用率    Web・中継サーバー  ip -s link  1分  帯域の70%以上    帯域の90%以上    5回  中   チャット（運用チャンネル）   通信量の多い相手先を確認
16  リソース    ネットワークのエラー数 全サーバー   ip -s link  5分  5分間に1件以上    5分間に100件以上  2回  低   日次レポート  ケーブル・インターフェースの状態を確認
17  リソース    DB接続数   DBサーバー  DBの接続数を数えるSQL   1分  最大接続数の70%以上 最大接続数の90%以上 3回  高   当番へ電話＋チャット  接続元と長時間の処理を確認
18  プロセス    Webサーバーのプロセス数   Webサーバー pgrep -x -c 1分  ―   0個  2回  高   当番へ電話＋チャット  サービスを起動し、止まった理由をログで確認
19  プロセス    アプリケーションのプロセス数  APサーバー  pgrep -x -c 1分  想定数より少ない    0個  2回  高   当番へ電話＋チャット  サービスを起動し、止まった理由をログで確認
20  プロセス    DBのプロセス数    DBサーバー  pgrep -x -c 1分  ―   0個  1回  高   当番へ電話＋チャット  DBのログを確認してから起動手順に従う
21  プロセス    サービスの状態 各サービス   systemctl is-active 1分  ―   active 以外   2回  高   当番へ電話＋チャット  systemctl status で状態と直近のログを確認
22  プロセス    ゾンビプロセス数    全サーバー   ps -eo stat 10分 10個以上   50個以上   3回  低   日次レポート  親プロセスを特定して状態を確認
23  プロセス    プロセスのメモリ使用量 APサーバー  ps -o rss   5分  想定値の1.5倍以上  想定値の2倍以上    3回  中   チャット（運用チャンネル）   増え続けているかを推移で確認、再起動を検討
24  ポート Web（80 / 443）   Webサーバー ss -ltn / 外部からのTCP接続    1分  ―   接続できない  2回  高   当番へ電話＋チャット  プロセスと待ち受けアドレスを確認
25  ポート アプリケーション（例：8080）    APサーバー  ss -ltn / TCP接続 1分  ―   接続できない  2回  高   当番へ電話＋チャット  プロセスの状態とログを確認
26  ポート DB（例：5432 / 3306）   DBサーバー  ss -ltn / TCP接続 1分  ―   接続できない  2回  高   当番へ電話＋チャット  DBのプロセスとログを確認
27  ポート SSH（22） 全サーバー   TCP接続   5分  ―   接続できない  2回  中   チャット（運用チャンネル）   コンソールから sshd の状態を確認
28  ポート 待ち受けキューのあふれ Web・APサーバー  ss -ltn の Recv-Q    1分  Send-Q の70%以上   Send-Q と同じ値 3回  中   チャット（運用チャンネル）   処理待ちが増えた原因（応答時間・スレッド数）を確認
29  URL トップページの応答コード    公開URL   curl -w %{http_code}    1分  ―   200 以外  2回  高   当番へ電話＋チャット  Webサーバー・APサーバーの順に切り分け
30  URL ヘルスチェック用URL 各APサーバー curl と本文の照合 1分  ―   200 以外または本文が不一致 2回  高   当番へ電話＋チャット  該当サーバーを振り分け先から外して調査
31  URL 応答時間    主要な画面・API   curl -w %{time_total}   1分  1秒以上    3秒以上    3回  中   チャット（運用チャンネル）   遅いリクエストとDBの処理時間を確認
32  URL ログイン処理  ログイン画面  シナリオ（ログインして表示を確認）   5分  3秒以上    ログインできない    2回  高   当番へ電話＋チャット  認証まわりのサービスとDBを確認
33  URL 5xxの割合  Web・APサーバー  アクセスログの集計   1分  1%以上    5%以上    3回  高   当番へ電話＋チャット  エラーの出ているURLと直前の変更を確認
34  URL 外部連携先のAPI   連携先のURL curl -w %{http_code}    5分  応答 2秒以上 200 以外  2回  中   チャット（運用チャンネル）   連携先の稼働情報を確認、再送の要否を判断
35  ログ  アプリケーションのERROR件数    アプリケーションログ  grep -c / 集計    5分  5分間に5件以上    5分間に50件以上   1回  中   チャット（運用チャンネル）   多いメッセージの上位を確認
36  ログ  特定の文字列（メモリ不足など） アプリケーションログ  grep -E 1分  ―   1件以上    1回  高   当番へ電話＋チャット  該当プロセスの状態を確認、再起動を検討
37  ログ  OSのエラー（優先度 err 以上）  システムログ  journalctl -p err   5分  1件以上    10件以上   1回  中   チャット（運用チャンネル）   メッセージの内容と発生源のユニットを確認
38  ログ  メモリ不足による強制終了    カーネルログ  journalctl -k -g    5分  ―   1件以上    1回  高   当番へ電話＋チャット  終了したプロセスとメモリの推移を確認
39  ログ  認証の不成立の回数   認証ログ    journalctl -u ssh / 集計  5分  5分間に20件以上   5分間に100件以上  1回  中   チャット（運用チャンネル）   送信元を確認し、接続制限を検討
40  ログ  DBの遅いSQL    DBのログ   スロークエリログの集計 5分  5分間に10件以上   5分間に100件以上  2回  中   チャット（運用チャンネル）   該当SQLと実行計画を確認
41  ログ  ログが出ていない    アプリケーションログ  最終更新時刻（find -mmin）  5分  10分間更新なし    30分間更新なし    1回  中   チャット（運用チャンネル）   プロセスの状態とログの出力先を確認
42  証明書・期限  TLS証明書の残り日数 公開URL   openssl x509 -enddate   1日  30日以内   14日以内   1回  中   チャット（運用チャンネル）   更新手続きを開始、自動更新の状態を確認
43  証明書・期限  内部用証明書の残り日数 内部のAPI・DB接続 openssl x509 -checkend  1日  30日以内   14日以内   1回  中   チャット（運用チャンネル）   発行元に更新を依頼
44  証明書・期限  ドメインの有効期限   利用中のドメイン    管理画面の期限日    1日  60日以内   30日以内   1回  中   チャット（運用チャンネル）   更新手続きと自動更新の設定を確認
45  証明書・期限  APIキー・パスワードの期限  外部連携・サービス用アカウント 台帳の期限日から計算  1日  30日以内   7日以内    1回  中   チャット（運用チャンネル）   新しいキーを発行し、切り替え日を調整
46  ジョブ 終了コード   各バッチジョブ 状態ファイルまたは終了コード  終了時 ―   0 以外    1回  高   当番へ電話＋チャット  ジョブのログを確認し、再実行の可否を手順書で判断
47  ジョブ 終了していない（遅延） 各バッチジョブ 予定終了時刻と状態ファイルの照合    5分  予定の1.5倍の時間  予定の2倍の時間    1回  中   チャット（運用チャンネル）   処理件数と進み具合を確認
48  ジョブ 起動していない 各バッチジョブ 状態ファイルの更新時刻（find -mmin） 予定時刻の後  ―   予定時刻から15分たっても開始なし   1回  高   当番へ電話＋チャット  スケジューラの状態を確認し、手動で起動
49  ジョブ 処理件数    各バッチジョブ ジョブの出力する件数  終了時 前日比 ±30%以上  0件  1回  中   チャット（運用チャンネル）   入力データの有無と取り込み元を確認
50  ジョブ バックアップの完了   バックアップジョブ   ファイルの更新時刻とサイズ   1日  サイズが前回比 ±30%以上  24時間以内のファイルなし   1回  高   当番へ電話＋チャット  バックアップのログを確認し、再取得

各項目をLinuxのコマンドで確かめる

一覧の「取得方法」を、実際のコマンドと出力で確かめます。監視ツールを入れる前でも、手で打って値が取れるかを見ておくと、しきい値の単位や判定の向きを取り違えにくくなります。 出力例のポート 9690 は、確認用に立てたWebサーバーのものです。

死活監視：ping

ping -c 3 -W 2 127.0.0.1

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.015 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.023 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.029 ms

--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2053ms
rtt min/avg/max/mdev = 0.015/0.022/0.029/0.005 ms

見る場所は2つです。packet loss が損失率、rtt の avg が平均の応答時間です。-c は送る回数、-W は応答を待つ秒数です。

再起動の検知には uptime を使います。稼働時間が短ければ、直前に再起動があったとわかります。

uptime

 22:00:54 up 9 min,  0 user,  load average: 0.77, 1.12, 0.58

リソース監視：vmstat・free・df

CPU使用率は、vmstat の id（何もしていない割合）を100から引いて求めます。1行目は起動してからの平均なので、2行目以降を使います。

vmstat 1 3

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 2  0      0 3314856 625936 3350016    0    0  3306  4534 2365   43 15  6 76  3  0  0
 1  0      0 3159004 625936 3350124    0    0     0    52 2353 8638 32 26 42  0  0  0
 0  0      0 3183956 625936 3350160    0    0    36   248 1599 2085 13  9 78  0  0  0

数値だけを取り出すときは、最後の行の15列目（id）を使います。

vmstat 1 2 | tail -n 1 | awk '{print 100 - $15}'

28

ロードアベレージは、コア数と比べて判断します。

nproc
cat /proc/loadavg

2
0.77 1.12 0.58 3/148 6097

左から1分・5分・15分の平均です。コア数が2なので、一覧のしきい値「コア数 × 1.0」は 2.0、「コア数 × 2.0」は 4.0 になります。

メモリは free の available（新しく使える見込みの量）で判断します。free の列は、キャッシュに使っている分を含まないため、空きが少なく見えます。

free -m

               total        used        free      shared  buff/cache   available
Mem:            8031        1409        3109          72        3882        6621
Swap:              0           0           0

使用率は「（total − available）÷ total」で求めます。上の値では（8031 − 6621）÷ 8031 = 17.6% です。コマンド1行で出すなら次のようにします（実行のたびに値は少し変わります）。

free -m | awk '/^Mem:/ {printf "%.1f\n", ($2 - $7) / $2 * 100}'

16.3

ディスクは使用率とiノード（ファイルの数の枠）の両方を見ます。

df -h /
df -i /
df --output=pcent,target / | tail -n 1

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda        252G   35G  7.6G  82% /

Filesystem       Inodes  IUsed    IFree IUse% Mounted on
/dev/vda       16777216 802717 15974499    5% /

 82% /

この環境の使用率は82%で、一覧の警告（80%以上）に当たります。容量に余裕があってもiノードが尽きるとファイルを作れなくなるため、df -i も項目に入れておきます。

開いているファイル数は /proc/sys/fs/file-nr で確かめられます。左が現在の数、右が上限です。

cat /proc/sys/fs/file-nr

534 0   819756

プロセス監視：pgrep・ps

pgrep -x -c は、名前が完全に一致するプロセスの数を返します。

pgrep -x -c postgres; echo "exit=$?"
pgrep -x -c nosuchproc; echo "exit=$?"

6
exit=0
0
exit=1

見つからないときは 0 を表示し、終了コードが 1 になります。 監視スクリプトでは、数（0個かどうか）と終了コードのどちらでも判定できます。プロセスごとの状態・稼働時間・メモリ使用量（RSS、単位はキロバイト）は ps で取れます。

ps -o pid,stat,etime,rss,cmd -p 6060

  PID STAT     ELAPSED   RSS CMD
 6060 SN         00:05 19664 python3 -m http.server 9690 --bind 127.0.0.1

ゾンビプロセス（終了したのに親プロセスが後始末をしていない状態）の数は、状態が Z で始まる行を数えます。

ps -eo stat | grep -c '^Z'

5

systemd で管理しているサービスは、systemctl is-active サービス名 で状態を確かめられます。ヘルプには次のように載っています。

  is-active PATTERN...                Check whether units are active
  is-failed [PATTERN...]              Check whether units are failed or
  status [PATTERN...|PID...]          Show runtime status of one or more units

ポート監視：ss とTCP接続

サーバーの中からは ss -ltn で待ち受けの有無を見ます（-l 待ち受け中、-t TCP、-n 番号で表示）。

ss -ltn 'sport = :9690'
ss -ltn 'sport = :9691'

State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0      5          127.0.0.1:9690      0.0.0.0:*          

State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess

待ち受けがあれば LISTEN の行が出て、なければ見出しだけになります。Local Address が 127.0.0.1 のときは、そのサーバーの中からしか接続できません。 外から使うポートは、0.0.0.0 や公開用のアドレスで待ち受けているかも確かめます。

外側からの確認は、実際にTCP接続を試します。bash だけでも次のように書けます。

timeout 3 bash -c '</dev/tcp/127.0.0.1/9690' && echo open || echo closed
timeout 3 bash -c '</dev/tcp/127.0.0.1/9691' && echo open || echo closed

open
bash: connect: Connection refused
bash: line 1: /dev/tcp/127.0.0.1/9691: Connection refused
closed

URL監視：curl

curl の -w で、応答コードと応答時間を1行で取り出せます。-m 5 は全体の制限時間（秒）です。

curl -s -o /dev/null -m 5 -w '%{http_code} %{time_total}\n' http://127.0.0.1:9690/health
curl -s -o /dev/null -m 5 -w '%{http_code} %{time_total}\n' http://127.0.0.1:9690/none
curl -s -o /dev/null -m 5 -w '%{http_code}\n' http://127.0.0.1:9691/health; echo "exit=$?"

200 0.004004
404 0.000806
000
exit=7

応答コードが200でも、中身がエラー画面ということもあります。ヘルスチェック用URLは、本文に決まった文字列が含まれるかまで確かめると、より確かになります。

curl -s -m 5 http://127.0.0.1:9690/health | grep -c '^ok$'

1

ログ監視：grep と journalctl

次のアプリケーションログ（app.log）を例にします。

2026-10-05 09:58:12 INFO  request done path=/items status=200 ms=41
2026-10-05 09:58:40 WARN  slow query ms=1840 sql=select_items
2026-10-05 09:59:03 ERROR db connection timeout host=db01
2026-10-05 09:59:31 INFO  request done path=/items status=200 ms=38
2026-10-05 10:00:02 ERROR db connection timeout host=db01
2026-10-05 10:00:45 ERROR OutOfMemoryError: Java heap space
2026-10-05 10:01:10 INFO  request done path=/login status=200 ms=55
2026-10-05 10:02:27 ERROR db connection timeout host=db01

ERROR の件数、特定の時刻以降の件数、見逃したくない文字列の有無、メッセージごとの件数を順に取ります。

grep -c ' ERROR ' app.log
awk '$2 >= "10:00:00" && $3 == "ERROR"' app.log | wc -l
grep -E -c 'OutOfMemoryError|Too many open files' app.log
grep ' ERROR ' app.log | cut -d' ' -f4- | sort | uniq -c | sort -rn

4
3
1
      3 db connection timeout host=db01
      1 OutOfMemoryError: Java heap space

ログ監視のしきい値は「件数で見るもの」と「1件でも出たら知らせるもの」に分けます。 接続のタイムアウトのように一時的に出ることがあるメッセージは件数で、メモリ不足のように1件で対応が要るメッセージは文字列で見ます。最後のコマンドのようにメッセージ別に集計しておくと、一次対応で「何が多いか」をすぐ確かめられます。

systemd のログ（ジャーナル）は journalctl で絞り込みます。ヘルプに載っている、監視でよく使うオプションは次のとおりです。

  -S --since=DATE            Show entries not older than the specified date
  -u --unit=UNIT             Show logs from the specified unit
  -p --priority=RANGE        Show entries with the specified priority
  -g --grep=PATTERN          Show entries with MESSAGE matching PATTERN
  -k --dmesg                 Show kernel message log from the current boot
  -n --lines[=[+]INTEGER]    Number of journal entries to show
     --no-pager              Do not pipe output into a pager

ログが出ていないことも異常の手がかりになります。ファイルの更新時刻で確かめる方法は、次のジョブ監視と同じです。

証明書期限の監視：openssl

証明書ファイルの期限は -enddate で、動いているサーバーの証明書は s_client でつないで確かめます。例では、確認用に有効期間20日の証明書を作り、ポート 9691 でHTTPSサーバーを動かしています。

openssl x509 -in cert.pem -noout -enddate
echo | openssl s_client -connect 127.0.0.1:9691 -servername localhost 2>/dev/null | openssl x509 -noout -enddate

notAfter=Oct 25 13:01:24 2026 GMT
notAfter=Oct 25 13:01:24 2026 GMT

-checkend 秒数 は、「その秒数のうちに期限が来るか」を終了コードで返します。30日（2,592,000秒）と14日（1,209,600秒）で試した結果です。

openssl x509 -in cert.pem -noout -checkend $((30*86400)); echo "exit=$?"
openssl x509 -in cert.pem -noout -checkend $((14*86400)); echo "exit=$?"

Certificate will expire
exit=1
Certificate will not expire
exit=0

残り20日の証明書なので、30日のしきい値（警告）には当たり、14日のしきい値（異常）にはまだ当たらないという結果です。残り日数を数値で出すなら、次のように計算します。

end=$(openssl x509 -in cert.pem -noout -enddate | cut -d= -f2)
echo $(( ($(date -d "$end" +%s) - $(date +%s)) / 86400 ))

19

ジョブ監視：終了コードと状態ファイル

バッチジョブは、終了コードと終了時刻を状態ファイルに残すようにしておくと、監視する側は同じ方法で確かめられます。

#!/bin/bash
# 夜間ジョブの例：終了コードと終了時刻を状態ファイルに残す
start=$(date +%s)
sleep 1            # ここに本来の処理を書く
rc=$?
end=$(date +%s)
echo "job=nightly_export rc=$rc start=$start end=$end sec=$((end - start))" > job_status.txt
exit $rc

./nightly_job.sh
cat job_status.txt
grep -o 'rc=[0-9]*' job_status.txt
find job_status.txt -mmin -1440 | wc -l
find job_status.txt -mmin +1440 | wc -l

job=nightly_export rc=0 start=1791205285 end=1791205286 sec=1
rc=0
1
0

find -mmin -1440 は「1440分（24時間）以内に更新されたファイル」を返します。1 なら24時間以内にジョブが終わっており、0 なら終わっていない（または起動していない）とわかります。 終了コードだけを見ていると「そもそも起動しなかった」ことに気づけないため、更新時刻とあわせて見るのがポイントです。

しきい値を決める考え方

一覧のしきい値は出発点です。次の4つの手順で、自分のシステムに合う値にしていきます。

警告と異常の2段階にする理由は、対応の急ぎ方が違うからです。 警告は「営業時間内に確認すれば間に合う水準」、異常は「すぐに対応を始める水準」と決めておくと、通知先や時間帯を分けられます。

割合で見るか、残りの量で見るか

ディスクのように大きさが環境で違う項目は、割合だけで決めると実態に合わないことがあります。

増え方が一定の項目は、「このペースで増えるとあと何日で満杯か」を見るほうが、対応の時期を決めやすくなります。一覧の No.12「ディスクが満杯になるまでの日数」がこの見方です。

継続回数で通知の数を整える

一瞬だけしきい値を超えて、すぐ戻る値は珍しくありません。「何回続いたら通知するか」を決めておくと、対応が要らない通知を減らせます。 1分ごとのCPU使用率16回分に、継続回数を変えて当てはめてみます。

"""継続回数の効果：同じ測定値に「1回で通知」「3回続いたら通知」を当てて比べる"""
cpu = [42, 55, 91, 48, 51, 88, 93, 47, 50, 86, 90, 92, 95, 94, 60, 45]  # 1分ごとのCPU使用率(%)
THRESHOLD = 85

def alerts(values, threshold, need):
    """need 回続けてしきい値以上になった時点（分）を返す。下回ったら数え直す"""
    fired, streak, active = [], 0, False
    for minute, v in enumerate(values, start=1):
        streak = streak + 1 if v >= threshold else 0
        if streak >= need and not active:
            fired.append(minute)
            active = True
        if streak == 0:
            active = False
    return fired

for need in (1, 2, 3, 5):
    a = alerts(cpu, THRESHOLD, need)
    print(f"継続回数 {need}回: 通知 {len(a)}件  発生した分 = {a}")

継続回数 1回: 通知 3件  発生した分 = [3, 6, 10]
継続回数 2回: 通知 2件  発生した分 = [7, 11]
継続回数 3回: 通知 1件  発生した分 = [12]
継続回数 5回: 通知 1件  発生した分 = [14]

継続回数を増やすと通知は減りますが、そのぶん気づくのが遅れます。「間隔 × 継続回数」が、異常が起きてから通知されるまでの時間です。 一覧では、一時的に上がりやすいCPU・メモリは5回、止まったらすぐ知りたいプロセスやポートは1〜2回としています。

重要度別の通知ルール表のひな形

項目ごとに通知先を書くと、担当の変更のたびに一覧全体を直すことになります。一覧には重要度だけを書き、通知先はこの表で一括して決めると、保守がしやすくなります。

表計算ソフト用のTSVです。

重要度 状態の目安   通知の手段   通知する時間帯 最初の応答の目標    応答がないとき
高   利用者に影響が出ている、またはすぐ出る 当番へ電話＋チャット  24時間    15分以内   15分後に副当番、30分後に責任者へ
中   余裕が減っている。放置すると影響が出る チャット（運用チャンネル）   営業時間内   当日中 翌営業日の朝会で担当を決める
低   傾向として知っておきたい    日次レポート  営業時間内   週次の確認で対応を決める    ―

通知ルールとあわせて、次の3点も決めておくと運用が安定します。

一覧を育てるための見直しポイント

すべての通知に「受けた人が何をするか」が書かれている状態を目標にします。 一次対応が書けない項目は、通知ではなくグラフで見るだけの項目にするという整理もできます。

よくある質問

Q. 監視項目は多いほどよいですか？ A. 数よりも、通知を受けて動けるかどうかが大切です。まず利用者に近い項目（URL・ポート）と、止まると影響の大きい項目（ディスク・プロセス・ジョブ）から始め、出来事があるたびに足していく進め方が続けやすいです。

Q. CPU使用率のしきい値は80%が正解ですか？ A. 一律の正解はありません。バッチ処理でCPUを使い切るのが正常なサーバーもあります。平常時の値を1〜2週間見て、ふだんの最大値より少し上に置き、継続回数とあわせて調整します。

Q. 警告と異常で通知先を分けるべきですか？ A. 分けることをおすすめします。警告はチャット、異常は電話、というように手段を変えると、急ぎの通知が埋もれにくくなります。

Q. 監視ツールを決めていなくても、この一覧は作れますか？ A. 作れます。項目・しきい値・通知先は道具に依らない設計なので、先に一覧を作り、あとからツールの設定に置き換えられます。取得方法の列は、ツールが決まったらその機能名に書き換えてください。

まとめ

• 監視設計は「何を・どう測り・いくつで・誰に・最初に何をするか」を一覧にする作業
• 8分類（死活・リソース・プロセス・ポート・URL・ログ・証明書期限・ジョブ）を組み合わせ、内側と外側の両方から見る
• しきい値は警告と異常の2段階にし、限界・目標・平常時の値・対応にかかる時間から決める
• 継続回数を決めると通知の数を整えられる。間隔 × 継続回数が、通知までの時間になる
• 一覧には重要度だけを書き、通知先は通知ルール表で一括して決めると保守しやすい
• コマンドで手で確かめてから設定すると、単位や判定の向きを取り違えにくい
• 対応が要らなかった通知を月に一度数え、しきい値・継続回数・重要度を見直す

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。