ITM 622 FP2 新增的一个有用的小功能
常有用户在收集历史数据时，并不需要所有行。比如，用户想关注，db2进程所消耗的系统资源，但如果配置了process属性组的历史数据收集，将收集所有的进程信息，一般一台主机有几十到几百个进程，绝大部分不是客户所关心的。现在好了，可以设置row filter，过滤到不需要的行。
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 PRESERVE=1 MAXFILES=30′;
Then go to ihsarm_kbb_ log
#######################################
Enable arm in plugin
#######################################
Set “armEnabled=”true” in /opt/IBM/HTTPServer/Plugins/config/IHS1/plugin-cfg.xml
#################################################
Starting T3 is essential
#######################################
Since 7201, we have to start T3 before TU to get ARM data because ARM profile is stored in AMC need to be downloaded before runing
######################################
Check arm is loaded
######################################
[root@itcamapp WebSphere]# lsof -p 27356 | grep -i arm
httpd 27356 root mem REG 253,0 21982068 1984031 /opt/IBM/ITM/li6263/tu/tusupport/libarm4.so
#######################################
kbb lib debug
######################################
Is IHS loading “libkbb.so”?
If for whatever reason the log file can’t be created, RAS1 will default to logging to stdout. So check the IHS stdout log, and see fi anything else is going in there.
If you’re really keen to get logging, you can set an environment variables to see why RAS1 logging isn’t working:
CYTA_LOGGER_DEBUG=1
This will log a few lines about loading the loggers to stdout.
######################################
Plugin log
######################################
/opt/IBM/HTTPServer/Plugins/logs/http_plugin.log
#######################################
Determine the process environment
#######################################
/proc/<pid>/environ
########################################
Configure the MQ API Exit
########################################
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.csqzal.doc/fg14130_.htm
#######################################
Determine the ttapiexit
#######################################
Turn on logLevel=debug in /opt/IBM/ITM/li6263/th/config/ttdcmqexits.cfg, go to the log: itcamapp_th_mqexits.log
TTAPI called by MQ Exit API, and put the ttapi event to file: /opt/IBM/ITM/li6263/th/queues/TTDC_MQ_IPC_QUEUE,
TTDC_MQ_IPC_QUEUE is working as a pipe for th to pipe the events to TEMS
#######################################
Determine the th problem
#######################################
/opt/IBM/ITM/li6263/th/config/ttdcproxy.cfg,
logLevel=debug
#######################################
Stitch WAS-> MQ
#######################################
1.duplicate the J2EE Default profile and name the new profile as “J2EEMQ”
2.edit the J2EEMQ profile, enable checkbox “MQ” and remove the “*”
Apply the new profile to the DC
#######################################
Enable Tomcat in TT
#######################################
Add following in DCHOME/runtime/platform.node.server/custom/toolkit_custom.properties
com.ibm.tivoli.itcam.dc.ttapi.enable=true
com.ibm.tivoli.itcam.dc.ttapi.ttas.transport=tcp:itcam.localdomain:5455
Add following in DCHOME/runtime/platform.node.server/dc.properties
com.ibm.tivoli.tt.api.libname=dc_ttapi
写给甲方
在乙方工作的这段时间，感触更多的却是甲方。以下是个人的一些感受，和碰巧到访的甲方同仁共享：
- 不要迷信品牌。品牌能为他的质量提供多大的保障？我觉得只有50%，另50%需要你自己的来判断，尤其是面对当一家做的范围很广企业。
- 要自己去思考。找几个大的供应商来讲讲，然后拼凑一把，所谓，博取众家之长，实际上，你会发现，其实众家的目的都是一致的。就像，狐狸诱因乌鸦投票，乌鸦开口说“普京”，结果肉掉到了狐狸嘴里；但乌鸦如果开口说“梅德韦杰夫”，肉还是掉到狐狸口里。其实乌鸦可以不投票。
- 成就客户。其实是，你成就我的口袋，我就成绩你的业绩。千万别以为，你成就了我的口袋，我就一定会成就的你的业绩。只不过，很多国企，一旦成交，就不得不承认“我确实成就了你的业绩”。
- 客户案例。没有人希望做白老鼠，第一个吃螃蟹，但最大的风险不是没有成功案例，而是轻易的相信所谓的成功案例。并且用成功案例取代自己的思考和判断。
- 自己负责。没有谁会替你负责，最终也是“流程”负责，除非你用钱来换特例。但这样做实际上是不划算的。
- 专家。其实很多专家，和我们从电视里面看到的那些“专家”是一样的，不管是否真懂，都不妨碍他用万分肯定的语气描述给你。这不是专家的错，他们要生存，你得学会自己判断，如果你愿意花1个小时Google一下，那么你会发现你也是专家。
- 必要的苛刻。如果你太nice，太善良，乙方不但价格上宰你一刀，还给你配不好的售后服务人员，同时还把你做成成功案例。
浪潮之巅系列
Google 研究院 吴军的作品。非常不错的一部IT史，融技术性，趣味性，知识性于一体，让普通人也能体察到技术与市场，乃至生活的脉搏。
目录：
- 浪潮之巅第一章 帝国的余辉（AT&T)（一）：百年帝国
- 浪潮之巅第一章 帝国的余辉（AT&T)（二）：几度繁荣
- 浪潮之巅第一章 帝国的余辉（AT&T)（三）：利令智昏
- 浪潮之巅第一章 帝国的余辉（AT&T)（四）：外来冲击
- 浪潮之巅第二章 蓝色巨人（IBM）（一）：赶上机械革命的最后一次浪潮
- 浪潮之巅第二章 蓝色巨人（IBM）（二）：领导电子技术革命的浪潮
- 浪潮之巅第二章 蓝色巨人（IBM）（三）：错过全球信息化的大潮
- 浪潮之巅第二章 蓝色巨人（IBM）（四）：他也是做（芯）片的
- 浪潮之巅第二章 蓝色巨人（IBM）（五）：保守的创新者
- 浪潮之巅第二章 蓝色巨人（IBM）（六）：内部的优胜略汰
- 浪潮之巅第三章 “水果”公司的复兴 （乔布斯和苹果公司）（一）：传奇小子
- 浪潮之巅第三章 “水果”公司的复兴 （乔布斯和苹果公司）（二）：迷失方向
- 浪潮之巅第三章 “水果”公司的复兴 （乔布斯和苹果公司）（三）：再创辉煌
- 浪潮之巅第三章 “水果”公司的复兴 （乔布斯和苹果公司）（四）：大难不死
- 浪潮之巅第四章 计算机工业的生态链（一）：摩尔定理（Moore’s Law）
- 浪潮之巅第四章 计算机工业的生态链（二）：安迪-比尔定理 （Andy and Bill’s Law）
- 浪潮之巅第四章 计算机工业的生态链（三）：反摩尔定理 （Reverse Moore’s Law）
- 浪潮之巅第五章 奔腾的芯（英特尔—Intel）（一）：时势造英雄
- 浪潮之巅第五章 奔腾的芯（英特尔—Intel）（二）：英特尔摩托罗拉之战
- 浪潮之巅第五章 奔腾的芯（英特尔—Intel）（三）：指令集之争
- 浪潮之巅第五章 奔腾的芯（英特尔—Intel）（四）：英特尔和 AMD 的关系
- 浪潮之巅第五章 奔腾的芯（英特尔—Intel）（五）：天步艰难
- 浪潮之巅第六章 互联网的金门大桥（思科）（一）：好风凭借力
- 浪潮之巅第六章 互联网的金门大桥（思科）（二）：好风凭借力（续）
- 浪潮之巅第六章 互联网的金门大桥（思科）（三）：持续发展的绝招
- 浪潮之巅第六章 互联网的金门大桥（思科）（四）：竞争者
- 浪潮之巅第七章 硅谷的见证人—惠普公司（一）：昔日硅谷之星
- 浪潮之巅第七章 硅谷的见证人—惠普公司（二）：争议的生死抉择
- 浪潮之巅第七章 硅谷的见证人—惠普公司（三）：最有争议的CEO
- 浪潮之巅第七章 硅谷的见证人—惠普公司（四）：亚洲制造的冲击
- 浪潮之巅第七章 硅谷的见证人—惠普公司（五）：峰回路转
- 浪潮之巅第八章 没落的贵族—摩托罗拉（一）：二战的品牌
- 浪潮之巅第八章 没落的贵族—摩托罗拉（二）：黄金时代
- 浪潮之巅第八章 没落的贵族—摩托罗拉（三）：基因决定定理
- 浪潮之巅第八章 没落的贵族—摩托罗拉（四）：铱星计划
- 浪潮之巅第八章 没落的贵族—摩托罗拉（五）：全线溃败
- 浪潮之巅第八章 没落的贵族—摩托罗拉（六）：回天乏力
- 浪潮之巅第九章 硅谷的另一面（一）：成王败寇
- 浪潮之巅第九章 硅谷的另一面（二）：嗜血的地方
- 浪潮之巅第九章 硅谷的另一面（三）：机会均等
- 浪潮之巅第九章 硅谷的另一面（四）：硅含量不断降低
- 浪潮之巅第十章 短暂的春秋——与机会失之交臂的公司（一）：太阳公司之昔日的辉煌
- 浪潮之巅第十章 短暂的春秋——与机会失之交臂的公司（二）：太阳公司之错失良机
- 浪潮之巅第十章 短暂的春秋——与机会失之交臂的公司（三）：太阳公司之历史的回放
- 浪潮之巅第十章 短暂的春秋——与机会失之交臂的公司（四）：Novell 公司
- 浪潮之巅第十章 短暂的春秋——与机会失之交臂的公司（五）：网景公司
- 浪潮之巅第十章 短暂的春秋——与机会失之交臂的公司（六）：Real Networks
- 浪潮之巅第十一章 幕后的英雄—风险投资（一）：风投的起源
- 浪潮之巅第十一章 幕后的英雄—风险投资（二）：风投的结构
- 浪潮之巅第十一章 幕后的英雄—风险投资（三）：风投的过程
- 浪潮之巅第十一章 幕后的英雄—风险投资（四）：投资的决策和公司的估价
- 浪潮之巅第十一章 幕后的英雄—风险投资（五）：风投的角色
- 浪潮之巅第十一章 幕后的英雄—风险投资（六）：著名的风投公司
- 浪潮之巅第十二章 信息产业的规律性 （一）：70-20-10律
- 浪潮之巅第十二章 信息产业的规律性 （二）：诺威格定理
- 浪潮之巅第十二章 信息产业的规律性 （三）：基因决定定理
- 浪潮之巅第十三章 高科技公司的摇篮 — 斯坦福大学（一）：充满传奇的大学
- 浪潮之巅第十三章 高科技公司的摇篮 — 斯坦福大学（二）：硅谷的支柱
- 浪潮之巅第十三章 高科技公司的摇篮 — 斯坦福大学（三）：纽曼+洪堡的教育模式
- 浪潮之巅第十三章 高科技公司的摇篮 — 斯坦福大学（四）：创业的孵化器
- 浪潮之巅第十四章 科技公司的吹鼓手 — 投资银行（前言）：有幸见证历史
- 浪潮之巅第十四章 科技公司的吹鼓手 — 投资银行（一）：华尔街和美国的金融体系
- 浪潮之巅第十四章 科技公司的吹鼓手 — 投资银行（二）：著名的投资公司
- 浪潮之巅第十四章 科技公司的吹鼓手 — 投资银行（三）：科技公司的上市过程
- 浪潮之巅第十四章 科技公司的吹鼓手 — 投资银行（四）：成也萧何、败也萧何
- 浪潮之巅第十四章 科技公司的吹鼓手 — 投资银行（五）：华尔街与微软、雅虎和 Google 的三国演义
- 浪潮之巅第十五章 成功的转基因（一）：从木工厂到手机之王（诺基亚 Nokia）
- 浪潮之巅第十五章 成功的转基因（二）：道琼斯的常青树（3M）
- 浪潮之巅第十五章 成功的转基因（三）世界最大的联合体（GE）3.1 百年扩张，从有线电到无线电
- 浪潮之巅第十五章 成功的转基因（四）世界最大的联合体（GE）3.2 从实体经济到金融
- 浪潮之巅第十五章 成功的转基因（五）世界最大的联合体（GE）3.3 领袖的重要性
- 浪潮之巅第十六章 印钞机——最佳的商业模式（一）
- 浪潮之巅第十六章 印钞机——最佳的商业模式（二）第一节 Google 的广告系统
- 浪潮之巅第十六章 印钞机——最佳的商业模式（三）第二节 Ebay和亚马逊的在线市场
- 浪潮之巅第十六章 印钞机——最佳的商业模式（四）第三节 戴尔的虚拟工厂
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的资源消耗应该非常之小。