之前讲解的日志框架,记录的日志都是文本,而且是非结构化的,这样一串串文本实际上不利于我们去做分析
一、ASP.NET Core WebApi如何设计一个日志中间件? ASP.NET Core WebApi 一个良好的日志记录内容包含,唯一请求 Id(traceId),请求 url ,请求 body 内容,相应 body 内容,执行开始和执行结束时间,总耗时时间等等。通过组合 Docker,ElasticSearch,Kibana,ASP.NET Core 和 Serilog ,您获得了前所未有的便利性和功能,再也没有理由不再将日志记录整合到应用程序中了。。 • 一句话总结今天我们学习到达的目标? 如
在我上篇文章中,我描述了如何配置Serilog的RequestLogging中间件以向Serilog的请求日志摘要中添加其他属性(例如请求主机名或选定的端点名称)。这些属性都在HttpContext中可用,因此可以由中间件本身直接添加。
这是在ASP.NET Core 3.X中使用Serilog.AspNetCore系列文章的第四篇文章:。
这是该系列的第二篇文章:在ASP.NET Core 3.0中使用Serilog.AspNetCore。
首先,打开VS2019新建一个ASP.NET Core Web Api项目,项目创建好后会有一个集成好的天气预报的类和控制器,接下来,我们的方法就在天气控制器里完成。
这是该系列的第一篇文章:在ASP.NET Core 3.0中使用Serilog.AspNetCore。
这段代码中,我们使用 Log.Logger 创建了一个 Serilog 的日志记录器。然后,我们使用 Log.Information 记录了一条日志。在 CreateHostBuilder 方法中,我们使用 builder.Host.UseSerilog() 将 Serilog 配置到主机中。
ASP.NET Core 中,可以使用 ConfigurationBuilder 对象来构建。
前面写过一篇《.NET Core类库中读取配置文件》 ,当时对于.NET Core读取配置文件了解有限,这里做下补充:
.NET Core采用的这个全新的配置模型的一个主要的特点就是对多种不同配置源的支持。我们可以将内存变量、命令行参数、环境变量和物理文件作为原始配置数据的来源。如果采用物理文件作为配置源,我们可以选择不同的格式(比如XML、JSON和INI等)。如果这些默认支持的配置源形式还不能满足你的需求,我们还可以通过注册自定义IConfigurationSource的方式将其他形式数据作为配置来源。
通过《服务承载系统[2]: 承载长时间运行的服务[下篇]》的介绍可知,IHostBuilder接口中定义了ConfigureHostConfiguration方法和ConfigureAppConfiguration方法,它们可以帮助我们设置面向宿主(IHost对象)和应用(承载服务)的配置。针对配置的初始化也可以借助IWebHostBuilder接口来完成。[本文节选自《ASP.NET Core 3框架揭秘》第11章, 更多关于ASP.NET Core的文章请点这里]
要访问配置,需要使用 ConfigurationBinder 类,它实现了 IConfigurationBuilder 接口,该接口包括两个重要的方法:
在原本的结构里面,由于默认服务引用的都是ABP原生的模块,所以结构目录里面没有包含modules目录,这里我们添加一个modules目录,用于存放我们的自定义模块。 在shared里面,我们再抽一个EventData的模块,用于消息队列共用数据实体。修改后结构如下图所示:
Loki是一个轻量级的日志系统,受到Prometheus项目的启发,由Grafana团队设计和开发,所以在Grafana中是原生支持的,具有可水平扩展,高度可用等特性,通过存储压缩的、非结构化的日志以及仅索引元数据,更加易于操作并且运行成本更低。
日志功能是几乎所有程序或系统都必备的一个功能。该文章通过使用Loki+Grafana来实现日志记录与可视化查询。
前言 .NET Core 在配置文件的操作上相对于.NET Framework做了不少改变,今天来聊一聊。关于Configuration的Package都是以Microsoft.Extensions.Configuration开头的支持多种方式的配置,包括内存、Json文件、XML文件等等,今天我们主要用Json格式文件配置来演示。 开始 新建一个ConsoleApp(这里为了方便演示就用控制台程序来演示了,而不用ASP.NET Core),添加两个Package: Install-Package Micr
Logstash是一种分布式日志收集框架,经常与ElasticSearch,Kibana配置,组成著名的ELK技术栈,非常适合用来做日志数据的分析。logstash具备实时数据传输能力的管道,负责将数据信息从管道的输入端传输到管道的输出端;与此同时这根管道还可以让你根据自己的需求在中间加上滤网,Logstash提供里很多功能强大的滤网以满足你的各种应用场景。当然它可以单独出现,作为日志收集软件,你可以收集日志到多种存储系统或临时中转系统,如MySQL,Redis,Kakfa,HDFS, Lucene,Solr等,并不一定是ElasticSearch。
提到“配置”二字,我想绝大部分.NET开发人员脑海中会立即浮现出两个特殊文件的身影,那就是我们再熟悉不过的app.config和web.config,多年以来我们已经习惯了将结构化的配置定义在这两个XML格式的文件之中。到了.NET Core的时代,很多我们习以为常的东西都发生了改变,其中就包括定义配置的方式。总的来说,新的配置系统显得更加轻量级,并且具有更好的扩展性,其最大的特点就是支持多样化的数据源。我们可以采用内存的变量作为配置的数据源,也可以将配置定义在持久化的文件甚至数据库中。在对配置系统进行系统介绍之前,我们先从编程的角度来体验一下全新的配置读取方式。
一般dotnet core配置文件都位于项目目录下,名为appsettings.json
Serilog是.net里面非常不错的记录日志的库,另外一个我认为比较好的Log库是NLog。 在我个人的asp.net web api 2 基础框架(Github地址)里,我原来使用的是NLog,但是由于好奇心,我决定使用Serilog代替Nlog。 安装: 首先安装 Serilog,通过Package Manager Console或者Nuget管理窗口进行安装: PM> Install-Package Serilog 然后安装 Serilog的Sinks,所谓Sink就是记录Log的途径,比如在控制台
ConfigurationBuilder在生成以Configuration对象的时候会利用注册其中的ConfigurationProvider加载原始的配置数据,那么一旦配置源中的数据发生变化,应用程序中的使用的配置信息如何与之同步呢?如果需要在应用程序中实现对配置信息的实施同步,就需要对原始配置数据的进行监控,并在数据改变的时候重新加载配置数据。除此之外,重新加载的配置需要应用到程序中,我们必然需要一种通知机制。 为了让读者朋友们对配置同步机制在具体项目中的应用有个感官认识,我们先通过一个简单的实例来演
在杨中科老师 B 站的.Net Core 视频教程[1]其中 DDD 部分讲到了强类型 ID(Strongly-typed-id)的概念,也叫受保护的密钥(guarded keys)当时在 .NET 中的 DDD 实现是个悬而未决的问题,之后我也一直在寻找相关的实现方案。
本文主要是关于.NET Standard 代码 在多框架 和 多平台 支持自己实践过程中遇到的一些问题和解决办法,希望给遇到这些问题的同学一点参考和思路。问题基本上都是提在 博问 和 Stackoverflow 中,不乏很多大佬都提供了解决问题的思路。接下来则是正文。
https://www.cnblogs.com/savorboard/p/cap-7-0.html)
一个完善的系统,必然会有非常完善的日志记录,用户的操作、系统的运行状况等信息被完整的记录下来,方便我们对系统进行维护和改进。.net core 也为日志记录提供了内置的支持。
开源项目是众多组织与个人分享的组件或项目,作者付出的心血我们是无法体会的,所以首先大家要心存感激、尊重。请严格遵守每个项目的开源协议后再使用。尊重知识产权,共建和谐开源社区。
最近在学习博客园腾飞(jesse)的.Net Core视频教程,收益匪浅,在此作推荐 : http://video.jessetalk.cn/ 言归正传,.Net Core应用程序中如何通过命令行读取
在《.NET Core采用的全新配置系统[1]: 读取配置数据》中,我们通过实例的方式演示了几种典型的配置读取方式,其主要目的在于使读者朋友们从编程的角度对.NET Core的这个全新的配置系统具有一个大体上的认识,接下来我们从设计的维度来重写认识它。通过上面演示的实例我们知道,配置的编程模型涉及到三个核心对象,它们分别是Configuration、ConfigurationSource和ConfigurationBuilder。如果从设计层面来审视这个配置系统,还缺少另一个名为ConfigurationP
我打算开个专题,系统地写一写 Dotnet 6.0 在各个方面的特性,以及全新的开发方式。也是因为最近讨论 6.0 比较多,看到很多人的畏难情绪,所以打算写写相关的内容。
本文所需的一些预备知识可以看这里: http://www.cnblogs.com/cgzl/p/9010978.html 和 http://www.cnblogs.com/cgzl/p/9019314.html
如果有时间,我会在周报中加入一些专题和项目案例的分享,本周就是讨论.NET NanoFramework项目案例的专题,在讨论 NanoFramework 的典型案例之前,让我们先回顾一下 .NET 在嵌入式领域的历史。
提到“配置”二字,我想绝大部分.NET开发人员脑海中会立马浮现出两个特殊文件的身影,那就是我们再熟悉不过的app.config和web.config,多年以来我们已经习惯了将结构化的配置定义在这两个文件之中。到了.NET Core的时代,很多我们习以为常的东西都发生了改变,其中也包括定义配置的方式。总的来说,新的配置系统显得更加轻量级,并且具有更好的扩展性,其最大的特点就是支持多样化的数据源。我们可以采用内存的变量作为配置的数据源,也可以直接配置定义在持久化的文件甚至数据库中。由于很多人都不曾接触过这个采用
较之传统通过App.config和Web.config这两个XML文件承载的配置系统,ASP.NET Core采用的这个全新的配置模型的最大一个优势就是针对多种不同配置源的支持。我们可以将内存变量、命令行参数、环境变量和物理文件作为原始配置数据的来源,如果采用物理文件作为配置源,我们可以选择不同的格式,比如XML、JSON和INI等。如果这些默认支持的配置源形式还不能满足你的需求,我们还可以通过注册自定义ConfigurationProvider的方式将其他形式数据作为我们的配置来源。接下来就让我们来逐个认
今天呐,我特别要向 写框架 的朋友们,想要写框架 ** 的朋友们,已经有框架** 的朋友问声好!
课程链接:http://video.jessetalk.cn/course/explore
在.net framework平台中我们常见的也是最熟悉的就是.config文件作为配置,控制台桌面程序是App.config,Web就是web.config,里面的配置格式为xml格式。
[接上篇]提到“配置”二字,我想绝大部分.NET开发人员脑海中会立即浮现出两个特殊文件的身影,那就是我们再熟悉不过的app.config和web.config,多年以来我们已经习惯了将结构化的配置定义在这两个XML格式的文件之中。到了.NET Core的时代,很多我们习以为常的东西都发生了改变,其中就包括定义配置的方式。总的来说,新的配置系统显得更加轻量级,并且具有更好的扩展性,其最大的特点就是支持多样化的数据源。我们可以采用内存的变量作为配置的数据源,也可以将配置定义在持久化的文件甚至数据库中。在对配置系统进行系统介绍之前,我们先从编程的角度来体验一下全新的配置读取方式。
上一部分预备知识在这 http://www.cnblogs.com/cgzl/p/9010978.html 如果您对ASP.NET Core很了解的话,可以不看本文, 本文基本都是官方文档的内容。 A
提到“配置”二字,我想绝大部分.NET开发人员脑海中会立马浮现出两个特殊文件的身影,那就是我们再熟悉不过的app.config和web.config,多年以来我们已经习惯了将结构化的配置信息定义在这两个文件之中。到了.NET Core的时候,很多我们习以为常的东西都发生了改变,其中也包括定义配置的方式。总的来说,新的配置系统显得更加轻量级,并且具有更好的扩展性,其最大的特点就是支持多样化的数据源。我们可以采用内存的变量作为配置的数据源,也可以直接配置定义在持久化的文件甚至数据库中。 由于很多人都不曾接触过
较之传统通过App.config和Web.config这两个XML文件承载的配置系统,.NET Core采用的这个全新的配置模型的最大一个优势就是针对多种不同配置源的支持。我们可以将内存变量、命令行参数、环境变量和物理文件作为原始配置数据的来源,如果采用物理文件作为配置源,我们可以选择不同的格式(比如XML、JSON和INI等) 。如果这些默认支持的配置源形式还不能满足你的需求,我们还可以通过注册自定义ConfigurationSource的方式将其他形式数据作为我们的配置来源。 目录 一、内存变量 二
前段时间有同学在微信群里提问,要使用.NET开发一个简单的爬虫功能但是没有做过无从下手。今天给大家推荐一个轻量、灵活、高性能、跨平台的分布式网络爬虫框架(可以帮助 .NET 工程师快速的完成爬虫的开发):DotnetSpider。
上一部分预备知识在这 http://www.cnblogs.com/cgzl/p/9010978.html
综合考虑,第三点肯定是不靠谱的,第一点成本太高,公司本来就比较忙,那就只能去找一个现成的了…
Kestrel介绍 在Asp.Net Core中,我们的web application 其实是运行在Kestrel服务上,它是一个基于libuv开源的跨平台可运行 Asp.Net Core 的web服务器。 在开发阶段,我们可以直接使用Kestrel服务器用来测试,也可以使用IISExpress。在使用IISExpress其实也需要启动一个Kestrel服务器,通过IISExpress反向代理请求到Kestrel,很多时候我更喜欢使用Kestrel,因为可以实时看到log。 配置端口 在Socket开发中,
添加Command支持 新建一个ASP.NET Core 项目,打开Program.cs 添加下面的代码: public class Program { public static void Main(string[] args) { BuildWebHost(args).Run(); } public static IWebHost BuildWebHost(string[] args) => WebHost.CreateDefaultBu
我是后端开发人员, 前端的Angular部分讲的比较差一些, 可以直接看代码!!!!
首先新建一.net core控制台项目,命名为jsonReader 然后选中引用,选择NuGet包管理器,点击浏览引入mircosoft.aspnetcore.all并安装 选中解决方案,填加,新建项
初学.Net Core,很多细节还不熟悉,打算一步一步来学,能学多少就看时间有多少,时间就像海绵里的水,挤一挤总还是有的嘛。
这篇内容主要来自Microsoft .NET团队程序经理Sourabh Shirhatti的博客文章:https://grpc.io/blog/grpc-on-dotnetcore/, .NET Core 3.0现已提供grpc的.NET 托管实现 grpc-dotnet, gRpc 取代WCF成为 .NET的一等公民。自2018年11月以来,Microsoft的.NET团队一直与gRPC团队密切合作,共同开发适用于.NET Core的gRPC的全新完全托管实现。
领取专属 10元无门槛券
手把手带您无忧上云