ITM Situation 的性能和最佳实践
如果假定Agent没有bug，那么它在运行时的CPU和内存占用通常应该很低，对资源的消耗主要来自两个方面，一个是Situation验证，另一个就是Sampling。其中Situation是ITM告警中一个比较重要的环节，毕竟Sampling能调优的范围不多，Situation的策略将直接影响ITM的整体性能，ITM61的Situation在服务端验证，从ITM62之后，绝大部分Situation挪到了Agent端验证，这对验证的性能有非常大的提升，对TEMS也是很大的解放。即便如此，对Situation的编写，也要注意很多地方： 尽量不必要使用Group Function，也就是MIN, MAX, AVG, SUM, COUNT，这种函数。原因是这样，当配置了这些函数，那么Agent无法在采集的那一刹那，判断出是否满足Situatoin的公式条件，只能把数据传递给TEMS，在一个缺省的时间段内，把Agent连续传过来的值做平均，然后判断是否告警。这样效率肯定是很低，首先Agent自身不能验证Situatoin，一旦把验证的任务交给TEMS，那么对性能就是极大的伤害，而且低效。这里，绕行的方法很多，比如可以采集一些平均值（比如AIX OS中有些指标本省就是平均值，就利用之，不要用瞬时值，依靠ITM来做运算），或者，用连续多次，超过阀值，来告警，以避免偶尔阀值超越产生的无告警。 把最严格的Situation限制条件放到第一个，这个应该比较好理解，这样能让验证的数据量尽快的降到最小。比如，Situation有3个条件，采集的数据有100 rows，那么第一个条件导致满足的只有10条，那么后两个条件，只用面对这10条做验证了。 为重要的系统建立单独的managed System，这样能尽量的让其他的Situation减少对重要系统的干扰，在Situation tuning中可以有针对性的tuning。 尽量不要使用太短的sample interval，一旦告警的验证周期，不足以确保采集，那么必然会导致数据丢失或者告警延时。比如，很多客户轮询SOAP，N个系统，几百个SOAP，轮询下来10分钟，但是告警周期是8分钟，那么就会出这个问题。 尽量减少大数据量属性组的Situation，有的属性组返回数据量极大，最常见的就是有的系统进程数几百个，或者磁盘mount的几百块，比如Situation要检查某个进程的CPU消耗，要把所有的进程信息都获取到，然后做判断，这种情况内存，CPU，消耗都很大。需要提一下的是，从ITM622开始，进程的missing function在Agent端验证了，以前实在TEMS上。 如果需要到TEMS验证的Situation，可以考虑分散到不同RTEMS，某些情况，我们不得不考虑在Server上验证Situation，包括前面的AVG，MIN，等函数，还包括一些关联Situation，比如A发生，同时B也发生了，才告警，牵扯到不同的属性组等等，都需要到TEMS验证，这时候，考虑到压力分担道不同的RTEMS。 不需要的Situation不要启动，缺省系统有些Situation自启动的，在生产环境中，这些都要仔细检查，没用的都不要启。 ...