Apache Skywalking 实战 阅读笔记 第二章

Apache Skywalking 实战 阅读笔记 第二章

一、参考资料

二、笔记总结

第2章　SkyWalking安装与配置

• 本章主要介绍SkyWalking的项目编译和工程结构，以及JavaAgent模块、后端模块、UI模块的部署和配置信息。通过本章的学习，读者可以部署一个简单的SkyWalking环境来体验SkyWalking的便捷和强大。

2.1 项目编译与工程结构

• 本节将主要从代码工程的角度介绍SkyWalking的源码编译和项目的工程结构，来帮助读者更好地理解SkyWalking的源码结构。

2.1.1 项目编译

2.1.2 工程结构

2.2 JavaAgent安装

• JavaAgent是SkyWalking系统中的数据发送端，通过简单的部署和配置，用户就可以做到无代码侵入式地获取到业务调用链路数据。

2.2.1 安装方法

2.2.2 配置参数

2.2.3 插件介绍

• SkyWalking的插件库主要分为以下两类。
  • 稳定插件：装载了SkyWalking的JavaAgent之后会自动进行加载的插件，稳定插件在agent/plugins目录下。
  • 可选插件：不会自动进行加载的插件。在agent/optional-plugins目录下，如果要使用可选插件，需要将对应插件的jar包复制到/agent/plugins目录下。

1. 稳定插件

2. 可选插件

2.2.4 高级特性

1. 配置覆盖

• 探针参数 > 系统属性 > 系统环境变量 > 配置文件

2. 自定义配置文件

3. 客户端采样

• agent.sample_n_per_3_secs=400代表SkyWalking只会采集3秒内的400个链路。

4. TLS

• 在互联网中传输数据时，TLS （Transport Layer Security，传输层安全性协议）是一种很常见的安全解决方案。TLS是建立在传输层TCP协议之上的协议，它会将应用层的报文进行加密后再交由TCP进行传输，这样就保证了传输数据的安全性。
• 在一些SkyWalking使用案例中，用户有如下使用背景：目标应用在一个区域（也称为VPC），SkyWalking后端在另一个区域(VPC)。两端之间通信的报文一旦被截获就会泄露传输的内容。因此，SkyWalking通过使用gRPC TLS来保证通信的安全性。其鉴权模式只支持no mutual auth。

5. 命名空间

• SkyWalking是一个监控工具，会从分布式系统中收集度量值。在真实世界中，大型分布式系统包含了成百上千的服务和服务实例。在这种情况下，很有可能不止一个小组，甚至不止一个公司在维护和监控分布式系统。每个小组或公司 掌管着不同的部分，他们不希望也不应该共享他们的度量值。

6. Application Toolkit API与OpenTracing API

• Application Toolkit API是SkyWalking提供的一些用户可以主动使用的工具API，其中包含日志与TraceId的整合、自定义某个方法的Trace、修改某个Span的信息，以及跨线程的链路追踪等。OpenTracing API则是SkyWalking基于OpenTracing标准实现的SkyWalking API，用户可以使用这些API手动构建分布式链路追踪的上下文。

2.3 后端与UI部署

• 本节将主要介绍SkyWalking项目的后端collector(OAP Server)和前端UI的部署方式，包括主要配置介绍及配置含义。你可以将SkyWalking的后端部署在物理机、虚拟机或者Kubernetes集群中。通过本节的学习，读者将了解到SkyWalking后端collector和前端UI是如何运行的，并能根据实际业务场景配置更加优化的参数。

2.3.1 SkyWalking部署介绍

2.3.2 快速启动

• JDK需要JDK 8及以上版本。
• 快速启动的SkyWalking只能用于初步了解和预览其功能，不能作为生产环境长期部署，关于如何在生产环境中部署，3.3节会具体讲解。
• 最简单的快速启动方式是进入skywalking目录后，在命令行直接执行**bin/startup.sh（Linux和Mac用户）或bin/startup.bat（Windows用户）**。startup会同时启动后端oapServer（对应启动脚本为oapService.sh）和UI模块（对应启动脚本为webappService.sh），启动成功后将会在控制台输出启动成功的日志。
• 快速启动会读取默认的配置文件，oapServer的默认配置文件在config目录中，UI模块的默认配置文件在webapp目录中。
• 正常情况下，控制台显示启动成功后，服务端oapServer就可以正常服务了。关于快速启动服务采用的存储和服务端口，可以参考如下说明。
  • 后端oapServer默认使用的存储为H2内存数据库，这样就不需要额外部署存储，可以参考config/application.yaml中storage的相关配置。
  • 后端oapServer默认会开启gRPC监听端口11800及HTTP RESTful的端口12800，用来接收多语言(Java、PHP、.Net Core、Node.js、Go)的Agent探针及Service Mesh中数据面的监控数据。
  • UI模块默认监听8080端口，用于前端页面访问，并且UI模块会将前端的所有后端请求(GraphQL)代理到后端oapServer的12800端口。

2.3.3 application.yaml详解

2.3.4 参数复写

• 虽然application.yaml提供了丰富灵活的配置，但是某些情况下用户还是需要针对某些节点或者每个节点有不同的配置，这时，可以采用启动参数或者环境变量进行覆盖。其中优先级顺序为，从启动参数指定、环境变量到application.yaml中具体配置依次递减。

2.3.5 IP和端口设置

• 在核心模块中，可以对后端OAP服务监听的IP和端口进行设置，特别是系统有多网卡多IP的时候，可以设置将OAP服务绑定在某一个IP上。

2.3.6 集群管理配置

• 在实际生产环境 中使用时，为了保证服务的稳定和健壮，需要对OAP后端采用集群模式进行部署 。本节将详细讲解如何对OAP后端进行集群管理，包括使用传统集群管理工具管理物理机集群，以及使用Kubernetes管理云原生集群。

1. 传统集群管理工具

• OAP目前支持4种集群管理工具：ZooKeeper、Consul、Nacos和etcd。

2. Kubernetes集群管理

• Kubernetes是一个开源的云原生容器化集群管理平台，目标是让部署容器化的应用简单且高效。SkyWalking后台可以非常容易地部署在该管理平台之中，而且受益于Kubernetes的高效管理，可以保证OAP和UI组件的高可用性。
• 对于在Kubernetes集群之中部署OAP集群，虽然我们可以用前面介绍的服务发现服务（如ZooKeeper、Consul等）进行集群管理，但Kubernetes平台本身就具备成为服务发现组件的能力，通过访问API Server可以获取到OAP各个实例的Endpoint的位置，从而实现集群中节点的互相访问。
• 2.3.7节有完整的部署实例。

3. 探针与集群通信

• 由前面的IP和端口设置可知，OAP服务端主要提供了gRPC和HTTP RESTful的接口方式接收客户端的数据。随着Skywalking项目的发展和演进，目前的客户端早已不是仅有Java Agent探针，还提供了多种语言（PHP、C#、Node.js、Go等）的探针 ，同时支持一些主流调用链平台的协议，如Zipkin和Jaeger，也支持目前非常盛行的Service Mesh框架Istio的遥测数据。OAP服务端将接收不同类型的数据，在application.yaml中分成了不同的配置，因此读者在配置文件中可以看到如下配置。

2.3.7 Kubernetes部署

2.3.8 后端存储

• SkyWalking后端存储实现了多种生产环境可用的存储形式，读者可以按照技术栈的要求和熟练程度自行选择。如果读者比较熟悉架构和代码，也可以按照提供的接口自行实现存储，目前已经支持的存储有Elasticsearch 6、MySQL和TiDB。

1. Elasticsearch

• 选择Elasticsearch作为存储，只需要将前文所说的application.yaml中的storage设置为 elasticsearch即可。目前，Elasticsearch也是大多数场景所使用的的存储形式，Elasticsearch 集群可以方便地管理和水平扩展，能够适应不同条件下监控数据量不同的业务场景。

2. MySQL/TiDB

3. 数据过期设置

• 在SkyWalking中，除了应用的元数据 外，还有以下两类可观测数据被持久化在存储系统中。
  • Record记录。包含追踪调用链路数据和告警记录信息，这种数据只会顺序记录，不会被聚合和更新。
  • Metric指标数据。比如各种维度 （all、service、endpoint等）的p99/p95/p90/p75/p50 （p为对应对百分位请求的响应时间，如p99表示99%的用户响应时间）的响应时间数据等、热力图、成功率、CPM（每分钟请求数）​、错误率等信息加粗样式**。这种Metric数据通常按照分钟、小时、天、月等维度进行统计并存储在不同的表中。
• 通常情况下，随着数据量的增加，为了节约存储空间、提高资源利用率，会按照一定的周期进行数据删除。

2.3.9 设置服务端采样率

• 在服务端设置采样率只会将部分trace调用链路数据丢弃，不会影响Metric数据（比如service、service instance、endpoint）统计的精确性，因而可以用来应对大量数据上报带来的存储系统压力。

2.3.10 告警设置

1. 告警规则配置

• 在SkyWalking中，你可以非常灵活地设置各种指标的告警，所有告警规则均配置在config/alarm-settings.yml中，该配置主要包含以下两个部分。
  • 告警规则配置。配置哪些指标达到什么条件需要报警的规则。
  • Webhooks。当告警触发后，用于告警的外部接口。
• 先来看一个示例配置，你可以针对不同的Metric按照某个指标和指定频率配置告警。
• 为了方便用户进行简易部署，SkyWalking默认的发布包中已经包含了一些常用的告警规则，可以到config/alarm-settings.yml中查看。

2. Webhooks

• 当告警规则达到触发条件后，需要通过Webhooks将告警信息发送到用户指定的Web服务上。

2.3.11 Exporter设置

2.3.12 UI部署详解

• UI的部署主要由部署webapp代理层和前端页面组成，由于apm-webapp在编译的时候会自动将skywalking-ui前端页面模块编译到最终的输出文件中，所以读者只需关心apm-webapp应该如何配置。apm-webapp的核心配置位于webapp/webapp.yml中 ，该配置文件主要包含以下两部分。
  • UI的监听端口，即通过浏览器访问页面的端口。
  • 后端OAP的端口。webapp本身没有业务逻辑，所有查询都是通过Zuul代理转发到OAP服务的REST服务端口，再通过GraphQL进行查询，默认地址为127.0.0.1:12800。
• 配置完成后，如果无异常，通过bin/webappService.sh(.bat)启动UI模块即可正常运行。

2.4 UI介绍

• SkyWalking的Dashboard分为上、中、下三块区域，上部是功能选择区，右上为自动刷新设置，下部是时间选择区，中间是面板内容。功能选择方面，各个版本会有所差别，图2-5为SkyWalking 7.0的官方UI效果图。
  

2.4.1 Dashboard介绍

• Dashboard提供服务、服务实例、Endpoint、数据库等多个实体维度的指标相关信息。
• 服务实例包含几个典型的指标，如图2-7所示。
  • CPM：每分钟调用数。
  • Apdex：一个标准的应用性能工业指标，读者可以在网上查询相关资料。
  • 平均响应时间和响应时间的百分位数：这里提一下，百分位数用于反映响应时间的长尾效应，例如p99=200ms，代表99%的请求响应时间可以小于等于200ms。
  • SLA：在SkyWalking中表示成功率。
    
• 数据库视图是根据应用探针采集的数据推算出的数据性能指标数据。此推算中的响应时间、成功率、慢SQL等均由客户端采集得到，其中包含网络问题、客户端程序故障造成的性能问题。

2.4.2 拓扑介绍

• 拓扑图是根据探针上行数据分析出的整体拓扑结构，如图2-8所示。拓扑图支持点击展现和下钻单个服务的性能统计、trace、告警，也可以通过点击拓扑图中的关系线，展现服务间、服务实例间的性能指标 ，如图2-9所示。
  
  

2.4.3 Trace视图

• Trace是分布式追踪的典型视图 ，SkyWalking提供了3种展现形式，分别是列表（见图2-10）、树结构（见图2-11）、表格（见图2-12）。不同视图允许用户从不同角度查看追踪数据，特别是Span间的耗时关系。
  
  
  

2.5 本章小结

• 本章从SkyWalking的项目编译和工程结构开始，逐步学习了SkyWalking的JavaAgent、后端和UI模块的部署与配置。相信你已经成功部署了自己的SkyWalking环境，体验了SkyWalking的便捷和强大。下一章，我们就进入生产环境进行实战！