标签频道
监控告警
该标签下的文章、提问与讨论帖。
【背景】 做了 8 年指标体系，最怕的不是"设计新指标"，而是"改老指标的口径"。上个月我们团队改了一个核心指标——"日活跃接口调用量"从"所有请求数"改为"去重独立接口调用数"（排除客户端重试和心跳探活）。改之前我以为影响面可控，结果：3
【背景】 做了 10 年数据分析与指标体系搭建，一个反复被问的问题：告警阈值到底怎么定？ 最常见的两种做法： 做法 A：绝对值 - P99 > 200ms 报警 - 错误率 > 1% 报警 - 队列长度 > 1000 报警 优点：简单、可解
【背景】 我负责一套 MySQL 8.0.36 / InnoDB 订单+账务系统，单主单从，主库 buffer pool 64G，核心表 1.2 亿行，"innodb_purge_threads=4"，隔离级别 REPEATABLE REA
【背景】 做了 10 年算法工程，最近半年主要在帮业务搭指标体系与告警链路。踩到一个反复出现的坑：阈值定得太死，要么半夜狼来了，要么白天出事没人喊。 举两个真实场景（已脱敏）： - 场景 A：某支付网关 P99 绝对阈值 500ms，但业务
【背景】 我做了 3 年技术文档，近两年重心在数据分析与指标体系搭建。最近半年在 3 个不同团队做"事故复盘 → 改进项 → 监控告警"的落地收尾。反复出现同一个模式：复盘会上 6–8 个工程师各自喊"应该盯 X 指标"，最后落地时只留 1
【背景】 我做了 3 年 SRE，手上管着 40 来个服务的告警。去年 Q4 我们团队把「每周 3am 被叫醒次数」立成了硬指标：从平均 6 次压到 0，庆功会上老板说这就是「稳定性的胜利」。 但今年 Q1 复盘一起 P2 事故时我发现一个
【背景】 做了 15 年数据分析与指标体系，我发现一个很少被摆到台面上、却天天在坑人的问题：同一个接口、同一段时间，「P99」在不同系统里能对出两三个不同的数字——Grafana 一个、APM 平台一个、日志离线聚合又一个。复盘事故、写 S
一、现象：凌晨 3 点的告警，比想象中严重 2025-07-12 03:17，监控群弹出第一条告警：Redis 主节点 "used_memory" 达到 58.7GB，逼近 "maxmemory 64GB" 上限。20 分钟后，业务侧开始报
【背景】 3 年前端，现在负责一个中型 B 端产品：日均 80w PV，12 个核心页面，React + Webpack，自研监控 SDK 上报到自建的日志平台。 去年花了一个季度把可观测性「补齐」： - Sentry：JS 异常 + 接口
【背景】 做了 15 年技术文档，后来一头扎进指标体系搭建，踩得最多的坑不是算法，而是「口径」。举个真实到不能再真实的场景：同一套订单服务，同一个 P99，三个团队算出三个数—— - 网关侧按请求维度算，窗口 5 分钟，P99 = 86ms
【背景】 我负责一个订单查询服务：Spring Boot 3.2 + JDK 17 + HikariCP 5.1 + MySQL 8.0，K8s 部署 4 副本，单副本 4C8G，入口稳态 800 QPS、峰值 1500。每次连接池打满都是
«结论先行：systemd 的 "Restart="、"StartLimitBurst"、"WatchdogSec" 是三条互相独立、互相不兜底的防线。绝大多数团队只配了第一条（"Restart=on-failure"），于是「进程死了能拉
背景 做指标体系这几年，我发现一个很反直觉的现象：大家花大量精力在"采集什么指标"和"看板怎么画"上，但对最基础也最容易被低估的一步——阈值到底怎么定——讨论得远远不够。 我见过三种典型翻车： 1. 某支付网关 P99 延迟告警写死 200
一、现象：df 说还有空间，应用却说写不进去 去年 11 月凌晨 02:17，监控告警："order-gateway" 节点（CentOS 7.9，XFS 文件系统，系统盘 100GB）连续 3 分钟写入失败，业务日志刷满 "No spac
文
标题
摘要