用SkyWalking作分布式追踪和应用性能监控系统

【转载请注明出处】：http://www.javashuo.com/article/p-kfelrwfm-nq.html

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编码放入data_binary字段而且将字段标记为not_analyzed来避免进行预处理创建查询索引

整体来讲，Skywalking尽可能使用ES在大数据和查询方面的优点，同时尽可能减小ES数据密度低的劣势带来的影响，从目前来看，ES在调用链跟踪方面是不二的数据容器，而在数据指标方面，ES也能中规中矩的完成业务，虽然和时序数据库相比要弱一些，但在PB级如下的数据支持也不会有太大问题。

数据结构

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

• 数据维度（ES索引为skywalking_*_inventory)

  1. service：服务
  2. instance：实例
  3. endpoint：接口
  4. network_adress：外部依赖

• 数据内容

  1. 原始数据

     • 调用链跟踪数据（调用链的trace信息，ES索引为skywalking_segment，Skywalking主要的数据消耗都在这里）
     • 指标（主要是jvm或者envoy的运行时指标，例如ES索引skywalking_instance_jvm_cpu）

  2. 二次统计指标

     • 指标（按维度/时间二次统计出来的例如pxx、sla等指标，例如ES索引skywalking_database_access_p75_month）
     • 数据库慢查询记录（数据库索引：skywalking_top_n_database_statement）
  3. 关联关系（维度/指标之间的关联关系，ES索引为skywalking_relation)

  4. 特别记录

     • 告警信息（ES索引为skywalking_alarm_record）
     • 并发控制（ES索引为skywalking_register_lock）

其中数量占比最大的就是调用链跟踪数据和各类指标，而这些数据都可以经过OAP设置过时时间，以下降历史数据的对磁盘占用和查询效率的影响。

调用链跟踪数据

做为Skywalking的核心数据，调用链跟踪数据（skywalking_segment）基本上奠基了整个系统的基础，而若是要详细的了解调用链跟踪的话，就不得不提到openTracing。

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

其中：

• SpanContext：一个相似于MDC（Slfj)或者ThreadLocal的组件，负责整个调用链数据采集过程当中的上下文保持和传递

• Trace：一次调用的完整记录

  • Span：一次调用中的某个节点/步骤，相似于一层堆栈信息，Trace是由多个Span组成，Span和Span之间也有父子或者并列的关系来标志这个节点/步骤在整个调用中的位置

    • Tag：节点/步骤中的关键信息
    • Log：节点/步骤中的详细记录，例如异常时的异常堆栈
  • Baggage：和SpanContext同样并不属于数据结构而是一种机制，主要用于跨Span或者跨实例的上下文传递，Baggage的数据更可能是用于运行时，而不会进行持久化

以一个Trace为例：

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

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

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

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

{
    "trace_id": "52.70.15530767312125341",
    "endpoint_name": "Mysql/JDBI/Connection/commit",
    "latency": 0,
    "end_time": 1553076731212,
    "endpoint_id": 96142,
    "service_instance_id": 52,
    "version": 2,
    "start_time": 1553076731212,
    "data_binary": "CgwKCjRGnPvp5eikyxsSXhD///////////8BGMz62NSZLSDM+tjUmS0wju8FQChQAVgBYCF6DgoHZGIudHlwZRIDc3FsehcKC2RiLmluc3RhbmNlEghyaXNrZGF0YXoOCgxkYi5zdGF0ZW1lbnQYAiA0",
    "service_id": 2,
    "time_bucket": 20190320181211,
    "is_error": 0,
    "segment_id": "52.70.15530767312125340"
}

其中：

• trace_id：本次调用的惟一id，经过snowflake模式生成
• endpoint_name：被调用的接口
• latency：耗时
• end_time：结束时间戳
• endpoint_id：被调用的接口的惟一id
• service_instance_id：被调用的实例的惟一id
• version：本数据结构的版本号
• start_time：开始时间戳
• data_binary：里面保存了本次调用的全部Span的数据，序列化并用Base64编码，不会进行分析和用于查询
• service_id：服务的惟一id
• time_bucket：调用所处的时段
• is_error：是否失败
• segment_id：数据自己的惟一id，相似于主键，经过snowflake模式生成

这里能够看到，目前Skywalking虽然相较于Pinpoint来讲查询的维度要多一些，可是也颇有限，并且除了endPoint，并无和业务有关联的字段，只能经过时间/服务/实例/接口/成功标志/耗时来进行非业务相关的查询，若是后续要加强业务相关的搜索查询的话，应该还须要增长一些用于保存动态内容（如messageId，orderId等业务关键字）的字段用于快速定位

指标

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

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

{
    "total": 8900,
    "service_id": 5,
    "time_bucket": 2019031816,
    "service_instance_id": 5,
    "entity_id": "7",
    "value": 148
}

各个字段的释义以下：

• total：一分钟内的调用总量
• service_id：所属服务的惟一id
• time_bucket：统计的时段
• service_instance_id：所属实例的惟一id
• entity_id：接口（endpoint）的惟一id
• value：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均可以接入。

安装

1. 下载最新的安装包
2. 解压，并进入bin目录执行startup.sh启动
3. 访问http://localhost:8080/ 便可看到面板
4. 启动服务
   添加以下VM 参数：

-javaagent:${agent_home}/agent/skywalking-agent.jar -Dskywalking.agent.service_name=${service_name}

【转载请注明出处】：http://www.javashuo.com/article/p-kfelrwfm-nq.html