当你停下来休息的时候,不要忘记,别人还在奔跑~
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 &
网友评论