• SkyWalking 入门教程


    APM 系统

    APM (Application Performance Management) 即应用性能管理系统,是对企业系统即时监控以实现对应用程序性能管理和故障管理的系统化的解决方案。应用性能管理,主要指对企业的关键业务应用进行监测、优化,提高企业应用的可靠性和质量,保证用户得到良好的服务,降低IT总拥有成本。
    APM 系统是可以帮助理解系统行为、用于分析性能问题的工具,以便发生故障的时候,能够快速定位和解决问题。

    APM 产品对比

    在这里插入图片描述

    分布式链路追踪

    分布式链路追踪最先由 Google 在 Dapper 论文中提出。
    在比较大型的 web 集群和微服务环境中,客户端的一次请求可能需要经过多个不通的模块,多个中间件,多台主机一起相互协作才能处理完成客户端的骑牛,而在这一系列的请求过程之中,处理流程可能是串行也可能是并行,要清晰的了解客户端的一次请求到结束的背后调用了哪些应用以及哪些模块并经过了哪些节点,且么个模块的调用先后顺序是怎么的,每个模块的处理相应性能如何,就需要一套链路追踪(Trace)来分析各个环节的业务处理状况,从而让运维人员对整个业务系统一目了然。
    分布式服务跟踪系统是整个分布式系统中跟踪一个用户请求的完整过程,包括数据采集、数据传输、数据存储、数据分析和数据可视化,获取并存储和分享此类跟踪可以让运维清晰了解用户请求也业务系统交互背后的这个调用链的调用关系,链路追踪系统是针对调试和监控微服务不可或缺的好帮手。

    OpenTracing 规范

    由于 APM 系统较多,各个分布式链路追踪产品的 API 并不兼容,如果用户在各个产品之间进行切换,成本非常高。因此社区成立了 OpenTracing 组织,通过指定统一个 API 标准和数据结构模型,从而帮助开发人员和用户能够方便地使用或更换追踪系统。

    下图是一个分布式调用的例子,客户端发起请求,请求首先到达负载均衡器,接着经过认证服务,订单服务,然后请求资源,最后返回结果。
    在这里插入图片描述

    虽然这种图对于看清各组件的组合关系是很有用的,但是存在下面两个问题:
    它不能很好显示组件的调用时间,是串行调用还是并行调用,如果展现更复杂的调用关系,会更加复杂,甚至无法画出这样的图。
    这种图也无法显示调用间的时间间隔以及是否通过定时调用来启动调用。

    基于 OpenTracing 可以更有效地展现调用过程:
    在这里插入图片描述

    数据模型 trace

    一个 Trace 代表一个事物、请求或是流程在分布式系统中的执行过程,OpenTracing 中的一个 Trace 被认为是一个由多个 Span 组成的有向无环图(Directed Acyclic Graph,DAG 图),一个 Span 代表系统中具有开始时间和执行时长的逻辑单元,一条 Trace 中 Span 是首尾连接的(从请求开始到响应结束)。
    在这里插入图片描述

    数据模型 span

    span 代表系统中具有开始时间和执行长度的请求跨度,span 之间通过嵌套或者顺序排列建立逻辑因果关系,每个 span 中可以包含以下的信息:

    • 操作名称:例如访问的具体 RPC 服务,访问的 URL 地址等;
    • 起始时间;
    • 结束时间;
    • span tag:一组键值对构成的 span 标签集合,其中键必须为字符串类型,值可以是字符串、bool 类型或者数据;
    • span log:一组 span 的日志集合;
    • spanContext:trace 的全局上下文信息;
    • references:span 之间的引用关系,下图详细说明 span 之间的引用关系,span 的请求会产生 logs,logs 会携带一个时间戳以及一个可选的附加信息。
      在这里插入图片描述

    数据模型 tags

    每个 span 可以有多个键值对形式的 tags,tags 是没有时间戳的,只是为span添加一些简单解释和补充信息

    Skywalking

    Skywalking 是一个可观测性分析平台(Observability Analysis Platform,简称 OAP)
    和应用性能管理系统(Application Performance Management,简称 APM)。提供分布式链路追踪、服务网格(Service Mesh)遥测分析、度量(Metric)聚合和可视化一体化解决方案。

    • 实现从请求跟踪,指标收集和日志记录的完整信息记录,多语言自动探针,支持
      Java、Go、Python、PHP、NodeJS、Lua、Rust 等客户端;
    • 多种监控手段,语言探针和service mesh;
    • 轻量高效,不需要额外搭建大数据平台; 模块化架构。存储,集群管理,使用插件集合都可以进行自由选择; 支持告警; 优秀的可视化效果。
      在这里插入图片描述

    主要概念

    **服务(service):**服务相当于一个应用,表示对请求提供相同行为的一组工作负载。在使用打点代理或 SDK 的时候,你可以定义服务的名字。
    **服务实例(Service Instance):**相当于服务部署的具体节点,上述的一组工作负载中的每一个工作负载称为一个实例。就像 Kubernetes 中的 pods 一样,服务实例未必就是操作系统上的一个进程。 但当你在使用打点代理的时候,一个服务实例实际就是操作系统上的一个真实进程。
    **端点(Endpoint):**对于特定服务所接收的请求路径,如 HTTP 的 URI 路径和 gRPC 服务的类名 + 方法签名。

    架构

    SkyWalking 逻辑上分为四部分:探针、平台后端、存储和用户界面。
    在这里插入图片描述

    探针

    在 SkyWalking中,探针表示集成到目标系统中的代理或 SDK 库,它负责收集遥测数据,包括链路追踪和性能指标。根据目标系统的技术栈,探针可能有差异巨大的方式来达到以上功能。但从根本上来说都是一样的,即收集并格式化数据,并发送到后端。

    基于语言的原生代理

    这种类型的代理运行在目标服务的用户空间中,就像用户代码的一部分一样。如 SkyWalking Java 代理,使用 -javaagent 命令行参数在运行期间对代码进行操作,操作一词表示修改并注入用户代码。另一种代理是使用目标库提供的钩子函数或拦截机制。如你所见,这些探针是基于特定的语言和库。

    服务网格探针

    服务网格探针从服务网格的 Sidecar 和控制面板收集数据。在以前,代理只用作整个集群的入口,但是有了服务网格和 Sidecar 之后,我们可以基于此进行观测了。

    什么是服务网格?
    服务网格通常用于描述组成此类应用程序的微服务网络以及它们之间的交互。随着服务网格的大小和复杂性的增长,它会变得更难理解和管理。它需要包括发现、负载平衡、故障恢复、度量和监视以及更复杂的操作需求 A/B 测试、金丝雀发布、限流、访问控制和端到端身份验证。

    探针从哪里采集数据?
    服务网格探针可以选择从控制平面和数据平面采集数据。Istio 是一个非常典型的服务网格的设计和实现,在 Istio 中,指的是从 Mixer(Control Panel) 或者 Envoy sidecar(Data Panel) 中采集遥测数据。
    探针从客户端和服务器端收集每个请求的两个遥测实体,它们其实是相同的数据。
    在这里插入图片描述
    服务网格如何使后端工作?
    从探针中,可以看到在这种探针中一定没有相关的跟踪,那么为什么 SkyWalking 平台仍然可以工作?
    服务网格探针从每个请求收集遥测数据,因此它知道源、目标、端点、延迟和状态。通过这些,后端可以通过将这些调用合并为行来描述整个拓扑图,以及每个节点通过传入请求的度量。后端解析跟踪数据,请求相同的度量数据。因此,正确的表述是:服务网格度量就是跟踪解析器生成的度量。他们是相同的。

    第三方打点类库

    SkyWalking 也能够接收其他流行的打点库产生的数据格式。SkyWalking 通过分析数据,将数据格式化成自身的链路和度量数据格式。该功能最初只能接收 Zipkin 的 span 数据。

    平台后端

    支持数据聚合, 数据分析以及驱动数据流从探针到用户界面的流程。分析包括 Skywalking 原生追踪和性能指标以及第三方来源,包括 Istio 及 Envoy telemetry,Zipkin 追踪格式化等。 你甚至可以使用 Observability Analysis Language 对原生度量指标 和 用于扩展度量的计量系统 自定义聚合分析。

    存储

    通过开放的插件化的接口存放 SkyWalking 数据。你可以选择一个既有的存储系统,如 ElasticSearch、H2 或 MySQL 集群(Sharding-Sphere 管理),也可以选择自己实现一个存储系统。

    UI

    一个基于接口高度定制化的 Web 系统,用户可以可视化查看和管理 SkyWalking 数据。

    设计模式

    面向协议设计是 SkyWalking 从 5.x 开始严格遵守的首要设计原则,组件之间使用标准的协议进行数据交互,协议分为探针协议和查询协议。

    探针协议

    • 探针上报协议:协议包括语言探针的注册、Metrics 数据上报、Tracing 数据上报等标准,Java、Go 等探针都需要严格遵守此协议的标准。
    • 探针交互协议:因为分布式追踪环境,探针间需要借助 http header、MQ header 在应用之间进行通信和交互,探针交互协议就定义了交互的数据格式。
    • Service Mesh 协议:是 SkyWalking 对 Service Mesh 抽象的专有协议,任何 Mesh 类的服务都可以通过此协议直接上传指标数据,用于计算服务的指标数据和绘制拓扑图。
    • 第三方协议:对大型的第三方开源项目,尤其是 Service Mesh 核心平台 Istio 和 Envoy,提供核心协议适配,支持针对 Istion+Envoy Service Mesh 进行无缝对接。

    查询协议

    • 元数据查询:查询在 SkyWalking 注册的服务、服务实例、Endpoint 等元数据信息。
    • 拓扑关系查询:查询全局、单个服务、Endpoint 的拓扑图及依赖关系。
    • Metrics 指标查询:查询指标数据。
    • 聚合指标查询:区间范围均值查询及 Top N 排名数据查询等。
    • Trace 查询:追踪数据的明细查询。
    • 告警查询:基于表达式,判断指标数据是否超出阈值。
  • 相关阅读:
    Easily Compare and Deploy SQL Database Changes
    Python——while循环
    Error: “MountVolume.SetUp failed for volume pvc 故障处理
    C++中TCP socket传输文件
    荧光染料CY3/CY5/CY5.5偶联PCL纳米粒|CY3-PCL|PCL-CY5|CY5.5-PEG-PCL
    Springboot+Easyexcel将数据写入模板文件并导出Excel
    idea热部署-修改代码不重启
    【已解决】Vue项目中Vite以及Webpack代码混淆处理
    C++——list
    git上登录拉取项目记录
  • 原文地址:https://blog.csdn.net/qq997404392/article/details/125504036