整体主要分为三个部分:
1.skywalking-collector:链路数据归集器,数据可以保存在H2或ElasticSearch
2.skywalking-web:web的可视化管理后台,可以查看归集的数据
3.skywalking-agent:探针,用来收集和推送数据到归集器
特点
- 性能好:针对单实例5000tps的应用,在全量采集的情况下,只增加 10% 的CPU开销
- 支持多语言探针
- 支持自动及手动探针:其中手动探针通过OpenTrackingApi、@Trace注解、trackId集成到日志中。
通过在应用程序中添加 SkyWalking Agent,就可以将接口、服务、数据库、MQ等进行追踪,将追踪结果通过 HTTP 或 gRPC 发送到 SkyWalking Collecter,SkyWalking Collecter 经过分析和聚合,将结果存储到 Elasticsearch 或 H2,SkyWalking 同时提供了一个 SkyWalking UI 的可视化界面,UI 以 GraphQL + HTTP 方式获取存储数据进行展示。
java项目接入skywalking
只需在项目目录下增加skywalking目录,然后再启动参数中增加jvm参数即可:
-javaagent:/path/to/skywalking-agent/skywalking-agent.jar
同时,我们也可以修改config文件夹中agent.config的相关配置
skywalking是一个开放源码的,用于收集、分析,聚合,可视化来自于不同服务和本地基础服务的数据的可观察的平台,
skywalking提供了一个简单的方法来让你对你的分布式系统甚至是跨云的服务有清晰的了解。
它更像是一个现代的系统性能管理,特别为分布式系统而设计。
skywalking提供了在很多不同的场景下用于观察和监控分布式系统的方式。
首先,像传统的方法,skywalking为java,c#,Node.js等提供了自动探针代理.
同时,它为Go,C++提供了手工探针。
随着本地服务越来越多,需要越来越多的语言,掌控代码的风险也在增加,
Skywalking可以使用网状服务探针收集数据,以了解整个分布式系统。
通常,skywalking提供了观察service,service instance,endpoint的能力。
service: 一个服务
Service Instance: 服务的实例(1个服务会启动多个节点)
Endpoint: 一个服务中的其中一个接口
第二步:启动skywalking收集器服务,启动脚本是E:\apache-skywalking-apm-bin\bin\startup.sh,启动之后我们就可以访问http://localhost:8080/就可以看到skywalking的ui界面了。
第三步:启动项目: 拷贝skywalking-agent目录到所需位置,探针包含整个目录,请不要改变目录结构,可修改agent.config配置agent.application_code=xxl-job为自己的应用名
增加JVM启动参数,-javaagent:/path/to/skywalking-agent/skywalking-agent.jar。参数值为skywalking-agent.jar的绝对路径。
通过以上几步之后,我们就可以直接访问我们的项目的接口,看skywalking界面上能否收集到我们的调用信息了。
下图为skywalking的首页,主要展示全局的性能信息。
3.skywalking的traceId与日志组件(log4j,logback,elk等)的集成:
以logback为例,只要在日志配置xml中增加以下配置,则在打印日志的时候,自动把当前上下文中的traceId加入到日志中去。
4.skywalking告警模块的使用:
下图为告警页面的ui界面,可以看到可以从三个维度来监控,分别为服务(service)、服务实例(service instance),端点(endpoint/接口)。
告警规则可以在安装包下的配置文件-(apache-skywalking-apm-bin/config/alarm-settings.yml)中,自由定义。
默认配置监控服务和服务实例,不监控端点,因为 # Active endpoint related metrics alarm will cost more memory than service and service instance metrics alarm.# Because the number of endpoint is much more than service and instance.
5.skywalking的原理:
skywalaking总体架构分为三部分:
- skywalking-collector:链路数据归集器,数据可以落地ElasticSearch,单机也可以落地H2,不推荐,H2仅作为临时演示用
- skywalking-web:web可视化平台,用来展示落地的数据
- skywalking-agent:探针,用来收集和发送数据到归集器
skywalking的核心在于agent部分,下图展示了一次调用跨多个进程里agent的详细的运行过程:
以拦截dubbo请求为例,skywalking的dubbo拦截插件实现的代码实现:
源码使用的是拦截dubbo中的MonitorFilter
这个类中的invoke
方法。具体如DubboInterceptor所示,通过获取dubbo的上下文RpcContext
先对消费者调用之前加入sky walking的跨进程协议header信息sw:traceId
,然后到生产者取出。
在调用结束后结束,把span的详情信息发送给collector(数据收集器).具体实现在类org.apache.skywalking.apm.agent.core.context.TracingContext的stopSpan(AbstractSpan span)方法,
下面是stopSpan的具体实现方法:
5.skywalking的限制
1.只支持已知的代理,如果使用的中间件还未被支持,需要自己写插件。
2.跨线程的场景不支持自动代理,比如任务分配,任务池,批处理的场景。
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
架构设计
背景
对于APM来说,自动探针和手动探针,只是关于如何实现监控的技术细节。这些和架构设计无关。因此在本文档中,我们将它们仅视为客户端库。
基本原则
SkyWalking架构的基本设计原则包括易于维护、可控和流式处理。
为了实现这些目标,SkyWalking后端采用以下设计。
- 模块化设计。
- 多种客户端连接方式。
- 后端集群服务发现机制。
- 流模式。
- 可切换的存储模块。
模块化
SkyWalking后端基于纯模块化设计。用户可以根据自己的需求切换或组装后端功能。
模块
模块定义了一组特性,这些特性可以包括技术库(如:gRPC/Jetty服务器管理)、跟踪分析(如:跟踪段或zipkin span解析器)或聚合特性。 这些完全由模块定义及其模块实现来决定。
每个模块都可以在Java接口中定义它们的服务,每个模块的提供者都必须为这些服务提供实现者。 提供者应该基于自己的实现定义依赖模块。这意味着,即使两个不同的模块实现者,也可以依赖不同的模块。
此外,后端模块化core还检查启动序列,如果没有发现周期依赖或依赖,后端应该被core终止。
后端启动所有模块,这些模块的配置在application.yml
中是分离的。在这个yaml文件中:
- 根级别是模块名称,例如
cluster
、naming
等。 - 第二级别是模块的实现者的名称,例如
zookeeper
是cluster
等模块。 - 第三级是实现者的具体属性。例如
hostPort
和sessionTimeout
是zookepper
的必需属性。
yaml文件的一部分举例
cluster:
zookeeper:
hostPort: localhost:2181
sessionTimeout: 100000
naming:
jetty:
#OS real network IP(binding required), for agent to find collector cluster
host: localhost
port: 10800
contextPath: /
多种连接方式
首先,后端提供两种类型的连接,也即提供两种协议(HTTP和gRPC):
- HTTP中的命名服务,它返回后端群集中的所有可用collector地址。
- 在gRPC(SkyWalking原生探针的主要部分)和HTTP中使用上行链路服务,它将跟踪和度量数据上传到后端。 每个客户端将只向单个collector发送监视数据(跟踪和度量)。如果与连接的后端在某个时刻断开连接将会尝试连接其它的后端。
比如在SkyWalking Java探针中
collector.servers
表示命名服务,将naming/jetty/ip:port
映射为HTTP请求地址。collector.direct_servers
表示直接设置上行服务,并使用gRPC发送监控数据。
客户端库和后端集群之间的流程图
Client lib Collector1 Collector2 Collector3
(Set collector.servers=Collector2) (Collector 1,2,3 constitute the cluster)
|
+-----------> naming service ---------------------------->|
|
|<------- receive gRPC IP:Port(s) of Collector 1,2,3---<--|
|
|Select a random gRPC service
|For example collector 3
|
|------------------------->Uplink gRPC service----------------------------------->|
Collector 集群发现
当Collector以群集模式运行时,后端必须以某种方式相互发现。默认情况下,SkyWalking使用Zookeeper进行协调,并作为实例发现的注册中心。
通过以上部分(多个连接方式),客户端库将不会使用Zookeeper来查找集群。我们建议客户不要这么做。因为集群发现机制是可切换的,由模块化核心提供。依赖它会破坏可切换能力。 我们希望社区提供更多的实现者来进行集群发现,例如Eureka,Consul,Kubernate等。
流模式
流模式类似轻量级storm/spark的实现,它允许使用API构建流处理图(DAG)以及每个节点的输入/输出数据协定。
新模块可以查找和扩展现有的流程图。
处理中有三种情况
- 同步过程,传统方法调用。
- 异步过程,又叫做基于队列缓冲区的批处理。
- 远程过程,汇总后端的汇总。以这种方式,在节点中定义选择器以决定如何在集群中找到collector。(HashCode,Rolling,ForeverFirst是支持的三种方式)
通过具备的这些功能,collector集群像流式网络一样运行着去聚合、度量标准监控信息,并且不依赖于存储模块的实现来支持并发地编写相同的度量id。
可切换存储实现器
由于流模式负责并发,因此存储模块的实现的职责是提供高速写入和组合查询。
目前,我们支持ElasticSearch作为主要实现模块,H2用于预览版本,以及由Sharding Shpere项目管理的MySQL关系数据库集群。
Web 界面
除了后端设计的原则,UI是SkyWalking的另一个核心组件。它基于React,Antd和Zuul代理实现,提供后端集群发现、查询调度和可视化的功能。
Web UI以多连接方式中的相似的流程机制作为客户端的1.naming
、2.uplink
。唯一的区别是,在ui/jetty/yaml
定义下的主机和端口上(默认值:localhost:12800)用HTTP绑定中的GraphQL查询协议替换上行。
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
目前Skywalking已经支持从6个可视化维度剖析分布式系统的运行情况。
- 总览视图是应用和组件的全局视图,其中包括组件和应用数量,应用的告警波动,慢服务列表以及应用吞吐量;
- 拓扑图从应用依赖关系出发,展现整个应用的拓扑关系;
- 应用视图则是从单个应用的角度,展现应用的上下游关系,TopN的服务和服务器,JVM的相关信息以及对应的主机信息。
- 服务视图关注单个服务入口的运行情况以及此服务的上下游依赖关系,依赖度,帮助用户针对单个服务的优化和监控;
- 调用链展现了调用的单次请求经过的所有埋点以及每个埋点的执行时长;
- 告警视图根据配置阈值针对应用、服务器、服务进行实时告警。
Dubbo与Apache Skywalking(Incubator)
编写Dubbo示例程序
Dubbo实例程序已上传到Github仓库中。方便大家下载使用。
API工程
服务接口:
|
Dubbo服务提供工程
|
Consumer工程
|
部署Apache Skywalking(Incubator)
Apache Skywalking(Incubator)共提供两种部署模式:单节点模式和集群模式,以下为单节点模式部署步骤,集群模式部署详情参考文档。
依赖第三方组件
- JDK8+
- Elasticsearch 5.x
部署步骤
- 下载 Apache Skywalking Collector
- 部署ElasticSearch
- 修改elasticsearch.yml文件,并设置
cluster.name
设置成CollectorDBCluster
。此名称需要和collector配置文件一致。 - 修改ES配置
network.host
值,将network.host
的值修改成0.0.0.0
。 - 启动Elasticsearch
- 修改elasticsearch.yml文件,并设置
- 解压并启动Skywalking Collector。运行
bin/startup.sh
命令即可启动Skywalking Collector
启动示例程序
在启动示例程序之前,执行编译打包的命令:
|
启动服务提供端
|
启动服务消费端
|
访问消费端提供的服务
|
Skywalking监控截图:
首页
拓扑图
应用视图
JVM信息
服务视图
服务消费端:
服务提供端:
Trace视图
Span信息: