APM (Application Performance Management) 即应用性能管理系统,是对企业系统即时监控以实现对应用程序性能管理和故障管理的系统化的解决方案。应用性能管理,主要指对企业的关键业务应用进行监测、优化,提高企业应用的可靠性和质量,保证用户得到良好的服务,降低IT总拥有成本。
APM 系统是可以帮助理解系统行为、用于分析性能问题的工具,以便发生故障的时候,能够快速定位和解决问题。
分布式链路追踪最先由 Google 在 Dapper 论文中提出。
在比较大型的 web 集群和微服务环境中,客户端的一次请求可能需要经过多个不通的模块,多个中间件,多台主机一起相互协作才能处理完成客户端的骑牛,而在这一系列的请求过程之中,处理流程可能是串行也可能是并行,要清晰的了解客户端的一次请求到结束的背后调用了哪些应用以及哪些模块并经过了哪些节点,且么个模块的调用先后顺序是怎么的,每个模块的处理相应性能如何,就需要一套链路追踪(Trace)来分析各个环节的业务处理状况,从而让运维人员对整个业务系统一目了然。
分布式服务跟踪系统是整个分布式系统中跟踪一个用户请求的完整过程,包括数据采集、数据传输、数据存储、数据分析和数据可视化,获取并存储和分享此类跟踪可以让运维清晰了解用户请求也业务系统交互背后的这个调用链的调用关系,链路追踪系统是针对调试和监控微服务不可或缺的好帮手。
由于 APM 系统较多,各个分布式链路追踪产品的 API 并不兼容,如果用户在各个产品之间进行切换,成本非常高。因此社区成立了 OpenTracing 组织,通过指定统一个 API 标准和数据结构模型,从而帮助开发人员和用户能够方便地使用或更换追踪系统。
下图是一个分布式调用的例子,客户端发起请求,请求首先到达负载均衡器,接着经过认证服务,订单服务,然后请求资源,最后返回结果。
虽然这种图对于看清各组件的组合关系是很有用的,但是存在下面两个问题:
它不能很好显示组件的调用时间,是串行调用还是并行调用,如果展现更复杂的调用关系,会更加复杂,甚至无法画出这样的图。
这种图也无法显示调用间的时间间隔以及是否通过定时调用来启动调用。
基于 OpenTracing 可以更有效地展现调用过程:
一个 Trace 代表一个事物、请求或是流程在分布式系统中的执行过程,OpenTracing 中的一个 Trace 被认为是一个由多个 Span 组成的有向无环图(Directed Acyclic Graph,DAG 图),一个 Span 代表系统中具有开始时间和执行时长的逻辑单元,一条 Trace 中 Span 是首尾连接的(从请求开始到响应结束)。
span 代表系统中具有开始时间和执行长度的请求跨度,span 之间通过嵌套或者顺序排列建立逻辑因果关系,每个 span 中可以包含以下的信息:
每个 span 可以有多个键值对形式的 tags,tags 是没有时间戳的,只是为span添加一些简单解释和补充信息
Skywalking 是一个可观测性分析平台(Observability Analysis Platform,简称 OAP)
和应用性能管理系统(Application Performance Management,简称 APM)。提供分布式链路追踪、服务网格(Service Mesh)遥测分析、度量(Metric)聚合和可视化一体化解决方案。
**服务(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 管理),也可以选择自己实现一个存储系统。
一个基于接口高度定制化的 Web 系统,用户可以可视化查看和管理 SkyWalking 数据。
面向协议设计是 SkyWalking 从 5.x 开始严格遵守的首要设计原则,组件之间使用标准的协议进行数据交互,协议分为探针协议和查询协议。