性能监控之JMeter分布式压测轻量日志解决方案
在前文中我们已经介绍了使用JMeter非GUI模式进行压测的时候，我们可以使用 InfluxDB+Grafana进行实时性能测试结果监控，也可以用 Tegraf+InfluxDB+Grafana进行实现服务器性能监控。尽管Grafana看板可以显示事务执行的请求数和失败率。但是我们也想知道它失败的原因。
并不是所有的HTTP请求失败都是500引起的，有时候也可能是200，响应断言只是检查响应数据是否存在给定的字符串，如果不满足那么就是请求失败。但是这段时间我们实际的响应数据是什么？要知道在性能测试期间调试应用可是非常重要的。 我们经常使用阿里云或者物理机集群来压测，即使我们将响应数据记录在日志里面，我们也可能无法立即获取数据。我们只能等待压测结束去ssh/ftp访问主机去检查日志。我们不能像性能测试结果一样使用InfluxDB收集这些大量的非结构文本数据。因为InfluxDB作为时序数据库并不是为检索文本设计的。
其中一个简单的轻量日志解决方案就是使用 ElasticSearch+FileBeats+Kibana去收集分析错误响应数据。
背景
Filebeat
Filebeat是ELK协议栈的新成员，一个亲量级开源日志文件数据搜集器，用GO语言实现。 Filebeat安装在服务器上做为代理监视日志目录或者特定的日志文件，要么将日志转发到Logstash进行解析，要么直接发送到ElasticSearch进行索引。 Filebeat文档完善，配置简单，天然支持ELK，为Apache,Nginx,System,MySQL等服务产生的日志提供默认配置，采集，分析和展示一条龙。
如下所示，Filebeat的配置简单易懂
filebeat:
spool_size: 1024 # 最大可以攒够 1024 条数据一起发送出去
idle_timeout: "5s" # 否则每 5 秒钟也得发送一次
registry_file: "registry" # 文件读取位置记录文件，会放在当前工作目录下。
config_dir: "path/to/configs/contains/many/yaml" # 如果配置过长，可以通过目录加载方式拆分配置
prospectors: # 有相同配置参数的可以归类为一个 prospector
-
fields:
log_source: "sample" # 类似logstash的 add_fields，此处的"log_source"用来标识该日志来源于哪个项目
paths:
- /var/log/system.log # 指明读取文件的位置
- /var/log/wifi.log
include_lines: ["^ERR", "^WARN"] # 只发送包含这些字样的日志
exclude_lines: ["^OK"] # 不发送包含这些字样的日志
-
document_type: "apache" # 定义写入ES时的 _type 值
ignore_older: "24h" # 超过24小时没更新内容的文件不再监听。
scan_frequency: "10s" # 每10秒钟扫描一次目录，更新通配符匹配上的文件列表
tail_files: false # 是否从文件末尾开始读取
harvester_buffer_size: 16384 # 实际读取文件时，每次读取16384字节
backoff: "1s" # 每1秒检测一次文件是否有新的一行内容需要读取
paths:
- "/var/log/apache/*" # 可以使用通配符
exclude_files: ["/var/log/apache/error.log"]
-
input_type: "stdin" # 除了 "log"，还有 "stdin"
multiline: # 多行合并
pattern: '^[[:space:]]'
negate: false
match: after
output.elasticsearch:
hosts: ["127.0.0.1:9200"] # The elasticsearch hostsFilebeat 发送的日志，会包含以下字段：
beat.hostname beat运行的主机名beat.name shipper配置段设置的name，如果没设置，等于beat.hostname@timestamp读取到该行内容的时间- type 通过
document_type设定的内容 - input_type 来自"log"还是"stdin"
- source 具体的文件名全路径
- offset 该行日志的起始偏移量
- message 日志内容
- fields 添加的其他固定字段都存在这个对象里面
Elasticsearch
Elasticsearch是一个开源的高扩展的分布式全文检索引擎，它可以近乎实时的存储、检索数据；本身扩展性很好，可以扩展到上百台服务器。Elasticsearch强在全文搜索，InfluxDB擅长时序数据，所以还是具体需求具体分析。如果需要保存日志并经常查询的，Elasticsearch比较合适,比如我们的JMeter log。如果只依赖日志做状态展示，偶尔查询，InfluxDB比较合适。
Kibana
Kibana 是一个开源的分析和可视化平台，旨在与 Elasticsearch 合作。Kibana 提供搜索、查看和与存储在 Elasticsearch 索引中的数据进行交互的功能。用户可以轻松地执行高级数据分析，并在各种图表、表格和地图中可视化数据。Fibana在图表展示上没有Grafana美观，但Kibana从Elasticsearch中检索日志非常方便。
整体架构
日志采集架构
安装及配置
下载及配置ElasticSearch
可以直接参考官网的教程，此处就不重复造轮子了
官网教程地址：https://www.elastic.co/downloads/elasticsearch
安装完成后，确认可以通过 使用 http://elasticsearch-host-ip:9200访问elastic search
下载及配置Kibana
参考官网教程： https://www.elastic.co/downloads/kibana
更新 config/kibana.yml配置文件以获取elasticsearch数据 运行 kibana.bat/.sh 确保可以使用 http://kibana-host-ip：5601访问kibana主页
下载及配置FileBeat
参考官网教程 https://www.elastic.co/downloads/beats/filebeat
我们需要为每个压力机部署一个FileBeat节点，FileBeat主要负责收集日志数据，并发送给elasticsearch存储。
更新filebeat.yml文件
filebeat.inputs:
- type: log
enabled: true
paths:
- D:\BaiduNetdiskDownload\jmeter\apache-jmeter-4.0\bin\jmeter.log
multiline.pattern: ^[0-9]{4}-[0-9]{2}-[0-9]{2}
multiline.negate: true
multiline.match: after
output.elasticsearch:
hosts: ["127.0.0.1:9200"]默认情况下，FileBeat将日志文件中的每一行记录为单独的日志条目。有时JMeter异常可能跨越多行。所以我们需要使用多行模式配置filebeat.yml。
JMeter.log每个日志条目都带有其时间戳（yyyy-MM-dd）。所以，我们可以将模式配置为从时间戳开始截取，如果没有时间戳，FileBeat可以根据配置将该行附加到上一行。
启动FileBeat后将开始监视日志文件，每当更新日志文件时，数据将被发送到ElasticSearch存储。
JMeter日志采集
我们创建了一个非常简单的测试，如下所示，只有有Debug Sampler，使用BeanShell Assertion监听在发生任何错误时在日志文件中写入返回数据。
压测开始后，FileBeat将开始收集从日志文件中的信息，并转发到ElasticSearch存储，我们可以通过Kibana检索详细日志。
如果我们点击小箭头展开细节，下面的消息部分将显示我们感兴趣的日志详细内容。
小结
除了实时性能测试结果和实时性能数据外，我们还能够实时收集失败请求的响应数据。当我们在长时间运行的分布式负载测试时，上述设置非常有用。当请求事务突然失败时，此设置可帮助我们检查响应数据以便了解应用的情况和测试工具行为。
本文只抛砖引玉，大家有兴趣的话，可以参照教程深入实践。
相关系列：
性能监控之Telegraf+InfluxDB+Grafana服务器实时监控
腾讯云开发者
