系统监控-分布式调用链Skywalking

1. 为什么要使用分布式调用链技术？

随着公司业务的高速发展，公司服务之间的调用关系愈加复杂，如何理清并跟踪它们之间的调用关系就显的比较关键。线上每一个请求会经过多个业务系统，并产生对各种缓存或者 DB 的访问，但是这些分散的数据对于问题排查，或者流程优化提供的帮助有限。在这样复杂的业务场景下，业务流会经过很多个微服务的处理和传递，我们难免会遇到这些问题：

• 一次请求的流量从哪个服务而来？ 最终落到了哪个服务中去？
• 为什么这个请求这么慢? 到底哪个环节出了问题?
• 这个操作需要依赖哪些东西? 是数据库还是消息队列?
• Redis挂了，哪些业务受影响?

2. 开源产品从多，可以从如下几个方面去选型。

我们需要达到的目标：

• 低消耗性：跟踪系统对业务系统的影响应该做到足够小。在一些高度优化过的服务，即使一点点损耗也容易察觉到，而且有可能迫使在线负责的部署团队不得不将跟踪系统关停
• 低侵入性：作为非业务组件，应当尽可能少侵入或者无侵入业务系统，对于使用方透明，减少开发人员的负担
• 时效性：从数据的收集产生，到数据计算处理，再到最终展现，都要求尽可能快
• 决策支持：这些数据是否能在决策支持层面发挥作用，特别是从 DevOps 的角度
• 数据可视化：做到不用看日志通过可视化进行筛选

实现的功能：

• 故障定位：调用链路跟踪，一次请求的逻辑轨迹可以完整清晰的展示出来。
• 性能分析：调用链的各个环节分别添加调用耗时，可以分析出系统的性能瓶颈，并针对性的优化。
• 数据分析：调用链是一条完整的业务日志，可以得到请求的行为路径，汇总分析应用在很多业务场景。

开源产品：

• Twitter 公司开源的分布式追踪系统 Zipkin 
• 韩国人开源的分布式跟踪组件 Pinpoint
• 国产的优秀APM组件 Skywalking，
• 其他类似的组件还有美团点评的 CAT。

分布式调用链和传统的新能监控有什么区别？

APM工具与传统的性能监控工具的区别在于，不仅仅提供一些零散的资源监控点和指标，其主要关注在系统内部执行、系统间调用的性能瓶颈分析，这样更有利于定位到问题的具体原因。

社区活跃度：

性能分析： 

3. 综上多个方面最终选择Skywalking，下面主要围绕Skywalking进行展开。

搭建Skywalking需要安装的组件（windows为例）：

• elasticsearch-5.6.2（ES/data目录为ES数据存放目录，可以通过删除该目录清空数据，ES/config/elasticsearch.yml配置cluster name、node.name）
• ES和head插件（需要安装Node.js），安装参考博客：windows下ES和head插件的安装（一个界面化的集群操作和管理工具）
• 下载apache-skywalking-apm-incubating-5.0.0-GA，详细介绍可以参考博客：skywalking学习笔记
  • agent：探针，用来收集和发送数据到归集器（在/apm/agent/config/agent.config主要配置collector地址和应用名称，一般都是一个项目对应一个agent目录）。
  • collector：链路数据归集器，数据可以落地ElasticSearch，单机也可以落地H2，不推荐，H2仅作为临时演示用（在/apm/config/application.yml主要配置ES）。
  • web：web可视化平台，用来展示落地的数据。
  • ui：单独的开源ui项目，更美观易用。

搭建过程中需要注意的事：

• 需要在/apm/collector-libs下放入mysql-connector-java-5.1.47.jar包。
• 所有软件的目录尽量不要放在带有空格的目录下（如：Program Files），ES除外。
• 多服务器搭建需要考虑时区不一致问题。

多组件启动顺序：

ES、ES head、/apm/bin/startup.bat、使用java命令指定-javaagent:skywalking-agent.jar去启动应用（war、jar）去运行应用、访问web查看agent注册情况。

相关软件请移步到码云或网盘上下载（相关软件都亲测成功，请放心使用）：

https://gitee.com/qrmc/oschina_software_package

链接：https://pan.baidu.com/s/1nCa0Xipj-5tD3nc-3g-QdQ  提取码：wdxu 

4. 总结：待应用实战后总结优缺点...