SOA监控相关功能的易用性优化(2.18)

最近开始对已有的SOA管控平台的监控相关功能做易用性方面的优化，这篇作为易用性优化的简单总结。

服务运行监控和运行分析类功能，主要分为三大类， 其中一类是对服务运行问题排查用的功能，另外一类是我们做服务运行整体统计分析用的功能，还有一类是服务实时监控类的功能 。而这三类功能本身使用场景和驱动也存在差异。

对于问题排查往往是问题驱动，问题来了要马上定位分析；对于实时监控类功能是准实时的定频率监控使用，监控具备准实时和定频率的特征；而对于运行整体分析往往则用于日报分析，周报和月报分析，使用频率相对较低。对于以上三类都需要考虑易用性优化，只是关注点可能不同而已。

问题排查类功能优化

重点就是要根据用户反馈的问题提供的关键字段，实例号，时间段或者关键字等能够快速的找到具体的异常记录和异常日志。同时要确保异常记录完整，异常日志无丢失。同时对于异常问题类功能要确保异常的边界明确，即通过提供的日志能够明确判断出具体的问题究竟出再哪方，具体的日志记录是如何的。

问题排查类功能优化还需要考虑，一个是业务系统通过自服务的方式进行进行问题分析和排查，一类是由SOA云和管理人员进行问题分析和排查，这两类场景需要单独分析和处理。其次，对于问题发现后，如何触发具体的工单，方便后续的问题闭环跟踪也是必须要考虑的一个关键问题。

统计分析类功能优化

首先要做到我们做分析报表的时候需要的数据都能够通过Excel完全导出，没有数据缺失。其次对于导出的Excel数据我们能够做最小的数据加工和整理就形成我们需要的统计报表数据。

在原来的统计分析功能中，我们发现有一些功能最终查询结果出来的数据，我们在进行统计分析的时候还要人工筛选出需要纳入统计范围的数据，或者删除一些数据，这些都增加了后期处理工作量，因此这些都应该变更查询统计规则，或者增加查询条件。

举例来说对于服务运行性能监控，我们统计分析结果包括了异常服务数据，这个导致服务运行时长值明显偏大，而对于异常服务数据本身是由于发版导致的服务调用异常。那么我们就有两种处理方法，一个是配置发版周期和时间间隔，在发版周期里面不进行计算。其次就是我们可以选择是统计所有服务，还是只统计正常运行服务。

实时监控类功能

对于实时系统监控类功能，核心就是告警策略和指标的设计，以区别自动监控到的异常是真正的系统异常，否则将导致大量的异常误报。

对于人工定时监控的功能，那么重点就是如何快速的查询是否存在异常记录或可疑记录，而减少人工筛选的工作量。比如我们异常日志查询，查询出大量异常日志，但是大部分异常是不需要我们关注的，而真正需要关注的往往就会不容易找出来，这些都需要我们在监控功能优化的时候考虑如何增加快速定位的方便些。

还有一种做法是我们将我们定时监控的查询条件配置为自定义查询，固化这些查询指标，而每次只需要根据预设的查询条件进行查询和分析即可。

服务运行筛选条件很重要，我们一天的服务运行日志就上千万次，即使喜欢到1分钟都上万次的服务调用，因此必须细化查询条件，筛选方式，以方便快速的定位问题。比如我们要查看某个周期有无大数据量调用，原来只能导出特定周期服务运行实例，再人工筛选。那么考虑到易用性，这种就需要优化为增加报文量的查询条件方便我们快速的筛选异常调用类服务。

对于基准监控也是我们不断优化调整的功能，目的就是基准告警要越来越准确，减少误报和漏报的情况。

当我们能够做到我们基于特定条件查询出的基准预警结果完全不再需要人工筛选就能够分发给业务系统，那么就说明这个功能可以做到完全的自动化，不再需要人工监控和干预。

这也是我经常说到的，即：

当任何一个监控功能或稽核功能，我们通过人工监控方式不断的优化和调整监控规则和策略，当优化和调整到足够准确的时候，那么这个功能就最终自动化掉，不再需要人工干预和处理。 这个也是我们要做到服务监控运维自动化的一个必经之路。因为一开始，你很难立刻给出明确的规则定义。

方便第一时间快速的分析和定位问题，方便统计分析的时候快速的生成需要的数据和图表而少做人工处理和加工，方便基于不同关键业务场景的快速的筛选。这些就是对于监控类功能优化的重点。