上一篇我们简单介绍了基于SkyWalking自定义增强的基本架构,即通过把Trace数据导入数据加工模块进行加工,进行持久化,并赋能grafana展示。
现在我们给出一个例子,对于量化交易系统,市场交易订单提交,该订单可以走模拟盘也可以走实盘,可以自动提交,也可以走人工提交,订单提交后,会把交易所给到的订单信息反馈回来。 需要监控的需求很简单:可以按,自动实盘/虚拟盘,人工实盘/虚拟盘订单分类监控,提交和反馈流程,满足指标项:
1 每分钟延时、延时百分位(P50/75/90/95/99 MAX)、每分钟请求数,排名前5的慢请求等监控项(metrics)
2 以及按排名前5的慢请求对应的SPAN进行抓取,分析出最慢的SPAN
那么SW原生监控有啥问题呢?
1 需要根据该流程在不同阶段的特征才能定位该流程,按Trace-Span模型来说,即需要一个Trace链根据不同Span提供的特征才能抓取该Trace,SW并不支持
例如 分辨人工/自动订单实际上是按Trace相关EndpointName来的
人工订单走页面,EntrySpan的 endpointName为POST:/api/trade/order/send
但自动订单由程序发起,EntrySpan的 endpointName为“rpc.OrderTradeService.send”
而分辨是否走实盘/虚拟盘,则是在后续Span,按tag systemFlag=1或2,来确认

而SW的搜索显然是不支持的
- 问题2 反馈消息是根据交易所API生成的,不是一个标准通讯架构,只能根据自定义用户增强(customize-enhance),生成的localSpan形成跟踪链,那SW原生Trace查询根本没法按endpoint名字搜索,只能按tag搜索,然后按时间取定位,效率非常低
- 还有一个上一篇说了,SW对Trace和Span不提供metric聚合项
那增强计算模块怎么解决上述问题
对问题1: 按人工、自动、虚拟、实盘,形成4个搜索项,然后定时(基本)同时执行,把搜索结果叠加到ES索引中,按订单编号trade_id更新索引项,利用ES的向量特征形加上业务标签,供下游按业务标签定位需要的Trace
对问题2: 按预先设计的Tag值标识反馈消息,然后按Tag搜索,把搜索结果叠加到ES索引中,按订单编号trade_id更新索引项,利用ES的向量特征形加上业务标签,供下游按业务标签定位需要的Trace
对问题3 按业务标签计算各监控项(metrics),并按时间点汇总最慢的5个Trace,查找Span
我们按配置config来说明
关于问题1,我们配置了4个搜索项
"tasks" : [
{
#查找按EndpointName=rpc.OrderTradeService.send查找自动订单,并且在ES索引中增加业务标签 businessTag:: Auto
"name": "task.QueryTraces",
"para" : {
"serviceName" : "TradeService",
"endpointName" : "rpc.OrderTradeService.send",
"businessTag" : {
"key": "businessTag", "value": "Auto"},
"tags" : {
},
"traces_index" : "traces-" #索引名,xx-后面跟着日期
},
"switch" : "on", #搜索项有效
"interval" : "60" #每隔60秒执行一次
},
{
#查找按EndpointName=POST:/api/trade/order/send查找人工订单,并且在ES索引中增加业务标签 businessTag:: manual
"name" : "task.QueryTraces",
"para" : {
"serviceName" : "TradeService",
"endpointName" : "POST:/api/trade/order/send",
"businessTag" : {
"key": "businessTag", "value": "manual"},
"tags" : {
},
"traces_index" : "traces-"
},
"switch" : "on",
"interval" : "60"
},
{
#查找按tag: systemFlag=1 查找人工订单,并且在ES索引中增加业务标签 systemFlag:: 1 (实盘)
"name" : "task.QueryTraces",
"para" : {
"serviceName" : "TradeService",
"endpointName" : "",
"businessTag" : {
"key": "systemFlag", "value": "sim"},
"tags" : {
"key": "systemFlag", "value": "1"},
"traces_index" : "traces-"
},
"switch" : "on",
"interval" : "60"
},
{
#查找按tag: systemFlag=2 查找人工订单,并且在ES索引中增加业务标签 systemFlag:: 2 (实盘)
"name" : "task.QueryTraces",
"para" : {
"serviceName" : "TradeService",
"endpointName" : "",
"businessTag" : {
"key": "systemFlag", "value": "RealTime"},
"tags" : {
"key": "systemFlag", "value": "2"},
"traces_index" : "traces-"
},
"switch" : "on",
"interval" : "60"
},
task.QueryTraces是查询程序,按每分钟1次的节奏,按Graphql接口查询,需要用到的接口,按ServiceName按SW内置查询searchService接口查ServiceId , 按SW内置查询searchEndpoint接口查EndpointId
然后根据ServiceId , EndpointId调用,或者ServiceId和预置Tag,按SW内置查询接口queryBasicTraces查询相关Traces,注意点如下:
1 查询窗口要注意,也就是要防止Trace形成前执行查询语句,建议做成滑动窗口,可以调节窗口的大小,或者隔几秒多试几次(比如10秒执行3次)
2 要注意应用多页查询,queryBasicTraces有页数限制,一次最多1000条,要查全需要比较完整多页查询结构
查询完更新ES索引之后

很容易根据业务标签,获取我们所需的Traces
同理对问题2,我们引入配置文件,实际上我们利用FIX报文msgtype=8 报文的特征来标识反馈消息,然后按ordStatus,表示是否是成交或者订单有效的报文,即按tags msgType=8, ordStatus=2/0 查询相关Traces
{
"name" : "task.QueryTraces",
"para" : {
"serviceName" : "APIService",
"endpointName" : "",
"businessTag" : {
"key": "OrdStatus", "value": "deal"},
"tags" : [{
"key": "msgType", "value": "8"},{
"key": "ordStatus","value": "2"}],
"traces_index" : "traces-"
},
"switch" : "on",
"interval" : "60"
},
{
"name" : "task.TracesQueryInfo",
"para" : {

最低0.47元/天 解锁文章
542

被折叠的 条评论
为什么被折叠?



