一个简单的远程日志平台

一个简单的远程日志平台

在github
源代码
下载二进制文件
初始 src - 下载客户端库- 2.8 KB
初始 src - 下载演示- 5.9 MB的

介绍

日志是我们应用程序中最常见的部分之一，要么有网站或者客户端应用程序，没有任何合适的日志支持就无法构建程序。 像NLog或者log4net这样的当前库提供了一个强大的方法来跟踪我们的应用程序做什么并提供一些错误报告。 无论如何，大多数日志都被隔离在它们所产生的范围上，在服务器内部非常隐蔽。 有时，我在项目中看到了发送一些重要事件或者关键错误的电子邮件的实践。 现在，有很多方法可以集中日志。 这是通过收集日志或者向中央日志接收器发送事件，开发人员可以访问。 这在一些业务环境中非常常见，随着事情的发展，我认为这是必要的，这种实践在将来会更加普遍。

日志集中可以采用两种不同的方法实现：

使用中央日志收集器，安装了"on-premise"，我们将在这里定义日志源
使用面向服务的架构，在这里我们向这个实体发送错误或者事件
第一种方法可以通过使用( 商业或者免费)的众多工具之一实现。 这些工具通常安装起来很复杂，并且有一些维护成本，所以我们经常选择第二个工具，这仅仅是购买在 SAAS ( 软件作为服务) 中转售的许多在线工具之一。 这种方法具有成本低的优点，但有时不会选择对数据收集( 大多数服务保证crypted和独立数据源) 丢失信任。

因此，在本文中，我们将介绍两种解决方案的优点，即生成一个轻量级且易于安装的平台服务，我们将在web服务器中安装基本的日志收集功能。 此外，我们将实现一个NLog目标( log4net附加程序的类似概念)，以演示如何使用这里服务而不重写现有应用程序。 最后，我们将做一些测试来测试性能，并检测这种日志会减慢应用程序的速度。

注释： 本文是
HubLink 项目的acestor 。 我们将"将收集作为服务进行收集"扩展到更广泛的"服务中心"概念，该概念允许将公共特性委托给这个外部系统。

要求

因为日志通常是密集的，所以我们期望大量的调用对我们的服务。 这意味着每次调用都是调用应用程序的成本，并且这种成本必须尽可能低的维护，以获得良好的性能。 报告可以通过引入一些缓冲系统( 。nlog记录器中的缓冲区) 来实现，避免了大量的请求和后台请求。 此外，我们还必须在服务上保持低响应时间。 同时，在客户端引入缓冲区，在服务器端实现更好的性能，引入队列来提高响应速度。 通过这种方式，请求将被尽快处理，只需将原始请求放入内存队列中，然后将有一个后台作业，该作业将对项目进行排队，并将。

构架

简单来说，这是一个公开 Web服务 以收集数据的web应用程序，这是一个文档化。 我们通过堆栈构建这个应用程序：

ASP.NET 5
Hangfire
yf_terminology_NHibernate@#@#@#NHibernate_yf_terminology
宋体
.NET 框架 4.5



这里不是解释如何构建应用程序的地方，所以我们只限于展示最重要的部分。

Web API ( 数据收集): 应用程序的这一部分公开了允许远程应用程序发送日志的REST接口。 这是使用 ASP.NET API框架实现的，并支持json或者XML输入格式。
WEB UI ( MVC 5 ): 这是用户可以搜索日志并管理应用程序设置或者用户的"网站"。
后台作业: 为了保持这个简单，我们将这个部分放在 ASP.NET 应用程序中。 这里有一些暗示恢复,但使用强大的hangfire库,我们可以解决大多数问题航运( 否则我们必须部署一个服务，一个计划任务或者类似的东西) web应用程序的所有功能。

yf_terminology_Web API@#@#@#Web API_yf_terminology

提供了将日志信息发送到这里应用程序的REST API 。 实际上，这部分是一个 ASP.NET Web API 应用程序，因此我们从序列化实现( 这个例子中的json或者 XML ) 继承了一些很酷的东西，比如 API 。

在下面的图中，我们解释用于存储日志的流。 客户端调用到WebApi控制器，这只是把它放在一个队列中，然后一个后台作业将持久化到 db 。

NLog目标

在前一节中，我解释了如何创建一个web应用程序并使用它收集数据是很简单的。 无论如何，我们需要有人生成这个日志，而这不会完成重写应用程序，只是改变日志记录程序。 使用log4net或者NLog系统，这是可能的，这是我推荐的方式。

在这个例子中，我实现了一个简单的

NLog

记录器。 为此，我们只需要实现一个类，如下所示：

namespace NLog.WebLog

{

[Target("WebTarget")]

public class WebTarget : TargetWithLayout

{

public WebTarget()

{

this.Destination = "localhost";

}

public WebTarget(String Destination)

{

this.Destination = Destination;

}

[RequiredParameter]

public string Destination { get; set; }

protected override void Write(LogEventInfo logEvent)

{

//Get the log message from base type

string logMessage = this.Layout.Render(logEvent);

//create a new entry to send

LogEntry entry = new LogEntry();

entry.Message = logMessage;

//... fill more data

entry.SourceDate = DateTime.Now;

//Make the request

DoRequest(Destination, JsonConvert.SerializeObject(entry));

}

}

Destination

是客户端配置( 请参见"上的REST端点集的完整url如何使用") 。 这一目标继承自

TargetWithLayout

类,所以我们有一个已经格式化的消息,在配置
web.config 或 app.config 。

如何使用

这个远程日志系统的使用非常简单，一旦你在服务器上安装了一个web应用程序并配置了它，你就需要将它集成。 如果你使用的是

NLog

或者

log4net

这样的标准库，那么这是非常简单的。 在这个演示中，我们实现了一个

NLog

目标，它将缓冲日志写入服务器。 你只需将这里配置放置在
web.config 或者app配置上。

下面，你可以找到

NLog

库的示例，请参见源代码中的

TestApp

示例以清除任何混淆。

<nlog xm
4000
lns="http://www.nlog-project.org/schemas/NLog.xsd"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" throwExceptions="true" >

<extensions>

<add assembly="NLog.WebLog"/>

</extensions>

<targets>

<target name="f1" xsi:type="File" fileName=".testlog.txt"/>

<!-- registering a new target for logs-->

<target name="wlog.logger" xsi:type="WebTarget"

destination="http://localhost:55044/api/log"

layout="${longdate}|${level:uppercase=true}|${logger}|${message}"  />

</targets>

<rules>

<!-- you can just log everything and then set retention or display policy on remote environment-->

<logger name="*" minlevel="Trace" writeTo="wlog.logger"  />

</rules>

</nlog>

在这个示例中，我们只将所有内容记录到远程平台。 通常，这不是最佳做法，因为太多的日志难以管理，当你需要查找一些事件日志或者发现错误时，常常会浪费大量的磁盘空间。 使用一个能提供强大过滤系统的远程平台，这些问题变得不那么重要。 你需要记住的唯一方面是性能： 我们要么使用一个批量日志系统最小化网络开销，要么延迟写入，"日志太多"意味着"慢速"无论如何都是。

将所有内容记录到远程系统之后，稍后再进行过滤，似乎是一种幼稚的方法，但忘记了在远程环境中的性能问题，而忘记了在远程环境中快速处理日志的开发人员，而不需要访问生产环境。

性能测试

由于我们的工作场所，我们设计了这个应用程序，。 总之，在我们的工作中，好的意图是不够的，所以我们也产生了一组测试来证明达到了性能目标。

下面的表显示了我们本地环境( i5四核内核 1.86 GHz+8GB RAM+高清 SSD ) 中的测试结果。 这个测试包含在源代码中，所以你只需运行它来检查这些测试，无论如何，我期望在大多数环境中都有类似的结果。

*Buffer 设置为：缓冲区size=1000元素；刷新超时： 160 ；#logFile

时间( ms ) WLog

时间( ms ) Wlog+Buffer*

时间( ms ) 110100100010000

4.64	8.7	10.7
4.13	6.22	0.005
4.44	6.25	0.005
5.91	4.17	3.83
8.99	5.73	7.88

测试 1: 在同一机器上的网络服务器和客户端，没有假定网络延迟
在第一个测试中,我们看到一个低差异文件编写和wlog写没有缓冲,只是因为我们没有网络过载( 或者可以忽略) 和客户端日志实现异步技术,保持低对性能的影响。 引入缓冲区可以提高性能，而缓冲区的缓冲时间又不会影响用户。 实际上，我们使用的是 1000个元素的缓冲区，每分钟刷新一分钟，所以每分钟发送一次小于 500的日志，所以当我们发送到最重的负载时，调用方会付出刷新的代价，这样一来，调用方就会。 true, 我们可以应用一些优化日志文件做wlog目标,但在实践中,大多数的系统使用日志使用默认配置,我们可以假定我们可以使用这样的解决方案在不影响性能。

#logFile

时间( ms ) WLog*

时间( ms ) Wlog+Buffer*

时间( ms ) 10100100010000

3	5	6
3	5	6
3	5	6
3	5	6

测试 2: 客户端调用远程服务器承载网络应用程序。
在第二个( 更真实) 案例中，缓冲和未缓冲案例之间的区别变得相关，缓冲的好处也。 不过，性能差异对于大多数应用程序来说是可以接受的。

那么网络延迟？ 网络延迟可能取决于许多因素，如跳数。距离。介质质量。等等，但要记住，使用异步方法时，这种延迟不会直接影响性能。 从服务器在局域网环境中进行的测试，在本地安装服务器时没有有意义的区别。

yf_terminology_Points of Interest@#@#@#兴趣点_yf_terminology

在本文中，我们将介绍如何构建简单的远程日志平台以及如何在实践中集成它。 此外，我们还谈到了远程日志系统，解释了好处：

一个位置的所有应用程序日志
实时查看分布式环境中发生的情况
轻松搜索
无保留问题
轻松更改 alertevents，直接在网页上进行调整
没有安全问题：开发人员在浏览器中读取日志( 配置文件) 。
在实践中，使用这样的日志系统是不必要的，因为类似的结果是，只要简单地使用数据库日志记录程序或者其他hand-made解决方案，就可以简单地使用日志记录器。计划的复制。等等 等其他解决方案，这很重要。

我们知道这种平台并不是所有的玫瑰。 实际上，这些成本可以是每月费用，也可以是on-premises解决方案的硬件维护成本。 从我的经验来看，将在线解决方案的性能和成本与雇主的小时成本相比较，我发现SaaS解决方案非常方便。 当然，有人可能不相信这是远程发送他的数据，但我认为有不同种类的应用程序。

最后，但并非最不重要的是，关于这个项目的评论。 就像你所想象的，没有任何 true 理由来构建你自己的web日志收集器。 我解释了有多种外部工具可以集成。 但这不是一个商业项目。 它具有教学目的，允许我们提供关于日志( 传统方法)的反射，并生成一个简单但完整的web应用程序( 我们大部分的元素通常在业务应用程序中共享。)的示例。