标签:elk elasticsearch logstash kibana
ELK日志分析平台学习记录
首先ELK主要指elasticsearch 、logstash 和kibana,三个开源软件组合而成的一套日志平台解决方案。可以将平时收集到的日志,通过前台展示出来,并且可以加以分析,理论上可以解放劳动力(再也不用干上生产取日志这种活了——很搓)。
最近在研究ELKstack日志分析平台,网上相关的中文资料不多。所以呢也就写了这篇文章将自己的一些学习认识总结记录下来,基本偏实战,概念理论较少,概念这块,我想以后可以再开一篇文章来做一个阐述总结。
这篇文章中会先讲一下搭建部署的内容,这一部分我在自己电脑上建了两台虚拟机来做这个实验,大致做个入门。同时后面我会记录一下我在实际使用过程中的一些心得,还有遇到的一些坑,以及解决办法。由于ELK stack这块我也还在学习摸索中,还有诸多不足,如果有什么不正确的地方,请见谅。
这里推荐大家可以上官网查看官方文档https://www.elastic.co/guide/index.html写的是很全的。
一、架构
采用官方推荐的架构
首先官方推出了轻量化数据收集输送应用beat,其中主要的做日志收集的filebeat是新一代作为原来logstash-forwarder的替代品,那所以就使用filebeat了。
其中beat(现在只使用filebeat)作为 agent端收集日志并发送给logstash,logstash做过滤再给到搜索引擎elasticsearch。最后kibana提供前台界面给用户。
二、安装部署
我这里起了两个虚拟机作为安装部署的实例
IP | role | app |
192.168.247.128 | server | logstash elasticsearch kibana |
192.168.247.129 | client | filebeat |
应用清单
elasticsearch-2.1.1
kibana-4.3.1
logstash-2.1.1-1
filebeat-1.0.1
我这边应用基本都用最新的了,采用的架构可能也与网上较多的logstash→redis→logstash→elasticsearch→kibana的方式不同。那种基于的应用版本可能较低,但是应该在很多地方已经实际投产使用了,稳定性应该有保证。
filebeat、logstash、elasticsearch都采用rpm包安装方式,注意logstash和elasticsearch是基于java的需要先安装jdk。具体的安装要求见https://www.elastic.co/support/matrix
rpm包安装很方便,在此不做赘述
elasticsearch安装后修改下绑定IP启动,elasticsearch的配置文件/etc/elasticsearch/elasticsearch.yml中有许多配置项目,这里不一一说明了。像是存数据的路径、绑定IP端口、集群name等等。
启动后验证
[root@servertest01 elasticsearch]# curl -XGET http://192.168.247.128:9200 { "name" : "Black Crow", "cluster_name" : "elasticsearch", "version" : { "number" : "2.1.1", "build_hash" : "40e2c53a6b6c2972b3d13846e450e66f4375bd71", "build_timestamp" : "2015-12-15T13:05:55Z", "build_snapshot" : false, "lucene_version" : "5.3.1" }, "tagline" : "You Know, for Search" }
logstash先不起,我们先来写配置文件
logstash配置文件主要分三块,官方提供了相当相当多的plugin,可以更具情况来使用,其中filter不是必须项。
由于实验用filebeat采集数据,然后输出到elasticsearch。所以input plugin用beats, output plugin用elasticsearch。
input { beats { port => "5044" } } output { elasticsearch { hosts => "192.168.247.128" index =>"hello-%{+YYYY.MM.dd}" } }
我把5044端口作为输入端口,logstash提供了检查语法的功能service logstash configtest,检查好OK后(这里是实验很简单所以不用检查也可以,但是我在实际使用中内容会比较多,会有codec filter plugin等等配置难免会有遗漏,所以检查下养成个好习惯),启动service logstash start
客户端上的filebeat在启动前,elasticsearch需要先读取其索引模版
[root@clienttest01 ~]# curl -XPUT ‘http://192.168.247.128:9200/_template/filebeat?pretty‘ -d@/etc/filebeat/filebeat.template.json { "acknowledged" : true }
来看看默认的配置文件
[root@clienttest01 filebeat]# egrep -v ‘^$|^#|^\s+#‘ filebeat.yml filebeat: prospectors: - paths: - /var/log/*.log input_type: log registry_file: /var/lib/filebeat/registry output: elasticsearch: hosts: ["localhost:9200"] shipper: logging: files: rotateeverybytes: 10485760 # = 10MB
为做实验我做了下修改,启动
[root@clienttest01 filebeat]# more filebeat.yml filebeat: prospectors: - paths: - /var/log/*.log input_type: log output: logstash: hosts: ["192.168.247.128:5044"]
然后我就在 /var/log下建了a.log 随便追加了一些信息
kibana下载后解包 直接使用 由于我们绑定了elasticsearch的IP,所以修改config目录下配置文件kibana.yml 中elasticsearch server 的地址信息后 到bin目录下 nohup ./kibana &
默认端口5601
浏览器输入http://192.168.247.128:5601
由于索引我output plugin设的是hello 所以kibana那边就设默认索引为hello好了
然后看看成果
OK,基本的部署流程就这样的。这个实验我就起了一个elasticsearch,这就是一个节点,如果只有一个的话,elasticsearch的健康度就是***的。elasticsearch一共分红色、***、绿色三种健康度。所以也就是说实际投产的话,至少得起两个elasticsearch,那样健康度才能是绿色。做实验也就无所谓了。elasticsearch中有个配置叫cluster.name。当网络环境一样,多个elasticsearch的cluster.name一样那他们就会加入到同一个集群。这样是很方便的。
三、注意事项
修改MMAP参数,这个官方文档里有明确说明
vi /etc/sysctl.conf
添加vm.max_map_count = 262144
sysctl -p
生效
修改文件描述符
文件描述符如果不调的话,elasticsearch运行一段时间就会报错too many open files同时logstash也会报管道阻塞。所以必须调整
查看现有的情况,可以看到open files 只有1024 这是远远不够的,要调大。
[root@servertest01 bin]# ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 14717 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 14717 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
修改配置 在最后添加两行如下。
[root@servertest01 ~]# more /etc/security/limits.conf # /etc/security/limits.conf # #Each line describes a limit for a user in the form: # #<domain> <type> <item> <value> # #Where: #<domain> can be: # - a user name # - a group name, with @group syntax # - the wildcard *, for default entry # - the wildcard %, can be also used with %group syntax, # for maxlogin limit # #<type> can have the two values: # - "soft" for enforcing the soft limits # - "hard" for enforcing hard limits # #<item> can be one of the following: # - core - limits the core file size (KB) # - data - max data size (KB) # - fsize - maximum filesize (KB) # - memlock - max locked-in-memory address space (KB) # - nofile - max number of open file descriptors # - rss - max resident set size (KB) # - stack - max stack size (KB) # - cpu - max CPU time (MIN) # - nproc - max number of processes # - as - address space limit (KB) # - maxlogins - max number of logins for this user # - maxsyslogins - max number of logins on the system # - priority - the priority to run user process with # - locks - max number of file locks the user can hold # - sigpending - max number of pending signals # - msgqueue - max memory used by POSIX message queues (bytes) # - nice - max nice priority allowed to raise to values: [-20, 19] # - rtprio - max realtime priority # #<domain> <type> <item> <value> # #* soft core 0 #* hard rss 10000 #@student hard nproc 20 #@faculty soft nproc 20 #@faculty hard nproc 50 #ftp hard nproc 0 #@student - maxlogins 4 * soft nofile 65535 * hard nofile 65535 # End of file
重新ssh连上来查看,生效
[root@servertest01 ~]# ulimit -n 65535
四、遇到的一些坑和使用体会
1、发现kibana中的中文日志有乱码。根据检查发现是因为中文有乱码的日志文件是ISO-8859格式文件。如果想要中文没有乱码。日志文件应该是UTF-8格式。这个可以用file命令查看。由于我这里的日志是用log4j生成的。所以生成的日志文件类型可以在log4j中定义,统一起来也不难。配置参考如下
<appender name="FILE" class="org.apache.log4j.DailyRollingFileAppender"> <param name="File" value="./logs/app.log"/> <param name="Encoding" value="UTF-8"/> <param name="DatePattern" value="‘.‘yyyy-MM-dd"/>
这样生成的文件就是UTF-8格式的了
[uat4@localhost logs]$ file app.log app.log: UTF-8 Unicode English text, with very long lines
2.我在一台rhel5.7的服务器上 用rpm包安装了filebeat 。用service filebeat start启动报错
FATAL: kernel too old,
我在官方论坛发现有人用rhel5.10启动topbeat也有这样的报错
而回答是这样
Currently we don‘t support RHEL 5.x as Golang doesn‘t have officially support for it,
但是我发现用 /usr/bin/filebeat -e -c /etc/filebeat/filebeat.yml 是可以使用的。我没研究过源代码,但是用后面的方法是可以用的,所以如果服务器是rhel5.X的话,可以下载filebeat的tar安装包来使用。那样应该是不会有问题的。
3.filebeat如果直接连elasticsearch,首先默认的话它会把所以收集的日志信息都作为一个以beatname命名的索引建立。实际使用时,一个服务器上可能不止跑一个应用,会有多个应用的日志文件,那么在kibana上就会发现所有的日志都合在一起,那这样子是不科学的,这些应该都区分开来。根据官方文档所述,filebeat有个fields参数可以自定义字段。可以把不同的应用日志用字段来区分。然后传到logstash做判断,不同的日志分为不同的索引。那这样可以在kibana上通过不同的索引查看不同应用的日志信息了。
举例说明,我为这两个日志自定义了字段tag,分别值为zabbix和alivelog。就可以将日志分类,最后在elasticsearch生成为两个不同的索引。
filebeat: prospectors: - paths: - "/var/log/zabbix/*.log" fields: tag: zabbix - paths: - "/home/hu/test/alivehost*" fields: tag: alivelog
logstash中output-plugin
output { if [fields][tag] == "zabbix" { elasticsearch { hosts => "192.168.1.123" index => "zabbix-%{+YYYY.MM.dd}" } } if [fields][tag] == "alivelog" { elasticsearch { hosts => "192.168.1.123" index => "alive-%{+YYYY.MM.dd}" } } }
那这样就可以在kibana中区分了
4.将多行日志内容合并为一条日志,实际使用中会有报错日志信息,像java的报错信息就是需要将多行合并为一行的,不然kibana上看到的都是每行独立的一条记录。这个可以使用logstash中codec插件中的multiline。通过multiline写正则表达式匹配多行信息。将codec配置在logstash中的input里,然后写上对应的正则表达式。我从网上参考了java报错日志的正则匹配,如下
codec => multiline { pattern => "(^\s*Caused by.+)|(^.+Exception.+)|(^\s+at .+)|(^\s+... \d+ more)" what => "previous" }
5.分析日志内容,将内容分成不同的字段,这里可以使用filter_plugin中的grok
grok正则匹配日志的话logstash默认自带了一些模板,tomcat的模板也有。该模板可能与实际的情况不符。但是改一下就可以了,在测试环境上我修改了java文件的内容,用于匹配tomcat日志,分为timestamp level class logmessage 这几个字段。这里logstash是用rpm包安装的。
cd /opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-patterns-core-2.0.2/patterns/
可以看到有许多grok的patterns文件,这些就是模板。编辑下java文件修改tomcat的正则表达式。
[root@localhost patterns]# vi java JAVACLASS (?:[a-zA-Z$_][a-zA-Z$_0-9]*\.)*[a-zA-Z$_][a-zA-Z$_0-9]* #Space is an allowed character to match special cases like ‘Native Method‘ or ‘Unknown Source‘ JAVAFILE (?:[A-Za-z0-9_. -]+) #Allow special <init> method JAVAMETHOD (?:(<init>)|[a-zA-Z$_][a-zA-Z$_0-9]*) #Line number is optional in special cases ‘Native method‘ or ‘Unknown source‘ JAVASTACKTRACEPART %{SPACE}at %{JAVACLASS:class}\.%{JAVAMETHOD:method}\(%{JAVAFILE:file}(?::%{NUMBER:line})?\) # Java Logs JAVATHREAD (?:[A-Z]{2}-Processor[\d]+) #JAVACLASS (?:[a-zA-Z0-9-]+\.)+[A-Za-z0-9$]+ JAVACLASS \[(?:[a-zA-Z0-9-]+\.)+[A-Za-z0-9$]+\] -----------实际由中括号括起来 JAVAFILE (?:[A-Za-z0-9_.-]+) JAVASTACKTRACEPART at %{JAVACLASS:class}\.%{WORD:method}\(%{JAVAFILE:file}:%{NUMBER:line}\) JAVALOGMESSAGE (.*) # MMM dd, yyyy HH:mm:ss eg: Jan 9, 2014 7:13:13 AM CATALINA_DATESTAMP %{MONTH} %{MONTHDAY}, 20%{YEAR} %{HOUR}:?%{MINUTE}(?::?%{SECOND}) (?:AM|PM) # yyyy-MM-dd HH:mm:ss,SSS ZZZ eg: 2014-01-09 17:32:25,527 -0800 #TOMCAT_DATESTAMP 20%{YEAR}-%{MONTHNUM}-%{MONTHDAY} %{HOUR}:?%{MINUTE}(?::?%{SECOND}) %{ISO8601_TIMEZONE} TOMCAT_DATESTAMP 20%{YEAR}-%{MONTHNUM}-%{MONTHDAY} %{HOUR}:?%{MINUTE}(?::?%{SECOND})------------将时区去除 CATALINALOG %{CATALINA_DATESTAMP:timestamp} %{JAVACLASS:class} %{JAVALOGMESSAGE:logmessage} # 2014-01-09 20:03:28,269 -0800 | ERROR | com.example.service.ExampleService - something compeletely unexpected happened... #TOMCATLOG %{TOMCAT_DATESTAMP:timestamp} \| %{LOGLEVEL:level} \| %{JAVACLASS:class} - %{JAVALOGMESSAGE:logmessage} TOMCATLOG %{TOMCAT_DATESTAMP:timestamp} %{LOGLEVEL:level} %{JAVACLASS:class} - %{JAVALOGMESSAGE:logmessage} -------实际环境没有竖线所以重新配置TOMCATLOG
在logstash配置文件中添加filter plugin
filter { grok { match => { "message" => "%{TOMCATLOG}" } } }
重启logstash就可以了,这样在kibana中就可以看到处理原始日志内容外,多出了timestamp、level、class、logmessage字段。在做日志检索的时候可以根据字段来做匹配,而不需要全文检索了。logmessage内容比较多,和message字段会有重复。可以把message字段过滤掉。
总结
使用过程中的一个感受是标准规范真的很重要,如果系统开发或运维过程中都是流程化、规范化的话。那么真的会很舒服,反之就会很难受。以前我没有注意过,通过接触学习ELK后发现现有系统上的日志是很不规范的。不同应用的日志里面的模式几乎都是不一样的。那么难道每一个应用我都要写一套grok正则匹配么?那肯定是不行的。所以我决定应该通过更好管理来提高工作的规范标准化。
本文出自 “呵呵呵呵” 博客,请务必保留此出处http://10452483.blog.51cto.com/10442483/1732225
标签:elk elasticsearch logstash kibana
原文地址:http://10452483.blog.51cto.com/10442483/1732225