基于Skywalking开发分布式监控（四）一个案例

上一篇我们简单介绍了基于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. 问题2 反馈消息是根据交易所API生成的，不是一个标准通讯架构，只能根据自定义用户增强（customize-enhance），生成的localSpan形成跟踪链，那SW原生Trace查询根本没法按endpoint名字搜索，只能按tag搜索，然后按时间取定位，效率非常低
3. 还有一个上一篇说了，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" : {