3 个关键决策让 Prometheus 监控平稳落地生产环境【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheusPrometheus 是一款开源监控系统兼时序数据库负责指标的采集、存储与查询。本文复盘我们在生产环境中先后遇到的 3 个具体问题告警风暴、扩容后的监控盲区和存储成本失控并给出当时的配置决策与验证方式适合刚接触 Prometheus 监控的工程师和技术负责人参考。把告警按严重级别分层日通知量降到值班能处理的量级现场现象。上线头两个月我们把能想到的告警全部写进了规则文件结果每天 100 条以上的通知涌进值班群。值班同学很快开始忽略真正需要关注的实例宕机淹没在噪音里。告警系统从提醒工具变成了噪音源。思路与决策。我们做的第一件事不是加规则而是给存量规则逐条定级只保留 critical 和 warning 两级critical 表示现在就要有人接手warning 表示今天内看一眼。其余降级为 info不进值班渠道。同时给 critical 告警统一加for: 2m过滤网络抖动造成的瞬时误报再配合分组与抑制一个实例 down 时抑制它的连通性告警避免同根因连发 5 条。groups: - name: availability rules: - record: job:up:avg1h expr: avg by (job) (up) - alert: InstanceDown expr: up 0 for: 2m labels: severity: critical上面第 4 行的 recording rule预计算规则把每个 job 的可用率提前算好存成一条新时间序列值班时直接查它避免每次现算完整写法可参考告警规则文档。验证方式。统计告警通知的条数变化治理前后一周日均通知从约 120 条降到 20 条以内更重要的是 MTTR平均恢复时间从小时级回到 10 分钟级——规则少而准之后值班响应意愿明显恢复。让 Kubernetes 服务发现自动跟踪新实例消除扩容后的监控盲区现场现象。业务按季度扩容Pod 数量翻了两倍。老配置里靠静态 IP 列表采集的目标越来越多新 Pod 上线后要人工补 IP平均 2 天左右才补完这期间新实例的指标是空白的出了故障只能翻应用日志。思路与决策。我们放弃静态列表改用 Prometheus 的 Kubernetes 服务发现通过 role 声明要发现的对象Pod、Service 等由 kube API 自动推送目标列表新 Pod 创建后一个采集周期内就会出现在采集列表里。用注解做过滤只有主动声明需要被监控的 Pod 才被抓取避免把无 /metrics 接口的实例也算进去scrape_configs: - job_name: kubernetes-pods kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: truerelabel 这里只做一件事按 Pod 注解prometheus.io/scrape: true保留目标。对于边缘节点或采集量特别大的场景可以考虑 Agent 模式——它不保留本地历史数据只做抓取并通过 remote write 转发给中心存储磁盘占用小很多官方说明见 Prometheus Agent 文档。验证方式。写一条 PromQL 对比发现的 Pod 数和实际运行的 Pod 数两者一致即说明没有盲区count(kube_pod_info) count(kube_pod_info{node!})扩容演练时新 Pod 上线后约 30 秒内一个 15s 采集间隔加缓冲就能查到指标盲区基本消除。给保留时长和磁盘上限设硬顶让 TSDB 容量可预期现场现象。Prometheus 自带的 TSDB时序存储默认只限时间不限空间运行半年后单节点磁盘被吃到 80%扩容窗口期一过就必须处理。事后看问题在于我们没在部署第一天就给保留策略设上限数据量涨了多少全靠感觉。思路与决策。我们同时设了时间和空间两条硬顶谁先到就先清理谁避免单维度失控./prometheus \ --config.fileprometheus.yml \ --storage.tsdb.retention.time15d \ --storage.tsdb.retention.size80GB15 天本地保留对故障回溯足够更长的历史交给 remote write 推到长期存储。与此同时我们把几个高基数序列数多的聚合查询改成了 recording rules让采集侧和查询侧的压力都降下来——预计算把重复查询摊平序列数增长也更容易盯住。验证方式。对prometheus_storage_bytes和prometheus_tsdb_head_active_series两个指标做趋势图磁盘用量按线性缓慢增长而非指数活跃序列数稳定在 50 万上下。容量评审时直接拿这条趋势外推下季度空间即可不再拍脑袋。现在就能启动的 3 件事 给存量告警规则定级逐条标注 critical / warning删除无主告警给 critical 统一加for时间一周内观察通知量是否降到 30 条/日以内。补一份冗余与发现配置确认 scrape 目标是动态发现而非静态 IP给关键 Prometheus 实例配第二副本两边external_labels用不同值区分来源。设置保留硬顶并盯两个指标加上--storage.tsdb.retention.time和--storage.tsdb.retention.size对磁盘与活跃序列数建趋势面板增长异常时先查是否有未收敛的高基数标签。这三件事不依赖任何新组件改动集中在 配置文件 与启动参数查不明白 PromQL 写法的可以从 PromQL 入门 补起。配置做完后用真实扩容或故障演练验证一遍比任何理论推演都可靠。【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 3 个关键决策：让 Prometheus 监控平稳落地生产环境
3 个关键决策让 Prometheus 监控平稳落地生产环境【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheusPrometheus 是一款开源监控系统兼时序数据库负责指标的采集、存储与查询。本文复盘我们在生产环境中先后遇到的 3 个具体问题告警风暴、扩容后的监控盲区和存储成本失控并给出当时的配置决策与验证方式适合刚接触 Prometheus 监控的工程师和技术负责人参考。把告警按严重级别分层日通知量降到值班能处理的量级现场现象。上线头两个月我们把能想到的告警全部写进了规则文件结果每天 100 条以上的通知涌进值班群。值班同学很快开始忽略真正需要关注的实例宕机淹没在噪音里。告警系统从提醒工具变成了噪音源。思路与决策。我们做的第一件事不是加规则而是给存量规则逐条定级只保留 critical 和 warning 两级critical 表示现在就要有人接手warning 表示今天内看一眼。其余降级为 info不进值班渠道。同时给 critical 告警统一加for: 2m过滤网络抖动造成的瞬时误报再配合分组与抑制一个实例 down 时抑制它的连通性告警避免同根因连发 5 条。groups: - name: availability rules: - record: job:up:avg1h expr: avg by (job) (up) - alert: InstanceDown expr: up 0 for: 2m labels: severity: critical上面第 4 行的 recording rule预计算规则把每个 job 的可用率提前算好存成一条新时间序列值班时直接查它避免每次现算完整写法可参考告警规则文档。验证方式。统计告警通知的条数变化治理前后一周日均通知从约 120 条降到 20 条以内更重要的是 MTTR平均恢复时间从小时级回到 10 分钟级——规则少而准之后值班响应意愿明显恢复。让 Kubernetes 服务发现自动跟踪新实例消除扩容后的监控盲区现场现象。业务按季度扩容Pod 数量翻了两倍。老配置里靠静态 IP 列表采集的目标越来越多新 Pod 上线后要人工补 IP平均 2 天左右才补完这期间新实例的指标是空白的出了故障只能翻应用日志。思路与决策。我们放弃静态列表改用 Prometheus 的 Kubernetes 服务发现通过 role 声明要发现的对象Pod、Service 等由 kube API 自动推送目标列表新 Pod 创建后一个采集周期内就会出现在采集列表里。用注解做过滤只有主动声明需要被监控的 Pod 才被抓取避免把无 /metrics 接口的实例也算进去scrape_configs: - job_name: kubernetes-pods kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: truerelabel 这里只做一件事按 Pod 注解prometheus.io/scrape: true保留目标。对于边缘节点或采集量特别大的场景可以考虑 Agent 模式——它不保留本地历史数据只做抓取并通过 remote write 转发给中心存储磁盘占用小很多官方说明见 Prometheus Agent 文档。验证方式。写一条 PromQL 对比发现的 Pod 数和实际运行的 Pod 数两者一致即说明没有盲区count(kube_pod_info) count(kube_pod_info{node!})扩容演练时新 Pod 上线后约 30 秒内一个 15s 采集间隔加缓冲就能查到指标盲区基本消除。给保留时长和磁盘上限设硬顶让 TSDB 容量可预期现场现象。Prometheus 自带的 TSDB时序存储默认只限时间不限空间运行半年后单节点磁盘被吃到 80%扩容窗口期一过就必须处理。事后看问题在于我们没在部署第一天就给保留策略设上限数据量涨了多少全靠感觉。思路与决策。我们同时设了时间和空间两条硬顶谁先到就先清理谁避免单维度失控./prometheus \ --config.fileprometheus.yml \ --storage.tsdb.retention.time15d \ --storage.tsdb.retention.size80GB15 天本地保留对故障回溯足够更长的历史交给 remote write 推到长期存储。与此同时我们把几个高基数序列数多的聚合查询改成了 recording rules让采集侧和查询侧的压力都降下来——预计算把重复查询摊平序列数增长也更容易盯住。验证方式。对prometheus_storage_bytes和prometheus_tsdb_head_active_series两个指标做趋势图磁盘用量按线性缓慢增长而非指数活跃序列数稳定在 50 万上下。容量评审时直接拿这条趋势外推下季度空间即可不再拍脑袋。现在就能启动的 3 件事 给存量告警规则定级逐条标注 critical / warning删除无主告警给 critical 统一加for时间一周内观察通知量是否降到 30 条/日以内。补一份冗余与发现配置确认 scrape 目标是动态发现而非静态 IP给关键 Prometheus 实例配第二副本两边external_labels用不同值区分来源。设置保留硬顶并盯两个指标加上--storage.tsdb.retention.time和--storage.tsdb.retention.size对磁盘与活跃序列数建趋势面板增长异常时先查是否有未收敛的高基数标签。这三件事不依赖任何新组件改动集中在 配置文件 与启动参数查不明白 PromQL 写法的可以从 PromQL 入门 补起。配置做完后用真实扩容或故障演练验证一遍比任何理论推演都可靠。【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考