平常値を知る——ベースラインという武器
「いつもと違う」と言うには「いつも」の値を知っている必要があります。vmstatやsar（sysstat）で負荷・メモリ・I/Oの平常値を定点観測し、メモしておくことをベースラインと呼びます。障害時はこのベースラインとの差分を見るだけで、切り分けが一気に速くなります。cronによる自動収集など、簡単に続けられる仕組みも押さえます。
「このロードアベレージ、高いんですか？」と聞かれて、即答できるだろうか。実はこの質問、そのサーバの「いつも」を知らないと答えようがない。
ロードアベレージが3.0だとして、4コアの静かなWebサーバなら異常事態だが、32コアのバッチ処理専用機なら平常運転かもしれない。数字そのものに絶対的な「高い」「低い」はなく、常にそのシステムの普段の値との比較でしか語れない。
この「いつも」の値のことを、ベースライン（平常値）と呼ぶ。
📏 vmstat・sarで定点観測する
ベースラインを作るには、普段の状態を定期的に記録しておく必要がある。すでに紹介した vmstat は、その場で一時的に流れを見るのに向いているが、時間をおいた比較には別の道具が向く。
それが sar（System Activity Reporter）だ。sysstat というパッケージに含まれ、CPU・メモリ・ディスクI/O・ネットワークなど、システムの様々な活動状況を記録・報告してくれる。
sar は -u でCPU、-r でメモリ、-d でディスクI/O、-n DEV でネットワークというように、見たい対象を切り替えて表示できる。1つのコマンドで多角的な指標を扱えるのが強みで、CPU・メモリ・I/Oをそれぞれ別のツールで確認していた手間が1本化される。
📓 負荷・メモリ・I/Oの平常値をメモしておく
ツールが揃っても、記録して終わりでは意味がない。大切なのは、平常時の値を意識的に控えておくことだ。
構えて統計を取らなくても、日々の作業のついでにメモを残すだけで十分な効果がある。「平日昼間はロードアベレージ0.3〜0.6くらい」「availableは常時2GB以上ある」「iostatのawaitは通常10ms未満」といった具合に、ざっくりとした範囲感で構わない。
ベースラインは一度きりの記録では不十分な面もある。平日と週末、昼と深夜、月初のバッチ処理が走る日など、時間帯や曜日によって「いつも」の姿が変わるシステムは多い。可能であれば、複数のタイミングでの値を押さえておくと、より的確な比較ができる。
複数台のサーバを運用している場合は、同じ役割のサーバ同士でベースラインを比べる視点も有効だ。同じ構成・同じ負荷のはずの2台で、片方だけ数値が明らかに違えば、その1台に固有の問題があると見当を付けやすい。
⚡ 障害時は差分で切り分けが速くなる
実際に障害が起きたとき、ベースラインを知っているかどうかで調査速度はまるで違う。
ベースラインがなければ、目の前の数値が異常かどうかの判断そのものに時間がかかる。ロードアベレージ5.0を見ても「これは異常なのか、いつも通りなのか」から悩んでしまう。
ベースラインがあれば、比較は一瞬だ。「いつもは0.5前後なのに今は9.8」「awaitはいつも1桁msなのに今は200ms超え」――差分がそのまま異常のシグナルになる。どの指標が普段からいちばん外れているかを見れば、ボトルネックの当たりも自然と絞れる。
⏰ cronでsarを自動収集する仕組み
メモを手作業で続けるのは面倒だし、忘れることもある。幸い、多くのディストリビューションではsysstatパッケージをインストールすると、cron（自動-cron）ジョブによる定期収集があらかじめ設定されている。
一定間隔（多くは10分おき）でシステムの活動状況を自動的に記録し、日ごとのデータとして保存してくれる。これにより、特別な準備なしに、過去数日〜数週間分のベースラインが自動的に蓄積されていく。
ただし記録は無限に貯まり続けるわけではない。多くの設定では保存期間に上限があり、古いデータは順次消えていく。長期的な傾向（先月と比べて負荷が上がってきている、など）まで追いたい場合は、保存期間の設定を見直すか、別途グラフ化ツールと組み合わせて長期保存する運用も検討する価値がある。
平常値というのは、地味だが実務でいちばん効くツールの1つだ。障害が起きてから慌てて調べるのではなく、平穏なときにこそ vmstat や sar でシステムの「普段の顔」を記録しておく。この積み重ねが、いざというときの切り分け速度を大きく左右する。