随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。

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

原理图

说几个碰到的坑:

1. mysql 支持,github下载下来的包默认没有驱动,如果你要用mysql来存储数据,需要把mysql-connector-java-5.1.46.jar 放到oap-libs目录下
2. 数据自动清除,默认删除90分钟前的数据
3. 使用 端点面板 中 全局最慢端点追踪 中复制的id 去搜索是搜不到的,必须要加1
4. 时区必须保持一致:Ubuntu18.04 设置时区.必须要用
5. 不能使用域名,只能使用IP(碰到连接异常或者agent注册不上可以试试)

timedatectl set-timezone "Asia/Shanghai"

docker 中设置时区可以用

    environment:
      - TZ=Asia/Shanghai

主界面

提供全局视图,主要展示了所有被监控服务的总体信息

具体有:

全局热图

提供每分钟响应时间的统计数据

全局响应百分比

(大于) 过去 10 秒内最慢的 x% 的请求的平均延迟，其中 x 是数字与 100 之差。例如，p99 1.403 表示过去 10 秒内最慢的 1% 请求的平均延迟为 1.403 秒。
(ps:这句话很拗口)

全局概况

全局最大吞吐量

每个服务每分钟调用次数

全局最慢端点

服务面板

主要提供当前选中服务的基础信息

全局概况

服务平均响应时间

服务平均吞吐量

该服务每分钟调用次数

服务平均可用性

通过请求成功与失败次数来计算(来源:http://blog.itpub.net/31562043/viewspace-2305574/)

全局响应百分比

过去 10 秒内最慢的 x% 的请求的平均延迟，其中 x 是数字与 100 之差。例如，p99 1.403 表示过去 10 秒内最慢的 1% 请求的平均延迟为 1.403 秒。

服务响应百分比

过去 10 秒内最慢的 x% 的请求的平均延迟，其中 x 是数字与 100 之差。例如，p99 1.403 表示过去 10 秒内最慢的 1% 请求的平均延迟为 1.403 秒。

服务最慢端点

该服务下响应最慢的端点

运行中的实例

端点面板

主要提供当前选中端点的基础信息

全局概况

端点平均响应时间

端点平均吞吐量

该端点每分钟调用次数

端点平均可用性

通过请求成功与失败次数来计算(来源:http://blog.itpub.net/31562043/viewspace-2305574/)

全局响应百分比

过去 10 秒内最慢的 x% 的请求的平均延迟，其中 x 是数字与 100 之差。例如，p99 1.403 表示过去 10 秒内最慢的 1% 请求的平均延迟为 1.403 秒。

端点响应百分比

过去 10 秒内最慢的 x% 的请求的平均延迟，其中 x 是数字与 100 之差。例如，p99 1.403 表示过去 10 秒内最慢的 1% 请求的平均延迟为 1.403 秒。

依赖关系图

最慢端点追踪

默认显示该服务下的最慢的十条记录,可以点击右侧的图标复制追踪ID进行查询详细信息

全局最慢端点

默认显示全局的最慢的十条记录,可以点击右侧的图标复制追踪ID进行查询详细信息

实例面板

实例信息

该选中实例基础信息(语言,系统,主机名,流程号,ip)

实例平均吞吐量

该实例每分钟调用次数

实例平均响应时间

该实例平均响应时间

实例平均可用性

通过请求成功与失败次数来计算(来源:http://blog.itpub.net/31562043/viewspace-2305574/)

jvm 垃圾回收耗时

新生代,老年代

jvm 堆内存

jvm 非堆内存

jvm cpu

clr cpu

clr 堆内存

clr gc

拓扑图面板

接口请求的拓扑图

追踪面板

左上角可以输入追踪ID进行搜索

点击任意节点进行查询详情