8. その他¶
8.1. 詳細項目一覧¶
アクセスログの「Event」フィールドでは以下の情報が収集できます。
項目 |
説明 |
|---|---|
User |
操作を実行したユーザーアカウント名 |
Object |
操作の対象 (例: ファイル/フォルダーパス)、または操作内容や操作した端末名が表記される |
Operation |
実行された操作が表記される。詳しくは「アクセスログの種別 」を参照 |
AppName |
操作を実行したアプリケーション名 |
AuditUser |
ユーザーがsudoやsuを行った場合の、最初にログインしたユーザー名 |
AuthType |
認証の種類
- Kerberos = Kerberos認証
- NTLM = NTLM認証
|
ClientIP |
操作を実行したクライアントPCもしくは接続先PCのIPアドレス |
ClientName |
操作を実行したクライアントPCもしくは接続先PCのコンピューター名 |
Count |
ログ変換処理によってマージされたイベントログ（生ログ）のレコード数
※イベントログの特性として、ユーザーによる1回の操作に対し、同じ内容を示すログレコードが複数行出力されることがあり、ALogでは、「User」、「Host」、「Object」および「詳細（Countを除く）」が同じログレコードにおいて、5秒以内に同じ「Operation」のレコードが連続して発生した場合、これらを1レコードにマージしている
|
CurrentDir |
コマンドを実行したときのカレントワーキングディレクトリ |
DB |
アクセスしたデータベース名 |
DBID |
接続したデータベースのデータベースID |
ErrorCause |
Windowsアクセスログ：認証失敗の理由
Linux：認証だけでなく、各操作の失敗の理由
|
EventID |
操作が記録されたWindowsイベントログID |
LogonType |
ログオン処理の種類
- RemoteInteractive = リモートデスクトップ接続
- Script = ログオン/ログオフスクリプトのログである場合
※Windowsで定義されているログオンタイプと完全に一致するものではない
|
OSUser |
データベース接続時にOSへのログオンに利用したユーザーアカウント名 |
Pages |
印刷対象となったページ数（印刷部数、印刷枚数は出力されない） |
Printer |
印刷を行ったプリンター名 |
Protocol |
「SMB」以外の通信プロトコル名 |
RowCounts |
SELECTコマンド実行時にヒットしたレコード件数 |
Schema |
アクセスしたデータベーススキーマ名 |
SesId |
データベース接続時のセッションID |
To |
ファイル・フォルダーの名前変更/移動/コピー操作を行った場合の、RENAME/COPY/MOVE後ファイル・フォルダーのパス |
Tty |
レコードに紐づけられた仮想コンソール名（Tty名） |
Zone |
アクセスゾーン名 |
AccessList |
WindowsイベントログのAccessList |
AccessMask |
WindowsイベントログのAccessMask |
注意
対象ホストごとの収集可否は以下のとおりです。
対象ホスト |
ログ種別 |
収集可能な項目 |
|---|---|---|
Windowsアクセスログ |
すべてのログ |
User / Object / Operation / Count |
ファイルアクセスログ |
ClientName / ClientIP / AppName / To |
|
ログオンログ |
AuthType / LogonType / ErrorCause / ClientIP / ClientName |
|
管理者操作ログ |
EventID / ClientIP / ClientName |
|
プリントログ |
Printer / Pages |
|
ログオン/ログオフログ(スクリプト) |
LogonType / ClientIP / ClientName |
|
アプリケーション起動ログ |
AppName / ClientIP / ClientName |
|
アクセス権変更ログ |
ClientName / ClientIP / AppName |
|
NetApp |
すべてのログ |
Count / ClientIP / User / Object / Operation / ClientName |
ファイルアクセスログ |
To |
|
EMC |
すべてのログ |
Count / ClientIP / ClientName /User / Object / Operation |
PowerScale |
すべてのログ |
Count / ClientIP / Protocol / To / Zone / User / Object / Operation |
SQL Server |
すべてのログ |
Count / AppName / DB / User / Object / Operation |
RAWSQLログ以外 |
ClientIP ※SQL Server 2017以降 |
|
RAWSQLログ |
ClientName / RowCounts |
|
Oracle |
すべてのログ |
Count / ClientName / AppName / Schema / SesId / OSUser / DBID / User / Object / Operation |
DBログオンログ |
ClientIP |
|
Linux |
すべてのログ |
Count /User / Object / Operation |
ファイルアクセスログ |
AppName / AuditUser / ClientIP / ClientName / ErrorCause / To / Tty |
|
アクセス権変更ログ |
AppName / AuditUser / ClientIP / ClientName / ErrorCause / Tty |
|
コマンド実行ログ |
AppName / AuditUser / ClientIP / ClientName / ErrorCause / CurrentDir / Tty |
|
ログオンログオフログ |
AppName / AuditUser / ClientIP / ClientName / ErrorCause |
|
マッピング設定が可能なシステム |
(ログ種別なし) |
任意指定可能 |
Amazon FSx for Windows File Server |
すべてのログ |
Count / AccessList / AccessMask / User / Object / Operation |
Amazon FSx for NetApp ONTAP |
すべてのログ |
Count / ClientIP / User / Object / Operation / ClientName |
ファイルアクセスログ |
To |
8.2. Windows「LOGON」に関する補足情報¶
ログオンログの基本的な考え方について 「Windows「LOGON」のアクセスログについて」 で解説していますが、「ユーザーが行った操作 ─ その場合のアクセスログへの出力結果」をケースごとに解説します。 この中から、どのようなLOGONログを取得したいか確認し、『どのホストを対象ホストとして登録すべきか』 を明確にします。
ケースは計9ケースあります。同じ対象ホストに対して「ログオンログ」と「ログオン/ログオフログ(スクリプト)」を同時に設定することも可能です。
ログ種別「ログオンログ」を取得する方法：6ケース
ログ種別「ログオン/ログオフログ(スクリプト)」：3ケース
ケース図解の読み方
ケースごとの図解の中で赤い枠で示すホストが、 対象ホストとして登録対象となり得るホスト です。
吹き出しの中に、そのホストから取得できるアクセスログの内容を示します。
このあとの説明の際、省略名を使用しています。以下の表を確認してください。
FSとPCはいずれもそのドメインに参加しているマシンであることを前提としています。
省略名
意味
DC
ドメインコントローラー
FS
ファイルサーバ
AH
ALogをインストールしたホスト
RDP
リモートデスクトップ接続
WG
ワークグループ
8.2.1. ログ種別「ログオンログ」を取得するときのケース¶
8.2.1.1. PCの認証のログを取りたい場合¶
8.2.1.2. FSへのローカルログオンログを取りたい場合¶
8.2.1.3. FSの共有へのアクセスログを取りたい場合（ドメインユーザー）¶
- ※1
- AuthTypeがKerberosになるかNTLMになるかはネットワーク通信の仕方による。「\\ホスト名」と入力してアクセスした場合：Kerberos認証としてイベントログに記録される。「\\IPアドレス」と入力してアクセスした場合：NTLM認証としてイベントログに記録される。
- ※2
- FSとPCが同一ドメインの場合、認証が発生するケースとしてはPC自体へのログインをローカルユーザーで行いFSへのアクセス時にドメインユーザーを指定するケースが想定される。また、FSとPCが別ドメインの場合や、PCのみWGの場合も、認証は発生する。
- ※
- 「\\IPアドレス」（NTLM認証）でアクセスして認証失敗した場合のイベントログには、ドメイン名やNTLM or Kerberos等の必要な情報が書き込まれない。そのためこのケースによる「LOGON-Failure」のアクセスログにおいては、[User]は「ADサーバのホスト名認証で入力したユーザー名」を表示している。これは通常の「LOGON」や「LOGON-Failure」のアクセスログとは異なる特別な対応である。
8.2.1.4. FSの共有へのアクセスログを取りたい場合（ローカルユーザー）¶
8.2.1.5. RDP接続でFSの共有へ接続したときのアクセスログを取りたい場合（ドメインユーザー）¶
8.2.1.6. RDP接続でFSの共有へ接続したときのアクセスログを取りたい場合（ローカルユーザー）¶
8.2.2. ログ種別「ログオン/ログオフログ(スクリプト)」を取得するときのケース¶
※基本的なスクリプトの作成については「ログオン/ログオフログ(スクリプト)」 を参照してください。ここではスクリプト設定のうち、以下に示す2画面の選択について補足します。
ログの書き込み先ホストの指定
アカウントの指定
8.2.2.1. ログの書き込み先：DC （ドメインユーザー）¶
ドメインユーザーのログオン/ログオフを取得する際の一般的なケース
【スクリプト生成時の設定】
「ログの書き込み先ホストの指定」画面 |
「ログオン先のドメインコントーラーに書き込む」を選択する |
「アカウントの指定」画面 |
「ドメインユーザー権限で書き込む」を選択するのが一般的
(この場合はレジストリを変更する必要がある)
「以下の管理者アカウント権限で書き込む」を選択しても良い
|
8.2.2.2. ログの書き込み先：ALogをインストールしたホスト or ファイルサーバ（ドメインユーザー）¶
【スクリプト生成時の設定】
「ログの書き込み先ホストの指定」画面
「ALogをインストールしたホストまたは任意のホストに書き込む」を選択する
「アカウントの指定」画面
8.3. レポート-アラート機能「外部連携」の詳細情報¶
外部連携 の アラートSyslog通知 に関する詳細情報を記載します。
8.3.1. syslog通知に関する基本情報¶
RFC3164に基づきUDP送信を行います。syslogのメッセージの内容が200文字を超える場合は、超過分がカットされた上で送信されます。
1度の動作では最大で10000件しか送信されません。1度に10000件を超えるアクセスログがヒットした場合は、警告を発して10000件分を送信した時点で送信を完了します。
アクセスログのソート設定や表示項目設定は適用されません。syslogの送信はアクセスログの日時について昇順で行われます。syslogのメッセージ内容はsyslog本文の設定項目により決まります。
受信されるsyslogの日時は、アクセスログの日時ではなくsyslogを受信した日時です。
syslogのメッセージ内容は、受信するsyslogサーバ側の設定によっても異なります。
8.3.2. 「syslog本文」欄の設定について¶
この項目に指定する文字列は、Microsoft C#の補間文字列として扱われます。そのため、｛｝で関数を括ることで、その評価結果を表示することが可能です。文字種によってエスケープシーケンスで入力する必要があります。エスケープに関する詳細は「特別な文字列のエスケープ方法 」を参照してください。ALogが用意している関数について「syslog本文」欄で使えるALog用の関数は以下の通りです。また、以下に記載した関数以外にも Microsoft C# が用意する関数の一部を使用できます。
関数
説明
使用例
TimeStamp()
アクセスログの日時項目を文字列として取得する
{TimeStamp()}
Detail(string key)
アクセスログの詳細項目の中で、指定された詳細キーの値を取得する
{Detail("User")}、{Detail("Object")}、{Detail("ClientIP")}
Details()
アクセスログの詳細項目を全て文字列として取得する
{Details()}
TimeStamp(string format)
{TimeStamp("yyyy-MM-dd")}
8.3.3. 「syslog本文」欄を変更する場合の例¶
「syslog本文」欄の変更によってどのようにsyslogが変更されるかを解説します。
(アラートでヒットしたアクセスログの例) "2024/06/23 14:08:57.000","Host1","Windows-AccessLog","{TimeStamp:2024/06/23 14:08:57.000,AppName:C:\Windows\System32\notepad.exe,User:user1,Object:D:\共有\file.txt,Operation:READ,Count:1}"【基本形】「syslog本文」の初期設定のままsyslog送信した場合の例(syslog本文欄の指定) ALog alert. [User:{Detail("User")}] ↓ (受信するsyslogの例) Jun 23 14:09:35 <ローカルホスト名> ALog alert. [User:user1] ※<ローカルホスト名>は、「ローカルホスト」欄に指定した値が入る【変更例】アクセスログの詳細項目「Operation」の値をsyslogのメッセージに含めたい場合(syslog本文欄の指定) ALog alert. [User:{Detail("User")}][Operation:{Detail("Operation")}] ↓ (受信するsyslogの例) Jun 23 14:09:35 <ローカルホスト名> ALog alert. [User:user1][Operation:READ]
8.4. ALogのバックアップ・リストア手順¶
ALogをインストールしたホスト上で動作しているALogのバックアップ、リストアを行う場合、以下の手順を実施してください。
注意
本手順はシングルノード構成時の手順となりますので、マルチノード構成の場合は本手順は実施しないようお願いいたします。
8.4.1. バックアップ¶
【事前準備】
Webコンソールの[管理]-[ステータス]を確認し、ALogの各タスクが実行されていないことを確認する
実行されているタスクを停止したい場合1. [ステータス]-[ALogタスクスケジューラー]の[停止]ボタンをクリックする2. 「実行中のタスクを停止する」にチェックをつけて［OK］ボタンをクリックする
すべてのタスクが停止されたことを確認し、サービス「ALog」を停止する
サービス「ALog」が停止したことを確認し、サービス「ALogDB」を停止する
- 【バックアップする】
以下のフォルダーをバックアップする
1.プログラムインストール先フォルダー 例）「X:\ALog」（既定のフォルダー名称）※ 通常は必要なし。該当フォルダー配下の設定ファイルを変更している場合はバックアップが必要2. アプリケーションデータ用フォルダー 例）「X:\ALogData」（既定のフォルダー名称）3. アクセスログ/イベントログバックアップ出力先フォルダー※ 通常は必要なし。出力先をアプリケーションデータ用フォルダー以外に変更している場合はバックアップが必要※ 出力先フォルダーの設定は[管理]-[出力設定]から確認できる4. レポートファイル出力先フォルダー※ 通常は必要なし。出力先をアプリケーションデータ用フォルダー以外に変更している場合はバックアップが必要※ 出力先フォルダーの設定は各レポート設定から確認できる- 【バックアップ後の作業】
事前準備でサービスを停止しているので「ALogDB」、「ALog」の順番で忘れずにサービスを開始すること
8.4.2. リストア¶
【リストア手順】
1. ALogをインストールする2. Webコンソールの[管理]-[ステータス]を確認し、ALogのタスクが実行されていないことを確認する実行されているタスクを停止したい場合1. [ステータス]-[ALogタスクスケジューラー]の[停止]ボタンをクリックする2. 「実行中のタスクを停止する」にチェックをつけて［OK］ボタンをクリックする3. すべてのタスクが停止されたことを確認し、サービスの「ALog」を停止する4. サービス「ALog」が停止したことを確認し、サービス「ALogDB」を停止する5. バックアップしたフォルダーのうち、アプリケーションデータ用フォルダー以外を元の場所に上書きコピーする6. 現在のアプリケーションデータ用フォルダーを削除し、バックアップしたアプリケーションデータ用フォルダーに差し替える7. サービス「ALogDB」、「ALog」の順番で開始する
注意
イベントログの最終収集日時がバックアップした日時になるため、バックアップした時点から現在までのログ欠落（LogOverFlow）が発生する可能性があります。
リストア先(ALogをインストールするホスト)の構成がバックアップ時と異なる場合、上記手順ではリストアできません。
8.5. ALogをインストールしたホストのOSシャットダウンや「ALog」および「ALogDB」サービスを停止する手順¶
ALogをインストールしたホストのOSシャットダウンや「ALog」および「ALogDB」サービスを停止する場合は、事前にALogの全タスクを停止してください。
注意
データベース更新中にOSシャットダウンやサービス停止が行われると、データベースが破損する可能性があります。
本手順はシングルノード構成時の手順となります。マルチノード構成の場合は「クラスター構築完了後のサービス停止/起動手順」に記載の手順にて停止ください。
Webコンソールの[管理]-[ステータス]-「ALog タスクスケジューラー」を開き、「実行中のタスクを停止する」にチェックをつけて「OK」をクリックする
詳しい機能説明は『 ステータス 』を参照してください
全てのタスクが停止されていることを確認し、OSシャットダウンやサービス停止を実行する
注意
手動でサービス停止させる場合は、必ず「ALog」を停止させてから「ALogDB」を停止させてください。
8.6. アンインストール¶
8.6.1. Step1．対象ホストの削除¶
登録されている対象ホストを以下の手順ですべて削除します。
Webコンソールの[管理]-[対象ホスト]をクリックする
「対象ホスト」ページの一覧に表示されているすべての対象ホストにチェックを入れ、 [削除]をクリックする
ヒント
Windows、NetAppを選択して削除した場合は、削除確認ダイアログに「監査設定を無効化する」チェックボックスが表示されるので、必要に応じてチェックを入れてください。
製品
監査設定に対するその後の作業について
Windowsアクセスログ
NetApp
EMC
PowerScale
SQL Server
対象ホスト削除時に自動で解除する。特別な作業は必要ない 2
Oracle
Linux
対象ホスト削除時に自動で解除する。特別な作業は必要ない
Amazon FSx for Windows File Server
Amazon FSx for Windows File Serverの管理画面からファイルアクセスの監査設定の管理のチェックを外す
Amazon FSx for NetApp ONTAP
マッピングが必要なシステム
対象ホストとなる機器ごとに異なるため、それぞれの機器にあわせて解除する
8.6.2. Step2．ALogの削除¶
ALogをインストールしたホストのスタートメニューから[コントロールパネル] ‐ [プログラムと機能]を開く
一覧から「ALog」を選択して[アンインストール]をクリックする
アンインストール後、ALogをインストールしたホストの以下のフォルダーに設定ファイルやデータ等が残るので、必要に応じて手動で削除する
プログラムインストール先フォルダー X:\ALog （既定のインストール先フォルダーにインストールした場合）
アプリケーションデータ用フォルダー X:\ALogData （既定のアプリケーションデータ用フォルダーにインストールした場合）
注意
アクセスログバックアップやレポート出力先を個別に指定している場合は、上記のフォルダーを削除してもファイルが残ります。 必要に応じて手動で削除してください。
8.7. プロキシ環境下での利用について¶
プロキシ環境下でALogを利用する際は、下記の手順にてプロキシサーバの情報を設定してください。
管理者権限を持っているアカウントでALogをインストールしたホストへログオンする
エクスプローラーを起動する
ALogインストール時に指定したアプリケーションデータ用フォルダ配下にある[ALogData]フォルダをダブルクリックする
[config]フォルダをダブルクリックし、[ace_config.xml]を右クリックし[プログラムから開く]>[メモ帳]をクリックする
ファイルが開いたら、ファイル最下部まで移動し[ProxyHostName]と[ProxyPort]を下記のように編集し保存する
<ProxyHostName>プロキシのIPやホスト名</ProxyHostName> <ProxyPort>プロキシのポート番号</ProxyPort>
↓
注意
既にALogのWebコンソールへログイン済みの場合、上記設定後にWebコンソールの画面をリロードしてください。
8.8. 制限事項¶
ALogでは、以下の制限事項があります。
8.8.1. ログ変換に関する制限事項¶
ログ変換に関する制限事項を記載します。製品ごとの出力ログ種別や出力パターンについては 「アクセスログの種別」 を参照してください。
8.8.1.1. 実際の操作と異なるファイルアクセスログが記録されることがある場合について (Windowsアクセスログ/NetApp/EMC/PowerScale)¶
ALogは、対象ホストのイベントログを収集し、アクセスログに変換するシステムです。収集したイベントログの内容によってアクセスログの内容が決まるため、対象ホストやクライアントPCのOS、ユーザーが利用するアプリケーションの制約などにより、ユーザーが行った操作通りのログが出力されないことがあります。
ファイルアクセスのログ変換ロジックは、以下のアプリケーションによるファイル操作が正しく反映されるよう作成されています。
エクスプローラー / メモ帳 / ペイント / Microsoft Word, Excel, Power Point / Adobe Acrobat Reader
※その他のアプリケーションを利用した操作によるアクセスログは、実行されたシステムコールの内容を識別して、ユーザーの操作に近いログに置き換えますが、対象ホストやクライアントPCのOS、ユーザーが利用するアプリケーションの組み合わせによっては、ユーザーが行った操作どおりのログが出力されない場合があります。
(Windowsアクセスログのみ）
ALogでは、コピー元/コピー先双方のログがイベントログに書き込まれ、それぞれの関連性が読み取れる場合に「COPY」として出力します。「COPY」は、アプリケーションの状況や処理により、実際にユーザーがCOPY操作を行っていなくても出力される場合があります。この場合の「COPY」は、「READ」および「WRITE」が行われたことを示します。
8.8.1.2. COPY/MOVE操作のログ出力について (Windowsアクセスログ/NetApp/PowerScale)¶
「COPY」や「MOVE」のユーザー操作は、イベントログ上は「COPY」や「MOVE」という形では記録されません。ALogではアクセスログの可読性を上げるため、以下の通り特定の条件が合致した場合に「COPY」「MOVE」としています。ユーザー操作ではコピー、移動をした場合でも、イベントログに、条件に合致するログが出力されていない場合は「COPY」、「MOVE」と出力されない場合があります。[COPY]コピーしたファイルに対しREADもしくはWRITEが特定の条件で出力され、関連が読み取れる場合に、「COPY」とします。[MOVE]移動したファイルは「RENAME」として記録されているため、移動元(名前変更前)と移動先(名前変更後)でファイル名が維持された「RENAME」の場合に「MOVE」として出力します。
(Windowsアクセスログのみ）
ファイルを移動した際、移動先の情報がイベントログに記録されない場合があります。このような場合はALogの変換において移動元で「MOVE」、移動先で「WRITE」とすることができません。ALogの変換では以下のような出力になります。
移動元…「RENAME」として出力され、詳細項目の[To]欄は非表示になる
移動先…何も出力されない
8.8.1.3. 「ClientName」、「ClientIP」が表示される条件について (Windowsアクセスログ/NetApp/EMC/PowerScale)¶
アクセスログの詳細項目である「ClientName」、「ClientIP」が表示されるか否かは、元となるイベントログの情報に基づき決定されます。
ログオンログ … 元となるログオンのイベントログに付与されている情報に応じて「ClientName」、「ClientIP」のいずれかが出力されます。
ファイルアクセスログ … ファイルアクセスのイベント前にログオン情報が記録されている場合のみ表示されます。
※(Windowsのファイルアクセスログのみ)リモートホストからのWindowsファイルアクセスについて「ClientName」、および「ClientIP」が出力されるのは、以下の全ての条件を満たしたときのみです。
ファイルアクセスログ、管理者操作ログ、アプリケーション起動ログ、ログオンログ、のうち１つでも取得する設定が事前にされているとき （これらはセキュリティログを読み込むログ種別となります。）
事前に上記アクセスログに変換されるイベントがイベントログに発生しているとき
8.8.1.4. リモートデスクトップ接続時に出力される「ClientIP」について (Windowsアクセスログ)¶
リモートデスクトップ接続をする際に同一ユーザーで、且つ、複数の端末からログインを実施した場合、「ClientIP」に出力される情報は下記となります。
先にリモートデスクトップ接続した端末で「サインアウト」をしてから、別の端末から再度リモートデスクトップを行った場合、操作を行ったそれぞれの端末のIPが「ClientIP」に出力されます。
先にリモートデスクトップ接続した端末で「サインアウト」をせずに、別の端末から再度リモートデスクトップを行った場合、別の端末の操作であっても先に接続を行った端末のIPが「ClientIP」に出力されます。
8.8.1.5. ファイルアクセスログにおいて成功操作でFailureが出力されることがある場合について (Windowsアクセスログ/NetApp/EMC/PowerScale)¶
ファイルアクセスログ(READ/WRITE/RENAME/DELETE)におけるFailureの出力は、当該ファイル/フォルダーに対するアクセス権の確認に失敗したことを示しています。しかし、『Failureのアクセスログが出力された』ことは、必ずしも『ファイルへのアクセスに失敗した』ことを意味するものではありません。ユーザーがファイル/フォルダーにアクセスした際、OSは権限チェックを行い、アクセスしようとしているユーザーに紐づいた複数のアクセス権を順番にチェックします。Failureが出力されているケースでは、いくつか行われたアクセス権チェックにおいて、「失敗」（権限がない）の判定が出たことを意味しています。しかし、このあと次の権限チェックを行う中で、ファイル/フォルダー操作に対して必要な権限を持っていることが判明した場合、ユーザー操作としては成功します。この場合、ログの読み方としては、最終的にそのファイルへのアクセスに成功したログが出力されていれば、実際にはファイルアクセスは成功しています。
8.8.1.6. ファイルアクセスログにおいて期待したFailureが出力されないことがある場合について (Windowsアクセスログ/NetApp/EMC/PowerScale)¶
実際のユーザー操作でファイルアクセスに失敗した場合、イベントログに「失敗」が記録されていないとアクセスログでFailureのログを出力することは出来ません。ファイル破損等の権限以前の問題でファイルが開けないような場合も同様です。また、何らかの障害でファイル操作に失敗した場合は、操作の途中で処理が中断されるため、失敗操作の種類を特定することができません。実行されたシステムコールの内容をアクセスログに変換しますが、『書き込み処理でREAD-Failureになる』『削除処理でWRITE-Failureになる』など、実際の操作と異なるアクセスログが出力されることがあります。
8.8.1.7. フォルダーのアクセス失敗（READ-Failure）を出力しない場合について (Windowsアクセスログ/NetApp/EMC/PowerScale)¶
フォルダー”folder1”とそのサブフォルダー”folder2”があり、ユーザーは”folder1”を開くことができるが、”folder2”はアクセス権がなく開けないとします。このとき、このユーザーが”folder1”を開くと、”folder2”に対するREAD-Failureの履歴がイベントログに出力されます。このイベントログをそのままアクセスログに変換すると、実際には”folder2”を開こうとした訳ではないのにREAD-Failureのログが記録されてしまうことから、ALogはフォルダーのアクセス失敗（READ-Failure）の履歴をアクセスログに出力しません。なお、ファイルへのアクセスが失敗した場合（ユーザーがファイルを開こうとしたがアクセス権が無く開けなかった、等）はアクセスログに出力されます。
8.8.1.8. フォルダーを開くだけで配下のファイルのREADが出力されることがある場合について (Windowsアクセスログ/NetApp/EMC/PowerScale)¶
対象ホストは、フォルダーを開いた時に「フォルダー内にあるすべてのファイルの情報」を読み取り、すべてのファイルのイベントログを出力します。ALogは、この「フォルダーを開いた時のファイルのREAD」のイベントログと「実際にファイルを読み込んだ」時に発生するイベントログの違いを識別し、フォルダーを開いただけではファイルのREADを出力しないよう処理しています。しかし、イベントログの問題により、稀にこの判別を行うことが出来ない場合があります（この問題は一度現象が起こると連続的に発生する場合があります）。その場合は以下の条件によって目視で「フォルダーを開くだけで起きるファイルのREAD」を識別します。
フォルダー内のすべてのファイルがREADと記録されている
アクセスログの「User」と「TimeStamp」がほとんど同じ内容になっている
表 8.2 例¶ TimeStamp
User
Object
Operation
2015/05/18 14:04:51.890
Domain\Yamaguchi
D:\営業部\業務受託案件リスト.doc
READ
2015/05/18 14:04:51.890
Domain\Yamaguchi
D:\営業部\社員名簿.xls
READ
2015/05/18 14:04:51.890
Domain\Yamaguchi
D:\営業部\受注登録シートマスター.xls
READ
2015/05/18 14:04:51.890
Domain\Yamaguchi
D:\営業部\090430運営委員会議事録.doc
READ
2015/05/18 14:04:51.890
Domain\Yamaguchi
D:\営業部\（社外秘）新卒採用シート.xls
READ
2015/05/18 14:04:51.890
Domain\Yamaguchi
D:\営業部\2008下期営業部業績.xls
READ
なお、ファイルの縮小版の表示や、フォルダー内のファイルのマイナー属性項目の表示などは、実際にファイルを操作しているとみなされ、READが記録されます。
8.8.1.9. 0byteのファイル/フォルダー操作について (Windowsアクセスログ/NetApp/PowerScale)¶
ホスト内のファイルやフォルダーの操作では、中身のあるファイル/フォルダーの操作(nbyteの操作)と、中身のないファイル/フォルダーの操作(0byteの操作)で、変換の元となるイベントログに記録される内容が異なります。ALogの変換は、nbyteの操作を優先したログ変換ロジックとなっており、0byteの操作はnbyteの操作と同じアクセスログにならない場合があります。例1：0byteのファイルを開いた場合、操作したアプリケーションによってはアクセスログが出力されないことがあります。例2：0byteのファイルをコピーした場合、元ファイルのCOPYもしくはREADが出ず、新ファイルのWRITEだけが出力されることがあります。例3：0byteのWordファイルを移動した場合、MOVEおよびWRITEが2回出力されることがあります。例4：0byteのフォルダーを別ドライブに移動した場合、元フォルダーのCOPYが出力されることがあります。
8.8.1.10. 拡張子の無いファイルはフォルダーとして扱われる可能性がある場合について (Windowsアクセスログ/NetApp/EMC)¶
イベントログの解析によりファイルかフォルダーかの判断がつかないファイルアクセスに関しては、その判断を拡張子の有無で行っているため、拡張子のないファイルアクセスはフォルダーアクセスと見なされてREADが出力されないことがあります。
8.8.1.11. ユーザー名の末尾が「$」となるログの出力について (Windowsアクセスログ/NetApp/EMC/PowerScale)¶
ローカルシステムアカウント（ドメイン名\コンピューター名$と表記されるアカウント）によるアクセスは、ユーザーの操作によるログとみなさないため、末尾が「$」となるユーザーによるアクセスログは出力されません。ただし、Windowsの管理者操作ログでは、この仕様は適用されず、出力されます。
8.8.1.12. RENAME先のファイル名の確認方法 (Windowsアクセスログ)¶
「RENAME」操作が行われた際の変更後のファイル名は、「RENAME」のアクセスログ行のEvent欄および[詳細]に[To]で記録されます。また、直後に「WRITE」のアクセスログが出力されます。但し、「RENAME」先のファイル名がイベントログに出力されないケースを確認しており、この場合はアクセスログに出力できません。
「RENAME」先のファイル名がイベントログに記録されるケース では「RENAME」行の後に「WRITE」が出力されます。
表 8.3 正しく出力される例¶ Object
Operation
Event
C:\XX\ファイル名A
RENAME
To:C:\XX\ファイル名B
C:\XX\ファイル名B
WRITE
「RENAME」先のファイル名がイベントログに記録されない、関連が明確にならないケースでは、アクセスログが正しく出力できません。
8.8.1.13. RENAME先のフォルダーREADの出力について (EMC)¶
RENAME先のフォルダーREADは、RENAMEのイベント発生から5秒以内に以下のREADイベントが発生した場合にのみ出力されます。なお、以下の条件でREADイベントが発生していない場合は、RENAME先のREADは出力されません。
同じホスト/同じユーザーで、同じフォルダーパス配下に異なるフォルダー名のアクセスがあった場合
同じホスト/同じユーザーで、異なるフォルダーパスに、同名のフォルダー名のREADアクセスがあった場合
また、RENAME先のREADが出力されても、フォルダーパスがRENAME先のパスにならず、全く異なるフォルダーパスとして出力されることがあります。これも上記の(a)または(b)の状況の場合に発生します。
8.8.1.14. ファイルアクセス時のアプリケーション名（AppName)の表示について (Windowsアクセスログ)¶
リモートアクセスの場合イベントログにAppName相当の情報が出力されないため、AppNameは表示されません。ファイルアクセスにおけるAppNameの表示は、ローカルアクセスの場合のみに限定されます。
8.8.1.15. 対象ホスト内のファイル操作に関するファイルアクセスログについて (Windowsアクセスログ)¶
対象ホスト内でのファイル操作では、共有経由でのファイル操作とは異なるイベントログが出力されるため、アクセスログの出力結果も異なる場合があります。以下のようなケースを確認しています。
ケース
操作：OfficeのアプリケーションにおいてPDF形式で保存するアクセスログの出力：「WRITE」を期待するが「DELETE」と出力される
8.8.1.16. プリントログのユーザーのドメイン名の表示について (Windowsアクセスログ)¶
イベントログによるプリントのイベントには、ユーザーのドメイン名情報が含まれていないため、プリントログのユーザーのドメイン名は表示されません。
8.8.1.17. アクセスログに「UnknownXXX(User/Workstation/PrintDocument)」と出力されることがある場合について (Windowsアクセスログ)¶
アクセスログの[User]に「(UnknownUser)」、[Object]に「(UnknownWorkstation)」、「(UnknownPrintDocument)」と出力される場合があります。これらの出力は、収集したイベントログ内にユーザー名、ワークステーション名またはプリントドキュメント名が無かった事を意味しています。
8.8.1.18. PowerScaleで変換対象となる領域について (PowerScale)¶
PowerScaleの変換エンジンはCIFS領域の監査ログを変換することを想定しています。監査ログにNFS領域のログが出力された場合も変換対象としますが、精度については保証していません。NFS領域の監査ログを変換した場合、アクセスログではEvent欄および[詳細]に「Protocol:NFS」と出力されます。
8.8.1.19. RAWSQLログ内のSQL文にマスクがかかる場合について (SQL Server)¶
RAWSQLログ内のSQL文にマスクがかかるケースが存在します。マスクがかかるケースは以下のとおりです。[条件]PASSWORDのパラメータを持つSQL文、システムストアドプロシジャの場合[影響と対処方法]ログインの追加、削除などに影響します。RAWSQLログ内のSQL文でパスワードやオプションとして指定した 内容が表示されません。DB管理者操作ログとしてはログイン名を確認することができます。
8.8.1.20. 監査情報を変換するための情報不足によりDB管理者操作ログが出力できない場合について (SQL Server)¶
トレースログに出力されている情報が不足しているため、DB管理者操作ログが出力できない制限事項が存在します。[条件]オブジェクト種別とオブジェクト名称から内容が特定できないイベントが発生するシステムストアドプロシジャの場合[影響と対処方法]リンクサーバの追加、削除などの操作を行った場合、DB管理者操作ログが表示されません。SQLログにて確認する必要があります。
8.8.1.21. syslogの変換時の日付の規則について (Linux)¶
1つのログ内に複数の時刻フォーマットやロケールが混在している場合、複数のフォーマット、ロケールの指定は出来ません。また、syslogに年情報が無い場合、収集したログの最終行の日付に年情報を付加します。収集した1ファイルの中に1年以上古いログが出力されていた場合、自動的に1年前と判断して変換します。
2017年に収集したファイル内のログ
アクセスログの結果
4/3 XXXX
2016/04/03
4/4 XXXX
2016/04/04
・・・
4/1 XXXX
2017/04/01
4/2 XXXX
2017/04/02
8.8.1.22. コマンド実行ログの失敗操作EXEC-Failureログにおいて対象欄に引数が出ない仕様について (Linux)¶
コマンド実行ログの失敗操作EXEC-Failureの場合、アクセスログの対象欄に表示されるのはプログラム名となります。プログラムに渡された引数は表示されません。これは失敗操作の場合、引数がauditログの中に含まれていないためです。
8.8.1.23. 実行されたコマンドにより、絶対パスではなく相対パスやファイル名で出力されるケースについて (Linux)¶
ファイルアクセスログやアクセス権変更ログの中には、パスが絶対パスではなく相対パスやファイル名で出力されるものがあります。これはauditログの中に、システムコールの種類によって絶対パスではなく相対パスやファイル名で記録されるものがあるためです。(現象例)ディレクトリ内に下位ディレクトリやファイルが含まれた状態でディレクトリを削除(rmコマンド)したときファイル名しか記録されない
8.8.1.24. 追記リダイレクト実行時にWRITEログが出力されない仕様について (Linux)¶
追記リダイレクトコマンドを実行してファイルに書き込み処理をした場合、WRITEのログは出力されません。これは当該コマンド実行時のauditログにパス名が記録されていないためです。(例) $ echo add_line >> /tmp/targetfile(auditログ) 「name="/tmp/"」と記録される
8.8.1.25. 実行時にディレクトリの末尾に「/」(スラッシュ)を付与してコマンド実行した場合のログについて (Linux)¶
コマンド実行時にディレクトリの末尾に「/」(スラッシュ)を付与すると、auditログにパスの記録が行われない現象を確認しています。パスのないログについてはアクセスログに変換しません。(現象例)「mv testdir testdir2」 変更前も変更後も「/」がないため、どちらのauditログも記録された結果、正常なRENAMEログになる「mv testdir/ testdir2」 変更前に「/」を付けたため、変更後しかパスが記録されずWRITEのログになる「mv testdir testdir2/」 変更後に「/」を付けたため、変更前しかパスが記録されずRENAMEログになるがTo欄が出ない「mv testdir/ testdir2/」 どちらもログにパスが記録されないため、アクセスログの変換結果がなしとなる
8.8.1.26. Sambaの「アクセス権変更ログ」について (Linux)¶
Sambaのアクセス権変更ログ(エクスプローラー経由の権限操作)は出力されません。
8.8.1.27. Auditログの変換ロジックについて (Linux)¶
8.8.2. その他の制限事項¶
8.8.2.1. 監査ポリシーの自動設定について (Windowsアクセスログ)¶
1. エージェント方式とエージェントレス方式で、監査ポリシーの設定箇所、内容が異なります。エージェントレス方式の場合は、WindowsOSに従来からある監査ポリシーで設定しており、エージェント方式の場合は詳細なセキュリティ監査ポリシーで設定しています。2. エージェント方式の対象ホストに対して監査ポリシーの自動設定をする場合、「監査ポリシーの詳細な構成」をWin32APIにて変更します。その際、APIの仕様上、変更した結果をローカルセキュリティポリシー画面(secpol.msc)で確認することができません。実際のポリシーの値（変更した結果）を確認する場合のコマンド「auditpol.exe/get /category:*」3. 監査ポリシーの変更は、対象ホストのローカル設定をWin32APIにて更新しています。このため、以下の制限があります。a. エージェント方式/エージェントレス方式共に、対象ホストがActive Directoryドメインに所属している場合、ドメインのグループポリシーの設定によってはポリシーの上書きが発生します。b. エージェント方式の場合、secpol.msc(=ローカルセキュリティポリシー。ローカルグループポリシーオブジェクトのセキュリティ設定部分)の「監査ポリシーの詳細な構成」を変更していると、グループポリシーの更新のタイミングでポリシーの上書きが発生します。
8.8.2.2. イベントログが破損している場合におけるタスクへの影響と変換について (Windowsアクセスログ)¶
Windowsのイベントログは、希にOSから出力されている時点で既に破損している事があります。 破損の程度は、ファイル全体が破損しているケースから、1行の特定レコードが破損しているケース、または特定レコードの中の特定のパラメータが破損している等、様々です。
ALogでは完全に破損している場合、収集タスクでエラーが発生し収集することが出来ません。 また、収集の際、収集対象となるイベントログファイルの先頭30行、および末尾30行の中に破損があれば、破損の行をスキップして収集します。 このときに、該当する先頭・末尾行以外に破損があってもエラーとはなりませんが、当該ログの変換時に、その破損レコードが変換対象となった場合には変換をスキップして処理を継続するため、アクセスログに変換できないレコードが発生します。 また、破損の状況によっては破損と認識せずに、その破損したデータをそのまま利用して変換等を行う場合があります。 その場合はアクセスログにその壊れたデータがそのまま表示されることがあります。
8.8.2.3. イベントログのOS設定について (Windowsアクセスログ)¶
1. 対象ホスト設定がエージェントレス方式、かつ収集対象のイベントログのパスが以下の場合、イベントログ収集タスクで対象ホストのイベントログをリモート収集する処理や、対象ホスト設定編集ダイアログでイベントログのOS設定を変更する処理などが正常に動作しません。a. %SystemRoot% 以外の環境変数が含まれているb. %SystemRoot% 環境変数が含まれており、かつその値が C:\Windows でない2. イベントログの出力先を変更した際、変更先のフォルダーに既に過去のイベントログが存在していると、過去のフォルダーにおける収集履歴はリセットされているため、すべてのイベントログが収集対象となります。重複したログの収集を避けるためには、変更先のフォルダーの中のイベントログを退避する必要があります。3. エージェント方式で、収集ユーザーにAdministratorsグループに属するAdministrator以外のユーザーを指定するとイベントログOS設定の取得が正常に動作しません。これを回避するためには対象ホストのUACを無効にする必要があります。
8.8.2.4. クラスタ構成の場合について (SQL Server)¶
対象ホストがクラスタ構成でフェールオーバー発生時に以下の条件に当てはまる場合は、トレースログの欠落が発生する可能性があります。
主機のトレースログがRAM上に保存されていて、トレースファイルに書き込まれる前にフェールオーバーした場合
フェールオーバー発生後に副機の監査設定を実施した場合（フェールオーバーが発生してから副機の監査設定が完了するまでの間はトレースログを取得することができません）
8.8.2.5. 初期化パラメータ・ファイル(PFILE)をご利用の場合について (Oracle)¶
初期化パラメータ・ファイル(PFILE)をご利用の場合、以下のとおりファイルの書き換えが必要になります。ファイルの書き換えは対象ホスト追加後に実施してください。1. 初期化パラメータ・ファイルのバックアップ2. 下記の行を追加するaudit_trail = OS audit_sys_operations=TRUE audit_file_dest='D:\alogora_trace\ORCL'
3. 設定を反映するため、Oracleインスタンスを再起動する設定を確認するには、sqlplusでOracleへ接続後 下記SQLを実行し確認する【SQL】show parameters audit_trail 【SQL】show parameters audit_sys_operations 【SQL】show parameters audit_file_dest注意
対象ホストを追加後に「SYSDBAログ」、「RAWSQLログ」を変更する場合は、Oracleインスタンスの再起動が必要になります。注意
「audit_trail = OS」の指定はOS出力時の設定例です。出力設定に合わせて置き換えて設定してください。( 例：audit_trail = XML,EXTENDED )
8.8.2.6. 複数のアクセスログ/イベントログ出力設定(バックアップ)で、同じ保存先フォルダーを指定すると、保存や自動削除が正しく動作しない場合について (Webコンソール)¶
アクセスログ/イベントログ出力設定において、複数の出力設定同士で同じ保存先フォルダーを重複して指定してしまうと、保存や自動削除の機能が正しく動作しません。 アクセスログ/イベントログ出力設定を複数にする際は、それぞれ保存先フォルダーを分けてください。 また、すでに作成している出力設定の内容を変更する場合も、出力先を変更するか、それまで出力していたデータを事前に別フォルダーに退避させてください。
8.8.2.7. レポートファイルの削除の際、特定のケースで誤判断によりレポートファイルが削除される場合について (Webコンソール)¶
出力されたレポートファイルを削除する際、<レポートタイトル> + <->でファイルを検索し、ヒットしたものを削除します。そのため、以下の様なケースの場合、誤判断をしてしまい、意図しないレポートファイルも削除してしまいます。
「ファイルランキング」 3ヶ月で削除 c:\reportに出力
「ファイルランキング-2」 5ヶ月で削除 c:\reportに出力
上記のケースでは、「ファイルランキング」で検索した結果、「ファイルランキング-2」も条件にヒットしてしまい、「ファイルランキング-2」が5ヵ月ではなく、3ヵ月で削除されてしまいます。このような誤判断を回避するためには、レポートタイトルを異なる名称に変更するか、レポートファイルの出力先を異なるパスにする必要があります。なお、共通設定の場合は削除期間と出力パスが共通のため影響はありません。この制限事項は、個別設定のレポートが共通設定や他の個別設定と出力パスが同じ場合に起こる可能性があります。
8.8.2.8. レポートタイトルの不適合な文字を「_」に置換するため、ファイル名が重複し、意図しない処理が行われる場合について (Webコンソール)¶
レポートタイトルにファイル名として不適合な文字があった場合、レポートファイルを出力する際に不適合文字を「_」に置換します。その結果、ファイル名が重複してしまう可能性があります。ファイル名が重複した場合、ファイル作成時に上書きをしたり、削除時に削除してしまいます。このような場合は、個別設定で出力先を変更するか、レポートタイトルを変更する必要があります。
8.8.2.9. 8191byte以上の文字列が入っている項目を含むアクセスログがある場合の検索時とレポートの制限について(Webコンソール)¶
8191byte以上の文字列が入っている項目を含むアクセスログがある場合、該当のアクセスログは検索結果にヒットしません。(現象例)10件のレコードのうち、1件だけ[Event]欄に8191byte以上入っているアクセスログがあった場合、すべての[Event]欄に検索した文字列があったとしても、検索では9件しかヒットしない
8.8.2.10. ALogで扱えるフォルダー、ファイルのパスの長さの制限について (Webコンソール)¶
ALogにおいて収集/変換/レポート作成等で様々なファイル処理が発生しますが、.NET 6の制限により、フォルダーパスおよびファイルパスが「32767文字以上」に該当する場合、エラーとなり扱えません。上記の他に各OSでの長さ制限によりエラーが発生する可能性があります。
8.8.2.11. バックアップ機能やアンチウィルスソフトがデータファイルを排他で開き、エラーとなる場合について¶
ALogのアプリケーションデータ用フォルダーをバックアップ機能(robocopy等)のコピー対象や、アンチウィルスソフトのリアルタイムスキャンの対象にしている場合、バックアップ機能やアンチウィルスソフトがALogのデータファイルを排他で開き、各種処理がデータファイルを開けずエラーになることがあります。アプリケーションデータ用フォルダーはバックアップ機能やアンチウィルスソフトの対象外にしてください。
8.8.2.12. レポートタスクを「停止」(キャンセル)した場合のファイル出力について¶
レポートタスクをステータス画面から「停止」した場合、ファイル出力の設定によって出力処理の途中でキャンセルされたファイルは作成されません。必要な場合は、レポート画面から「再作成」を行うことでファイルを作成してください。
8.8.2.13. データベースの運用について¶
データベース更新中にOSシャットダウンやサービス停止が行われると、データベースが破損する可能性があります。安全に運用するために、OSシャットダウンやサービス停止の際はタスクが動作していないことを確認してください。手順は『 ALogをインストールしたホストのOSシャットダウンや「ALog」および「ALogDB」サービスを停止する手順 』を参考にしてください。
8.8.2.14. インポート時のディスク使用率に関する制限¶
ALogDataフォルダーが存在するディスクの使用率が95%を越えた際、インポートタスクが失敗する可能性があります。エラーが発生した場合には、該当ディスク内のファイルの削除や容量を増やすなどして、ディスクの使用率を下げてください。
8.8.2.15. サービス停止時のディスク使用率に関する制限¶
ALogDataフォルダーが存在するディスクの使用率が95%を越えた状態で、サービス停止すると次回サービス起動時にデータベースがロックされてしまう可能性があります。本事象が発生した場合は、網屋までお問合せください。
8.8.3. Amazon FSx for Windows File Serverの制限事項¶
8.8.3.1. ログ変換に関する制限事項¶
Amazon FSx for Windows File Serverのログは、ALogでは全て「ObjectAccess」操作として出力します。ファイルの新規作成、書き込み、削除、どのような操作も「ObjectAccess」になります。基本的に「何らかのファイル操作があった」と読み取ります。(理由)Amazon FSx for Windows File Serverは出力するイベントログの絞り込みをしており、ALogで操作を判断するための情報が不足しているためです。「ファイルを書き込み」したイベントログに「削除」の情報が付与されているケースがありますが、これを「書き込み」の操作であると判断する材料がありません。詳細フィールドにAccessList、AccessMaskを出力していますので、それらの情報から判断できる情報があります。詳細についてはAmazon FSx for Windows File Serverの監査ログの説明ページを参照してください。
8.8.4. マッピング設定を要するログタイプを対象とした制限事項¶
8.8.4.1. ログ収集に関する制限事項¶
|
|
|
|
8.8.4.1.1. BOM(byte order mark)を含む収集対象のファイルの処理¶
|
|
|
収集対象ファイルが先頭にBOM（byte order mark）を含むファイルであった場合、差分収集したファイルはBOM（byte order mark）のないファイルになります。 また、ファイルの分割が行われた場合、差分収集のような、単純なバイトカットではないため、以下のような処理結果になります。
分割後のファイルの改行コードは、「CR/LF」になる。 utf-8またはutf-16などで分割した場合は、BOM（byte order mark）が必ず付加される。
8.8.4.1.2. 特定の条件下において対象ホストからのイベントログ収集処理が正常に動作しない¶
|
対象ホストから収集の対象としているイベントログのパスが以下のような状況にある場合、ログ収集タスクで対象ホストのイベントログを収集する処理が正常に動作しません。
%SystemRoot% 以外の環境変数が含まれている。
%SystemRoot% 環境変数が含まれており、かつその値が C:\Windowsではない。
収集対象となるログが格納されているフォルダーパスに対し、管理共有経由でアクセスできない。
8.8.4.1.3. 変更後の収集対象パスに過去のイベントログが存在する場合そのイベントログも収集されてしまう¶
|
収集対象としているイベントログのパスを変更した際、変更後のパスのフォルダーに過去のイベントログが存在している場合、過去のフォルダーにおける収集履歴はリセットされているため、すべてのイベントログが収集対象となり、結果重複したログ収集となってしまいます。 なお、この重複したログ収集を避けるためには、変更後のパスのフォルダー内のイベントログを退避する必要があります。
8.8.4.2. 対象ホスト管理に関する制限事項¶
8.8.4.2.1. 収集対象となるログのフォーマットが変わった場合、ログ変換時にエラーとなる可能性がある¶
ファイル形式がCSVのログを収集するために、マッピングの設定で、「CSV/TSV/DSV」を選択し、カンマ区切りを指定した
その後、出力されるログのファイル形式がSyslogに変更となったため、対象ホストのマッピングの設定を「CSV/TSV/DSV」から「Syslog」に変更した
8.8.4.2.2. ログ変換時のマージ処理について¶
マッピング設定を要するログタイプを選択した場合において、[マッピング設定-出力]設定のオプション「重複する行を1行にマージする」にチェックをつけるとマージ処理が動作しますが、この処理はファイル内のレコードに対して行われるため、別ファイルに分かれる場合はマージ処理を行いません。またファイル内のレコードにおいて、TimeStampフィールドの記録順にマージ処理を行います。TimeStampフィールドを変換処理時に並び替えすることは行いませんので、場合によっては期待するマージが行われない場合があります。
8.8.4.2.3. 過去のログを再変換する時のログフォーマット毎の既定値について¶
ログフォーマット
設定項目
適用される値
プレーンテキスト
文字コード
UTF-8
自動フォーマット設定
ユーザー設定値
プレーンテキスト（旧方式）
文字コード
UTF-8
正規表現文字列
ユーザー設定値
CSV/TSV/DSV
文字コード
UTF-8
区切り文字
ユーザー設定値
入力ファイルにヘッダーを含む
OFF
空のフィールドを除外
OFF
コメント行の先頭文字
ユーザー設定値
JSON
文字コード
UTF-8
Syslog
文字コード
UTF-8
注意
ログフォーマットで「CSV/TSV/DSV」を選択した際、「区切り文字」および「コメント行の先頭文字」は任意の値へ変更することが可能ですが、再変換が失敗する原因となる可能性があります。