在谈Nacos服务注册的时候,刚好看到了Skywalking分布式追踪系统,而这个本身也完全可以用于微服务架构里面的服务链监控上面。对于APM应用性能监控工具有很多,常说的主要是类似Zipkin,
Pinpoint,
Cat等,而Skywalking是国产的一款开源APM工具软件,包括了包括了分布式追踪、性能指标分析、应用和服务依赖分析等。
Skywalking和Pinpoint的对比
总结:经过前面对skywalking和Pinpoint全方位对比后我们发现,对于两款非常优秀的APM软件,有一种既生瑜何生亮的感觉。Pinpoint的优势在于:追踪数据粒度非常细、功能强大的用户界面,以及使用HBase作为存储带来的海量存储能力。而skywalking的优势在于:非常活跃的中文社区,支持多种语言的探针,对国产开源软件非常全面的支持,以及使用es作为底层存储带来的强大的检索能力,并且skywalking的扩展性以及定制化要更优于Pinpoint。
该项目由国人吴晟基于OpenTracking实现的开源项目skywalking,017年12月8日,Apache软件基金会孵化器项目管理委员会
ASF IPMC宣布“SkyWalking全票通过,进入Apache孵化器。
分布式追踪的三种场景
1. Metrics 指标性统计: 比如说我们会去做一个服务的 TBS
的正确率、成功率、流量等,这是我们常见的针对单个指标或者某一个数据库的,这就是 Metrics 单指标分析。
2. Tracing 分布式追踪:
这里提到的是一次请求的范围,也就是我们从浏览器或者手机端发起任何的一次调用,甚至我们可以再推广一点,是一次业务教育,比如说一次订购的过程,从浏览商品到最后下定单、支付、物流、最后交到我们的手上。这是一个流程化的东西,我们需要轨迹,需要去追踪。
3. Logging 日志记录:
我们程序在执行的过程中间发生了一些日志,会一帧一帧地跳出来给大家去记录这个东西,这是日志记录。
什么是分布式追踪
上图是常见的微服务的框架,4 个实例,2 个 MySQL、1 个
Redis。实际上它有两次完全不同的请求进来:有一次的一个请求会访问 Redis,再去访问
MySQL;另外一个可能走到另外的服务上,然后直接去
MySQL。整个分布式追踪的目的是什么?是为了让我们最终在页面上、UI上、和数据上能够复现这个过程。我们要拿到整个完整的链路,包括精确的响应时间,访问的方法、访问的
circle,访问的 Redis 的 key等,这些是我们在做分布式追踪的时候需要展现的一个完整的信息。
什么是 OpenTracing
开发和工程团队因为系统组件水平扩展、开发团队小型化、敏捷开发、CD(持续集成)、解耦等各种需求,正在使用现代的微服务架构替换老旧的单片机系统。
也就是说,当一个生产系统面对真正的高并发,或者解耦成大量微服务时,以前很容易实现的重点任务变得困难了。
过程中需要面临一系列问题:用户体验优化、后台真是错误原因分析,分布式系统内各组件的调用情况等。
当代分布式跟踪系统(例如,Zipkin, Dapper, HTrace,
X-Trace等)旨在解决这些问题,但是他们使用不兼容的API来实现各自的应用需求。尽管这些分布式追踪系统有着相似的API语法,但各种语言的开发人员依然很难将他们各自的系统(使用不同的语言和技术)和特定的分布式追踪系统进行整合,OpenTracing
通过提供平台无关、厂商无关的 API,使得开发人员能够方便的添加(或更换)追踪系统的实现。 OpenTracing
提供了用于运营支撑系统的和针对特定平台的辅助程序库。
OpenTracing 是一个规范,它不是一个数据结构,能提供的是语音和概念。OpenTracing
要涵盖的是中间的一层,它是要实现的是一套 API 的套件。你需要按照 OpenTracing 的规范向用户提供
API,实现把数据下送到 API 的探针或者 Tracer 的探针。OpenTracing
的主旨是在做手动埋点,程序的开发者要主动调用 Tracing 的 API 。我们这里主要是在讲 java ,而不是在讲例如
go、c++、c 等不太好写自动探针的语言。
Skywalking总体架构
Skywalking
是一个APM系统,即应用性能监控系统,为微服务架构和云原生架构系统设计。它通过探针自动收集所需的指标,并进行分布式追踪。通过这些调用链路以及指标,Skywalking
APM会感知应用间关系和服务间关系,并进行相应的指标统计。目前支持链路追踪和监控应用组件如下,基本涵盖主流框架和容器,如国产PRC
Dubbo和motan等,国际化的Spring boot,Spring cloud都支持了。
SkyWalking 的核心是数据分析和度量结果的存储平台,通过 HTTP 或 gRPC 方式向 SkyWalking
Collecter 提交分析和度量数据,SkyWalking Collecter 对数据进行分析和聚合,存储到
Elasticsearch、H2、MySQL、TiDB 等其一即可,最后我们可以通过 SkyWalking UI
的可视化界面对最终的结果进行查看。
Skywalking总体架构分为三个部分内容
skywalking-collector:链路数据归集器,数据可以落地ElasticSearch,单机也可以落地H2,不推荐,H2仅作为临时演示用
skywalking-web:web可视化平台,用来展示落地的数据
skywalking-agent:探针,用来收集和发送数据到归集器
整体架构看似模块有点多,但在实际上还是比较清晰的,主要就是通过收集各种格式的数据进行存储,然后展示。所以搭建
Skywalking 服务我们需要关注的是 SkyWalking Collecter、SkyWalking UI 和
存储设备,SkyWalking Collecter、SkyWalking UI
官方下载安装包内已包含,最终我们只需考虑存储设备即可。
Skywalking关键特性
1. 性能好,针对单实例5000tps的应用,在全量采集的情况下,只增加 10% 的CPU开销。
2. 支持多语言探针
3. 支持自动及手动探针
自动探针:Java支持的中间件、框架与类库列表;
手动探针:OpenTrackingApi、@Trace注解、trackId集成到日志中。
4. 采用探针技术,在使用过程中,完全是0代码,无侵入,分布式自动采集与监控系统运行;
Skywalking实践
Skywalking学习引导
Skywalaking的安装和使用
1. 部署Java agent
拷贝agent目录到所需位置.
日志,插件和配置都包含在包中,请不要改变目录结构.建议将该agent目录与客户端应用放在同一台服务器,多台服务器需要监控则都部署agent目录,每台服务器上的应用配置本机的agent参数。
增加JVM启动参数,
-javaagent:/path/to/skywalking-agent/skywalking-agent.jar.
参数值为skywalking-agent.jar的绝对路径。
可以看到这种代理方式的启动和探针的引入基本对你原来的项目和代码无侵入。
2.配置Collector-所需的第三方软件
JDK6+(被监控的应用程序运行在jdk6及以上版本)
JDK8+(SkyWalking collector和WebUI部署在jdk8及以上版本)
Elasticsearch 5.x(集群模式或不使用)
Zookeeper 3.4.10(单机可不使用)
被监控应用的宿主服务器系统时间(包含时区)与collectors,UIs部署的宿主服务器时间设置正确且相同。具体详细的配置和部署可以参考官方文档。