.NET下日志系统的搭建——log4net+kafka+elk

.NET下日志系统的搭建——log4net+kafka+elk 前言

    我们公司的程序日志之前都是采用log4net记录文件日志的方式(有关log4net的简单使用可以看我另一篇博客),但是随着后来我们团队越来越大,项目也越来越大,我们的用户量也越来越多。慢慢系统就暴露了很多问题,这个时候我们的日志系统已经不能满足我们的要求。其主要有下面几个问题:

随着我们访问量的增加,我们的日志文件急剧增加

多且乱的文件日志,难以让我们对程序进行排错

文件日志的记录耗用我们应用服务器的资源,导致我们的应用服务器的处理用户请求的能力下降

我们的日志分布在多台应用服务器上,当程序遇到问题时,我们的程序员都需要找运维人员要日志,随着团队越来越大,问题越来越多,于是导致了程序员们排队找运维要日志,解决问题的速度急剧下降!

起初,用户量不大的时候,上面的问题还能容忍。但任何一种小问题都会在用户量访问量变大的时候急剧的放大。终于在几波推广活动的时候,很悲剧的我们又不得不每天深夜加班来为我们之前对这些问题的不重视来买单。于是,在推广活动结束之后,在我们的程序员得到一丝喘息的机会时,我决定来搭建一个我们自己的日志系统,改善我们的日志记录方式。根据以上问题分析我们的日志系统需要有以下几点要求:

日志的写入效率要高不能对应用服务器造成太大的影响

要将日志集中在一台服务器上(或一组)

提供一个方便检索分析的可视化页面(这个最重要,再也受不了每天找运维要日志,拿到一堆文件来分析的日子了!)

一开始想要借助log4net AdoAppender把我们的日志写到数据库里,然后我们开发一个相应的功能,来对我们的日志来进行查询和分析。但考虑到写入关系数据库的性能问题,就放弃了,但有一个替代方案,就是写入到Mongo中,这样就解决了提高了一定的性能。但也需要我们开发一个功能来查询分析。这个时候从网上找了许多方案:

//方案1:这是我们现有的方案,优点:简单 缺点:效率低,不易查询分析,难以排错... service-->log4net-->文件 //方案2:优点:简单、效率高、有一定的查询分析功能 缺点:增加mongodb,增加一定复杂性,查询分析功能弱,需要投入开发精力和时间 service-->log4net-->Mongo-->开发一个功能查询分析 //方案3:优点:性能很高,查询分析及其方便,不需要开发投入 缺点:提高了系统复杂度,需要进行大量的测试以保证其稳定性,运维需要对这些组件进行维护监控... service-->log4net-->kafka-->logstash-->elasticsearch-->kibana搜索展示 //其它方案 service-->log4net-->文件-->filebeat-->logstash-->elstaicsearch-->kibana service-->log4net-->文件-->filebeat-->elstaicsearch-->kibana service-->log4net-->文件-->logstash-->elstaicsearch-->kibana

最终和团队交流后决定采用方案2和方案3的结合,我增加了一个log4net for mongo的appender(这个appender,nuget上也有),另外我们的团队开发一个能支持简单查询搜索的功能。我同步来搭建方案3。关于方案2就不多介绍了,很简单。主要提一提方案3。

一. ELKB简介

Elastic Search: 从名称可以看出,Elastic Search 是用来进行搜索的,提供数据以及相应的配置信息(什么字段是什么数据类型,哪些字段可以检索等),然后你就可以自由地使用API搜索你的数据。

Logstash:。日志文件基本上都是每行一条,每一条里面有各种信息,这个软件的功能是将每条日志解析为各个字段。

Kibana:提供一套Web界面用来和 Elastic Search 进行交互,这样我们不用使用API来检索数据了,可以直接在 Kibana 中输入关键字,Kibana 会将返回的数据呈现给我们,当然,有很多漂亮的数据可视化图表可供选择。

Beats:安装在每台需要收集日志的服务器上,将日志发送给Logstash进行处理,所以Beats是一个“搬运工”,将你的日志搬运到日志收集服务器上。Beats分为很多种,每一种收集特定的信息。常用的是Filebeat,监听文件变化,传送文件内容。一般日志系统使用Filebeat就够了。

二. kafka简介 2.1 简介

kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者规模的网站中的所有动作流数据。这种动作(网页浏览,搜索和其他用户的行动)是在现代网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。

2.2 适用场景

Messaging
对于一些常规的消息系统,kafka是个不错的选择;partitons/replication和容错,可以使kafka具有良好的扩展性和性能优势.不过到目前为止,我们应该很清楚认识到,kafka并没有提供JMS中的"事务性""消息传输担保(消息确认机制)""消息分组"等企业级特性;kafka只能使用作为"常规"的消息系统,在一定程度上,尚未确保消息的发送与接收绝对可靠(比如,消息重发,消息发送丢失等)

Websit activity tracking
kafka可以作为"网站活性跟踪"的最佳工具;可以将网页/用户操作等信息发送到kafka中.并实时监控,或者离线统计分析等

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpfxww.html