对于普通系统或者服务来说,一般通过打日志来进行埋点,然后再通过elk或splunk进行定位及分析问题,更有甚者直接远程服务器,直接操作查看日志,那么,随着业务越来越复杂,企业应用也进入了分布式服务化的阶段,传统的日志监控等方式无法很好达到跟踪调用、排查问题等需求,可以想象,如果你的服务节点达到有很多很多(两位数以上吧),而没有一个自动跟踪系统,那查找一个问题将成为噩梦。
  那么,服务之间调用的问题是:  
* 如何快速发现问题?
* 如何判断故障影响范围?
* 如何梳理服务依赖以及依赖的合理性?
* 如何分析链路性能问题以及实时容量规划?
* 如何在分布式服务进行日志监控呢?   首先大家会想到分布式链路追踪系统,说到这,就得讲 OpenTracing 规范,OpenTracing
是一个轻量级的标准化层,它位于应用程序/类库和追踪或日志分析程序之间。详细介绍见 《opentracing文档中文版
<https://wu-sheng.gitbooks.io/opentracing-io/content/>》。在谷歌论文《Dapper,
大规模分布式系统的跟踪系统 <http://bigbully.github.io/Dapper-translation/>
》的指导下,许多优秀的APM应运而生,分布式追踪系统发展很快,种类繁多,给我们带来很大的方便。虽然目前市面许多优秀的APM系统,但是作为我们.NET程序员的选择却就少之又少了(甚至没得选),几乎各大分布式追踪系统均提供java版的支持,而.NET上却只有SkyWalking的
SkyAPM-dotnet <https://github.com/SkyAPM/SkyAPM-dotnet>一直在默默的支持着,辛苦了,大佬们。  
好吧,既然不能做到技术选型,那么我们就开始工作吧。SkyWalking和Elasticsearch的安装,网上一抓一大把,这里不在重复的介绍“如何安装”和“如何使用”。
  从SkyAPM-dotnet中,我们可以拿到团队的官方示例,
https://github.com/SkyAPM/SkyAPM-dotnet/tree/master/sample
<https://github.com/SkyAPM/SkyAPM-dotnet/tree/master/sample>
,她分为请求端,前置端和后端(当然,你喜欢怎么叫都行),我稍微修改一下,做了一些数据和请求数上的调整,
本篇代码不是重点(SkyAPM-dotne已经达到开箱即用的强大优势),希望得到的数据像下面这样:    
解释一下这个数据是怎么来的(或者这个实验的服务架设):
* 后端:提供数据库的查询,队列的接口等一系列数据操作的地方;
* 前置:提供接口的过滤和处理,可以把他理解为一个逻辑后端,或者一个API网关;
* 请求:提供请求,或者模拟串行或并行请求;  
这样从逻辑上理解就是1->2->3->2->1,其实一个请求从头到尾然后在返回到前端也都是这样的,你可以把他想象成我们常见的三层模型、等等。
启动三个节点后,通过SkyWalking可以看到,Service数量是3,正是我们创建的三个服务节点,Endpoint表示所有连接的数量,DB和Cache作为数据库(或缓存)的数量,MQ的数量、平均吞吐量、网络拓扑图等等。
整个界面一目了然,更多详细介绍可查看官网解释。            
在.NET的生态圈中,曾经有ButterFly这样的原生.NET框架来实现我们整个系统的链路追踪,只是作者表示已不在维护,所以,在.NET上,我们能选的资源也就非常非常的少了!
 

友情链接
KaDraw流程图
API参考文档
OK工具箱
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:637538335
关注微信