Read this blog post. If that configuration is slow it is most likely because grok is slow. grok will be slow when it fails to match DATA or GREEDYDATA correctly and has to backtrack and start over. I would suggest replacing %{DATA:service} with (?<service>[^|]*) and likewise for env, dc, etc.
Thank you Badger. That help.
I could see below error in the container.
[2023-12-14T11:03:25,013][WARN ][filewatch.tailmode.processor][main][993ec5e5da348f46223f1ca5d2f39d980341bc3b6c17be730f7dc2ed5b7db313] >>> Rotation In Progress - inode change detected and original content is not fully read, file is closed and path points to new content {:watched_file=>"<FileWatch::WatchedFile: @filename='status-cog-1.1.1553-74766c4c6d-fnhqg', @state=:rotation_in_progress, @recent_states=[], @bytes_read=0, @bytes_unread=0, current_size=4515709, last_stat_size=4515709, file_open?=false, @initial=true, sincedb_key='138215548 0 66305'>"}
What does this mean?
Is logstash sending the purged file? How does this handle purged file?
I don't see sincedb file created for this service which I m not receiving in kibana.
If filewatch detects that a rotation is in progress (i.e. my.log.1 is being renamed to my.log.2, my.log is being renamed to my.log.1 etc.) then if the code currently has a file handle open to read my.log it will simply read the whole of the rest of the file before closing it. If it doesn't have an open file handle then it logs that warning to tell you that it will not finish reading my.log.1 after the rotation.
A file input looks for logs by name, but tracks them in the sincedb by inode, so it it calls stat and the inode for my.log has changed then it knows there has been a file rotation.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.