关于容器:基于-Prometheus-的边缘计算监控实践

监控作为边缘计算基础设施的重要组成部分，是边缘稳定性的基本保障。本文次要介绍火山引擎边缘计算的监控实际，分享火山引擎如何进行监控技术选型以及构建监控服务体系。次要内容如下：

1. 边缘计算监控初衷
2. 基于 Prometheus 的监控零碎
3. 落地实际
4. 总结

01 边缘计算监控初衷

监控作为边缘计算基础设施的重要组成部分，是边缘稳定性的基本保障。在面对低时延、高带宽、异构汇聚等特点的边缘环境时，如何更加清晰的展现出边缘集群的运行状态，应答边缘环境复杂多变的线上挑战？为此，火山引擎边缘计算须要构建一套欠缺的边缘计算监控和服务体系。

02 基于 Prometheus 的监控零碎

火山引擎边缘计算采纳了云原生架构，而 Prometheus 作为云原生时代的指标监控利器，有其先天的劣势。相较于其余监控计划，Prometheus 具备以下长处：

1. 原生反对 Kubernetes（以下简称 K8s）监控，具备 K8s 对象服务发现能力，而且外围组件提供了 Prometheus 的采集接口；
2. 基于 HTTP 的 pull 形式采集时序数据，能够满足边缘多集群的监控需要；
3. 无依赖存储，反对 local 和 remote 存储模式；
4. 提供有数据查询语言 PromQL，用户能够间接通过 PromQL 从 Prometheus 里查问到须要的聚合数据。
5. 反对多种多样的图表和界面展现，比方 Grafana 等。

基于 Prometheus 的监控零碎的架构如图所示，这里具体分享一下数据源和 Prometheus Server 两局部。

​

数据源

在监控零碎中，数据源局部蕴含：

• node-exporter：采集物理节点指标；

<!—->

• kube-state-metrics：采集 k8s 相干指标，包含资源应用状况，以及各种对象的状态信息；

<!—->

• cadvisor：采集容器相干指标；

<!—->

• apiserver, etcd, scheduler, k8s-lvm，gpu 等外围组件的监控数据；

<!—->

• 其余自定义 metrics，通过在 pod yaml 文件 annotations 增加 prometheus.io/scrape: “true” 可实现主动抓取提供的 metrics；

Prometheus Server

Prometheus Server 是 Prometheus 最外围的模块。它次要蕴含抓取、存储和查问这 3 个性能：

• 抓取 ：Prometheus Server 通过服务发现组件，周期性地从 Exporter 中通过 HTTP 轮询的模式拉取监控指标数据。

<!—->

• 存储 ：抓取到的监控数据通过肯定的规定清理和数据整顿（抓取前应用服务发现提供的 relabel_configs 办法，抓取后应用作业内的 metrics_relabel_configs 办法），把失去的后果存储到新的工夫序列中进行长久化。

<!—->

• 查问 ：Prometheus 长久化数据当前，客户端就能够通过 PromQL 语句对数据进行查问了。

03 落地实际

整体监控架构

边缘计算基于 Prometheus、M3DB、自研 Metrix 等构建起一套监控架构，架构图如下：

​

整个边缘计算监控架构次要由数据采集、Prometheus、M3DB、Grafana、Metrix 几个外围模块形成。

• 数据采集

  • Prometheus 对接组件监控信息通常应用 exporter。exporter 不会被动推送监控数据到 server 端，而是期待 server 端定时来收集数据，即所谓的被动监控。边缘计算应用的 exporter 蕴含：node_exporter、xlb_exporter、kubevirt-exporter 等。
  • 而后通过 Endpoints 对象定义须要监控的设施 IP 及端口，Prometheus Pod 依据 ServiceMonitor 配置向散布在各设施上的 exporter 拉取 metrics 数据；

<!—->

• Prometheus

  • Prometheus Pod 将采集上来的数据依据 record-rules 进行 relabel、预聚合等操作，而后将所有数据打上 externalLabels(例如 cluster: bdcdn-bccu)remote write 写入远端的 M3DB；

<!—->

• M3DB

  • M3DB 是分布式时序数据库，实现了 Pometheus 的 remote_read 和 remote_write 接口，同时反对 PromQL 等查询语言。咱们应用了 M3DB 作为保留边缘计算相干的监控数据，用于对接报警及展现。

<!—->

• Metrix 和 Grafana

  • 通过 PromQL 语句向 M3DB 查问数据，对接报警零碎 Metrix 和视图展现。

监控组件

通过以 Prometheus 为主的若干组件实现 K8s 全组件监控及业务监控，组件列表如下：

存储后端

存储后端次要是 M3DB。M3DB 是原生的分布式时序数据库，提供高度灵便和性能的聚合服务、查问引擎等。M3DB 可能通过提供不同的组件进行拆散，让分布式时序数据库进行很好的扩大。

• 分布式数序数据存储 （M3DB）：提供可程度扩大的时序数据存储和反向索引；

<!—->

• 一个 Sidecar 程序 （M3Coordinator）：能够使 M3DB 作为 Prometheus 的近程存储应用；

<!—->

• 分布式查问引擎 （M3Query）：反对 PromQL，Graphit 和 自研的 M3Query 语法；

<!—->

• 聚合服务 （M3Aggregator）：对数据进行聚合和降级，以实现对不同指标执行不同存储策略。

​

监控指标

K8s 的资源指标分类：

• 资源指标 ：metrics-server 内建 API；

<!—->

• 自定义指标 ：通过 Prometheus 来采集，须要组件 k8s-prometheus-adapter；

​

（1）metrics-server：API server

kubectl api-versions 中默认不蕴含 metrics.k8s.io/v1beta1；

应用时须要增加 kube-aggregator 前缀；

能够应用 kubectl top nodes 来获取信息。

（2）自定义指标

如 node_exporter 用来裸露 node 信息，当然还有其余的 exporter；

PromQL 查问语句，不能间接被 K8s 间接解析，须要通过 kube-state-metrics 组件转 k8s-promethues-adpater 转为 Custom Metrics API；

（3）HPA — 基于资源值指标的伸缩

指定 Deployment、ReplicaSet 或 ReplicationController，并创立曾经定义好资源的主动伸缩器。应用主动伸缩器能够依据须要主动减少或缩小零碎中部署的 pod 数量。

• Metrics Server：集群级别的外围资源应用聚合器，通过各个节点的 /stats/summary 接口提供的数据来收集节点和 Pod 的 CPU 和内存应用状况。Summary API 是一种内存高效的 API，用于将数据从 kubelet/cAdvisor 传递到 Metrics Server。
• API Server：聚合 Metrics Server 提供的外围资源指标，通过 http://metrics.k8s.io/v1beta1 API 提供给 HPA 做主动扩缩。

​

同时，咱们采纳 Grafana 将采集的数据进行查问和可视化。通过对系统拆解，别离在物理机、网络、K8s、存储等层级做了监控汇聚及展现。以上是整个边缘计算监控服务体系的次要模块。

04 总结

回顾一下本文介绍的次要内容：

• 首先，介绍了边缘计算场景下的监控，包含边缘计算监控场景面临的挑战及监控的重要性；

<!—->

• 而后，介绍了如何实现边缘计算的监控，基于 Prometheus 的监控零碎；

<!—->

• 最初，介绍了边缘计算监控的落地实际场景，包含监控架构及监控组件、存储后端、监控指标等；

基于 Prometheus 构建的监控零碎，不仅满足了多样化业务对监控的需要，还晋升了火山引擎边缘计算对边缘集群的管控、运维能力。而 Prometheus 作为新生代的开源监控零碎，已成为云原生体系的事实标准，也证实了其设计很受欢迎。