当你停下来休息的时候,不要忘记,别人还在奔跑~
1 先说遇到的问题
1.1 场景1
用户服务与订单服务部署在同一机子不同目录，一次下单流程设计用户服务与订单服务，但下单过程抛异常，为了定位异常（哪个服务产生的？具体代码行数？），要分别打开用户服务所在目录，查看各自的日志文件，然后定位问题。
1.2 场景2
由于业务压力，订单服务有多个实例，分别部署在多个不同服务器上，一次下单流程失败，确定由订单服务引起，为了定位异常，需要查看日志，但是由于负载均衡，无法确定该异常是哪台服务器打印的，因此只能逐一登录服务器，进行一一查看。
1.3 综述
场景1和场景2是分布式应用在日志采集上遇到的普遍问题，因为应用的分散，日志也被分散在不同服务器的不同目录上，这给开发定位问题带来了极大的不便。
2 解决方案
2.1 手动查看
逐一登录服务器，然后执行命名监听日志文件，该方案费时费力，效率较为低下。
- tail/cat -f xxxx.log
2.2 写数据库
需在主业务库外新建一套辅库，写入日志文件，日志写入可有以下几种方式，该方案侵入性较强，大量的日志输出日志库，日志库可能存在瓶颈，从而影响到业务。
- 代码或aop写入日志（不推荐，侵入性强）；
- 日志框架配置输出到数据库（同样存在侵入性，当日志库挂掉，服务无法正常启动）。
2.3 elk
elk由elasticsearch、logstash和kibana三部分的组件，在官网上即可下载，安装过程不在赘述。
-
Logstash部署到每个节点，收集相关的日志，并经过分析过滤后发送到Elasticsearch进行存储，Elasticsearch将数据以分片的形式压缩存储，通过kibana对日志进行图形化的展示。
该方案的优点是，架构搭建简单，容易上手且是业界成熟的方案，性能高，方便后续的日志统一分析和查询。缺点是，每个节点部署logstash，运行时占用CUP、内存大，会对节点性能造成一定的影响；没有将日志数据进行缓存，存在丢失的风险。
ELK收集日志流程
2.4 elk+filebeat
Filebeat是一个日志文件托运工具，做为一个agent安装到服务器上，filebeat会监控日志目录或者指定的日志文件，追踪读取这些文件；
将filebeat 作为日志收集器，相比logstach，filebeat更轻量，占用资源更少，filebeat采集日志后，发送到消息队列kafaka或redis暂存起来，起到一个缓冲池的作用，能缓解日志峰值处理压力；
然后logstash去消息队列中获取，利用filter功能过滤分析，然后存储到elasticsearch中，再通过kibana图形化直观展示。
-
该方案的优点是，弥补了单elk的性能以及日志丢失问题；缺点就是部署较复杂，如果是正式环境还要考虑集群部署，避免单点。
elk+filebeat
3. 环境搭建（可参考别的帖子，不赘述。。。。）
本次搭建的elk版本统一为6.5.4版本。
基本都是开箱即用，简单说下配置，亲测可用。
elasticsearch：
cluster.name: elasticsearch
#这是集群名字，我们 起名为 elasticsearch
#es启动后会将具有相同集群名字的节点放到一个集群下。
node.name: es-node1
#节点名字。
transport.tcp.port: 9300
http.port: 9200
discovery.zen.minimum_master_nodes: 1
#指定集群中的节点中有几个有master资格的节点。
#对于大集群可以写3个以上。
discovery.zen.ping_timeout: 40s
#默认是3s，这是设置集群中自动发现其它节点时ping连接超时时间，
#为避免因为网络差而导致启动报错，我设成了40s。
#discovery.zen.ping.multicast.enabled: false
#设置是否打开多播发现节点，默认是true。
#network.bind_host: 192.168.0.120
#设置绑定的ip地址，这是我的master虚拟机的IP。
#network.publish_host: 192.168.0.120
#设置其它节点和该节点交互的ip地址。
network.host: 192.168.0.120
#同时设置bind_host和publish_host上面两个参数。
#discovery.zen.ping.unicast.hosts: ["192.168.0.120"]
#discovery.zen.ping.unicast.hosts:["节点1的 ip","节点2的ip"]
#指明集群中其它可能为master的节点ip,
#以防es启动后发现不了集群中的其他节点。
#第一对引号里是node1，默认端口是9300,
#第二个引号里是node2，因为它和node1在一台机器上，所以指定了9301端口。
#
path.data: /home/es1/data
path.logs: /home/es1/logs
http.cors.enabled: true
#是否支持跨域，默认为false
http.cors.allow-origin: "*"
##当设置允许跨域，默认为*,表示支持所有域名，如果我们只是允许某些网站能访问，那么可以使用正则表达式。比如只允许本地地址。 /https?:\/\/localhost(:[0-9]+)?/
##http.cors.allow-headers: Authorization,X-Requested-With,Content-Length,Content-Type
#bootstrap.system_call_filter: false
logstash:
input {
beats {
host => "192.168.0.120"
port => 5044
}
}
#过滤
filter {
ruby {
code => "event.timestamp.time.localtime"
}
#logback日志过滤
if "erp_error_log" in [tags] {
grok {
match => {"message" => "%{DATA:timestamp} %{LOGLEVEL:level} \[%{DATA:class} :%{INT:line}\] %{DATA:log_message}" }
}
date {
match => [ "timestamp", "MMM d HH:mm:ss" ]
}
}
}
output{
if "erp_error_log" in [tags]{
elasticsearch{
hosts => ["192.168.0.120:9200"]
index => "erp_error_log"
}
}
}
filebeat:
# 输入源
filebeat.prospectors:
- type: log
enabled: true
#日志路径
paths:
- /home/erp/order/logs/*.log #路径
#日志tags
tags: ["erp_error_log"] #日志类型，类似标签，logstash可以按照标签创建不同索引
#排除空行
exclude_lines: ['^$']
#java多行日志合并
multiline:
pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
negate: true # 正则是否开启，默认false不开启
match: after # 不匹配的正则的行是放在上面一行的前面还是后面
filebeat.config.modules:
path: ${path.config}/modules.d/*.yml
reload.enabled: false
setup.template.settings:
index.number_of_shards: 3
setup.kibana:
#输出至logstash
output.logstash:
hosts: ["192.168.0.120:5044"]
kibana:
server.port: 5601
server.host: "0.0.0.0"
elasticsearch.url: "http://192.168.0.120:9200"
启动顺序
其实没有特别的顺序，一般的启动顺序是elasticsearch->logsatsh->kibana->filebeat。其实差别都不大，特别注意一个就是，如果你想要测试的话，logstash支持配置自动更新，如果是日志文件更新，想让filebeat重新再搜索一次，删除掉filebeat根目录下data/registry文件。其实类推，如果要删除其它的软件(elk)的的数据，删掉data目录,很直接很暴力，但不建议在正式场景直接这样弄。
- 启动es:
./bin/elasticsearch
- 启动logstash：
测试conf文件是否正确配置
./bin/logstash -f logstash.conf --config.test_and_exit
启动logstash，如果有修改conf会自动加载
./bin/logstash -f logstash.conf --config.reload.automatic
- 启动kibana：
./bin/kibana
- 启动filebeat:
nohup ./filebeat -e -c filebeat.yml > filebeat.log &