微服务日志之.NET Core使用NLog通过Kafka实现日志收集

一、前言

NET Core越来越受欢迎,因为它具有在多个平台上运行的原始.NET Framework的强大功能。Kafka正迅速成为软件行业的标准消息传递技术。这篇文章简单介绍了如何使用.NET(Core)和Kafka实现NLog的Target。

在日常项目开发过程中,Java体系下Spring Boot + Logback很容易就接入了Kafka实现了日志收集,在.NET和.NET Core下一直习惯了使用NLog作为日志组件。为了让微服务环境中dotnet和java的服务都统一的进行日志收集,接下来的文章中会介绍两种语言的统一接入方式。写这个组件的目地是让团队成员不需要编写NLog的JsonLayout从而达到与java服务输出一样格式到kafka的目地,简化开发人员的配置难度,当然代价就是配置不灵活了。

二、开源

通过实现NLog的Target,接入kafka将日志传输到Logstash的组件。

https://github.com/maxzhang1985/NLog.Kafka

三、使用

建立项目

NLog.Kafka组件支持.NET 4.5+和 NETStandard1.6+ ,所在可以在传统.NET使用,当然也支持.NET Core的跨平台使用(Win、Linux、Mac)。

项目引用

  • NLog 4.5.8
  • NLog.Kafka
  • librdkafka.redist

引用librdkafka.redist是因为使用了依赖库Confluent.Kafka 0.11.5,Confluent.Kafka 使用了著名的librdkafka开源库,它是用C ++编写的,作为其它的语言(如C ++,C#,Python和Node)的Kafka驱动程序的基础。

配置

在项目中建立NLog.config,并设置为Copy always,内容如下:

<?xml version="1.0" encoding="utf-8" ?>
<!--nlog 基础配置  第二行throwExceptions开始 上线后关闭-->
<nlog autoReload="true" xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  throwExceptions="true" throwConfigExceptions="true" internalLogLevel="Trace" >
  <!-- load NLog.Extended to enable ASP.NET-specific functionality -->
  <targets>
    <target name="queue" xsi:type="kafka" topic="loges" appname="nlogtest" includeMdc="true"  >
      <!-- bootstrap.servers = 127.0.0.1:9092,127.0.0.1:9092,127.0.0.1:9092 -->
      <producerConfig key="bootstrap.servers" value="127.0.0.1:9092" />
      <producerConfig key="queue.buffering.max.messages" value="2000000" />
      <producerConfig key="retry.backoff.ms" value="500" />
      <producerConfig key="message.send.max.retries" value="3" />
    </target>
  </targets>
  <rules>
    <logger name="*" writeTo="queue" />
  </rules>
</nlog>

编写测试代码

class Program
{
        static void Main(string[] args)
        {

            Logger logger = LogManager.GetCurrentClassLogger();

            MappedDiagnosticsContext.Set("item1", "haha");
            for(int i = 0; i < 10; i++)
            {
                logger.Info("hello world");
                Console.WriteLine("sended");
            }

            Console.ReadKey();
        }
}

Logstash配置

input {
    kafka {
       bootstrap_servers => "127.0.0.1:9092"
       group_id => "logstash"
       topics => "loges"
       codec => "json"
    }
}

output{
  elasticsearch {
        hosts => ["127.0.0.1:9002"]
        index => "log_{[appname]}_%{+YYYY.MM.dd}"

  }
  #stdout { codec => rubydebug }
}

四、最后

附上的Demo和开源库地址:https://github.com/maxzhang1985/NLog.Kafka

GitHub:https://github.com/maxzhang1985/YOYOFx 如果觉还可以请Star下, 欢迎一起交流。

.NET Core 开源学习群:214741894

我的博客即将搬运同步至腾讯云+社区,邀请大家一同入驻:https://cloud.tencent.com/developer/support-plan?invite_code=2j4ukgnjjum8o

分类: .NET Core.NET跨平台

标签: NLogKafka.NET Core

8

0

«上一篇: ASP.NET Core使用SkiaSharp实现验证码
»下一篇: 微服务日志之Spring Boot Kafka实现日志收集

原文地址:https://www.cnblogs.com/webenh/p/11605650.html

时间: 2024-08-28 03:07:02

微服务日志之.NET Core使用NLog通过Kafka实现日志收集的相关文章

.NET Core微服务之ASP.NET Core on Docker

Tip: 此篇已加入.NET Core微服务基础系列文章索引 一.Docker极简介绍 1.1 总体介绍 Docker 是一个开源的应用容器引擎,基于 Go 语言 并遵从Apache2.0协议开源.Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级.可移植的容器中,然后发布到任何流行的 Linux 机器上,也可以实现虚拟化.容器是完全使用沙箱机制,相互之间不会有任何接口(类似 iPhone 的 app),更重要的是容器性能开销极低. 简而言之> 容器是一个打包了应用服务的环境,它是一

浅谈微服务架构与.Net Core

微服务(microservice)这个概念是2012年出现的,2014年3月Martin Fowler在他的个人网站(https://martinfowler.com/articles/microservices.html)中是这样说到的: The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing softwar

(1).NET CORE微服务 Micro-Service ---- 什么是微服务架构,.netCore微服务选型

开发工具:VS2017 .Net Core 2.1 什么是微服务?单体结构: 缺点:1)只能采用同一种技术,很难用不同的语言或者语言不同版本开发不同模块:2)系统耦合性强,一旦其中一个模块有问题,整个系统就瘫痪了:一旦升级其中一个模块,整个系统就停机了:3)要上线必须一起上线,互相等待,无法快速响应需求:4)集群只能是复制整个系统,即使只是其中一个模块压力大: 微服务:不同模块放到不同的进程/服务器上,模块之间通过网络通讯进行协作.适用于:模块比较多,访问量比较大的互联网类系统,并不是所有项目都

微服务操作模型

这里并不是介绍微服务概念,如需要了解微服务,可以阅读Fowler-Microservices文章.本博客假定我们已开始使用微服务解耦单体应用,用来提升可部署性和可扩展性. 当我们在系统范围内部署大量的微服务时,一个新的挑战产生了,单体应用部署时不会发生.这篇文章将针对这些新的挑战,在系统范围内部署大量微服务时定义一套操作模型(operations model). 这篇文章分为如下几个部分: 前提条件: 扩展: 问题: 需要的组件: 参考模型: 下一步: 1. 前提条件 当在系统范围内需要部署大量

Health Check in eShop -- 解析微软微服务架构Demo(五)

引言 What is the Health Check Health Check(健康状态检查)不仅是对自己应用程序内部检测各个项目之间的健康状态(各项目的运行情况.项目之间的连接情况等),还包括了应用程序对外部或者第三方依赖库的状态检测. Why use Health Check 现在我们的项目越来越多的从单体多层架构转换成多项目多层架构即现在流行的微服务架构. 原来我们的App把各个模块分层分项目处理,比如Users项目仅仅处理User的一些业务需求,但在整个项目使用的时候,我们仅仅需要引用

基于容器与微服务架构的Web应用实践eShopOnContainers

微软官方提供了一个基于Docker和微服务的示例应用eShopOnContainers:它使用了面向服务的架构并且从服务端到客户端都是跨平台的:该架构使用通过http作为客户端与服务端直接的通信协议.多个微服务每个都有自己的db:另外主要使用的技术Docker.事件总线.DDD/CQRS. 开源项目地址: https://github.com/dotnet-architecture/eShopOnContainers 每个微服务都提供了一种实施方案: Identity微服务:使用了Identit

什么是微服务架构,.netCore微服务选型

什么是微服务架构,.netCore微服务选型 https://www.cnblogs.com/uglyman/p/9182485.html 开发工具:VS2017 .Net Core 2.1 什么是微服务? 单体结构: 缺点: 1)只能采用同一种技术,很难用不同的语言或者语言不同版本开发不同模块: 2)系统耦合性强,一旦其中一个模块有问题,整个系统就瘫痪了:一旦升级其中一个模块,整个系统就停机了: 3)要上线必须一起上线,互相等待,无法快速响应需求: 4)集群只能是复制整个系统,即使只是其中一个

微服务实战(四):落地微服务架构到直销系统(将生产者与消费者接入消息总线)

前一篇文章我们已经完成了基于RabbitMq实现的的消息总线,这篇文章就来看看生产者(订单微服务)与消费者(经销商微服务)如何接入消息总线实现消息的发送与消息的接收处理. 定义需要发送的消息: 下单消息要被发送到消息总线,并被经销商微服务的处理器处理.经销商微服务处理时,需要知道要对哪个经销商处理多少的PV值与电子币余额.这些信息就是事件消息需要承载的重要信息. public class OrderCreatedProcessDealerEvent:BaseEvent { public deci

自主搭建CI/CD,为vNext微服务开发保驾护航

简介 微服务开发中自动化.持续化工程十分重要,在成熟的CI/CD环境中项目团队可以灵活分配,大大提供团队效率.如果还不了解什么是CI/CD,可以先查看相关文章,这里主要介绍环境的搭建,相关原理就不过多搬书了. 开始之前 目前主流的ci/cd环境都是基于容器化管理的,所以想要搭建这一环境必须熟练docker操作.版本控制选择git,构建工具选择Jenkins,所以开始前需要先掌握这些技术. 安装docker Ubuntu 18.04 docker安装 docker安装方式有多种,存储库安装方式如下