kamon文档翻译（三）--Tracing-核心概念

Tracing 模块

Tracing 模块提供基本的API让你能够记录你的应用程序中有用的功能点信息，允许你获取你的应用程序运行时更深层次的和更精确的数据，以及内部组件的运行状态。
在metrics模块引导你监测你的应用程序中特定的模块时，tracing模块工作在更高的层次，当组建之间的交互，提供具体的面向用户的功能是关系的主题。在这里，主要目的是了解功能X和功能Y的行为方式，如果可能，并知道这些组成功能点的组件的行为方式。
假定有一个类似Twitter的应用程序，你想要测量和监测。它提供了两种基本的功能：“发布新状态”和“获取用户时间线”。在这简单的例子中，所有的数据都可以从数据库中获取到，当你监测“发布新状态”功能时，显然你想知道处理每个新状态时花费的时间，此外，你也想知道这段查询数据库的代码是如何从普通的查询到成为数据库的瓶颈的。也许有一个内部共享功能点叫做“获取用户细节”，在“发布新状态”和“获取用户时间线”中都有用到，当调用“获取用户细节”时，单独测量“获取用户细节”这段代码是不够的，二是要获取足够的上下文信息去了解他在被“发布新状态”和“获取用户时间线”调用时是如何工作的。
将上文用kamon术语阐述的话，我们将一个功能点的调用称为一个Trace,组成trace的每个zujian 叫做Segments。每次请求“发布新状态”都会生成一个新的trace，每次调用“获取用户细节”的代码段都是一个属于segment，这个segment属于前面所述的trace。所有关于trace的信息都被存储在一个单独的TraceContext实例中，下面将会阐述。

TraceContext

TraceContext Kamon提供的tracing基本组件中的一个基础片，理解他的工作方式并且理解为了最有效的发挥作用，它是如何传播的，这跟重要。
你的应用程序每调用一次traced功能点，都会生成一个新的TraceContext ，用来存储与这个trace有关的所有的性能和诊断信息。作为一个开始，TraceContext 有以下几个属性：

• name：一次traced请求中一个用户友好的描述功能点的名字。例子可以使“GetUserDetails”，“PublisStatus”或者“GenerateSalesReport”。Trace可以在一次请求执行过程中的任何时候被重命名。你或许已经想到了，应用程序中的多个traces应该有相同的名字。
• trace-token：给TraceContext 自动生成的一个id，一旦TraceContext 被创建，知道trace结束这个trace-token都不会变。与trace name 不同，trace token是独一无二的，在应用程序的整个声明周期中不能重复。
• metadata： 简单的key-value对，包含trace执行过程中的其他信息。

可以通过请求Kamon的tracer获取TraceContext ，你不能够直接实例化它，因为他的依赖被严格的控制，并且由Kamon根据你提供的配置生成。创建一个TrraceContext 并在几秒收关闭它。

Scala：

val newContext = Kamon.tracer.newContext("test-trace")Thread.sleep(3000)newContext.finish()

Java:

final TraceContext newContext = Kamon.tracer().newContext("test-trace");Thread.sleep(3000);newContext.finish();

上面的例子中，我们可以看到最基本的trace操作：测量获取的时间。当我们创建一个新的TraceContext时，Kamon自动记录他的开始时间戳，并通过调用.finish()结束这个trace，这期间trace经过的时间被记录下来。更多的操作参考trace metrics小节。
这是一个极其简单的例子，真实世界的应用程序中很少能够再遇到。事实上，你的应用程序中会用到几个组件，一个trace的整个生命周期都会被这些组建的交替管理。但是，为了提高和增强争端和它所包含的性能数据，每个组件都必须访问同一个TraceContext 。因此需要有一个独一无二的和可预测的地方来查看和存储上下文信息。
在你的应用程序中，从开始到结束，你都能够用简单的方法将TraceContext实例传递给所有相关的组件，也就能完全控制trace的整个生命周期，从而清晰的描述它所覆盖的步骤，但是也极其多余。这样做之外，您也可以将应用程序代码与Kamon的跟踪基础设施相结合，这似乎不太好。相反，我们定义了一个单独的地方来查找和存储TraceContext在当前线程中执行的功能，我们确保托管在那里的信息是一致和可预测的，而不管使用的线程模型如何。有关详细信息，请参阅跟踪上下文存储部分。

Trace Segments

如上所述，segments聚焦在组成trace的代码段的行为，查看哇靠，segments也不能够在Kamon中单独使用，因为你要先有一个trace，然后在创建一个属于这个trace的segment。一旦创建了这个trace的segment，他将永远属于这个trace。与TraceContext类似，segments也有几个属性：

• category：通常来讲，精确描述segment是关于什么的。一些模块为http-client和database创建了了segments分类，不仅仅是这些模块，这仅仅是为了信息目的。
• name segment的名字应该能够精确的告诉你这个segment是用来干嘛的。
• library : 基础模块通过library属性告诉我们是哪个库创建了segment。
• metadata ： 简单的key-value对包含了segment执行过程中的额外信息。

segment的生命周期不会与trace的生命周期绑定。可以在任何时刻创建并结束segment，不论trace是否打开。

Tracing 级别

tracing模块目标在于提供两个不同的trace 级别，可以用于收集你的应用程序的监测信息，可以通过配置kamon.trace.level-of-detali 配置这两个追踪级别。分别是：

• Metric Only： 默认的配置。trace和segment仅仅用于收集消耗时间的时候。只能收集trace metrics 小节描述的metric信息。
• Simple Tracing : 额外的收集trace metrics信息。simple tracing级别的tracing存储每个运行的与之有关的segment信息，你能通过简单的甘特图展示trace以及所有的segment。与metric only级别相比，这个级别做的更多，这就是为什么你需要配置要被用到的采样机制，当你决定trace应该收集额外的信息还是仅仅收集metrics的信息。可以选择的采样机制有：
  
  • all : 每个trace都会被选择和报告
  • random : 使用一个随机数发生器产生1-100的随机数，如果产生的数小于等于设定的几率，这个trace就被选择和报告
  • ordered : 每个采样间隔选择一个trace，跟踪并报告
  • threshold ： 这个可能是最优意思的。采样方法会选择所有的trace收集信息，但是只报告消耗时间超出阈值的那个trace。

用kamon.trace.sampling 配置可以设定采样机制。kamon默认使用10%的概率随机采样选择trace。