ELK stack 学习记录

时间 2020-10-04

标签 html java 正则表达式 redis apache json 浏览器 tomcat ruby bash 栏目 HTML 繁體版

原文原文链接

ELK日志分析平台学习记录html

首先ELK主要指elasticsearch 、logstash 和kibana，三个开源软件组合而成的一套日志平台解决方案。能够将平时收集到的日志，经过前台展现出来，而且能够加以分析，理论上能够解放劳动力（不再用干上生产取日志这种活了——很搓）。java

最近在研究ELKstack日志分析平台，网上相关的中文资料很少。因此呢也就写了这篇文章将本身的一些学习认识总结记录下来，基本偏实战，概念理论较少，概念这块，我想之后能够再开一篇文章来作一个阐述总结。正则表达式

这篇文章中会先讲一下搭建部署的内容，这一部分我在本身电脑上建了两台虚拟机来作这个实验，大体作个入门。同时后面我会记录一下我在实际使用过程当中的一些心得，还有遇到的一些坑，以及解决办法。因为ELK stack这块我也还在学习摸索中，还有诸多不足，若是有什么不正确的地方，请见谅。redis

这里推荐你们能够上官网查看官方文档https://www.elastic.co/guide/index.html写的是很全的。apache

1、架构json

采用官方推荐的架构浏览器

首先官方推出了轻量化数据收集输送应用beat，其中主要的作日志收集的filebeat是新一代做为原来logstash-forwarder的替代品，那因此就使用filebeat了。tomcat

其中beat（如今只使用filebeat）做为 agent端收集日志并发送给logstash，logstash作过滤再给到搜索引擎elasticsearch。最后kibana提供前台界面给用户。ruby

2、安装部署bash

我这里起了两个虚拟机做为安装部署的实例

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同样那他们就会加入到同一个集群。这样是很方便的。

3、注意事项

修改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

4、遇到的一些坑和使用体会

一、发现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正则匹配么？那确定是不行的。因此我这方面应该经过更好管理来提升工做的规范标准化。