实习生跑路留了一个大坑,搞出2个线上问题,我被坑惨了

Posted 啊码

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了实习生跑路留了一个大坑,搞出2个线上问题,我被坑惨了相关的知识,希望对你有一定的参考价值。

小编今天被实习生坑惨了。。。

昨天线上问题

昨天出了一个线上问题,今天又出了一个线上问题。

昨天出的一个线上问题。

监控开始报大量的异常pvlost,接口访问过来报500,就报pvlost了。

小编赶快登录到这个出问题的实例,上去手动curl了一下这个请求,发现登录这个实例手动去curl没啥异常信息。

返回是正常的200。连续curl了十几次都没问题。

奇了怪了。

昨天没排查出来就想着加点日志打印点日志看下。这个问题先和客户同步好结论,就准备今天加日志看下。

结果今天还没来得及加日志。。。

今天又出一个线上问题

又爆出来个线上问题,那再继续看下这个新的线上问题。

发现新上线的一个查询故障机房的功能不太好使。

现在线上有两个机房。A机房和B机房。

  • 当A机房的tsdb时序数据库有问题就去查询B机房的tsdb时序数据库。
  • 当B机房的tsdb时序数据库有问题就去查询A机房的tsdb时序数据库。

客户op会发现哪个机房有问题,就会往数据库mysql插入一条故障机房数据。

上图里面的 idcA 对应的时间段有故障。

目前整个架构里面有M服务和D服务查询tsdb时序数据库。

在D服务里面实现了这个查询故障机房的功能,就是查询数据库里面看看那个机房有问题,如果发现用户传的查询起止时间段和mysql数据库里面的idcA故障时间有交集,那么就说明A机房有故障就去读取配置文件中idcB机房的url查询idcB机房的tsdb时序数据。

由于D服务实现了,就用M服务去查询D服务,由于D服务的可承受查询能力不行,M服务的查询压力很大,所以M服务查询D服务的时候做了一层缓存。

这缓存服务代码写的真牛逼,搞出两个线上问题。

    @Cacheable(value =  "cacheManager", key =  "#root.method")
    public String getMalfunctionStatus(long queryStartTime, long queryEndTime) 

        QueryDateDto queryDateDto = new QueryDateDto();
        String startTime = String.valueOf(queryStartTime);
        String endTime = String.valueOf(queryEndTime);

        queryDateDto.setStartTime(startTime);
        queryDateDto.setEndTime(endTime);
        String malfunctionStatus =  "";
        try 
            malfunctionStatus  = 查询D服务的数据http调用。
         catch (Exception e) 
            LOG.error( "request dashboard failed. e: ", e.getMessage());
            
        
         return malfunctionStatus;
    

缓存分析

getMalfunctionStatus 这个方法加了缓存,key是这个方法名字。假设传的参数queryStartTime:2022-05-17 10:00:00 queryEndTime 2022-05-17 12:00:00

假设这个时间段查询下游 D服务的http调用,返回是故障 状态

缓存时间失效是5分钟。

这5分钟内这个getMalfunctionStatus 这个方法返回的都是故障状态。

如果这5分钟内用户传的是参数queryStartTime:2022-05-17 12:00:00 queryEndTime 2022-05-17 14:00:00 查询时间段不一样,但是由于有缓存,这个返回的还是故障状态。

这缓存加了个寂寞。

加还不如不加。

不加起码能查询下游D服务是正确的返回结果,加了这5分钟内结果都是错的。。。

实习生给小编留大坑!

实习生牛X!

第二个坑

这个服务如果发现当前机房出现故障了。

就根据查询的下游D服务的状态发现故障了,需要切换查询机房的地址。

所以就在配置文件里面写了两个机房的地址,然后读取配置文件就行了。

由于最近用户使用了添加了故障机房,报大量接口返回500错误。

是配置文件这块切换机房的时候的没有端口。导致查询下游服务报500。

总结

之前还是对实习生太仁慈了,以后实习生的代码还是得好好看看,实习生拿着一天300的实习工资,写了一堆坑的代码,搞出两个线上问题,混了份大厂实习经历,拍拍屁股走人了,小编在这擦实习生的屁股。

难受。。。

实习生跑路留了一个大坑,搞出2个线上问题,我被坑惨了

小编今天被实习生坑惨了。。。

昨天线上问题

昨天出了一个线上问题,今天又出了一个线上问题。

昨天出的一个线上问题。

监控开始报大量的异常pvlost,接口访问过来报500,就报pvlost了。

小编赶快登录到这个出问题的实例,上去手动curl了一下这个请求,发现登录这个实例手动去curl没啥异常信息。

返回是正常的200。连续curl了十几次都没问题。

奇了怪了。

昨天没排查出来就想着加点日志打印点日志看下。这个问题先和客户同步好结论,就准备今天加日志看下。

结果今天还没来得及加日志。。。

今天又出一个线上问题

又爆出来个线上问题,那再继续看下这个新的线上问题。

发现新上线的一个查询故障机房的功能不太好使。

现在线上有两个机房。A机房和B机房。

  • 当A机房的tsdb时序数据库有问题就去查询B机房的tsdb时序数据库。
  • 当B机房的tsdb时序数据库有问题就去查询A机房的tsdb时序数据库。

客户op会发现哪个机房有问题,就会往数据库mysql插入一条故障机房数据。

上图里面的 idcA 对应的时间段有故障。

目前整个架构里面有M服务和D服务查询tsdb时序数据库。

在D服务里面实现了这个查询故障机房的功能,就是查询数据库里面看看那个机房有问题,如果发现用户传的查询起止时间段和mysql数据库里面的idcA故障时间有交集,那么就说明A机房有故障就去读取配置文件中idcB机房的url查询idcB机房的tsdb时序数据。

由于D服务实现了,就用M服务去查询D服务,由于D服务的可承受查询能力不行,M服务的查询压力很大,所以M服务查询D服务的时候做了一层缓存。

这缓存服务代码写的真牛逼,搞出两个线上问题。

    @Cacheable(value =  "cacheManager", key =  "#root.method")
    public String getMalfunctionStatus(long queryStartTime, long queryEndTime) 

        QueryDateDto queryDateDto = new QueryDateDto();
        String startTime = String.valueOf(queryStartTime);
        String endTime = String.valueOf(queryEndTime);

        queryDateDto.setStartTime(startTime);
        queryDateDto.setEndTime(endTime);
        String malfunctionStatus =  "";
        try 
            malfunctionStatus  = 查询D服务的数据http调用。
         catch (Exception e) 
            LOG.error( "request dashboard failed. e: ", e.getMessage());
            
        
         return malfunctionStatus;
    

缓存分析

getMalfunctionStatus 这个方法加了缓存,key是这个方法名字。假设传的参数queryStartTime:2022-05-17 10:00:00 queryEndTime 2022-05-17 12:00:00

假设这个时间段查询下游 D服务的http调用,返回是故障 状态

缓存时间失效是5分钟。

这5分钟内这个getMalfunctionStatus 这个方法返回的都是故障状态。

如果这5分钟内用户传的是参数queryStartTime:2022-05-17 12:00:00 queryEndTime 2022-05-17 14:00:00 查询时间段不一样,但是由于有缓存,这个返回的还是故障状态。

这缓存加了个寂寞。

加还不如不加。

不加起码能查询下游D服务是正确的返回结果,加了这5分钟内结果都是错的。。。

实习生给小编留大坑!

实习生牛X!

第二个坑

这个服务如果发现当前机房出现故障了。

就根据查询的下游D服务的状态发现故障了,需要切换查询机房的地址。

所以就在配置文件里面写了两个机房的地址,然后读取配置文件就行了。

由于最近用户使用了添加了故障机房,报大量接口返回500错误。

是配置文件这块切换机房的时候的没有端口。导致查询下游服务报500。

总结

之前还是对实习生太仁慈了,以后实习生的代码还是得好好看看,实习生拿着一天300的实习工资,写了一堆坑的代码,搞出两个线上问题,混了份大厂实习经历,拍拍屁股走人了,小编在这擦实习生的屁股。

难受。。。

以上是关于实习生跑路留了一个大坑,搞出2个线上问题,我被坑惨了的主要内容,如果未能解决你的问题,请参考以下文章

做个程序员真难一读者经历,培训半年,花了5万,被坑惨了

做个程序员真难一读者经历,培训半年,花了5万,被坑惨了

List中remove()方法的陷阱,被坑惨了!

poj1201(差分约束)

我被线程坑惨了!线程间的通信有毒!!!

刚入职的小菜鸡,设错了RPC超时,搞了个线上事故