记一次redis挂机导致的服务雪崩事故,哦不对,是故事~

  • 时间:
  • 浏览:2
  • 来源:5分3D_5分排列5

    以后 ,发现亲戚朋友好几只业务的域名都暴增了,以后 又没方向了,意味着并都不 哪个特定的业务出了间题,要是整体的。

    结果,测试环境一样搜索出该情况表,意味着机制决定,最终确认该情况表也为正常访问。

    最后,发现,ip都不 无规律分布的,亲戚朋友假设是被肉机模拟的ip,以后 这条路也意味着走不通了。

    从连接原理上和代码逻辑上,确认代码连接redis都不 短链接,本次访问完成后释放该连接。(针对该间题,我还一度怀疑redis的连接意味着被默默重用,但最终证明我是错的)

  3. 对比刚刚这麼 报警时的访问情况表和现在的情况表? 对比出间题前后访问情况表刚刚,得知:在这麼 该间题时,也会有流量高峰,以后 都不 其他点,以后 服务器也是正常运行。也这麼 否肯定,是上方位于了哪几种,才意味着的间题!

  7. 统计每个ip的访问情况表,确认与非 有黑客攻击行为? 与每个接口访问统计一样,统计ip

  当然,这里有个间题也是我没想太明白的,要是有刚刚对于调用第三方的东西,你搞活动不去跟别人打招呼(一般情况表都不 会),这麼 ,你的系统扛住了压力,这麼 别人的系统呢?



周一,开发同学还没去找运维同学查间题,运维同学倒先紧张起来了。

意味着是,朋友从监控(监控工具: granfana, zabbix)上发现,服务器到其他点就会有二个 访问量的暴增,真的是暴增哦,从图中可不都可以看出,二个 笔直的线就上去了。以后 运维同学也给出了具体哪几种接口的访问次数,以后 给出了对比性的数据,在其他点的接口访问次数比其他时间要多上一倍以上的访问量。

要是是虚惊一场啊(业务人员一不小心搞的秒杀活动~,流量暴增属正常情况表),好的反义词服务器多次挂掉,以后 意味着都不 个人所有的锅,悬着的心总算掉下来了。

  6. 发现可疑接口,怀疑意味着被黑客攻击,重点排查?

  2. 是都不 代码里连接redis后,不释放该连接?

  4. 会我这麼多 是定时任务反复访问个人所有的服务器,从而意味着该流量高峰? 仔细检查任务中心(quartz),以及每台机器上的crontab,确认异常的脚本运行位于。不过,以后 排除了该意味着,可亲戚朋友曾一度花了很长时间在排查其他意味着性上!

  8. 统计每个开放域名的访问情况表,以确认与非 某个不安全的域名被扫描意味着攻击了?

好的反义词其他工作应该是留在前面进行的,以后 亲戚朋友也是到了上方,好的反义词这麼了方向,才又折回来的,统计法律办法和(5)是一样的。

  5. 统计每个接口的访问量,对比间题前与间题后? 对于该间题,主要通过统计服务器的访问日志,如apache的access_log, 得到接口地址,当然了,亲戚朋友都不 要是的集群环境,意味着要在每台机器进行日志搜索,自然是要累死人的。咱们使用 salt工具,进行一台机器上直接搜索所有机器上的日志文件,进行统计。如:

    排查过程中发现其他接口,正常的访问这麼 是get,以后 却发现有post请求,以为是异常请求。于是找了一台测试环境下访问日志,也进行相应的统计:

以后 ,归根结底,还是亲戚朋友的系统过低牛逼啊,对于这突发的流量,一下没扛住,当然,在本案中,主要表现为redis这麼 扛住压力,赶紧强化进来吧!~

  对于推送活动一类的操作,一定要先跟技术运维做好沟通,将所有的流量预估,机器新增,安全因素考虑在内。让系统做好足够的准备,不能安稳地去搞个人所有的活动,以后 任何二个 环节都意味着意味着瓶颈,从而合使服务瘫痪。(应对其他情况表,亲戚朋友这麼 這個法律办法,重启服务甚至服务器)

事故时常有,最近有点多!但每次事故总会这麼 人出来背锅!意味着都不 个人所有的锅,正确处理了对个人所有是這個成长。意味着是个人所有的锅,恐怕锅大了,就得走人了,哈哈哈。。。

    该请求达到好几十万的访问,以后 亲戚朋友又去找,为哪几种会有其他请求,以后 努力模拟其他请求,甚至想用线上服务器地址作为请求对象,但最终也这麼 模拟出其他情况表。意味着无论为甚会 请求,一定会有二个 相对路径地址产生,以后 在OPTION成功刚刚,会默认触发一次GET请求。

  9. 查看业务代码日志,检查与非 冒出了相应的访问后端接口缓慢或异常的情况表?

我随机抽看后下某台机器的日志,发现一切访问都正常,除了几只redis读取的异常外,并无异常值得注意。以后 我作出了判定,后端接口这麼 间题。当然,这最终证明了我是错的,意味着正意味着后端服务响应慢,从而意味着了前端请求老要挂起,从而redis连接未释放情况表,从而意味着其他的redis连接!

  10. 根据统计中发现,在冒出间题时,access_log中,有大量的" OPTION * " 的请求,为哪几种? 日志如下:

  这不,最近又出了二个 锅:从周五现在现在开始了了,每天到11点就不停的接到服务器报警,对于一般的报警,亲戚朋友早已见怪不怪了,以后 作了稍微排查(监控工具: CAT),发现是redis间题,没找到意味着,以后 过了一会个人所有就好了,要是刚现在现在开始了了也没为甚会 管他。以后 ,第五天报警,第五天报警。以后 领导火了,以后 亲戚朋友只好说,要不等到周一上班咱们再正确处理吧!

以后 现在现在开始了了排查:

  1. 是都不 代码有间题,会我这麼多 意味着个人所有调用个人所有意味着流量激增? 确认最近项目有上线吗?我擦,我还真有二个 项目是差这麼来越多其他时间上去的,吓死我了,赶紧查看代码与非 有漏洞位于,几经排查后,确认这麼 间题。以后 ,抛弃该条路。

    最终证明,这要是apache在管理子多多线程 时,对自身多多线程 的监听所产生的access log日志,对都不 间题的方向。

  11. 所有间题都排查了,仍然我不知道这流量是从哪里来的,这麼 问个人所有了? 老要这麼 人想起,产品改过某个流控规则,提示文案为”xx业务在xx点开抢,并不错过“!我靠,这都不 秒杀系统何时能 能 ?流量不暴增才怪!