logstash处理文件进度记录机制

简介: 假如使用如下配置处理日志input { file { path => "/home/vagrant/logstash/logstash-2.

假如使用如下配置处理日志

input {
     file {
        path => "/home/vagrant/logstash/logstash-2.2.2/dbpool-logs/dev/common-sql-*.log"
        start_position => "beginning"
        type => "sql"
        codec => json {
            charset => "UTF-8"
        }        
     }
}
output { 
    if "_grokparsefailure" in [tags] {
    }else{
        if [type] == "sql"{
                elasticsearch {
                         hosts => ["http://192.168.33.10:9200"]
                         index => "common-sql-%{+YYYY.MM.dd}"
                }
       }
    }
}
  • 所有匹配common-sql-*.log的文件都将被处理

  • 第一次从头开始处理文件

  • 处理后以json格式输出到elasticsearch

logstash如何记录处理进度?

  • 第一次运行logstash时从头处理文件,假如此时有两个文件匹配上则按顺序开始处理文件。
  • logstash处理过程中不断将每个文件处理的进度写入到某个地方,这就是sincedb。
  • sincedb一般以隐藏文件默认写到home目录下面,文件名类似.sincedb_6268051ae572b42bd86b7f9e8c1e004b。
  • sincedb的格式为inode majorNumber minor Number pos。每行记录每个文件处理进度,比如下面的例子,表示inode为177037的文件处理到25951716位置、inode为176956的文件处理到32955178位置。
177037 0 64768 25951716
176956 0 64768 32955178
  • 用stat看看这两个文件inode信息。可以看到两个文件都已经处理完了。如果没处理完关闭了logstash则会在下次启动时继续处理。
[vagrant@hb-localhost ~]$ stat logstash/logstash-2.2.2/dbpool-logs/dev/common-sql-2016-11-24.log 
  File: `logstash/logstash-2.2.2/dbpool-logs/dev/common-sql-2016-11-24.log'
  Size: 32955178    Blocks: 64368      IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 176956      Links: 1
Access: (0664/-rw-rw-r--)  Uid: (  501/ vagrant)   Gid: (  501/ vagrant)
Access: 2016-11-24 02:08:19.058506565 +0000
Modify: 2016-11-24 01:46:14.000000000 +0000
Change: 2016-11-24 02:05:06.194122690 +0000
[vagrant@hb-localhost ~]$ stat logstash/logstash-2.2.2/dbpool-logs/dev/common-sql-2016-11-23.log 
  File: `logstash/logstash-2.2.2/dbpool-logs/dev/common-sql-2016-11-23.log'
  Size: 25951716    Blocks: 50688      IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 177037      Links: 1
Access: (0664/-rw-rw-r--)  Uid: (  501/ vagrant)   Gid: (  501/ vagrant)
Access: 2016-11-24 02:15:28.217978771 +0000
Modify: 2016-11-23 13:19:16.000000000 +0000
Change: 2016-11-24 02:15:27.913826772 +0000
  • 如果往这两个文件追加日志则将往下继续处理,而且也会将进度更新到sincedb文件中。
  • 如果处理完了关闭logstash,下次再启动时则不会再从头开始处理,因为sincedb已经记录了进度,不要以为start_position => “beginning”就是每次都从头处理,如果把sincedb文件删了又会从头开始处理。

========广告时间========

鄙人的新书《Tomcat内核设计剖析》已经在京东销售了,有需要的朋友可以到 https://item.jd.com/12185360.html 进行预定。感谢各位朋友。

为什么写《Tomcat内核设计剖析》

=========================

目录
相关文章
|
2月前
|
SQL JSON Java
Flink数据问题之checkpoint数据删除失败如何解决
Apache Flink是由Apache软件基金会开发的开源流处理框架,其核心是用Java和Scala编写的分布式流数据流引擎。本合集提供有关Apache Flink相关技术、使用技巧和最佳实践的资源。
|
5月前
|
数据库
解决logstash同步数据库内容到ES时,同步时间点用到了别的表的最新时间点
解决logstash同步数据库内容到ES时,同步时间点用到了别的表的最新时间点
26 0
|
7月前
|
运维 监控 安全
使用日志数据的方式
使用日志数据的方式
45 0
|
7月前
|
网络安全
Agent 报告复制作业 "sync" 进度时遇到错误
Agent 报告复制作业 "sync" 进度时遇到错误
57 1
|
10月前
|
存储 Kubernetes Linux
k8s日志自动收集脚本
k8s日志自动收集脚本
143 0
|
消息中间件 监控 Kafka
flume搜集日志:如何解决实时不断追加的日志文件及不断增加的文件个数问题
flume搜集日志:如何解决实时不断追加的日志文件及不断增加的文件个数问题
204 0
flume搜集日志:如何解决实时不断追加的日志文件及不断增加的文件个数问题
一次性捋清楚吧,对乱糟糟的“日志”说再见
最近一个朋友老是和我抱怨:公司系统日志打得实在是太烂了,有用的信息很少,没用的一大堆。就连那有用的信息,在那么多节点日志之间进行追查,也是痛苦的一笔。 我问他,公司没有日志收集吗,日志收集起来看总好过一个节点一个节点日志查看。他表示,公司有接入一个收费第三方的日志产品,做了收集。但是仅仅是方便了统一化查看搜索,但是系统本身的日志缺少一些关键性的要素。比较乱,在很多微服务之间查看调用日志时定位很难。
|
开发工具
【vim使用】问题记录,不定时更新
【vim使用】问题记录,不定时更新
194 0
|
网络协议 Windows
【错误集】不定时更新
文章目录 前言 一、内容 二、服务(配置文件) 2.1 DNS服务无效(文件无权
126 0
【错误集】不定时更新
|
SQL 存储 运维
FLIP-147:支持包含结束任务的 Checkpoint 操作与作业结束流程修正
为了完善流执行模式对有限数据流的支持,所进行的改动以及更详细的实现。
FLIP-147:支持包含结束任务的 Checkpoint 操作与作业结束流程修正