4C8G 边缘 ARM 节点上 Prometheus + node-exporter + kube-state-metrics 到底吃掉多少？值不值得上？

背景 我做了 10 年嵌入式，这两年主要精力在容器化和 K8s 运维。最近接手一批边缘节点：ARMv8（Cortex-A72），4C8G，本地 NVMe 256GB，跑 K3s（v1.29）。每个节点上除了业务容器，还默认装了 node-exporter + prometheus-node-exporter 的 K3s 内置组件；我们想再加一个 Prometheus + kube-state-metrics + Grafana 的轻量栈做集中监控。痛点是：节点就 8G，业务本身要跑两个常驻服务（一个 MQTT broker ~500MB，一个规则引擎 ~1GB），留给监控栈和系统（K3s control plane + containerd + page cache）的余量很紧，我担心监控栈本身吃掉 1~2G 后把业务挤 OOM。

现象 / 现状

• 目前只跑 node-exporter，kubectl top node 看 CPU 基本贴地，内存里 node-exporter 容器 RSS ~40MB，可忽略。
• 但还没实测过 Prometheus + kube-state-metrics 一起上的开销。我的担忧是：Prometheus 本地 TSDB 在边节点上做 scrape + 本地存储，--local-storage.retention 开 7 天后内存和磁盘 IO 会不会飙；kube-state-metrics 在大集群（我们中心有 2000+ 对象）里启动内存会冲到 1GB+。
• 边缘节点网络是 4G/5G 回传，带宽 50Mbps 上下、延迟 80~200ms，把本地 Prometheus 的指标再 remote-write 回中心，这条链路的 CPU/内存代价我不确定。

已尝试的排查与结果

1. 只跑 node-exporter 稳态，节点空闲内存还剩 ~5G，看不出问题——但这不代表加了 Prometheus 也没事。
2. 在中心集群（16C64G）上跑过同样的 Prometheus 栈，稳态 ~1.5G，但那是 x86 大节点，跟 4C8G ARM 边缘节点不能直接类比，我不放心拿这个数套到边缘上。
3. 查了 K3s 文档，它的内置 agent 是单二进制带 prometheus + 告警，但没说清 4C8G 下的实测 RSS 上限，也没给 ARM 的参考值。

期望得到的答案形态（不是泛泛的「上 Prometheus」）

1. 一份实测数据：你们在 ≤8G 的节点（最好 ARM）上跑 Prometheus + kube-state-metrics + Grafana，稳态 RSS 峰值各是多少？Prometheus 的 --local-storage / TSDB 在 7d retention 下，内存和磁盘 IO 的实测曲线？
2. 一个取舍判断：边缘节点上，你们到底是「每节点本地 Prometheus + 回传」，还是「只跑 exporter / 轻量 agent，指标全部推到中心」？各自的 CPU/内存/带宽代价和故障域怎么权衡？
3. 一个可复现的最小配置：如果你们选择轻量方案，用的什么组件（VictoriaMetrics single-node？Thanos sidecar？还是 K3s 内置 agent + 中心 Prometheus remote-write？），关键的资源 request/limit 和 retention 参数怎么设，能贴出来最好。

我特别想要「你们在 4C8G 或更小节点上，监控栈最终稳态吃掉多少内存」这条硬数据。社区里大集群 x86 的讨论很多，但边缘 ARM 小节点的实测几乎没有，而我手上正好是这种场景，希望有人拆给我看。