『Skywalking』.NET Core快速接入分布式链路追踪平台

本文涉及的产品
应用实时监控服务-可观测链路OpenTelemetry版,每月50GB免费额度
简介: 📣读完这篇文章里你能收获到- .NET Core接入Skywalking- 了解Skywalking的整体架构设计- 了解Skywalking的各项技术指标怎么看- 生产部署时的坑全跳过- 感谢点赞+收藏,避免下次找不到~

请添加图片描述
📣读完这篇文章里你能收获到

  • .NET Core接入Skywalking
  • 了解Skywalking的整体架构设计
  • 了解Skywalking的各项技术指标怎么看
  • 生产部署时的坑全跳过
  • 感谢点赞+收藏,避免下次找不到~

请添加图片描述

一、概述

1 概念——SkyWalking 是什么?

Application performance monitor tool for distributed systems, especially designed for microservices, cloud native and container-based (Kubernetes) architectures.

分布式系统的应用程序性能监视工具,专为微服务、云原生架构和基于容器(Docker、K8s、Mesos)架构而设计。
提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。

2 核心功能

在这里插入图片描述

  • 多种监控手段。可以通过语言探针和 service mesh 获得监控是数据
  • 多个语言自动探针。包括 Java,.NET Core 和 Node.JS
  • 轻量高效。无需大数据平台,和大量的服务器资源
  • 模块化。UI、存储、集群管理都有多种机制可选
  • 支持告警
  • 优秀的可视化解决方案

3 系统架构

在这里插入图片描述

考虑到让描述更简单,我们舍弃掉 Metric 指标相关,而着重在 Tracing 链路相关功能。
  • 上部分 Agent :负责从应用中,收集链路信息,发送给 SkyWalking OAP 服务器。目前支持 SkyWalking、Zikpin、Jaeger 等提供的 Tracing 数据信息。而我们目前采用的是,SkyWalking Agent 收集 SkyWalking Tracing 数据,传递给服务器。
  • 下部分 SkyWalking OAP :负责接收 Agent 发送的 Tracing 数据信息,然后进行分析(Analysis Core) ,存储到外部存储器( Storage ),最终提供查询( Query )功能。
  • 右部分 Storage:Tracing 数据存储。目前支持 ES、MySQL、Sharding Sphere、TiDB、H2 多种存储器。而我们目前采用的是 ES ,主要考虑是 SkyWalking 开发团队自己的生产环境采用 ES 为主。
  • 左部分 SkyWalking UI :负责提供控台,查看链路等等。

请添加图片描述

二、工具安装

请添加图片描述

三、.NET项目接入

1. NuGet包引用

  • 需要在每个服务里通过NuGet引用SkyAPM.Agent.AspNetCore ,如果是.net core3.1的话需要选择1.3.0版本

在这里插入图片描述

2. 添加配置文件skyapm.json

在这里插入图片描述

{
  "SkyWalking": {
    "ServiceName": "demo-application",
    "Namespace": "",
    "HeaderVersions": [
      "sw8"  //6.x以下的版本为sw6
    ],
    "Sampling": {
      "SamplePer3Secs": -1,
      "Percentage": -1.0
    },
    "Logging": {
      "Level": "Information", //可填空
      "FilePath": "logs\\skyapm-{Date}.log"//可填空
    },
    "Transport": {
      "Interval": 3000,
      "ProtocolVersion": "v8", //6.x以下的版本为v6
      "QueueSize": 30000,
      "BatchSize": 3000,
      "gRPC": {
        "Servers": "localhost:11800", //ip:port
        "Timeout": 10000,
        "ConnectTimeout": 10000,
        "ReportTimeout": 600000
      }
    }
  }
}
  • 注意:
  1. gRPC的Servers需要指定SkyWalking的服务端地址,默认端口是11800
  2. v8指的是版本号,新版本是v8

3. 配置环境变量

  • 直接改启动文件
 "ASPNETCORE_HOSTINGSTARTUPASSEMBLIES": "SkyAPM.Agent.AspNetCore"

在这里插入图片描述

  • 或者在启动Program.cs->Main()方法开头设置环境变量
Environment.SetEnvironmentVariable("ASPNETCORE_HOSTINGSTARTUPASSEMBLIES", "SkyAPM.Agent.AspNetCore");

在这里插入图片描述

4. skyapm.json文件输出

  • 将skyapm.json文件的属性”复制到输出目录“ 修改为 ”如果较新则复制”

在这里插入图片描述

请添加图片描述

四、运行监控

  • 到此就可以使用了,打开skywalking地址,查看效果
  • 这里,我们可以看到.NET Core应用的服务为 demo-application

1 普通服务——General-Service

普通服务(General-Service):表示对请求提供相同行为的一系列或一组工作负载。在使用 Agent 或 SDK 的时候,你可以定义服务的名字。

在这里插入图片描述

2 主要监控指标

  • 点击 demo-application 这个服务名,可以看到该服务的【整体监控信息】

在这里插入图片描述

  • ApdexScore : 性能指数,Apdex(Application Performance Index)是一个国际通用标准,Apdex 是用户对应用性能满意度的量化值。它提供了一个统一的测量和报告用户体验的方法,把最终用户的体验和应用性能作为一个完整的指标进行统一度量,其中最高为1最低为0;
  • ResponseTime:响应时间,即在选定时间内,服务所有请求的平均响应时间(ms);
  • ServiceLoad-Throughput: 服务负载-吞吐量,即在选定时间内,每分钟服务响应的请求量(cpm)
  • SuccessRate: 单位-(SLA)service level agreement,服务等级协议,SW中特指每分钟内响应成功请求的占比。
  • Slow Endpoint in Current Service : 当前服务的端点,服务指标仪表盘会列举出当前服务响应时间最大的端点Top10,如果有端点的响应时间过高,则需要进一步关注其指标(点击可以复制端点名称)。
  • Endpoint Load in Current Service : 当前服务负载(吞吐量)高的端点,通过此可以推断出实例之间的负载情况。如果发现某个实例吞吐量较低,就需要查询实例指标(如查询该实例是不是发生了GC,或则CPU利用率过高)

3 服务实例——Service Instance

  • 服务实例(Service Instance):上述的一组工作负载中的每一个工作负载称为一个实例。就像 Kubernetes 中的 pods 一样, 服务实例未必就是操作系统上的一个进程。但当你在使用 Agent 的时候, 一个服务实例实际就是操作系统上的一个真实进程
  • 点击 [Instance] 选项卡,可以查到该服务的【实例列表】

在这里插入图片描述

4 端点——Endpoint

  • 端点(Endpoint) :对于特定服务所接收的请求路径, 如 HTTP 的 URI 路径和 gRPC 服务的类名 + 方法签名。 这里,我们可以看到 .Net Core 应用的一个端点,为 API 接口 /demo/echo
  • 点击 [Endpoint] 选项卡,可以查看到该服务的【端点列表】

在这里插入图片描述

5 拓扑图——Topology

  • 点击 [Topology] 选项卡,可以查看到该服务的【拓扑图】

6 链路——Trace

  • 点击 [Trace] 选项卡,可以查看到该服务的【链路】。

在这里插入图片描述

7 日志——Log

  • 点击 [Log] 选项卡,可以查看到该服务的【日志】。

在这里插入图片描述

请添加图片描述

五、生产环境部署

如果是采用第三点的启动Program.cs->Main()方法开头设置环境变量
则以下操作均可省略

1. Linux部署

  • 命令行启动方式,增加systemd环境变量,语法为
Environment=ASPNETCORE_HOSTINGSTARTUPASSEMBLIES=SkyAPM.Agent.AspNetCore

2. Windows IIS方式部署

项目编译后发布到IIS,SkyWalking是不起作用的,我们需要在IIS中设置下环境变量,这里介绍设置环境变量有两种方式
  1. 方法一: 发布的文件里会有web.config,我们需要在web.config中添加环境变量

在这里插入图片描述

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath="dotnet" arguments=".\MI.Web.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout">
                <environmentVariables>
                    <environmentVariable name="ASPNETCORE_HOSTINGSTARTUPASSEMBLIES" value="SkyAPM.Agent.AspNetCore" />
                    <environmentVariable name="SKYWALKING__SERVICENAME" value="xx.Service" />
                </environmentVariables>
            </aspNetCore>
    </system.webServer>
  </location>
</configuration>
  1. 方法二:通过IIS配置
  • 选中相应项目,点击配置编辑器

在这里插入图片描述

在这里插入图片描述
在这里插入图片描述

相关实践学习
基于OpenTelemetry构建全链路追踪与监控
本实验将带领您快速上手可观测链路OpenTelemetry版,包括部署并接入多语言应用、体验TraceId自动注入至日志以实现调用链与日志的关联查询、以及切换调用链透传协议以满足全链路打通的需求。
分布式链路追踪Skywalking
Skywalking是一个基于分布式跟踪的应用程序性能监控系统,用于从服务和云原生等基础设施中收集、分析、聚合以及可视化数据,提供了一种简便的方式来清晰地观测分布式系统,具有分布式追踪、性能指标分析、应用和服务依赖分析等功能。 分布式追踪系统发展很快,种类繁多,给我们带来很大的方便。但在数据采集过程中,有时需要侵入用户代码,并且不同系统的 API 并不兼容,这就导致了如果希望切换追踪系统,往往会带来较大改动。OpenTracing为了解决不同的分布式追踪系统 API 不兼容的问题,诞生了 OpenTracing 规范。OpenTracing 是一个轻量级的标准化层,它位于应用程序/类库和追踪或日志分析程序之间。Skywalking基于OpenTracing规范开发,具有性能好,支持多语言探针,无侵入性等优势,可以帮助我们准确快速的定位到线上故障和性能瓶颈。 在本套课程中,我们将全面的讲解Skywalking相关的知识。从APM系统、分布式调用链等基础概念的学习加深对Skywalking的理解,从0开始搭建一套完整的Skywalking环境,学会对各类应用进行监控,学习Skywalking常用插件。Skywalking原理章节中,将会对Skywalking使用的agent探针技术进行深度剖析,除此之外还会对OpenTracing规范作整体上的介绍。通过对本套课程的学习,不止能学会如何使用Skywalking,还将对其底层原理和分布式架构有更深的理解。本课程由黑马程序员提供。
相关文章
|
2月前
|
开发框架 .NET 开发者
简化 ASP.NET Core 依赖注入(DI)注册-Scrutor
Scrutor 是一个简化 ASP.NET Core 应用程序中依赖注入(DI)注册过程的开源库,支持自动扫描和注册服务。通过简单的配置,开发者可以轻松地从指定程序集中筛选、注册服务,并设置其生命周期,同时支持服务装饰等高级功能。适用于大型项目,提高代码的可维护性和简洁性。仓库地址:&lt;https://github.com/khellang/Scrutor&gt;
60 5
|
1月前
|
存储 Prometheus Cloud Native
分布式系统架构6:链路追踪
本文深入探讨了分布式系统中的链路追踪理论,涵盖追踪与跨度的概念、追踪系统的模块划分及数据收集的三种方式。链路追踪旨在解决复杂分布式系统中请求流转路径不清晰的问题,帮助快速定位故障和性能瓶颈。文中介绍了基于日志、服务探针和边车代理的数据收集方法,并简述了OpenTracing、OpenCensus和OpenTelemetry等链路追踪协议的发展历程及其特点。通过理解这些概念,可以更好地掌握开源链路追踪框架的使用。
98 41
|
4月前
|
存储 开发框架 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`,优化了内存使用和序列化速度。
116 0
|
2月前
|
开发框架 算法 中间件
ASP.NET Core 中的速率限制中间件
在ASP.NET Core中,速率限制中间件用于控制客户端请求速率,防止服务器过载并提高安全性。通过`AddRateLimiter`注册服务,并配置不同策略如固定窗口、滑动窗口、令牌桶和并发限制。这些策略可在全局、控制器或动作级别应用,支持自定义响应处理。使用中间件`UseRateLimiter`启用限流功能,并可通过属性禁用特定控制器或动作的限流。这有助于有效保护API免受滥用和过载。 欢迎关注我的公众号:Net分享 (239字符)
62 1
|
3月前
|
开发框架 .NET C#
在 ASP.NET Core 中创建 gRPC 客户端和服务器
本文介绍了如何使用 gRPC 框架搭建一个简单的“Hello World”示例。首先创建了一个名为 GrpcDemo 的解决方案,其中包含一个 gRPC 服务端项目 GrpcServer 和一个客户端项目 GrpcClient。服务端通过定义 `greeter.proto` 文件中的服务和消息类型,实现了一个简单的问候服务 `GreeterService`。客户端则通过 gRPC 客户端库连接到服务端并调用其 `SayHello` 方法,展示了 gRPC 在 C# 中的基本使用方法。
64 5
在 ASP.NET Core 中创建 gRPC 客户端和服务器
|
3月前
|
消息中间件 监控 数据可视化
Apache Airflow 开源最顶级的分布式工作流平台
Apache Airflow 是一个用于创作、调度和监控工作流的平台,通过将工作流定义为代码,实现更好的可维护性和协作性。Airflow 使用有向无环图(DAG)定义任务,支持动态生成、扩展和优雅的管道设计。其丰富的命令行工具和用户界面使得任务管理和监控更加便捷。适用于静态和缓慢变化的工作流,常用于数据处理。
Apache Airflow 开源最顶级的分布式工作流平台
|
2月前
|
开发框架 缓存 .NET
GraphQL 与 ASP.NET Core 集成:从入门到精通
本文详细介绍了如何在ASP.NET Core中集成GraphQL,包括安装必要的NuGet包、创建GraphQL Schema、配置GraphQL服务等步骤。同时,文章还探讨了常见问题及其解决方法,如处理复杂查询、错误处理、性能优化和实现认证授权等,旨在帮助开发者构建灵活且高效的API。
57 3
|
3月前
|
存储 监控 数据可视化
双十一线上服务调用链路追踪SkyWalking实战分析
【11月更文挑战第27天】随着电商行业的飞速发展,双十一购物节已成为全球最大的购物狂欢节之一。在双十一期间,电商平台需要处理海量的用户请求和订单,这对系统的稳定性和性能提出了极高的要求。为了确保系统在高并发环境下的稳定运行,对线上服务的调用链路进行追踪和分析显得尤为重要。本文将通过实战案例,详细介绍如何在双十一期间使用SkyWalking对线上服务进行调用链路追踪,并结合Seata实现分布式事务管理,从而保障系统的稳定性和性能。
114 6
|
4月前
|
开发框架 JavaScript 前端开发
一个适用于 ASP.NET Core 的轻量级插件框架
一个适用于 ASP.NET Core 的轻量级插件框架
|
4月前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?