ELK stack 学习记录

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:
#
#            
#
#Where:
# 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
#
# can have the two values:
#        - "soft" for enforcing the soft limits
#        - "hard" for enforcing hard limits
#
# 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
#
#                 
#

#*               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中定义，统一起来也不难。配置参考如下

这样生成的文件就是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  method
JAVAMETHOD (?:()|[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正则匹配么？那肯定是不行的。所以我这方面应该通过更好管理来提高工作的规范标准化。