微服务可观测平台(三)-metrics测量组件设计与实现
背景
增强服务可观测性，预测与发现系统性能瓶颈，透视系统状态，为系统调优和改进提供可靠数据
规划特性
服务日志: 记录时间，用户，用户地点(ip)，服务节点(ip)，服务名称，模块名称，参数(可配置)，支持异步写入，减少服务正常执行影响
服务性能指标，RT，请求数(1m/5m/15m)，异常数(1m/5m/15m)，失败数(1m/5m/15m)
服务调用链路，服务调用拓扑，调用关系性能，topN(最忙服务，最慢服务)
业务日志，如，拉单每秒字节数，数据笔数，拉单作业数
监控门户，仪表盘，告警 Prometheus+grafana(运维)；elasticsearch agg+数据可视化(开发)
*日志收集ELK不在本次计划
*系统监控，如cpu，线程数(jvm)，内存(jvm)，磁盘io，网络io 直接使用Prometheus，不在本平台范
技术架构
测量组件位于可观测架构蓝框部分，负责业务测量/性能测量的构建， 采集，转换和报告
测量组件
测量组件是可观测平台的第三部分，由metrics，exporter，reporter 3部分组成
metrics 测量构建/收集/计算组件，业界metrics组件选择比较少，主要有dropwizard-metrics，micrometer也是源于dropwizard-metrics，还有些框架自带metrics组件，基本上也是参考dropwizard-metrics
测量exporter/测量reporter，两者是配套，exporter 转换本地测量类型为监控平台类型；reporter 推送转换后的测量到监控平台，本组件实现Prometheus测量转换和报告
设计模型
本组件的设计
Counter/Gauge/Meter/Summary/Histogram dropwizard-metrics支持的测量类型，其中后3者属于统计量，分布式系统统计单节点意义不大；另外，Prometheus Counter/Gauge都是数值，Gauge客家可减，Counter单调增加
ScheduledReporter/DefaultScheduledReporter ScheduledReporter是dropwizard-metric提供的Reporter实现，定时报告测量，抽象模板模式，DefaultScheduledReporter本组件实现，DropWizardPrometheusExporter转换测量为Prometheus类型，simple-pushgateway推送到Prometheus
TagExtractor tag是Prometheus测量的属性，定义数据维度，对后续的统计非常重要；TagExtractor是本组件接口，应用实现自己的tag生成逻辑
MetricHolder 本组件的开发，负责全局构建，操作，持有测量
开发指南
1. 依赖
<dependency>
<groupId>io.dropwizard.metrics</groupId>
<artifactId>metrics-core</artifactId>
</dependency>
2. 配置
以java config为例，以下内容在代码单元测试TesstMetricsReporterConfiguration
示例：
metrics:
reporter:
type: prometheus # metrics报告类型 nop/console/prometheus
url: ip:port # Prometheus pushgateway地址
job: apiflow # Prometheus job标签
interval: 10 # 报告间隔，单位秒
1）报告期采集间隔
Value("${flowsharping.metrics.reporter.interval:30}")
private int reprotInterval;
2) 测量注册，全局
public static final MetricRegistry metricsReg = new MetricRegistry();
3) 报告器声明和初始化
声明3个报告器，通过conditional激活，nop相当于屏蔽报告，console reporter
测量输出到控制台，单机测试用；DefaultSchedulerReporter 输出到Prometheus，支持分布式聚合统计，DemoTagExtractorImpl简单的标签提取实现，增加type和instant标签，
其中type pass/fail，instant host:ip，用于示例
4) MetricHolder
5) 环境工具
获取当前ip和端口
示例
场景1：单机测试
本示例在单元测试TestQpsMetrics，模拟api调用qps测量，使用ConsoleReporter，报告间隔10秒，示例使用随机数模拟调用的通过和不通过，分别计数到pass计数器和fail计数器
控制台输出
场景2：分布式测试
本示例在单元测试TestQpsMetricsCluster1，TestQpsMetricsCluster2，模拟两个服务集群调用qps测量，服务测试代码同场景1，使用PrometheusReporter，报告间隔10秒，tag提取器增加type，instant标签，type标签pass，fail，通过和不同的qps技术，instant ip+port，测量输出如下图：
上面2个图标，服务8091和8092的通过请求数速率，不通过数速率，总请求数速率
下面是两个服务通过总请求数，不通过的总请求数，两个服务的总请求
promsql：
rate(apixxx{exported_job="apiflow", instant="host:port", type="pass|fail"}[1m])
sum(rate(apixxx {exported_job="apiflow", instant="host:port", type="pass|fail"}[1m]))
