Windows で無料の syslog サーバを構築する方法【OSS・設定ファイル不要】

前提と要件の整理

本稿で構築するのは、社内の管理されたネットワークで、ファイアウォール・スイッチ・無線 AP・UPS・サーバなどの syslog を受信して保存し、ブラウザから検索できるログ集約サーバです。前提は次のとおりです。

• 受け手となる Windows マシン（Windows Server、または常時稼働できる Windows PC）が一台あること
• ログを送りたい機器が「syslog 送信先」を設定できること（多くのネットワーク機器は対応しています）
• 利用場所は社内 LAN の内側であること（syslog の既定は平文のため）

Linux の知識、データベースの事前構築、追加のライセンス費用は必要ありません。

なぜ Windows ネイティブの OSS か

syslog サーバの選択肢は従来、商用製品（ライセンス費用が壁）か、rsyslog・syslog-ng といった Linux 系 OSS（Linux サーバの構築・運用スキルが壁）の二択でした。Windows 管理者にとってはどちらも一段の負担があります。

Yagura はこの間を埋める選択肢です。単一の Windows サービスとして動き、運用に要るのは Windows サービス・SQL Server・Active Directory といった、Windows 管理者が既に持っている技能だけ。ライセンスは Apache License 2.0 の OSS で、費用は掛かりません。選定の比較検討は 「syslog サーバの選び方」で詳しく扱っています。

手順一 — MSI をひとつ実行する

公式サイトの配布の段（または GitHub Releases）から MSI インストーラをダウンロードし、実行します。これだけで次がすべて済みます。

• Windows サービスとしての登録（受信・解析・保存・閲覧を単一サービスに同居）
• Windows ファイアウォール規則の作成
• 内蔵データベース（SQLite）の用意 —— インストール直後から保存が始められます

self-contained 形式で配布されているため、.NET ランタイムの事前導入も不要です。そして設定ファイルは —— ありません。インストールが終わった時点で、syslog サーバは既に udp/514・tcp/514 で待ち受けています。

手順二 — 機器の syslog 送信先を向ける

次に、ログを送りたい機器側の設定です。各機器の管理画面で「syslog サーバ」「ログ転送」といった項目を開き、送信先として Yagura を入れたサーバの IP アドレス（またはホスト名）と、ポート 514（UDP または TCP、IPv4/IPv6 とも可）を指定します。機器タイプ別の勘所は「ネットワーク機器の syslog 送信設定まとめ」に、届かない場合の切り分けは確認手順の記事にまとめています。

形式は RFC 3164・RFC 5424 のどちらでも解釈されます。機器が規格から外れたログを送ってきても心配は要りません。解析に失敗したメッセージも破棄されず、原文のまま「解析失敗」の印付きで保存されます。ログを失わないことが、集約サーバの第一の仕事だからです。

なお、Windows サーバのイベントログも同じ画面に集約できます。手順は別稿 「Windows イベントログを syslog サーバへ集約する方法」にまとめました。

手順三 — ブラウザで見る

受信が始まったら、ブラウザで次の URL を開きます。

http://サーバ名:8514/

もうログは集まっています。画面は三つです。

• ダッシュボード —— 受信件数の推移、送信元ホスト別・重要度別の集計、最近のログを一望
• ログ検索 —— 期間・ホスト・重要度・本文での絞り込み
• システム状態 —— 受信・保存の統計と、取りこぼしの発生箇所別カウンタ

表示テーマはライト・ダーク・OS 追従から選べ、時刻はサーバ OS のタイムゾーンでオフセット明示のうえ表示されます。「UTC か JST か分からないログ」を突き合わせる不毛な時間とは、ここでお別れです。

運用の初期設定 — 保持期間・通知・途絶検知

受信が回り始めたら、運用向けの設定を必要な分だけ重ねます（いずれも任意・opt-in です）。

保持期間の自動削除

既定では 30 日で自動削除されます。日数も実行時間帯も変更できるため、監査要件に合わせて延ばす、ディスクに合わせて縮める、といった調整が可能です（何日にすべきかの考え方は「ログの保存期間はどのくらい必要？」へ）。

能動通知のメール送信

証明書の期限接近、スプール退避の開始、保存の恒久失敗など、対応を要する警告を SMTP で受け取れます。再送抑制と流量上限を備え、既定は無効です。

送信元の途絶検知

意外に気づけないのが「来るはずの syslog が来ていない」ことです。ウォッチリストに登録した送信元からの受信が閾値時間（既定 24 時間）途絶えると警告され、メール通知にも乗せられます。機器の障害や設定の巻き戻りを早期に発見できます。

本格運用へ — SQL Server への昇格

まずは内蔵 SQLite で十分に運用できますが、ログ量が増えてきたら、管理画面のウィザードで保存先を SQL Server へ切り替えられます。接続パスワードは Windows DPAPI で暗号化して保存されます。

また、保存先データベースに障害が起きた場合も、受信データはディスクスプールへ退避され、復旧後に取り込まれます。「DB が落ちていた間のログが消えた」を避ける仕組みです。

セキュリティ上の心得

そのうえで、必要に応じて強化を重ねられます。syslog over TLS 受信（tcp/6514）、閲覧 UI の Windows 統合認証 + AD グループによるアクセス制御、閲覧・管理 UI の HTTPS 化 —— いずれも opt-in で、既定を軽く、強化を明示的に、という流儀です。管理 UI（tcp/8515）は既定で loopback 限定です。