基于规则的操作监视和警告（12.19）

对于能监视，ESB总线本身的性能监视以前已经写了一些文章来说明，对于SOA管理和控制，我们也很早就实现了监视和预警功能. 也就是说，您可以灵活地为单个服务或所有服务配置监视和警告策略，然后实时监视所有服务的操作，动态计算监视和警告策略是否在内存中触发，以及监视和警报实时触发.

由于监视和预警策略的存在，实际的服务操作实例数据和性能指标都在内存中，并且计算过程也在内存中，因此整个监视和预警计算过程也都在内存中完成，因此它可以保证很高的性能监控是实时的，但缺点是它消耗了应用程序服务器的大量内存资源和CPU计算资源.

第二，通过这种方式，我们目前仅配置三个指标，分别用于服务运行时间，服务运行时间和服务运行异常. 也就是说，该服务只能监视和警告这三个指标. 例如，如果所有服务的异常数量达到某个阈值，则会实时触发警告，或者指定服务的平均运行时间超过某个值.

也就是说，我们只能根据上述参数设置我们预设的服务范围，监控时间段，服务指标（次数，持续时间，错误数量），所有监控和预警策略. 从服务本身的性能分析和管理的角度来看，上述方法可以基本达到目标，但是如果对ESB服务总线本身进行性能监视和预警分析，则上述监视和预警通常是不够的.

也就是说，对服务本身的监视和警告通常不一定会导致ESB总线上出现性能问题或警告，并且ESB总线本身的性能警告也无法反映在当前的监视指标和范围中.

例如，如果对服务实例数据进行大量耗时的调用，或者总服务运行时间是源时间的倍数，则这种情况基本上会导致ESB总线资源警告或内存溢出，这是我们需要监视的内容. 现在，我们的运行时间本身并不适合基于平均值或最大值的判断.

第二，如前所述，我们当前所有的性能监视和警告均基于服务运行实例日志表，该表需要动态的实时组统计信息和计算，这会消耗大量的计算资源，并且还会影响应用程序服务器. 性能和内存使用情况.

因此，我们新的自动监控和预法应考虑以下问题:

1. 不要基于实时实例日志表进行计算，以减少资源使用并提高动态计算效率

2. 监控规则可以手动灵活配置运维体系 实时计算平台，包括动态公式化或脚本配置

3. 对于监视和预警，可以触发后续动作，例如限制直流电流或直接熔断

基于此要求，我们可以考虑基于动态规则实现自动监视和预警功能. 同时，实际的服务日志数据表不再用于基本计算表，而是更改为服务分钟中间摘要表. 分钟级别的摘要表基本上可以满足准实时数据监视的需求. 同时，类似服务的数量可以保留在分钟级别的摘要表中. KPI索引项.

对于监视规则的配置，我们可以考虑编写动态Sql进行配置，即监视和警告规则是动态Sql语句，并且实际执行是在解析动态Sql语句之后执行的. 动态Sql预警是上面提到的服务名称，业务系统，时间段，KPI索引项，成功或失败可以用作关键计算索引项.

我们以一个示例为例，例如，要监视所有服务运维体系 实时计算平台，我们需要计算每单位周期的指标计算，即服务总运行时间超过100秒，或者服务总运行时间/源时间> 10且源时间<10s，或者计算总服务运行时间/源时间> 5且源时间> 10s.

也就是说，我们的动态Sql可以写为:

从表1中选择计数（*）

whereTotalTime> 100

或（TotalTime / SourceTime> 10和SourceTime <10）

或（TotalTime / SourceTime> 5和SourceTime> 10）

计算索引值后，我们将设置特定的规则项. 规则项只是保持大于，小于，等于. 也就是说，计算出的索引值大于或小于我们设置的规则值，实时监视和警告.

对于单个服务，我们还可以灵活设置. 例如，就单个服务的数据量而言，我们现在是一个固定的约束，即只要超过10M，就直接拒绝服务消耗调用，但是如果有1000个服务，对多个调用通常是正常的超过10M的数据出现，那么现在不是时候拒绝软件包中的所有服务请求.

例如，对于QueryVendorInfoSrv服务，我们可以对MsgSize进行以下设置

从表1中选择计数（*）

whereMaxSize> 10M或Avg-MsgSize> 2M

如果此数据的总次数超过限制，我们将实时触发警报. （在这种模式下，如果使用分钟报告，则需要提前以分钟为单位计算10M以上消息的出现次数，并将其记录在分钟报告的中间表中. ）

同时，如第三点所述，在预警完成后，我们还可以触发对服务的实时更严格的数据量数据包大小约束，例如之前的20M数据包约束，但发现较大数据包并发非常大，因此实时触发器被限制为10M或更小. 但是，在这种操作下，有一点需要处理，即是否恢复或取消了触发的约束规则.

当然，基于上述动态规则，我们还可以轻松地通过单个系统观察异常情况，例如，访问业务系统是否存在问题. 不能简单地说，异常调用服务一定是业务系统的问题. 因此，我们可以观察到，如果业务系统提供的服务具有5个或更多服务，则业务系统异常发生10次以上，我们可以初步确定业务系统问题并进行实时警告. 对于这种情况，我们也很容易设置.

从（选择服务名称，从表1中的计数（错误时间）中选择计数（*），其中sysname = ERP

按服务名称分组（错误次数）> 10）

这样，我们可以计算处理索引值，然后在规则中灵活配置它.

在一个单元监视周期中，发生了多少大消息呼叫，发生了多少长时间耗时的呼叫，发生了多少异常呼叫，或者当异常比例达到一定值时，大报告文字通话达到了一定的价值，这些可以作为我们灵活配置的条件. 通过灵活的规则配置，我们可以更灵活，更有效地执行服务操作性能监视和实时警告.

本文的一些实现细节有待进一步改进，但基于灵活脚本规则动态触发预警的总体思路是可行的.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-198356-1.html