VictoriaMetrics--k8s多集群监控探索实践

原创田杰好未来技术

Ⅰ.引言

A. VictoriaMetrics简介

VictoriaMetrics 是一种快速、经济高效且可扩展的监控解决方案和时间序列数据库,它可以作为prometheus的长期存储，可以直接用于 Grafana 作为数据源使用，相比prometheus相同集群规模所需cpu、内存以及存储空间更少，比较符合我们k8s多集群的统一监控告警需求，接下来就介绍下VictoriaMetrics详细部署实施过程，VictoriaMetrics下文中简称vm。

Ⅱ.VictoriaMetrics架构概述

以下是官网架构图，可以看到vmselect、vmstorage、vminsert每个组件都具备横向扩展能力,提高了集群可用性。例如在查询速率上来后，适当扩展vmselect副本满足需求。最小集群必须包含vmselect、vmstorage、vminsert三个组件，其中有状态服务只有vmstorage，其余都是无状态服务。

主要组件

1.vmselect: 数据查询，汇总和数据去重

2.vmstorage: 负责存储原始数据并返回请求数据

3.vminsert：负责数据写入到vmstorage节点中

4.vmalert: 报警插件

Ⅲ.VictoriaMetrics部署和配置

环境准备

1.集群可用性规划

结合tck3集群情况来说，集群时间序列数量2300万个，选择集群版安装，保证服务可用性核心组件vmselect、vmstorage、vminsert至少2个副本，并通过pod反亲和属性打散到不同节点，增加服务可用性。

2.资源规划

需要准备2个6C12G的主机规格，本次经过测试下来一天12台机器占用4G，同规模集群保留30天至少准备120G磁盘大小，存储根据实际情况规划即可。

B.VictoriaMetrics集群安装

选用最方面管理的helm部署VictoriaMetrics集群，IDC集群k8s主流版本为1.20，通过测试victoria-metrics-cluster选用0.10.5版本，之后的版本需要k8s至少1.23以上版本。

#安装源helm repo add vm https://victoriametrics.github.io/helm-charts/#更新源查找最新版本helm repo updatehelm  search repo  vm/victoria-metrics-cluster  -l#这里简单设置了节点亲和属性、存储时间、以及数据存储类类型helm  install vmcluster /root/.cache/helm/repository/victoria-metrics-cluster-0.10.5.tgz  --version 0.10.5  -n vm --set vmstorage.nodeSelector."directpv\/disk-type"=ssd-960 --set vmstorage.retentionPeriod=10d --set vmstorage.persistentVolume.storageClass=directpv-ssd-960

部署完可以对照下图的服务pod查看启动情况，可以看到有状态服务vmstorage两个副本都处于Running状态，其无状态类型的vminsert和vmselect也都正常启动。

Ⅳ.数据收集和管理

接入多个数据源，并通过标签区分不同k8s集群的指标

将多个集群的监控数据写入到统一的vm中，目前复用prometheus的采集器能力，通过prometheus复写到vm中，列举两种修改集群prometheus中remoteWrite和externalLabels的配置,这样prometheus数据就能写入到vm中。

1.集群内写入，可通过service访问

kubectl edit prometheus

 externalLabels:    cluster: iaas-test  remoteWrite:  - url: http://vmcluster-victoria-metrics-cluster-vminsert.vm.svc.cluster.local:8480/insert/0/prometheus/

2.集群外写入，通过nodeport或者暴露的域名访问

externalLabels:    cluster: 151-test  remoteWrite:  - url: http://       .xx:30113/insert/0/prometheus/

存储数据持久化

查看集群中可用的存储类,本次通过directpv提供本地盘的存储，在部署阶段通过–set vmstorage.persistentVolume.storageClass指定存储类即可,从下图可看到创建出来的磁盘提供存储

Ⅴ.监控和告警

经过上面步骤正常两个集群的监控指标已经收集到vm中了，接下来就是数据展示以及告警规则配置。

构建监控仪表盘

grafana中配置数据源,如下图所示

添加好数据源后，在以前的仪表盘中添加data source中选中vmcluster这样就可以切换不同集群的监控仪表盘了

安装告警插件以及告警规则

helm install  vmalert vm/victoria-metrics-alert   --version 0.7.4 --set server.configMap="vmalert-alert-rules-config"  --set server.datasource.url="http://vmcluster-victoria-metrics-cluster-vmselect.vm.svc.cluster.local:8481/select/0/prometheus/"  --set  alertmanager.enabled=true  -n vm

通过configmap配置相关告警规则这里给出一个简单demo,检测k8s集群中ControllerManager组件存活数，相比之前告警规则需要增加cluster信息的筛选，这样修改一条报警规则就不用修改各自集群的规则，通过汇总在vm的指标即可管理多集群告警规则。

###vmalert-alert-rules-config.yamlapiVersion: v1data:  alert-rules.yaml: |    groups:    - name: iass-custom.rules      rules:      - alert: KubeControllerManagerMiss        annotations:          message: KubeControllerManager has disappeared from Prometheus target discovery.          runbook_url: https://github.com/kubernetes-monitoring/kubernetes-mixin/tree/master/runbook.md#alert-name-kubecontrollermanagerdown        expr: sum(up{job="kube-controller-manager"}) by (cluster) == 3        for: 1m        labels:          severity: criticalkind: ConfigMapmetadata:  annotations:    meta.helm.sh/release-name: vmalert    meta.helm.sh/release-namespace: vm  labels:    app: server    app.kubernetes.io/instance: vmalert    app.kubernetes.io/managed-by: Helm    app.kubernetes.io/name: victoria-metrics-alert    helm.sh/chart: victoria-metrics-alert-0.7.4  name: vmalert-alert-rules-config  namespace: vm

代码片段：可切换语言，无法单独设置文字格式

整合第三方告警服务

到目前已经可以定期执行告警规则，这里借助一个第三方开源插件webhook,匹配critical级别告警规则发送到知音楼消息群，详细配置流程参考附录链接项目，这里是alert对接alertmanager-webhook-dingtalk的关键配置，到这里从多集群的指标采集到存储到统一监控告警的链路打通。

apiVersion: v1data:  alertmanager.yaml: |2
    global:      resolve_timeout: 5m    inhibit_rules:    - equal:      - namespace      - alertname      source_matchers:      - severity = critical      target_matchers:      - severity =~ warning|info    - equal:      - namespace      - alertname      source_matchers:      - severity = warning      target_matchers:      - severity = info    - equal:      - namespace      source_matchers:      - alertname = InfoInhibitor      target_matchers:      - severity = info    receivers:      - name: "null"      - name: 'webhook'        webhook_configs:        - url: 'http://alertmanager-webhook-dingtalk.default:8060/dingtalk/webhook/send'    route:      group_by:      - namespace      group_interval: 5m      group_wait: 30s      receiver: "null"      repeat_interval: 10m      routes:      - matchers:        - alertname =~ "InfoInhibitor|Watchdog"        receiver: "null"      - matchers:        - severity = "critical"        receiver: "webhook"kind: ConfigMapmetadata:  annotations:    meta.helm.sh/release-name: vmalert    meta.helm.sh/release-namespace: vm  labels:    app: alertmanager    app.kubernetes.io/instance: vmalert    app.kubernetes.io/managed-by: Helm    app.kubernetes.io/name: victoria-metrics-alert    helm.sh/chart: victoria-metrics-alert-0.7.4  name: vmalert-alertmanager-alertmanager-config  namespace: vm

代码片段：可切换语言，无法单独设置文字格式

VI. 总结和未来展望

到这里基本就是完整的数据采集到写入到最后的看板展示、监控告警流程，综上所述可以看出它的架构特别适合云原生环境，可扩展性高，部署简便，通过prometheus的结合利用remote write功能将多个集群指标汇总到一个集中的VictoriaMetrics集群，这样简化数据的收集和管理，还有着数据压缩率高的优势,对于有长期的存储的需求也是个不错的选择，另外社区活跃度也高，相信在K8s多集群监控方面也会变得更加成熟和稳定。

也许你还想看

继续滑动看下一个