.NET下日志系统的搭建——log4net+kafka+elk#
前言#
咱们公司的程序日志以前都是采用log4net记录文件日志的方式(有关log4net的简单使用能够看我另外一篇博客)，可是随着后来咱们团队愈来愈大，项目也愈来愈大，咱们的用户量也愈来愈多。慢慢系统就暴露了不少问题，这个时候咱们的日志系统已经不能知足咱们的要求。其主要有下面几个问题:html
- 随着咱们访问量的增长，咱们的日志文件急剧增长
- 多且乱的文件日志，难以让咱们对程序进行排错
- 文件日志的记录耗用咱们应用服务器的资源，致使咱们的应用服务器的处理用户请求的能力降低
- 咱们的日志分布在多台应用服务器上，当程序遇到问题时，咱们的程序员都须要找运维人员要日志，随着团队愈来愈大，问题愈来愈多，因而致使了程序员们排队找运维要日志，解决问题的速度急剧降低！
起初，用户量不大的时候，上面的问题还能容忍。但任何一种小问题都会在用户量访问量变大的时候急剧的放大。终于在几波推广活动的时候，很悲剧的咱们又不得不天天深夜加班来为咱们以前对这些问题的不重视来买单。因而，在推广活动结束以后，在咱们的程序员获得一丝喘息的机会时，我决定来搭建一个咱们本身的日志系统，改善咱们的日志记录方式。根据以上问题分析咱们的日志系统须要有如下几点要求：java
- 日志的写入效率要高不能对应用服务器形成太大的影响
- 要将日志集中在一台服务器上(或一组)
- 提供一个方便检索分析的可视化页面(这个最重要，再也受不了天天找运维要日志，拿到一堆文件来分析的日子了！)
一开始想要借助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。mongodb
一. ELKB简介#
- Elastic Search: 从名称能够看出，Elastic Search 是用来进行搜索的，提供数据以及相应的配置信息（什么字段是什么数据类型，哪些字段能够检索等），而后你就能够自由地使用API搜索你的数据。
- Logstash：。日志文件基本上都是每行一条，每一条里面有各类信息，这个软件的功能是将每条日志解析为各个字段。
- Kibana：提供一套Web界面用来和 Elastic Search 进行交互，这样咱们不用使用API来检索数据了，能够直接在 Kibana 中输入关键字，Kibana 会将返回的数据呈现给咱们，固然，有不少漂亮的数据可视化图表可供选择。
- Beats：安装在每台须要收集日志的服务器上，将日志发送给Logstash进行处理，因此Beats是一个“搬运工”，将你的日志搬运到日志收集服务器上。Beats分为不少种，每一种收集特定的信息。经常使用的是Filebeat，监听文件变化，传送文件内容。通常日志系统使用Filebeat就够了。
二. kafka简介#
2.1 简介#
kafka是一种高吞吐量的分布式发布订阅消息系统，它能够处理消费者规模的网站中的全部动做流数据。这种动做（网页浏览，搜索和其余用户的行动）是在现代网络上的许多社会功能的一个关键因素。这些数据一般是因为吞吐量的要求而经过处理日志和日志聚合来解决。docker
2.2 适用场景#
-
Messaging
对于一些常规的消息系统,kafka是个不错的选择;partitons/replication和容错,可使kafka具备良好的扩展性和性能优点.不过到目前为止,咱们应该很清楚认识到,kafka并无提供JMS中的"事务性""消息传输担保(消息确认机制)""消息分组"等企业级特性;kafka只能使用做为"常规"的消息系统,在必定程度上,还没有确保消息的发送与接收绝对可靠(好比,消息重发,消息发送丢失等)数据库 -
Websit activity tracking
kafka能够做为"网站活性跟踪"的最佳工具;能够将网页/用户操做等信息发送到kafka中.并实时监控,或者离线统计分析等json -
Log Aggregation
kafka的特性决定它很是适合做为"日志收集中心";application能够将操做日志"批量""异步"的发送到kafka集群中,而不是保存在本地或者DB中;kafka能够批量提交消息/压缩消息等,这对producer端而言,几乎感受不到性能的开支.此时consumer端可使hadoop等其余系统化的存储和分析系统.bootstrap
3、log4net+ELK+Kafka日志系统#
3.1.简介#
从上咱们能够了解到，咱们能够增长一个log4net kafkaappender 日志生产者经过这个appender将日志写入kafka，因为kafka批量提交、压缩的特性，所以对咱们的应用服务器性能的开支很小。日志消费者端使用logstash订阅kafka中的消息，传送到elasticsearch中，经过kibana展现给咱们。同时咱们也能够经过kibana对咱们的日志进行统计分析等。恰好能够解决咱们上面的一些问题。整个流程大体以下图:浏览器
关于log4net for kafka appender，我本身写了一个，nuget上也有现成的包，你们须要能够去nuget上找一找。
3.2.搭建#
简单介绍一下搭建，搭建过程当中采用Docker。
3.2.1 docker 安装kafka#
//下载 //下载zookeeper docker pull wurstmeister/zookeeper //下载kafka docker pull wurstmeister/kafka:2.11-0.11.0.3
//启动 //启动zookeeper docker run -d --name zookeeper --publish 2181:2181 --volume /etc/localtime:/etc/localtime wurstmeister/zookeeper //启动kafka docker run -d --name kafka --publish 9092:9092 \ --link zookeeper \ --env KAFKA_ZOOKEEPER_CONNECT=192.168.121.205:2181 \ --env KAFKA_ADVERTISED_HOST_NAME=192.168.121.205 \ --env KAFKA_ADVERTISED_PORT=9092 \ --volume /etc/localtime:/etc/localtime \ wurstmeister/kafka:2.11-0.11.0.3
//测试 //建立topic bin/kafka-topics.sh --create --zookeeper 192.168.121.205:2181 --replication-factor 1 --partitions 1 --topic mykafka //查看topic bin/kafka-topics.sh --list --zookeeper 192.168.121.205:2181 //建立生产者 bin/kafka-console-producer.sh --broker-list 192.168.121.205:9092 --topic mykafka //建立消费者 bin/kafka-console-consumer.sh --zookeeper 192.168.121.205:2181 --topic mykafka --from-beginning
3.2.2 Docker安装ELK#
//1.下载elk docker pull sebp/elk
//2.启动elk //Elasticsearch至少须要单独2G的内存 //增长了一个volume绑定，以避免重启container之后ES的数据丢失 docker run -d -p 5044:5044 -p 127.0.0.1:5601:5601 -p 127.0.0.1:9200:9200 -p 127.0.0.1:9300:9300 -v /var/data/elk:/var/lib/elasticsearch --name=elk sebp/elk
//若启动过程出错通常是由于elasticsearch用户拥有的内存权限过小，至少须要262144 切换到root用户 执行命令： sysctl -w vm.max_map_count=262144 查看结果： sysctl -a|grep vm.max_map_count 显示： vm.max_map_count = 262144
上述方法修改以后，若是重启虚拟机将失效，因此：
解决办法：
在 /etc/sysctl.conf文件最后添加一行 vm.max_map_count=262144 便可永久修改
启动成功以后访问：http://:5601 看到kibana页面则说明安装成功
配置使用
//进入容器 docker exec -it <container-name> /bin/bash
//执行命令 /opt/logstash/bin/logstash -e 'input { stdin { } } output { elasticsearch { hosts => ["localhost"] } }' /* 注意：若是看到这样的报错信息 Logstash could not be started because there is already another instance using the configured data directory. If you wish to run multiple instances, you must change the "path.data" setting. 请执行命令：service logstash stop 而后在执行就能够了。 */
测试
当命令成功被执行后，看到：Successfully started Logstash API endpoint {:port=>9600} 信息后，输入：this is a dummy entry 而后回车，模拟一条日志进行测试。
打开浏览器，输入：http://:9200/_search?pretty 如图，就会看到咱们刚刚输入的日志内容。
3.2.3 logstash-kafka配置实例#
这是我测试用的一个配置文件。
input {
kafka{
//此处注意:logstash5.x版本之前kafka插件配置的是zookeeper地址，5.x之后配置的是kafka实例地址 bootstrap_servers =>["192.168.121.205:9092"] client_id => "test" group_id => "test" consumer_threads => 5 decorate_events => true topics => "logstash" } } filter{ json{ source => "message" } } output { elasticsearch { hosts => ["192.168.121.205"] index=> "hslog_2" codec => "json" } }
配置文件启动logstash方式
/opt/logstash/bin/logstash -f "配置文件地址"
结束语#
如上，咱们的日志系统基本搭建完毕，固然还有不少关于kafka,logstash,elstaicsearch,kibana的使用，以及咱们使用的一些问题，你们本身尝试着搭建一下。固然，没有最好的方案，建议你们结合本身公司和系统的现实状况，寻找和选择解决方案。能用简单的方案解决问题，就不要使用复杂的方案。由于复杂的方案在解决问题的同时，也会给咱们带来其余的问题。就像咱们这个方案，虽然解决了咱们当时的问题，可是也增长了咱们系统的复杂度，例如:这其中的每个组件出了问题，都将致使咱们的日志系统不可用......,此外，工欲善其事必先利其器，咱们虽然解决了器的问题，可是要想"善咱们的事"还有很长的路要走，由于究其根本，日志记不记录，在什么地方记录，记录什么等级的日志，仍是由咱们选择去记录。日志记录无规范、乱记、瞎记，如何规范日志的记录才是是咱们接下来要解决的大问题！欢迎你们留言，探讨这些问题！