一套标准的ASP.NET Core容器化应用日志收集分析方案

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 本文记录一套标准的、无侵入的的容器化应用日志收集方案:

本文记录一套标准的、无侵入的的容器化应用日志收集方案:


  1. 什么样的日志应该被收集?


  1. 如何输出为结构化日志?


  1. 使用EFK无侵入的收集分析日志


100ce73ebc1853d90f3d9a665610e8fb.png


定制ASP.NET Core日志;       将结构化日志输出到stdout;

                       

Fluentbit无侵入式转发容器日志;    存储在Es并在Kibana上分析日志。


定制ASP.NET Core日志


面向互联网的经典应用,不外乎三部分日志:请求、业务处理、数据库操作。

在实际采集日志时,关注[特定日志场景]:


  • 提供给第三方调用的API(👃有撕逼可能性)


  • 核心流程业务 (👃996排障)


  • 数据库操作(👃删库跑路可能性)


  • 应用内部发起的Http请求 (👃联调撕逼)


  • Warn、Error、Fatal级别日志(👃持续关注)


ASP.NETCore灵活的配置系统、可插拔的组件系统,让我们轻松配置日志、管理日志组件。


日志采集策略


ASP.NET Core应用的日志配置取决于appsettings.{Environment}.json文件的Logging配置节


支持多个LogProvider、过滤日志、定制特定种类日志的收集级别。


"Logging": {
    "LogLevel": {
      "Microsoft": "Warning",
      "Microsoft.AspNetCore.Hosting.Diagnostics": "Information",    // 提供给第三方调用API日志
      "Microsoft.Hosting.Lifetime": "Information",
      "Microsoft.EntityFrameworkCore.Database.Command": "Information",  //数据库操作sql日志
      "System.Net.Http.HttpClient": "Information",    // 应用内部发起的Http请求日志
      "Default": "Warning"    // 除以上日志之外,记录Warning+级别日志
    }
  }


以上Logging配置针对[特定日志场景],满足经典互联网应用的日志采集需求。


NLog Provider


结构化日志提出[MessageTemplate]来解决传统文本日志对机器不友好的问题。


① 这里使用NLog Provider接管所有的日志输出


// Please  install-package NLog.Web.AspNetCore
internal static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
              .ConfigureLogging((hostBuilder, loggerBuilder) =>
              {
                  loggerBuilder.ClearProviders();
                  loggerBuilder.AddNLog("nlog.production.config");
              })
              .ConfigureWebHostDefaults(webBuilder =>
              {
                  webBuilder.UseStartup<Startup>();
              });


② 编写NLog[JsonLayout]将传统文本日志转换为JSON格式日志:


<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" autoReload="true" internalLogFile="logs/nlog-internal.log" internalLogLevel="Info" >
  <targets async="true">
    <target name="console" xsi:type="Console">
      <layout xsi:type="JsonLayout" includeAllProperties="true" excludeProperties="EventId_Id,EventId_Name,EventId">
        <attribute name="time" layout="${date:format=yyyy/MM/dd HH\:mm\:ss.fff zzz}" />
        <attribute name="category" layout="${logger}" />
        <attribute name="log_level" layout="${level:lowerCase=true}" />
        <attribute name="message" layout="${message}" />
        <attribute name="trace_id" layout="${aspnet-TraceIdentifier:ignoreActivityId=true}" />
        <attribute name="user_id" layout="${aspnet-user-identity}" />
        <attribute name="exception" layout="${exception:format=tostring}" />
      </layout>
    </target>
  </targets>
  <rules>
    <logger name="*" minlevel="Info" writeTo="console"   ruleName="console" />
  </rules>
</nlog>


与业务紧密相关的日志字符:


  • includeAllProperties="true"  输出日志条目的所有属性


  • trace_id=${aspnet-TraceIdentifier:ignoreActivityId=true}  取得trace_id,排障时很有用


  • user_id=${aspnet-user-identity}  取得该条日志生产者的名字

启动应用日志长这样:


176fd20148fa1899be98224ae7c5cb9a.png


请保持所有应用日志的输出目标为stdout,让Fluent-bit无侵入采集!


....【TODO: 容器制作镜像!!!!】 ...


Fluent-Bit收集容器日志


Fluent-bit采集日志,小巧够用!


采集容器日志需要将容器应用的Logging Driver改为[Fluentd]

Fluentd Driver默认会在宿主机24224端口监听Forward消息 。


一个简单的容器Docker-compose示例:


version: "3.7"
services:
  website:
    image: ${DOCKER_REGISTRY}/eap/website:0.1
    ports:
      - "80:80"
    environment:
      - TZ=Asia/Shanghai
    networks:
      - webnet
    logging:
      driver: fluentd
      options:
#       fluentd-address: localhost:24224
        tag: eap-website
    restart: always
networks:
  webnet:
    external: true
    name: eap-net


Fluentd Driver采集的格式如下 :


{
"container_id": "...",
"container_name": "...",
"source": "stdout",
"log": "This is log content"
}


容器应用产生的json日志(log字段)会被编码,这就很尴尬了,处心积虑的结构化日志没

有萃取出日志字段!!


e34a18ba5128acea1406053d3f1d37a8.png


多番搜索,在Fluentbit上找到Decoders 插件, 能将被编码的JSON字符串解码:

完整的fluent-bit.conf 如下:


[SERVICE]
    flush            1
    log_Level        info
    daemon           off
    http_server      on    // 在宿主机作为http server启动
    http_listen      0.0.0.0
    http_port        2020
    storage.metrics  on
    Parsers_File     parsers.conf
[INPUT]
    name             forward
    max_chunk_size   1M
    max_buffer_size  5M
[FILTER]
    Name  parser
    Match *
    Key_Name log            // 要解析的字段
    Parser  docker          // 以docker日志格式解析,内容在parser.conf文件
    Preserve_Key   True     // 保留原解析的字段
    Reserve_Data   True     // 保留原始其他字段
[OUTPUT]
    name             es
    match            *
    host             es01
    port             9200
    logstash_format  on
    replace_dots     on
    retry_limit      false


这样输出的结果就是:


d69d2c0392fe449407b2b1da598e18de.png


nice,后面就请自由在Kibana中分析日志吧。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
1月前
|
存储 开发框架 JSON
ASP.NET Core OData 9 正式发布
【10月更文挑战第8天】Microsoft 在 2024 年 8 月 30 日宣布推出 ASP.NET Core OData 9,此版本与 .NET 8 的 OData 库保持一致,改进了数据编码以符合 OData 规范,并放弃了对旧版 .NET Framework 的支持,仅支持 .NET 8 及更高版本。新版本引入了更快的 JSON 编写器 `System.Text.UTF8JsonWriter`,优化了内存使用和序列化速度。
|
15天前
|
开发框架 监控 .NET
【Azure App Service】部署在App Service上的.NET应用内存消耗不能超过2GB的情况分析
x64 dotnet runtime is not installed on the app service by default. Since we had the app service running in x64, it was proxying the request to a 32 bit dotnet process which was throwing an OutOfMemoryException with requests >100MB. It worked on the IaaS servers because we had the x64 runtime install
|
13天前
Visual Studio 快速分析 .NET Dump 文件
【11月更文挑战第10天】.NET Dump 文件是在 .NET 应用程序崩溃或出现问题时生成的,记录了应用程序的状态,包括内存对象、线程栈和模块信息。通过分析这些文件,开发人员可以定位和解决内存泄漏、死锁等问题。在 Visual Studio 中,可以通过调试工具、内存分析工具和符号加载等功能来详细分析 Dump 文件。此外,还可以使用第三方工具如 WinDbg 进行更深入的分析。
|
19天前
|
存储 SQL 监控
|
19天前
|
运维 监控 安全
|
22天前
|
监控 关系型数据库 MySQL
分析慢查询日志
【10月更文挑战第29天】分析慢查询日志
37 3
|
22天前
|
监控 关系型数据库 数据库
怎样分析慢查询日志?
【10月更文挑战第29天】怎样分析慢查询日志?
34 2
|
1月前
|
存储 缓存 关系型数据库
MySQL事务日志-Redo Log工作原理分析
事务的隔离性和原子性分别通过锁和事务日志实现,而持久性则依赖于事务日志中的`Redo Log`。在MySQL中,`Redo Log`确保已提交事务的数据能持久保存,即使系统崩溃也能通过重做日志恢复数据。其工作原理是记录数据在内存中的更改,待事务提交时写入磁盘。此外,`Redo Log`采用简单的物理日志格式和高效的顺序IO,确保快速提交。通过不同的落盘策略,可在性能和安全性之间做出权衡。
1646 14
|
1月前
|
存储 消息中间件 大数据
大数据-69 Kafka 高级特性 物理存储 实机查看分析 日志存储一篇详解
大数据-69 Kafka 高级特性 物理存储 实机查看分析 日志存储一篇详解
39 4
|
1月前
|
SQL 分布式计算 Hadoop
Hadoop-19 Flume Agent批量采集数据到HDFS集群 监听Hive的日志 操作则把记录写入到HDFS 方便后续分析
Hadoop-19 Flume Agent批量采集数据到HDFS集群 监听Hive的日志 操作则把记录写入到HDFS 方便后续分析
47 2
下一篇
无影云桌面