Tivoli developerWorks

ITM（IBM  Tivoli Monitoring），IBM从2005年并购Candle之后的第一个发布版本是6.1，在2006年，2007年上线的客户，通常使用的就是这个版本，运气稍好点的客户，是一个纯粹的ITM61的框架，运气稍差一点的，是一个ITM61和ITM5的混合框架。不要简单的认为主版本号差1，实际上是完全来自不同的公司，ITM5之前是老的基于TMF的框架，是最开始收购的那家的产品，61之后用Candle公司的OMEMAGMON框架取而代之，在分布式平台上重命名为ITM，在主机平台依然保持原始的命名：Omegamon for XXX。如果是混搭的架构，那么意味着客户需要维护两套Framework，就是两套毫不相关的服务端。 时隔2，3年，ITM61所暴露出来的问题，逐渐的被修复，而每一个新的版本推出都会伴随大量的新功能，以下我列出我认为6.1客户最为头疼，但在62X中已经解决的问题，和已经比较显著的提升点，总结了8个，对于想升级的客户做一个参考： 服务端的稳定性：虽然这是一个理所应当满足的，但直到ITM 61 FP4之后，才有些好转，服务端的稳定性不可置疑是一个改进，虽然它是一个基本的功能。 服务端的可承载能力：对于以前一个RTEMS所承载最多300来个Agent，从62开始，单独一个RTEMS承载能力可到500～1500个（只所以跨度很大，是因为不同的网络环境，Agent种类，以及事件的发生频度差异太大，通常我们按照1000个Agent做规划），这无形的节约了硬件成本。 HA（高可用）架构中Agent的回切：大量的客户由于Agent不能自动回切到Primary的TEMS，而放弃Agent的高可用配置，这样造成了架构的先天不足，而有部分客户则手工回切，这样的工作量是相当可观的，ITM621增加了参数CTIRA_PRIMARY_FALLBACK_INTERVAL，可设定回切周期。对于运维人员是个福音。 TEPS可使用Derby作为内嵌数据库：很多客户缺乏DB2的管理员，因为他们的生产环境只有Oracle，而为了TEPS不得不增加利用率很低的DB2技能学习成本。ITM622支持内嵌数据库，对于运维人员，应该是个好消息 ITM自我管理能力：以前为了保持ITM进程的可用性，不得不加一些定期检查的脚本在crontab里面，从ITM622之后，ITM自身的进程均可支持可用性自检。 Situation的验证从服务端挪到了Agent端：不是所有的，而是大部分的Situation验证分散在客户端进行，这无需太多的解释，可以想象对性能的提升。 动态阀值：以前的阀值一刀切方式，被动态阀值所取代，这样的好处对于同一个指标阀值，比如CPU使用率，对于不同的时段（半夜还是早10点），不同的机器（性能好的和坏的），不同的日子（月末出帐，月中闲置），所设定的阀值是不同的，以前的绕行方法是设定不同的Situation，现在的做法更优雅，合理，并且简便。 AgentBuilder：在此不再重复UA的毛病，如果是ITM61的用户，那么对UA应该是有恨无爱。但作为唯一的扩展接口，又不得不用之。从ITM62开始，提供一个基于Eclipse的IDE，能非常简便的开发定制化的Agent，在开发，测试，部署所有的环节都有较多的提升。 ...