日常开发需求中，为了更好排查问题，我们常常需要把多台服务器的日志数据进行集中式收集，一来这样便于集中查看处理日志打印，也更方便我们排查问题，定位问题点。
今天我们主要聊聊如何从Kids到ELK的集中式日志收集方法。
谈谈Kids
首先我们来谈谈Kids是什么？Kids是知乎14年开源的日志收集系统，采用Scribe的消息聚合模型和Redis的pub/sub模型。特点：无第三方依赖，实时订阅，使用Redis协议等。
因为上面这些原因，团队在一开始就把Kids作为主要的集中式日志收集管理平台。
下面是主要的配置步骤：
- 用docker进行安装（也可以源码安装）客户端及服务端
- 在客户端应用App代码配置logging handler，配置好对应的应用的日志level，topic。(通过topic配置可以把应用日志各种状态都分类收集起来)
- 应用App的logging日志打印到kids服务端得到日志文件，实现统一收集
上图来自官方架构图，更多参考：
https://github.com/zhihu/kids/blob/master/README.zh_CN.md
最后上一张日志效果图，其中日志的压缩是运行了自动化shell加密脚本与kids本身无关。
使用ELK+Filebeat收集日志
通过kids配置使用，就能把各个应用日志统一进行收集分析了，但是随着需求越来越多，对日志要求也越来越高，需要各种类型日志来源，需要可视化，需要集中挖掘各个日志数据信息，比如数据库慢查询日志，nginx请求日志，错误日志。这个时候轻量级的Kids系统就有些力不从心了。
这个时候就需要用到ELK+Filebeat这种重量级装备了。
ELK是一个软件集合，由Elasticsearch(简称ES 负责存储搜索聚合)，Logstash（数据收集过滤）， Kibana（数据分析及可视化）三款开源软件组成，现在已成为目前最为流行的日志解决方案。
而Filebeat是ELK 家族新成员Beats下面分支，一个更轻量级的日志文件收集器，用来替换Logstash，通过Filebeat收集数据更加节约服务器资源。
Filebeat主要场景是在需要采集日志的服务器上面安装服务，指定好对应的日志文件，读取文件数据发送到Logstash解析或者发送到ES，Redis进行存储。
上图是整个日志的流转过程，首先通过从各个服务器收集到的数据发送到logstash集中处理，存储到ES，最后再通过Kibana进行数据展示，生成图表。
知道整个数据流转情况，下面简要讲下Filebeat及Logstash下安装配置过程：
- 安装配置步骤如下：
- 使用docker安装指定版本的镜像
- 配置对应的配置命令挂载指定的路径
- 使用docker-compose up -d 启动管理容器
# 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，大家一起探讨。
