Podczas używania file input z Logstash, zapisywany jest plik sincedb w celu śledzenia aktualnej pozycji monitorowanych plików dziennika. Jak rozumieć jego zawartość?Zrozumienie plików sincedb z pliku wejściowego Logstash
przykład pliku sincedb:
286105 0 19 20678374
Istnieją 4 pola (source)
Zakładając, że dysk twardy zostałby podzielony na tysiące bardzo małych części z liczbą dla każdego, to i-węzeł byłby mniej więcej numerem maleńkiej części, od której zaczyna się plik. Tak więc dany i-węzeł jest unikalny dla każdego dysku twardego, ale w celu adresowania przypadków, w których znajduje się wiele dysków na tym samym serwerze, wymagany jest duży i mniejszy numer urządzenia, aby zagwarantować unikalność tripletu {i-węzła, mniejszy numer urządzenia, podrzędny numer urządzenia}. Dokładniejsze informacje na temat i-węzłów na Wikipedia.
To powiedziawszy, nie jestem pewien, że (na przykład) pliki montowane przez NFS nie mogą kolidować z plikami lokalnymi, ponieważ i-węzeł pliku zamontowanego przez NFS wydaje się być zdalny. Chociaż nie sądzę, aby autor wtyczek zajmował się takimi przypadkami i pomimo używania samego NFS, nigdy nie napotkaliśmy żadnych problemów. Podejrzewam też, że prawdopodobieństwo kolizji jest bardzo małe.
Teraz z triolą utworzoną przez i-węzeł oraz główny i drugorzędny numer urządzenia mamy sposób kierowania na pojedynczy plik dziennika, który jest odczytywany przez wtyczkę bez błędu (lub przynajmniej to było pierwotne założenie). Ostatni numer, offset bajtowy, śledzi odległość pliku dziennika wejścia, która została już odczytana i wysłana do Logstash.
W niektórych specyficznych architekturach, takich jak Solaris lub Windows pojawiły się błędy z rubinem błędnie wykrywające numer i-węzła, który był równy 0. Może to na przykład prowadzić do problemów takich jak logstash nie wykrywający rotacji pliku.
To było bardzo pomocne. Chciałem zamapować wszystkie moje pliki SinceDB na wejścia logstash, więc przygotowałem dwuczęściowy bash do wydrukowania tego mapowania.
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
Właśnie udokumentowałem szczegóły dotyczące mapping SinceDB files to logstash input.
Dlaczego nie opisać wszystkich 4 pól w odpowiedzi na pytanie, a może z większym autorytetem? –
Po prostu podaję rzadkie informacje, które były już trudne do zdobycia. Moim celem nie było rozpoczynanie artykułu wikipedii. W każdym razie uświadomiłeś mi, że "przesunięcie bajtu" nie było oczywiste dla wszystkich, więc dodałem trochę więcej informacji. – Aldian