/tags/%E7%9B%91%E6%8E%A7/ Recent content in 监控 on Hugo -- gohugo.io en Sun, 30 Aug 2026 06:45:00 +0800 /posts/memory-alert-page-cache-false-alarm/ Sun, 30 Aug 2026 06:45:00 +0800 /posts/memory-alert-page-cache-false-alarm/ 2026-08-29 15:49，监控发来一条 ContainerMemoryNearLimit（全文时刻都是 UTC）：homelab 的 Prometheus 容器 7 天内存峰值 3055Mi，limit 是 3Gi，占 99.45%。告警正文里那句「一次尖峰就会 OOMKill，而 OOM 后干净重启、无人察觉」是我自己写的。 但经历那个峰值的容器，自己的终止状态是这样： { "startedAt": "2026-08-29T15:09:21Z", "finishedAt": "2026-08-29T15:33:22Z", "exitCode": 0, "reason": "Completed" } 它活过了峰值，24 分钟后正常退出，紧接着就是 15:35 的第二次节点重启。拆开看，3055Mi 里约 87% 是页缓存（page cache），同一时刻 RSS 只有 408Mi。后来的对照实验里，什么都不改，只挑页缓存热的时候把它再重启一次，峰值 728Mi（23.70%），差了 4 倍多。 下面按排查顺序写，数字都是当时取的。 背景 这套 homelab 监控用的是 kube-prometheus-stack。Prometheus 跑在一台由笔记本改成的 Proxmox 宿主上的 K3s VM 里，memory limit 3Gi、requests 512Mi。 这条告警上一次响在 08-16，原因是 k3s 单进程把同一批 apiserver/etcd 指标重复暴露，active series 太多（那次的处理记在把重复 series 拦在入库前：我的 Prometheus 内存瘦身）。砍完 series 之后，max_over_time[7d] 还记着旧峰值。我挂了一条 7 天的 Alertmanager 静默（silence）等窗口滚过去，也在 values 文件里给自己留了一句注释：到期后仍然报，就别再续静默，去查原因。 /posts/prometheus-memory-tuning-cut-series/ Wed, 19 Aug 2026 07:39:00 +0800 /posts/prometheus-memory-tuning-cut-series/ 背景 homelab 这套监控是 kube-prometheus-stack（chart 87.6.0，跑的是 Prometheus 3.13.0），Prometheus 落在一台 12G 内存的笔记本 VM 上，是这台机器上最大的单一内存消耗者。 2026-08-16 起，ContainerMemoryNearLimit 连着两天报 Prometheus：7 天窗口的内存峰值 2715Mi / 3072Mi = 88%。我当时的处理是把 memory limit 从 3Gi 抬到 4Gi，抬完就发现这条路没得走了，宿主机 available 只剩 0.6G 左右，物理内存见底，再抬也没地方抬。08-18 改成砍产生内存的东西本身，砍完当天把 limit 收回了 3Gi。 今天早上（2026-08-19 07:39）从集群里拉的读数： 读数 08-18 改动前 现在 active series 234,532 113,262 ingest rate 7,562 samples/s 4,063 samples/s cgroup 内存峰值 2,002Mi 758Mi memory limit 4Gi 3Gi series 那一栏现在比刚改完那会儿（109,566）略高，是这一天里新增采集的自然增长。今天早上现取的 container_memory_working_set_bytes 是 799Mi，占 3Gi 上限的 26%。 我踩的坑基本是同一种：以为某个配置项管 A，其实它管的是 B。下面按这次的处理顺序记。