背景：

差异：

• 存储：我们将所有的 prometheus 的数据额外存储一份到 aliyun sls 中，这样不仅可以做到数据 backup，也可以方便 grafana 统一查询 prometheus 数据。

• 服务发现：由于流利说拥有大量 aliyun ecs 机器，所以我们在 prometheus 原有的服务发现基础上开发了 ecs scrape 代码，以便监控ecs机器。

• 告警：使用 pagerduty 以及正在开发的 goalert +流利说自研通知中心用于告警通知，并且支持告警调度以及告警升级。

 Gitops：

1. 统一管理 Prometheus Config：由于流利说现有多个 prometheus 同时运行，由于每个 prometheus 所要监控的数据不同，所以需要分别配置相关 Recording rules && Alerting rules，但是如果分别管理每个prometheus config 就使得运维成本非常高。所以 infra 团队就将这些配置文件统一放到一个git仓库下，当某个 prometheus config 发生改变时，就会触发 prometheus reload，使变更立刻生效。这样我们只需管理一个配置“仓库”即可。

2. 自动检测 Prometheus Config ：由于 infra 团队会定制一些 metrics 用于告警，如果配置不准确会引起 prometheus 状态异常，所以当我们更新 prometheus config 时也会检测变更的 rule 或 metrics 是否正确，主要依靠 prometheus 自带检测工具 promtool 与流利说自研检测工具 prom-threshold 来检测。相关ci文件如下：

stages:  - test check_rules:  stage: test  image: debian:jessie  script:    - find ./ -type f -name '*.yml' | grep -E 'alerting|recording' | grep -v 'threshold' | xargs ./bin/promtool-linux check rules  tags:    - docker check_threshold:  stage: test  image: prom-threshold:v0.1.1  script:    - find ./ -type d -name threshold | egrep '.*' || exit 0    - find ./ -type d -name threshold | xargs /prom_threshold -op check -path  tags:    - docker

3. 自定义告警阈值：因为我们会配置一些通用的告警，但是由于业务差异，对一些告警的要求可能不同，所以我们就会给这些业务在通用告警的基础上，通过 metrics 的方式暴露业务专有指标（业务指定的告警阈值），然后通过 recordingRules 的方式修改其告警值，从而提高了告警的灵活性。

   ThresholdMetrics:- metric: http_4xx_ratio_threshold  threshold: 0.05  labels:    host: ****.com    path: /oauth/callback - metric: http_latency_95_seconds_threshold  threshold: 20  labels:    host: ****.com    path: / AlertingRule:- name: http/latency.customized  rules:  - alert: SlowHTTP    expr: service:kong_latency:quantile95_rate1m{type="request"} > on (host,path) group_left() (http_latency_95_seconds_threshold * 1000)

4. 自研监控插件 Mercury：
• 自动备份 AlertManagerSilence：alertmanager silence 是用户应对一些告警无法避免的情况下，对某些告警的屏蔽策略，但是 alertmanager 是在本地存储数据，为了降低 alertmanager 所在服务器的宕机风险，所以我们会实时的将 silence 数据备份一份到对象存储中。
• 自动检查 AlertManagerSilence：由于我们的告警是按照特定规则发送到 pagerduty 然后通知给工程师的，当屏蔽告警的时候也需要按照特定规则去屏蔽，所以我们会定时去检测这些 silence 规则是否符合规范，如果不符合规范的话，就视为无效然后将其删除。
• 自动同步生产测试环境中 Grafana Dashboard：流利说拥有两个环境的 prometheus 所以也就会对应两套 grafana，因为监控只有数据不同，但是 grafana dashboard 两个环境中可以复用，所以我们会定时同步两个环境下的 grafana dashboard，工程师只需对生产或测试环境某一个 grafana dashboard 做更改即可，从而减轻了运维成本。
• 自动生成 AlertManagerConfig：由于我们的告警需用按照 app 或 team 发送到 pagerduty，而 pagerduty 是给每个 app 或 team 的告警生成一个 integrations（API接口），然后 alertmanager 通过这个特定的integrations，将告警发送给制定的告警策略中，由于需要告警的 app 和 team 非常多，所以在 alertmanager-config 中便会存在大量的 integrations。因此我们会在 pagerduty 生成一个 integrations 后，自动在alertmanager-config 生成相关配置。
5. 云资源监控：

• 流利说拥有各种各样的云资源，如果分别依靠云平台的监控系统，那么就与我们预期的统一监控不符，所以我们通过拉取云平台监控系统 api，将云资源相关指标暴露在 prometheus 中，对这些指标再针对性的配置 Recording rules && Alerting rules，从而使得云资源监控告警可以统一且灵活的配置。

  ExportCode:    switch collectType {    case "EsExporter":        es := exporter.EsExporter(newCmsClient())        prometheus.MustRegister(es)    case "HbaseExporter":        hbase := exporter.HbaseExporter(newCmsClient())        prometheus.MustRegister(hbase)    case "KafkaExporter":        kafka := exporter.KafkaExporter(newCmsClient())        prometheus.MustRegister(kafka)    case "KvstroeExporter":        kvstroe := exporter.KvstoreExporter(newDbClient())        prometheus.MustRegister(kvstroe)    case "NatExporter":        nat := exporter.NatExporter(newCmsClient())        prometheus.MustRegister(nat)    case "OssExporter":        oss := exporter.OssExporter(newCmsClient())        prometheus.MustRegister(oss)    case "RdsExporter":        rds := exporter.RdsExporter(newDbClient())        prometheus.MustRegister(rds)    case "SlbExporter":        slb := exporter.SlbExporter(newCmsClient())        prometheus.MustRegister(slb)    } AlertingRule:groups:- name: rds.rules  rules:  - alert: RdsConnectionOutOfUsage    expr: avg_over_time(cloudmonitor_rds_connection_usage[5m]) + on (instanceid) group_left(app,team,owner,name) avg_over_time(alicloud_rds_tags[1m]) >80    for: 3m    labels:      severity: critical      prometheus: prometheus      k8s_cluster: k8s      source: rds    annotations:      summary: "{{ $labels.app }} {{ $labels.name }} {{ $labels.instanceid }} rds connection_usage out of 80% for 3 minutes"      details: "{{ $labels.app }} {{ $labels.name }} {{ $labels.instanceid }} rds connection_usage is out of 80% for 3 minutes \n  Current value: {{ $value }}%"

• 云平台提供的监控相关指标还满足不了我们的监控需求，所以我们还会额外生成一些 export，比如 mysql_export, node_export, blackbox_export, kafka_export，然后在再通过分析这些 export 暴露出来的指标，以满足我们的需求。
  0 */1 * * * bash /opt/cloudmonitor/cloudmonitor_cronjob.sh >> /opt/cloudmonitor/cronjob.log 2>&1

‍

监控告警系统：

• 告警升级策略：我们会为每个需要告警的 app，配置相关告警升级策略，升级策略分为多层，每一层对应一个或多个人，当告警通知到某一层，无人响应时，会升级到下一层中，从而使告警减少被忽略的情况。
• 告警排班策略：对应告警升级策略中的某一层，如果这一层是多个人接受告警，可能会存在告警排班（多个人轮流接收告警）的情况，所以会配置相关的 schedule，某个人只在特定时间段内接收告警，减少工作冗余。

服务可用性SLA：prometheus 的 Recording rules 功能非常的强大，所以流利说通过此规则延伸出了服务 SLA 监控，主要是通过 kong mertics 计算 HTTP SLA，通过 istio metrics 计算 GRPC SLA。

• HTTP SLA：因为用户的所有请求都会经过 kong（网关），所以 kong 上可以记录下每个域名的 http_status，再通过相关的 Recording rules 计算出每个 http 请求的相关指标对应到 HTTP SLA。
• GRPC SLA：流利说的服务基本都在 k8s 中运行，一个大型的服务又分为多个微服务，为了便于观察控制每个微服务，我们给 k8s 集群中接入了 istio 服务网格，因为 istio 可以记录并暴露出来微服务之间的调用指标，所以我们通过这些指标也计算出每个微服务的可用性，从而计算出 GRPC SLA。

展望：

作者简介

赵勇超  技术部 cloud-infra 团队 后端工程师