有些公司需要这样的同步方式，再往下是具体的采集方案设计，前面已经拆分出了公共性指标和个性化指标，它们延伸出来就是公共埋点和个性埋点，公共埋点是非常重要的业务性指标，这个指标很长时间都不会变。再往下是研发口径，不管是公共埋点的事件规则、属性规则，还是采集时机，都要做统一管理，最后再进行验证。
在此基础上，还得针对两类事件做统一的设计和规划，浏览页面和功能交互是统计数据中最多的，如果浏览页面和功能交互没有规范化就会导致数据脏乱差。
为什么这么说？以手机淘宝为例，手机淘宝的终端有网页、安卓、iOS、小程序等，页面浏览和功能交互都有不同的部分，如果完全分开按照最糟糕的情况永远规范不好。
目前，一个比较好的解决方法就是把它前置，所有的功能在某一个页面的某一个位置，以一个具体的按扭呈现出来，并设置一个唯一的参数ID，再用事件和属性进行归类。这样一来，所有的页面和功能只需做一个埋点，所有页面的标记都可以用ID来标记。
探针方式: 探针方式不需要在代码编译前引入SDK，而是在应用运行的过程中，通过一个Agent动态的拦截底层框架的行为，从而自动注入监控逻辑**。像Java这样的编程语言可以通过字节码增强技术实现探针方式的链路信息采集。这是一种最开发者最友好的方式，不需要任何代码层面的改动，但并不是每一种编程语言都能提供探针机制，因此SDK方式也被很多全链路监控组件采用。
不管是SDK方式还是探针方式，非手工埋点形式的链路信息采集都依赖于链路追踪组件对于底层框架的识别。这些底层框架包含的领域非常广，其中包含应用对外提供服务所需要的框架，应用进程内部的通讯框架，应用之间相互访问所需要的框架，应用访问外部系统所需要的框架等等。比如在Java体系中，用于提供HTTP服务的Tomcat、Jetty，用于进程内部通讯的RxJava，用于微服务应用之间相互调用的Feign，用于访问外部系统的MyBatis、MySQL JDBC、HTTPClient，都属于这个范畴。对于多种编程语言以及种类繁多的底层框架的适配，是一项浩大的工程，一个全链路监控方案能够适配的底层框架越多，它的能力就越强大。
基础链路信息收集上来之后，需要进行统一存储，并对数据进行清洗与聚合，根据应用响应时间、请求数、错误率等指标进行下钻分析，并按应用、接口、链路、事务等多个维度进行展示，这也是一项非常复杂的工作。
因此，全链路监控方案的技术门槛是非常高的，在开源的全链路监控产品中，真正遵循OpenTracing标准，又够被广泛认可和使用的产品非常少，其中通过SDK方式接入的产品以Jaeger为代表，通过探针方式接入的产品以Skywalking为代表。
开源的全链路监控方案能帮助开发者更深入的理解全链路监控的思想、原理以技术细节，但在在生产环境大规模使用开源方案，还是会给开发者带来很大的挑战：
第一部分阐述了一些学习的原则。任何时候，遵循一些经过检验的原则，都是影响效率的重要因素，正确的方法是成功的秘诀。
