Breeze‘s Blog

admin：Breeze

Dapper是什么

Dapper是Google开发的用于对后台进行全天候监控的大规模分布式系统的一种跟踪监控系统。

Google在开发时对于Dapper的基本要求

*广泛可部署性

一个监控系统应当能够对尽可能多的Google服务进行监控。

*不间断的监控

Google的服务是全天候的，如果不能对Google 的后台同样进行全天候的监控很可能会错过某些无法再现的关键性故障。

Dapper的设计目标

*低开销

这个是广泛可部署性的必然要求。监控系统的开销越低，对于原系统的影响就越小，系统的开发人员也就越愿意接受这个监控系统；

*对应用层透明

监控系统对程序员应当是不可见的。如果监控系统的使用需要程序开发人员对其底层的一些细节进行调整才能正常工作的话，这个监控系统肯定不是一个完善的监控系统；

*可扩展性

Google的服务增长速度是惊人的，设计出的系统至少在未来几年里要能够满足Google服务和集群的需求。

轻量级的核心功能库

为了实现对应用层透明，设计人员通过将Dapper的核心监控实现限制在一个由通用线程（Ubiquitous Threading）、控制流（Control Flow）和RPC代码库（RPC Library Code）组成的小规模库基础上实现了这个目标。

其中最关键的代码基础是线程、控制流函数库和基本RPC的实现，主要功能是实现区间创建、抽样和在本地磁盘上记录日志。将复杂的功能实现限制在一个轻量级的核心功能库中保证了Dapper的监控过程基本对应用层透明。

二次抽样技术

为了尽可能地减小开销，进而将Dapper广泛部署在Google中，设计人员设计了一种非常巧妙的二次抽样方案。二次抽样顾名思义包括两次抽样过程。Google每天需要处理的请求量惊人，如果对所有的请求都进行监控的话所产生的监控数据将会十分的庞大，也不利于数据分析，因此Dapper对这些请求进行了抽样，只有被抽中的请求才会被监控。

*第一次抽样

实践中，设计人员发现当抽样率低至1/1024时也能够产生足够多的有效监控数据，即在1024个请求中抽取1个进行监控也是可行的，从而可以捕获有效数据；（注：这种低抽样率有效的原因在于巨大的事件数量使关注的事件可能出现的足够多，从而可以捕获有效数据。）

最初Dapper设计的是统一的抽样率，但是慢慢地发现对于一些流量较低的服务，低抽样率很可能会导致一些关键性事件被忽略，因此Dapper的设计团队正在设计一种具有适应性抽样率的方案。

尽管采取抽样监控，所产生的数据量也是惊人的。根据Dapper团队的统计，Dapper每天得到的监控数据量已经超过1T，如果将这些数据全部写入Bigtable中效率较低（注意，最后的监控数据将写入BigTable中），而且Bigtable的数据存储量有限，必须定期处理，较少的数据能够保存更长的时间。对此，Dapper团队设计了第二次的抽样。

*第二次抽样

第二次抽样发生在数据写入Bigtable前（时机很重要），具体方法是将监控id散列成一个标量z（0≤z≤1），如果某个区间的z小于事先定义好的汇总抽样系数（Collection Sampling Coeficient），则保留这个区间并将它写入Bigtable，否则丢弃。也就是说在采样决策中利用z值来决定某个监控树是整棵予以保留还是整棵弃用。这种方法非常的巧妙，因为在必要时只需改动z值就可以改变整个系统的写入数据量。

附：沙盒限制

Google App Engine为每个应用程序提供了一个安全运行环境，该沙盒可以保证每个应用程序能够*安全*地*隔离*运行。

沙盒是Google App Engine虚拟出的一个环境，类似于PC所使用的虚拟机。

沙盒对用户进行以下限制

（1）与互联网中的计算机进行交互：用户的应用程序只能通过Google App Engine提供的网址抓取API和电子邮件服务API来访问互联网中其他的计算机，并且其他计算机如请求与该应用程序相连接，只能在标准接口上通过HTTP或HTTPS进行。
（特定网址限制）

（2）应用程序无法对Google App Engine的文件系统进行写入操作，只能读取应用程序代码上的文件，并且该应用程序必须使用Google App Engine的Data Store数据库来存储应用程序运行期间持续存在的数据。
（只读不写限制）

（3）应用程序只有在响应网络请求时才运行，并且这个响应时间必须极短，在几秒之内必须完成。与此同时，请求处理的程序不能在自己的响应发送后产生子进程或执行代码。
（短时响应限制）