简单的集群监控方案

背景

对于一个 saas 应用来说，面向的是广大用户，广大用户可能在任意一个时间点访问服务，因此，服务的高可用就变得非常重要了，用指标衡量的话，也就是 SLA (Service Level Agreement 服务等级保障)。

SLA 由两部分组成：指标定义 + 目标 (SLI + SLO)(indicator + objective) 。具体的指标和目标根据不同的服务而定。对于一个系统的可用性，一般有一个很直观的指标：1 - 当年宕机时长/当前总时长，大家平常说的服务可用性为 2 个 9、3 个 9、4 个 9 基本值的都是这个。

指标，也就是这套体系中的基石了，指标的采集、指标是否健康的判断、异常之后的告警组成了监控体系。

常用的指标体系

“服务可观测性” 方面，我们一般有 3 个方向： log、metrics、tracing。指标也一样，绝大多数指标都是从这三个方向中得出来的。

本文中我们暂不讨论 metrics 的细节，也不讨论 log 和 tracing 系统，一些 log 系统的信息可以参考简单的集群日志采集方案，tracing 体系之后再聊吧。本文着重于实践搭建一套简单实用的集群监控体系。

经典的 metrics 体系是 prometheus + grafana，这也是大多数互联网同学熟悉的体系。 prometheus 作为一个 metrics 数据采集器 + tsdb 存储引擎 + promql 查询语句，能很好地满足 metrics 使用的需求。之前在 prometheus代码走读也对 prometheus 做了一些代码层的研读。

实际上 metrics 存储和查询体系，从技术实现来看并不是特别难。我觉得 prometheus 最大的成功在于生态。其一，它有比较完整的 client SDK，各语言都能很方便地集成；其二，它有齐全的工具链，采集、存储、查询、面板；其三，它很好地实现了对 k8s 、service mesh 等的集成，云原生领域占了先机。

另外一些常用的监控系统有: zabbix、open-falcon、Nagios、datadog 等。各有一些优劣，空了的话可以再进一步了解下。

prometheus 竞品中有一个比较有意思的身影: ELK，对，就是那个大名鼎鼎的日志系统。他们的方案是 metricsbeat + elasticsearch + kibana 。

官方也有和一些竞品的对比：官方对比文档

我们就选用 prometheus + grafana 的方案进行后续的实操了。

监控项

一般而言，我们的架构体系中都会把软件系统分为这么几层：

基础设施层 (机器、虚拟机、网络、磁盘、集群等)
基础服务层 (数据库、缓存、队列、配置中心、注册/调度中心、网关等)
应用层 (业务应用)

当然，从更广泛的视角看，业务本身可以作为一层，主要关注业务指标相关的东西，例如注册量、转化率、用户路径等等。这类指标被直接成为 业务指标 ，一般不融入到技术的监控中来，主要采用的方案是 埋点上报 + BI 平台，这方面的内容也非常丰富，只有可以专门梳理一下。

prometheus 的生态非常好，除了非常具体的业务监控外，其他几乎都有对应的开源监控项。

基础设施：
- node: https://github.com/prometheus/node_exporter
- process: https://github.com/ncabatoff/process-exporter
- network: https://github.com/syepes/network_exporter
k8s 集群：
- https://github.com/kubernetes/kube-state-metrics
- https://github.com/google/cadvisor
基础服务：
- es: https://github.com/prometheus-community/elasticsearch_exporter
- pg: https://github.com/prometheus-community/postgres_exporter
- java: https://github.com/prometheus/jmx_exporter
- redis: https://github.com/oliver006/
- nginx: https://github.com/nginxinc/nginx-prometheus-exporter
- mongodb: https://github.com/percona/mongodb_exporter
- gitlab-ci: https://github.com/mvisonneau/gitlab-ci-pipelines-exporter
- haproxy: https://github.com/prometheus/haproxy_exporter
- kafka-lag: https://github.com/seglo/kafka-lag-exporter
- kafka: https://github.com/redpanda-data/kminion
- kafka: https://github.com/danielqsj/kafka_exporter
- ssl: https://github.com/ribbybibby/ssl_exporter
- gin: https://github.com/zsais/go-gin-prometheus
- ping: https://github.com/czerwonk/ping_exporter
- nats: https://github.com/nats-io/prometheus-nats-exporter
- influxdb: https://github.com/prometheus/influxdb_exporter
- rocketmq: https://github.com/apache/rocketmq-exporter
- airflow: https://github.com/epoch8/airflow-exporter
- pagespeed: https://github.com/foomo/pagespeed_exporter
- ov: https://github.com/kumina/openvpn_exporter
- logstash: https://github.com/BonnierNews/logstash_exporter
- zk: https://github.com/dabealu/zookeeper-exporter

上面这些只是自己扒的 github 得到的，其实官方文档已经维护了一份更全的了： https://prometheus.io/docs/instrumenting/exporters/

业务指标
- 框架指标
  - http 请求状态指标
  - ws 事件请求量、消息大小 histgram
- 中间件使用指标
  - kafka 消息情况 (可看 sarama metrics 指标)
  - 数据库的连接情况、请求耗时等
- 业务特性的指标
  - eg: 登录失败人数

实践

二进制部署

在机器上搭建 prometheus 很简单，直接一个二进制就起来了。

二进制的下载可以从这里找
配置可以参考官方文档
- 最简单的只用配 global 和 scrape_config 即可
- 如果要做告警，则要配置 rules 和 alertManager，告警的消息需要用模板来实现
- 如果要和 k8s 集成 service discovery，需要为 prometheus 创建 role 和 rolebinding (ns、svc、ep、pod、node、ing 等的 list、watch)