一家专注于做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 ...
如果假定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自启动的，在生产环境中，这些都要仔细检查，没用的都不要启。 ...
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，在开发，测试，部署所有的环节都有较多的提升。 ...
1 权限结构 详细的权限元素介绍请参看ITM User Guide 62 PDF文档，第12章节。此篇文档着重关注的是权限元素以及角色对权限元素之间的关系。 1.1 权限元素简介 在ITM62中，使用权限的有两个对象： 用户 用户组 被赋予权限，有三个对象： Permission：ITM基础功能的权限，比如对服务的起停，对Situation的定制，能否执行Query，等等。 Navigator View：ITM TEP不同的视图的访问权限控制。 Applications：对于被监控应用的控制。 以上三种属于权限资源，对这三种权限资源的是通过用户（User）和用户组（Group）来实现的。 2 赋权结构 2.1 赋权用例图 2.2 用户 针对用户，我们可以看到： 可以给用户直接赋权 用户可以属于一个或者多个组 用户将继承组所有的权限 用户不能修改继承得来的权限 2.3 用户组 针对用户组，我们可以看到： 可以给组赋权 一个组可以属于多个不同的Parent组，也可以拥有多个Child组, 但不能同时作为同一个组的Parent和Child （比如，GroupA既是GroupB的Parent，又是GroupB的Child, 这是不允许的）。原因是权限继承的时候会出现死循环递归如果互为父子的话。 不能修改来自继承得来的权限 组将拥有Parent组所拥有的全部权限 3 总结 从上面的权限元素之间的关系，我们可以看到，ITM的权限设计基本上遵循了RBAC（Role Based Access control）惯例，其中的Group就是Role的概念。对于权限的粒度，ITM只控制到了资源属性一级。比如说，一旦一个用户拥有Situation的查看权限，那么他就拥有了所有Situation的查看权限。无法针对不同的Situation进行更细粒度的控制。通常在大规模的集中部署情况下，权限会需要按照地域来划分。换言之，对于同一角色（在这里的概念是Group），不同的地域，将拥有不同的权限。在ITM 71中将实现细颗粒的授权（不确定71一定提供，但此feature已经在roadmap上）： ...
ITM缺省的职能展示实时的事件信息，在Tivoli的监控架构中，事件的处理，包括历史事件的统计和展现通常都由Omnibus来完成，如果客户没有Omnibus，ITM统一可以在一定程度上实现： 打开历史数据收集中的CCC Log 启动Situation Status Log Start这个Collection 配置后，Warehous Proxy Agent（WPA）将会在数据库中创建一个名字为Status_History的表，此表包含字段： Global_Timestamp: Status Situation_Name Managed_System Managing_System Atomize 其中需要说明的是Status字段使用单字符表示Event的状态： N = Closed D = Deleted P = Stopped A = Acknowledged E = Reopened F = Expired S = Reset 从TEP中，创建简单的Event报表： 开辟一个新的View，定制化Query为： SELECT “Status”, COUNT(“Status”) “Total” FROM "Status_History" WHERE "Status" = 'Y' OR "Status" = 'A' OR "Status" = 'N' GROUP BY "Status" 输出为： Status Total ------------ ----------- A 6 N 35 Y 138 ...