skyWalking-ui简介

基于v8.7.0版本
skyWalking-UI是一个纯前端的项目,使用的是vue+typescript,但是skywalking为了方便用户使用,直接使用了spring-gateway打包成了可执行jar,方便用户使用

UI概览

其实skywalking的UI每个界面进去点点,看看名字,差不多就那样,这里不会详细的介绍每个界面,但是会系统性的介绍一些重点的界面,以及一些缺失的功能

Global

  1. Services load（CPM - calls per minute）：服务平均每分钟请求数。
  2. Slow Services（ms）：慢响应服务，单位ms。
  3. Un-Health services（Apdex）：Apdex 性能指标，1为满分。
  4. Slow Endpoints（ms）：全局维度的慢响应端点（API）。例如一个接口，是全局Top N的数据，通过这个可以观测平台性能情况。
    1
    2
    3
    表示采集样本中某些值的占比，Skywalking 有 “p50、p75、p90、p95、p99” 一些列值。
    图中的 “p99:61010” 表示 99% 请求的响应时间在61010ms以内。
    而99%一般用于抛掉一些极端值，表示绝大多数请求。
  5. Global Response Latency（percentile in ms）：全局响应延迟百分位数统计，单位 ms。
    1
    2
    3
    可译为热力图、热度图都可以，途中颜色越深，表示请求数越多，这和 GitHub Contributions 很像，commit 越多，颜色越深。
    横坐标是响应时间，鼠标放上去，可以看到具体的数量。
    通过热力图，一方面可以直观感受平台的整体流量，另一方面也可以感受整体性能。

Service

  1. Service Apdex（数字）:当前服务的评分
  2. Service Apdex（折线图）：一段时间内Apdex评分
  3. Service Avg Response Times（ms）：平均响应延时，单位ms
  4. Service Response Time Percentile：百分比响应延时，参考Global Response Latency（percentile in ms）
  5. Successful Rate（数字）：请求成功率
  6. Successful Rate（折线图）：一段时间的请求成功率
  7. Servce Load（CPM / PPM）（数字）：每分钟请求数，
  8. Servce Load（CPM / PPM）（折线图）：不同时间的每分钟请求数
  9. Service Throughput （Bytes）：该指标只适用于TCP 服务。当前服务的吞吐量。
  10. Servce Instances Load（CPM / PPM）：每个服务实例的每分钟请求数
  11. Show Service Instance：每个 服务 实例 的最大延时
  12. Service Instance Successful Rate：每个服务实例的请求成功率

Instance

  1. Service Instance Load （CPM / PPM）：当前实例的每分钟请求数
  2. Service Instance Throughput （Bytes）：该指标只适用于TCP 服务。当前服务实例的吞吐量。
  3. Service Instance Successful Rate（%）：当前实例的请求成功率
  4. Service Instance Latency（ms）：当前实例的响应延时
  5. JVM CPU（Java Service）：jvm占用CPU的百分比
  6. JVM Memory (Java Service)：JVM内存占用大小，单位m，包括堆内存，与堆外内存（直接内存）
  7. JVM GC Time（ms）：JVM垃圾回收时间，包含YGC和OGC
  8. JVM GC Count：JVM垃圾回收次数，包含YGC和OGC
  9. JVM Thread Count (Java Service)
    10 其他参数我就不介绍了，.net的东西。

Endpoint

  1. Endpoint Load in Current Service（CPM / PPM）：每个端点（API）每分钟请求数
  2. Slow Endpoints in Current Service（ms）：每个端点（API）的最慢响应请求时间，单位ms
  3. Successful Rate in Current Service（%）：每个端点（API）的请求成功率
  4. 接下来是每个端点的情况
  5. Endpoint Load：当前端点每个时间段的请求数据
  6. Endpoint Avg Response Time：当前端点每个时间段的请求行响应时间
  7. Endpoint Response Time Percentile（ms）：当前端点每个时间段的响应时间占比
  8. Endpoint Successful Rate（%）：当前端点每个时间段的请求成功率

Database

  1. Database Avg Response Time（ms）：当前数据库事件平均响应时间，单位ms
  2. Database Access Successful Rate（%）：当前数据库访问成功率
  3. Database Traffic（CPM: Calls Per Minute）：当前数据库每分钟请求数
  4. Database Access Latency Percentile（ms）：数据库不同比例的响应时间，单位ms
  5. Slow Statements（ms）：前N个慢查询，单位ms
  6. All Database Loads（CPM: Calls Per Minute）：所有数据库中请求量排序
  7. Un-Health Databases：所有数据库不健康排名，请求成功率排名，失败最多的请求在最上。

jvm监控

没有心跳检测

没错,skywalking是没有心跳检测的,从界面上是看不到心跳相关的东西,但是skywalking的服务,有当前实例,实例里面有jvm memory,比如可以通过分析jvm的的堆从0开始增长
和变为0,来查看实例的存活情况,变相的达到心跳检测的结果.下面有查询时间,默认是查询最近15分钟的,所以,只要是在这个时间包含之内的,都可以查到

只有堆和非堆

只能堆内存和非堆内存,没有堆内存里面的详细信息,而且也只有young gc和old gc,没有full gc

vm 监控

vm监控使用的是Prometheus的node-exporter,然后通过OpenTelemetry Collector收集到oap

  1. 安装node-exporter启动
  2. 安装OpenTelemetry Collector并启动
  3. 修改oap的配置,重新启动

部署

  1. 安装node-exporter
1
2
3
4
wget https://github.com/prometheus/node_exporter/releases/download/v*/node_exporter-*.*-amd64.tar.gz
tar xvfz node_exporter-*.*-amd64.tar.gz
cd node_exporter-*.*-amd64
./node_exporter --web.listen-address=:19100 # 如何需要启动别的端口,添加这个参数
  1. 安装OpenTelemetry Collector并启动
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
FROM alpine:3.13 as certs
RUN apk --update add ca-certificates

FROM alpine:3.13 AS otelcol
COPY otelcol /
# Note that this shouldn't be necessary, but in some cases the file seems to be
# copied with the execute bit lost (see #1317)
RUN chmod 755 /otelcol

FROM scratch

ARG USER_UID=10001
USER ${USER_UID}

COPY --from=certs /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt
COPY --from=otelcol /otelcol /
COPY config.yaml /etc/otel/config.yaml
ENTRYPOINT ["/otelcol"]
CMD ["--config", "/etc/otel/config.yaml"]
EXPOSE 4317 55678 55679
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
receivers:
  prometheus:
    config:
      scrape_configs:
        - job_name: 'otel-collector'
          scrape_interval: 10s
          static_configs:
            - targets: [ '192.168.85.35:19100' ]

processors:
  batch:

exporters:
  opencensus:
    endpoint: "192.168.85.35:20630" # The OAP Server address
    insecure: true
  # Exports data to the console
  logging:
    logLevel: debug

service:
  pipelines:
    metrics:
      receivers: [prometheus]
      processors: [batch]
      exporters: [opencensus,logging]
1
docker run --name collector -v "/etc/opentelemetry-collector/otel-collector-config.yaml":"/etc/otel/config.yaml" -p 54317:4317 -p 55678:55678 -p 55679:55679 otel/opentelemetry-collector:0.34.0
  1. 修改oap的配置,重新启动
1
2
3
4
5
receiver-otel:
  selector: ${SW_OTEL_RECEIVER:default}
  default:
    enabledHandlers: ${SW_OTEL_RECEIVER_ENABLED_HANDLERS:"oc"}
    enabledOcRules: ${SW_OTEL_RECEIVER_ENABLED_OC_RULES:"vm"}
  1. 效果如下

追踪功能

追踪功能可以看到每次的请求,skywalking通过记录每次请求,来完成系统的各种分析,其中可以根据时间和tags进行过滤

  1. tags,注意必须配置了的tags才能搜索
  2. 还可以根据服务,实例,状态来查询

性能剖析

可以新建任务,采集固定的次数,然后根据采集的次数,可以通过代码堆栈来一步步分析,代码那里比较慢

暂时不支持自定义指标

虽然skywalking可以自定义一些指标的样式,和是否显示,但是目前没有查到相关的资料,可以自定义指标,所以,目前只有官方的指标可以用,不过,如果想看某个接口的查询次数,可以在追踪里面查询,然后一页是15行,大致看出来这个接口的调用次数

告警功能(重点)

一片非常不错的告警讲解文章
官方文档
发送到钉钉群
注意,如果不需要全部的entity,可以根据包含,排除,名称和标签,名字和regex,标签,多个维度来组合,达到精准的告警,比如根据包含,我只监控某个名称的endpoint

label是这样子的,可以查看指标的编辑页面看到,不是每个指标都有的

告警支持简单规则和复合规则,而且支持webhooks,目前支持Webhook,gRPCHook,Slack Chat Hook,WeChat Hook,Dingtalk Hook,Feishu Hook,WeLink Hook

常用的指标简介
  1. endpoint_avg,针对全部endpoint,可以告警响应时间,可以根据包含,监控重点业务的响应时间,超时就报警
  2. endpoint_sla,针对全部endpoint,监控成功率,配置成小于100%,那就是有失败就告警
  3. vm监控里面的meter_vm_cpu_total_percentage,cpu全部负载平均值,可以查看vm是否负载严重
  4. vm监控里面的meter_vm_memory_used,内存使用,可以查看vm内存是否耗尽,一般来说,cpu超负荷,内存爆满,就是机器要挂的征兆

以下是一个实例配置,特定的endpoint响应时间,10分钟一个周期,超过一次就报警,如果你想超过就报警,就把周期设置短一些,比如1分钟报警一次,这样10分钟就能报警10次

1
2
3
4
5
6
7
8
9
endpoint_avg_laon_login_rule:
 metrics-name: endpoint_avg
 include-names:
   - '{POST}/login in ladon'
 op: ">"
 threshold: 10
 period: 10
 count: 1
 message: Response time of endpoint {name} is more than 10ms in 10 minutes of last 10 minutes