对metric方案的选择：
- 功能性角度：
单纯衡量metric方案，大多已经满足基本功能，但是除此之外，更需要考虑功能的完整性：
（1） 是否支持硬件层次（CPU、Memory、Disk、Network等）的数据收集和展示；（2） 是否对常见服务有更轻便的支持。
市场上流行的服务都比较集中，例如数据库有oracle、mysql，缓存有memcached、redis等，服务器容器有tomcat，jetty等，消息中间件有rabbitmq、kafka。所以很多metric系统除了通用方案外，还额外对这些常见服务有更轻便的直接接入支持。
（3） 是否集成Alert功能
Metrics里面含有的数据越丰富可以做的事情也越多：
a. 根据主机metric，判断主机故障，例如磁盘是否快满了；
b. 根据错误信息判断是否当前存在故障；
c. 根据metric趋势，判断是否需要扩容；
d. 根据用户行为信息判断是否存在恶意攻击，
当判断出这些信息，仅仅展示是不够的，更应该是提供预警和报警功能，以立马能够解决。同时报警的通知方式是否多样化（邮件、电话、短信、其他及时通信系统的集成）或者进行了分级（轻重缓解不同，不同方式）。
有了更丰富的功能，则避免多种方案的东拼西凑，有利于一体化。
- 扩展性角度：
（1） 容量是否具有可扩容性：
当数据量小时，传统的Sql数据库甚至excel、csv都能存储所有的历史metric数据，并能满足查询等需求，但是除非可预见业务量永不会有突破，否则初始调研时，就应该考虑容量可扩展的方案。例如influxdb单机版是免费的，但是想使用集群模式的时候就变成了收费模式。所以在不喜欢额外投资，只热衷开源方案的企业，长远计划时则不需要选择这类产品。
（2） 切换新方案或者新增多层方案时，方案的可移植性：
很少有一种metric系统能满足所有需求，特别是定制化需求比较多的时候，而对于初创公司而言，可能更换metric系统更为频繁，所以假设选择的方案本身具有强耦合性，不具有可移植性时，就会带来一些问题：
a. 并存多种metric系统，每种方案都对系统资源有所占用
例如方案A通过发http请求，方案B通过写日志，方案C通过直接操作数据库。最后系统本身变成了metric系统的战场。
b. 切换新老metric系统时，需要做的工作太多。
参考问题a，每种方案的方式都不同，例如使用new relic时，需要的是绑定一个new relic jar，根据这个jar定制的规则，不见得适合其他的metric方案，例如influxdb.所以迁移时，不仅要重新修改代码，甚至修改数据结构。
所以方案本身的扩展性不仅体现在本身容量要具有可扩展性，还在于方案是否容易切换或者与其他方案并存，并与业务系统解耦，所以在实际操作时，可能需要加入一个中间层去解耦，例如常见的ELK增加一个kafka来解耦和隔离变化。
- 技术性能角度：
1. Invasive->Non-invasive
从技术角度看，选择的metric方案本身是否具有侵入性是需要考虑的第一要素，一般而言，侵入性方案提供的功能更具有可定制性和丰富性，但是代价是对系统本身会有一定的影响，例如new relic，除了常用的功能外，还能根据不同的数据库类型显示slow query等，但是它采用的方案是使用java agent在class 被加载之前对其拦截，已插入我们的监听字节码。所以实际运行的代码已不单纯是项目build出的package。不仅在业务执行前后做一些额外的操作，同时也会共享同一个jvm内的资源：例如cpu和memory等。所以在使用new relic时，要求“开辟”更多点的内存，同时也要求给项目本身的影响做一定的评估。当然new relic本身也考虑到，对系统本身的影响，所以引入了“熔断器”来保护应用程序：
com.newrelic.agent.config.CircuitBreakerConfig:
this.memoryThreshold = ((Integer) this.getProperty("memory_threshold", Integer.valueOf(20))).intValue();
this.gcCpuThreshold = ((Integer) this.getProperty("gc_cpu_threshold", Integer.valueOf(10))).intValue();
com.newrelic.agent.circuitbreaker.CircuitBreakerService：
内存控制：
double percentageFreeMemory = 100.0D * ((double) (Runtime.getRuntime().freeMemory() + (Runtime.getRuntime().maxMemory() - Runtime.getRuntime().totalMemory())) / (double) Runtime.getRuntime().maxMemory());
CPU控制：
获取年老代：
GarbageCollectorMXBean lowestGCCountBean = null;
Agent.LOG.log(Level.FINEST, "Circuit breaker: looking for old gen gc bean");
boolean tie = false;
long totalGCs = this.getGCCount();
Iterator arg5 = ManagementFactory.getGarbageCollectorMXBeans().iterator();
while (true) {
while (arg5.hasNext()) {
GarbageCollectorMXBean gcBean = (GarbageCollectorMXBean) arg5.next();
Agent.LOG.log(Level.FINEST, "Circuit breaker: checking {0}", gcBean.getName());
if (null != lowestGCCountBean
&& lowestGCCountBean.getCollectionCount() <= gcBean.getCollectionCount()) {
if (lowestGCCountBean.getCollectionCount() == gcBean.getCollectionCount()) {
tie = true;
}
} else {
tie = false;
lowestGCCountBean = gcBean;
}
}
if (this.getGCCount() == totalGCs && !tie) {
Agent.LOG.log(Level.FINEST, "Circuit breaker: found and cached oldGenGCBean: {0}",
lowestGCCountBean.getName());
this.oldGenGCBeanCached = lowestGCCountBean;
return this.oldGenGCBeanCached;
}
Agent.LOG.log(Level.FINEST, "Circuit breaker: unable to find oldGenGCBean. Best guess: {0}",
lowestGCCountBean.getName());
return lowestGCCountBean;
}
年老代GC时间占比计算：
long currentTimeInNanoseconds = System.nanoTime(); long gcCpuTime = this.getGCCpuTimeNS() - ((Long) this.lastTotalGCTimeNS.get()).longValue(); long elapsedTime = currentTimeInNanoseconds - ((Long) this.lastTimestampInNanoseconds.get()).longValue(); double gcCpuTimePercentage = (double) gcCpuTime / (double) elapsedTime * 100.0D;
2 Tcp -> Udp
使用tcp方式可靠性高，但是效率低，占用资源多，而使用udp可靠性低，但是效率高，作为metric数据本身，udp本身更适合，因为不是核心数据，丢弃少数也无所谓。
3 Sync->Async
同步方式直接影响业务请求响应时间，假设写metric本身消耗10ms，则请求响应也相应增加对应时间，但是使用异步时，不管是操作时间长的问题还是操作出错，都不会影响到业务流程。同时也容易做batch处理或者其他额外的控制。
4 Single-> Batch
对于metric数据本身，需要考察是否提供了batch的模式，batch因为数据内容更集中，从而可以减少网络开销次数和通信“头”格式的额外重复size等，同时batch方式也更容易采用压缩等手段来节约空间，毕竟metric数据本身很多字段key应该都是相同的。当然要注意的是过大的batch引发的问题，例如udp对size大小本身有限制，batch size过大时，操作时间会加长，是否超过timeout的限制。
以influxdb为例，使用udp模式的batch（小于64k）和single时，时间消耗延时如下表：
| Mode\ms | 300 | 500 | 800 | 1000 |
| Single | 34 | 85 | 111 | 173 |
| batch | 25 | 22 | 28 | 29 |
- 总结
通过以上分析，可知选择一个metric系统不应该仅仅局限当前需求，而更应该从多个角度兼顾未来发展，同时对应用产生侵入性低、隔离变化、易于切换都是选择方案必须追求的要素，否则没有搞成想要的metrics却拉倒了应用则得不偿失。
