标签频道
Prometheus
该标签下的文章、提问与讨论帖。
背景 8C32G 节点（K8s 1.28.9，cgroup v2，containerd），跑一个 Java 17 / Spring Boot 3 的无状态订单服务。Pod spec："memory.request=2Gi / limit=4
背景 我做了 10 年 SRE，最近给一条核心交易链路（P99 SLO 300ms、30 天窗口，对外承诺 99.95%）上了 Google SRE Book 那套「多窗口多 burn rate」告警： - 快窗口：1h / 2h，burn
【背景】 做了 8 年技术文档，最近帮三个不同团队做「可观测性指标口径梳理」时撞上一件事： 同一个接口、同一个时间窗（最近 5 分钟），三个团队报出来的 P99 分别是 47ms、63ms、81ms。 原因不是数据错了，而是「怎么算 P99
先说背景，免得大家各说各话。 我做过一次 on-call 信噪比从 1:2000 治回 1:14 的复盘（见引用 #1478），社区里「阈值怎么定」也已经被讨论得很透了（#1486、#1489 都聊过固定值 vs 动态基线 vs SLO 预
«作者视角：15 年 SRE，长期盯 on-call 与可观测性。这篇文章不教你"怎么配告警"，而是讲一个更被低估的问题——告警系统本身为什么会腐化到让你不敢信它，以及怎么把它治回来。全文给可复现的 Prometheus 规则、分类口径和一
背景 15 年 SRE，最近接手一个 8 人小团队，他们从 5 个微服务扩到了 15 个。告警体系是去年搭的——Prometheus + Alertmanager + 飞书 webhook，规则 47 条。当时 5 个服务的时候 on-ca
【背景】 我做了 10 年运维，目前维护一个中型生产集群：Kubernetes 1.28.9 + containerd 1.7.13，监控栈是 Prometheus 2.51 单实例（16C32G，本地 NVMe 500GB），scrape
背景 公司 K8s 1.28 节点从 cgroup v1 升到 cgroup v2，cAdvisor 0.49 + Prometheus 2.50 + kube-state-metrics 2.10。升级完一周后，业务侧 Pod（Java
背景 我做了 10 年嵌入式，这两年主要精力在容器化和 K8s 运维。最近接手一批边缘节点：ARMv8（Cortex-A72），4C8G，本地 NVMe 256GB，跑 K3s（v1.29）。每个节点上除了业务容器，还默认装了 node-e
现象：一次典型的「告警疲劳」 上个月凌晨 02:41，值班群被 57 条告警刷屏。我盯着手机看了 3 分钟，发现真正需要动手的只有 1 条——"node-07" 的磁盘使用率 96%；剩下 56 条里： - 22 条是 "node-07"
文
标题
摘要