背景

rpc请求的时候，上游调用下游，希望能记录每次调用标识以及结果，以后看服务稳定性相关报表的时候方便直接可视化，比如耗时，调用方名字，被调用方名字，集群名等，如果每个业务代码都自己写一遍调用不同下游的代码，过于繁琐
需要有一个记录metrics的组件，封装所有上游调用下游的请求

metrics说明

metrics是用来显示整体调用情况的，可tsdb和grafana配合使用，这里不展开可以参照refer
metric核心函数

emit_counter(key,n,tagkv):代表某个key计数+n,tagkv表示附带信息map,可用来记录成功失败次数
emit_timer(key,time,tagkv):记录某个key花费时间，可用来记录一次请求耗时

实现

定义key

调用成功计数SUC_COUNTER_KEY:
${from}.call.success.throughput

调用失败计数FAIL__COUNTER_KEY:
${from}.call.fail.throughput

调用成功耗时：SUC_TIMER_KEY
${from}.call.success.latency.us

调用失败耗时:FAILE_TIMER_KEY
${from}.call.fail.latency.us

定义tagkv

可以作为后续按tagkv分类查询,包含

from_method：调用方名字
called:被调用方服务标志
method:被调用方的方法名
to_cluster:被调用方的集群名
from_cluster:调用方集群名称
from:被调用方名字
status_code:调用结果码（成功，失败，异常等）
cost:此次rpc请求耗时

记录metrics实现

框架上用middleware,切面等方式（我是以py的django框架为基础，其他语言也有自己的框架)，该中间件的处理在upstream调用下游的时候
除了cost和status_code之外，在rpc调用前就能获取到
cost和status_code则在请求处理时记录

成功，则

emit_counter(SUC_COUNTER_KEY, 1, tagkv)
emit_timer(SUC_TIMER_KEY, cost, tagkv)

失败，则

emit_counter(FAIL_COUNTER_KEY, 1, tagkv)
emit_timer(FAIL_TIMER_KEY, cost, tagkv)

思考

cost是哪里获取的

是真正调用rpc前后的时间之差，在该middle更下层

治理metrics的意义

方便可视化查看各个rpc调用的成功失败率，以及成功失败的耗时
并且可以根据metrics发出的结果，计算出pct99，avg等值，由metrics agent发出

refer

http://docs.grafana.org/features/panels/graph/