【轉！】skywalking告警配置

當履行職責成爲功績，當基本道德成爲美德，當所有人都失去了正確的價值判斷，這個社會距離崩潰就不遠了

---《中國是部金融史》

轉自：https://www.cnblogs.com/gaoyanbing/p/17867548.html

1、概述

Skywalking發送告警的基本原理是每隔一段時間輪詢skywalking-oap收集到的鏈路追蹤的數據，再根據所配置的告警規則（如服務響應時間、服務響應時間百分比）等，如果達到閾值則發送響應的告警信息。發送告警信息是以線程池異步的方式調用webhook接口完成的，具體的webhook接口可以由使用者自行定義，從而可以在指定的webhook接口中自行編寫各種告警方式，比如釘釘告警、郵件告警等等。告警的信息也可以在RocketBot即ui中查看到。

目前對應我前面文章中部署的8.4.0版本支持的告警接口如下：

普通webhook
gRPCHook
Slack Chat Hook
WeChat Hook（微信告警）
Dingtalk Hook（釘釘告警）
Feishu Hook（飛書告警）

2、告警規則

2.1 默認告警規則

在Skywalking中，告警規則稱爲rule，默認安裝的Skywalking oap server組件中包含了告警規則的配置文件，位於安裝目錄下conﬁg文件夾下alarm-settings.yml文件中，在容器中運行的也是一樣的

# kubectl -n monitoring exec -it skywalking-oap-57d7f454f5-w4k4j -- bash
bash-5.0# pwd
/skywalking       
bash-5.0# cat config/alarm-settings.yml

以下是默認的告警規則配置文件內容

rules:
  # Rule unique name, must be ended with `_rule`.
  service_resp_time_rule:
    metrics-name: service_resp_time
    op: ">"
    threshold: 1000
    period: 10
    count: 3
    silence-period: 5
    message: Response time of service {name} is more than 1000ms in 3 minutes of last 10 minutes.
  service_sla_rule:
    # Metrics value need to be long, double or int
    metrics-name: service_sla
    op: "<"
    threshold: 8000
    # The length of time to evaluate the metrics
    period: 10
    # How many times after the metrics match the condition, will trigger alarm
    count: 2
    # How many times of checks, the alarm keeps silence after alarm triggered, default as same as period.
    silence-period: 3
    message: Successful rate of service {name} is lower than 80% in 2 minutes of last 10 minutes
  service_resp_time_percentile_rule:
    # Metrics value need to be long, double or int
    metrics-name: service_percentile
    op: ">"
    threshold: 1000,1000,1000,1000,1000
    period: 10
    count: 3
    silence-period: 5
    message: Percentile response time of service {name} alarm in 3 minutes of last 10 minutes, due to more than one condition of p50 > 1000, p75 > 1000, p90 > 1000, p95 > 1000, p99 > 1000
  service_instance_resp_time_rule:
    metrics-name: service_instance_resp_time
    op: ">"
    threshold: 1000
    period: 10
    count: 2
    silence-period: 5
    message: Response time of service instance {name} is more than 1000ms in 2 minutes of last 10 minutes
  database_access_resp_time_rule:
    metrics-name: database_access_resp_time
    threshold: 1000
    op: ">"
    period: 10
    count: 2
    message: Response time of database access {name} is more than 1000ms in 2 minutes of last 10 minutes
  endpoint_relation_resp_time_rule:
    metrics-name: endpoint_relation_resp_time
    threshold: 1000
    op: ">"
    period: 10
    count: 2
    message: Response time of endpoint relation {name} is more than 1000ms in 2 minutes of last 10 minutes
#  Active endpoint related metrics alarm will cost more memory than service and service instance metrics alarm.
#  Because the number of endpoint is much more than service and instance.
#
#  endpoint_avg_rule:
#    metrics-name: endpoint_avg
#    op: ">"
#    threshold: 1000
#    period: 10
#    count: 2
#    silence-period: 5
#    message: Response time of endpoint {name} is more than 1000ms in 2 minutes of last 10 minutes

webhooks:
#  - http://127.0.0.1/notify/
#  - http://127.0.0.1/go-wechat/

2.2 告警規則詳解

下面取默認的告警規則中的一條進行分析

rules:
  # Rule unique name, must be ended with `_rule`.
  service_resp_time_rule:
    metrics-name: service_resp_time
    op: ">"
    threshold: 1000
    period: 10
    count: 3
    silence-period: 5
    message: Response time of service {name} is more than 1000ms in 3 minutes of last 10 minutes.

首先提示聲明瞭告警規則名稱應該具有唯一性，且必須以 _rule 結尾，這裏是service_resp_time_rule（服務響應時間）

metrics-name：告警指標，指標度量值爲long、double或int類型
op：度量值和閾值的比較方式，這裏是大於
threshold：閾值，這裏是1000，毫秒爲單位
period：評估度量標準的時間長度，也就是告警檢查週期，分鐘爲單位
count：累計達到多少次告警值後觸發告警
silence-period：忽略相同告警信息的週期，默認與告警檢查週期一致。簡單來說，就是在觸發告警時開始計時N，在N+period時間內保持沉默silence不會再次觸發告警，這和alertmanager的告警抑制類似
message：告警消息主體，通過變量在發送消息時進行自動替換

除此之外，還有以下可選（高級）規則配置：

到這裏，就能分析出上面列出的所有默認告警規則的含義，依次爲：

1 最近3分鐘內服務平均響應時間超過1秒
2 最近2分鐘內服務成功率低於80％
3 最近3分鐘的服務響應時間百分比超過1秒
4 最近2分鐘內服務實例的平均響應時間超過1秒
5 最近2分鐘內數據庫訪問的平均響應時間超過1秒
6 最近2分鐘內端點平均響應時間超過1秒
7 過去2分鐘內端點關係的平均響應時間超過1秒
  這條規則默認沒有打開，並且提示：由於端點的數量遠遠多於服務和實例，活動端點相關度量告警將比服務和服務實例度量告警消耗更多內存

3、自定義告警規則

Skywalking的配置大部分內容是通過應用的application.yml及系統的環境變量設置的，同時也支持下面系統的動態配置來源

gRPC服務
Zookeeper
Etcd
Consul
Apollo
Nacos
k8s configmap

參考Skywalking動態配置說明，如果開啓了動態配置，可以通過鍵alarm.default.alarm-settings覆蓋掉默認配置文件alarm-settings.yml

本文記錄的是基於k8s和helm部署的Skywalking，因此可以通過k8s-configmap進行自定義配置的注入，最終在Skywalking配置文件中的實現如下，此文件中有很多變量，通過分析chart，發現已經寫好邏輯會根據是否啓用動態配置來自動注入所有變量，所以就無需在value.yaml中聲明瞭

cluster:
  selector: ${SW_CLUSTER:standalone}
...
  kubernetes:
    namespace: ${SW_CLUSTER_K8S_NAMESPACE:default}
    labelSelector: ${SW_CLUSTER_K8S_LABEL:app=collector,release=skywalking}
    uidEnvName: ${SW_CLUSTER_K8S_UID:SKYWALKING_COLLECTOR_UID}
...
configuration:
  selector: ${SW_CONFIGURATION:k8s-configmap}
...
  k8s-configmap:
      # Sync period in seconds. Defaults to 60 seconds.
      period: ${SW_CONFIG_CONFIGMAP_PERIOD:60}
      # Which namespace is confiigmap deployed in.
      namespace: ${SW_CLUSTER_K8S_NAMESPACE:default}
      # Labelselector is used to locate specific configmap
      labelSelector: ${SW_CLUSTER_K8S_LABEL:app=collector,release=skywalking}

在自定義配置告警規則的同時加入webhook後端報警相關配置，configmap文件寫法可以參考官方helm configmap示例

我這裏只把默認的報警規則提示信息改成了中文報警信息，具體每條規則的參數沒有變化，同時還加入了釘釘webhook配置，具體流程如下

修改chart包的value.yaml，開啓動態配置

...
oap:
  name: oap
  dynamicConfigEnabled: true # 開啓動態配置功能
...

修改chart包中template的oap-configmap.yaml，配置自定義的rule和釘釘webhook

{{- if .Values.oap.dynamicConfigEnabled }}
apiVersion: v1
kind: ConfigMap
metadata:
  name: skywalking-dynamic-config
  labels:
    app: {{ template "skywalking.name" . }}
    release: {{ .Release.Name }}
    component: {{ .Values.oap.name }}
data:
  alarm.default.alarm-settings: |-
    rules:
      # Rule unique name, must be ended with `_rule`.
      service_resp_time_rule:
        metrics-name: service_resp_time
        op: ">"
        threshold: 1000
        period: 10
        count: 3
        silence-period: 5
        message: 最近3分鐘內服務 {name} 的平均響應時間超過1秒
      service_sla_rule:
        # Metrics value need to be long, double or int
        metrics-name: service_sla
        op: "<"
        threshold: 8000
        # The length of time to evaluate the metrics
        period: 10
        # How many times after the metrics match the condition, will trigger alarm
        count: 2
        # How many times of checks, the alarm keeps silence after alarm triggered, default as same as period.
        silence-period: 3
        message: 最近2分鐘內服務 {name} 的成功率低於80％
      service_resp_time_percentile_rule:
        # Metrics value need to be long, double or int
        metrics-name: service_percentile
        op: ">"
        threshold: 1000,1000,1000,1000,1000
        period: 10
        count: 3
        silence-period: 5
        message: 最近3分鐘的服務 {name} 的響應時間百分比超過1秒
      service_instance_resp_time_rule:
        metrics-name: service_instance_resp_time
        op: ">"
        threshold: 1000
        period: 10
        count: 2
        silence-period: 5
        message: 最近2分鐘內服務實例 {name} 的平均響應時間超過1秒
      database_access_resp_time_rule:
        metrics-name: database_access_resp_time
        threshold: 1000
        op: ">"
        period: 10
        count: 2
        # message: Response time of database access {name} is more than 1000ms in 2 minutes of last 10 minutes
        message: 最近2分鐘內數據庫訪問 {name} 的平均響應時間超過1秒
      endpoint_relation_resp_time_rule:
        metrics-name: endpoint_relation_resp_time
        threshold: 1000
        op: ">"
        period: 10
        count: 2
        message: 最近2分鐘內端點 {name} 的平均響應時間超過1秒
    dingtalkHooks:
      textTemplate: |-
        {
          "msgtype": "text",
          "text": {
            "content": "SkyWalking 鏈路追蹤告警: \n %s."
          }
        }
      webhooks:
        - url: https://oapi.dingtalk.com/robot/send?access_token=<釘釘機器人token>
          secret: <釘釘機器人加簽>
{{- end }}

修改完成後，執行helm進行更新

# ls                                                                                
skywalking
# helm -n monitoring upgrade skywalking skywalking --values ./skywalking/values.yaml
# helm -n monitoring list                                                           
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
skywalking      monitoring      3               2021-03-22 13:35:36.779541 +0800 CST    deployed        skywalking-4.0.0
# helm -n monitoring history skywalking                                             
REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION                                                                              
1               Sun Mar 21 17:45:34 2021        superseded      skywalking-4.0.0                        Install complete                                                                         
2               Mon Mar 22 13:35:36 2021        deployed        skywalking-4.0.0                        Upgrade complete

觀察pod狀態，直到正常

# kubectl -n monitoring get pods                               
NAME                              READY   STATUS      RESTARTS   AGE
elasticsearch-logging-0           1/1     Running     0          19h
elasticsearch-logging-1           1/1     Running     0          19h
elasticsearch-logging-2           1/1     Running     0          19h
skywalking-es-init-ktdcn          0/1     Completed   0          19h
skywalking-oap-7bbb775965-49895   1/1     Running     0          15s
skywalking-oap-7bbb775965-s89dz   1/1     Running     0          43s
skywalking-ui-698cdb4dbc-mjl2m    1/1     Running     0          19h

4、測試告警

爲了測試告警功能，拉上業務研發在項目中簡單寫了個url地址，請求時會超時5s返回

然後利用瀏覽器或postman請求應用的/api/timeout進行測試

查看Skywalking的ui界面，鏈路追蹤

告警界面

到釘釘中查看報警消息

到這裏，在Skywalking中配置報警就完成了 ~

附：在一次Skywalking線上分享會上記錄的關於使用Skywalking定位問題的思路：

縱覽全局，Skywalking拓撲圖
監控告警，metric/tracing確定問題存在故障（根據metric做告警，根據tracing統計作比較）
確定故障在哪，tracing調用關係，確定故障出現在哪個service或者endpoint
profile手段（skywalking新能力）或者常見傳統性能定位方法，定位單節點問題所在（比如CPU、內存、io、網絡 ——> 動態追蹤採樣 ——> 火焰圖）基本可以解決99.9%的問題

附錄：

釘釘hooks配置：

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: <加簽值>

【轉！】skywalking告警配置

1、概述

2、告警規則

2.1 默認告警規則

2.2 告警規則詳解

3、自定義告警規則

4、測試告警

關於遊戲付費的一點想法

我通過CKA和CKS啦！

【轉！】skywalking告警配置

混沌測試工具ChaosBlade

Jenkins發送HTTP請求

Jmeter（五十）Dubbo Sampler

VisualVM應用

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結