前面提到了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。
