skywalking前端_用SkyWalking做分布式追踪和应用性能监控系统

SkyWalking 是观察性分析平台和应用性能管理系统。提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。

特性：

多种监控手段，语言探针和service mesh多语言自动探针，Java，.NET Core和Node.JS轻量高效，不需要大数据模块化，UI、存储、集群管理多种机制可选支持告警优秀的可视化方案Skywalking 技术架构

整个系统分为三部分：

agent：采集tracing(调用链数据)和metric(指标)信息并上报OAP：收集tracing和metric信息通过analysis core模块将数据放入持久化容器中(ES，H2(内存数据库)，mysql等等)，并进行二次统计和监控告警webapp：前后端分离，前端负责呈现，并将查询请求封装为graphQL提交给后端，后端通过ribbon做负载均衡转发给OAP集群，再将查询结果渲染展示Skywalking也提供了其他的一些特性：

配置重载：支持通过jvm参数覆写默认配置，支持动态配置管理集群管理：这个主要体现在OAP，通过集群部署分担数据上报的流量压力和二次计算的计算压力，同时集群也可以通过配置切换角色，分别面向数据采集(collector)和计算(aggregator，alarm)，需要注意的是agent目前不支持多collector负载均衡，而是随机从集群中选择一个实例进行数据上报支持k8s和mesh支持数据容器的扩展，例如官方主推是ES，通过扩展接口，也可以实现插件去-- 支持其他的数据容器支持数据上报receiver的扩展，例如目前主要是支持gRPC接受agent的上报，但是也可以实现插件支持其他类型的数据上报(官方默认实现了对Zipkin，telemetry和envoy的支持)支持客户端采样和服务端采样，不过服务端采样最有意义官方制定了一个数据查询脚本规范：OAL(Observability Analysis Language)，语法类似Linq，以简化数据查询扩展的工作量支持监控预警，通过OAL获取数据指标和阈值进行对比来触发告警，支持webhook扩展告警方式，支持统计周期的自定义，以及告警静默防止重复告警数据容器

由于Skywalking并没有自己定制的数据容器或者使用多种数据容器增加复杂度，而是主要使用ElasticSearch(当然开源的基本上都是这样来保持简洁，例如Pinpoint也只使用了HBase)，所以数据容器的特性以及自己数据结构基本上就限制了业务的上限，以ES为例：

ES查询功能异常强大，在数据筛选方面碾压其他所有容器，在数据筛选潜力巨大(Skywalking默认的查询维度就比使用HBase的Pinpoint强很多)支持sharding分片和replicas数据备份，在高可用/高性能/大数据支持都非常好支持批量插入，高并发下的插入性能大大增强数据密度低，源于ES会提前构建大量的索引来优化搜索查询，这是查询功能强大和性能好的代价，但是链路跟踪往往有非常多的上下文需要记录，所以Skywalking把这些上下文二进制化然后通过Base64编码放入databinary字段并且将字段标记为notanalyzed来避免进行预处理建立查询索引总体来说，Skywalking尽量使用ES在大数据和查询方面的优势，同时尽量减少ES数据密度低的劣势带来的影响，从目前来看，ES在调用链跟踪方面是不二的数据容器，而在数据指标方面，ES也能中规中矩的完成业务，虽然和时序数据库相比要弱一些，但在PB级以下的数据支持也不会有太大问题。

数据结构

如果说数据容器决定了上限，那么数据结构则决定了实际到达的高度。Skywalking的数据结构主要为：

数据维度(ES索引为skywalking*inventory)service：服务instance：实例endpoint：接口networkadress：外部依赖数据内容告警信息(ES索引为skywalkingalarmrecord)并发控制(ES索引为skywalkingregisterlock)指标(按维度/时间二次统计出来的例如pxx、sla等指标，例如ES索引skywalkingdatabaseaccessp75month)数据库慢查询记录(数据库索引：skywalkingtopndatabasestatement)调用链跟踪数据(调用链的trace信息，ES索引为skywalkingsegment，Skywalking主要的数据消耗都在这里)指标(主要是jvm或者envoy的运行时指标，例如ES索引skywalkinginstancejvmcpu)关联关系(维度/指标之间的关联关系，ES索引为skywalking*relation*)特别记录二次统计指标原始数据其中数量占比最大的就是调用链跟踪数据和各种指标，而这些数据均可以通过OAP设置过期时间，以降低历史数据的对磁盘占用和查询效率的影响。

调用链跟踪数据

作为Skywalking的核心数据，调用链跟踪数据(skywalkingsegment)基本上奠定了整个系统的基础，而如果要详细的了解调用链跟踪的话，就不得不提到openTracing。

openTracing基本上是目前开源调用链跟踪系统的一个事实标准，它制定了调用链跟踪的基本流程和基本的数据结构，同时也提供了各个语言的实现。如果用一张图来表现openTracing，则是如下：

openTracing基本结构

其中：

SpanContext：一个类似于MDC(Slfj)或者ThreadLocal的组件，负责整个调用链数据采集过程中的上下文保持和传递Trace：一次调用的完整记录Tag：节点/步骤中的关键信息Log：节点/步骤中的详细记录，例如异常时的异常堆栈Span：一次调用中的某个节点/步骤，类似于一层堆栈信息，Trace是由多个Span组成，Span和Span之间也有父子或者并列的关系来标志这个节点/步骤在整个调用中的位置Baggage：和SpanContext一样并不属于数据结构而是一种机制，主要用于跨Span或者跨实例的上下文传递，Baggage的数据更多是用于运行时，而不会进行持久化以一个Trace为例：

span间的关系

首先是外部请求调用A，然后A依次同步调用了B和C，而B被调用时会去同步调用D，C被调用的时候会依次同步调用E和F，F被调用的时候会通过异步调用G，G则会异步调用H，最终完成一次调用。

上图是通过Span之间的依赖关系来表现一个Trace，而在时间线上，则可以有如下的表达：

span的调用顺序

当然，如果是同步调用的话，父Span的时间占用是包括子Span的时间消耗的。

而落地到Skywalking中，我们以一条skywalkingsegment的记录为例：

{"traceid":"52.70.15530767312125341","endpointname":"Mysql/JDBI/Connection/commit","latency":0,"endtime":1553076731212,"endpointid":96142,"serviceinstanceid":52,"version":2,"starttime":1553076731212,"databinary":"CgwKCjRGnPvp5eikyxsSXhD///8BGMz62NSZLSDM+tjUmS0wju8FQChQAVgBYCF6DgoHZGIudHlwZRIDc3FsehcKC2RiLmluc3RhbmNlEghyaXNrZGF0YXoOCgxkYi5zdGF0ZW1lbnQYAiA0","serviceid":2,"timebucket":20190320181211,"iserror":0,"segmentid":"52.70.15530767312125340"}其中：

traceid：本次调用的唯一id，通过snowflake模式生成endpointname：被调用的接口latency：耗时endtime：结束时间戳endpointid：被调用的接口的唯一idserviceinstanceid：被调用的实例的唯一idversion：本数据结构的版本号starttime：开始时间戳databinary：里面保存了本次调用的所有Span的数据，序列化并用Base64编码，不会进行分析和用于查询serviceid：服务的唯一idtimebucket：调用所处的时段iserror：是否失败segmentid：数据本身的唯一id，类似于主键，通过snowflake模式生成这里可以看到，目前Skywalking虽然相较于Pinpoint来说查询的维度要多一些，但是也很有限，而且除了endPoint，并没有和业务有关联的字段，只能通过时间/服务/实例/接口/成功标志/耗时来进行非业务相关的查询，如果后续要增强业务相关的搜索查询的话，应该还需要增加一些用于保存动态内容(如messageId，orderId等业务关键字)的字段用于快速定位

指标

指标数据相对于Tracing则要简单得多了，一般来说就是指标标志、时间戳、指标值，而Skywalking中的指标有两种：一种是采集的原始指标值，例如jvm的各种运行时指标(例如cpu消耗、内存结构、GC信息等)；一种是各种二次统计指标(例如tp性能指标、SLA等，当然也有为了便于查询的更高时间维度的指标，例如基于分钟、小时、天、周、月)

例如以下是索引skywalkingendpointcpmhour中的一条记录，用于标志一个小时内某个接口的cpm指标：

{"total":8900,"serviceid":5,"timebucket":2019031816,"serviceinstanceid":5,"entityid":"7","value":148}各个字段的释义如下：

total：一分钟内的调用总量serviceid：所属服务的唯一idtimebucket：统计的时段serviceinstanceid：所属实例的唯一identityid：接口(endpoint)的唯一idvalue：cpm的指标值(cpm=call per minute，即total/60)agent

agent(apm-sniffer)是Skywalking的Java探针实现，主要负责：

采集应用实例的jvm指标通过切向编程进行数据埋点，采集调用链数据通过RPC将采集的数据上报当然，agent还实现了客户端采样，不过在APM监控系统里进行客户端数据采样都是没有灵魂的，所以这里就不再赘述了。

首先，agent通过 org.apache.skywalking.apm.agent.core.boot.BootService 实现了整体的插件化，agent启动会加载所有的BootService实现，并通过 ServiceManager 来管理这些插件的生命周期，采集jvm指标、gRPC连接管理、调用链数据维护、数据上报OAP这些服务均是通过这种方式扩展。

然后，agent还通过bytebuddy以javaagent的模式，通过字节码增强的机制来构造AOP环境，再提供PluginDefine的规范方便探针的开发，最终实现非侵入性的数据埋点，采集调用链数据。

OAP

同agent类似，OAP作为Skywalking最核心的模块，也实现了自己的扩展机制，不过在这里叫做Module，具体可以参考library-module，在module的机制下，Skywalking实现了自己必须核心组件：

core：整个OAP核心业务(remoting、cluster、storage、analysis、query、alarm)的规范和接口cluster：集群管理的具体实现storage：数据容器的具体实现query：为前端提供的查询接口的具体实现receiver：接收探针上报数据的接收器的具体实现alarm：监控告警的具体实现以及一个可选组件：

telemetry：用于监控OAP自身的健康状况而前面提到的OAP的高扩展性则体现在核心业务的规范均定义在了core中，如果有需要自己扩展的，只需要自己单独做自己的实现，而不需要做侵入式的改动，最典型的示例则是官方支持的storage，不仅支持单机demo的内存数据库H2和经典的ES，连目前开源的Tidb都可以接入。

安装

下载最新的安装包解压，并进入bin目录执行startup.sh启动访问http://localhost:8080/即可看到面板启动服务添加如下VM 参数：-javaagent:${agenthome}/agent/skywalking-agent.jar -Dskywalking.agent.servicename=${servicename}