企业官网建设流程全解析

Aptos 节点监控中的 prometheus-node-exporter 包装 Helm Chart：配置解析与 Terraform 集成

【免费下载链接】aptos-coreAptos is a layer 1 blockchain built to support the widespread use of blockchain through better technology and user experience.项目地址: https://gitcode.com/GitHub_Trending/ap/aptos-core

导读

aptos-prometheus-node-exporter是 Aptos 官方 Kubernetes 部署体系中用于采集节点宿主机系统指标（CPU、内存、磁盘、网络等）的 Helm 包装图表（wrapper chart）。本文基于 terraform/helm/prometheus-node-exporter/README.md 及其配套的 Chart 元数据、values 配置，结合monitoring监控图表与terraform/aptos-node下的 Terraform 编排源码，完整讲解该图表的依赖结构、三个核心配置项、在 Aptos 监控栈中的启用方式，以及官方给出的废弃与迁移建议，帮助你直接复用到自己的 Aptos 节点集群监控方案中。

一、图表定位：一个极简的依赖包装层

在 Aptos 仓库中，terraform/helm/prometheus-node-exporter/目录下并非一个从零实现的 Chart，而是对 Prometheus 社区官方prometheus-node-exporter图表的一次最小化封装，目录结构如下：

terraform/helm/prometheus-node-exporter/ ├── charts/ # 打包缓存的依赖子图表 prometheus-node-exporter-4.17.5.tgz ├── Chart.lock # 依赖锁定文件（含 digest） ├── Chart.yaml # 图表元数据与依赖声明 ├── README.md # 本文档 └── values.yaml # 默认 values 覆盖

从 Chart.yaml 可以看到它的全部"业务逻辑"只有一条依赖声明：

apiVersion: v2 name: aptos-prometheus-node-exporter version: 4.17.5 dependencies: - name: prometheus-node-exporter version: 4.17.5 repository: "https://prometheus-community.github.io/helm-charts"

即：父图表版本号与依赖子图表版本号完全一致（4.17.5），父图表本身不渲染任何模板，仅负责把官方子图表带入发布，并通过values.yaml的层级覆盖机制注入 Aptos 部署所需的默认值。这种"依赖 + 覆盖"的包装模式，使得 Aptos 的监控部署可以锁定一个经过验证的 node-exporter 版本，同时保持对上层监控栈配置的单一入口。

依赖版本被固化在 Chart.lock 中，包含仓库地址、版本号、sha256digest 与生成时间（2023-06-07），确保helm dependency build/update拉取的子图表可复现、可审计。

二、Values 配置详解：三个关键覆盖项

values.yaml 是全仓库最小的 values 文件之一，只覆盖了三项配置：

prometheus-node-exporter: namespaceOverride: monitoring podAnnotations: prometheus.io/scrape: "true" prometheus.io/port: "9100"

README 中由 helm-docs 自动生成的 Values 表格与之一一对应：

逐项说明：

1. namespaceOverride: monitoring：node-exporter 的 DaemonSet 及其 ServiceAccount 等资源被强制部署到monitoring命名空间，与 Aptos 监控栈（Prometheus、Grafana、Alertmanager）保持同一命名空间，便于 Prometheus 的 service discovery 按命名空间就近发现目标。
2. podAnnotations."prometheus.io/scrape": "true"：为 node-exporter Pod 打上 Prometheus 标准采集开关标注，Aptos 监控栈中的 Prometheus 据此自动抓取该 Pod。
3. podAnnotations."prometheus.io/port": "9100"：指定采集端口。9100 是 node-exporter 的默认监听端口，Prometheus 依据此标注建立抓取端点（/metrics）。

三、在 Aptos 监控栈中的角色：与 kube-state-metrics 并列的采集器

将上述配置与 terraform/helm/monitoring/values.yaml 对比，可以清晰看出 node-exporter 在 Aptos 监控体系中的分工：

kube-state-metrics: enabled: false namespaceOverride: kube-system podAnnotations: prometheus.io/scrape: "true" prometheus.io/port: "8080" prometheus-node-exporter: enabled: false namespaceOverride: kube-system podAnnotations: prometheus.io/scrape: "true" prometheus.io/port: "9100"

• prometheus-node-exporter采集的是宿主机层面的指标（node_*系列，如node_cpu_seconds_total、node_memory_*、node_filesystem_*、node_network_*），通过 DaemonSet 在每个节点上运行一个 Pod；
• kube-state-metrics采集的是Kubernetes 对象状态指标（deployment、daemonset、pod 等资源对象的kube_*系列）；
• 二者共同组成 monitoring 图表 中默认关闭、按需开启的"集群可观测性扩展"，而核心的 Prometheus 指标（aptos_*、diem_*等节点内部指标）由监控栈主图表负责抓取与存储。

注意一个差异：terraform/helm/monitoring/values.yaml中 node-exporter 的默认namespaceOverride是kube-system，而独立包装图表 terraform/helm/prometheus-node-exporter/values.yaml 中设为monitoring——使用时需明确你以哪个入口部署，二者默认命名空间不同。

四、Terraform 集成：一行开关接入节点监控

node-exporter 的实际启用并不直接发生在 Helm CLI，而是通过 Terraform 的helm_release资源透传开关。在 terraform/aptos-node/aws/kubernetes.tf 与 terraform/aptos-node/gcp/kubernetes.tf 中，monitoring的 Helm release 会注入如下 values：

resource "helm_release" "monitoring" { count = var.enable_monitoring ? 1 : 0 name = "${local.helm_release_name}-mon" chart = local.monitoring_helm_chart_path max_history = 5 wait = false values = [ jsonencode({ chain = { name = var.chain_name } validator = { name = var.validator_name } service = { domain = local.domain } monitoring = { prometheus = { storage = { class = kubernetes_storage_class.gp3.metadata[0].name # AWS # class = kubernetes_storage_class.ssd.metadata[0].name # GCP } } } kube-state-metrics = { enabled = var.enable_kube_state_metrics } prometheus-node-exporter = { enabled = var.enable_prometheus_node_exporter } }), jsonencode(var.monitoring_helm_values), ] }

对应地在variables.tf中声明了开关变量：

description = "Enable prometheus-node-exporter within monitoring helm chart"

使用方式即terraform apply时设置变量（或写入.tfvars）：

terraform apply -var="enable_prometheus_node_exporter=true"

values参数中的jsonencode(var.monitoring_helm_values)还允许你以额外的monitoring_helm_values变量对 node-exporter 的namespaceOverride、podAnnotations等做最终覆盖，实现"默认值 + 自定义覆盖"的灵活组合。

五、废弃声明与迁移指引：以官方 chart 为最终归宿

README 开头即明确声明该图表DEPRECATED（已废弃），并建议改用 Prometheus 社区官方 chart（prometheus-community/helm-charts 仓库下的charts/prometheus-node-exporter）。迁移时建议：

1. 新部署：直接以官方prometheus-node-exporter图表为依赖，或在监控栈的values中维护prometheus-node-exporter.enabled / namespaceOverride / podAnnotations三项配置，替代本包装图表；
2. 存量部署：核对当前helm list中由本图表创建的 release，迁移后保持namespaceOverride（monitoring或kube-system）与prometheus.io/scrape、prometheus.io/port标注一致，确保 Prometheus 抓取规则无需改动；
3. 版本锁定：参考本仓库 Chart.lock 的做法，在迁移后的Chart.yaml+Chart.lock中锁定官方图表 4.17.5 版本及其 digest，保证可复现部署。

六、验证与排查

部署完成后，可通过以下方式确认 node-exporter 是否被 Prometheus 正常采集：

• 查看 Pod 状态与标注：确认 DaemonSet Pod 处于 Running，且 Pod 上带有prometheus.io/scrape=true与prometheus.io/port=9100；
• 直接探测指标端点：curl节点 Pod 的9100/metrics，应返回node_*系列指标；
• 在 Prometheus 的 Target 页面（/targets）中确认 node-exporter 目标状态为 UP。

若指标缺失，优先排查命名空间覆盖是否与 Prometheus 的 discovery 范围一致，以及prometheus.io/scrape标注是否被后续 values 覆盖覆盖。

总结

aptos-prometheus-node-exporter是 Aptos 仓库中一个"小而有代表性"的包装图表：它以单个依赖声明 + 三个 values 覆盖项，将官方 node-exporter 4.17.5 接入 Aptos 监控栈，并通过 Terraformhelm_release的enabled开关实现一键启用。理解它的依赖锁定、命名空间覆盖与 Prometheus 标注机制，无论继续沿用还是按官方建议迁移，都能保证 Aptos 节点的宿主机监控指标稳定、可复现地落入 Prometheus。

【免费下载链接】aptos-coreAptos is a layer 1 blockchain built to support the widespread use of blockchain through better technology and user experience.项目地址: https://gitcode.com/GitHub_Trending/ap/aptos-core