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

讲故事

关注我公众号的朋友,应该知道我写了一些云原生应用日志收集/分析相关的文章,其中内容大多聚焦某个具体的组件:

  • 超级有用的TraceId,快点用起来吧!
  • 如何利用NLog输出结构化日志,并在Kibana优雅分析日志?
  • 既然能直接向ElasticSearch写日志,为什么还要logstash日志摄取器?

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

  1. 什么样的日志应该被收集?
  2. 如何输出为结构化日志?
  3. 使用EFK无侵入的收集分析日志

定制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} 取得该条日志生产者的名字

启动应用日志长这样:

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

....【TODO: 制作Docker镜像!!!!】 ...

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                                        // 注意,这里需要指定使用 Fluentd 作为Logging Driver
      options:
#       fluentd-address: localhost:24224
        tag: eap-website
    restart: always
networks:
  webnet:
    external: true
    name: eap-net

请注意上面的app容器使用Fluentd作为 Logging Driver, 请给app容器添加适当的日志标签tag: eap-website, 这个标签在后面Fluent-bit过滤数据时会用到。

Fluentd Driver采集的格式如下 :

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

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

多番搜索,在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        // 加载用于Parser的文件
[INPUT]
    name             forward
    max_chunk_size   1M
    max_buffer_size  5M
[FILTER]                               // Filter Praser插件(docker)解码应用的json日志
    Name             parser            // 插件名称,某枚举值
    Match            eap-website       // 匹配什么tag的日志
    Key_Name         log               // 要解析的字段
    Parser           docker            // 以docker日志格式解析  [具体内容在在parser.conf文件】
    Preserve_Key     True              // 保留原解析的字段
    Reserve_Data     True              // 保留原始其他字段
[FILTER]                               // 这一部分是nginx容器日志
    Name             parser
    Match            eap-frontend      // Filter Praser插件(nginx)解析前端nginx日志
    Parser           nginx
    Key_Name         log
    Preserve_Key     True
    Reserve_Data     True

[OUTPUT]
    name             es
    match            *
    host             es01
    port             9200
    logstash_format  on
    replace_dots     on
    retry_limit      false

这样输出的结果就是:

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

完整的EFK收集容器日志的源码配置,github传送门:https://github.com/zaozaoniao/dockercompose-efk

这是一套完整的容器日志采集和分析方案: ①经典互联网应用的日志收集策略、②结构化输出、③无侵入式采集,提供github配置源码,可学习可商用。

原文地址:https://www.cnblogs.com/JulianHuang/p/14049455.html

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


引言 本文从Linux小白的视角, 在CentOS 7.x服务器上搭建一个Nginx-Powered AspNet Core Web准生产应用。 在开始之前,我们还是重温一下部署原理,正如你所常见的.Net Core 部署图: 在Linux上部署.Net Core App最好的方式是在Linux机器
引言: 多线程编程/异步编程非常复杂,有很多概念和工具需要去学习,贴心的.NET提供Task线程包装类和await/async异步编程语法糖简化了异步编程方式。 相信很多开发者都看到如下异步编程实践原则: 遵守以上冷冰冰的②③条的原则,可保证异步程序按照预期状态正常运作;我们在各大编程论坛常看到违背
一. 宏观概念 ASP.NET Core Middleware是在应用程序处理管道pipeline中用于处理请求和操作响应的组件。 每个组件是pipeline 中的一环。 自行决定是否将请求传递给下一个组件 在处理管道的下个组件执行之前和之后执行业务逻辑 二. 特性和行为 ASP.NET Core处
背景 在.Net和C#中运行异步代码相当简单,因为我们有时候需要取消正在进行的异步操作,通过本文,可以掌握 通过CancellationToken取消任务(包括non-cancellable任务)。 Task&#160;表示无返回值的异步操作, 泛型版本Task&lt;TResult&gt;表示有返
HTTP基本认证 在HTTP中,HTTP基本认证(Basic Authentication)是一种允许网页浏览器或其他客户端程序以(用户名:口令) 请求资源的身份验证方式,不要求cookie,session identifier、login page等标记或载体。 - 所有浏览器据支持HTTP基本认
1.Linq 执行多列排序 OrderBy的意义是按照指定顺序排序,连续两次OrderBy,后面一个有可能会打乱前面一个的排序顺序,可能与预期不符。 要实现sql中的order by word,name类似效果; LINQ 有ThenBy可以紧接使用, ThenBy记住原本排序的值,然后再排其他值,
ASP.NET Core 核心特性:开源、跨平台、高性能是其决战JAVA的必胜法宝,最引人关注的跨平台特性 到底是怎么实现? &#xA; 本文分Unix、Windows剖析跨平台内幕,读完让你大呼过瘾。
前导 Asynchronous programming Model(APM)异步编程模型以BeginMethod(...) 和 EndMethod(...)结对出现。 IAsyncResult BeginGetResponse(AsyncCallback callback, object state
引言 最近在公司开发了一个项目,项目部署架构图如下: 思路 如图中文本所述,公司大数据集群不允许直接访问外网,需要一个网关服务器代理请求,本处服务器A就是边缘代理服务器的作用。 通常技术人员最快捷的思路是在服务器A上部署IISʺpplication Request Routing Module组件
作为一枚后端程序狗,项目实践常遇到定时任务的工作,最容易想到的的思路就是利用Windows计划任务/wndows service程序/Crontab程序等主机方法在主机上部署定时任务程序/脚本。 但是很多时候,若使用的是共享主机或者受控主机,这些主机不允许你私自安装exe程序、Windows服务程序
引言 熟悉TPL Dataflow博文的朋友可能记得这是个单体程序,使用TPL Dataflow 处理工作流任务, 在使用Docker部署的过程中, 有一个问题一直无法回避: 在单体程序部署的瞬间(服务不可用)会有少量流量无法处理;更糟糕的情况下,迭代部署的这个版本有问题,上线后无法运作, 更多的流
合格的web后端程序员,除搬砖技能,还必须会给各种web服务器配置Https,本文结合ASP.NET Core部署模型聊一聊启用Https的方式。 温故知新 目前常见的Http请求明文传输,请求可能被篡改,访问的站点可能被伪造。 HTTPS是HTTP加上TLS/SSL协议构建的可进行加密传输、身份认
长话短说 前文《解剖HttpClientFactory,自由扩展HttpMessageHandler》主要讲如何为HttpClientFactory自定义HttpMessageHandler组件, 现在来完成课后的小作业: 将重点日志字段显示到Nlog的LayoutRenderer上。 本文实现一个
引言问题 作为资深老鸟,有事没事,出去面试;找准差距、定位价值。 面试必谈哈希, Q1:什么是哈希? Q2:哈希为什么快? Q3:你是怎么理解哈希算法利用空间换取时间的? Q4:你是怎么解决哈希冲突的? Q5:你有实际用写过哈希算法吗? 知识储备 哈希(也叫散列)是一种查找算法(可用于插入),哈希算
前言 如题,有感于博客园最近多次翻车,感觉像胡子眉毛一把抓, 定位不了生产环境的问题。 抛开流程问题,思考在生产环境中如何做故障排除,&#160;发现博客园里面这方面的文章比较少。 .Net 本身是提供了sos.dll工具帮助我们在生产中故障排除,通过提供有关内部公共语言运行时(CLR)环境的信息,
.NET程序是基于.NET Framework、.NET Core、Mono、【.NET实现】开发和运行的 ,定义以上【.NET实现】的标准规范称为.NET Standard .NET Standard .NET标准是一组API集合,由上层三种【.NET实现】的Basic Class Library
长话短说 上个月公司上线了一个物联网数据科学项目,我主要负责前端接受物联网事件,并提供 参数下载。 webapp 部署在Azure云上,参数使用Azure SQL Server存储。 最近从灰度测试转向全量部署之后,日志时常收到: SQL Session超限报错。 排查 我在Azure上使用的是 S
临近年关,搜狗,360浏览器出现页面无法成功跳转,同域Cookie丢失? 也许是服务端 SameSite惹的祸。&#xA;本文揭示由于Chrome低版本内核不识别 SameSite= None, 引发的单点登录故障。
本文聊一聊TraceID的作用和一般组成,衍生出ASP. NETCore 单体和分布式程序中 TraceId 的使用方式
通过给 HttpClint请求的日志增加 TraceId,解锁自定义扩展 HttpClientFacroty 的姿势