「何かあってから」では遅すぎる
こんにちは！「リナックス先生」です。
今回からは、インフラエンジニアにとって地味ながらも「生命線」と言える技術、「統合ログ管理サーバー」の構築に挑戦します。全5回の大型連載です。
先生、質問です！
最近、管理するサーバーが10台に増えたんですけど、毎日1台ずつSSHでログインして /var/log/messages を確認するのが苦痛すぎます…。
これ、もっと楽にする方法はないんですか？
いいところに気がついたわね。
サーバーが10台ならまだマシだけど、50台、100台、そこにネットワーク機器も加わったら、人力での確認は不可能よ。
それに、もしサーバーがハッキングされてログごと消されたら、どうやって犯人を追跡するの？
あ…！サーバー内のログが消されたら、何も証拠が残らないですね…。
それはマズイです。
そのために必要なのが「統合ログ管理サーバー（Syslogサーバー）」よ。
今回はAlmaLinux 9と標準ツールの「Rsyslog」を使って、あらゆる機器のログを一元管理するシステムを作るわ。
第1回は、手を動かす前の「設計編」よ。ここが一番大事だからしっかりついてきなさい！
1. 統合ログサーバー構築の目的とメリット
構築を始める前に、「なぜログを集めるのか」を明確にしておきましょう。設計の方向性がブレないようにするためです。
ログ収集の3つの柱
- 障害対応の迅速化（Troubleshooting）
- ネットワーク障害時、スイッチ、ルーター、サーバーのログを時系列で横断的に見ることで、「どこが最初にコケたか」を一瞬で特定できます。
- 証拠保全とセキュリティ（Security & Forensics）
- サーバーへの不正侵入時、攻撃者はまず痕跡（ログ）を消そうとします。ログサーバーにリアルタイム転送しておけば、手元のログが消されても「転送先」に証拠が残ります。
- 監査対応とコンプライアンス（Audit）
- ISMS（ISO27001）やPCI-DSSなどのセキュリティ基準では、ログの長期保存と定期的なレビューが義務付けられています。「いつ、誰が、何をしたか」を証明する唯一の手段です。
2. システム構成と要件定義
今回の連載で構築するシステムの全体像を定義します。
実務で「基本設計書」に書くレベルの内容です。
| 項目 | 要件・仕様 | 理由・備考 |
|---|---|---|
| OS | AlmaLinux 9.x (64bit) | RHEL 9互換でサポート期間が長く（2032年まで）、安定性が高いため。 |
| ミドルウェア | Rsyslog (OS標準) | CentOS/RHEL系でのデファクトスタンダード。設定の柔軟性が高い。 |
| 収集対象 | Linuxサーバー、Ciscoルーター、Firewall、Windows(Agent経由) | マルチベンダー環境を想定。 |
| 受信プロトコル | UDP 514 / TCP 514 | あらゆる機器に対応するため両方開放する。 |
| 保存ルール | /var/log/remote/ホスト名/ログファイル | 機器ごとにディレクトリを分割し、混在を防ぐ。 |
| 保存期間 | ローカル：1年 NFS：無期限（容量許す限り） |
監査要件（最低1年）を満たすため。 |
3. プロトコル設計：UDPとTCPの使い分け
Syslog転送には、大きく分けてUDPとTCPの2つの通信方式があります。
「とりあえずUDPで」と適当に決めるのは素人のやることです。それぞれの特性を理解して使い分けましょう。
UDP (User Datagram Protocol) – RFC 5426
- 特徴： 「送りっぱなし」のプロトコル。相手が受け取ったか確認しません。
- メリット： オーバーヘッドが小さく、ネットワーク帯域を圧迫しにくい。送信側のCPU負荷も低い。
- デメリット： ネットワークが混雑すると、ログが「迷子（パケットロス）」になっても気づけません。
- 採用基準：
- 大量のアクセスログ（ウェブアクセスなど）
- 古いネットワーク機器（UDPしか対応していない場合が多い）
- 「多少欠損しても、全体傾向がわかればいい」ログ
TCP (Transmission Control Protocol) – RFC 6587
- 特徴： 「到達確認（ACK）」を行うプロトコル。相手が受け取るまで再送を試みます。
- メリット： 信頼性が高い。ログの欠損をほぼ防げる。
- デメリット： 通信の往復が発生するため、大量のログが発生すると送信側の動作が重くなる可能性がある。
- 採用基準：
- 認証ログ、決済ログなどの「1行たりとも失ってはいけない」重要ログ
- WAN越え（インターネット経由）での転送
【設計の結論】
今回のサーバーでは「UDPとTCP、両方のポート(514番)を開ける」構成にします。
基本は信頼性の高いTCPを使い、TCP非対応の古いルーターなどはUDPで受け取る、という「いいとこ取り」のハイブリッド構成よ。
4. Syslogファシリティとプライオリティの理解
ログサーバーを設計する上で避けて通れないのが「ファシリティ（Facility）」と「プライオリティ（Priority）」です。
これはログにつけられる「タグ」のようなものです。
ファシリティ（ログの種類・発生元）
Linuxやネットワーク機器は、ログを送る際に「これは何系のログですよ」という情報を付与します。
| 値 | キーワード | 内容・用途 |
|---|---|---|
| 0 | kern | カーネルメッセージ |
| 4 | auth / authpriv | 認証・セキュリティ関連（SSHログインなど） |
| 9 | cron | Cronジョブの実行ログ |
| 10 | authpriv | 認証関連（プライベート） |
| 16-23 | local0 〜 local7 | 【超重要】 ユーザー独自の用途 |
★ここがポイント！
ネットワーク機器（Ciscoなど）のログ設計では、この local0 〜 local7 を活用します。
例えば、「ファイアウォールのログは local0 で送る」「スイッチのログは local1 で送る」と送信側で設定しておけば、受信側のRsyslogで「local0なら /var/log/firewall.log に保存する」といった振り分けが可能になります。
プライオリティ（重要度・深刻度）
ログの緊急性を示します。設定ファイルで「どのレベル以上を記録するか」を決める際に使います。
- emerg (0): システム使用不可（パニック状態）
- alert (1): 直ちに対処が必要
- crit (2): 致命的なエラー（ハードウェア故障など）
- err (3): 一般的なエラー
- warning (4): 警告（エラーではないが注意）
- notice (5): 通常だが重要な情報
- info (6): 情報メッセージ（通常の操作ログなど）
- debug (7): デバッグ情報（開発用、量が膨大）
なるほど！
「info」レベルにしておけば、「warning」や「err」も全部含まれるってことですね。
逆に「debug」にすると、ディスクが一瞬で埋まりそうで怖いです…。
5. サイジング（ディスク容量の計算）
ログサーバー構築で一番失敗するのが「ディスク容量不足」です。
なんとなく決めるのではなく、論理的に計算しましょう。
計算式（見積もりの公式）
必要容量 ＝ (1行あたりの平均バイト数) × (1秒間のログ行数：EPS) × (保存日数) × (台数) × (安全係数)
計算例
ある企業のネットワーク機器とサーバー合わせて50台を想定します。
- 1行のサイズ： 日本語含め平均 200 Bytes と仮定
- EPS (Events Per Second)： 1台あたり平均 5行/秒（ピーク時考慮）
- 保存期間： 365日（1年）
- 台数： 50台
200 Bytes × 5 EPS × 60秒 × 60分 × 24時間 ＝ 約86.4 MB/日（1台あたり）86.4 MB × 50台 ＝ 約4.3 GB/日（全体）4.3 GB × 365日 ＝ 約1.57 TB（年間）
結果： 1.5TBの容量が必要です。
ただし、テキストログは gzip 圧縮すると約1/10〜1/20に圧縮できます。
Logrotateで毎日圧縮する運用なら、「生ログ用 200GB ＋ 過去ログ用 200GB ＝ 合計500GB」 程度あれば、1年分はギリギリ入ると試算できます。
【プロの助言】
ディスクは「容量」だけでなく「書き込み速度（IOPS）」も重要よ。
50台から同時にログが書き込まれると、HDD（ハードディスク）では処理が追いつかなくなることがあるわ。
最近のVPSはSSDが標準だから安心だけど、オンプレミスで作るなら絶対にSSDを選びなさい。
6. ディレクトリ構造の決定
最後に、サーバー内部のディレクトリ構造を決めます。/var/log/ 直下にすべてのファイルを置くと、ファイル数が数万個になり、ls コマンドすら返ってこなくなります。
今回は、Rsyslogのテンプレート機能を駆使して、以下のような「階層型ディレクトリ」を自動生成させます。
/var/log/remote/
├── 192.168.10.1 (Webサーバー)
│ ├── 2026-01-01-messages.log
│ ├── 2026-01-01-secure.log
│ └── 2026-01-02-messages.log
├── 192.168.20.254 (Coreルーター)
│ ├── 2026-01-01-syslog.log
│ └── 2026-01-02-syslog.log
└── firewall-01 (FW)
└── ...
この構成のメリット：
- ホストごとにフォルダが分かれるので管理しやすい。
- 日付がファイル名に入るので、過去ログを探しやすい。
- 「1年前のフォルダごと消す」といった掃除が楽。
次回予告：いよいよ構築開始！
お疲れ様でした！これで「設計図」は完成です。
今回のポイントをおさらいしましょう。
- 目的： 障害対応とセキュリティのためにログを集める。
- プロトコル： 信頼性のTCP、互換性のUDP、両方使う。
- サイジング： ログは圧縮前提で計算し、SSDを用意する。
- 保存場所：
/var/log/remote/ホスト名/配下に整理する。
次回は、この設計図を元に「AlmaLinuxへのRsyslogインストールとファイアウォール設定」を行います。
実際にコマンドを打っていく作業編です。お楽しみに！
▼ログサーバー構築におすすめのVPS
ログサーバーは常にディスクへの書き込みが発生します。I/O性能が高く、かつ将来的にディスク容量を簡単に増やせる（スケールアップできる）VPSを選ぶのが正解です。
コメント