近期接手离职同事项目,突然遇到线上事故,Flink无法正常聚合数据生成指标. 以下是详细的排查过程: 问题复现 清晨,运维报告Flink数据分析模块无法正常生成指标数据. 赶紧登陆Flink所在机器,使用如下语句简单查看Job状态. ./bin/flink list 查看输出,发现故障Job在Running状态. 因为数据分析模块运行时间较久,近期没有更新过,因此怀疑是依赖的中间件问题. 问题根源定位 (1) 查看数据源 数据分析模块依赖于Kafka,因此登陆Kafka所在机器,查看相应topi…
一次Java线程池误用(newFixedThreadPool)引发的线上血案和总结 这是一个十分严重的线上问题 自从最近的某年某月某天起,线上服务开始变得不那么稳定(软病).在高峰期,时常有几台机器的内存持续飙升,并且无法回收,导致服务不可用. 给出监控中GC的采样曲线: 内存使用曲线如下: 如上两张图显示:18:50-19:00的这10分钟阶段里,服务已经处于不可用的状态了.这就导致了:上游服务的超时异常会增加,该台机器会触发熔断. 熔断触发后,这台机器的流量会打到其他机器,其他机器发生类似的…
目录 前言 项目背景介绍 要命的update 结语 前言   从事互联网开发这几年,参与了许多项目的架构分析,数据库设计,改过的bug不计其数,写过的sql数以万计,从未出现重大纰漏,但常在河边走,哪有不湿鞋,就在五一假期的头一天,我干了职业生涯中最愚蠢,也是最刺激的一件事:执行update的时候忘了添加where条件,结果更新了整张表(系统最重要的一张表)的时间字段... 项目背景介绍   简单介绍一下项目背景:大家可以把其理解为一个文章检索系统,前台用户端通过输入日期.关键字以及文章类型可以…
前言 那天我和同事一起吃完晚饭回公司加班,然后就群里就有人@我说xxx商户说收不到推送,一开始觉得没啥.我第一反应是不是极光没注册上,就让客服通知商户,重新登录下试试.这边打开极光推送的后台进行检查.后面反应收不到推送的越来越多,我就知道这事情不简单. 事故经过 由于大量商户反应收不到推送,我第一反应是不是推送系统挂了,导致没有进行推送.于是让运维老哥检查推送系统各节点的情况,发现都正常.于是打开RabbitMQ的管控台看了一下,人都蒙了.已经有几万条消息处于ready状态,还有几百条unack…
[转]原文链接:https://cloud.tencent.com/developer/article/1497826 这是一个十分严重的线上问题 自从最近的某年某月某天起,线上服务开始变得不那么稳定(软病).在高峰期,时常有几台机器的内存持续飙升,并且无法回收,导致服务不可用. 给出监控中GC的采样曲线: 内存使用曲线如下: 如上两张图显示:18:50-19:00的这10分钟阶段里,服务已经处于不可用的状态了.这就导致了:上游服务的超时异常会增加,该台机器会触发熔断. 熔断触发后,这台机器的流…
> 线上用户存储数据后查看提示无权限 前言 不知道什么时候年轻的我曾一度认为Java没啥难度,没有我实现不了的需求,没有我解不了的bug 直到我遇到至今难忘的一个bug . 线上用户存储数据后查看提示无权限 初次定位 明明自己添加的数据,为什么提示自己没有权限呢?我一开始自信的认为是我们的客户操作有问题.或者是我们权限配置有问题 但是带我自己亲自验证了一下之后发现这个问题时现时不现,属于一个偶发的问题.这个在开发阶段还真的不容易发现. 问题升级 经过自己的测试后让我更加怀疑人生了,你要么就有问题…
今天线上的hadoop集群崩溃了,现象是namenode一直在GC,长时间无法正常服务.最后运维大神各种倒腾内存,GC稳定后,服务正常.虽说全程在打酱油,但是也跟着学习不少的东西. 第一个问题:为什么会频繁GC 有过JVM经验的开发者都应该知道,GC是在内存不够时,JVM自动进行的自我救赎(删除不用的数据,释放内存空间).那么NameNode在什么情况下会进行GC呢?在解释这个问题之前,需要明白GC的几种级别,以及触发的条件: Minor GC:清理新生代,一般都是复制回收算法 Full GC:…
最近开始服务拆分,时间将近半个月.测试阶段也非常顺利,没有什么问题. 但上线之后的第二天,产品就风风火火的来找我们了,一看就是线上有什么问题.我们也不敢说,我们也不敢问,线上的后台商品忽然无法上架了,导致运营的同学删除商品后无法上架新的商品,导致APP的部分商品暂时不可见. 线上有问题,那么大家就开始迅速排查起来了.这里有一点要说一下,在上线前夕,产品临时添加一个新的需求,商品的搜索状态不可判断这个条件去掉,这个由于紧急而且对于我们来说也就是SQL中的一个条件的问题,也就没有经过测试,直接上线了…
MyBatis上线前后的版本:上线前(3.2.3)上线后(3.4.6) 服务上线后,开始陆续出现了一些更新系统交互日志方面的报警,这属于系统的辅助流程,报警如下代码所示.我们发现都是跟 MyBatis相关的报警,说明在进行类型转换 [ibatis.type.TypeException]的时候,系统产生了强转错误. 更新开票请求返回日志, id:{#######}, response:{{"code":XXX,"data":{"callType":…
美好的周五 周五的早晨,一切都是那么美好. 然鹅,10点多的时候,运营小哥哥突然告诉我后台打不开了,我怀着一颗"有什么大不了的,估计又是(S)(B)不会连wifi"的心情,自信的打开了网址,果然,真打不开了. 这是存心让我过不好周末呀! 抓住那只bug 经过我缜密的排查,发现是一个"获取今天之前登录的用户"接口调用严重超时: 这个接口其实调用的数据表不多,在mysql只读取了1张表,表结构如下: 获取今天之前登录的用户列表的SQL如下: SELECT u.email…