当前位置：网站首页>实习生跑路留了一个大坑，搞出2个线上问题，我被坑惨了

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

2022-07-02 06:13:00 【啊码】

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

昨天线上问题

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

昨天出的一个线上问题。

监控开始报大量的异常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;
    }