谈运维监控流程改进(8.23)

注:可以参考热力图的可视化方式来展现服务运行一周不同时段的访问情况。

对于服务性能的监控,前面谈到过服务的三个关键参数为服务运行次数并发,服务数据量,服务时长,实际上在我们对服务性能监控上,还需要增加突变监控,即什么时候服务运行数据会发生突变,那么这些突变点往往才是我们最应该关心的内容。比如一个服务运行次数从1000次/分钟,突然变好到1万次/分钟,或者说一个服务运行数据量发现突增,那么这些点我们就应该实时监控到。

对于服务运行时长的监控,我们会监控单位时间里面的平均时长,但是这里要注意,如果一个单位时间间隔里面服务运行100次,其中99次都<1秒,但是有1次运行时长100秒,那么一平均后就会使得整个服务平均运行时长很长。在这种情况下我们就需要考虑数据的分布情况和具体的置信区间,否则会影响到数据分析和判断。

对于数据量的监控也是同样的道理,我们实际并不担心某一个服务单次的数据量传输大,而是担心某一个服务持续的大数据量进行调用和传输。只有这种持续大数据传输往往才影响到OSB总线JVM内存消耗,容易导出最终的内存溢出问题。即可以制定的原则类似在连续的多个单位时间区间里面,有80%以上的场景都出现数据量大于某一个阈值,那么这种情况就必须进行监控告警。

对于当前的监控和性能分析,我们实际上缺少一个对比分析功能。具体对比分析可以是时间维度,也可以是系统维度和组织维度。通过对比分析,目的也是发现性能数据出现的各种突变和异常情况。

时间维度:本周数据和上周数据的对比,本月数据和上月数据的对比

系统维度:不同系统间消费同一个服务的对比

组织维度:不同的省份或子组织,对服务消费数据(次数,数据量,时长等)的对比分析

有了对比分析,我们更容易发现在服务提供和服务消费中出现的问题,即使发现各种服务异常消费场景,并即使对服务异常消费情况进行跟踪解决。

对于服务调用异常,应该是第一时间监控到并进行通知,其中异常包括了系统异常,业务系统异常和业务异常。对于前两种情况都应该第一时间监控到并进行告警。对于各种异常情况监控,最好的方式应该是将基于我们异常监控规则进行监控发现的所有异常都进行记录,形成每天的异常监控报表。这个报表将有助于我们分析每天的服务异常情况。

对于大屏监控,应该分为两类,一个是统计数据的汇总展示,一个是异常性能数据监控和实时告警。相对来说对于异常监控和实时告警往往更加重要,这个在设计大屏监控的时候必须考虑,即大屏监控的目的就是第一时间发现问题并反馈出来。如果能够达到这个效果,那么我们的大屏监控才真正起了作用。

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章