从Kids到ELK Stack集中式日志收集之路

elk
日常开发需求中,为了更好排查问题,我们常常需要把多台服务器的日志数据进行集中式收集,一来这样便于集中查看处理日志打印,也更方便我们排查问题,定位问题点。

今天我们主要聊聊如何从Kids到ELK的集中式日志收集方法。

谈谈Kids

首先我们来谈谈Kids是什么?Kids是知乎14年开源的日志收集系统,采用Scribe的消息聚合模型和Redis的pub/sub模型。特点:无第三方依赖,实时订阅,使用Redis协议等。

因为上面这些原因,团队在一开始就把Kids作为主要的集中式日志收集管理平台。

下面是主要的配置步骤:

  1. 用docker进行安装(也可以源码安装)客户端及服务端
  2. 在客户端应用App代码配置logging handler,配置好对应的应用的日志level,topic。(通过topic配置可以把应用日志各种状态都分类收集起来)
  3. 应用App的logging日志打印到kids服务端得到日志文件,实现统一收集

kids 架构图
上图来自官方架构图,更多参考:

https://github.com/zhihu/kids/blob/master/README.zh_CN.md

最后上一张日志效果图,其中日志的压缩是运行了自动化shell加密脚本与kids本身无关。
kids效果图


使用ELK+Filebeat收集日志

通过kids配置使用,就能把各个应用日志统一进行收集分析了,但是随着需求越来越多,对日志要求也越来越高,需要各种类型日志来源,需要可视化,需要集中挖掘各个日志数据信息,比如数据库慢查询日志,nginx请求日志,错误日志。这个时候轻量级的Kids系统就有些力不从心了。

这个时候就需要用到ELK+Filebeat这种重量级装备了。

ELK是一个软件集合,由Elasticsearch(简称ES 负责存储搜索聚合),Logstash(数据收集过滤), Kibana(数据分析及可视化)三款开源软件组成,现在已成为目前最为流行的日志解决方案。

而Filebeat是ELK 家族新成员Beats下面分支,一个更轻量级的日志文件收集器,用来替换Logstash,通过Filebeat收集数据更加节约服务器资源。

Filebeat主要场景是在需要采集日志的服务器上面安装服务,指定好对应的日志文件,读取文件数据发送到Logstash解析或者发送到ES,Redis进行存储。

elk
上图是整个日志的流转过程,首先通过从各个服务器收集到的数据发送到logstash集中处理,存储到ES,最后再通过Kibana进行数据展示,生成图表。

知道整个数据流转情况,下面简要讲下Filebeat及Logstash下安装配置过程:

安装配置步骤如下:

  1. 使用docker安装指定版本的镜像
  2. 配置对应的配置命令挂载指定的路径
  3. 使用docker-compose up -d 启动管理容器
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
# docker-compose.yml
version: '2'
services:
logstash:
image: docker.elastic.co/logstash/logstash:5.6.10
hostname: logstash
container_name: logstash
restart: always
ports:
- "5044:5044"
volumes:
- ./logstash.conf:/usr/share/logstash/pipeline/logstash.conf
filebeat:
image: docker.elastic.co/beats/filebeat:5.6.10
hostname: filebeat
container_name: filebeat
command: filebeat -e -strict.perms=false # 其中strict.perms=false 表示filebeat忽略权限
restart: always
volumes:
- ./settings/filebeat.yml:/usr/share/filebeat/filebeat.yml
- ./yourselfdir:/usr/share/filebeat/yourselfdir
# 下面是filebeat.yml配置
filebeat.prospectors:
- input_type: log
paths:
- /usr/share/filebeat/yourselfdir/*/*.log
#document_type: 'test1' # 在5.X版本用document_type区分不同日志来源6.0被废弃,使用fields
#fields: # 这里是在6.0版本使用 fields来自定义进行区分来源
#type: test1
#fields_under_root:true #如果自定义字段和原有字段重名,是否覆盖原有字段
#output.elasticsearch:
# hosts: ['xx':9200']
output.logstash:
hosts: ["xx:5044"]
#tail_files: true 默认为false从文件末尾开始读取而不是开始,适用大文件日志读取
-------------
# 下面是 logstash.yml配置
input {
beats {
port => 5044
codec => "json"
add_field => {"myid"=>"nginx"} # 通过logstash特定端口add_field也能区分不同日志来源,相对来说不够优雅
}
}
filter {
if [myid] == "nginx" {
grok {
match => ["message", "%{HTTPDATE:logdate}"]
}
}
date {
match => ["@timestamp", "yyyy-MM-dd HH:mm:ss"]
}
}
output {
if [myid] == "nginx" {
elasticsearch {
hosts => "XX:9200"
manage_template => false
index => "nginx-log-%{+YYYY.MM.dd}"
document_type => "nginx-log"
}
}
}

其中注意的是:ducument_type参数已经在5.5版本建议丢弃,6.0中彻底废弃,使用fields代替,通过fields_under_root属性,替换原始type属性,上面演示了其实通过logstash端口号也能区分不同日志来源。

由于笔者已经装好ES及Kibana,这里就简单罗列了基本日志配置文件(实际生产环境较为复杂),需要注意事项较多,尤其是安全相关认证,数据加密等这些都是重点需要关注的。

通过把不同来源的数据日志进行集中整合及可视化操作,让我们对我们的应用服务了解的更为透彻。


写在后面

开发技术都是在不断变化迭代的,Kids简单方便但功能较单一,ELK复杂臃肿但是功能强大,每个时间点都有适合自己的技术,不是越时髦越好,而是最适合团队业务场景和技术水平。

由于篇幅有限,大家如果有问题可以微信留言或者加我微信pengtaotalk,大家一起探讨。

本文首发微信公众号, 欢迎订阅

sitin wechat
扫一扫上面的二维码,订阅我的博客!