目录html
logstash依赖java 8或 java 11,也可使用OpenJDK,在进行安装时,咱们须要声明JAVA_HOME的环境变量,以保证正常地安装。这里咱们采用OpenJDK的方式,更为简洁。java
[root@elk ~]# java -version openjdk version "1.8.0_222" OpenJDK Runtime Environment (build 1.8.0_222-b10) OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
YUM安装方式:node
# rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch #增长logstash源到yum仓库/etc/yum.repos.d/ [logstash-6.x] name=Elastic repository for 6.x packages baseurl=https://artifacts.elastic.co/packages/6.x/yum gpgcheck=1 gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch enabled=1 autorefresh=1 type=rpm-md # yum install logstash
Logstash的工做原理图:redis
标准的输入输出测试:数据库
/usr/share/logstash/bin/logstash -e 'input {stdin {} } output { stdout {} }' hello
Logstash进行数据采集和流水线处理主要有三个步骤:inputs --> filters --> outputsjson
inputs负责定义数据采集的来源,filters进行自定义的过滤日志的规则,outputs是将日志输出到日志的存储区域,如elasticsearch存储。vim
inputs和outputs都支持对数据的格式进行编码和解码操做。ruby
Inputsbash
inputs支持多种数据采集的方式,经常使用的方式有如下几种:服务器
file:直接读取日志文件,相似命令行执行tailf查看日志
syslog:经过514端口进行监听syslog日志信息
redis:从redis服务器集群中读取日志,redis一般会做为一个中间运输层,以下降logstash日志处理的压力
beats:是一种轻量级的日志收集方式
Filters
Filters是logstash日志收集中的过滤处理层,经常使用的过滤器包含如下几种:
grok:解析和构建任意文本,通俗地说就是将非结构化的日志进行定义成结构化的格式
mutate:对日志的字段进行修改,替换和删除
drop:对日志进行删减部分
clone:对日志进行复制,能够是增长或者是删除操做
geoip:添加ip的地理位置信息,用于在kibana的图表统计信息,能够看到访问的区域分布
Outputs
Outputs是Logstash收集的最后一个环节,一般将前面收集的日志进行过滤规则之后再统一输出到存储区域。一般存储区包含如下几种:
elasticsearch:将收集到的数据发送到elasticsearch,其能够提供高效方便的格式化查询
file:将日志数据存储在文件当中
graphite:将日志存储到开源的时序数据库graphite当中,存储和聚合监控数据并绘制图表
statsd:这是一个监听服务,相似redis的使用,属于一个中间缓冲层,结合graphite一块儿使用
Codecs
Codecs是在输入和输出层的一个文本格式的编码器,支持json,msgpack和各类文本格式,如txt
json:对数据进行编码和解码成json格式
multiline:将多行的文本进行合并成单行的文本格式进行输出
在经过RPM包安装Logstash后,咱们能够看到有不少目录,一般了解一个软件的使用,对目录的使用了解也是很是有必要的,能够加深对Logstash设计的理解,其结构以下:
类型 | 描述 | 默认值 | 如何定义配置 |
---|---|---|---|
home | logstash安装的默认主目录 | /usr/share/logstash | |
bin | logstash的二进制脚本程序和logstash-plugin插件安装脚本 | /usr/share/logstash/bin | |
settings | 配置文件,包括logstash.yml、jvm选项配置、启动选项配置 | /etc/logstash | path.settings |
conf | logstash数据收集配置 | /etc/logstash/conf.d/*.conf | /etc/logstash/pipelines.yml |
logs | 日志文件 | /var/log/logstash | path.logs |
plugins | 插件目录 | /usr/share/logstash/plugins | path.plugins |
data | 数据持久化目录 | /var/lib/logstash | path.data |
Logstash主要有两种配置文件,分别是:logstash.yml和pipeline.yml,logstash.yml用于配置logstash的启动和执行相关配置,pipeline.yml用于配置流水线数据处理的配置。其中在安装完成后,还包含如下的配置文件:
logstash.yml:定义logstash的基础配置信息
pipeline.yml:定义数据收集规则的配置信息
jvm.options:定义JVM的总堆空间的最小值和最大值,也就是内存使用量,默认是1g
log4j2.properties:log4j2库的相关设置
startup.options:定义logstash启动时的相关配置
logstash.yml的详解:
配置参数 | 解析 | 默认值 |
---|---|---|
node.name |
节点名称定义 | 主机名 |
path.data |
持久化数据目录定义 | LOGSTASH_HOME/data |
pipeline.id |
pipeline的id号 | main |
pipeline.java_execution |
使用java执行引擎 | false |
pipeline.workers |
定义在过滤筛选和输出阶段的进程数量 | 默认为cpu的核心数 |
pipeline.batch.size |
定义在筛选和输出以前单次处理数据量大小,一般和jvm的堆内存值相关,值越大,jvm内存配置也须要更大 | 125 |
pipeline.batch.delay |
批处理数据的时间延迟,在数据量不达标时的延迟时间,单位为毫秒 | 50 |
pipeline.unsafe_shutdown |
在关机状态强制关闭logstash在处理的数据,会致使数据丢失 | false |
path.config |
pipeline的相关配置,一般在pipeline.yml中配置好 | |
http.host |
监听配置 | "127.0.0.1" |
http.port |
监听端口 | 9600 |
path.logs |
日志路径 | LOGSTASH_HOME/logs |
log.format |
日志格式 | 文本 |
path.plugins |
插件定义 |
Logstash配置文件构建语法:
input { ... } filter { ... } output { ... }
Logstash 使用一个名叫 FileWatch
的 Ruby Gem 库来监听文件变化。这个库支持 glob 展开文件路径,并且会记录一个叫 .sincedb
的数据库文件来跟踪被监听的日志文件的当前读取位置。sincedb 文件中记录了每一个被监听的文件的inode, major number, minor number 和 pos。
配置示例以下:
input { file { path => "/var/log/messages" type => "system" start_position => "beginning" } } output { stdout { codec => rubydebug } }
tcp模块的使用场景以下: 有一台服务器A只须要收集一个日志,那么咱们就能够不须要在这服务器上安装logstash,咱们经过在其余logstash上启用tcp模块,监听某个端口,而后咱们在这个服务器A把日志经过nc发送到logstash上便可。
input { tcp { port => "5566" mode => "server" type => "tcplog" } } output { stdout { codec => rubydebug } }
syslog支持RFC3164的系统日志格式,在logstash端进行tcp或upd的监听,从而实现对系统日志的收集。配置该日志收集,本机的syslog会默认发送到logstash,同时也要在rsyslog进行配置发送的监听地址。
# vim /etc/rsyslog.conf #修改rsyslog发送日志的监听端口 *.* @@192.168.56.100:44231 #配置logstash收集rsyslog发送的日志并标准输出 input { syslog { port => "44231" } } output { stdout { codec => rubydebug } }
具体实现中,UDP 监听器只用了一个线程,而 TCP 监听器会在接收每一个链接的时候都启动新的线程来处理后续步骤。因此在监听时,建议配置TCP的监听的性能会更佳。
curl '192.168.56.100:9200/_cat/indices?v'