监控作为边缘计算基础设施的重要组成部分，是边缘稳定性的基本保障。本文次要介绍火山引擎边缘计算的监控实际，分享火山引擎如何进行监控技术选型以及构建监控服务体系。次要内容如下：
- 边缘计算监控初衷
- 基于 Prometheus 的监控零碎
- 落地实际
- 总结
01 边缘计算监控初衷
监控作为边缘计算基础设施的重要组成部分，是边缘稳定性的基本保障。在面对低时延、高带宽、异构汇聚等特点的边缘环境时，如何更加清晰的展现出边缘集群的运行状态，应答边缘环境复杂多变的线上挑战？为此，火山引擎边缘计算须要构建一套欠缺的边缘计算监控和服务体系。
02 基于 Prometheus 的监控零碎
火山引擎边缘计算采纳了云原生架构，而 Prometheus 作为云原生时代的指标监控利器，有其先天的劣势。相较于其余监控计划，Prometheus 具备以下长处：
- 原生反对 Kubernetes（以下简称 K8s）监控，具备 K8s 对象服务发现能力，而且外围组件提供了 Prometheus 的采集接口；
- 基于 HTTP 的 pull 形式采集时序数据，能够满足边缘多集群的监控需要；
- 无依赖存储，反对 local 和 remote 存储模式；
- 提供有数据查询语言 PromQL，用户能够间接通过 PromQL 从 Prometheus 里查问到须要的聚合数据。
- 反对多种多样的图表和界面展现，比方 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 全组件监控及业务监控，组件列表如下：
| 监控组件 | 性能点 |
|---|---|
| prometheus | 一套开源的监控 & 报警 & 工夫序列数据库的组合； |
| prometheus-adapter | 转换成 prometheus 的监控； |
| grafana | 一个开源的度量剖析与可视化套件； |
| cAdvisor | 机器上的资源及容器进行实时监控和性能数据采集，包含 CPU 应用状况、内存应用状况、网络吞吐量及文件系统应用状况。当初曾经集成到 kubelet 里了； |
| node-exporter | 收集 *NIX 零碎中硬件、零碎指标； |
| eventrouter | 事件采集，能够采集集群中的 event 到 es 中； |
| blackbox-exporter | 被动监测主机与服务状态； |
| 存储 M3DB | 分布式时序数据库； |
| Metrix | 自研产品，用于报警； |
存储后端
存储后端次要是 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 作为新生代的开源监控零碎，已成为云原生体系的事实标准，也证实了其设计很受欢迎。