谈服务运行监控-检查和稽核(8.21)

最近用服务运行监控功能比较多，在前面博客文章里面也谈到的，主要还是用服务运行次数，服务运行时长，服务运行失败和异常，服务传输数据量等分析统计功能来分析服务当前运行状态。

服务运行异常和性能问题判断准则

什么是服务运行异常问题？实际上这个概念一开始是很模糊的，即使你开始有过一些基准定义，但是实际到了服务运行的时候你会发现更多的服务运行异常场景。比如服务调用失败仍然在没修改输入的情况下大并发异常调用，对于服务安全校验不通过仍然大并发调用，对于服务查询批量大数据，比如超过10m的大数据而且并发量很大等。

当然里面还有一些特殊的情况，比如对于服务平均运行时间并不长，比如都在1秒以内，但是会出现个别服务耗时超过5秒的情况，那么这种情况是正常还是异常，仍然需要进行分析。

还有类似一个服务大并发调用和消费，不能简单的判断为异常调用，因为这个服务本身有可能就是数据不落地的实时触发调用，只要输入和响应的报文都小，响应时间满足要求，本身是没有问题的。对于这种也需要我们人工去分析和判断，细化到具体的消费方或者细化到具体的服务上面。

刚开始我们的基准或异常判断规则不明确，这个并不要紧，但是在我们多次人工检查后，有了实际的运行数据就会进一步的细化规则并固化规则，那么这个规则就可以用到后续的检查和判断中。

面对这种场景，我们要做的就是先人工检查，然后将模糊的需要人工去判断的规则精确化和标准化，形成可以自动判断的准则，只要有了这个基准数据，那么我们就可以设置自动稽核功能，不再需要人工干预。

人工检查分析异常场景和问题-》基于数据分析细化和基准规则-》基于规则进行自动化稽核

在前面服务运行监控中谈到过，对于服务运行监控规则主要还是涉及到服务运行时长，数据量，并发量几个关键指标，这几个指标需要组合形成规则而不是单一规则。在形成了基准规则后，还需要考虑阈值的问题，即超过阈值多少就要告警后暴露问题。这个阈值可以是200%，也可以是300%，要做到可以灵活的定义。

对于基准值的设置也需要注意，往往也需要在平台正式上线并实际运行后，采集相关的服务实际运行数据来分析和定义基准值，而不是简单的根据前期的需求分析和定义。一个服务前期可以定位为响应时间<5秒，但是这个服务本身涉及到大数据量的传递或复杂业务规则的处理，即使业务系统程序做大量优化可能也很难达到这种响应要求，那么我们就需要根据实际情况来调整基准值。

有了基准值，也有了服务运行实际采集值，同时有了检查规则和触发条件则可以触发自动化稽核操作。 即首先获取服务实际运行性能数据，然后根据规则和基准值做比较，看是否满足了触发条件，如果满足条件则触发服务异常告警。

有了这个思考，可以看到对于服务告警和预警功能，我们完全可以另外做一个替代功能。

即首先对接入到集成平台的每一个服务维护基准值，即单位时间里面的基准并发数，基准平均运行时长，基准传输的数据量，基准失败次数。同时制定相应的检查和稽核规则。然后我们就可以定时的采集服务运行实际性能数据，和这个基准值进行比较，对于满足了触发和告警条件的信息进行单独的异常告警，形成异常报表。

对于异常报表可以每天生成一次数据写入到数据库，然后可以按天或按时间段，或者按系统，按服务对异常报表数据进行查询。方便分析和监控服务本身的性能问题。