使用VictoriaMetrics监控大规模Kubernetes集群

iyacontrol

目前大多数关于Kubernetes集群监控的文章主要介绍如何使用Prometheus在Kubernetes集群上设置监控和报警系统,以及如何使用Grafana在其上建立出色的可视化系统。这本身就是一个很棒的系统,但是确实有一些问题,例如:

  • 如果Prometheus异常怎么办?如果那是在关键阶段发生的呢?现在,可以通过部署多个Prometheus实例来解决此问题,但是仍然需要全局视图
  • 如果您需要分析旧的监控数据怎么办? Prometheus默认情况下仅将数据保留15天。因此,需要维护用于保持历史数据的数据库和查询系统。
  • 如果您的架构可扩展到数百个集群/环境,该怎么办?在这种情况下,将有多个Prometheus部署,并且同样需要全局视图。

在扩展和创建高度可用的监控系统方面,存在很多问题。通过VictoriaMetrics解决所有问题。
可以将其无缝添加到现有Prometheus部署之上。而且,它提供了与Prometheus非常相似的仪表板,因此学习曲线很平。

本文主要介绍如何使用victoriametrics监控大规模Kubernetes 集群,并提供高可用,可扩展,全局视图等优势。

整体架构

下图是整体架构图,主要包括4大块:

  • 采集
  • 存储
  • 查询
  • 报警

整体架构图,可以让大家一目了然我们如何使用victoriametrics扩展Prometheus功能,从而完成对大规模集群的监控。

下面我们将对这4块一一解读。

采集

Prometheus正在迅速成为Docker和Kubernetes监控工具之一。本节介绍包括Prometheus server,kube-state-metrics,各种用到的exporter,以及监控目标自动发现。

  • 1 – Prometheus server 需要尽可能多的服务发现.
  • 有几种方法可以实现此目的::
  • Consul
  • Prometheus Kubernetes SD 插件
  • Prometheus operator 和Custom Resource Definitions
  • 2 – 除了应用程序指标,我们还希望Prometheus收集与Kubernetes服务,节点和业务流程状态相关的指标。
  • Node exporter, 收集与主机相关的经典指标:cpu,mem,网络等
  • Kube-state-metrics 收集架构和集群维度的指标: deployments, pod 指标, resource reservation等
  • 来自内部组件的Kube-system指标: kubelet, etcd, dns, scheduler等等

关于该部分组件的安装和Promethues的配置相关,我们不做详细介绍。

更加云原生的话,可以使用prometheus-operator。Prometheus Operator能够帮助用户自动化的创建以及管理Prometheus Server以及其相应的配置。

当你的单个集群非常大的时候,我们可以考虑使用Prometheus relabel 中 hashmod 功能,实现采集对象的分片。

不过必须为Prometheus配置remote_write才能将数据发送到VictoriaMetrics。将以下行添加到Prometheus配置文件(通常位于/etc/prometheus/prometheus.yml中):

remote_write:
  - url: http://<victoriametrics-addr>:8428/api/v1/write

Prometheus将传入的数据写入本地存储,并将其并行复制到远程存储。这意味着即使--storage.tsdb.retention.time持续时间内,数据在本地存储中仍然可用,即使远程存储不可用。

因为我们的VictoriaMetrics集群将服务多个Kubernetes集群的metrics,所以将以下行添加到Prometheus config的global部分中:

global:
  external_labels:
    datacenter: k8s-cluster-01

存储

VictoriaMetrics是快速,经济高效且可扩展的时间序列数据库。可处理来自Kubernetes,IoT传感器,联网汽车,工业遥测,财务数据和各种企业工作负载的大量时间序列数据。可用作Prometheus的长期远程存储。

VictoriaMetrics 包括了如下的组件:

  • vmstorage-- 存储数据。
  • vminsert-- 通过remote_write API接收来自Prometheus的数据并将其分布在可用的vmstorage节点上。
  • vmselect-- 通过从vmstorage节点获取并合并所需数据,通过Prometheus查询API执行传入查询。

每个组件可以使用最合适的硬件配置独立扩展到多个节点。

整体架构图如下:

VictoriaMetrics 作为Prometheus的长期持久存储,具备伸缩性和高可用的特点。此外,相对比influxdb,承载同样的metrics,只使用不到1/10的内存。

查询

VictoriaMetrics 支持Prometheus查询API,因此可以在Grafana中用作Prometheus的替代产品。

使用以下网址在Grafana中创建Prometheus数据源:

http://<victoriametrics-addr>:8428

用VictoriaMetrics的主机名或IP地址替换<victoriametrics-addr>。

报警

出于性能的考虑,VictoriaMetrics 并没有支持Prometheus 远程读api。但是提供了VM Alert组件。vmalert执行给定MetricsQL表达式(规则)的列表,并将警报发送到Alert Manager。

该组件具备以下特点:

  • 与VictoriaMetrics TSDB集成;
  • VictoriaMetrics MetricsQL表达式验证;
  • Prometheus警报规则定义格式支持;
  • 与Alertmanager集成;
  • 轻巧,没有额外的依赖关系。

要开始使用vmalert,需要满足以下条件:

  • 警报规则列表-要执行的PromQL / MetricsQL表达式;
  • 数据源地址-可访问的VictoriaMetrics实例,用于规则执行;
  • 通知程序地址-可到达的Alertmanager实例,用于处理,汇总警报和发送通知。

然后相应地配置vmalert:

./bin/vmalert -rule=alert.rules \
        -datasource.url=http://localhost:8428 \
        -notifier.url=http://localhost:9093

示例的rules文件如下:

groups:
  - name: groupGorSingleAlert
    rules:
      - alert: VMRows
        for: 10s
        expr: vm_rows > 0
        labels:
          label: bar
          host: "{{ $labels.instance }}"
        annotations:
          summary: "{{ $value|humanize }}"
          description: "{{$labels}}"

  - name: TestGroup
    rules:
      - alert: Conns
        expr: sum(vm_tcplistener_conns) by(instance) > 1
        annotations:
          summary: "Too high connection number for {{$labels.instance}}"
          description: "It is {{ $value }} connections for {{$labels.instance}}"
      - alert: ExampleAlertAlwaysFiring
        expr: sum by(job)
          (up == 1)

vmalert在单独的goroutine中为每个组运行评估。组中的规则按顺序一对一评估。

结论

本文介绍了如何利用VictoriaMetrics作为Prometheus的长期存储,来实现大规模k8s集群的监控。满足高可用,易扩展等特性。基本上涵盖了数据的采集,指标存储,查询,和报警主要方面。

阅读 4k

kubernetes solutions
专注k8s,serverless,service mesh,devops

专注kubernetes,devops,aiops,service mesh。

1.4k 声望
2.7k 粉丝
0 条评论

专注kubernetes,devops,aiops,service mesh。

1.4k 声望
2.7k 粉丝
文章目录
宣传栏