NXLog Platform と NXLog Agent は、ベンダーに依存しないクロスプラットフォームのテレメトリ・パイプラインを提供し、セキュリティ／IT／クラウドのデータを大規模に収集・処理・転送します。Windows Event Log、Linux/systemd、アプリケーションログ、ネットワークテレメトリ、OpenTelemetry（トレース／ログ／メトリクス）を含むログや各種テレメトリを一元化し、統一フォーマットへ正規化したうえで、強固な転送セキュリティとボリューム制御で、あらゆる SIEM や分析基盤へ確実に届けます。

NXLog を選ぶ理由

• 主要 OS／アーキテクチャを 1 つのエージェントでカバー。エージェント方式／エージェントレス／オフライン処理に対応
• 「収集 → 処理 → ルーティング」のベンダー非依存パイプライン。豊富なパース／変換（JSON、CEF、GELF、CSV、XML、キー・バリュー など）
• エンタープライズ級の信頼性（TLS/mTLS、バッファリング、フロー制御、ディスク支援キュー）とエアギャップ展開のサポート
• 任意の SIEM／ログ分析／オブザーバビリティ基盤／データレイクと連携。同一ストリームを並列で複数宛先へ配信
• エッジでのきめ細かなフィルタリングと正規化でノイズを削減し、重要イベントを落とさず取り込み量を抑制

製品紹介

アーキテクチャとコンポーネント

導入メリット

ユースケース

1) Windows 基盤のハードニングと AD 可視化

課題： Security／System／Application／Sysmon などの Windows Event Log を高忠実・低ノイズで確実に収集したい。

実装概要：

• ドメインコントローラとメンバーサーバーに NXLog Agent を導入
• 高価値イベント ID やチャネルに対して XPath フィルタを適用。Sysmon Operational ログを収集
• 下流 SIEM 要件に応じて JSON もしくは CEF へ変換
• TLS/mTLS で SIEM へ転送（フォレンジック用に第 2 宛先へも並行転送）

効果（例）： エッジで低価値ノイズを削減。正規化により SIEM でのトリアージ高速化。DC と中央コレクタ間の安全かつ監査可能な転送。

2) エアギャップ OT/ICS と拠点集約

課題： プラントや支店内から外部へ送信不可。Windows／Linux 混在、PLC や HMI がローカル syslog／Windows チャネルに出力。

実装概要：

• ローカルサーバーに NXLog Agent を展開。エージェント不可のクライアントには Linux ベースの WEC を用意
• セグメント間のリンク断に耐えるディスク支援バッファを活用
• オンプレミス SIEM とオフライン保持ストアへ転送

効果（例）： インターネット非依存でも堅牢・暗号化された収集を実現。IT/OT を横断した一貫ポリシー管理。

3) マルチ SIEM／MDR への並行ルーティング

課題： 本社で Splunk を運用しつつ、別のプラットフォームを使う MDR にも同一のエンリッチ済みイベントを届けたい。

実装概要：

• エッジで JSON/CEF へ正規化
• 両バックエンド（例：Splunk HEC と QRadar syslog/LEEF）へ並列出力
• 「ホット」イベントはリアルタイム宛先へ、「ウォーム」イベントは調査用ストアへ振り分け

効果（例）： プロバイダー追加時も再インスツルメンテーション不要。将来に強い SIEM 戦略。

4) 大規模オブザーバビリティのコスト統治

課題： 取り込み課金モデルで高ボリューム環境が不利。コストを抑えつつ本質的なコンテキストを保持したい。

実装概要：

• 未使用フィールドの削減、DEBUG/TRACE クラスの事前ドロップ
• 可能な箇所でバッチ化・圧縮。ディスクバッファを活用して転送時間帯を調整
• 冗長なアプリログはオブジェクトストレージに退避し、要約のみを SIEM へ

効果（例）： 可視性を損なわずに分析コスト低減。段階的ルーティングでフォレンジック完全性を確保。

5) DevSecOps のための OpenTelemetry ブリッジ

課題： OTel 採用チームが、アプリのトレース／ログ／メトリクスと従来のセキュリティログを統合したい。

実装概要：

• サービスから OTel のログ／トレースを取り込み
• SOC スキーマに合わせて再整形・エンリッチ。SIEM とオブザーバビリティ基盤へ同時ファンアウト
• 必要に応じて Prometheus 互換メトリクスを公開

効果（例）： SecOps と SRE が共通のテレメトリ基盤を共有し、重複エージェントを削減。

代替製品との違い

一般的なログ収集・転送ソフトウェアと比べた際の観点（一般論）：

• ベンダー非依存の設計： 任意の SIEM／データ基盤へ同一ストリームを並列配信する前提のポリシー運用。
• Windows ネイティブ対応の厚み： WEF/WEC、ETW、XPath などの機能を含む収集と正規化の選択肢。
• エッジでの正規化とコスト統治： JSON/CEF/GELF などへの変換、フィールドトリム、イベント選別で取り込み量を制御。
• 複数宛先ファンアウト： 宛先ごとにバッファ／復旧動作を分離し、障害ドメインを切り分け。
• エアギャップ／オンプレ運用： オフライン／断続回線を前提としたバッファリングと再送制御。

アーキテクチャとコンポーネント

入力（抜粋）

• Windows Event Log（im_msvistalog）： チャネル／XPath でクエリ。ローカル／リモート
• Windows Event Forwarding/Collector（im_wseventing）： WEC として動作し WEF ストリームを受信
• Event Tracing for Windows（im_etw）： カーネル／ユーザーモードのトレースプロバイダ、Debug／Analytic チャネル
• ファイルとディレクトリ（im_file）： ローテートファイル、再帰パス。履歴 EVTX／CSV／JSON／XML の読み取り
• ソケット（im_udp、im_tcp、im_ssl）： UDP/TCP/TLS 取り込み。許可／ブロックリスト
• systemd/journald（im_systemd）： Linux ネイティブログ
• パフォーマンスカウンタ（im_winperfcount）： Windows パフォーマンスカウンタのテレメトリ
• 内部テレメトリ（im_internal、im_internalmetrics）： エージェント健全性とカウンタ
• OpenTelemetry（im_otel）： HTTP(S)/gRPC で OTel のログ／トレースを取り込み

拡張とプロセッサ（抜粋）

• xm_json / xm_xml / xm_csv / xm_kvp： 構造化フォーマットのパース／生成。入れ子 JSON のフラット化
• xm_cef / xm_gelf / xm_w3c / xm_grok： 代表的な SIEM／アプリ形式の生成／パース
• xm_syslog： IETF/BSD syslog ヘッダ処理と変換
• pm_buffer： メモリ／ディスクバッファ。ディスク分割、警告／制限しきい値
• pm_blocker： 転送時間帯のスケジュール制御
• フィールド書き換え／トリム： 許可／拒否リストと正規化

出力（抜粋）

• om_tcp / om_udp / om_ssl： TCP/UDP/TLS によるネットワーク転送（mTLS 対応）
• NXLog Transport： エージェント間／Platform 向けの圧縮・効率的転送
• OpenTelemetry（om_otel）： OTel コレクタへログ／トレースを転送
• Prometheus（om_prometheus）： スクレイプ用カウンタ／ゲージを公開
• ファイル（om_file）、Unix ドメインソケット（om_uds）： ローカル保管やプロセス間ハンドオフ

ルーティングモデル

• 宣言的な route で input → processor → output を接続
• 同一ストリームを複数出力へファンアウト。ルート分離とルート毎のバッファで障害ドメインを分割
• BatchSize と BatchFlushInterval を全体またはモジュール単位で調整し、スループット／レイテンシのバランスを最適化

セキュリティと信頼性

転送セキュリティ

• TLS を全面採用し証明書検証を必須化。クライアント証明書による相互認証
• ネットワーク入力での許可／拒否リスト、TCP keepalive、再接続バックオフ

耐障害配送とバックプレッシャー制御

• ルート上のメモリ／ディスクバッファ。バッファ種別／最大容量／警告しきい値を調整
• ファイル入力や Windows Event Log 入力の読み取り位置を永続化して再起動後の重複／欠落を防止
• 下流キューが枯渇した際は上流モジュールを一時停止。宛先ごとのルート設計で、ある宛先の不調が他へ波及するのを防止

高スループット チューニング

• 入力スレッド数の増加、ReusePort による並列受付
• バッチ化でスループットを向上。下流制約に合わせてフラッシュ間隔を調整
• マルチ宛先ルーティングでコレクタ間の負荷分散、または低遅延系とバルク系を分離

FAQ

Q1. 同じイベントを複数の SIEM へ送れますか？
はい。並列出力や別ルートを定義します。多くの組織が、プライマリ SIEM と分析／フォレンジック用途のストアへ並行転送しています。

Q2. すべての Windows エンドポイントにエージェントが必要ですか？
必須ではありません。エージェント不可の環境では、NXLog Agent を Windows Event Collector（WEC）として構成し、Windows Event Forwarding（WEF）を受信できます。深いホスト可視化とローカルフィルタリングにはエージェントを推奨します。

Q3. 取り込みコストを下げるには？
許可／拒否リストでフィールドを削減し、チャネルや XPath で低価値イベントをフィルタし、冗長ログは低コストストレージへ、要約のみを SIEM へ送ります。必要に応じてバッチ化や圧縮も活用します。

Q4. 転送のセキュリティは？
TLS と任意の相互認証に対応します。CA 信頼、サーバー／クライアント証明書、鍵保護を構成し、リスナーでは許可リストを使い、証明書は計画的にローテーションしてください。

Q5. エアギャップ環境でも動作しますか？
はい。Platform と Agent は完全オンプレで動作します。Windows は WEC/WEF、Linux は syslog/journald を使い、セグメント内で完結する経路を構成できます。境界を跨ぐ場合はバッファリングしたリレーで引き継げます。

Q6. 対応 OS は？
Windows、Linux、macOS、BSD、IBM AIX、Oracle Solaris。アーキテクチャは OS に応じて x86/x64、ARM、PowerPC をサポートします。

Q7. OpenTelemetry をサポートしますか？
はい。HTTP(S)/gRPC で OTel のログ／トレースを取り込み、OTel コレクタ／バックエンドへエクスポートできます。必要に応じて Prometheus 互換メトリクスも公開します。

Q8. どのように中央管理しますか？
NXLog Platform のテンプレートとソリューションパックを用い、役割でグルーピングして適用します。Windows フリートの初期展開には GPO が一般的です。

Q9. Linux で rsyslog/syslog-ng の代替になりますか？
はい。journald やソケットから読み取り、同等の syslog 機能に加えて、リッチな変換や複数宛先への並行ルーティングを提供します。