この記事のツールを使用して、複数のサーバーとデスクトップからWindowsイベントログを一元化 ログを適切に管理することで、システムの健全性を追跡し、ログファイルを安全に保ち、内容をフィルタリングして特定の情報を見つけることがで
なぜログを一元化するのですか？
ログを一元化すると、時間が節約され、ログデータの信頼性が向上します。 Windowsログファイルが各サーバーにローカルに保存されている場合は、各サーバーに個別にログインして、それらを調べてエラーや警告を探す必要があります。 サーバーが応答しない場合は、運が悪い可能性があります。 どのサーバーが影響を受けているかわからない場合は、それぞれを追跡する必要があり、大規模なネットワークでは長い時間がかかる可能性があります。 インスタンスが終了したり、ファイルが(意図的にまたは意図せずに)削除されたりしても、ログの集中バックアップコピーは影響を受けないため、ログ
Windowsイベントサブスクリプション
Windowsサーバーがイベントをコレクタサーバーに転送することができます。 このシナリオでは、コレクタサーバーは、ネットワーク内の他のサーバー(イベントソースと呼ばれる)からのWindowsログの中央リポジトリになります。 ソースからコレクタへのイベントのストリームは、サブスクリプションと呼ばれます。
この手順では、設定方法を示します。 これらの手順は、Windows Server2008R2、Windows Server2012、およびWindows Server2019で動作します。
システムの例
2つのActive Directoryドメインに参加したWindows Server2012システムを使用しています。 ドメイン名はmytestdomain.com そして、両方のマシンがドメインに登録されています。
移行元サーバー MYTESTSQLは、SQL Server2014インスタンスをホストします。 コレクタサーバー MYTESTSERVERは、イベントログサブスクライバとして機能し、MYTESTSQLからのSQL Server関連のすべてのログを一元化します。
セットアップ
Windowsリモート管理サービスを有効にする
Windowsリモート管理(WinRM)は、インフラストラクチャ内のシステム間で情報を交換するためのプロトコルです。 ログファイルを交換するには、各移行元コンピュータで有効にする必要があります。
- ソースコンピュータ(MYTESTSQL)にローカル管理者またはドメイン管理者としてリモートでログインします。
- コマンドプロンプトからWindowsリモート管理サービスを有効にします。
winrm quickconfig
既に実行されている場合は、この例のようなメッセージが表示されます。
windows Event Collectorサービスの構成
ソースからログを受信できるようにするには、collectorサーバーでWindows Event Collectorサービスを有効にする必要があります。
- ローカル管理者またはドメイン管理者としてコレクタコンピュータ(MYTESTSERVER)にリモートでログインします。
- コマンドプロンプトからWindowsイベントコレクターサービスを構成します。
wecutil qcin
例のようにプロンプトが表示されたら、yキーを押します
イベントログリーダーグループの構成
デフォルトでは、特定のログは管理者に制限されています。 これは、他のシステムからログを受信するときに問題が発生する可能性があります。 これを回避するには、コレクタコンピュータをイベントログリーダーグループに追加して、コレクタコンピュータへのアクセスを許可します。
- ソースコンピュータ(MYTESTSQL)に戻ります。
- サーバーマネージャーを開きます。
- コンピュータの管理を開きます。
- ナビゲーションペインからローカルユーザーとグループノードを展開し、グループを選択します。
- イベントログリーダーをダブルクリックします。
- 追加をクリックして、ユーザー、コンピュータ、サービスアカウント、またはグループの選択ダイアログを開きます。
- オブジェクトタイプをクリックします。
- コンピュータにチェックを入れ、OKをクリックします。
- オブジェクト名として”MYTESTSERVER”と入力し、”名前の確認”をクリックします。 コンピュータアカウントが見つかった場合は、下線で確認されます。
- OKを二度クリックしてダイアログボックスを閉じます。
Windowsファイアウォールを構成する
移行元コンピュータがWindowsファイアウォールを実行している場合は、リモートイベントログ管理とリモートイベントモニ
サブスクリプションの作成
サブスクリプションは、コレクターとソースの関係を定義します。 任意の数のソース(ソース開始サブスクリプション)からイベントを受信するようにコレクタを構成したり、制限されたソースセット(コレクタ開始サブスクリプション)を指定したりすることができます。 この例では、どのコンピュータログを受信するかがわかっているため、コレクタ開始サブスクリプションを作成します。
- コレクタサーバー MYTESTSERVERでイベントビューアアプリケーションを起動します。
- ナビゲーションペインからサブスクリプションを選択します
- アクションペインでサブスクリプションの作成をクリックします。
- サブスクリプションプロパティで、例に示すように次のように入力します。
サブスクリプション名:MYTESTSQL_EVENTS
説明:リモートソースサーバー MYTESTSQL
宛先ログからのイベント: Forwarded Events
Collector initiatedを選択し、コンピュータの選択をクリックしてコンピュータダイアログを開きます。
- [ドメインコンピュータの追加]をクリックします。
- オブジェクト名としてMYTESTSQLを入力し、”名前の確認”をクリックします。 コンピュータが見つかった場合は、下線で確認されます。
- [OK]をクリックします。
- “OK”をクリックして、サブスクリプションプロパティに戻ります。
- イベントの選択をクリックしてクエリフィルタを開き、次のように入力して、リモートサーバーが過去24時間のすべてのアプリケーションイベントを転送す: 過去24時間
すべてのイベントレベルをチェック
ログで選択
イベントログ:ドロップダウンリストからアプリケーションを選択します
- “OK”をクリックして、サブスクリプションプロパティに戻ります。
- 詳細設定をクリックして詳細サブスクリプション設定を開き、次のように入力します。
マシンアカウントを選択
遅延の最小化を選択
プロトコル:HTTP
ポート: 5985
- “OK”をクリックして、サブスクリプションプロパティに戻ります。
- OKをクリックして閉じます。
コレクタコンピュータイベントビューアのサブスクリプションノードに新しいサブスクリプションが表示されるようになりました。
コレクタコンピュータ上のイベントを確認する
コレクタコンピュータのナビゲーションペインから転送されたイベントを選択します。
詳細ウィンドウの[コンピューター]列には、リモートコンピューターからのイベントが表示されますMYTESTSQL.MYTESTDOMAIN.COM collectorサブスクリプションを有効または無効にするには、サブスクリプションを右クリックして[Disable]を選択します。 サブスクリプションのステータスは、メインウィンドウに無効として表示されます。 アクティブなコレクタサブスクリプションは、成功しているわけではありません。 コレクタがソースに接続できるかどうかを確認するには、サブスクリプションを右クリックし、実行時の状態を選択します。 この例では、コレクタはソースに接続できません。 デフォルトでは、5分ごとに再試行されます。
すべてがOKの場合、サブスクリプションランタイムステータスには緑色のチェックマークが表示され、アクティブステータスが表示されます。
カスタムビューの作成(オプション)
イベントが転送されたら、統合イベントを表示するカスタムビューを作成できます。 たとえば、エラーイベント用のカスタムビューを作成することができます。 この例では、SQL Server関連のメッセージ用のカスタムビューを作成します。 コレクタコンピュータは、数十台のサーバーから数千のレコードをホストすることができます。 カスタムビューを使用すると、情報の過負荷から注文を作成できます。 詳細な手順については、”Windowsログの基本”の”カスタムビューの作成”を参照してください。
Windows Logging Services
すべてのログデータを外部ログサービスに一元化するために使用できるWindowsサービスがいくつかあります。 これらのサービスは、ログをsyslog経由でクロスプラットフォームログサーバーまたはsolarwinds®Loggly®のようなクラウドベースのログサービスに送信します。
私たちは、バックグラウンドで実行される人気のある、自由にダウンロード可能なサービス、NXLogをお勧めします。 または、ログファイルを収集するサービスであるsyslog-ngとSnareがあります。 これらのすべてのサービスは、有料で追加の専門的なサポートを提供します。
Install nxlog
この例では、ログファイルをパッケージ化するようにNXlogをインストールして設定します。
現在のバージョンのNXlogをダウンロードしてインストールします。 ダウンロードには直感的なインストーラが含まれています。 インストールが完了したら、構成ファイルを開きます。 デフォルトでは、NXLog設定ファイルは次の場所にありますC:/Program ファイル（x86）/nxlog/conf/nxlog。conf
さまざまなタイプの設定モジュールを作成できます。
- ログのソースの入力
- ログの送信先の出力
- 入力を出力にマップするルート
NXlog設定ファイルを変更するたびに、NXlogサービスを再起動する必要があります。
Configure NXLog
この例では、Nxlog構成ファイルを変更して、Windowsイベントログを一元化します。 以下のコードスニペットをnxlogの最後に追加します。confファイルはモジュールを有効にし、”eventlog”という名前を与えます。 Im_msvistalog入力モジュールは、システム、ハードウェア、アプリケーション、セキュリティ関連のイベントなど、新しいエントリをWindowsイベントログに送信します。
# Windows Event Log<Input eventlog># Uncomment im_msvistalog for Windows Vista/2008 and laterModule im_msvistalog# Uncomment im_mseventlog for Windows XP/2000/2003# Module im_mseventlog# If you prefer to send events as JSON dataExec $Message = to_json();</Input>
ファイルログ
NXLogは、ドライブに保存されているログファイルを読み取るために使用できます。 この例では、ファイル名はFILE1です。 SavePos TRUEは、nxlogが終了時にログファイル内の現在の場所を追跡することを意味します。 Exec Message Message=r raw_eventは、nxlogが追加の書式設定を適用せずに生のログメッセージを取り込むことを意味します。 ファイル名には、ディレクトリまたはワイルドカードを含めることもできます。
<Input FILE1>Module im_fileFile "FILE1"SavePos TRUEExec $Message = $raw_event;</Input>
IISログ
Windowsログの基本セクションで説明したように、IISログにはW3C形式で保存されたアクセスログが含まれています。 ログ管理ツールで簡単に処理できるように、JSON形式に変換することをお勧めします。 NXLogは、W3C拡張機能を使用してこの変換を行うことができます。 構成ファイルで適切な形式を使用して、解析が正しく行われ、すべてのサイトのログファイルが含まれていることを確認してください。
<Extension w3c>Module xm_csvFields $date, $time, $s-ip, $cs-method, $cs-uri-stem, $cs-uri-query, $s-port, $cs-username, $c-ip, $csUser-Agent, $cs-Referer, $sc-status, $sc-substatus, $sc-win32-status, $time-takenFieldTypes string, string, string, string, string, string, integer, string, string, string, string, integer, integer, integer, integerDelimiter ' 'QuoteChar '"'EscapeControl FALSEUndefValue -</Extension># Convert the IIS logs to JSON and use the original event time<Input IIS_Site1>Module im_fileFile "C:/inetpub/logs/LogFiles/W3SVC1/u_ex*"SavePos TRUEExec if $raw_event =~ /^#/ drop();else{w3c->parse_csv();$SourceName = "IIS";$Message = to_json();}</Input>
SQL Serverエラーログ
SQL Serverは、Microsoftのエンタープライズクラスのフラッグシップデータベースプラットフォームです。 これは、データベースとデータウェアハウスツールのスイートで提供されています。 通常、SQL Serverには、Windowsファイルシステムのアプリケーションのインストールディレクトリに保存された独自のログがあります。 SQL Server2012の既定の場所は次のとおりですC:/Program ファイル/Microsoft SQL Server/MSSQL11.MSSQLSERVER/MSSQL/Log. ログエントリは、Windowsアプリケーションイベントログにも送信されます。
バックアップと復元、クエリタイムアウト、遅いI/OなどのSQL Server操作は、Windowsアプリケーションイベントログから簡単に見つけることができます。
サーバーへのログの転送
NXLogは、上記のいずれかの入力からログサーバーやクラウドベースのログ管理サービスなどの外部宛先にログを転送できます。 これを行うために、NXLogは出力とルートと呼ばれる概念を使用します。 出力は、ファイルやリモートサーバーなどの宛先にログを送信するための機能を提供するモジュールです。 ルートとは、ログメッセージが入力(im_msvistalogモジュールなど)から出力(ログ管理サービスなど)に渡すパスのことです。
ログを転送するには、nxlogに出力モジュールを追加します。conf設定ファイル。 次に、選択した入力から選択した出力にログを送信するルートモジュールを追加します。 この例では、デフォルトsyslogポート514上のホストホスト名にtcp上のsyslogとしてログを送信しています。 Eventlog入力からログを取得し、それを新しい出力（outという名前）に送信するルートを作成します):
<Output out>Module om_tcpHost HOSTNAMEPort 514</Output><Route 1>Path eventlog => out</Route>
いくつかのログ管理ソリューションには、Windowsログ記録のための特定のセッ Logglyは1つのプロバイダの例であり、ログファイルを収集するためのNXLogの設定に関する詳細情報は、ガイド「Windowsからのログ記録」に記載されています。
TLSによるログの暗号化
デフォルトでは、インターネット経由で送信されるログはクリアテキストで送信されます。 これは、スヌーパーがログデータを傍受して表示できることを意味します。 特に、個人識別情報の詳細、政府が規制するデータ、財務情報などの機密情報が含まれている場合は、ログデータを暗号化することをお勧めします。 Syslog通信を暗号化するための最も一般的なプロトコルは、TLSまたはTransport Layer Securityです。
TLSはログを暗号化し、誰もがログ内の機密データを詮索するのを防ぎます。 ベストプラクティスは、パスワードのような情報をログに記録することではありませんが、 TLS暗号化は、このデータをより安全に保つのに役立ちます。 暗号化により、ログの送信元と送信先の間にある悪意のある関係者がログデータを読み取ったり変更したりするのを防ぎます。
ここでは、LogglyのTLS暗号化を使用したNXLog設定の設定例を示します。
- Nxlog TLS設定ページからLogglyのデジタル証明書をダウンロードします。
- デジタル証明書ファイルをNXLog証明書ディレクトリにコピーします。
loggly_fullをコピーします。crt C:/Program ファイル*/nxlog/cert - om_sslと証明書の場所を使用して出力モジュールを設定します。 暗号化されたログのデフォルトのsyslogポートは6514です。 AllowUntrusted FALSEは、証明書が信頼されていないか自己署名されていない場合、サーバーへの接続を禁止します:
<Output out>Module om_sslHost server.example.comPort 6514CAFile %CERTDIR%/example.crtAllowUntrusted FALSE<Output>
