Logstash详细介绍
下面我们将对ELK框架进行深入详细的了解,了解了其中的原理,才能选择更加高效可靠的配置方案。ElasticSearch的配置比较简单,主要性能瓶颈在于内存以及节点设置方面,Kibana的配置也较为简单,web应用无很大的优化改进空间,主要在于第三方插件的使用。下面我们主要介绍Logstash的方案设计。
Logstash使用Ruby语言编写,它编写了自己的一套DSL。Logstash在处理数据的时候,就像管道一样,每一个配置文件中都必须存在一个input插件和一个output插件,数据以流的形式在管道中进行传输。下面我通用一个图例来表示,日志数据就像是大小形状不同的图案,通过nput进入到管道内部,然后通过一个圆形的filter插件,这样从output出来的数据就都成为了圆形。所以一个标准的Logstash配置,应该同时存在一个nput,filter,output配置。
通过官方文档我们可以看到,由于开放的社区环境,logstash中存在大量的插件,功能丰富且强大。可以接受多种形式的数据,进行多样性的处理,最后传输到各种各样的环境中。下面我们结合实际情况,介绍一些常用的插件。
- 情景:需要监控Apache等生成的日志,可以动态监控文件内容。
解决方案:
监控文件内容,使用input:file插件。Logstash中使用一个名叫FileWatch的Ruby Gem库来监听文件变化,并且会生成一个${Home}/.sincedb的数据库文件来记录被监听的日志文件的当前读取位置。具体实现如下:
input {
file {
type => “apache”
path => "apache_access.log"
start_position => "beginning"
sincedb_path => "/dev/null"
}
}
type:通过type字段来表示这个日志的类型或者归属等特性,用来进行区分。
path:指定需要监控的文件,可以使用*号来表示某个路径下的所有满足条件的文件。
start_position:默认为”beginning”,表示每次Logstash重启后文件都从头开始加载,直到当前监控的位置。”end”选项表示,每次读取文件都从最后开始,接收当前传输的最新的文件。
sincedb_path:指定.sincedb文件的位置。每次logstash读取数据时会从since_db中记录的pos开始读取数据。如果在重复测试的时候,为了方便,可以将sincedb_path定义为/dev/null,这样logstash每次重启时都会从头开始读取文件。
情景:获取到日志文件后,需要对数据进行提取,最终以key-value字段的形式显示,便于Elasticsearch对数据进行索引,方便后期Kibana生成图表等。
解决方案:
使用filter:grok插件对数据进行提取。因为logstah会根据事件传输的当前时间自动给事件加上@timestamp字段,后续elasticsearch会根据该字段对事件进行排序。如果需要将日志中的事件抽取为@timestamp字段,还需用到filter:date插件。
假设当前日志为log4j打印日志的格式为:%d [%p] [%c{1}] [%t] %30.30C.%M():%L - %m%n
具体实现如下:
filter {
if [type] == "log4j" {
grok {
match=>["message",
"(?m)%{
TIMESTAMP_ISO8601:timestamp}\[%{
LOGLEVEL:logLevel}\] \[%{
WORD:method}\] \[%{
GREEDYDATA:thread}\] %{
GREEDYDATA:javaClass}\(\)\:%{
NUMBER:line} - {
GREEDYDATA:message}"]
remove_field => ["@version"]
overwrite => [