大促场景下，监控服务器、CDN、高防必须三层联动告警，任何单点监控都会让你在大促流量洪峰中变成盲人；而整套联动方案的核心是：先看带宽是否被打满，再看连接数是否异常，最后才排查业务代码和数据库。这套排查顺序,能帮你省下大把黄金抢救时间。
大促前服务器CDN高防怎么做联动告警
大促前做联动告警，很多人第一反应是给三套系统分别设阈值，这正是误报和漏报的根源，监控服务器看CPU，高防看攻击流量，CDN看回源率，各看各的，一旦真出问题，告警会同时涌进来,你不知道该先处理哪个。
行业共识是：按流量走向做告警分层，用户请求先到高防，高防过滤后转发给CDN，CDN命中缓存直接返回，没命中的请求才回源到你的服务器，告警也要按这个链路逐层设置,每一层只关注和它直接相关的指标。
高防告警：盯清洗量而不是攻击峰值
高防的第一层看的是攻击流量峰值的绝对值，很多厂商默认在超过阈值的瞬间就触发告警，大促期间的正常流量本身就比平时高好几倍，这个默认阈值参考意义不大,更靠谱的做法是看清洗量占比。
具体操作为：在高防控制台的告警设置里，将“清洗流量占总流量比例”设为主要触发条件，当这个比例超过一定数值时，说明来路不明的流量正在挤占正常访问的通道，把连接数新建速率作为辅助告警条件，应对慢速连接型的CC攻击，这两项指标联动,大促期间高防告警的准确率会显著提高。
CDN联动告警：回源率是唯一信任标尺
CDN层会同时出现两个指标波动：命中率和回源率，它们是此消彼长的关系，大促前你调整了刷新预热策略，命中率会短暂下降，这是正常现象，但如果回源率在几分钟内持续攀升，同时源站服务器的带宽使用率同步上涨,那问题就严重了。
这说明缓存正在大面积失效，或者出现了针对源站的直接攻击，此时CDN告警的作用是提前告诉你：源站即将承受压力，收到这类告警后，你不需要去CDN后台反复排查，而是直接切到服务器监控页面,看带宽和连接数是否已经在爬升。
服务器监控：别只看CPU和内存
服务器层的CPU和内存告警，在大促流量突增场景下是最后才会触发的指标，在此之前，带宽使用率、TCP连接数、请求队列深度会率先变化，所以服务器监控告警的设置,要把网络层的指标排在CPU之前。
- 带宽使用率：超过总带宽的80%时触发预警，90%时触发紧急告警
- TCP连接数：新建连接数速率超过平时3倍时预警，5倍时紧急
- 请求平均响应时间：超过500毫秒且持续1分钟
- 错误状态码比例：4xx和5xx占比异常升高时立即告警
指标是你在监控系统后台需要着重配置的，按照这个优先级去响应告警,大促期间服务器侧的有效告警数量会明显可控。
联动告警的落地动作：消息聚合与值班响应
三层告警都触发时，如果分别推送给三拨人，就会出现互相等待、推诿的情况，正确的操作是搭建一个告警聚合群，把高防、CDN、服务器三方的告警推送到同一条消息流，按时间顺序排列,值班人员看到的第一条告警往往就是问题的起点。
电商大促监控服务器延迟高是什么原因
大促期间，你会收到一条服务器响应变慢的告警，此时别急着登录服务器看日志，按下面的顺序排查,最快能定位问题。
第一步：立刻看带宽和TCP连接数
这是排查延迟问题的首要动作，登录监控后台，调出服务器带宽使用率曲线和TCP连接数曲线，如果带宽使用率已经逼近上限，那问题出在网络层，可能是CDN回源流量异常,也可能是高防的转发链路出现了拥堵。
此时去高防后台看清洗流量是否异常，如果是，说明有人正在尝试绕过CDN直接攻击源站IP，如果清洗量正常，再看CDN的回源统计，确认哪些URL正在被高频回源,进一步排查是否发生了缓存穿透。
第二步：确认回源请求量是否翻倍上涨
CDN的缓存命中率在正常情况下应保持高位，如果发现命中率下降了两成以上，而回源请求数翻倍，问题大概率出在缓存key的设计上，比如大促期间URL带了时间戳参数或者用户ID参数，导致CDN无法命中缓存,每个请求都穿透到源站。
这种场景下，服务器的CPU和内存可能还处于安全水位，但请求处理线程已经被占满，表现出来的是响应延迟慢慢爬升，解决方向是调整CDN的缓存key配置，忽略掉URL中的动态参数,或者在代码层面改用Cookie传递这些动态信息。
第三步：检查慢查询和数据库锁竞争
完成带宽和回源检查后，如果网络层数据一切正常，那问题就在应用层和数据库之间的交互上，登录服务器，查看数据库的慢查询日志，找个出现频率最高的SQL语句,看它的执行计划和索引命中情况。
同时关注数据库的锁等待时间，大促期间，热卖商品的库存扣减操作会集中在同一行记录上，锁竞争激烈，事务等待时间拉长，外部表现就是接口响应变慢，这种情况下，可以考虑应用层的限流和削峰，比如对库存扣减接口做请求排队处理,或者引入消息队列把写请求做异步化。
大促期间的告警阈值怎么设才不误报
阈值设置没有一劳永逸的通用答案，不同业务的流量模型差异很大,这里给到一套公认的可落地的设定逻辑。
高防清洗阈值：按近7天峰值上浮
调出高防运营数据中近7天的正常流量峰值，按照这个峰值乘以一个系数来设定告警阈值，具体系数可以根据大促的预期增长来调整，预估增长5倍就按5倍设，预估增长10倍就按10倍设，这个设置逻辑的好处是，既能自动适应业务波峰波谷的节奏,又能避免固定阈值在大促期间频繁误报。
CDN回源告警：关注比例而非绝对值
回源率的告警阈值不要设成固定数字，一个日活上百万的应用和一个日活几千的小程序，回源率绝对值不具备可比性，正确的做法是关注回源率的变化速率，设置一个规则：回源率在5分钟内上升超过20%，触发警告；上升超过50%,触发紧急告警。
服务器带宽告警：按端口区分
如果是Nginx反代架构，8090端口负责静态资源，7080端口负责动态请求，两个端口的带宽消耗特征完全不同，共用一套阈值会导致告警失真，建议按端口分别设置带宽告警，同时把每个端口的连接数也纳入独立监控,这样才能在大促期间快速定位是哪一类请求在耗资源。
联动告警的响应动作前置演练
阈值设好了，不演练等于白设，大促前48小时，建议做一次完整的联动告警演练,具体操作步骤是：
- 在监控后台新建一条测试用的告警规则，模拟高防清洗量突增事件
- 触发该告警后，验证消息是否按时推送到了值班群
- 按预案执行CDN刷新预热操作，确认源站带宽是否下降
- 记录从告警触发到处置完成的总时长，目标是不超过5分钟
- 根据演练结果调整值班排班表和升级机制
这一步实操做完，大促当天即使真出状况,也不会手忙脚乱。
大促当天怎么配合监控值班
大促正式开始后，盯监控屏幕这件事，也有讲究，不要三个人同时盯同一块大屏，要分工协同，一个人盯高防的攻击态势和清洗量，一个人盯CDN的命中率和回源率，一个人盯服务器的带宽和错误码，三个人各看一屏，发现问题就在群里说一声,联动响应自然会发生。
还有人会问：监控告警和CDN高防联动告警配置的价格贵不贵？大多数云厂商的告警推送功能是包含在监控服务内的，短信和电话通知按条数单独计费，大促期间消息量会超出日常套餐，建议提前在控制台看一下通知额度的余额，预先把告警消息的接收人调整为核心几个人,避免消息轰炸。
Q&A：关于大促监控的常见问题
高防和CDN同时开启的情况下，源站IP还是暴露了怎么办？
这种情况下源站IP泄露通常来自两条途径：历史DNS解析记录和代码中的直接回源调用，前者可以在高防控制台开启源站IP保护，让高防代替源站进行回源；后者需要在代码层面排查所有直接指向源站IP的请求，统一改为通过CDN域名访问，如果泄露时间较长，最稳妥的方案是更换源站IP，并对新IP做好访问控制白名单,只允许高防的回源网段访问。
大促期间CDN回源率突然暴涨，服务器带宽被打满，是先扩容还是先调缓存策略？
先调缓存策略，再考虑扩容，如果缓存的配置本身有问题，扩容只能暂时缓解，伴随的是大促期间云资源成本的显著上升，先检查CDN控制台的缓存配置，确认动态参数是否被纳入了缓存key，排除缓存穿透的问题；然后检查源站是否被高频刷接口，如有必要，针对特定URL配置限频规则，做完这两步后，如果回源率回落，就不需要扩容了，如果回源率依然居高不下，再考虑临时带宽扩容,同时排查业务侧的异常请求。
联动的告警策略应该自己写还是用云厂商现成的模板？
云厂商提供的告警模板覆盖的是通用场景，比如CPU高、带宽被打满，这类模板在大促场景下通常不够精细，如果你对自家业务流量特征比较熟悉，建议自己配置，但要注意，自己配置的前提是清楚每一项指标的含义以及指标间的关系，如果刚开始接触监控告警配置，可以先从云厂商模板起步，在大促前的演练中观察告警的触发情况,再针对性地调整阈值和条件。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/630484.html
