多集群thanos sidecar+MinIO监控告警实践
环境简介
项目环境
为保障业务高可用，业务使用了多个网络运营商的机房线路，每个机房均部署一套k8s环境，故而有多个k8s集群，每个k8s集群环境上运行的服务基本一致。原来监控体系存在以下问题：
配置管理混乱 先前使用Prometheus-operator部署管理监控告警，但是每个集群存在个别差异，导致每次调整告警时需要逐个修改集群配置，创建ServiceMonitor对象，才能完成Prometheus监控项添加。操作较为繁琐，没有统一管理。
无法统一查询 每个集群部署一套Prometheus，当需要查询数据时，只能在特定集群的Prometheus上查询数据。或者在grafana创建多个Prometheus的数据源，通过使用不同的数据源查询数据，缺少所有Prometheus数据统一查询的入口功能。
历史数据存储 先前Prometheus的历史监控数据，只能通过挂载pv方式持久化，每天监控数据量较大，存储策略只能设置为保留1个月。
运行环境
除了snmp exporter和ipmi exporter物理机部署外，其余组件均部署在k8s集群上。
每个集群均部署sidecar、query、store gateway、compact、rule组件，其中一个集群部署了Alertmanager、全局thanos-query、minIO组件。
组件版本
| 组件 | 版本 |
|---|---|
| k8s | 1.19.X |
| Alertmanager | 0.24.0 |
| thanos | 0.26.0 |
| prometheus | 2.36.0 |
| node exporter | 1.3.1 |
| blackbox exporter | 0.21.0 |
| elasticsearch exporter | 1.3.0 |
| kafka exporter | 1.4.2 |
| process exporter | 0.7.10 |
| ipmi exporter | 1.5.1 |
| snmp exporter | 0.20.0 |
整体架构
实现目标
配置文件统一
所有集群使用同一个告警和规则配置，当需要修改规则时，使用ansible paly统一推送并reload服务即可。
全局统一查询
grafana只需要配置一个Prometheus数据源，不同集群通过label标签区分。使用thanos-query全局查询所有Prometheus监控数据。
历史数据长期保留
监控数据留存三个月以上，用于同比分析对比监控指标。
方案选型
Thanos还是VictoriaMetrics
在VictoriaMetrics官方文档列出了与thanos的区别[1]，也可参考米开朗基杨的文章[2]。总结来说，
写入方式 VictoriaMetrics只能通过标准的 remote_write API 接收来自 Prometheus 实例写入的数据然后持久化存储，而thanos既可以使用sidecar将数据上传对象存储，也支持receiver模式远程写入。
全局查询 VictoriaMetrics内置全局查询视图，Prometheus将数据写入远程存储后就可以使用全局查询，而thanos需要依赖store gateway、sidecar、query组件才能实现查询。
部署难度 thanos部署难度比VictoriaMetrics更高，使用组件也更多。
存储方式 thanos使用对象存储，VictoriaMetrics使用块存储存储。
使用习惯 thanos基于Prometheus开发，web界面风格和操作逻辑与Prometheus基本相同，更容易上手使用。
由于当初做技术选型时，thanos是较为主流的解决方案，社区活跃，文档更丰富，所以选择了thanos。但是目前VictoriaMetrics发展势头也不容小觑，也可以作为技术方案备选。例如开源的夜莺监控告警平台，就使用VictoriaMetrics作为解决方案。
thanos部署方式
Prometheus-operator 集群中安装了 prometheus-operator 后，就可以通过创建 CRD 对象来部署 Thanos，但是部署和使用多了一层封装，屏蔽了许多底层细节，不利于后期更改。
helm charts helm仓库有多个版本，都可以实现一键部署，但需要修改大量变量。
kube-thanos Thanos 官方的开源项目，包含部署 thanos 到 kubernetes 的 yaml 示例，资源文件较多，具有较高的使用门槛。
此处选择kube-thanos方式直接配置yaml文件部署，因为直接使用 kubernetes 的 yaml 资源文件部署更直观，也更容易做自定义配置，当我们对 thanos 理解透彻后，可以灵活根据实际场景做架构和配置的调整。
对象存储选择
thanos支持的存储如下表
| Provider | Maturity | Aimed For | Auto-tested on CI | Maintainers |
|---|---|---|---|---|
| Google Cloud Storage | Stable | Production Usage | yes | @bwplotka |
| AWS/S3 (and all S3-compatible storages e.g disk-based Minio ) | Stable | Production Usage | yes | @bwplotka |
| Azure Storage Account | Stable | Production Usage | no | @vglafirov |
| OpenStack Swift | Beta (working PoC) | Production Usage | yes | @FUSAKLA |
| Tencent COS | Beta | Production Usage | no | @jojohappy,@hanjm |
| AliYun OSS | Beta | Production Usage | no | @shaulboozhiao,@wujinhu |
| Local Filesystem | Stable | Testing and Demo only | yes | @bwplotka |
如果是公有云服务，那就无脑选择腾讯或阿里的对象存储即可，毕竟数据无价。存储里的水很深，一般人把持不住。难的不是部署搭建，而是服务异常如何解决问题，如何恢复数据，所有如果项目在公有云的话，直接花钱买服务就行。
如果是自建IDC机房，私有云使用，可以使用的对象存储有MinIO和ceph的RGW可供选择。这里的建议是如果有专门的存储负责人维护ceph存储，那就首选ceph。如果是自己维护使用，对存储不太熟悉，那就选minIO，相较ceph，minIO的使用门槛更低。
sidecar模式还是receiver模式
在先前的版本，receive一直是beat模式，近期的版本才稳定下来，可以在生产环境使用。使用sidecar还是receive模式，主要就看你的query组件和Prometheus离得远不远。
Sidecar和Receiver功能相似，都是获取prometheus的数据给thanos。区别在于近期数据的查询，sidecar采用边车模式读取prometheus数据，默认最近2H的数据都在Prometheus里面，而receiver相当于存储服务，prometheus的进群数据都随时写入到了Receiver中。
如果你的 Query 跟 Sidecar 离的比较远，比如 Sidecar 分布在多个数据中心，Query 向所有 Sidecar 查数据，速度会很慢，这种情况可以考虑用 Receiver，将数据集中吐到 Receiver，然后 Receiver 与 Query 部署在一起，Query 直接向 Receiver 查最新数据，提升查询性能。
我们刚开始也是用receiver模式，但是发现随着集群和节点的增加，数据量激增，整个thanos架构的压力全在receiver节点上，非常消耗资源，重启一个receiver pod需要30分钟以上，最后换回sidecar模式，都是国内节点，虽然跨机房和地域，但是查询延迟并不是很大。
rule组件告警还是prometheus告警
直接使用 Prometheus 自带的 rule 功能 (生成新指标+告警)，当生成告警后直接推送至alertmanager，这种方式资源消耗最小，而且中间的数据链路较少，不会因为thanos某一组件异常导致告警失败的情况发生，但是如果每个集群部署多套Prometheus的话，需要在alertmanager做重复告警抑制。
使用thanos-rule的话，他去定期查询thanos-query的接口数据，计算是否生成告警，并推送给alertmanager。除此之外还可以根据规则配置计算新指标并存储，同时，还可以将数据上传到对象存储以供长期保存。由于rule组件实现了多Prometheus副本重复告警的屏蔽，所以就不需要在alertmanager做告警抑制了。
经验分享
关于minio
thanos只会对历史数据压缩降低采样率，并不会删除指定天数前数据，需要在minio设置bucket数据保留天数。
跨集群配置minio的endpoint地址时注意，最好将minio写入地址使用vip做成高可用，minio的写入接口属于四层协议，而非七层。
minio的部署本文和yaml文件不做涉及，大家可参考官网文档（一定要看英文，中文版本有误差）自行部署即可。
关于thanos-compact
当thanos使用了对象存储后，我们就可以查询较大时间范围的监控数据，但是当时间范围很大时，查询的数据量也会很大，这会导致查询速度非常慢。通常在查看较大时间范围的监控数据时，我们并不需要那么详细的数据，只需要看到大致就行。Thanos Compact 这个组件应运而生，它读取对象存储的数据，对其进行压缩以及降采样再上传到对象存储，这样在查询大时间范围数据时就可以只读取压缩和降采样后的数据，极大地减少了查询的数据量，从而加速查询。compact配置时主要关注如下几个参数
- --retention.resolution-raw=7d # 指定原始数据存放时长
- --retention.resolution-5m=15d # 指定降采样到数据点 5 分钟间隔的数据存放时长
- --retention.resolution-1h=30d # 指定降采样到数据点 1 小时间隔的数据存放时长
它们的数据精细程度递减，占用的存储空间也是递减，在生产环境配置时，这三个参数与minio的bucket保留天数一起决定了每个bucket数据占用空间。如果bucket占用空间较大，可尝试调整compact的参数
关于多集群标签区分
当使用远程存储或集群联邦时，可以通过external_labels标签区分不同的prometheus实例，所有指标都会带这个额外标签。在每个集群部署一套prometheus集群时，通过添加额外的cluster标签来区分这个指标属于哪个集群。
external_labels:
cluster: $(CLUSTER)
prometheus_replica: $(CLUSTER)-$(POD_NAME)
- 使用thanos-query查询时，效果如下所示：
- 使用grafana时，记得添加cluster这个变量
关于grafana告警
虽然grafana告警配置方便，显示更加直观，但出现过由于MySQL服务异常，从而grafana异常，最终导致grafana配置的告警没有正常触发的情况。
目前我们的告警配置策略是重要基础告警和不需要经常调整阈值的告警（例如服务是否正常运行，节点是否宕机），交由Prometheus配置管理。
业务相关告警，阈值经常变化，或者需要经常查看指标变化的历史情况，直观反映业务性能指标的告警（网络延迟，es活跃分片数等）以及es日志分析告警（例如日志500错误数量，超时时间等），交由grafana配置管理，因为告警值经常变化，配置修改较为方便。
需要注意的是grafana的告警没有额外标签这个配置项，所以当配置grafana告警时，可以通过指定tag的方式，手动添加cluster标签。
关于告警配置管理
在编写告警规则时，记得告警规则通过{{$labels.cluster}}获取每个告警所属集群，生成的告警内容如下所示：
告警配置管理目前的整体思路是所有prometheus和grafana的告警都接入alertmanager，然后通过webhook推送至事件平台创建工单，根据告警组和等级调用不同的告警媒介。所有告警通过alertmanager做统一的告警分组，抑制和静默操作。但是alertmanager缺乏一个历史告警的记录功能，于是我们使用webhook功能，当有告警产生，推送到事件平台的过程中，通过webhook程序记录告警详细信息并存入数据库。通过grafana作图显示当前和历史告警信息表格。
后期规划开发告警事件处理平台，功能模块如下所示：
关于全局查询
每个集群一套thanos组件，集群内部的query通过 dns srv 做服务发现。查询多个集群的数据时，单独再部署一个全局的thanos-query，然后将各个集群的query组件grpc端口通过NodePort暴露出来，这个全局query的 store api 地址就写各集群的 query 的grpc暴露的NodePort地址。
- name: thanos-query-global
args:
- query
- --log.level=debug
- --query.auto-downsampling
- --grpc-address=0.0.0.0:10901
- --http-address=0.0.0.0:9090
- --query.partial-response
- --query.replica-label=prometheus_replica
- --store=192.168.10.30:30030
- --store=192.168.10.31:30030
- --store=192.168.10.32:30030
- --store=192.168.20.30:30030
- --store=192.168.20.31:30030
- --store=192.168.20.32:30030
配置好全局thanos-query后，不仅可以查看所有的监控指标，还可以查看所有prometheus的alerts、targets、rules信息
关于黑盒监测
如果网络探测资源较少，可手动指定静态targets ，当资源较多时，推荐基于Consul实现Prometheus的自动发现功能配置。监控所有tcp ipmi ssl资源的监控，可参考开源项目https://github.com/starsliao/ConsulManager
关于网络监控
网络监控主要snmp trap（异常事件）、syslog（全部日志）、ping（IP+端口网络存活监控）、snmp get（流量采集、cup、内存）、net flow流量采集分析五个方面。除了net flow通过网管工具查看分析外，其余均建议监控。
- ping监测使用blackbox exporter定期抓取指标即可。
- snmp get信息通过snmp export配置交换机地址，监控项即可获取到。
- 网络设备的syslog日志统一发送到rsyslog服务器，如果有es集群的话，使用logstash读取rsyslog日志，然后写入es集群，最后使用grafana作图，展示日志关键字段信息；或者自己开发exporter，通过正则匹配过滤的方式，当日志中存在关键字信息时，输出一个异常问题的指标，由Prometheus抓取，并判断是否触发告警。
- snmp exporter官方暂时没有计划支持snmp trap，需要mib库翻译，可以借助较为成熟的zabbix插件翻译的生成日志。思路如下：
- 部署snmptrap服务器，配置网络设备将trap信息发送到这台服务器上；
- 在snmp trap服务器上安装snmptrapd和snmptt工具，snmptrapd负责接受snmptrap信息，snmptt负责翻译snmp并写入到日志文件，然后将日志文件发送到rsyslog服务器中；
- 由logstash读取rsyslog日志并存入es，最终由grafana作图配置告警。
yaml资源清单文件
github
https://github.com/cuiliang0302/thanos-install
gitee
https://gitee.com/cuiliang0302/thanos-install
注意事项
由于资源清单中存在敏感信息，已进行脱敏替换，因此yaml资源清单并不能直接apply创建，参考readme.md文件，按实际情况进行修改后创建。
参考文档
VictoriaMetrics官方文档，与thanos区别：https://docs.victoriametrics.com/FAQ.html?highlight=thanos#what-is-the-difference-between-victoriametrics-and-thanos
thanos与VictoriaMetrics对比：https://icloudnative.io/posts/comparing-thanos-to-victoriametrics-cluster/
thanos支持的存储类型：https://thanos.io/v0.27/thanos/storage.md/
滴滴夜莺使用VictoriaMetrics长期存储：https://n9e.github.io/docs/install/victoria/
Zabbix监控设备SNMP Trap消息：https://cloud.tencent.com/developer/article/1784442
Prometheus snmp exporter：https://xie.infoq.cn/article/b7cf024fc516e3326d2c8531b
prometheus告警规则模板：https://awesome-prometheus-alerts.grep.to/
查看更多
微信公众号
微信公众号同步更新，欢迎关注微信公众号第一时间获取最近文章。
博客网站
崔亮的博客-专注devops自动化运维，传播优秀it运维技术文章。更多原创运维开发相关文章，欢迎访问https://www.cuiliangblog.cn