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: 9100README 中由 helm-docs 自动生成的 Values 表格与之一一对应KeyTypeDefaultDescriptionprometheus-node-exporter.namespaceOverridestringmonitoring覆盖默认命名空间prometheus-node-exporter.podAnnotations.prometheus.io/portstring9100采集端口标注prometheus-node-exporter.podAnnotations.prometheus.io/scrapestringtrue允许采集标注逐项说明namespaceOverride: monitoringnode-exporter 的 DaemonSet 及其 ServiceAccount 等资源被强制部署到monitoring命名空间与 Aptos 监控栈Prometheus、Grafana、Alertmanager保持同一命名空间便于 Prometheus 的 service discovery 按命名空间就近发现目标。podAnnotations.prometheus.io/scrape: true为 node-exporter Pod 打上 Prometheus 标准采集开关标注Aptos 监控栈中的 Prometheus 据此自动抓取该 Pod。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: 9100prometheus-node-exporter采集的是宿主机层面的指标node_*系列如node_cpu_seconds_total、node_memory_*、node_filesystem_*、node_network_*通过 DaemonSet 在每个节点上运行一个 Podkube-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 会注入如下 valuesresource 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时设置变量或写入.tfvarsterraform apply -varenable_prometheus_node_exportertruevalues参数中的jsonencode(var.monitoring_helm_values)还允许你以额外的monitoring_helm_values变量对 node-exporter 的namespaceOverride、podAnnotations等做最终覆盖实现默认值 自定义覆盖的灵活组合。五、废弃声明与迁移指引以官方 chart 为最终归宿README 开头即明确声明该图表DEPRECATED已废弃并建议改用 Prometheus 社区官方 chartprometheus-community/helm-charts 仓库下的charts/prometheus-node-exporter。迁移时建议新部署直接以官方prometheus-node-exporter图表为依赖或在监控栈的values中维护prometheus-node-exporter.enabled / namespaceOverride / podAnnotations三项配置替代本包装图表存量部署核对当前helm list中由本图表创建的 release迁移后保持namespaceOverridemonitoring或kube-system与prometheus.io/scrape、prometheus.io/port标注一致确保 Prometheus 抓取规则无需改动版本锁定参考本仓库 Chart.lock 的做法在迁移后的Chart.yamlChart.lock中锁定官方图表 4.17.5 版本及其 digest保证可复现部署。六、验证与排查部署完成后可通过以下方式确认 node-exporter 是否被 Prometheus 正常采集查看 Pod 状态与标注确认 DaemonSet Pod 处于 Running且 Pod 上带有prometheus.io/scrapetrue与prometheus.io/port9100直接探测指标端点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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考