续上篇，上一篇主要是讲了为啥选skywalking，以及怎么有针对性改造SW Agent，现在我们继续看看如何构建自定义Trace跟踪链
-
要对SW Agent插件做适当剪裁，原来包括customize插件在内SW 8.9有100多个插件，如果没有作用也就罢了，但是有些插件会产生大量trace和span数据，用处不大，但是会干扰需要聚焦的数据，例如一次最多查10000个trace，但有可能绝大部分都不是用户关注的，而用户关注的数据，又被淹没在无用数据中------因为运行中系统还在大量产生新的数据。
裁剪的原则是，根据应用实际，用户关注什么技术/框架，就留什么SW Agent，然后漏掉什么加什么，比如需要跟踪kafka再加，我们最终裁剪到大约30个左右，专门建立一个目录，然后把目录路径加载到JVM变量里。
另外需要注意，不同节点/服务所使用插件可以不同，但要注意衔接，例如dubbo，生成者服务和消费者服务都需要配置相关的有效SW Agent。
-
构建customize-enhance.xml
这部分的基本方法就不赘述了，可以看官方文档https://skywalking.apache.org/docs/skywalking-java/next/en/setup/service-agent/java-agent/customize-enhance-trace/
这里说两点：
1） tag标签设计，customize-enhance中的tag数据如果设计得当不仅仅能显示运行时的状态，而且可以在筛选指定类型trace方面发挥作用，这个需要和SW OAP配置文件application.yml中searchableTracesTags配置项配合使用，可以通过UI组件 Trace板块中实现按tag搜索所需的trace list，实际上可以实现在整个业务流程中根据标签精准跟踪相关业务，后续可以进一步结合导出SW OAP数据进行深加工
例如
bash
<enhanced>
<class class_name="com.quant.trade.service.baseImpl.OrderServiceImpl">
<method method="sendOrder(com.quant.trade.service.contract.OrderVO)" operation_name="/sendOrder" static="false">
<operation_name_suffix>arg[0].modelId</operation_name_suffix>
<tag key="modelId">arg[0].modelId</tag>
<tag key="userNumber">arg[0].userNumber</tag>
<tag key="refId">arg[0].refId</tag>
<tag key="systemFlag">arg[0].getSystemFlag()</tag>
<log key="infoMsg">arg[0].getSystemFlag()</log>
</method>
...
</class>
...
</enhanced>OAP的application.yml中配置
bash
# Define the set of span tag keys, which should be searchable through the GraphQL.
searchableTracesTags: ${SW_SEARCHABLE_TAG_KEYS:http.method,status_code,db.type,db.instance,mq.queue,mq.topic,mq.broker,modelId,refId,systemFlag}其中modelId（策略编号）,refId（报价编号）,systemFlag（系统标志,）是用户自定义增加的, 可以在UI组件按上述tags进行查询
例如，按systemFlag=2查询
2） 关于customize-enhance.xml 跟踪方法入参如果是复杂类型怎么提取tag数据，这部分官网说的不太清楚，可以参考我之前的写的blog
关于Skywalking Agent customize-enhance-trace对应用复杂参数类型取值
总之要对入参的类型和方法要有充分了解，不要机械套用官网的说明
完成Agent的修补和customize-enhance.xml 就可以构建自定义Trace链，可以在UI的查询，一般可以用两种方式定位Trace
1） 按Service Instance Endpoint名字搜索定位，注意 Endpoint需要SW Agent构建的EntrySpan才能搜索，如果是自定义的Local则不能用这个办法
2） 用刚才提到的tag查询，不再赘述。
到目前位置，我们已经完成自定义监控构建，那是不是已经万事大吉了，还没有，思考几个问题
-
Scope Metrics 只有SW Agent构建的标准化的Endpoint，instance和Service才有比较多监控项，但是用户定义的Trace却没有办法计算和展示监控项（metrics）
-
虽然SW UI结合Tags搜索较为灵活，但终究是作用于一个span上，即同一个操作或者方法上，但如果要求同时满足，调用方法1（span1）按策略号搜索，且endpointName为XXX的trace，则力不从心。比如搜索 网页发起（按endpointName）的某个策略号（tag systemFlag=2）统计跟踪情况，就无能为力了
-
如果要深入分析哪些操作方法最耗时的，需要跨trace综合分析span的信息，肯定也是做不到的
拿怎么解决这个问题呢，下一篇我们会讨论基于GraphQL用户接口的二次开发，解决上述问题