当前位置:首页 > 数码 > .NET-下优秀的日志框架使用解析-Core (net向下兼容吗)

.NET-下优秀的日志框架使用解析-Core (net向下兼容吗)

admin3周前 (04-28)数码12

日志记录对于任何软件应用程序来说都是一项至关重要的任务。它使开发人员能够记录应用程序的行为,以便在出现错误或问题时进行排查。

.NET Core 提供了丰富的日志框架生态系统,可让开发人员轻松地向其应用程序添加日志记录功能。本文将介绍五个优秀且广泛使用的 .NET Core 日志框架,并指导您如何使用它们。

1. Microsoft.Extensions.Logging

Microsoft.Extensions.Logging 是由 Microsoft 开发的官方 .NET Core 日志框架。它提供了一个强大且可扩展的 API,用于记录应用程序中的事件。它与 ASP.NET Core 和其他 Microsoft 库紧密集成,实现了开箱即用的日志记录。

使用 Microsoft.Extensions.Logging


using Microsoft.Extensions.Logging;

public class MyController
{
    private readonly ILogger _logger;

    public MyController(ILogger logger)
    {
        _logger = logger;
    }

    public IActionResult Index()
    {
        _logger.LogInformation("Index page loaded.");

        return View();
    }
}

2. Serilog

Serilog 是一个第三方日志框架,因其简单、灵活和高性能而广受欢迎。它提供了一个丰富的 API,用于格式化和记录日志消息,并支持多种目标,包括文件、控制台和数据库。

使用 Serilog

Core
using Serilog;
using Serilog.Core;
using Serilog.Formatting.Compact;
using Serilog.Sinks.File;

public class Program
{
    public static void Main(string[] args)
    {
        // 创建日志配置
        LoggerConfiguration config = new LoggerConfiguration()
            .Enrich.FromLogContext()
            .WriteTo.File(new CompactJsonFormatter(), "log.json");

        // 创建日志器
        ILogger logger = config.CreateLogger();

        // 记录日志消息
        logger.Information("Application started.");

        // ...

    }
}

3. NLog

NLog 是另一个流行的 .NET Core 日志框架,因其广泛的功能和可配置性而闻名。它支持多种日志级别、目标和布局,使您可以根据自己的需要定制日志记录行为。

使用 NLog


using NLog;

public class Program
{
    private static readonly Logger logger = LogManager.GetCurrentClassLogger();

    public static void Main(string[] args)
    {
        // 记录日志消息
        logger.Info("Application started.");

        // ...

    }
}

4. Log4Net

Log4Net 是一个成熟而广泛使用的 .NET 日志框架,它在 .NET Core 中也可用。它提供了一个灵活且强大的 API,用于配置日志记录行为,并支持各种附加组件,以扩展其功能。

使用 Log4Net


using log4net;

public class Program
{
    private static readonly ILog logger = LogManager.GetLogger(typeof(Program));

    public static void Main(string[] args)
    {
        // 记录日志消息
        logger.Info("Application started.");

        // ...

    }
}

5. Elk Stack

Elk Stack 是一个开源套件,它将 Elasticsearch、Logstash 和 Kibana 结合在一起,用于集中日志管理和分析。它允许您收集、处理和可视化来自不同来源的日志数据,从而实现对应用程序行为的深入见解。

使用 Elk Stack

使用 Elk Stack 进行日志记录需要进行更全面的配置和安装。请参考其官方文档以获取详细说明。

如何选择日志框架

选择的日志框架应取决于应用程序的具体要求。以下是一些考虑因素:

  • 功能:不同的日志框架提供不同的功能集。选择与应用程序需要相匹配的框架。
  • 性能:日志记录会对应用程序的性能产生影响。选择一个在不影响应用程序性能的情况下记录足够信息的框架。
  • 可扩展性:应用程序可能会随着时间的推移而发展。选择一个易于扩展和自定义的框架。
  • 社区支持:活跃的社区可以提供支持、文档和附加组件。

结论

日志记录是 .NET Core 应用程序的关键方面。通过使用合适的日志框架,开发人员可以轻松地跟踪应用程序的行为并诊断问题。本文中介绍的五个框架提供了各种功能和特性,以满足不同的需求。根据应用程序的特定要求做出明智的选择,并确保在程序入口处配置日志记录,以便在需要时记录必要的日志信息。


Spring Boot - 日志记录

Spring Boot 内部使用的日志框架为 Commons Logging ,但是 Commons Logging 的内部具体实现可以由用户自行指定。 默认已提供了对Java Utils Logging , Log4J2和Logback日志库的相关配置。 无论选择以上哪一个日记库,Spring Boot 都预置了将日志输出到控制台以及可选的文件上。

如果项目配置使用起步依赖(Starters),那么默认情况下,Spring Boot 使用的日记记录库为 Logback。

因此,本文主要介绍在 Spring Boot 中使用 Logback 进行日志记录。

前面已经介绍过,Spring Boot 默认使用的日志框架为Apache Commons Logging 。

在 Spring 4.x(也即Spring Boot 1.x )时,我们需要手动进行依赖导入。 但是在 Spring 5.x(也即Spring Boot 2.x )时,该依赖由 Spring Framework 模块 spring-jcl提供。

当我们项目使用各种起步依赖(Starter)时, spring-jcl模块包含在spring-boot-starter-logging中,理论上我们需要手动导入该依赖,如下所示:

但实际上我们无需手动导入该起步依赖,因为几乎每一个起步依赖(比如: spring-boot-starter , spring-boot-starter-web ...)都内置了spring-boot-starter-logging 。

因此,当我们使用起步依赖创建 Spring Boot 项目时,日志功能开箱即可用。 且日记框架内部默认实现采用 Logback。

还有其他一些设置日志级别的方法,这里就不展开阐述了。 更多内容可参考:Log Levels ,zero-configuration-logging

Spring Boot 支持多种不同的日志系统实现,可以通过导入相应的依赖库从而在运行时激活对应的日志系统,并且可以通过在 classpath 或 属性指定一个配置文件,实现自定义系统日志配置。

对于不同的日志系统,Spring Boot 会默认加载的日志配置文件如下表所示:

注 :Spring Boot 建议我们使用带有 -spring 后缀的作为日志配置文件名称(即相较于使用 ,更建议使用 )。 如果使用标准配置路径,Spring 无法完全控制日志初始化过程(因为 的加载时间非常早,导致一些扩展功能无法在其内进行配置,而此时使用 即可解决这个问题)。

我们主要关注的是 Logback 的配置文件内容。

要对 Logback 添加配置文件,只需创建 resources/ ,然后对该文件进行配置即可,其基本配置内容如下:

注 :日志配置文件路径也可以在 中进行指定:

简单对上述的配置内容进行一些介绍:

更多 Logback 配置文件内容,请参考:A Guide To Logback

可以通过在日志配置文件中使用标签 <springProfile> 来创建不同的环境日志配置。

比如,我们可以通过定义生产环境 prod ,测试环境 test 和开发环境 dev 来实现不同的日志输出,如下所示:

然后,启动服务的时候,设置相应环境的 profile 即可。 比如,可以直接通过命令指定运行环境 profile,如下:

Spring Boot 多环境配置内容,可参考:Spring Boot - 多环境配置

SpringBoot接入轻量级分布式日志框架(GrayLog)

在文章正式开始之前,我分享下我以前负责过的一个系统,它的架构如下:

每次当我查问题的时候,我都能把问题初步定位在 逻辑层,但为了能给业务方交代,我需要 给证据业务方面(日志信息就是铁证)。

一个请求肯定是被这8台机器内的某一台处理,但具体是哪一台,我不知道。所以,我需要上每台机器上 grep一把日志,然后才能找出对应的日志证明我的分析。

有的时候,可能 接入层也需要一起参与进去,就排查一个问题,人都傻了了(翻看日志的时间占用了太久了)。

后来啊,看了同事的骚操作(在 item2编写脚本:快速登录堡垒机 (免去输入账号和密码信息),根据应用服务器数量来切割窗口并且切换到对应的日志目录)。说白了就是一键登录 多台应用服务器。嗯,这查日志的速度比起以前又快了好多。

再后来,公司运维侧又主力推在 Web页面上登录应用服务器( 自动登录堡垒机),这能省去编写脚本( 支持批量操作)。但从当时的体验上,没有问题 item2访问得流畅(总感觉卡卡的)。

不过还有问题,因为我们在很多时候是不知道在 info/warn/error哪个文件下。很多时候只能一个一个文件去查,虽然说可以直接查通配符 一把查,如果日志过大,带来停顿时间也挺烦的。

系统一旦被问到业务问题,查日志的频率实在是太高了。于是我在某个Q规划的时候是想自己把日志信息写入到 搜索引擎,顺便学习下搜索引擎的知识。然后这个规划被组内的某个大佬看到了,在底下评论: 要不来试试Graylog?

原来组内本身就在维护了一个 日志框架,只是我不知道...于是我接入了 Graylog日志,工作效率杠杠提高了,凭借这个事情吹了一个Q 。

自从接入了之后,我就没登录过应用服务器了,有次差点连 grep都不会写了。

说起ELK,即便没用过肯定也听说过这玩意了,在后端是真的流行。这次austin接入一个比较轻量级的ELK框架: Graylog

这个框架我感觉蛮好用的,作为 使用方接入起来 异常简单(我估摸运维应该也挺简单的,很多用Graylog是直接发UDP到Server,不用在机器上装agent收集日志)

官方文档:

据我了解,有相当多的企业使用它来 查看日志和业务监控告警,这篇文章我就直接让你们体验体验吧。

老样子,直接上docker-compose,如果一直跟着我的步伐,应该对着不陌生了。 的内容其实我也是抄官网的,这里还是贴下吧(就不用你们翻了)

这个文件里唯一需要改动的就是 ip(本来的端口是9000的,我由于已经占用了9000端口了,所以我这里把端口改成了9009,你们可以随意)

嗯,写完 文件,直接docker-compose up -d它就启动起来咯。

启动以后,我们就可以通过 ip:port访问对应的Graylog后台地址了,默认的账号和密码是admin/admin

随后,我们配置下 inputs的配置,找到GELF UDP,然后点击Launch new input,只需要填写Title字段,保存就完事了(其他不用动)。

嗯,到这里,我们的GrayLog设置就完成了。

还记得我们 austin项目使用的日志框架吗?没错,就是logback。我们要把日志数据写入Graylog很简单,只需要两步:

1、引入依赖:

2、在 配置graylog相关的信息:

在这个配置信息里,唯一要改的也只是 ip的地址,到这里接入就完毕了,我们再打开控制台,就能看到日志的信息啦。

懂点GrayLog查询语法:这块我日常来来去去其实就用几个,我来展示下我平时用的吧。如果觉得不够,再去官网文档捞一把就完事了:

1、根据字段精确查询: full_messag

2、查询错误日志信息: level_name:ERROR

3、组合多字段查询: level_name:INFO AND full_messag

在接入的时候,仔细的小伙伴可能会发现我这边在Input的时候选择的是 GELF,然后在引入Maven依赖的时候也有GELF的字样。那GELF是啥意思呢?

这块在官网也有给出对应的解释: The Graylog Extended Log Format (GELF) is a log format that avoids the shortcomings of classic plain syslog

详细资料:

GELF是一种日志格式,能避免传统意义上的syslogs的一些问题,而我们引入的Maven依赖则是把日志格式化成GELF格式然后append到GrayLog上。

前几天有个老哥在GitHub给我提了个 pull request关于swagger的,我昨天把他merge了,也升级了下swagger的版本。

之前我没用过 swagger类似的文档工具,就这次pull request我也去体验了下swagger。

在初次的体验感觉是不错的:它能把项目的所有接口的 文档信息都能在一个页面上 统一管理,并且就能直接通过 样例参数直接发送请求。通过注解的方式来进行编写文档,也不用担心代码改了然后忘了更新文档这事。

但是,后来我配置好对应的参数信息文档,再在 swagger-ui体验了下,发现是真滴丑 ,看到这ui我还是阶段性放弃吧。

swagger的竞品还有好几个,我看ui貌似都要比swagger好看。不过,austin项目的主要接口就只有一个 ,我作为熟练掌握的markdown工程师能轻松胜任文档工作,就没再继续体验别的竞品了。

免责声明:本文转载或采集自网络,版权归原作者所有。本网站刊发此文旨在传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及版权、内容等问题,请联系本网,我们将在第一时间删除。同时,本网站不对所刊发内容的准确性、真实性、完整性、及时性、原创性等进行保证,请读者仅作参考,并请自行核实相关内容。对于因使用或依赖本文内容所产生的任何直接或间接损失,本网站不承担任何责任。

标签: .net