对系统行为进行监控的过程非常的复杂，特别是在分布式系统中。为了理解这种复杂性，首先来看如图2-30所示的一个过程。
在图中，用户发出一个请求X，它期待得到系统对它做出的应答X。但是接收到该请求的前端A发现该请求的处理需要涉及服务器B和服务器C,因此A又向B和C发出两个RPC (远程过程调用）。B收到后立刻做出晌应，但是C在接到后发现它还需要调用服务器D和E才能完成请求X,因此C对D和E分别发出了RPC, D和E接到后分别做出了应答，收到D和E的应答之后C才向A做出响应，在接收到B和C的应答之后A才对用户请求X做出一个应答X。在监控系统中记录下所有这些消息不难，如何将这些消息记录同特定的请求（本例中的X)关联起来才是分布式监控系统设计中需要解决的关键性问题之一。
一般来说，有两种方案可供选择：黑盒（Black Box)方案及基于注释的监控 (Annotation-based Monitoring)方案。二者比较而言，黑盒方案比较轻便，但是在消息关系判断的过程中，黑盒方案主要是利用一些统计学的知识来进行推断，有时不是很准确。基于注释的方案利用应用程序或中间件给每条记录赋予一个全局性的标示符，借此将相关消息串联起来。考虑到实际的需求，Google的工程师最终选择了基于注释的方案，为了尽可能消除监控系统的应用程序对被监控系统的性能产生的不良影响，Google的工程师设计并实现了一套轻量级的核心功能库，这将在后面进行介绍。
Dapper监控系统中有三个基本概念：监控树（Trace Tree)、区间（Span)和注释 (Annotation)。如图2-31所示是一个典型的监控树，从中可以看到所谓的监控树实际上就是一个同特定事件相关的所有消息，只不过这些消息是按照一定的规律以树的形式组织起来。树中的每一个节点称为一个区间，区间实际上就是一条记录，所有这些记录联系在一起就构成了对某个事件的完整监控。从图2-31不难看出，每个区间包括如下的内蓉：区间名（Span Name)、区间id（Span id)、父id（Parent id)和监控id（Trace id)。区间名主要是为了方便人们记忆和理解，因此要求这个区间名是人们可以读懂的。区间id是为了在一棵监控树中区分不同的区间。父id是区间中非常重要的一个内容，正是通过父id才能够对树中不同区间的关系进行重建，没有父id的区间称为根区间（Root Span)。图2-31中的Fnmtend Request就是一个根区间。在图中还能看出，区间的长度实际上包括了区间的开始及结束时间信息。
监控id在图2-31中并没有列出，一棵监控树中所有区间的监控id是相同的，这个监控id是随机分配的，且在整个Dapper监控系统中是唯一的。正如区间id是用来在某个监控树中区分不同的区间一样，监控id是用来在整个Dapper监控系统中区分不同的监控。注释主要要用来辅助推断区间关系，也可以包含一些自定义的内容。图2-32展示了图2-31中Helper.Call区间的更详细信息。
在图2-32中可以清楚地看到这个区间的区间名是“Helper.Call”，监控id是100,区间id是5，父id是3。一个区间既可以只有一台主机的信息，也可以包含来源于多个主机的信息；事实上，每个RPC区间都包含来自客户端（Client)和服务器租用端（Server)的注释，这使得双主机区间（Two-host Span)成为最常见的一种。图2-32中的区间就包含了来自客户端的注释信息：“<Start>”、
“Client Send”、“Client Recv” 和“<End>”，也包含了来自服务器端的注释信息：“Server Recv”、“foo”和“Server Send”。除了“foo”是用户自定义的注释外，其他的注释信息都是和时间相关的信息。Dapper不但支持用户进行 简单的文本方式的注释，还支持键-值对方式的注释，这赋予了开发者更多的自由。
“Client Send”、“Client Recv” 和“<End>”，也包含了来自服务器端的注释信息：“Server Recv”、“foo”和“Server Send”。除了“foo”是用户自定义的注释外，其他的注释信息都是和时间相关的信息。Dapper不但支持用户进行 简单的文本方式的注释，还支持键-值对方式的注释，这赋予了开发者更多的自由。
2.监控信息的汇总
Dapper对几乎所有的Google后台服务器进行监控。海量的消息记录必须通过一定的方式汇集在一起才能产生有效的监控信息。在实际中，Dapper监控信息的汇总需要经过三个步骤，如图2-33所示。
(1)将区间的数据被写入到本地的日志文件。
(2)利用Dapper守护进程（Dapper daemon)和Dapper收集器（Dapper Collectors)将所有机器上的本地日志文件汇集在一起。
(3)将汇集后的数据写入到Bigtable存储库中。
从图中也很容易地看出，（1）和（2）是一个读的过程，而（3）是一个写的过程。选择Bigtable主要是因为区间的数目非常多，而且各个区间的长度变化很大，Bigtable对于这种很松散的表结构能够很好地进行支持。写入数据后的Bigtable中，单独的一行表示一个记录，而一列则相当于一个区间。这些监控数据的汇总是单独进行的，而不是伴随系统对用户的应答一起返回的。如此选择主要有如下的两个原因：首先，一个内置的汇总方案 (监控数据随RPC应答头返回）会影响网络动态。一般来说，RPC应答数据规模比较的小，通常不超过10kb。而区间数据往往非常的庞大，如果将二者放在一起传输，会使这些RPC应答数据相对“矮化”进而影响后期的分析。另一方面，内置的汇总方案需要保证所有的RPC都是完全嵌套的，但有许多的中间件系统在其所有的后台返回最终结果之前就对调用者返回结果，这样有些监控信息就无法被收集。基于这两个考虑，Google选择将监控数据和应答信息分开传输。
安全问题是所有系统都必须考虑的问题，为了防止未授权用户对于RPC信息的访问，信息汇总过程中Dapper只存储RPC方法的名称却不存储任何RPC负载数据，取而代之的是，应用层注释提供了一种方便的选择机制（OPt-in Mechanism):应用程序开发者可以将任何对后期分析有益的数据和区间关联起来。
