Tivoli developerWorks

Archive for April, 2010

ITM TEMA 系统资源消耗

04.23.2010 · Posted in 服务可用性和性能管理

很多人会问这样一个问题,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的资源消耗应该非常之小。 ...

ITM 对云的监控案例一枚

04.18.2010 · Posted in 动态基础架构和云计算

一家专注于做ITM扩展的BP,Blue Medora,开发了一些用于管理Amazon EC2的Agent,使用这些Agent可以让用户管理和监控Amazon EC2的云基础架构,具体的功能包括:Using the Blue Medora ITM Agent for Amazon EC2 The Amazon EC2 Agent is one of our most feature rich agents yet: ITM subnoding gives extensive information on each individual instance in your EC2 environment High level views of all instances on your EC2 account Auto discovery of new or deleted instances Historical data for monitoring long ...

设计模式

04.16.2010 · Posted in 企业应用

共享一份不错的设计模式手册:下载:新版设计模式手册。描述语言是C#。 在此,有些感想和大家分享一下,通常认为,对于Tivoli不论售前咨询,还是售后服务,都似乎不太需要看起来过于贴近开发领域的设计模式的知识,其实我倒是觉得,设计模式的思维方式可以运用于任何建模的环节,当然也包括售前的架构咨询,和售后的服务的前期设计。 据我的观察,国内大部分的架构都来自“对成功案例的复制”,很少创新,其原因一部分是,对企业应用架构,企业集成架构的缺乏理解和灵活运用的能力,只能重复前人的经验,或者搭建简单的积木。此外,了解设计模式,能有助于快速的理解大型软件,因为很多组件的命名能直接反映它在架构中的位置和作用,比如常见的Adapter,Gateway,Probe,Filter,Bridge,等等,在Tivoli软件中经常见到。 ...

传闻:下一代的TIP界面

04.07.2010 · Posted in 服务可用性和性能管理

传闻下一代的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 ...