开源实时日志分析ELK平台部署【入门篇】

面临的问题
通常,日志被分散的储存不同的设备上。如果你管理数十上百台服务器,你还在使用依次登录每台机器的传统方法查阅日志。这样是不是感觉很繁琐和效率低下。当务之急我们使用集中化的日志管理,例如:开源的syslog,将所有服务器上的日志收集汇总

集中化管理日志后,日志的统计和检索又成为一件比较麻烦的事情,一般我们使用grep、awk和wc等Linux命令能实现检索和统计,但是对于要求更高的查询、排序和统计等要求和庞大的机器数量依然使用这样的方法难免有点力不从心


ELK介绍
  1. Elasticsearch是个开源分布式搜索引擎,它的特点有:分布式,零配置,自动发现,索引自动分片,索引副本机制,restful风格接口,多数据源,自动搜索负载等。
  2. Logstash是一个完全开源的工具,他可以对你的日志进行收集、过滤,并将其存储供以后使用(如,搜索)。
  3. Kibana 也是一个开源和免费的工具,它Kibana可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面,可以帮助您汇总、分析和搜索重要数据日志
下载
logStash-5.4.2

kibana-5.4.2

elasticsearch-5.4.0

解压

修改相关配置
直接启动logstash

报错:ERROR: No configuration file was specified. Perhaps you forgot to provide the '-f yourlogstash.conf' flag?
从这个错误中,可以看出我们需要创建一个logstash的配置文件
那么如何编写配置文件呢?
logstash中文文档
在终端中,像下面这样运行命令来启动 Logstash 进程:
# bin/logstash -e 'input{stdin{}}output{stdout{codec=>rubydebug}}'

到这里的时候,logstash基本可以认为已经安装成功了
那么我们如何去编写它的配置呢?
若想编写配置,首先我们需要了解一下它的语法
Logstash 设计了自己的 DSL—— 有点像 Puppet 的 DSL,或许因为都是用 Ruby 语言写的吧 —包括有区域,注释,数据类型(布尔值,字符串,数值,数组,哈希),条件判断字段引用等。
字段引用
如果你想在 Logstash 配置中使用字段的值,只需要把字段的名字写在中括号 [] 里就行了,这就叫字段引用。
条件判断
if"_grokparsefailure" not in [tags] {
# 1
}else if [status]!~ /^2\d\d/or ( [url]== "/noc.gif"nand[geoip][city]!= "beijing") {
# 2
}else {
# 3
}
Logstash 提供了一个 shell 脚本叫 logstash 方便快速运行。它支持以下参数:
-e
意即执行。我们在 "Hello World" 的时候已经用过这个参数了。事实上你可以不写任何具体配置,直接运行 bin/logstash -e '' 达到相同效果。这个参数的默认值是下面这样:
input {
stdin { }
}
output {
stdout { }
}
--config 或 -f
意即文件。真实运用中,我们会写很长的配置,甚至可能超过 shell 所能支持的 1024 个字符长度。所以我们必把配置固化到文件里,然后通过 bin/logstash -f agent.conf这样的形式来运行。
此外,logstash 还提供一个方便我们规划和书写配置的小功能。你可以直接用 bin/logstash -f /etc/logstash.d/ 来运行。logstash 会自动读取 /etc/logstash.d/ 目录下所有 *.conf 的文本文件,然后在自己内存里拼接成一个完整的大配置文件,再去执行。
注意:
logstash 列出目录下所有文件时,是字母排序的。而 logstash 配置段的 filter 和 output 都是顺序执行,所以顺序非常重要。采用多文件管理的用户,推荐采用数字编号方式命名配置文件,同时在配置中,严谨采用 if 判断限定不同日志的动作。
另外还有一些参数:
  • --configtest -t
意即测试。用来测试 Logstash 读取到的配置文件语法是否能正常解析。Logstash 配置语法是用 grammar.treetop 定义的。尤其是使用了上一条提到的读取目录方式的读者,尤其要提前测试。
  • --log-l
意即日志。Logstash 默认输出日志到标准错误。生产环境下你可以通过 bin/logstash -l logs/logstash.log 命令来统一存储日志。
  • --pipeline-workers 或 -w
运行 filter 和 output 的 pipeline 线程数量。默认是 CPU 核数。
  • --pipeline-batch-size 或 -b
每个 Logstash pipeline 线程,在执行具体的 filter 和 output 函数之前,最多能累积的日志条数。默认是 125 条。越大性能越好,同样也会消耗越多的 JVM 内存。
  • --pipeline-batch-delay 或 -u
每个 Logstash pipeline 线程,在打包批量日志的时候,最多等待几毫秒。默认是 5 ms。
  • --pluginpath 或 -P
可以写自己的插件,然后用 bin/logstash --pluginpath /path/to/own/plugins 加载它们。
  • --verbose
输出一定的调试日志。
  • --debug
输出更多的调试日志。
第一步:编写简单的配置·1
input {
   stdin {
  }
}
output {
    stdout {
        codec => rubydebug
    }
}
配置·2
input {
stdin {
add_field => {"key" => "value"}
codec => "plain"
tags => ["add"]
type => "std"
}
}
output {
stdout {
codec => rubydebug
}
}
配置·3
input {
file {
path => ["/usr/ELK/log/message.log"]
type => "system"
}
}

output {
stdout {
codec => rubydebug
}
}
启动logstash
bin/logstash -f ./config/logstash.test.conf
然后打开一个窗口,我们向message.log日志中输入一条信息

到目前为止logstash已经简单的实现对日志文件的监控,一旦内容有更改,会立即捕捉到更改的内容。
接下来,看一下 elasticsearch
进入到elasticsearch目录中,直接启动 bin/elasticsearch

报错:
原因是什么?
通过这个报错日志,看来是不能用root用户启动了,网上查阅资料说加上
-Des.insecure.allow.root=true
试一下:bin/elasticsearch -Des.insecure.allow.root=true

好吧,再查查吧

简直是坑~~~~~~~
原来这是出于系统安全考虑设置的条件。由于ElasticSearch可以接收用户输入的脚本并且执行,为了系统安全考虑,建议创建一个单独的用户用来运行ElasticSearch。
切换当前用户到www用户 更改文件所属组,再次启动

启动成功了!!!!!!!
那么我们如何来验证是否安装成功了呢?
curl localhost:9200

成功返回了elasticsearch信息,说明已经安装成功了,那么我们如何在浏览器中访问呢?
修改配置文件
network.host:101.200.189.125
再次启动,发生一个问题,启动到一半直接显示已杀死,这是什么鬼?

苦苦寻找原因中.....
后来看了一下,当我启动elasticsearch的时候,cpu直接干超了!!超了!!!

哪里出了问题,如此的耗cpu呢?
在启动时,报错
Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000080000000, 348913664, 0) failed; error='Cannot allocate memory' (errno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 348913664 bytes for committing reserved memory.
# An error report file with more information is saved as:
# /usr/ELK/elasticsearch-5.4.0/hs_err_pid29773.log

打开日志,查看发现是jvm崩溃,导致启动失败,那么为什么jvm会崩溃呢?

查看一下jvm配置文件

发现在配置文件内,配置的内存是2G,由于测试机内存较小,无法分配出2G的内存空间,导致jvm崩溃。
解决办法:将内存值调小后,重启服务,发现还是报错!!!!!!
ERROR: bootstrap checks failed
system call filters failed to install; check the logs and fix your configuration or disable system call filters at your own risk

问题原因:因为Centos6不支持SecComp,而ES5.2.1默认bootstrap.system_call_filter为true进行检测,所以导致检测失败,失败后直接导致ES不能启动。详见 :https://github.com/elastic/elasticsearch/issues/22899
解决方法:在elasticsearch.yml中配置bootstrap.system_call_filter为false,注意要在Memory下面:
bootstrap.memory_lock: false
bootstrap.system_call_filter: false
修改后,重启服务

正常启动
然后我们用curl 访问一下,检测一下是否启动成功 101.200.189.125:9200

浏览器访问,正常返回

基本安装成功了~~~~~
接下来,我们安装kibana
kibana-5.4.2

进入kibana目录,打开配置文件,修改
server.host =
elasticsearch.url =
重启后

提示版本不对应
先不管,我们访问以下看看 http://101.200.189.125:5601

第一步:创建索引

1.安装好kibana平台 确保kibana以及elasticsearch正常运行
2.打开kibana平台在Dev Tools
3.创建一个customer索引
PUT /customer?pretty
4.查看该索引
GET /_cat/indices?v
看到结果
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open customer 95SQ4TSUT7mWBT7VNHH67A 5 1 0 0 260b 260b
则说明创建成功

现在基本上单个工具都已经基本完成了,那么现在的问题是,如何将日志的内容发送到elasticsearch中,然后通过kibanna展示出来呢?

这个时候就需要修改logstash的配置了

然后我们向日志文件写入日志记录

写入日志后,回到logstash看一下

这个时候我们刷新kibana界面看一下日志是否上传成功了

plugin的安装
命令 bin/logstash-plugin list 查看当前本机的可用插件
安装 bin/logstash-plugin install 插件名称 运行安装插件
升级 bin/logstash-plugin update 插件名称 升级已安装的插件

阅读更多
版权声明:以下内容来自参考前辈资料以及个人的一些心得 https://blog.csdn.net/bk_guo/article/details/73613448
个人分类: Linux 运维篇
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭