Universal Forwarderを使用したログ収集の仕様について,splunk forwaderによるログ収集の仕様について

[iyo063help]

初めて投稿させていただきます。至らない点が多々あるかと存じますがご容赦願います。
現在、Universal Forwarderを使用して収集している一部のログが断続的に取得できなくなる事象が発生しています。
原因調査のため、ログ収集の仕様についてご教示いただきたく存じます。

＜発生している事象＞
　対象ログ：JP1のスケジュールログ（ajs-log1.log、ajs-log2.log）
　　　　　　※log1、log2で自動ローテーションしています。（log1(2)が所定の容量になると、log2(1)に切り替わる。）
　発生事象：log1、log2ともに、ログファイルの中身が更新されてもsplunkにデータが収集されない場合がある。

＜OS、バージョン情報＞
　マネージャ側
　　OS：RedHatLinux 7.2
　　Splunk：7.1.2
　クライアント側
　　OS：Windows Server 2016
　　Universal Forwarder：7.1.2

＜確認事項＞
　Universal Forwarderは何をトリガーとして、収集対象ファイルの更新を検出しているのでしょうか。

＜確認事項の意図＞
　発生している事象で気になる点として、ログファイルの実態も、中身は更新されているのに
　更新日が更新されない状態となっており、こちらがログ収集が正常に行えない要因になっている
　のではないかと推測しています。まずはこの推測が正しいことを確認するために、本質問を
　起票させていただきました。

以上、ご教示の程何卒よろしくお願いします。

[to4kawa]

https://docs.splunk.com/Documentation/Splunk/8.0.2/Data/Monitorfilesanddirectorieswithinputs.conf

回答としては、 設定によります
@dillencehsu さんの方法もあれば、
followTail = 1 といった方法、もちろん更新日時でも可能
と記載されています

[iyo063help]

ご回答ありがとうございます。また、参考URLのご提供ありがとうございます。

現在の設定を確認したのですが、全てデフォルト設定となっているようです。

状況の補足なのですが、同構成のテスト環境では正常にログが取得できており（ファイルの更新日もタイムリーに更新されている）本番環境のみ当事象が発生しています。
また、OSの再起動により、一時的に症状が改善する（ログの収集が再開され、ファイルの更新も行われる）ことが多く、splunkの設定不備ではないような気がしています。（但し、数日後に症状が再発します。）

デフォルトではタイムスタンプによる判定はしていないとのことなので、ログファイルの更新日不備と収集できなくなる事象は関係ないのかもしれませんが、収集できているときはログファイルの更新も正常に行われているため何かしらの因果関係があるのではないかと考えています。

テスト環境での再現ができないため、ご教示いただいた設定の検証も難しい状況です。
まずは、更新日の不備について、OS側のサポートに問合せを実施してみようと思います。

親切なご対応誠にありがとうございました。

[dillencehsu]

よろしければ、inputs.conf を拝見させていただけないでしょうか。

＜発生している事象＞の状況を読むと、推理いたします。
各ファイル頭の CRC は一致で、Splunk が同じファイルと認識しているので、ログファイルを食べない。

下記２つ設定試して見ましょう。#inputs.conf
・crcSalt = を inputs.conf で各 inputs stanza を追加したら解決できると思います。
・initCrcLength = （default is 256 文字でチェック）512 以上に変更したら解決できると思います。

そうしてから、
index : _thefishbuck の中身を削除して再起動してから Splunk がログファイルをちゃんと食べれるはずです。

[iyo063help]

ご回答ありがとうございます。
確認しましたが、inputs.confにcrcSaltの設定はございませんでした。

また、ajs-log1.log、ajs-log2.logの出力内容は類似していますが、ログには日時が出力されるため、
2つのファイルの先頭に同様の文字列が出力されることはないと考えております。

学習不足であるため、crcSaltの設定について認識相違等がございましたらご指摘をお願いいたします。

[dillencehsu]

crcSalt 設定の認識は間違っていません。

ちなみに、ログファイルアクセスできる権限と Splunk 実行権限は同じでしょうか。

普通の状況、Windows の Splunk は SYSTEM このアカウントが実行しています。

もし、SYSTEM がログファイルアクセスできないなら、ログ順調に取り読めません。

チェックしていただければ幸いです。

どうぞよろしくお願いします。

[iyo063help]

ご回答ありがとうございます。
SYSTEMアカウントが実行しており、当該ログへのアクセス権限を保有していることを確認いたしました。

[dillencehsu]

index=_internal component=TailReader OR component=WatchedFile host=クライアント側ホスト名 ajs-log*.log

Universal Forwarder がちゃんとログファイルを食べているかどうか、
ちょっと調べて見ましょう。

どうぞよろしくお願いいたします。

[iyo063help]

ご回答ありがとうございます。
ご教示いただいた一文でサーチをかければよいのでしょうか？
実行してみましたが、対象が見つかりませんでした。
学習不足で申し訳ございませんが、どういった条件の検索になるのでしょうか？

[dillencehsu]

実は、Splunk がログファイルを取り読むの際にこのようなログがあります。

03-25-2020 15:09:12.689 +0900 INFO  WatchedFile - Checksum for seekptr didn't match, will re-read entire file='/opt/splunk/var/log/splunk/audit.log'.

こちらの Search Code を使っていただければ手掛かりを見つけるかもしれません。
index=_internal component=TailReader OR component=WatchedFile host="Forwarder のホスト名" ajs-log*.log

[to4kawa]

更新日が更新されないのはSplunkの問題ではないと思いますが、JP1のサポートの回答はありますか？

あとはSplunkの方のblogを
https://qiita.com/odorusatoshi/items/5a703b9befc253ab7deb

ただ、おもしろいなと思ったのが、普通は内容が更新されたら、タイムスタンプは更新されますよね？
でも、サポート側が自分の問題でないとつっぱねているのがこの質問になったのかな？と。

その際には、「さまざまなソフトウェアが内容の更新をタイムスタンプの更新で把握している。これは不具合ではないか？そうではないというのであればJP１はどうやってログファイルの更新を管理しているのか？」とか問い合わせるといいと思います。
Splunkの話ではないですね

[iyo063help]

ご回答ありがとうございます。

更新日が更新されないのはSplunkの問題ではないと思いますが、JP1のサポートの回答はありますか？
→ JP1側に問合せした結果は、「ログファイルは、アクティブな面が常時共有でオープンされている。
　Windowsの場合、ファイルのクローズ時に更新日が更新されるケースがあるという情報があるが、
　当製品での類似事例の問合せはない。ファイル更新はOSの仕様となるのでMS社へ問合せして下さい。」
　との回答でした。（to4kawa様ご想像のとおり、突っぱねられたことがご質問の経緯になっています。）
　→ JP1側の仕様として、ログファイルのタイムスタンプがどういう振る舞いをするのが正しいのか
　　という観点で再度問合せしてみようと思います。

Splunkの話ではないですね
→理解が低くて申し訳ございません。念のためご確認なのですが、Splunkも「内容の更新をタイムスタンプの更新で把握しているソフトウェアの一つである」という認識で問題ないでしょうか？

以上、ご教示の程よろしくお願いします。

[to4kawa]

inputs.conf
に
ignoreOlderThan = [s|m|h|d]
* The monitor input compares the modification time on files it encounters
with the current time. If the time elapsed since the modification time
is greater than the value in this setting, Splunk software puts the file
on the ignore list.
* Files on the ignore list are not checked again until the Splunk
platform restarts, or the file monitoring subsystem is reconfigured. This
is true even if the file becomes newer again at a later time.
* Reconfigurations occur when changes are made to monitor or batch
inputs through Splunk Web or the command line.
* Use 'ignoreOlderThan' to increase file monitoring performance when
monitoring a directory hierarchy that contains many older, unchanging
files, and when removing or blacklisting those files from the monitoring
location is not a reasonable option.
* Do NOT select a time that files you want to read could reach in
age, even temporarily. Take potential downtime into consideration!
* Suggested value: 14d, which means 2 weeks
* For example, a time window in significant numbers of days or small
numbers of weeks are probably reasonable choices.
* If you need a time window in small numbers of days or hours,
there are other approaches to consider for performant monitoring
beyond the scope of this setting.
* NOTE: Most modern Windows file access APIs do not update file
modification time while the file is open and being actively written to.
Windows delays updating modification time until the file is closed.
Therefore you might have to choose a larger time window on Windows
hosts where files may be open for long time periods.
* Value must be: . For example, "7d" indicates one week.
* Valid units are "d" (days), "h" (hours), "m" (minutes), and "s"
(seconds).
* No default, meaning there is no threshold and no files are
ignored for modification time reasons
なる記述を見つけました。
デフォルトではタイムスタンプによる重複判定はしていないようですね

[to4kawa]

Splunkの話ではないですね
は、自分のコメントへの所見です。紛らわしくてすいませんでした。