ITM 622 FP2 新增的一个有用的小功能
常有用户在收集历史数据时，并不需要所有行。比如，用户想关注，db2进程所消耗的系统资源，但如果配置了process属性组的历史数据收集，将收集所有的进程信息，一般一台主机有几十到几百个进程，绝大部分不是客户所关心的。现在好了，可以设置row filter，过滤到不需要的行。 ...
Archive for the ‘服务可用性和性能管理’ Category
ITCAM for TT 常用的troubleshooting信息
############################################## Enable arm in IBM HTTP Server ############################################## Add following red lines in /opt/IBM/HTTPServer/bin/envvars # envvars-std – default environment variables for apachectl # # This file is generated from envvars-std.in # LD_LIBRARY_PATH=”/opt/IBM/HTTPServer/lib:$LD_LIBRARY_PATH” export LD_LIBRARY_PATH # Added for TT export KBB_RAS1=’ERROR (COMP:ARM ALL)’ export KBB_RAS1_LOG=’/opt/IBM/HTTPServer/logs/ihsarm_kbb_-.log INVENTORY=/opt/IBM/HTTPServer/logs/ihs_arm.inv COUNT=10 LIMIT=32 PRESERVE=1 MAXFILES=30′; export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/IBM/ITM/li6263/tu/tusupport:/opt/IBM/ITM/li6263/tu/tusupport/32:/opt/IBM/ITM/li6263/tu/lib: export ITM_HOME=/opt/IBM/ITM ################################################## Debug armtest ################################################## Issue the following in command: export KBB_RAS1=’ERROR (COMP:ARM ALL)’ export KBB_RAS1_LOG=’/opt/IBM/HTTPServer/logs/ihsarm_kbb_-.log INVENTORY=/opt/IBM/HTTPServer/logs/ihs_arm.inv COUNT=10 LIMIT=32 ...
ITM TEMA 系统资源消耗
很多人会问这样一个问题，ITCAM所监控的MQ，OS，DB，……等等所需要部署在被监控端的Agent，对系统的资源消耗有多少，官方文档没有明确的说明，在这里我把我的理解分享给大家。TEMA的资源消耗，所指的资源消耗主要是指CPU，内存，网络，IO，主要来自两个方面： Validate Situation History Data Collection TEMA分发的的Situation的数量，Situation巡检的平率高低，Situation是否在TEMA端验证，都会给TEMA的性能开销带来很大的不同，因此不能一概而论，简单的说，Situation数量越多，巡检频率越高，需要在Server端验证的Situation，Situation验证是所要检索的表的行数越大，那么对资源开销就越高。比如表行数过多，将消耗更多的CPU。如果在Server端验证，将消耗更多的内存，和网络开销。 历史数据收集同理，如果搜集的频率高，搜集的属性指标多，那么对系统开销越大，每次搜集带来的开销主要依赖采集的方式和数据量大小，比如，DB的Agent，性能采集通过SQL，那么消耗来自SQL本身，如果磁盘性能采集，而系统有很大的磁盘阵列，那么性能开销来自list 整个磁盘阵列……等等。 当某个Agent的对资源消耗过大，比如CPU，内存消耗太多，那么我们诊断的方法是（假定不是Agent的bug带来的性能问题），逐个的取消Situation，和历史数据搜集，看看哪个带来的性能问题，换言之，如果没有负载situation和历史数据搜集，TEMA的资源消耗应该非常之小。 ...
传闻：下一代的TIP界面
传闻下一代的TIP的界面考虑基于Lotus的Mashup Center，这实在是个好消息。不过不知道计划到什么时候才能实现，如果真有其事的话。 目前绝大部分IBM软件产品的界面，只要是WEB的，多半都基于ISC，一个既不美观，也不高效的框架，Tivoli集成门户TIP基于eWAS的Portal框架，不但是管理端复用了ISC，展示层定制化部分则依赖于WebSphere 的Portal Server，每个小的数据区域通过客户化Portlet来实现，Portal技术和ISC同样的不美观，由于和ISC类似，需要在服务端wrap展示内容，因此经常为了获取少量数据而提交整个页面，并且对数据的来源也没有选择。 这些基本的问题，如果通过Mashup，几乎都可以轻易的避开，更重要的是，在定制开发层面，有大的多的灵活性。这对于IBM解决方案来说尤为重要，因为很多东西对于客户而言都只能算是半成品，加上Tivoli家族产品繁多，来源复杂，集成的需求无处不在，而mashup是看起来，把展示层面和数据提供层之间的耦合度降到最低的一种方式了。希望能尽快的看到一些进展。 同时，这是对集成商的好建议，展示层基于Mashup方式构建，非常有利于应付IT服务管理这一类的集成项目，这类项目的特点就是厂商多，标准少，产品线长，集成度不高。 IBM Mashup Center Wiki：http://www-10.lotus.com/ldd/mashupswiki.nsf ...
BAM 解决方案设想
§Business Activity（业务活动） 是指一项业务执行过程（Business Process）中，所包含到业务操作，以及这些业务操作之间的关联关系，拓扑结构，和每个操作的执行状态。 §Business Activity Management（业务活动管理） 是一套企业解决方案（Enterprise Solution），旨在为业务活动状态（status)，业务活动过程（process），业务活动交易（Transaction）提供实时信息，并对与之相关的业务应用，IT资源进行管理和关联。 BAM的结构 业务层面的监控：客户最终关心的依然是业务，包括业务的可用性，性能和操作过程，理想的情况是我们能直接让客户对于整个业务以白盒的形式呈现出来一旦业务出现故障，那么必定需要drill down来诊断故障。 应用层面的监控：一个真实的业务必定对应一个或者多个应用程序，对应用本身的监控，其实对业务最好的监控视角（如果我们无法直接的监控业务）。我们也希望应用的过程，也能以白盒呈现给客户。但现在依然不能，WRT/RRT只能最外层的终端响应时间做监控，roundtrip time，对于客户，应用依然大量的部分是黑盒子。因此，我们依赖一ITCAM for TT，但TT对客户应用容器有一些要求 容器层面的监控：有些时候，由于我们无法在应用层面做到白盒（TT最适用的场合是银行的WAS+MQ+MB+CICS的结构），因此，我们只能通过从容器的某些指标，辅助判断应用的执行。这和直接监控应用比较，当然是差一些的视角，但目前只能退而求其次。容器的哪些指标可以反映性能呢？以Siebel为例，Task相关指标就可以，如果DB，那么SQL的执行时间可以作为衡量指标之一，如果是J2EE容器，那么Servlet request的响应时间，可以作为衡量指标，诸如此类…… BAM的生命周期： ...