1.新服务部署中Dapper的使用
Google的AdWords系统的构建围绕着一个由关键字命中准则和相关的文字广告组成的大型数据库。在这个系统进行重新开发时，开发团队从原型系统直到最终版本的发布过程中，反复的使用了Dapper。开发团队利用Dapper对系统的延迟情况进行一系列的跟踪，进而发现存在的问题，最终证明Dapper对于AdWords系统的开发起到了至关重要的作用。
2.定位长尾延迟（Addressing Long Tail Latency)
Google最重要的产品就是搜索引擎，由于规模庞大，对其进行调试是非常复杂的。当用户请求的延迟过长，即延迟时间处于延迟分布的长尾时，即使最有经验的工程师对这种端到端性能表现不好的根本原因也常常判断错误。通过图2-39不难发现，端到端性能和关键路径上的网络延迟有着极大的关系，因此发现关键路径上的网络延迟常常就能够发现端到端性能表现不佳的原因。利用Dapper恰恰能够比较准确的发现关键路径。
3.推断服务间的依存关系（Inferring Service Dependencies)
Google的后台服务之间经常需要互相的调用，当出现问题时需要确定该时刻哪些服务是相互依存的，因为这样有利于发现导致问题的真正原因。Google的“服务依存关系”项目使用监控注释和DPAI的MapReduce接口实现了服务依存关系确定的自动化。
4.确定不同服务的网络使用情况
在Dapper出现之前，Google的网管人员在网络出现故障时几乎没有工具能够确定到底是哪个部分的网络出现的故障。而现在Google利用Dapper平台构建了一个连续不断更新的控制台，用来显示内部集群网络通信中最活跃的应用层终端。这样在出现问题时可以最快的定位占用网络资源最多的几个服务。
5.分层的共享式存储系统
Google中的许多存储系统都是由多个相对独立且具有复杂层次的分布式基础架构组成。例如，Google App Engine是构建在一个可扩展的实体存储系统之上的。而该实体存储系统则是构建在底层的Bigtable之上，展现出一些RDBMS (关系型数据库管理系统）的功能。而Bigtable又依次用到了Chubby和GFS。在这样的层次式系统中决定端用户的资源消耗模式并不总是那么简单。例如，由Bigtable的单元引起的GFS高流量可能主要由一个用户或几个用户产生，但是在GFS的层次上这两种不同的使用模式是没法分开的。更进一步，在没有Dapper之类的工具的情况下对于这种共享式服务资源的争用也同样难以调试。
6.利用Dapper进行“火拼”（Firefighting with Dapper)
这里所谓的“火拼”是指处于危险状态的分布式系统的代表性活动。正在“火拼”中的Dapper用户需要访问最新的数据却没有时间来编写新的DAPI代码或者等待周期性的报告，此时可以通过和Dapper守护进程的直接通信，将所需的最新数据汇总在一起。
Dapper在Google内部取得了巨大的成功，虽然毕种成功在一定程度上得益于Google内部系统的同构性，但是Dapper团队的创新性设计才是系统取得成功的根本性因素。Google的后台系统可以说是目前全球最大的一个云平台，读者借鉴Dapper的设计思想一定能够为不同规模的云平台设计出合适的监控系统。
