前面提到了Dapper的三个基本设计目标，在这三个目标中，实现难度最大的是对应用层透明。为了达到既定设计目标，Google不断进行创新,最终采用了一些关键性技术解决了存在的问题。这些关键性技术概括起来主要包括以下两个方面。
1.轻量级的核心功能库
这主要是为了实现对应用层透明，设计人员通过将DaPPer的核心监控实现限制在一个由通用线程（Ubiquitous Threading)、控制流（Control Flow)和 RPC代码库（RPC Library Code)组成的小规模库基础上实现了这个目标。其中最关键的代码基础是基本Rpc、线程和控制流函数库的实现，主要功能是实现区间创建、抽样和在本地磁盘上记录日志。用C++的话Dapper核心功能的实现不超过1000行代码，而用Java则不到800行。键/值对方式注释功能的实现需要额外增加500行代码。将复杂的功能实现限制在一个轻量级的核心功能库中保证了Dapper的监控过程基本对应用层透明。
2.二次抽样技术
监控开销的大小直接决定Dapper的成败，为了尽可能地减小开销，进而将Dapped泛部署在Google中，设计人员设计了一种非常巧妙的二次抽样方案。二次抽样顾名思义包括两次抽样过程。Google每天需要处理的请求量惊人，如果对所有的请求都进行监控的话所产生的监控数据将会十分的庞大，也不利于数据分析，因此DaPPer对这些请求进行了抽样，只有被抽中的请求才会被监控。在实践中，DaPPer的设计人员发现了一个非常有意思的现象，那就是当抽样率低至1/1024时也能够产生足够多的有效监控数据，却在1024个请求中抽取1个进行监控也是可行的，这种低抽样率有效的原因在于巨大的事件数量使关注的事件可能出现的足够多，从而可以捕获有效数据。这就是DaPPer的第一次抽样。最初Dapper设计的是统一的抽样率，但是慢慢地发现对于一些流量较低的服务，低抽样率很可能会导致一些关键性事件被忽略，因此Dapper的设计团队正在设计一种具有适应性抽样率的方案。尽管釆取抽样监控，所产生的数据量也是惊人的。根据Dapper团队的统计，Dapper每天得到的监控数据量已经超过1T,如果将这些数据全部写入Bigtable中效率较低，而且Bigtable的数据存储量有限，必须定期处理，较少的数据能够保存更长的时间。对此，Dapper团队设计了第二次的抽样。这次抽样发生在数据写入Bigtable之前，具体方法是将监控id散列）成一个标量z,其中0<z<l。如果某个区间的z小于事先定义好的汇总抽样系数（Collection Sampling Coeficient)，则保留这个区间并将它写入Bigtable。否则丢弃不用。也就是说在采样决策中利用z值来决定某个监控树是整棵予以保留还是整棵弃用。这种方法非常的巧妙，因为在必要时只需改动z值就可以改变整个系统的写入数据量。利用二次抽样技术成功地解决了低开销及广泛可部署性的问题。
上面的两种技术手段解决了主要设计问题，这使得Dapper在Google内部得到了广泛应用。Dapper守护进程已成为Google镜像的一部分，因此Google所有的服务器上都有运行Dapper。
