前言
当一个APM或一个日志中心实际部署在生产环境中时,是有点力不从心的。
比如如下场景分析的问题:
-
从APM上说,知道某个节点出现异常,或延迟过过高,却不能及时知道日志反馈情况,总不可能去相应的节点上一个一个的翻日志文件吧。
-
从日志中心上说(特别是Exceptionless,能及时反馈出异常信息),知道某个节点出现异常日志,可不知道引起异常的源头在哪;或者出现延迟过高日志,却不能及时知道节点问题,还是链路问题;就算诸上问题都能应付,那么一行行的、一个个的日志文件和使用图形化的表述形式,谁会更加直观,当然,你说你可以一目十行,甚至百行来分析日志,那我挺佩服你的。
本节内容较多,所以笔者特列举了如下目录。
一:准备
1.SkyWalking和Exceptionless简单回顾
2.新建多个站点(物理节点)
3.附加SkyApm-dotnet程序集到宿主
二:将SkyApm-dotnet的日志输出到Exceptionless
4.SkyApm-dotnet的日志入口
5.继承ILoggerFactory获取全局ILogger对象
6.将Logger写入到Exceptionless
三:运行
7.SkyWalking和Exceptionless的结合分析
SkyWalking和Exceptionless简单回顾
前两篇就《NET Core微服务之路:SkyWalking+SkyApm-dotnet分布式链路追踪系统的分享》和《NET Core微服务之路:简单谈谈对ELK,Splunk,Exceptionless统一日志收集中心的心得体会》简单的介绍了SkyApm-dotnet和三个日志收集中心。为何最终会选择SkyWalking和Exceptionless来作为生产实战,很简单:
1.SkyWalking和Exceptionless的存储和检索都是使用的ElasticSearch,ES的强大之处不用介绍:“you know, for search”
2.SkyWalking作为国人(吴晟)开发的一套开源追踪系统,虽然比不上Pinpoint功能强大,但社区活跃且免费,相信开源的力量,会越来越完善,甚至更好。
3.Exceptionless作为.Net开源社区的新起之秀,目前也十分活跃,原生.Net语言支持,能做到日后无缝扩展。
新建多个站点(物理节点)
传统单体应用(或站点)没必须要做到APM追踪,因为她毫无意义。只有在分布式架构模式下,例如SOA、微服务等架构才有意义,比如说,你在两个地方分别部署了多个应用,当某个地方的应用出现了故障,你总不可能专门跑去一个一个文件的查阅日志吧,假如这个应用部署在火星呢(哈哈,开个玩笑)。
我们就SkyApm-dotnet中的
Sample做一些二次修改和扩展,来模拟一个实际的分布式系统。
先看看这个系统的网络拓扑图:
asp-net-core-*为系统主要节点,而localhost:50000为Exceptionless的日志中心,114.215是数据库,具体每个线条的颜色请查阅SkyWalking手册。
asp-net-core-aspnetcore:我们可以把她理解为请求端,笔者在里面做了一个单请求,和一个并行请求,严格意义上来说,代码中不应该有try catch来进行重试,而是应该使用polly的Retry进行重试和异常处理,可以参考《NET Core微服务之路:弹性和瞬态故障处理库Polly的介绍》,代码参考如下:
[Route("api/[controller]")] [ApiController] public class ValuesController : ControllerBase { [HttpGet] public async Task<string> Get() { var httpClient = new HttpClient(); var values = await httpClient.GetStringAsync("http://localhost:5001/api/values"); ExceptionlessClient.Default.SubmitLog(JsonConvert.SerializeObject(values), LogLevel.Debug); return values; } [HttpGet("getall")] public string GetAll() { var list = new List<int>(); var listValue = new List<string>(); for (var i = 1; i <= 50; i++)