設計
syslog サーバのディスク容量はどれくらい必要？ 見積もりの計算式
syslog サーバを立てる前に必ず聞かれるのが「ディスクはどれだけ要りますか」です。答えは環境次第 —— ですが、見積もりの計算式は一つに決まっています。本稿では計算式と規模別の試算例を示し、見積もりを狂わせる要因と、あふれさせないための設計までを解説します。
見積もりの計算式
必要容量は次の式で見積もります。
必要容量 ≒ EPS × 平均メッセージサイズ × 86,400（秒/日） × 保持日数 × 余裕係数- EPS（Events Per Second）—— 毎秒の受信メッセージ数の平均
- 平均メッセージサイズ —— syslog は 1 件おおむね 100〜400 バイト程度。見積もりでは 300 バイト程度を置くと安全側です
- 余裕係数 —— データベースのオーバーヘッドと変動分。後述のとおり 2〜3 倍を見込みます
EPS の当たりを付ける
EPS は環境差が最も大きい変数です。目安として、通常レベル（Informational まで）の設定なら、スイッチや AP は平常時 1 台あたり毎分数件〜数十件程度に収まることが多く、ファイアウォールはトラフィックログを送るかどうかで桁が変わります。
机上で悩むより、数日間実際に受信して実測するのが確実です。受信側に統計画面があれば（Yagura ならダッシュボードとシステム状態画面）、日次の受信件数からそのまま EPS を割り出せます。
規模別の試算例
| 規模のイメージ | EPS | 1 日あたり（生データ） | 保持 30 日 | 保持 180 日 |
|---|---|---|---|---|
| 小規模（機器 10〜20 台） | 2 | 約 52 MB | 約 3 GB | 約 19 GB |
| 中規模（機器 50 台前後 + サーバ群） | 10 | 約 259 MB | 約 16 GB | 約 93 GB |
| FW のトラフィックログも送る場合 | 100 | 約 2.6 GB | 約 156 GB | 約 933 GB |
見てのとおり、通常の機器ログだけなら容量は拍子抜けするほど小さく、今どきのサーバなら誤差の範囲です。桁が変わるのは、トラフィックログや Windows イベントログのような大量ソースを加えたときです。
データベースのオーバーヘッドを見込む
受信した生データをデータベースに保存すると、インデックスや管理領域の分だけ実消費は膨らみます。実効で生データの 2〜3 倍を見込んでおけば、まず不足しません。上の試算表はすでに 2 倍を織り込んだ値です。
また、保存先の選択も容量設計の一部です。Yagura は内蔵 SQLite で始めて、ログ量が育ったら管理画面のウィザードで SQL Server へ昇格できるため、「最初から大きな器を用意する」必要がありません。
見積もりを狂わせる急増要因
平均で見積もった容量は、次のような事態で一気に食い潰されることがあります。
- Debug レベルでの送りっぱなし —— 調査のために下げたレベルの戻し忘れ（機器設定の記事参照）
- 障害時のログ嵐 —— リンクのフラッピングや認証失敗のループで、特定機器が突然大量に送り始める
- 集約対象の追加 —— サーバ群やトラフィックログを後から加えて、前提の EPS が変わる
対策は、送信元ホスト別の受信件数を日頃から眺められるようにしておくことです。急増はグラフを見れば一目で分かります。
あふれさせない設計 — 保持期間の自動削除
最後の砦は保持期間の自動削除です。「気づいたらディスクが満杯でサーバごと停止」が、ログ基盤の最悪の障害だからです。保持日数を決め（考え方は 保存期間の記事へ）、古いログが自動で消える仕組みを最初から有効にしておきます。Yagura は既定 30 日の自動削除が有効で、日数も実行時間帯も変更できます。さらに、保存先 DB の障害時にはディスクスプールへ退避して復旧後に取り込む仕組みもあり、「あふれ」と「消失」の両方に備えられます。