最近公司在准备接入Prometheus作为全平台监控方案，之前有考虑过全链路监控方案，但是一直没有时间没有精力去深入研究这块，起源是源于 CTO 转发的一篇文章 php全链路监控完全实现。很多事情，一旦你没有去努力，就与你无缘了。不尽人事，如何能安天命？
google 的这篇Dapper 的论文，基本是现在所有的分布式跟踪系统的理论基石。
第一章 介绍
其里面提到了系统设计的三个目标
- 低消耗
- 应用级透明
- 延展性
其实很好理解这三个目标，如果不是低消耗，那么接入方接入的话，就容易对现有系统的负载有影响，无法保证现有系统的稳定性。如果非应用级透明，而是与业务代码耦合的话，业务方接入的成本过高，同时容易漏接入。延展性就更不用多说了，设计一个系统，特别是这种与业务无关的底层系统，必须预见到其未来几年的发展方向。
第二章 Dapper的分布式跟踪
其实主要就是Dapper的分布式跟踪实现方案
为了实现低损耗，而提到了采样率的方案。确实很多时候我们也不需要全量记录，只要样本够大，该发生的问题理应会二次发生的。
不过里面还提到一点我完全没考虑到的一点是，其对系统的安全与隐私问题也能进行一定的监控。比源码审核更为强大的保障。有时候会觉得，google 的运维的基本思路就是，將一切自动化。
第三章 Dapper部署状况
目标：无处不在的部署和应用级的透明
通过对公共组件的改造，既实现了应用级的透明，也通过组件，部署到了所有的机器上。
第四章 处理跟踪损耗
主要就是跟踪的损耗问题，以及如何如何处理这个问题。
跟踪的损耗主要在于，追踪和收集数据，存储和分析所收集到的数据两个方面。
解决这个问题的最佳方式是采样。我也没想到有更好的方式可以解决这个问题，因为通过采样，我们可以最小化跟踪对整个系统负载的影响，甚至可以通过系统负载或者其他因素来对系统进行动态采样。
第五章 通用的Dapper工具
这章其实挺中规中矩的，大部分的组件，都会提供 web 管理界面，以及提供 api 接口，能够让你进行二次开发，自定制功能和界面。
第六章 经验
主要就是使用 Dapper 解决的一些问题
与异常监控的集成。
能够发现以前没法轻易发现的一些问题，系统的依赖也许并非如你所愿。
其它收获 相关产品 总结
剩下就是论文的标准收尾部分了。
总有一些问题，你不上线是根本想不到的。使用方能够帮你提出问题，更加完善你的系统。没有十全十美的系统，只有不断完善的系统。
自己的总结
自己基础还是比较差，思维不够清晰。觉得有时候读论文，应该要想着如果是我来做，我会采用什么方案，别人为什么采用了这个方案，有什么优势，自己为什么没想到。多思考，才能有收获。光是阅读，是远远不够的啊。
