Logstashファイル入力からのsincedbファイルの理解
Logstashで file input を使用すると、監視対象のログファイルの現在の位置を追跡するためにsincedbファイルが書き込まれます。その内容を理解する方法は？
Sincedbファイルの例：
286105 0 19 20678374
4つのフィールドがあります（ ソース ）：
- iノード
- メジャーデバイス番号
- マイナーデバイス番号
- バイトオフセット
ハードディスクが数千の非常に小さな部分に分割され、それぞれに番号が付けられていると仮定すると、iノードはファイルが始まる小さな部分の数とほぼ同じになります。したがって、特定のiノードは各ハードディスクに固有ですが、同じサーバー上に複数のディスクがある場合に対処するには、トリプレットの一意性を保証するためにメジャーデバイス番号とマイナーデバイス番号を使用する必要があります{inode、マイナーデバイス番号、マイナーデバイス番号}。 Wikipedia のiノードに関するより正確な情報。
とはいえ、NFSを介してマウントされたファイルのiノードはリモートファイルのように見えるため、（たとえば）NFSを介してマウントされたファイルがローカルファイルと衝突できないかどうかはわかりません。プラグインの作成者がそのようなケースを気にかけていなかったとは思いますが、NFSを自分で使用していても、これまでのところ問題は発生していません。また、衝突の確率は非常に小さいと思います。
これで、iノードとメジャーおよびマイナーデバイス番号によって形成されたトリプレットを使用して、プラグインによってエラーなしで読み取られている単一のログファイルをターゲットにする方法があります（または少なくともそれが元の意図でした）。最後の数値であるバイトオフセットは、入力ログファイルがすでに読み取られてLogstashに出力された距離を追跡します。
Solaris や Windows などの特定のアーキテクチャでは、Rubyが0に等しいiノード番号を誤って検出するというバグがありました。これはたとえば、logstashがファイルのローテーションを検出しないなどの問題が発生する可能性があります。
これはとても役に立ちました。すべてのSinceDBファイルをlogstash入力にマップしたかったので、このマッピングを印刷するために小さなbash2ライナーをまとめました。
filesystems=$(grep path /etc/logstash/conf.d/*.conf | awk -F'=>' '{ print $2 }' | xargs -I {} df -P {} 2>/dev/null | grep -v Filesystem | sort | uniq | cut -d' ' -f 1)
for fs in $filesystems; do for f in $(ls -a .sincedb_*); do echo $f; inodes=$(cut -d' ' -f 1 $f); for inode in $inodes; do Sudo debugfs -R "ncheck $inode" $fs 2>/dev/null | grep -v Inode | cut -f 2; done; echo; done; done
SinceDBファイルをlogstash入力にマッピングする に関する詳細を文書化しました。