Apache SkyWalking – User Manual

Zh: 如何使用java探针注入器?

Tue, 19 Apr 2022 00:00:00 +0000

1. 介绍

1.1 SWCK 是什么？

SWCK是部署在 Kubernetes 环境中，为 Skywalking 用户提供服务的平台，用户可以基于该平台使用、升级和维护 SkyWalking 相关组件。

实际上，SWCK 是基于 kubebuilder 开发的Operator，为用户提供自定义资源（ CR ）以及管理资源的控制器（ Controller ），所有的自定义资源定义（CRD）如下所示：

1.2 java 探针注入器是什么？

对于 java 应用来说，用户需要将 java 探针注入到应用程序中获取元数据并发送到 Skywalking 后端。为了让用户在 Kubernetes 平台上更原生地使用 java 探针，我们提供了 java 探针注入器，该注入器能够将 java 探针通过 sidecar 方式注入到应用程序所在的 pod 中。 java 探针注入器实际上是一个Kubernetes Mutation Webhook控制器，如果请求中存在 annotations ，控制器会拦截 pod 事件并将其应用于 pod 上。

2. 主要特点

透明性。用户应用一般运行在普通容器中而 java 探针则运行在初始化容器中，且两者都属于同一个 pod 。该 pod 中的每个容器都会挂载一个共享内存卷，为 java 探针提供存储路径。在 pod 启动时，初始化容器中的 java 探针会先于应用容器运行，由注入器将其中的探针文件存放在共享内存卷中。在应用容器启动时，注入器通过设置 JVM 参数将探针文件注入到应用程序中。用户可以通过这种方式实现 java 探针的注入，而无需重新构建包含 java 探针的容器镜像。
可配置性。注入器提供两种方式配置 java 探针：全局配置和自定义配置。默认的全局配置存放在 configmap 中，用户可以根据需求修改全局配置，比如修改 backend_service 的地址。此外，用户也能通过 annotation 为特定应用设置自定义的一些配置，比如不同服务的 service_name 名称。详情可见 java探针说明书。
可观察性。每个 java 探针在被注入时，用户可以查看名为 JavaAgent 的 CRD 资源，用于观测注入后的 java 探针配置。详情可见 JavaAgent说明。

3. 安装SWCK

在接下来的几个步骤中，我们将演示如何从0开始搭建单机版的 Kubernetes 集群，并在该平台部署0.6.1版本的 SWCK。

3.1 工具准备

首先，你需要安装一些必要的工具，如下所示：

kind，用于创建单机版 Kubernetes集群。
kubectl，用于和Kubernetes 集群交互。

3.2 搭建单机版 Kubernetes集群

在安装完 kind 工具后，可通过如下命令创建一个单机集群。

注意！如果你的终端配置了代理，在运行以下命令之前最好先关闭代理，防止一些意外错误的发生。

$ kind create cluster --image=kindest/node:v1.19.1

在集群创建完毕后，可获得如下的pod信息。

$ kubectl get pod -A                          
NAMESPACE            NAME                                         READY   STATUS    RESTARTS   AGE
kube-system          coredns-f9fd979d6-57xpc                      1/1     Running   0          7m16s
kube-system          coredns-f9fd979d6-8zj8h                      1/1     Running   0          7m16s
kube-system          etcd-kind-control-plane                      1/1     Running   0          7m23s
kube-system          kindnet-gc9gt                                1/1     Running   0          7m16s
kube-system          kube-apiserver-kind-control-plane            1/1     Running   0          7m23s
kube-system          kube-controller-manager-kind-control-plane   1/1     Running   0          7m23s
kube-system          kube-proxy-6zbtb                             1/1     Running   0          7m16s
kube-system          kube-scheduler-kind-control-plane            1/1     Running   0          7m23s
local-path-storage   local-path-provisioner-78776bfc44-jwwcs      1/1     Running   0          7m16s

3.3 安装证书管理器(cert-manger)

SWCK 的证书都是由证书管理器分发和验证，需要先通过如下命令安装证书管理器cert-manger。

$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.3.1/cert-manager.yaml

验证 cert-manger 是否安装成功。

$ kubectl get pod -n cert-manager
NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-7dd5854bb4-slcmd              1/1     Running   0          73s
cert-manager-cainjector-64c949654c-tfmt2   1/1     Running   0          73s
cert-manager-webhook-6bdffc7c9d-h8cfv      1/1     Running   0          73s

3.4 安装SWCK

java 探针注入器是 SWCK 中的一个组件，首先需要按照如下步骤安装 SWCK：

输入如下命令获取 SWCK 的 yaml 文件并部署在 Kubernetes 集群中。

$ curl -Ls https://archive.apache.org/dist/skywalking/swck/0.6.1/skywalking-swck-0.6.1-bin.tgz | tar -zxf - -O ./config/operator-bundle.yaml | kubectl apply -f -

检查 SWCK 是否正常运行。

$ kubectl get pod -n skywalking-swck-system
NAME                                                  READY   STATUS    RESTARTS   AGE
skywalking-swck-controller-manager-7f64f996fc-qh8s9   2/2     Running   0          94s

3.5 安装 Skywalking 组件 — OAPServer 和 UI

在 default 命名空间中部署 OAPServer 组件和 UI 组件。

$ kubectl apply -f https://raw.githubusercontent.com/apache/skywalking-swck/master/operator/config/samples/default.yaml

查看 OAPServer 组件部署情况。

$ kubectl get oapserver
NAME      INSTANCES   RUNNING   ADDRESS
default   1           1         default-oap.default

查看 UI 组件部署情况。

$ kubectl get ui
NAME      INSTANCES   RUNNING   INTERNALADDRESS      EXTERNALIPS   PORTS
default   1           1         default-ui.default                 [80]

4. 部署demo应用

在第3个步骤中，我们已经安装好 SWCK 以及相关的 Skywalking 组件，接下来按照全局配置以及自定义配置两种方式，通过两个 java 应用实例，分别演示如何使用 SWCK 中的 java 探针注入器。

4.1 设置全局配置

当 SWCK 安装完成后，默认的全局配置就会以 configmap 的形式存储在系统命令空间中，可通过如下命令查看。

$  kubectl get configmap skywalking-swck-java-agent-configmap -n skywalking-swck-system -oyaml
apiVersion: v1
data:
  agent.config: |-
    # The service name in UI
    agent.service_name=${SW_AGENT_NAME:Your_ApplicationName}

    # Backend service addresses.
    collector.backend_service=${SW_AGENT_COLLECTOR_BACKEND_SERVICES:127.0.0.1:11800}

    # Please refer to https://skywalking.apache.org/docs/skywalking-java/latest/en/setup/service-agent/java-agent/configurations/#table-of-agent-configuration-properties to get more details.

在 kind 创建的 Kubernetes 集群中， SkyWalking 后端地址和 configmap 中指定的地址可能不同，我们需要使用真正的 OAPServer 组件的地址 default-oap.default 来代替默认的 127.0.0.1 ，可通过修改 configmap 实现。

$ kubectl edit configmap skywalking-swck-java-agent-configmap -n skywalking-swck-system
configmap/skywalking-swck-java-agent-configmap edited

$ kubectl get configmap skywalking-swck-java-agent-configmap -n skywalking-swck-system -oyaml
apiVersion: v1
data:
  agent.config: |-
    # The service name in UI
    agent.service_name=${SW_AGENT_NAME:Your_ApplicationName}

    # Backend service addresses.
    collector.backend_service=${SW_AGENT_COLLECTOR_BACKEND_SERVICES:default-oap.default:11800}

    # Please refer to https://skywalking.apache.org/docs/skywalking-java/latest/en/setup/service-agent/java-agent/configurations/#table-of-agent-configuration-properties to get more details.

4.2 设置自定义配置

在实际使用场景中，我们需要使用 Skywalking 组件监控不同的 java 应用，因此不同应用的探针配置可能有所不同，比如应用的名称、应用需要使用的插件等。为了支持自定义配置，注入器提供 annotation 来覆盖默认的全局配置。接下来我们将分别以基于 spring boot 以及 spring cloud gateway 开发的两个简单java应用为例进行详细说明，你可以使用这两个应用的源代码构建镜像。

# build the springboot and springcloudgateway image 
$ git clone https://github.com/dashanji/swck-spring-cloud-k8s-demo 
$ cd swck-spring-cloud-k8s-demo && make

# check the image
$ docker images
REPOSITORY     TAG       IMAGE ID       CREATED          SIZE
gateway        v0.0.1    51d16251c1d5   48 minutes ago   723MB
app            v0.0.1    62f4dbcde2ed   48 minutes ago   561MB

# load the image into the cluster
$ kind load docker-image app:v0.0.1 && kind load docker-image gateway:v0.0.1

4.3 部署 spring boot 应用

创建 springboot-system 命名空间。

$ kubectl create namespace springboot-system

给 springboot-system 命名空间打上标签使能 java 探针注入器。

$ kubectl label namespace springboot-system swck-injection=enabled

接下来为 spring boot 应用对应的部署文件 springboot.yaml ，其中使用了 annotation 覆盖默认的探针配置，比如 service_name ，将其覆盖为 backend-service 。

需要注意的是，在使用 annotation 覆盖探针配置之前，需要增加 strategy.skywalking.apache.org/agent.Overlay: "true" 来使覆盖生效。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-springboot
  namespace: springboot-system
spec:
  selector:
    matchLabels:
      app: demo-springboot
  template:
    metadata:
      labels:
        swck-java-agent-injected: "true"  # enable the java agent injector
        app: demo-springboot
      annotations:
        strategy.skywalking.apache.org/agent.Overlay: "true"  # enable the agent overlay
        agent.skywalking.apache.org/agent.service_name: "backend-service"
    spec:
      containers:
      - name: springboot
        imagePullPolicy: IfNotPresent
        image: app:v0.0.1
        command: ["java"]
        args: ["-jar","/app.jar"]
---
apiVersion: v1
kind: Service
metadata:
  name: demo
  namespace: springboot-system
spec:
  type: ClusterIP
  ports:
  - name: 8085-tcp
    port: 8085
    protocol: TCP
    targetPort: 8085
  selector:
    app: demo-springboot

在 springboot-system 命名空间中部署 spring boot 应用。

$ kubectl apply -f springboot.yaml

查看部署情况。

$ kubectl get pod -n springboot-system
NAME                               READY   STATUS    RESTARTS   AGE
demo-springboot-7c89f79885-dvk8m   1/1     Running   0          11s

通过 JavaAgent 查看最终注入的 java 探针配置。

$ kubectl get javaagent -n springboot-system
NAME                            PODSELECTOR           SERVICENAME       BACKENDSERVICE
app-demo-springboot-javaagent   app=demo-springboot   backend-service   default-oap.default:11800

4.4 部署 spring cloud gateway 应用

创建 gateway-system 命名空间。

$ kubectl create namespace gateway-system

给 gateway-system 命名空间打上标签使能 java 探针注入器。

$ kubectl label namespace gateway-system swck-injection=enabled

接下来为 spring cloud gateway 应用对应的部署文件 springgateway.yaml ，其中使用了 annotation 覆盖默认的探针配置，比如 service_name ，将其覆盖为 gateway-service 。此外，在使用 spring cloud gateway 时，我们需要在探针配置中添加 spring cloud gateway 插件。

需要注意的是，在使用 annotation 覆盖探针配置之前，需要增加 strategy.skywalking.apache.org/agent.Overlay: "true" 来使覆盖生效。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: demo-gateway
  name: demo-gateway
  namespace: gateway-system
spec:
  selector:
    matchLabels:
      app: demo-gateway
  template:
    metadata:
      labels:
        swck-java-agent-injected: "true"
        app: demo-gateway
      annotations:
        strategy.skywalking.apache.org/agent.Overlay: "true"
        agent.skywalking.apache.org/agent.service_name: "gateway-service"     
        optional.skywalking.apache.org: "cloud-gateway-3.x" # add spring cloud gateway plugin
    spec:
      containers:
      - image: gateway:v0.0.1
        name: gateway
        command: ["java"]
        args: ["-jar","/gateway.jar"]
---
apiVersion: v1
kind: Service
metadata:
  name: service-gateway
  namespace: gateway-system
spec:
  type: ClusterIP
  ports:
  - name: 9999-tcp
    port: 9999
    protocol: TCP
    targetPort: 9999
  selector:
    app: demo-gateway

在 gateway-system 命名空间中部署 spring cloud gateway 应用。

$ kubectl apply -f springgateway.yaml

查看部署情况。

$ kubectl get pod -n gateway-system
NAME                           READY   STATUS    RESTARTS   AGE
demo-gateway-758899c99-6872s   1/1     Running   0          15s

通过 JavaAgent 获取最终注入的java探针配置。

$ kubectl get javaagent -n gateway-system
NAME                         PODSELECTOR        SERVICENAME       BACKENDSERVICE
app-demo-gateway-javaagent   app=demo-gateway   gateway-service   default-oap.default:11800

5. 验证注入器

当完成上述步骤后，我们可以查看被注入pod的详细状态，比如被注入的agent容器。

# get all injected pod
$ kubectl get pod -A -lswck-java-agent-injected=true
NAMESPACE           NAME                               READY   STATUS    RESTARTS   AGE
gateway-system      demo-gateway-5bb77f6d85-lt4z7      1/1     Running   0          69s
springboot-system   demo-springboot-7c89f79885-lkb5j   1/1     Running   0          75s

# view detailed state of the injected pod [demo-springboot]
$ kubectl describe pod -l app=demo-springboot -n springboot-system
...
Events:
  Type   Reason   Age                From                           Message
  ----   ------  ----                ----                           -------
  ...
  Normal Created  91s  kubelet,kind-control-plane Created  container inject-skywalking-agent
  Normal Started  91s  kubelet,kind-control-plane Started  container inject-skywalking-agent
  ...
  Normal Created  90s  kubelet,kind-control-plane Created  container springboot
  Normal Started  90s  kubelet,kind-control-plane Started  container springboot

# view detailed state of the injected pod [demo-gateway] 
$ kubectl describe pod -l app=demo-gateway -n gateway-system
...
Events:
  Type   Reason   Age            From                         Message
  ----   ------  ----            ----                         -------
  ...
  Normal Created 2m20s kubelet,kind-control-plane Created container inject-skywalking-agent
  Normal Started 2m20s kubelet,kind-control-plane Started container inject-skywalking-agent
  ...
  Normal Created 2m20s kubelet,kind-control-plane Created container gateway
  Normal Started 2m20s kubelet,kind-control-plane Started container gateway

现在我们可以将服务绑定在某个端口上并通过 web 浏览器查看采样数据。首先，我们需要通过以下命令获取gateway服务和ui服务的信息。

$ kubectl get service service-gateway -n gateway-system
NAME              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
service-gateway   ClusterIP   10.99.181.145   <none>        9999/TCP   9m19s

$ kubectl get service default-ui
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
default-ui   ClusterIP   10.111.39.250   <none>        80/TCP    82m

接下来分别启动2个终端将service-gateway 以及 default-ui 绑定到本地端口上，如下所示：

$ kubectl port-forward service/service-gateway -n gateway-system 9999:9999
Forwarding from 127.0.0.1:9999 -> 9999
Forwarding from [::1]:9999 -> 9999

$ kubectl port-forward service/default-ui 8090:80                     
Forwarding from 127.0.0.1:8090 -> 8080
Forwarding from [::1]:8090 -> 8080

使用以下命令通过spring cloud gateway 网关服务暴露的端口来访问 spring boot 应用服务。

$ for i in {1..10}; do curl http://127.0.0.1:9999/gateway/hello && echo ""; done
Hello World!
Hello World!
Hello World!
Hello World!
Hello World!
Hello World!
Hello World!
Hello World!
Hello World!
Hello World!

我们可以在 web 浏览器中输入 http://127.0.0.1:8090 来访问探针采集到的数据。

所有服务的拓扑图如下所示。

查看 gateway-service 网关服务的 trace 信息。

查看 backend-service 应用服务的 trace 信息。

6. 结束语

如果你的应用部署在 Kubernetes 平台中，且需要 Skywalking 提供监控服务， SWCK 能够帮助你部署、升级和维护 Kubernetes 集群中的 Skywalking 组件。除了本篇博客外，你还可以查看 SWCK文档以及 java探针注入器文档获取更多的信息。如果你觉得这个项目好用，请给 SWCK 一个star! 如果你有任何疑问，欢迎在Issues或者Discussions中提出。

Zh: Cyborg Flow X SkyWalking: 生产环境全链路压测

Tue, 18 Jan 2022 00:00:00 +0000

随着业务与用户量的持续发展，系统的瓶颈也逐渐出现。尤其在一些节假日、突发的营销活动中，访问量激增可能会导致系统性能下降，甚至造成系统瘫痪。全链路压测可以很好的帮助我们预先演练高峰流量，从而提前模拟出系统的执行情况，帮助我们预估系统容量。当流量真正来临时，也可以更从容面对。 Apache SkyWalking 联合 Apache APISIX 及 Apache ShardingSphere，三大顶级开源社区通力合作，共同打造生产级可用的全链路压测解决方案，CyborgFlow。

介绍

CyborgFlow 是一款面向生产级可用的全链路压测解决方案。总共由三个组件组成，如下图所示。

Flow Gateway: 压测流量网关。当流量到达该组件时，则会将请求认定为压测流量，并将压测流量标识传递至上游服务。
Database Shadow: 数据库中间件。当数据库中间件感知到当前流量为压测流量时，则会将数据库操作路由至影子表中进行操作。
Agent/Dashboard: 分布式监控系统。与业务系统紧密结合，当感知到压测请求后，自动将其标识传递至上游，无需业务代码改造。并且利用分析能力，构建Dashboard来便于查看流量情况。

以此，便覆盖了单个请求的完整生命周期，在网关层构建压测标识，到业务系统透传标识，最终将请求与影子表交互。同时整个流程拥有完整的监控分析。

原理

依托于三大社区合作，让这一切变得简单易用。下图为全链路压测系统的运行原理，橙色和蓝色分别代表正常流量和压测流量。

Flow Gateway

Flow Gateway 作为压测流量网关，主要负责接收流量，并传递压测流量表示至上游。

添加 skywalking插件构建链路入口。
依据 proxy-rewrite插件将压测流量标识注入到上游的请求头中。

Agent/Dashboard

该组件中则分为两部分内容说明。

Agent

Agent与业务程序拥有相同生命周期，负责压测流量标识在各个业务系统之间传递，并与 Database Shadow 交互。

SkyWalking Agent通过读取从Flow Gateway传递的压测流量标识，利用透传协议将该标识在应用之间传递。
当准备进行数据库调用时，则通过判断是否包含压测流量标识来决定是否SQL调用时追加压测流量标识(/* cyborg-flow: true */)。
当检测到当前请求包含压测流量标识后，将该数据与Trace绑定，用于Dashboard数据分析。

Dashboard

Dashboard 用于压测过程进行中的监控数据分析，并最终以图表的方式进行展示。

接收来自Agent中上报的Trace数据，并依据OAL中的Tag过滤器(.filter(tags contain "cyborg-flow:true"))来生成压测与非压测的指标数据。
利用指标数据便可以在Dashboard中创建图表进行观察。

Database Shadow

Database Shadow 作为 Proxy 在业务程序与数据库中间完成数据交互，当检测到压测流量时则会将SQL传递至影子表中处理。

检测下游传递的数据库语句中是否包含压测流量标识(/* cyborg-flow: true */)，存在时则将SQL交给由用户配置的影子表中处理。

快速上手

下面将带你快速将Cyborg Flow集成至你的项目中。相关组件的下载请至 Github Release 中下载，目前已发布 0.1.0 版本。

部署 Database Shadow

解压缩cyborg-database-shadow.tar.gz。
将 conf/config-shadow.yaml 文件中的业务数据库与影子数据库配置为自身业务中的配置。
启动 Database Shadow服务，启动脚本位于bin/start.sh中。

如需了解更详细的部署参数配置，请参考官方文档。

部署 Cyborg Dashboard

解压缩cyborg-dashboard.tar.gz。
启动后端与UI界面服务，用于链路数据解析与界面展示，启动脚本位于bin/startup.sh中。
接下来就可以通过打开浏览器并访问http://localhost:8080/，此页面为Cyborg Dashboard界面，由于目前尚未部署任何业务程序，所以暂无任何数据。

如需了解更详细的部署参数配置，请参考后端服务与 UI界面服务的安装文档。

部署 Cyborg Agent 到业务程序中

解压缩cyborg-agent.tar.gz.
修改config/agent.config中的collector.backend_service为 Cyborg Dashboard 中后端地址(默认为11800端口)，用于将监控数据上报至 Cyborg Dashboard 。
修改业务程序中与数据库的链接，将其更改为 Database Shadow 中的配置。默认访问端口为3307，用户名密码均为root。
当程序启动时，增加该参数到启动命令中：-jar path/to/cyborg-agent/skywalking-agent.jar。

如需了解更详细的部署参数配置，请参考 Agent安装文档。

部署 Flow Gateway

参考 Flow Gateway 快速开始进行下载 Apache APISIX 并配置相关插件。
基于 APISIX 创建路由文档进行路由创建。

完成！

最后，通过Flow Gateway访问业务系统资源，便完成了一次压测流量请求。

压测流量最终访问至影子表进行数据操作。
如下图所示，通过观察 Cyborg Dashboard 便可以得知压测与非压测请求的执行情况。

总结

在本文中，我们详细介绍了Cyborg Flow中的各个组件的功能、原理，最终搭配快速上手来快速将该系统与自己的业务系统结合。如果在使用中有任何问题，欢迎来共同讨论。

Zh: Chaos Mesh X SkyWalking: 可观测的混沌工程

Mon, 29 Nov 2021 00:00:00 +0000

Chaos Mesh 是一个开源的云原生混沌工程平台，借助 Chaos Mesh，用户可以很方便地对服务注入异常故障，并配合 Chaos Dashboard 实现对整个混沌实验运行状况的监测。然而，对混沌实验运行情况的监控并不能告诉我们应用服务性能的变化。从系统可观测性的角度来说，我们可能无法单纯通过混沌实验的动态了解故障的全貌，这也阻碍了我们对系统和故障的进一步了解，调试。

Apache SkyWalking 是一个开源的 APM (Application Performance Monitor) 系统，可以对云原生服务提供监控、跟踪、诊断等功能。SkyWalking 支持收集 Event（事件），可在 Dashboard 中查看分布式系统中发生了哪些事件，并可以直观地观测到不同 Event 对服务性能造成的影响，和 Chaos Mesh 结合使用，便可为混沌实验造成的服务影响提供监控。

本教程将分享如何通过将 SkyWalking 和 Chaos Mesh 结合，运用 Event 信息监控，实时了解混沌实验对应用服务性能造成的影响。

准备工作

创建 Skywalking 集群，具体可以参考 SkyWalking Readme。
部署 Chaos Mesh，推荐使用 helm 安装。
安装 Java 测试工具 JMeter （其他工具亦可，仅用于增加服务负载）
如果仅作为 Demo 使用，可以参考 chaos-mesh-on-skywalking 这个仓库进行配置

Step 1 - 访问 SkyWalking 集群

安装 SkyWalking 后，就可以访问它的UI了，但因为还没有服务进行监控，这里还需要添加服务并进行 Agent 埋点设置。本文选用轻量级微服务框架 Spring Boot 作为埋点对象搭建一个简易 Demo 环境。

可以参考 chaos-mesh-on-skywalking 仓库中的 demo-deployment.yaml 文件创建。之后使用 kubectl apply -f demo-deployment.yaml -n skywalking 进行部署。部署成功后即可在SkyWalking-UI 中看到实时监控的服务信息。

注意：因为 Spring Boot 的端口也是8080，在端口转发时要避免和 **SkyWalking **的端口冲突，比如使用 kubectl port-forward svc/spring-boot-skywalking-demo 8079:8080 -n skywalking 。

Step 2 - 部署 SkyWalking Kubernetes Event Exporter

SkyWalking Kubernetes Event Exporter 可以用来监控和过滤 Kubernetes 集群中的 Event ，通过设置过滤条件筛选出需要的 Event，并将这些 Event 发送到 SkyWalking 后台，这样就可以通过 SkyWalking 观察到你的 Kubernetes 集群中的Event 何时影响到服务的各项指标了。如果想要一条命令部署，可以参考此配置创建 yaml 文件，设置 filters 和 exporters 的参数后，使用 kubectl apply 进行部署。

Step 3 - 使用 JMeter 对服务加压

为了达到更好的观察效果，需要先对 Spring Boot 增加服务负载，本文选择使用 JMeter 这一使用广泛的 Java 压力测试工具来对服务加压。

通过 JMeter 对 `localhost:8079` 进行压测，添加5个线程持续进行加压。

通过 SkyWalking Dashboard 可以看到，目前访问成功率为100%，服务负载大约在5300 CPM (Calls Per Minute）。

Step 4 - Chaos Mesh 注入故障，观察效果

做好了这些准备工便可以使用 Chaos Dashboard 进行压力场景模拟，并在实验进程中观察服务性能的变化。

以下使用不同 Stress Chaos 配置，观测对应服务性能变化：

CPU 负载10%，内存负载128 MB 。

混沌实验开始和结束的时间点标记可以通过右侧开关显示在在图表中，将鼠标移至短线出可以看到是实验的 Applied 或 Recovered。可以看到两个绿色短线之间的时间段里，服务处理调用的的性能降低，为4929 CPM，在实验结束后，性能恢复正常。
CPU load 增加到50%，发现服务负载进一步降低至4307 CPM。
极端情况下 CPU 负载达到100%，服务负载降至无混沌实验时的40% 。

因为 Linux 系统下的进程调度并不会让某个进程一直占据 CPU，所以即使实在 CPU 满载的极端情况下，该部署的 Spring Boot Demo 仍可以处理40%的访问请求。

小结

通过 SkyWalking 与 Chaos Mesh 的结合，我们可以清晰的观察到服务在何时受到混沌实验的影响，在注入混沌后服务的表现性能又将如何。SkyWalking 与 Chaos Mesh 的结合使得我们轻松地观察到了服务在各种极端情况下的表现，增强了我们对服务的信心。

Chaos Mesh 在 2021 年成长了许多。为了更多地了解用户在实践混沌工程方面的经验，以便持续完善和提升对用户的支持，社区发起了 Chaos Mesh 用户问卷调查，点击【阅读原文】参与调查，谢谢！

https://www.surveymonkey.com/r/X78WQPC

欢迎大家加入 Chaos Mesh 社区，加入 CNCF Slack (slack.cncf.io) 底下的 Chaos Mesh 频道: project-chaos-mesh，一起参与到项目的讨论与开发中来！大家在使用过程发现 Bug 或缺失什么功能，也可以直接在 GitHub (https://github.com/chaos-mesh) 上提 Issue 或 PR。

Zh: SkyWalking报警发送到钉钉群

Sun, 13 Dec 2020 00:00:00 +0000

这篇文章暂时不讲告警策略, 直接看默认情况下激活的告警目标以及钉钉上的告警效果

SkyWalking内置了很多默认的告警策略, 然后根据告警策略生成告警目标, 我们可以很容易的在界面上看到

当我们想去让这些告警目标通知到我们时, 由于SkyWalking目前版本(8.3)已经自带了, 只需要简单配置一下即可

我们先来钉钉群中创建机器人并勾选加签

然后再修改告警部分的配置文件, 如果你是默认的配置文件(就像我一样), 你可以直接执行以下命令, 反之你也可以手动修改configs/alarm-settings.yml文件

tee <your_skywalking_path>/configs/alarm-settings.yml <<-'EOF'
dingtalkHooks:
  textTemplate: |-
    {
      "msgtype": "text",
      "text": {
        "content": "Apache SkyWalking Alarm: \n %s."
      }
    }
  webhooks:
    - url: https://oapi.dingtalk.com/robot/send?access_token=<access_token>
      secret: <加签值>
EOF

最终效果如下

参考文档:

https://github.com/apache/skywalking/blob/master/docs/en/setup/backend/backend-alarm.md

https://ding-doc.dingtalk.com/doc#/serverapi2/qf2nxq/uKPlK

谢谢观看, 后续我会在SkyWalking告警这块写更多实战文章

Zh: 度量服务网格健康度——Apdex得分

Sun, 26 Jul 2020 00:00:00 +0000

作者: Srinivasan Ramaswamy, tetrate
翻译：唐昊杰，南京大学在读学生
校对：吴晟
Original link, Tetrate.io blog
July. 26th, 2020

“你感觉怎么样” 比 “你的症状是什么” 更重要

背景

最近我拜访了我的医生。每次去看病，医生都会首先问我一连串轻快的问题，比如：你今天过得怎么样？上周过的怎么样？最近有什么出行吗？你打破了自己的骑车记录吗？你的锻炼计划实施如何？最后他会问：“你有什么麻烦吗？”如果这个时候我感觉自己不太好，我会说：“我这周感觉很沉闷，临近中午的时候感觉更累。”这时他就会拿出听诊器、脉搏血氧仪和血压仪。然后，如果他觉得自己需要更深入的了解情况，他就开始列出我需要做的具体检查。

当我问他，最开始的讨论是否只是为了缓和氛围。他说：“这是必不可少的部分。它帮助我发现你感觉如何，而不是你的症状是什么。"。我们这样关于生活的开场聊天，帮助他组织了后续关于症状、调查和测试结果的问题。

在回来的路上，我不停地问自己：“我们是不是也应该用这种方式管理我们的网格(service mesh)？”

如果我把自己的健康检查和网格的健康检查进行类比，“医疗检查”就是日志分析，“调查”就是追踪，“症状”就是传统的RED指标（请求速率、请求错误和请求耗时）。那么根本的问题，就是我们在这里讨论的：健康因素（主要是网格的健康）。

服务网格中的健康状况

我们可以通过RED指标来衡量任何被观察到的服务的性能。RED指标在了解每个服务的性能、可靠性和吞吐量方面提供了巨大的价值。这些指标在网格上的令人信服的可视化使得监控全部网格变得标准化和可扩展。此外，根据这些指标的阈值设置警报有助于在指标值异常的时候进行异常检测。

为了建立任何服务的上下文环境并观察它们，理想的做法是将网格可视化为一个拓扑结构。

网格的拓扑结构可视化不仅允许使用者挑选任意服务并观察其指标，还可以提供有关服务依赖和特定服务在网格上的潜在影响这些重要信息。

虽然每个服务的RED指标为使用者提供了深刻的洞察能力，但使用者更关心网格的整体响应性，而非每个单独出来的服务的响应性。

为了描述任意服务的性能（即从提交请求到收到完成了的http响应这段时间内的表现），我们会测量用户对响应性的感知。这种将响应时间与设定的阈值进行比较的衡量标准叫做Apdex。Apdex是衡量一个服务在网格中的健康程度的指标。

Apdex

Apdex是根据设定的阈值和响应时间结合考虑的衡量标准。它是满意响应时间和不满意响应时间相对于总响应时间的比率。

Apdex是根据应用和服务的响应时间来衡量使用者满意程度的行业标准。它衡量的是用户对你的服务的满意程度，因为传统的指标（如平均响应时间）可能很快就会容易形成偏差。

基于满意度的响应时间，表示特定服务的往返响应时间小于设定的阈值的次数。不满意响应时间虽然意思相反，但又进一步分为容忍型和失望型。容忍型包括了了任何响应时间不超过四倍阈值的表现，而任何超过四倍阈值或遇到了错误的表现都被认为是失望型。这里提到的阈值是我们对任意服务所期望的理想响应表现。我们可以设置一个全局范围的阈值，如，500ms。

Apdex得分是满意型请求和容忍型请求与做出的总请求的比率。

每个_满意的请求_算作一个请求，而每个_容忍的请求_算作半个_满意_的请求。

一个Apdex得分从0到1的范围内取值。0是最差的分数，表示用户总是感到失望；而'1’是最好的分数（100%的响应时间是令人满意的）。

这个分数的百分比表示也可以用作服务的健康指标。

数学表示

Apdex得分的实际计算是通过以下公式实现的：

		                   满意请求数 +  ( 容忍请求数 / 2 )

Apdex 得分  =  ------------------------------------------------------

                                总请求数

此公示得到的百分率，即可视为服务的健康度。

样例计算

在两分钟的采样时间内，主机处理200个请求。

Apdex阈值T设置为0.5秒（500ms）。

*. 170个请求在500ms内被处理完成，它们被分类为满意型。 *. 20个请求在500ms和2秒间被处理，它们被分类为容忍型。 *. 剩余的10个请求没有被正确处理或者处理时间超过了2秒，所以它们被分类为失望型。

最终的Apdex得分是0.9，即（170 + （20 / 2））/ 200。

深入使用

在接下来的层次，我们可以尝试通过根据节点的健康状况来着色节点以改进我们的拓扑可视化。此外，我们还可以在用户点击服务时将健康状况作为我们展示的信息的一部分。

Apdex规范推荐了以下Apdex质量评级，将Apdex得分分为优秀（0.94 - 1.00）、良好（0.85 - 0.93）、一般（0.70 - 0.84）、差（0.50 - 0.69）和不可接受（0.00 - 0.49）。

为了可视化网格的健康状况，我们用交通灯的颜色将我们的节点标记为健康、有风险和不健康，其中不健康表示健康率低于80%。健康率在80%到95%之间的表示有风险，健康率在95%及以上的称为健康。

让我们将这种着色融入到我们的拓扑可视化中，并将其可用性提升到一个新的水平。如果实施，我们将看到下图所示的情况。

更进一步

Apdex为客户对我们服务响应性的满意度提供了可见性。更有甚者，通过将实施范围扩展到调用该服务的调用关系，我们可以进一步了解网格本身的健康状况。

两个有着相似Apdex分数的服务，为客户提供了相同的客户满意度。然而，流入服务的流量大小对于优先处理哪一服务有着巨大的帮助。流量较高的服务表明这种服务体验影响了网格上更大量的使用者。

虽然健康程度与单个服务有关，但我们也可以分析两个服务之间的交互并计算交互过程的健康程度。这种对网格上每一个交互的健康程度的计算，可以帮助我们根据整个拓扑结构中所有交互的健康程度，建立一个关键路径。

在一个大的网格中，将流量展示为另一个数字将使可视化和监控更具挑战性。我们可以根据服务的吞吐量，通过用不同的粗细程度渲染连接服务的边来改善整个可视化的效果。

一个位于高吞吐量事务的不健康的服务可能会导致资源的过度消耗。另一方面，这种可视化也为调整服务时获取最大化投资效果提供了一个很好的提示。

与调整一个偶尔使用的服务相比，调整作为高吞吐量事务的一部分的那些服务会带来指数级的收益。

实施这种包括了交互的健康状况和吞吐量的可视化，我们会看到下图所示的情况:

这一天即将到来

目前，这些功能已经作为Tetrate服务网格平台的UI功能之一来提供给用户。该平台使用了高速可配置化、高性能的可观测性和监控性能管理平台：Apache SkyWalking (https://skywalking.apache.org)，SkyWalking可以监控整个网格的流量，为服务及它们的交互合计RED指标，持续计算和监控服务的健康状况，并使用户能够在服务超过特定阈值时配置报警和通知。这些功能使得SkyWalking对网格拥有全面的健康状况可见性。

有了这样强大的网格性能可视性，我们将可以在为网格准备的网络运营中心使用这种拓扑结构作为我们的HUD（Heads Up Display）。

HUD随着时间的推移收集了解到的信息和模式，并将预测各种情况和主动提示我们潜在的重点领域以提高客户满意度。

丰富的历史数据的可视化也可以使网络工程师能够看看过去中类似的一天的网格表现。

可视化效果如下图所示。

总结

综合到目前为止的所有讨论，网格的健康状况更多地是关于用户的感受，以及我们作为服务提供商可以采取积极行动来维持（如果不能增强）用户的体验。

着个人化医学的发展，现在距离我的医生给我发这样短信的日子并不遥远：“要不今天享用冰淇淋并且沿着灰色小山步道到达沙斯塔山！”相似的，我们可以通过更好地了解客户的整体健康状况为他们做更多的事情。

Tetrate的“服务网格健康程度”方法不仅提供了管理，监视和支持，而且从一开始就使基础架构保持健康以减少事故发生的可能性。在Istio，Envoy和SkyWalking的支持下，Tetrate的解决方案可为任何环境中的任何工作负载提供持续的端到端可观察性，运行时安全性和流量管理。

我们的客户应该拥有健康的系统！请分享您对使用服务网格为我们的客户带来令人兴奋和强健的体验的想法。

引用

Zh: SkyWalking 极简入门

Sun, 19 Apr 2020 00:00:00 +0000

作者：芋道源码

原文地址

1. 概述

1.1 概念

SkyWalking 是什么？

FROM http://skywalking.apache.org/

分布式系统的应用程序性能监视工具，专为微服务、云原生架构和基于容器（Docker、K8s、Mesos）架构而设计。

提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。

1.2 功能列表

SkyWalking 有哪些功能？

FROM http://skywalking.apache.org/

多种监控手段。可以通过语言探针和 service mesh 获得监控是数据。

多个语言自动探针。包括 Java，.NET Core 和 Node.JS。

轻量高效。无需大数据平台，和大量的服务器资源。

模块化。UI、存储、集群管理都有多种机制可选。

支持告警。

优秀的可视化解决方案。

1.3 整体架构

SkyWalking 整体架构如何？

FROM http://skywalking.apache.org/

整个架构，分成上、下、左、右四部分：

考虑到让描述更简单，我们舍弃掉 Metric 指标相关，而着重在 Tracing 链路相关功能。

上部分 Agent ：负责从应用中，收集链路信息，发送给 SkyWalking OAP 服务器。目前支持 SkyWalking、Zikpin、Jaeger 等提供的 Tracing 数据信息。而我们目前采用的是，SkyWalking Agent 收集 SkyWalking Tracing 数据，传递给服务器。
下部分 SkyWalking OAP ：负责接收 Agent 发送的 Tracing 数据信息，然后进行分析(Analysis Core) ，存储到外部存储器( Storage )，最终提供查询( Query )功能。
右部分 Storage ：Tracing 数据存储。目前支持 ES、MySQL、Sharding Sphere、TiDB、H2 多种存储器。而我们目前采用的是 ES ，主要考虑是 SkyWalking 开发团队自己的生产环境采用 ES 为主。
左部分 SkyWalking UI ：负责提供控台，查看链路等等。

1.4 官方文档

在 https://github.com/apache/skywalking/tree/master/docs 地址下，提供了 SkyWalking 的英文文档。

考虑到大多数胖友的英语水平和艿艿不相伯仲，再加上胖友一开始对 SkyWalking 比较陌生，所以比较推荐先阅读 https://github.com/SkyAPM/document-cn-translation-of-skywalking 地址，提供了 SkyWalking 的中文文档。

考虑到胖友使用 SkyWalking 的目的，是实现分布式链路追踪的功能，所以最好去了解下相关的知识。这里推荐阅读两篇文章：

2. 搭建 SkyWalking 单机环境

考虑到让胖友更快的入门，我们来搭建一个 SkyWalking 单机环境，步骤如下：

第一步，搭建一个 Elasticsearch 服务。
第二步，下载 SkyWalking 软件包。
第三步，搭建一个 SkyWalking OAP 服务。
第四步，启动一个 Spring Boot 应用，并配置 SkyWalking Agent。
第五步，搭建一个 SkyWalking UI 服务。

仅仅五步，按照艿艿标题党的性格，应该给本文取个《10 分钟快速搭建 SkyWalking 服务》标题才对，哈哈哈。

2.1 Elasticsearch 搭建

FROM https://www.elastic.co/cn/products/elasticsearch

Elasticsearch 是一个分布式、RESTful 风格的搜索和数据分析引擎，能够解决不断涌现出的各种用例。作为 Elastic Stack 的核心，它集中存储您的数据，帮助您发现意料之中以及意料之外的情况。

参考《Elasticsearch 极简入门》的「1. 单机部署」小节，搭建一个 Elasticsearch 单机服务。

不过要注意，本文使用的是 Elasticsearch 7.5.1 版本。因为 SkyWalking 6.6.0 版本，增加了对 Elasticsearch 7.X 版本的支持。当然，如果胖友使用 Elasticsearch 6.X 版本也是可以的。

2.2 下载 SkyWalking 软件包

对于 SkyWalking 的软件包，有两种方式获取：

手动编译
官方包

一般情况下，我们建议使用官方包。手动编译，更多是尝鲜或者等着急修复的 BUG 的版本。

2.2.1 官方包

在 http://skywalking.apache.org/downloads/ 下，我们下载操作系统对应的发布版。

这里，我们选择 Binary Distribution for ElasticSearch 7 (Linux) 版本，因为艿艿是 Mac 环境，再加上想使用 Elasticsearch 7.X 版本作为存储。如果胖友想用 Elasticsearch 6.X 版本作为存储，记得下载 Binary Distribution (Linux) 版本。

① 下载：

# 创建目录
$ mkdir -p /Users/yunai/skywalking
$ cd /Users/yunai/skywalking

# 下载
$ wget http://mirror.bit.edu.cn/apache/skywalking/6.6.0/apache-skywalking-apm-es7-6.6.0.tar.gz

② 解压：

# 解压
$ tar -zxvf apache-skywalking-apm-es7-6.6.0.tar.gz
$ cd  apache-skywalking-apm-bin-es7

$ ls -ls
 4 drwxr-xr-x 8 root root  4096 Sep  9 15:09 agent # SkyWalking Agent
 4 drwxr-xr-x 2 root root  4096 Sep  9 15:44 bin # 执行脚本
 4 drwxr-xr-x 2 root root  4096 Sep  9 15:44 config # SkyWalking OAP Server 配置文件
32 -rwxr-xr-x 1 root root 28903 Sep  9 14:32 LICENSE
 4 drwxr-xr-x 3 root root  4096 Sep  9 15:44 licenses
32 -rwxr-xr-x 1 root root 31850 Sep  9 14:32 NOTICE
16 drwxr-xr-x 2 root root 16384 Sep  9 15:22 oap-libs # SkyWalking OAP Server
 4 -rw-r--r-- 1 root root  1978 Sep  9 14:32 README.txt
 4 drwxr-xr-x 2 root root  4096 Sep  9 15:44 webapp # SkyWalking UI

2.2.2 手动编译

友情提示：如果胖友没有编译 SkyWalking 源码的诉求，可以跳过本小节。

参考 How to build project 文章。

需要前置安装如下：

GIT
JDK 8+
Maven

① 克隆代码：

$ git clone https://github.com/apache/skywalking.git

因为网络问题，可能克隆会有点久。

② 初始化子模块：

$ cd skywalking
$ git submodule init
$ git submodule update

③ 编译

$ ./mvnw clean package -DskipTests

编译过程，如果机子比较差，花费时间会比较久。

④ 查看编译结果

$ cd apm-dist # 编译结果目录
$ cd target
$ tar -zxvf apache-skywalking-apm-bin.tar.gz # 解压 Linux 包
$ cd apache-skywalking-apm-bin
$ ls -ls
 4 drwxr-xr-x 8 root root  4096 Sep  9 15:09 agent # SkyWalking Agent
 4 drwxr-xr-x 2 root root  4096 Sep  9 15:44 bin # 执行脚本
 4 drwxr-xr-x 2 root root  4096 Sep  9 15:44 config # SkyWalking OAP Server 配置文件
32 -rwxr-xr-x 1 root root 28903 Sep  9 14:32 LICENSE
 4 drwxr-xr-x 3 root root  4096 Sep  9 15:44 licenses
32 -rwxr-xr-x 1 root root 31850 Sep  9 14:32 NOTICE
16 drwxr-xr-x 2 root root 16384 Sep  9 15:22 oap-libs # SkyWalking OAP Server
 4 -rw-r--r-- 1 root root  1978 Sep  9 14:32 README.txt
 4 drwxr-xr-x 2 root root  4096 Sep  9 15:44 webapp # SkyWalking UI

2.3 SkyWalking OAP 搭建

① 修改 OAP 配置文件

友情提示：如果配置文件，适合 SkyWalking 6.X 版本。

$ vi config/application.yml

storage:
  elasticsearch7:
    nameSpace: ${SW_NAMESPACE:"elasticsearch"}
    clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:localhost:9200}
    protocol: ${SW_STORAGE_ES_HTTP_PROTOCOL:"http"}
#    trustStorePath: ${SW_SW_STORAGE_ES_SSL_JKS_PATH:"../es_keystore.jks"}
#    trustStorePass: ${SW_SW_STORAGE_ES_SSL_JKS_PASS:""}
    user: ${SW_ES_USER:""}
    password: ${SW_ES_PASSWORD:""}
    indexShardsNumber: ${SW_STORAGE_ES_INDEX_SHARDS_NUMBER:2}
    indexReplicasNumber: ${SW_STORAGE_ES_INDEX_REPLICAS_NUMBER:0}
    # Those data TTL settings will override the same settings in core module.
    recordDataTTL: ${SW_STORAGE_ES_RECORD_DATA_TTL:7} # Unit is day
    otherMetricsDataTTL: ${SW_STORAGE_ES_OTHER_METRIC_DATA_TTL:45} # Unit is day
    monthMetricsDataTTL: ${SW_STORAGE_ES_MONTH_METRIC_DATA_TTL:18} # Unit is month
    # Batch process setting, refer to https://www.elastic.co/guide/en/elasticsearch/client/java-api/5.5/java-docs-bulk-processor.html
    bulkActions: ${SW_STORAGE_ES_BULK_ACTIONS:1000} # Execute the bulk every 1000 requests
    flushInterval: ${SW_STORAGE_ES_FLUSH_INTERVAL:10} # flush the bulk every 10 seconds whatever the number of requests
    concurrentRequests: ${SW_STORAGE_ES_CONCURRENT_REQUESTS:2} # the number of concurrent requests
    resultWindowMaxSize: ${SW_STORAGE_ES_QUERY_MAX_WINDOW_SIZE:10000}
    metadataQueryMaxSize: ${SW_STORAGE_ES_QUERY_MAX_SIZE:5000}
    segmentQueryMaxSize: ${SW_STORAGE_ES_QUERY_SEGMENT_SIZE:200}
#  h2:
#    driver: ${SW_STORAGE_H2_DRIVER:org.h2.jdbcx.JdbcDataSource}
#    url: ${SW_STORAGE_H2_URL:jdbc:h2:mem:skywalking-oap-db}
#    user: ${SW_STORAGE_H2_USER:sa}
#    metadataQueryMaxSize: ${SW_STORAGE_H2_QUERY_MAX_SIZE:5000}

storage.elasticsearch7 配置项，设置使用 Elasticsearch 7.X 版本作为存储器。
- 这里，我们打开注释，并记得通过 nameSpace 设置 Elasticsearch 集群名。
storage.elasticsearch 配置项，设置使用 Elasticsearch 6.X 版本作为存储器。
- 这里，我们无需做任何改动。
- 如果胖友使用 Elasticsearch 6.X 版本作为存储器，记得设置这个配置项，而不是 storage.elasticsearch7 配置项。
storage.h2 配置项，设置使用 H2 作为存储器。
- 这里，我们需要手动注释掉，因为 H2 是默认配置的存储器。

友情提示：如果配置文件，适合 SkyWalking 7.X 版本。

重点修改 storage 配置项，通过 storage.selector 配置项来设置具体使用的存储器。
storage.elasticsearch 配置项，设置使用 Elasticsearch 6.X 版本作为存储器。胖友可以主要修改 nameSpace、clusterNodes 两个配置项即可，设置使用的 Elasticsearch 的集群和命名空间。
storage.elasticsearch7 配置项，设置使用 Elasticsearch 7.X 版本作为存储器。
还有 MySQL、H2、InfluxDB 等等存储器的配置可以选择，胖友自己根据需要去选择哈~

② 启动 SkyWalking OAP 服务

$ bin/oapService.sh

SkyWalking OAP started successfully!

是否真正启动成功，胖友打开 logs/skywalking-oap-server.log 日志文件，查看是否有错误日志。首次启动时，因为 SkyWalking OAP 会创建 Elasticsearch 的索引，所以会“疯狂”的打印日志。最终，我们看到如下日志，基本可以代表 SkyWalking OAP 服务启动成功：

友情提示：因为首次启动会创建 Elasticsearch 索引，所以可能会比较慢。

2020-01-02 18:22:53,635 - org.eclipse.jetty.server.Server - 444 [main] INFO  [] - Started @35249ms

2.4 SkyWalking UI 搭建

① 启动 SkyWalking UI 服务

bin/webappService.sh

SkyWalking Web Application started successfully!

是否真正启动成功，胖友打开 logs/logs/webapp.log 日志文件，查看是否有错误日志。最终，我们看到如下日志，基本可以代表 SkyWalking UI 服务启动成功：

2020-01-02 18:27:02.824  INFO 48250 --- [main] o.a.s.apm.webapp.ApplicationStartUp      : Started ApplicationStartUp in 7.774 seconds (JVM running for 8.316)

如果想要修改 SkyWalking UI 服务的参数，可以编辑 webapp/webapp.yml 配置文件。例如说：

server.port ：SkyWalking UI 服务端口。
collector.ribbon.listOfServers ：SkyWalking OAP 服务地址数组。因为 SkyWalking UI 界面的数据，是通过请求 SkyWalking OAP 服务来获得的。

② 访问 UI 界面：

浏览器打开 http://127.0.0.1:8080 。界面如下图：

2.5 SkyWalking Agent

大多数情况下，我们在启动项目的 Shell 脚本上，通过 -javaagent 参数进行配置 SkyWalking Agent 。我们在「2.3.1 Shell」小节来看。

考虑到偶尔我们需要在 IDE 中，也希望使用 SkyWalking Agent ，所以我们在「2.3.2 IDEA」小节来看。

2.3.1 Shell

① Agent 软件包

我们需要将 apache-skywalking-apm-bin/agent 目录，拷贝到 Java 应用所在的服务器上。这样，Java 应用才可以配置使用该 SkyWalking Agent。我们来看看 Agent 目录下有哪些：

$ ls -ls

total 35176
    0 drwxr-xr-x@  7 yunai  staff       224 Dec 24 14:20 activations
    0 drwxr-xr-x@  4 yunai  staff       128 Dec 24 14:21 bootstrap-plugins
    0 drwxr-xr-x@  3 yunai  staff        96 Dec 24 14:12 config # SkyWalking Agent 配置
    0 drwxr-xr-x@  3 yunai  staff        96 Jan  2 19:29 logs # SkyWalking Agent 日志
    0 drwxr-xr-x@ 13 yunai  staff       416 Dec 24 14:22 optional-plugins # 可选插件
    0 drwxr-xr-x@ 68 yunai  staff      2176 Dec 24 14:20 plugins # 插件
35176 -rw-r--r--@  1 yunai  staff  18006420 Dec 24 14:12 skywalking-agent.jar # SkyWalking Agent

关于 SkyWalking Agent 提供的插件列表，可以看看《SkyWalking 文档 —— 插件支持列表》。

因为艿艿是在本机测试，所以无需拷贝，SkyWalking Agent 目录是 /Users/yunai/skywalking/apache-skywalking-apm-bin-es7/agent/。

考虑到方便胖友，艿艿这里提供了一个最简的 Spring Boot 应用 lab-39-demo-2.2.2.RELEASE.jar。对应 Github 仓库是 lab-39-demo。

② 配置 Java 启动脚本

# SkyWalking Agent 配置
export SW_AGENT_NAME=demo-application # 配置 Agent 名字。一般来说，我们直接使用 Spring Boot 项目的 `spring.application.name` 。
export SW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800 # 配置 Collector 地址。
export SW_AGENT_SPAN_LIMIT=2000 # 配置链路的最大 Span 数量。一般情况下，不需要配置，默认为 300 。主要考虑，有些新上 SkyWalking Agent 的项目，代码可能比较糟糕。
export JAVA_AGENT=-javaagent:/Users/yunai/skywalking/apache-skywalking-apm-bin-es7/agent/skywalking-agent.jar # SkyWalking Agent jar 地址。

# Jar 启动
java -jar $JAVA_AGENT -jar lab-39-demo-2.2.2.RELEASE.jar

通过环境变量，进行配置。
更多的变量，可以在 /work/programs/skywalking/apache-skywalking-apm-bin/agent/config/agent.config 查看。要注意，可能有些变量是被注释掉的，例如说 SW_AGENT_SPAN_LIMIT 对应的 agent.span_limit_per_segment 。

③ 执行脚本：

直接执行上述的 Shell 脚本，启动 Java 项目。在启动日志中，我们可以看到 SkyWalking Agent 被加载的日志。日志示例如下：

DEBUG 2020-01-02 19:29:29:400 main AgentPackagePath : The beacon class location is jar:file:/Users/yunai/skywalking/apache-skywalking-apm-bin-es7/agent/skywalking-agent.jar!/org/apache/skywalking/apm/agent/core/boot/AgentPackagePath.class.
INFO 2020-01-02 19:29:29:402 main SnifferConfigInitializer : Config file found in /Users/yunai/skywalking/apache-skywalking-apm-bin-es7/agent/config/agent.config.

同时，也可以在 /Users/yunai/skywalking/apache-skywalking-apm-bin-es7/agent/agent/logs/skywalking-api.log 查看对应的 SkyWalking Agent 日志。日志示例如下：

DEBUG 2020-01-02 19:37:22:539 SkywalkingAgent-5-ServiceAndEndpointRegisterClient-0 ServiceAndEndpointRegisterClient : ServiceAndEndpointRegisterClient running, status:CONNECTED.

这里，我们看到 status:CONNECTED ，表示 SkyWalking Agent 连接 SkyWalking OAP 服务成功。

④ 简单测试

完事，可以去 SkyWalking UI 查看是否链路收集成功。

1、首先，使用浏览器，访问下 http://127.0.0.1:8079/demo/echo 地址，请求下 Spring Boot 应用提供的 API。因为，我们要追踪下该链路。

2、然后，继续使用浏览器，打开 http://127.0.0.1:8080/ 地址，进入 SkyWalking UI 界面。如下图所示：

这里，我们会看到 SkyWalking 中非常重要的三个概念：

服务(Service) ：表示对请求提供相同行为的一系列或一组工作负载。在使用 Agent 或 SDK 的时候，你可以定义服务的名字。如果不定义的话，SkyWalking 将会使用你在平台（例如说 Istio）上定义的名字。

这里，我们可以看到 Spring Boot 应用的服务为 "demo-application"，就是我们在环境变量 SW_AGENT_NAME 中所定义的。
服务实例(Service Instance) ：上述的一组工作负载中的每一个工作负载称为一个实例。就像 Kubernetes 中的 pods 一样, 服务实例未必就是操作系统上的一个进程。但当你在使用 Agent 的时候, 一个服务实例实际就是操作系统上的一个真实进程。

这里，我们可以看到 Spring Boot 应用的服务为 {agent_name}-pid:{pid}@{hostname}，由 Agent 自动生成。关于它，我们在「5.1 hostname」小节中，有进一步的讲解，胖友可以瞅瞅。
端点(Endpoint) ：对于特定服务所接收的请求路径, 如 HTTP 的 URI 路径和 gRPC 服务的类名 + 方法签名。

这里，我们可以看到 Spring Boot 应用的一个端点，为 API 接口 /demo/echo。

3、之后，点击「拓扑图」菜单，进入查看拓扑图的界面。如下图所示：

4、再之后，点击「追踪」菜单，进入查看链路数据的界面。如下图所示：

2.3.2 IDEA

我们统一使用 IDEA 作为开发 IDE ，所以忽略 Eclipse 的配置方式。

具体参考下图，比较简单：

3. 搭建 SkyWalking 集群环境

在生产环境下，我们一般推荐搭建 SkyWalking 集群环境。😈 当然，如果公司比较抠门，也可以在生产环境下使用 SkyWalking 单机环境，毕竟 SkyWalking 挂了之后，不影响业务的正常运行。

搭建一个 SkyWalking 集群环境，步骤如下：

第一步，搭建一个 Elasticsearch 服务的集群。
第二步，搭建一个注册中心的集群。目前 SkyWalking 支持 Zookeeper、Kubernetes、Consul、Nacos 作为注册中心。
第三步，搭建一个 SkyWalking OAP 服务的集群，同时参考《SkyWalking 文档 —— 集群管理》，将 SkyWalking OAP 服务注册到注册中心上。
第四步，启动一个 Spring Boot 应用，并配置 SkyWalking Agent。另外，在设置 SkyWaling Agent 的 SW_AGENT_COLLECTOR_BACKEND_SERVICES 地址时，需要设置多个 SkyWalking OAP 服务的地址数组。
第五步，搭建一个 SkyWalking UI 服务的集群，同时使用 Nginx 进行负载均衡。另外，在设置 SkyWalking UI 的 collector.ribbon.listOfServers 地址时，也需要设置多个 SkyWalking OAP 服务的地址数组。

😈 具体的搭建过程，并不复杂，胖友自己去尝试下。

4. 告警

在 SkyWaling 中，已经提供了告警功能，具体可见《SkyWalking 文档 —— 告警》。

默认情况下，SkyWalking 已经内置告警规则。同时，我们可以参考告警规则，进行自定义。

在满足 SkyWalking 告警规则的触发规则时，我们在 SkyWaling UI 的告警界面，可以看到告警内容。如下图所示：

同时，我们自定义 Webhook ，对接 SkyWalking 的告警请求。而具体的邮箱、钉钉等告警方式，需要自己进行开发。至于自定义 WebHook 如何实现，可以参考：

Java 语言：
- 《基于 SkyWalking 的分布式跟踪系统 - 异常告警》
Go 语言：
- dingding-notify-for-skywalking
- infra-skywalking-webhook

5. 注意事项

5.1 hostname 配置

在 SkyWalking 中，每个被监控的实例的名字，会包含 hostname 。格式为：{agent_name}-pid:{pid}@{hostname} ，例如说："scrm-scheduler-pid:27629@iZbp1e2xlyvr7fh67qi59oZ" 。

因为有些服务器未正确设置 hostname ，所以我们一定要去修改，不然都不知道是哪个服务器上的实例（😈 鬼知道 "iZbp1e2xlyvr7fh67qi59oZ" 一串是哪个服务器啊）。

修改方式如下：

1、修改 /etc/hosts 的 hostname ：

127.0.0.1 localhost
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.80.62.151 pre-app-01 # 就是这个，其中 10.80.62.151 是本机内网 IP ，pre-app-01 是 hostname 。

2、修改本机 hostname ：

参考《CentOS7 修改主机名（hostname）》

$ hostname pre-app-01 # 其中 pre-app-01 就是你希望的 hostname 。

$ hostnamectl set-hostname pre-app-01 # 其中 pre-app-01 就是你希望的 hostname 。

6. Spring Boot 使用示例

在《芋道 Spring Boot 链路追踪 SkyWalking 入门》中，我们来详细学习如何在 Spring Boot 中，整合并使用 SkyWalking 收集链路数据。😈 相比「2.5 SkyWaling Agent」来说，我们会提供更加丰富的示例哟。

7. Spring Cloud 使用示例

在《芋道 Spring Cloud 链路追踪 SkyWalking 入门》中，我们来详细学习如何在 Spring Cloud 中，整合并使用 SkyWalking 收集链路数据。😈 相比「2.5 SkyWaling Agent」来说，我们会提供更加丰富的示例哟。

666. 彩蛋

本文仅仅是简单的 SkyWalking 入门文章，如果胖友想要更好的使用 SkyWalking，推荐通读下《SkyWalking 文档》。

想要进一步深入的胖友，也可以阅读如下资料：

😈 最后弱弱的问一句，上完 SkyWaling 之后，有没发现自己系统各种地方慢慢慢！嘻嘻。

Zh: 使用 chart 部署 SkyWalking

Tue, 08 Oct 2019 00:00:00 +0000

作者：innerpeacez
原文地址

本文主要讲述的是如何使用 Helm Charts 将 SkyWalking 部署到 Kubernetes 集群中，相关文档可以参考skywalking-kubernetes 和 backend-k8s 文档。

目前推荐的四种方式：

使用 helm 2 提供的 helm serve 启动本地 helm repo
使用本地 chart 文件部署
使用 harbor 提供的 repo 功能
直接从官方 repo 进行部署

注意：目前 skywalking 的 chart 还没有提交到官方仓库，请先参照前三种方式进行部署

Helm 2 提供的 helm serve

打包对应版本的 skywalking chart

1.配置 helm 环境，参考 Helm 环境配置，如果你要部署 helm2 相关 chart 可以直接配置 helm2 的相关环境

2.克隆/下载ZIP skywalking-kubernetes 这个仓库，仓库关于chart的目录结构如下

helm-chart

helm2

6.0.0-GA

6.1.0

helm3

6.3.0

6.4.0

克隆/下载ZIP 完成后进入指定目录打包对应版本的chart

cd skywalking-kubernetes/helm-chart/<helm-version>/<skywalking-version>

注意：helm-version 为对应的 helm 版本目录，skywalking-version 为对应的 skywalking 版本目录，下面以helm3 和 skywalking 6.3.0 为例

cd skywalking-kubernetes/helm-chart/helm3/6.3.0

3.由于skywalking 依赖 elasticsearch 作为存储库，执行以下命令更新依赖，默认会从官方repo进行拉取

helm dep up skywalking

Hang tight while we grab the latest from your chart repositories… …Successfully got an update from the “stable” chart repository Update Complete. ⎈Happy Helming!⎈ Saving 1 charts Downloading elasticsearch from repo https://kubernetes-charts.storage.googleapis.com/ Deleting outdated charts

如果官方 repo 不存在，请先添加官方仓库

helm repo add stable https://kubernetes-charts.storage.googleapis.com

“stable” has been added to your repositories

4.打包 skywalking , 执行以下命令

helm package skywalking/

Successfully packaged chart and saved it to: C:\code\innerpeacez_github\skywalking-kubernetes\helm-chart\helm3\6.3.0\skywalking-0.1.0.tgz

打包完成后会在当前目录的同级目录生成 .tgz 文件

ls

skywalking/ skywalking-0.1.0.tgz

启动 helm serve

由于上文配置的 helm 为 helm3 ,但是 helm 3中移除了 helm serve 的相关命令，所以需要另外一个环境配置helm2 的相关环境，下载 helm 2.14.3 的二进制文件，配置基本上没有大的差别，不在赘述

初始化 helm

helm init

将上文生成的 skywalking-0.1.0.tgz 文件复制到 helm 相关目录 /root/.helm/repository/local,启动 serve

helm serve --address <ip>:8879 --repo-path /root/.helm/repository/local

注意： ip 为要能够被上文配置 helm 3 环境的机器访问到

可以访问一下看看服务 serve 是否启动成功

curl ip:8879

部署 skywalking

1.在helm3 环境中添加启动的本地 repo

helm repo add local http://<ip>:8879

2.查看 skywalking chart 是否存在于本地仓库中

helm search skywalking

NAME CHART VERSION APP VERSION DESCRIPTION
local/skywalking 0.1.0 6.3.0 Apache SkyWalking APM System

3.部署

helm -n test install skywalking local/skywalking

这样 skywalking 就部署到了 k8s 集群中的 test 命名空间了，至此本地安装skywalking 就完成了。

本地文件部署

如果你不想存储到 chart 到仓库中也可以直接使用本地文件部署 skywalking,按照上面的步骤将skywalking chart 打包完成之后，直接使用以下命令进行部署

helm -n test install skywalking skywalking-0.1.0.tgz

harbor 作为 repo 存储 charts

harbor 目前已经提供了，charts repo 的能力，这样就可以将 docker 镜像和 chart 存储在一个仓库中了，方便维护，具体harbor 的部署方法参考 Harbor 作为存储仓库存储 chart

官方 repo 部署

目前没有发布到官方 repo 中，后续发布完成后，只需要执行下面命令即可

helm install -n test stable/skywalking

总结

四种方式都可以进行部署，如果你想要自定义 chart ,需要使用上述两种本地方法及 harbor 存储的方式，以便你修改好 chart 之后进行部署.

Zh: 如何使用 SkyWalking Agent ？

Fri, 30 Aug 2019 00:00:00 +0000

作者：innerpeacez

原文地址

如果你还不知道 Skywalking agent 是什么，请点击这里查看 Probe 或者这里查看快速了解agent,由于我这边大部分都是 JAVA 服务，所以下文以 Java 中使用 agent 为例，提供了以下三种方式供你选择

三种方式：

使用官方提供的基础镜像
将 agent 包构建到已经存在的基础镜像中
sidecar 模式挂载 agent

1.使用官方提供的基础镜像

查看官方 docker hub 提供的基础镜像，只需要在你构建服务镜像是 From 这个镜像即可，直接集成到 Jenkins 中可以更加方便

2.将 agent 包构建到已经存在的基础镜像中

提供这种方式的原因是：官方的镜像属于精简镜像，并且是 openjdk ，可能很多命令没有，需要自己二次安装，以下是我构建的过程

下载 oracle jdk

这个现在 oracle 有点恶心了，wget 各种不行，然后我放弃了，直接从官网下载了

下载 skywalking 官方发行包，并解压（以6.3.0为例）

wget https://www.apache.org/dyn/closer.cgi/skywalking/6.3.0/apache-skywalking-apm-6.3.0.tar.gz && tar -zxvf apache-skywalking-apm-6.3.0.tar.gz

通过以下 dockerfile 构建基础镜像

FROM alpine:3.8 

ENV LANG=C.UTF-8

RUN set -eux && \
	apk update && apk upgrade && \
	wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub &&\
        wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.30-r0/glibc-2.30-r0.apk &&\
        apk --no-cache add unzip vim curl git bash ca-certificates glibc-2.30-r0.apk file && \
	rm -rf /var/lib/apk/* &&\
        mkdir -p /usr/skywalking/agent/

# A streamlined jre
ADD jdk1.8.0_221/ /usr/java/jdk1.8.0_221/
ADD apache-skywalking-apm-bin/agent/ /usr/skywalking/agent/

# set env
ENV JAVA_HOME /usr/java/jdk1.8.0_221
ENV PATH ${PATH}:${JAVA_HOME}/bin

# run container with base path:/
WORKDIR /

CMD bash

这里由于 alpine 是基于mini lib 的，但是 java 需要 glibc ,所以加入了 glibc 相关的东西，最后构建出的镜像大小在 490M 左右，因为加了挺多命令还是有点大，仅供参考，同样构建出的镜像也可以直接配置到 jenkins 中。

3.sidecar 模式挂载 agent

如果你们的服务是部署在 Kubernetes 中，你还可以使用这种方式来使用 Skywalking Agent ,这种方式的好处在与不需要修改原来的基础镜像，也不用重新构建新的服务镜像，而是以sidecar 模式，通过共享volume的方式将agent 所需的相关文件挂载到已经存在的服务镜像中

构建 skywalking agent sidecar 镜像的方法

下载skywalking 官方发行包，并解压

wget https://www.apache.org/dyn/closer.cgi/skywalking/6.3.0/apache-skywalking-apm-6.3.0.tar.gz && tar -zxvf apache-skywalking-apm-6.3.0.tar.gz

通过以下 dockerfile 进行构建

FROM busybox:latest 

ENV LANG=C.UTF-8

RUN set -eux && mkdir -p /usr/skywalking/agent/

ADD apache-skywalking-apm-bin/agent/ /usr/skywalking/agent/

WORKDIR /

注意：这里我没有在dockerfile中下载skywalking 发行包是因为保证构建出的 sidecar 镜像保持最小，bosybox 只有700 k左右，加上 agent 最后大小小于20M

如何使用 sidecar 呢？

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    name: demo-sw
  name: demo-sw
spec:
  replicas: 1
  selector:
    matchLabels:
      name: demo-sw
  template:
    metadata:
      labels:
        name: demo-sw
    spec:
      initContainers:
      - image: innerpeacez/sw-agent-sidecar:latest
        name: sw-agent-sidecar
        imagePullPolicy: IfNotPresent
        command: ['sh']
        args: ['-c','mkdir -p /skywalking/agent && cp -r /usr/skywalking/agent/* /skywalking/agent']
        volumeMounts:
        - mountPath: /skywalking/agent
          name: sw-agent
      containers:
      - image: nginx:1.7.9
        name: nginx
        volumeMounts:
        - mountPath: /usr/skywalking/agent
          name: sw-agent
        ports:
        - containerPort: 80
      volumes:
      - name: sw-agent
        emptyDir: {}

以上是挂载 sidecar 的 deployment.yaml 文件，以nginx 作为服务为例，主要是通过共享 volume 的方式挂载 agent，首先 initContainers 通过 sw-agent 卷挂载了 sw-agent-sidecar 中的 /skywalking/agent ，并且将上面构建好的镜像中的 agent 目录 cp 到了 /skywalking/agent 目录，完成之后 nginx 启动时也挂载了 sw-agent 卷，并将其挂载到了容器的 /usr/skywalking/agent 目录，这样就完成了共享过程。

总结

这样除去 ServiceMesh 以外，我能想到的方式就介绍完了，希望可以帮助到你。最后给 Skywalking 一个 Star 吧，国人的骄傲。

Zh: SkyWalking的远程调试

Thu, 24 Jan 2019 00:00:00 +0000

ps:本文仅写给菜鸟，以及不知道如何远程调试的程序员，并且仅仅适用skywalking的远程调试

概述

远程调试的目的是为了解决代码或者说程序包部署在服务器上运行，只能通过log来查看问题，以及不能跟在本地IDE运行debug那样查找问题，观看程序运行流程… 想想当你的程序运行在服务器上，你在本地的IDE随时debug，是不是很爽的感觉。

好了不废话，切入正题。

环境篇

IDE：推荐 IntelliJ IDEA

开发语言: 本文仅限于java，其他语言请自行询问google爸爸或者baidu娘娘

源代码：自行从github下载，并且确保你运行的skywalking包也源代码的一致，（也就是说你自己从源代码编译打包运行，虽然不一样也可以调试，但是你想想你在本地开发，更改完代码，没有重新运行，debug出现的诡异情况）

场景篇

假定有如下三台机器

IP	用途	备注
10.193.78.1	oap-server	skywalking 的oap服务（或者说collector所在的服务器）
10.193.78.2	agent	skywalking agent运行所在的服务器
10.193.78.0	IDE	你自己装IDE也就是IntelliJ IDEA的机器

以上环境，场景请自行安装好，并确认正常运行。本文不在赘述

废话终于说完了

操作篇

首要条件，下载源码后，先用maven 打包编译。然后使用Idea打开源码的父目录，整体结构大致如下图

1 :agent调试

1)Idea 配置部分

点击Edit Configurations 在弹出窗口中依次找到（红色线框的部分）并点击打开的界面如下

修改Name值，自己随意，好记即可然后Host输入10.193.78.2 Port默认或者其他的，重要的是这个端口在10.193.78.2上没有被占用

然后找到Use module classpath 选择 apm-agent 最终的结果如下：

注意选择目标agent运行的jdk版本，很重要

然后点击Apply，并找到如下内容，并且复制待用

2）agent配置部分

找到agent配置的脚本，并打开，找到配置agent的地方，就这个地方，在这个后边加上刚才复制的内容最终的结果如下提供一个我配置的weblogic的配置（仅供参考）然后重启应用（agent）

3）调试

回到Idea中找到这个地方，并点击debug按钮，你没看错，就是红色圈住的地方然后控制台如果出现以下字样：那么恭喜你，可以愉快的加断点调试了。 ps:需要注意的是agent的、 service instance的注册可能不能那么愉快的调试。因为这个注册比较快，而且是在agent启动的时候就发生的，而远程调试也需要agent打开后才可以调试，所以，如果你手快当我没说这句话。

2 :oap-server的调试（也就是collector的调试）

具体过程不在赘述，和上一步的agent调试大同小异，不同的是 Use module classpath需要选择oap-server

Zh: SkyWalking Java 插件贡献实践

Mon, 21 Jan 2019 00:00:00 +0000

引言

《SkyWalking Java 插件贡献实践》：本文将基于SkyWalking 6.0.0-GA-SNAPSHOT版本，以编写Redis客户端Lettuce的SkyWalking Java Agent 插件为例，与大家分享我贡献PR的过程，希望对大家了解SkyWalking Java Agent插件有所帮助。

基础概念

OpenTracing和SkyWalking链路模块几个很重要的语义概念。

Span:可理解为一次方法调用，一个程序块的调用，或一次RPC/数据库访问。只要是一个具有完整时间周期的程序访问，都可以被认为是一个span。SkyWalking Span对象中的重要属性

属性	名称	备注
component	组件	插件的组件名称，如：Lettuce，详见:ComponentsDefine.Class。
tag	标签	k-v结构，关键标签，key详见：Tags.Class。
peer	对端资源	用于拓扑图，若DB组件，需记录集群信息。
operationName	操作名称	若span=0，operationName将会搜索的下拉列表。
layer	显示	在链路页显示，详见SpanLayer.Class。

Trace:调用链，通过归属于其的Span来隐性的定义。一条Trace可被认为是一个由多个Span组成的有向无环图（DAG图），在SkyWalking链路模块你可以看到，Trace又由多个归属于其的trace segment组成。
Trace segment:Segment是SkyWalking中的一个概念，它应该包括单个OS进程中每个请求的所有范围，通常是基于语言的单线程。由多个归属于本线程操作的Span组成。

核心API

跨进程ContextCarrier核心API

为了实现分布式跟踪，需要绑定跨进程的跟踪，并且应该传播上下文整个过程。这就是ContextCarrier的职责。
以下是实现有关跨进程传播的步骤：
- 在客户端，创建一个新的空的ContextCarrier，将ContextCarrier所有信息放到HTTP heads、Dubbo attachments 或者Kafka messages。
- 通过服务调用，将ContextCarrier传递到服务端。
- 在服务端，在对应组件的heads、attachments或messages获取ContextCarrier所有消息。将服务端和客户端的链路信息绑定。

跨线程ContextSnapshot核心API

除了跨进程，跨线程也是需要支持的，例如异步线程（内存中的消息队列）和批处理在Java中很常见，跨进程和跨线程十分相似，因为都是需要传播上下文。唯一的区别是，不需要跨线程序列化。
以下是实现有关跨线程传播的步骤：
- 使用ContextManager＃capture获取ContextSnapshot对象。
- 让子线程以任何方式，通过方法参数或由现有参数携带来访问ContextSnapshot。
- 在子线程中使用ContextManager#continued。

详尽的核心API相关知识，可点击阅读《插件开发指南-中文版本》

插件实践

Lettuce操作redis代码

@PostMapping("/ping")
public String ping(HttpServletRequest request) throws ExecutionException, InterruptedException {
    RedisClient redisClient = RedisClient.create("redis://" + "127.0.0.1" + ":6379");
    StatefulRedisConnection<String, String> connection0 = redisClient.connect();
    RedisAsyncCommands<String, String> asyncCommands0 = connection0.async();
    AsyncCommand<String, String, String> future = (AsyncCommand<String, String, String>)asyncCommands0.set("key_a", "value_a");
    future.onComplete(s -> OkHttpClient.call("http://skywalking.apache.org"));
    future.get();
    connection0.close();
    redisClient.shutdown();
    return "pong";
}

插件源码架构

Lettuce对Redis封装与Redisson Redisson 类似，目的均是实现简单易用，且无学习曲线的Java的Redis客户端。所以要是先对Redis操作的拦截，需要学习对应客户端的源码。

设计插件

理解插件实现过程，找到最佳InterceptPoint位置是实现插件融入SkyWalking的核心所在。

代码实现

PR的url：Support lettuce plugin

实践中遇到的问题

多线程编程使用debug断点会将链路变成同步，建议使用run模式增加log，或者远程debug来解决。
多线程编程，需要使用跨线程ContextSnapshot核心API，否则链路会断裂。
CompleteableCommand.onComplete方法有时会同步执行，这个和内部机制有关，有时候不分离线程。
插件编译版本若为1.7+，需要将插件放到可选插件中。因为sniffer支持的版本是1.6。

插件兼容

为了插件得到插件最终的兼容兼容版本，我们需要使用docker对所有插件版本的测试，具体步骤如下：

编写测试用例：关于如何编写测试用例，请按照如何编写文档来实现。
提供自动测试用例。如：Redisson插件testcase
确保本地几个流行的插件版本，在本地运行起来是和自己的预期是一致的。
在提供自动测试用例并在CI中递交测试后，插件提交者会批准您的插件。
最终得到完整的插件测试报告。

Pull Request

提交PR

提交PR的时候，需要简述自己对插件的设计，这样有助于与社区的贡献者讨论完成codereview。

申请自动化测试

测试用例编写完成后，可以申请自动化测试，在自己的PR中会生成插件兼容版本的报告。

插件文档

插件文档需要更新：Supported-list.md相关插件信息的支持。

插件如果为可选插件需要在agent-optional-plugins可选插件文档中增加对应的描述。

注释

Lettuce是一个完全无阻塞的Redis客户端，使用netty构建，提供反应，异步和同步数据访问。了解细节可点击阅读 lettuce.io;

OpenTracing是一个跨编程语言的标准，了解细节可点击阅读《OpenTracing语义标准》;

span:org.apache.skywalking.apm.agent.core.context.trace.AbstractSpan接口定义了所有Span实现需要完成的方法;

Redisson是一个非常易用Java的Redis客户端，它没有学习曲线，无需知道任何Redis命令即可开始使用它。了解细节可点击阅读 redisson.org;

Zh: SkyWalking 微服务监控分析

Thu, 03 Jan 2019 00:00:00 +0000

作者：赵瑞栋
原文地址

引言

微服务框架落地后，分布式部署架构带来的问题就会迅速凸显出来。服务之间的相互调用过程中，如果业务出现错误或者异常，如何快速定位问题？如何跟踪业务调用链路？如何分析解决业务瓶颈？…本文我们来看看如何解决以上问题。

一、SkyWalking初探

Skywalking 简介

Skywalking是一款国内开源的应用性能监控工具，支持对分布式系统的监控、跟踪和诊断。

它提供了如下的主要功能特性：

Skywalking 技术架构

SW总体可以分为四部分：

1.Skywalking Agent：使用Javaagent做字节码植入，无侵入式的收集，并通过HTTP或者gRPC方式发送数据到Skywalking Collector。

Skywalking Collector ：链路数据收集器，对agent传过来的数据进行整合分析处理并落入相关的数据存储中。
Storage：Skywalking的存储，时间更迭，sw已经开发迭代到了6.x版本，在6.x版本中支持以ElasticSearch、Mysql、TiDB、H2、作为存储介质进行数据存储。
UI ：Web可视化平台，用来展示落地的数据。

Skywalking Agent配置

通过了解配置，可以对一个组件功能有一个大致的了解。让我们一起看一下skywalking的相关配置。

解压开skywalking的压缩包，在agent/config文件夹中可以看到agent的配置文件。

从skywalking支持环境变量配置加载，在启动的时候优先读取环境变量中的相关配置。

agent.namespace: 跨进程链路中的header，不同的namespace会导致跨进程的链路中断
agent.service_name:一个服务（项目）的唯一标识，这个字段决定了在sw的UI上的关于service的展示名称
agent.sample_n_per_3_secs: 客户端采样率，默认是-1代表全采样
agent.authentication: 与collector进行通信的安全认证，需要同collector中配置相同
agent.ignore_suffix: 忽略特定请求后缀的trace
collecttor.backend_service: agent需要同collector进行数据传输的IP和端口
logging.level: agent记录日志级别

skywalking agent使用javaagent无侵入式的配合collector实现对分布式系统的追踪和相关数据的上下文传递。

Skywalking Collector关键配置

Collector支持集群部署，zookeeper、kubernetes（如果你的应用是部署在容器中的）、consul（GO语言开发的服务发现工具）是sw可选的集群管理工具，结合大家具体的部署方式进行选择。详细配置大家可以去Skywalking官网下载介质包进行了解。

Collector端口设置

downsampling: 采样汇总统计维度，会分别按照分钟、【小时、天、月】（可选）来统计各项指标数据。
通过设置TTL相关配置项可以对数据进行自动清理。

Skywalking 在6.X中简化了配置。collector提供了gRPC和HTTP两种通信方式。

UI使用rest http通信，agent在大多数场景下使用grpc方式通信，在语言不支持的情况下会使用http通信。

关于绑定IP和端口需要注意的一点是，通过绑定IP，agent和collector必须配置对应ip才可以正常通信。

Collector存储配置

在application.yml中配置的storage模块配置中选择要使用的数据库类型，并填写相关的配置信息。

Collector Receiver

Receiver是Skywalking在6.x提出的新的概念，负责从被监控的系统中接受指标数据。用户完全可以参照OpenTracing规范来上传自定义的监控数据。Skywalking官方提供了service-mesh、istio、zipkin的相关能力。

现在Skywalking支持服务端采样，配置项为sampleRate，比例采样，如果配置为5000则采样率就是50%。

关于采样设置的一点注意事项

关于服务采样配置的一点建议，如果Collector以集群方式部署，比如：Acollector和Bcollector，建议Acollector.sampleRate = Bcollector.sampleRate。如果采样率设置不相同可能会出现数据丢失问题。

假设Agent端将所有数据发送到后端Collector处，A采样率设置为30%，B采样率为50%。

假设有30%的数据，发送到A上，这些数据被全部正确接受并存储，极端情况（与期望的采样数据量相同）下，如果剩下20%待采样的数据发送到了B，这个时候一切都是正常的，如果这20%中有一部分数据被送到了A那么，这些数据将是被忽略的，由此就会造成数据丢失。

二、业务调用链路监控

Service Topology监控

调用链路监控可以从两个角度去看待。我们先从整体上来认识一下我们所监控的系统。

通过给服务添加探针并产生实际的调用之后，我们可以通过Skywalking的前端UI查看服务之间的调用关系。

我们简单模拟一次服务之间的调用。新建两个服务，service-provider以及service-consumer，服务之间简单的通过Feign Client 来模拟远程调用。

从图中可以看到:

有两个服务节点：provider & consumer
有一个数据库节点：localhost【mysql】
一个注册中心节点

consumer消费了provider提供出来的接口。

一个系统的拓扑图让我们清晰的认识到系统之间的应用的依赖关系以及当前状态下的业务流转流程。细心的可能发现图示节点consumer上有一部分是红色的，红色是什么意思呢？

红色代表当前流经consumer节点的请求有一断时间内是响应异常的。当节点全部变红的时候证明服务现阶段内就彻底不可用了。运维人员可以通过Topology迅速发现某一个服务潜在的问题，并进行下一步的排查并做到预防。

Skywalking Trace监控

Skywalking通过业务调用监控进行依赖分析，提供给我们了服务之间的服务调用拓扑关系、以及针对每个endpoint的trace记录。

我们在之前看到consumer节点服务中发生了错误，让我们一起来定位下错误是发生在了什么地方又是什么原因呢？

在每一条trace的信息中都可以看到当前请求的时间、GloableId、以及请求被调用的时间。我们分别看一看正确的调用和异常的调用。

Trace调用链路监控

图示展示的是一次正常的响应，这条响应总耗时19ms，它有4个span：

span1 /getStore = 19ms 响应的总流转时间
span2 /demo2/stores = 14ms feign client 开始调用远程服务后的响应的总时间
span3 /stores = 14ms 接口服务响应总时间
span4 Mysql = 1ms 服务提供端查询数据库的时间

这里span2和span3的时间表现相同，其实是不同的，因为这里时间取了整。

在每个Span中可以查看当前Span的相关属性。

组件类型: SpringMVC、Feign
Span状态: false
HttpMethod: GET
Url: http://192.168.16.125:10002/demo2/stores

这是一次正常的请求调用Trace日志，可能我们并不关心正常的时候，毕竟一切正常不就是我们期待的么！

我们再来看下，异常状态下我们的Trace以及Span又是什么样的呢。

发生错误的调用链中Span中的is error标识变为true，并且在名为Logs的TAB中可以看到错误发生的具体原因。根据异常情况我们就可以轻松定位到影响业务的具体原因，从而快速定位问题，解决问题。

通过Log我们看到连接被拒，那么可能是我们的网络出现了问题（可能性小，因为实际情况如果网络出现问题我们连这个trace都看不到了），也有可能是服务端配置问题无法正确建立连接。通过异常日志，我们迅速就找到了问题的关键。

实际情况是，我把服务方停掉了，做了一次简单的模拟。可见，通过拓扑图示我们可以清晰的看到众多服务中哪个服务是出现了问题的，通过trace日志我们可以很快就定位到问题所在，在最短的时间内解决问题。

三、服务性能指标监控

Skywalking还可以查看具体Service的性能指标，根据相关的性能指标可以分析系统的瓶颈所在并提出优化方案。

Skywalking 性能监控

在服务调用拓扑图上点击相应的节点我们可以看到该服务的

SLA: 服务可用性（主要是通过请求成功与失败次数来计算）
CPM: 每分钟调用次数
Avg Response Time: 平均响应时间

从应用整体外部来看我们可以监测到应用在一定时间段内的

服务可用性指标SLA
每分钟平均响应数
平均响应时间
服务进程PID
服务所在物理机的IP、HostName、Operation System

Service JVM信息监控

还可以监控到Service运行时的CPU、堆内存、非堆内存使用率、以及GC情况。这些信息来源于JVM。注意这里的数据可不是机器本身的数据。

四、服务告警

前文我们提到了通过查看拓扑图以及调用链路可以定位问题，可是运维人员又不可能一直盯着这些数据，那么我们就需要告警能力，在异常达到一定阈值的时候主动的提示我们去查看系统状态。

在Sywalking 6.x版本中新增了对服务状态的告警能力。它通过webhook的方式让我们可以自定义我们告警信息的通知方式。诸如:邮件通知、微信通知、短信通知等。

Skywalking 服务告警

先来看一下告警的规则配置。在alarm-settings.xml中可以配置告警规则，告警规则支持自定义。

一份告警配置由以下几部分组成：

service_resp_time_rule：告警规则名称 ***_rule （规则名称可以自定义但是必须以’_rule’结尾
indicator-name：指标数据名称：定义参见http://t.cn/EGhfbmd
op: 操作符： > , < , = 【当然你可以自己扩展开发其他的操作符】
threshold：目标值：指标数据的目标数据如sample中的1000就是服务响应时间，配合上操作符就是大于1000ms的服务响应
period: 告警检查周期：多久检查一次当前的指标数据是否符合告警规则
counts: 达到告警阈值的次数
silence-period：忽略相同告警信息的周期
message：告警信息
webhooks：服务告警通知服务地址

Skywalking通过HttpClient的方式远程调用在配置项webhooks中定义的告警通知服务地址。

了解了SW所传送的数据格式我们就可以对告警信息进行接收处理，实现我们需要的告警通知服务啦！

我们将一个服务停掉，并将另外一个服务的某个对外暴露的接口让他休眠一定的时间。然后调用一定的次数观察服务的状态信息以及告警情况。

总结

本文简单的通过skwaylking的配置来对skywlaking的功能进行一次初步的了解，对skwaylking新提出的概念以及新功能进行简单的诠释，方便大家了解和使用。通过使用APM工具，可以让我们方便的查看微服务架构中系统瓶颈以及性能问题等。

精选提问

问1：想问问选型的时候用pinpoint还是SK好？

答：选型问题

要结合具体的业务场景，比如你的代码运行环境是java、php、net还是什么。
pinpoint在安装部署上要比skywalking略微复杂
pinpoint和sw支持的组件列表是不同的。 https://github.com/apache/incubator-skywalking/blob/master/docs/en/setup/service-agent/java-agent/Supported-list.md你可以参照这里的支持列表对比下pinpoint的支持对象做一个简单对比。
sw经过测试在并发量较高的情况下比pinpoint的吞吐量更好一些。

问2：有没有指标统计，比如某个url 的top10 请求、响应最慢的10个请求？某个服务在整个链条中的耗时占比？

答：1.sw自带有响应最慢的请求top10统计针对所有的endpoint的统计。 2.针对每个url的top10统计，sw本身没有做统计，数据都是现成的通过简单的检索就可以搜到你想要的结果。 3.没有具体的耗时占比，但是有具体总链路时间统计以及某个服务的耗时统计，至于占比自己算吧，可以看ppt中的调用链路监控的span时间解释。

问3：能不能具体说一下在你们系统中的应用？

答：EOS8LA版本中，我们整合sw对应用提供拓扑、调用链路、性能指标的监控、并在sw数据的基础上增加系统的维度。当服务数很庞大的时候，整体的拓扑其实就是一张密密麻麻的蜘蛛网。我们可以通过系统来选择具体某个系统下的应用。 8LA中SW是5.0.0alpha版本，受限于sw功能，我们并没有提供告警能力，这在之后会是我们的考虑目标。

问4：业务访问日志大概每天100G，kubernetes 环境中部署，使用稳定吗？

答：监控数据没有长时间的存储必要，除非你有特定的需求。它有一定的时效性，你可以设置ttl自动清除过时信息。100g，es集群还是能轻松支撑的。

问5：和pinpoint相比有什么优势吗？

答：

部署方式、使用方式简单
功能特性支持的更多
高并发性能会更好一些

问6：skywalking的侵入式追踪功能方便进行单服务链的服务追踪。但是跨多台服务器多项目的整体服务链追踪是否有整体设计考虑？

答：sw本身特性就是对分布式系统的追踪，他是无侵入式的。无关你的应用部署在多少台服务器上。

问7：应用在加上代理之后性能会下降。请问您有什么解决方法吗？

答：性能下降是在所难免的，但是据我了解，以及官方的测试，他的性能影响是很低的。这是sw的测试数据供你参考。 https://skywalkingtest.github.io/Agent-Benchmarks/README_zh.html。

问8：有异构系统需求的话可以用sw吗？

答：只要skywalking的探针支持的应该都是可以的。

问9：sw对于商用的web中间件，如bes、tongweb、websphere、weblogic的支持如何？

答：商业组件支持的比较少，因为涉及到相关license的问题，sw项目组需要获得他们的支持来进行数据上报，据我了解，支持不是很好。

Zh: 关于 ElasticSearch 因 basic 认证导致 SkyWalking 无法正常调用接口问题

Wed, 02 Jan 2019 00:00:00 +0000

SkyWalking 依赖 elasticsearch 集群，如果 elasticsearch 安装有 x-pack 插件的话，那么就会存在一个 Basic 认证，导致 skywalking 无法调用 elasticsearch, 解决方法是使用 nginx 做代理，让 nginx 来做这个 Basic 认证，那么这个问题就自然解决了。

方法如下:

安装 nginx

yum install -y nginx

配置 nginx

server {
        listen       9200 default_server;
        server_name  _;
        
        location / {
                 proxy_set_header Host $host;
                 proxy_set_header X-Real-IP $remote_addr;
                 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                 proxy_pass http://localhost:9200;
                 #Basic字符串就是使用你的用户名(admin),密码(12345)编码后的值
                 #注意:在进行Basic加密的时候要使用如下格式如:admin:123456 注意中间有个冒号
                 proxy_set_header Authorization "Basic YWRtaW4gMTIzNDU2";
        }
    }

验证

curl localhost:9200

{
  "name" : "Yd0rCp9",
  "cluster_name" : "es-cn-4590xv9md0009doky",
  "cluster_uuid" : "jAPLrqY5R6KWWgHnGCWOAA",
  "version" : {
    "number" : "6.3.2",
    "build_flavor" : "default",
    "build_type" : "tar",
    "build_hash" : "053779d",
    "build_date" : "2018-07-20T05:20:23.451332Z",
    "build_snapshot" : false,
    "lucene_version" : "7.3.1",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
  },
  "tagline" : "You Know, for Search"
}

看到如上结果那么恭喜你成功了。

Zh: 更容易理解将要到来的分布式链路追踪 6.0GA (翻译)

Wed, 02 Jan 2019 00:00:00 +0000

作者: Wu Sheng, tetrate, SkyWalking original creator
GitHub, Twitter, Linkedin
翻译: jjlu521016

背景

在当前的微服务架构中分布式链路追踪是很有必要的一部分，但是对于一些用户来说如何去理解和使用分布式链路追踪的相关数据是不清楚的。这个博客概述了典型的分布式跟踪用例，以及Skywalking的V6版本中新的可视化功能。我们希望新的用户通过这些示例来更好的理解。

指标和拓扑图

跟踪数据支持两个众所周知的分析特性：指标和拓扑图
指标: 每个service, service instance, endpoint的指标都是从跟踪中的入口span派生的。指标代表响应时间的性能。所以可以有一个平均响应时间，99%的响应时间，成功率等。它们按service, service instance, endpoint进行分解。
拓扑图: 拓扑表示服务之间的链接，是分布式跟踪最有吸引力的特性。拓扑结构允许所有用户理解分布式服务关系和依赖关系，即使它们是不同的或复杂的。这一点很重要，因为它为所有相关方提供了一个单一的视图，无论他们是开发人员、设计者还是操作者。

这里有一个拓扑图的例子包含了4个项目，包括kafka和两个外部依赖。

-在skywalking的可选择UI0RocketBot的拓扑图-

Trace

在分布式链路追踪系统中，我们花费大量资源（CPU、内存、磁盘和网络）来生成、传输和持久跟踪数据。让我们试着回答为什么要这样做？我们可以用跟踪数据回答哪些典型的诊断和系统性能问题？

Skywalking v6包含两种追踪视图:

1. TreeMode: 第一次提供,帮助您更容易识别问题。
1. ListMode: 常规的时间线视图，通常也出现在其他跟踪系统中，如Zipkin。

发生错误

在trace视图，最简单的部分是定位错误，可能是由代码异常或网络故障引起的。通过span详情提供的细节，ListMode和TreeMode都能够找到错误

-ListMode 错误span-

-TreeMode 错误span-

慢span

一个高优先级的特性是识别跟踪中最慢的span。这将使用应用程序代理捕获的执行持续时间。在旧的ListMode跟踪视图中，由于嵌套，父span几乎总是包括子span的持续时间。换句话说，一个缓慢的span通常会导致它的父节点也变慢，在Skywalking 6中，我们提供了 最慢的前5个span 过滤器来帮助你您直接定位span。

-最慢的前5个span-

太多子span

在某些情况下，个别持续时间很快，但跟踪速度仍然很慢，如：

-没有慢span的追踪-

如果要了解根问题是否与太多操作相关，请使用子范围号的Top 5 of children span number,筛选器显示每个span的子级数量，突出显示前5个。

-13个数据库访问相关的span-

在这个截图中，有一个包含13个子项的span，这些子项都是数据库访问。另外，当您看到跟踪的概述时，这个2000ms跟踪的数据库花费了1380ms。

-1380ms花费在数据库访问-

在本例中，根本原因是数据库访问太多。这在其他场景中也很常见，比如太多的RPC或缓存访问。

链路深度

跟踪深度也与延迟有关。像太多子span的场景一样，每个span延迟看起来不错，但整个链路追踪的过程很慢。

-链路深度-

上图所示,最慢的span小鱼500ms,对于2000毫秒的跟踪来说，速度并不太慢。当您看到第一行时，有四种不同的颜色表示这个分布式跟踪中涉及的四个services。每一个都需要100~400ms，这四个都需要近2000ms，从这里我们知道这个缓慢的跟踪是由一个序列中的3个RPC造成的。

结束语

分布式链路追踪和APM 工具帮助我们确定造成问题的根源，允许开发和操作团队进行相应的优化。我们希望您喜欢这一点，并且喜欢Apache Skywalking和我们的新链路追踪可视化界面。如果你喜欢的话，在github上面给我们加start来鼓励我们

Skywakling 6计划在2019年的1月底完成release。您可以通过以下渠道联系项目团队成员

关注 skywalking推特
订阅邮件:dev@skywalking.apache.org。发送邮件到 dev-subscribe@kywalking.apache.org 来订阅.
加入Gitter聊天室

Zh: SkyWalking apm-sniffer 原理学习与插件编写

Fri, 21 Dec 2018 00:00:00 +0000

导读

SkyWalking 中 Java 探针是使用 JavaAgent 的两大字节码操作工具之一的 Byte Buddy（另外是 Javassist）实现的。项目还包含.Net core 和 Nodejs 自动探针，以及 Service Mesh Istio 的监控。总体上，SkyWalking 是一个多语言，多场景的适配，特别为微服务、云原生和基于容器架构设计的可观测性分析平台（Observability Analysis Platform）。
本文基于 SkyWalking 5.0.0-RC2 和 Byte Buddy 1.7.9 版本，会从以下几个章节，让大家掌握 SkyWalking Java 探针的使用，进而让 SkyWalking 在自己公司中的二次开发变得触手可及。
- Byte Buddy 实现 JavaAgent 项目
- 迭代 JavaAgent 项目的方法论
- SkyWalking agent 项目如何 Debug
- SkyWalking 插件开发实践
文章底部有 SkyWalking 和 Byte Buddy 相应的学习资源。

Byte Buddy 实现

首先如果你对 JavaAgent 还不是很了解可以先百度一下，或在公众号内看下《JavaAgent 原理与实践》简单入门下。
SpringMVC 分发请求的关键方法相信已经不用我在赘述了，那我们来编写 Byte Buddy JavaAgent 代码吧。

 public class AgentMain {
    public static void premain(String agentOps, Instrumentation instrumentation) {
        new AgentBuilder.Default()
                .type(ElementMatchers.named("org.springframework.web.servlet.DispatcherServlet"))
                .transform((builder, type, classLoader, module) ->
                        builder.method(ElementMatchers.named("doDispatch"))
                                .intercept(MethodDelegation.to(DoDispatchInterceptor.class)))
                .installOn(instrumentation);
    }
}

编写 DispatcherServlet doDispatch 拦截器代码（是不是跟 AOP 如出一辙）

 public class DoDispatchInterceptor {
    @RuntimeType
    public static Object intercept(@Argument(0) HttpServletRequest request, @SuperCall Callable<?> callable) {
        final StringBuilder in = new StringBuilder();
        if (request.getParameterMap() != null && request.getParameterMap().size() > 0) {
            request.getParameterMap().keySet().forEach(key -> in.append("key=" + key + "_value=" + request.getParameter(key) + ","));
        }
        long agentStart = System.currentTimeMillis();
        try {
            return callable.call();
        } catch (Exception e) {
            System.out.println("Exception :" + e.getMessage());
            return null;
        } finally {
            System.out.println("path:" + request.getRequestURI() + " 入参:" + in + " 耗时:" + (System.currentTimeMillis() - agentStart));
        }
    }
}

resources/META-INF/MANIFEST.MF

Manifest-Version: 1.0
Premain-Class: com.z.test.agent.AgentMain
Can-Redefine-Classes: true

pom.xml 文件

dependencies
    +net.bytebuddy.byte-buddy 
    +javax.servlet.javax.servlet-api *scope=provided
plugins
    +maven-jar-plugin *manifestFile=src/main/resources/META-INF/MANIFEST.MF
    +maven-shade-plugin *include:net.bytebuddy:byte-buddy:jar:
    +maven-compiler-plugin

小结：没几十行代码就完成了，通过 Byte Buddy 实现应用组件 SpringMVC 记录请求路径、入参、执行时间 JavaAgent 项目，是不是觉得自己很优秀。

持续迭代 JavaAgent

本章节主要介绍 JavaAgent 如何 Debug，以及持续集成的方法论。
首先我的 JavaAgent 项目目录结构如图所示:
应用项目是用几行代码实现的 SpringBootWeb 项目:

@SpringBootApplication(scanBasePackages = {"com"})
public class TestBootWeb {
    public static void main(String[] args) {
        SpringApplication.run(TestBootWeb.class, args);
    }
    @RestController
    public class ApiController {
        @PostMapping("/ping")
        public String ping(HttpServletRequest request) {
            return "pong";
        }
    }
}

下面是关键 JavaAgent 项目如何持续迭代与集成:

VM options增加:-JavaAgent:{$HOME}/Code/github/z_my_test/test-agent/target/test-agent-1.0-SNAPSHOT.jar=args
Before launch 在Build之前增加：
    Working directory:{$HOME}/Code/github/incubator-skywalking
    Command line:-T 1C -pl test-agent -am clean package -Denforcer.skip=true -Dmaven.test.skip=true -Dmaven.compile.fork=true

小结：看到这里的将 JavaAgent 持续迭代集成方法，是不是瞬间觉得自己手心已经发痒起来，很想编写一个自己的 agent 项目了呢，等等还有一个好消息:test-demo 这 10 几行的代码实现的 Web 服务，居然有 5k 左右的类可以使用 agent 增强。
注意 mvn 编译加速的命令是 maven3 + 版本以上才支持的哈。

SkyWalking Debug

峰回路转，到了文章的主题《SkyWalking 之高级用法》的正文啦。首先，JavaAgent 项目想 Debug，还需要将 agent 代码与接入 agent 项目至少在同一个工作空间内，网上方法有很多，这里我推荐大家一个最简单的方法。File->New->Module from Exisiting Sources… 引入 skywalking-agent 源码即可
详细的 idea 编辑器配置：
优化 SkyWalking agent 编译时间，我的集成时间优化到 30 秒左右：

VM options增加:-JavaAgent:-JavaAgent:{$HOME}/Code/github/incubator-skywalking/skywalking-agent/skywalking-agent.jar：不要用dist里面的skywalking-agent.jar，具体原因大家可以看看源码：apm-sniffer/apm-agent/pom.xml中的maven插件的使用。
Before launch 在Build之前增加：
    Working directory:{$HOME}/Code/github/incubator-skywalking
    Command line:-T 1C -pl apm-sniffer/apm-sdk-plugin -amd clean package -Denforcer.skip=true -Dmaven.test.skip=true -Dmaven.compile.fork=true： 这里我针对插件包，因为紧接着下文要开发插件
另外根pom注释maven-checkstyle-plugin也可加速编译

kob 之 SkyWalking 插件编写

kob（贝壳分布式作业调度框架）是贝壳找房项目微服务集群中的基础组件，通过编写贝壳分布式作业调度框架的 SkyWalking 插件，可以实时收集作业调度任务的执行链路信息，从而及时得到基础组件的稳定性，了解细节可点击阅读《贝壳分布式调度框架简介》。想详细了解 SkyWalking 插件编写可在文章底部参考链接中，跳转至对应的官方资源，好话不多说，代码一把唆起来。
apm-sdk-plugin pom.xml 增加自己的插件 model

<artifactId>apm-sdk-plugin</artifactId>
    <modules>
        <module>kob-plugin</module>
        ...
    <modules>

resources.skywalking-plugin.def 增加自己的描述

kob=org.apache.skywalking.apm.plugin.kob.KobInstrumentation

在 SkyWalking 的项目中，通过继承 ClassInstanceMethodsEnhancePluginDefine 可以定义需要拦截的类和增强的方法，编写作业调度方法的 instrumentation

public class KobInstrumentation extends ClassInstanceMethodsEnhancePluginDefine {
    private static final String ENHANCE_CLASS = "com.ke.kob.client.spring.core.TaskDispatcher";
    private static final String INTERCEPT_CLASS = "org.apache.skywalking.apm.plugin.kob.KobInterceptor";
    @Override
    protected ClassMatch enhanceClass() {
        return NameMatch.byName(ENHANCE_CLASS);
    }
    @Override
    protected ConstructorInterceptPoint[] getConstructorsInterceptPoints() {
        return null;
    }
    @Override
    protected InstanceMethodsInterceptPoint[] getInstanceMethodsInterceptPoints() {
        return new InstanceMethodsInterceptPoint[] {
                new InstanceMethodsInterceptPoint() {
                    @Override
                    public ElementMatcher<MethodDescription> getMethodsMatcher() {
                        return named("dispatcher1");
                    }
                    @Override
                    public String getMethodsInterceptor() {
                        return INTERCEPT_CLASS;
                    }
                    @Override
                    public boolean isOverrideArgs() {
                        return false;
                    }
                }
        };
    }
}

通过实现 InstanceMethodsAroundInterceptor 后，定义 beforeMethod、afterMethod 和 handleMethodException 的实现方法，可以环绕增强指定目标方法，下面自定义 interceptor 实现 span 的跟踪（这里需要注意 SkyWalking 中 span 的生命周期，在 afterMethod 方法中结束 span）

public class KobInterceptor implements InstanceMethodsAroundInterceptor {
    @Override
    public void beforeMethod(EnhancedInstance objInst, Method method, Object[] allArguments,  Class<?>[] argumentsTypes, MethodInterceptResult result) throws Throwable {
        final ContextCarrier contextCarrier = new ContextCarrier();
        com.ke.kob.client.spring.model.TaskContext context = (TaskContext) allArguments[0];
        CarrierItem next = contextCarrier.items();
        while (next.hasNext()) {
            next = next.next();
            next.setHeadValue(JSON.toJSONString(context.getUserParam()));
        }
        AbstractSpan span = ContextManager.createEntrySpan("client:"+allArguments[1]+",task:"+context.getTaskKey(), contextCarrier);
        span.setComponent(ComponentsDefine.TRANSPORT_CLIENT);
        SpanLayer.asRPCFramework(span);
    }
    @Override
    public Object afterMethod(EnhancedInstance objInst, Method method, Object[] allArguments, Class<?>[] argumentsTypes, Object ret) throws Throwable {
        ContextManager.stopSpan();
        return ret;
    }
    @Override
    public void handleMethodException(EnhancedInstance objInst, Method method, Object[] allArguments, Class<?>[] argumentsTypes, Throwable t) {
    }
}

实现效果，将操作名改成任务执行节点 + 任务执行方法，实现 kob 的 SkyWalking 的插件编写，加上报警体系，可以进一步增加公司基础组件的稳定性。

参考链接

Zh: SkyWalking 源码解析合集

Fri, 21 Dec 2018 00:00:00 +0000

搭建调试环境

阅读 SkyWalking 源码，从配置调试环境开始。

一定一定一定不要干读代码，而是通过调试的方式。

SkyWalking 3.X 源码解析合集

虽然是基于 3.X 版本的源码解析，但是对于阅读 SkyWalking Java Agent 和插件部分，同样适用。

对于 SkyWalking Collector 部分，可以作为一定的参考。

SkyWalking 6.X 源码解析合集

《SkyWalking 6.x 源码分析 —— 调试环境搭建》

Zh: Apache SkyWalking 5.0 中文版图文详解使用手册

Tue, 18 Dec 2018 00:00:00 +0000

版本选择

我们采用的是 5.0.0-RC2 的版本，SkyWalking 的版本信息可以参考 https://github.com/apache/incubator-skywalking/blob/5.x/CHANGES.md

那么为什么我们没有采用 5.1.0 版本呢，这是因为我们公司内部需要支持 es x-pack，但是在官方发布里面，没有支持 xpack 的版本。

在 Apache SkyWalking 官方文档 https://github.com/CharlesMaster/incubator-skywalking/tree/master/docs/others/cn 中有提到，SkyWalking 5.x 仍受社区支持。

对于用户计划从 5.x 升级到 6.x，您应该知道关于有一些概念的定义的变更。最重要的两个改变了的概念是：

Application（在 5.x 中）更改为 Service（在 6.x 中），Application Instance 也更改为 Service Instance。
Service（在 5.x 中）更改为 Endpoint（在 6.x 中）。

图文详解

Apache SkyWalking 的监控界面由 Monitor 和 Trace 两者构成，Monitor 菜单又包括 Dashbord、Topology、Application、Service、Alarm 五个子菜单构成。本文就是围绕这些菜单分别逐一进行介绍。

Monitor

当用户通过 SkyWalking 登陆界面使用用户名、密码登陆以后，就会默认进入到 SkyWalking 的 Monitor 下的 Dashboard 界面

Dashboard

下图就是用户登陆之后都会看到的关键 Dashboard 页面，在这个页面的下方的关键指标，图中都做了详细的解释。

上图中 app 需要强调的是，52 个 app 并不代表 52 个应用，比如 paycenter 有两台 paycenter1 和 paycenter2 就算了 2 个 app，当然还有一些应用是 3 个以上的。在我们公司，paycenter1、paycenter2 这些运维都和我们跳板机管理平台上的名称设置的一样，约定大于配置，开发人员可以更加便捷的排查问题。

再次修正一下，关于 dashboard 页面的 app 数，语言类探针，是探针的 app_code 来决定的。比如我们公司的线上配置就是 agent.application_code=auth-center-1

上图中需要解释两个概念：

cpm 代表每分钟请求次数
SLA=(TRANSACTION_CALLS- TRANSACTION_ERROR_CALLS ) * 10000 ) / TRANSACTION_CALLS

该页面主要支持四个跳转：

一、在上图中，App 板块上的帮助选项是可以直接跳转到 Application 监控页面的。

二、 Service 板块上的帮助选项是可以直接跳转到 Service 监控页面的。

三、 Slow Service 列表中的每一个慢服务点击以后都会进入到其专项的 Service 监控页面。

四、 Application Throughput 列表中的每一个 Application 点击以后也都是可以进入到其专项的 Application 监控页面。

关于 Application 和 Service 的详细介绍我们后续会展开

在 Dashboard 的页面上部分，还有一个选择功能模块：

左侧部分可以定期 refresh Dashboard 的数据，右侧则可以调整整体的查询区间。

Topology

点击 Monitor 菜单下的 Topology 你会看到下面这张拓扑图

当然这张图太过于夸张了，如果接入 SkyWalking 的应用并不是很多，会如下图所示：

左侧的三个小按钮可以调整你的视图，支持拖拽。右侧可以输入你所关心的应用名。比如我们输入一个支付和订单两个应用，左侧的拓扑图会变得更加清晰：

另外，上图中的绿色圆圈都是可以点击的，如果你点击以后，还会出现节点信息：

Application

点击 Monitor 菜单下的 Application 你会看到下面这张图，这张图里你可以看到的东西都做了注解。

这张图里有一个惊喜，就是如果你点开 More Server Details，你可以看到更多的信息

是的，除了 Host、IPv4、Pid、OS 以外，你还可以看到 CPU、Heap、Non-Heap、GC（Young GC、Old GC）等详细监控信息。

Service

点击 Monitor 菜单下的 Service 你会看到下面这张图，这张图里你可以看到的同样都做了注解。

关于 Dependency Map 这张图我们再补充一下，鼠标悬停可以看到每个阶段的执行时间，这是 Service 下的功能

我们点开图中该图中 Top 20 Slow Traces 下面的被我马赛克掉的 trace 的按钮框，可以看到如下更加详细的信息：

这些信息可以帮助我们知道每一个方法在哪个阶段那个具体实现耗时了多久。

如上图所示，每一行基本都是可以打开的，每一行都包含了 Tags、Logs 等监控内容

Alarm

点击 Monitor 菜单下的 Alarm 你会看到告警菜单。目前 5.X 版本的还没有接入邮件、短信等告警方式，后续 6 支持 webhook，用户可以自己去接短信和邮件。

告警内容中你可以看到 Applicaion、Server 和 Service 三个层面的告警内容

Trace

Trace 是一个非常实用的功能，用户可以根据精确的 TraceId 去查找

也可以设定时间段去查找

我在写使用手册时候，非常巧的是，看到了上图三起异常，于是我们往下拉列表看到了具体的数据

点击进去，我们可以看到具体的失败原因

当然用户也可以直接将 Trace State 调整为 Error 级别进行查询

再回顾一遍

一、首先我们进入首页：

二、点击一下首页的 Slow Service 的 projectC，可以看到如下信息：

三、如果点击首页的 Appliation Throughput 中的 projectD，可以看到如下信息：

四、继续点进去右下角的这个 slow service 里的 Consumer，我们可以看到下图：

Apache SkyWalking – User Manual

Zh: 如何使用java探针注入器?

目录

1. 介绍

1.1 SWCK 是什么？

1.2 java 探针注入器是什么？

2. 主要特点

3. 安装SWCK

3.1 工具准备

3.2 搭建单机版 Kubernetes集群

3.3 安装证书管理器(cert-manger)

3.4 安装SWCK

3.5 安装 Skywalking 组件 — OAPServer 和 UI

4. 部署demo应用

4.1 设置全局配置

4.2 设置自定义配置

4.3 部署 spring boot 应用

4.4 部署 spring cloud gateway 应用

5. 验证注入器

6. 结束语

Zh: Cyborg Flow X SkyWalking: 生产环境全链路压测

介绍

原理

Flow Gateway

Agent/Dashboard

Agent

Dashboard

Database Shadow

快速上手

部署 Database Shadow

部署 Cyborg Dashboard

部署 Cyborg Agent 到业务程序中

部署 Flow Gateway

完成！

总结

Zh: Chaos Mesh X SkyWalking: 可观测的混沌工程

准备工作

Step 1 - 访问 SkyWalking 集群

Step 2 - 部署 SkyWalking Kubernetes Event Exporter

Step 3 - 使用 JMeter 对服务加压

通过 JMeter 对 localhost:8079 进行压测，添加5个线程持续进行加压。

Step 4 - Chaos Mesh 注入故障，观察效果

小结

Zh: SkyWalking报警发送到钉钉群

Zh: 度量服务网格健康度——Apdex得分

“你感觉怎么样” 比 “你的症状是什么” 更重要

背景

服务网格中的健康状况

Apdex

数学表示

样例计算

深入使用

更进一步

这一天即将到来

总结

引用

Zh: SkyWalking 极简入门

1. 概述

1.1 概念

1.2 功能列表

1.3 整体架构

1.4 官方文档

2. 搭建 SkyWalking 单机环境

2.1 Elasticsearch 搭建

2.2 下载 SkyWalking 软件包

2.2.1 官方包

2.2.2 手动编译

2.3 SkyWalking OAP 搭建

2.4 SkyWalking UI 搭建

2.5 SkyWalking Agent

2.3.1 Shell

2.3.2 IDEA

3. 搭建 SkyWalking 集群环境

4. 告警

5. 注意事项

5.1 hostname 配置

6. Spring Boot 使用示例

7. Spring Cloud 使用示例

666. 彩蛋

Zh: 使用 chart 部署 SkyWalking

通过 JMeter 对 `localhost:8079` 进行压测，添加5个线程持续进行加压。