在服务导向架构(SOA)的应用中，当出现问题时，定位问题的源头和确定出错的组件及Web服务可能会非常困难。由于同一错误日志可能分布在不同的机器上，这些机器与参与活动的Web服务和消费者共存。为了找到问题的原因，需要从不同机器上整合日志。此外，弄清楚Web服务是如何被消费的，以及错误发生的时间，也没有一个简单的机制来捕获系统内活动的端到端流程。
为了解决这些困难，需要一个可靠的日志系统，比如UptoLog。本文将探讨UptoLog，并描述这个日志系统如何在.NET SOA应用程序中使用。
UptoLog旨在收集.NET 2.0、3.0和3.5应用程序中应用程序故障的详细信息。该系统记录错误，并在多个逻辑和物理层生成跟踪和时间度量。日志数据被收集到一个中央数据库中。在特定活动中收集的所有日志数据都通过一个唯一的活动ID关联起来。这使得可以跨系统内多个层对特定活动的错误、跟踪和时间度量进行分组。
下图展示了UptoLog日志系统是如何集成到SOA应用程序中的。
可以在这里找到UptoLog日志系统不同组件的详细信息。
UptoLog搜索服务器是一个带有简单搜索工具的Web应用程序。这使能够搜索收集到的日志数据，并调查应用程序故障，或通过跨多台机器的时间度量观察系统的实际响应时间。
例如，如果应用程序出现错误，Web服务消费者和上下文将自动可视化，因为错误日志是从应用程序的所有层收集到一个中央数据库中，并且日志是按活动分组的。
以下是通过UptoLog搜索服务器可视化日志的两个示例。
下图是一个应用程序故障的屏幕截图，显示了来自两个不同层的两个错误日志，按活动分组：
以下是显示活动的响应时间的时间度量屏幕截图：
如果想尝试这些示例，可以在此处下载用于示例的测试应用程序。测试应用程序位于一个.NET 2.0解决方案中，该解决方案还包含其他示例。
应用程序通过UptoLog卫星组件进行日志记录，该组件集成到SOA应用程序中的所有消费者和Web服务应用程序中。
日志记录功能简要描述如下。更详细的描述可以在此处找到。
错误是通过方法调用来记录的。UptoLog以三种不同的错误级别记录错误。根据所需的错误级别，使用以下方法之一：
LogFatalError, LogError, 或 LogWarning
以下是如何记录致命错误的示例：
try
{
// 可能导致错误的应用程序代码。
}
catch (Exception exc)
{
Log.LogFatalError(exc);
// 记录致命错误。
}
跟踪由UptoLog卫星收集，并通过包发送跟踪日志。以下是如何生成跟踪的示例：
private void SomeMethod()
{
Log.LogTraceItem(
"执行代码前的跟踪文本"
);
// 一些应用程序代码。
Log.LogTraceItem(
"执行代码后的跟踪文本"
);
}
UptoLog卫星收集时间度量，并以包的形式发送度量。时间度量通常可以通过以下两种不同的方式生成。
// 第一种方法
private void SomeMethod()
{
TimeMeasure tm = Log.BeginTimeMeasure(
"时间度量的名称"
);
// 一些应用程序代码。
tm.EndTimeMeasure();
}
// 第二种方法
private void SomeMethod()
{
using (Log.BeginTimeMeasure(
"时间度量的名称"
))
{
// 一些应用程序代码。
}
// 即使应用程序代码出现故障，时间度量也会自动停止。
}
UptoLog卫星在消费者中持有一个活动GUID，每次开始一个新活动时都必须更新。当消费者调用Web服务时，Web服务请求是活动的一部分，该活动是在Web服务外部开始的。因此，需要在消费者处读取活动GUID（活动ID），将活动GUID与Web服务调用一起发送，并将其传递给Web服务中的UptoLog卫星。
活动GUID的更新方式如下：
Log.StartNewActivityId();
随后可以在消费者处的UptoLog卫星中读取活动GUID：
Guid someActivityId = Log.CurrentActivityId;
通过Web服务调用接收到的活动GUID如下传递给Web服务中的UptoLog卫星：
Log.CurrentActivityId = someActivityId;