|
|
|
|
公众号矩阵

通过Prometheus来做SLI/SLO监控展示

SRE通常通过这两个指标来衡量系统的稳定性,其主要思路就是通过SLI来判断SLO,也就是通过一系列的指标来衡量我们的目标是否达到了"几个9"。

作者:乔克来源:运维开发故事|2021-04-07 14:53

什么是SLI/SLO

SLI,全名Service Level Indicator,是服务等级指标的简称,它是衡定系统稳定性的指标。

SLO,全名Sevice Level Objective,是服务等级目标的简称,也就是我们设定的稳定性目标,比如"4个9","5个9"等。

SRE通常通过这两个指标来衡量系统的稳定性,其主要思路就是通过SLI来判断SLO,也就是通过一系列的指标来衡量我们的目标是否达到了"几个9"。

如何选择SLI

在系统中,常见的指标有很多种,比如:

  • 系统层面:CPU使用率、内存使用率、磁盘使用率等
  • 应用服务器层面:端口存活状态、JVM的状态等
  • 应用运行层面:状态码、时延、QPS等
  • 中间件层面:QPS、TPS、时延等
  • 业务层面:成功率、增长速度等

这么多指标,应该如何选择呢?只要遵从两个原则就可以:

  • 选择能够标识一个主体是否稳定的指标,如果不是这个主体本身的指标,或者不能标识主体稳定性的,就要排除在外。
  • 优先选择与用户体验强相关或用户可以明显感知的指标。

通常情况下,可以直接使用谷歌的VALET指标方法。

  • V:Volume,容量,服务承诺的最大容量
  • A:Availability,可用性,服务是否正常
  • L:Latency,延迟,服务的响应时间
  • E:Error,错误率,请求错误率是多少
  • T:Ticket,人工介入,是否需要人工介入

这就是谷歌使用VALET方法给的样例。

上面仅仅是简单的介绍了一下SLI/SLO,更多的知识可以学习《SRE:Google运维解密》和赵成老师的极客时间课程《SRE实践手册》。下面来简单介绍如何使用Prometheus来进行SLI/SLO监控。

service-level-operator

Service level operator是为了Kubernetes中的应用SLI/SLO指标来衡量应用的服务指标,并可以通过Grafana来进行展示。

Operator主要是通过SLO来查看和创建新的指标。例如:

  1. apiVersion: monitoring.spotahome.com/v1alpha1 
  2. kind: ServiceLevel 
  3. metadata: 
  4.   name: awesome-service 
  5. spec: 
  6.   serviceLevelObjectives: 
  7.     - name"9999_http_request_lt_500" 
  8.       description: 99.99% of requests must be served with <500 status code. 
  9.       disable: false 
  10.       availabilityObjectivePercent: 99.99 
  11.       serviceLevelIndicator: 
  12.         prometheus: 
  13.           address: http://myprometheus:9090 
  14.           totalQuery: sum(increase(http_request_total{host="awesome_service_io"}[2m])) 
  15.           errorQuery: sum(increase(http_request_total{host="awesome_service_io", code=~"5.."}[2m])) 
  16.       output
  17.         prometheus: 
  18.           labels: 
  19.             team: a-team 
  20.             iteration: "3" 
  • availabilityObjectivePercent:SLO
  • totalQuery:总请求数
  • errorQuery:错误请求数

Operator通过totalQuert和errorQuery就可以计算出SLO的指标了。

部署service-level-operator

  • 前提:在Kubernetes集群中部署好Prometheus,我这里是采用Prometheus-Operator方式进行部署的。

(1)首先创建RBAC

  1. apiVersion: v1 
  2. kind: ServiceAccount 
  3. metadata: 
  4.   name: service-level-operator 
  5.   namespace: monitoring 
  6.   labels: 
  7.     app: service-level-operator 
  8.     component: app 
  9.  
  10. --- 
  11. apiVersion: rbac.authorization.k8s.io/v1 
  12. kind: ClusterRole 
  13. metadata: 
  14.   name: service-level-operator 
  15.   labels: 
  16.     app: service-level-operator 
  17.     component: app 
  18. rules: 
  19.   # Register and check CRDs. 
  20.   - apiGroups: 
  21.       - apiextensions.k8s.io 
  22.     resources: 
  23.       - customresourcedefinitions 
  24.     verbs: 
  25.       - "*" 
  26.  
  27.   # Operator logic. 
  28.   - apiGroups: 
  29.       - monitoring.spotahome.com 
  30.     resources: 
  31.       - servicelevels 
  32.       - servicelevels/status 
  33.     verbs: 
  34.       - "*" 
  35.  
  36. --- 
  37. kind: ClusterRoleBinding 
  38. apiVersion: rbac.authorization.k8s.io/v1 
  39. metadata: 
  40.   name: service-level-operator 
  41. subjects: 
  42.   - kind: ServiceAccount 
  43.     name: service-level-operator 
  44.     namespace: monitoring  
  45. roleRef: 
  46.   apiGroup: rbac.authorization.k8s.io 
  47.   kind: ClusterRole 
  48.   name: service-level-operator 

(2)然后创建Deployment

  1. apiVersion: apps/v1  
  2. kind: Deployment 
  3. metadata: 
  4.   name: service-level-operator 
  5.   namespace: monitoring 
  6.   labels: 
  7.     app: service-level-operator 
  8.     component: app 
  9. spec: 
  10.   replicas: 1 
  11.   selector: 
  12.     matchLabels: 
  13.       app: service-level-operator 
  14.       component: app 
  15.   strategy: 
  16.     rollingUpdate: 
  17.       maxUnavailable: 0 
  18.   template: 
  19.     metadata: 
  20.       labels: 
  21.         app: service-level-operator 
  22.         component: app 
  23.     spec: 
  24.       serviceAccountName: service-level-operator 
  25.       containers: 
  26.         - name: app 
  27.           imagePullPolicy: Always 
  28.           image: quay.io/spotahome/service-level-operator:latest 
  29.           ports: 
  30.             - containerPort: 8080 
  31.               name: http 
  32.               protocol: TCP 
  33.           readinessProbe: 
  34.             httpGet: 
  35.               path: /healthz/ready 
  36.               port: http 
  37.           livenessProbe: 
  38.             httpGet: 
  39.               path: /healthz/live 
  40.               port: http 
  41.           resources: 
  42.             limits: 
  43.               cpu: 220m 
  44.               memory: 254Mi 
  45.             requests: 
  46.               cpu: 120m 
  47.               memory: 128Mi 

(3)创建service

  1. apiVersion: v1 
  2. kind: Service 
  3. metadata: 
  4.   name: service-level-operator 
  5.   namespace: monitoring 
  6.   labels: 
  7.     app: service-level-operator 
  8.     component: app 
  9. spec: 
  10.   ports: 
  11.     - port: 80 
  12.       protocol: TCP 
  13.       name: http 
  14.       targetPort: http 
  15.   selector: 
  16.     app: service-level-operator 
  17.     component: app 

(4)创建prometheus serviceMonitor

  1. apiVersion: monitoring.coreos.com/v1 
  2. kind: ServiceMonitor 
  3. metadata: 
  4.   name: service-level-operator 
  5.   namespace: monitoring 
  6.   labels: 
  7.     app: service-level-operator 
  8.     component: app 
  9.     prometheus: myprometheus 
  10. spec: 
  11.   selector: 
  12.     matchLabels: 
  13.       app: service-level-operator 
  14.       component: app 
  15.   namespaceSelector: 
  16.     matchNames: 
  17.       - monitoring  
  18.   endpoints: 
  19.     - port: http 
  20.       interval: 10s 

到这里,Service Level Operator部署完成了,可以在prometheus上查看到对应的Target,如下:

然后就需要创建对应的服务指标了,如下所示创建一个示例。

  1. apiVersion: monitoring.spotahome.com/v1alpha1 
  2. kind: ServiceLevel 
  3. metadata: 
  4.   name: prometheus-grafana-service 
  5.   namespace: monitoring 
  6. spec: 
  7.   serviceLevelObjectives: 
  8.     - name"9999_http_request_lt_500" 
  9.       description: 99.99% of requests must be served with <500 status code. 
  10.       disable: false 
  11.       availabilityObjectivePercent: 99.99 
  12.       serviceLevelIndicator: 
  13.         prometheus: 
  14.           address: http://prometheus-k8s.monitoring.svc:9090 
  15.           totalQuery: sum(increase(http_request_total{service="grafana"}[2m])) 
  16.           errorQuery: sum(increase(http_request_total{service="grafana", code=~"5.."}[2m])) 
  17.       output
  18.         prometheus: 
  19.           labels: 
  20.             team: prometheus-grafana  
  21.             iteration: "3" 

上面定义了grafana应用"4个9"的SLO。

然后可以在Prometheus上看到具体的指标,如下。

接下来在Grafana上导入ID为8793的Dashboard,即可生成如下图表。

上面是SLI,下面是错误总预算和已消耗的错误。

下面可以定义告警规则,当SLO下降时可以第一时间收到,比如:

  1. groups: 
  2.   - name: slo.rules 
  3.     rules: 
  4.       - alert: SLOErrorRateTooFast1h 
  5.         expr: | 
  6.           ( 
  7.             increase(service_level_sli_result_error_ratio_total[1h]) 
  8.             / 
  9.             increase(service_level_sli_result_count_total[1h]) 
  10.           ) > (1 - service_level_slo_objective_ratio) * 14.6 
  11.         labels: 
  12.           severity: critical 
  13.           team: a-team 
  14.         annotations: 
  15.           summary: The monthly SLO error budget consumed for 1h is greater than 2% 
  16.           description: The error rate for 1h in the {{$labels.service_level}}/{{$labels.slo}} SLO error budget is being consumed too fast, is greater than 2% monthly budget. 
  17.       - alert: SLOErrorRateTooFast6h 
  18.         expr: | 
  19.           ( 
  20.             increase(service_level_sli_result_error_ratio_total[6h]) 
  21.             / 
  22.             increase(service_level_sli_result_count_total[6h]) 
  23.           ) > (1 - service_level_slo_objective_ratio) * 6 
  24.         labels: 
  25.           severity: critical 
  26.           team: a-team 
  27.         annotations: 
  28.           summary: The monthly SLO error budget consumed for 6h is greater than 5% 
  29.           description: The error rate for 6h in the {{$labels.service_level}}/{{$labels.slo}} SLO error budget is being consumed too fast, is greater than 5% monthly budget. 

第一条规则表示在1h内消耗的错误率大于30天内的2%,应该告警。第二条规则是在6h内的错误率大于30天的5%,应该告警。

下面是谷歌的的基准。

最后

说到系统稳定性,这里不得不提到系统可用性,SRE提高系统的稳定性,最终还是为了提升系统的可用时间,减少故障时间。那如何来衡量系统的可用性呢?

目前业界有两种衡量系统可用性的方式,一个是时间维度,一个是请求维度。时间维度就是从故障出发对系统的稳定性进行评估。请求维度是从成功请求占比的角度出发,对系统稳定性进行评估。

时间维度:可用性 = 服务时间 / (服务时间 + 故障时间)

请求维度:可用性 = 成功请求数 / 总请求数

在SRE实践中,通常会选择请求维度来衡量系统的稳定性,就如上面的例子。不过,如果仅仅通过一个维度来判断系统的稳定性也有点太武断,还应该结合更多的指标,比如延迟,错误率等,而且对核心应用,核心链路的SLI应该更细致。

参考

[1] 《SRE实践手册》- 赵成

[2] 《SRE:Google运维解密》

[3] https://github.com/spotahome/service-level-operator

【编辑推荐】

  1. 换掉Java的老牌日志框架Logback,我用Log4j2!
  2. 历时近 20 年,SCO 和 IBM 间的 Unix 纠纷再起
  3. 轻量级NLP工具开源,中文处理更精准,超越斯坦福Stanza
  4. 统治50年:为什么SQL在如今仍然很重要?
  5. 如何成为多编程语言人才?这有一份独门诀窍
【责任编辑:姜华 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

数据湖与数据仓库的分析实践攻略

数据湖与数据仓库的分析实践攻略

助力现代化数据管理:数据湖与数据仓库的分析实践攻略
共3章 | 创世达人

7人订阅学习

云原生架构实践

云原生架构实践

新技术引领移动互联网进入急速赛道
共3章 | KaliArch

37人订阅学习

数据中心和VPDN网络建设案例

数据中心和VPDN网络建设案例

漫画+案例
共20章 | 捷哥CCIE

230人订阅学习

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微