IBM APM 解决方案咨询

IBMTivoliAPM解决方案咨询HOBBIT2077应用系统管理的维度2应用运维管理ApplicationOperationManagement应用开发管理ApplicationDevelopmentManagement应用系统管理ApplicationSystemManagement+=应用交易管理ApplicationTransactionManagement应用基础设施管理ApplicationInfrastructureManagement应用配置管理ApplicationConfigurationManagement应用运行时管理ApplicationRealtimeManagement应用运维管理ApplicationOperationManagement应用开发管理ApplicationDevelopmentManagement应用系统管理的维度3应用运维管理ApplicationOperationManagement应用开发管理ApplicationDevelopmentManagement应用系统管理ApplicationSystemManagement+=应用交易管理ApplicationTransactionManagement应用基础设施管理ApplicationInfrastructureManagement应用配置管理ApplicationConfigurationManagement应用运行时管理ApplicationRealtimeManagement应用运维管理ApplicationOperationManagement应用开发管理ApplicationDevelopmentManagement应用系统管理应用交易管理：关注应用程序的运行，应用交易，应用交易所体现的业务功能管理应用基础设施管理：关注是应用所直接依赖的平台，如J2EE中间件，消息中间件，分布式交易中间件，数据库的管理应用配置管理：关注静态的应用系统配置信息，了解企业的业务服务，业务应用，IT基础设施之间的关系，并控制，IT基础设施变更对业务服务带来的影响。应用运行时管理：关注的是动态的应用系统在运行状态下的可用性，以及性能，涵盖感知问题，隔离故障，查找根源，修复问题4个环节应用运维管理：关注的是应用系统投产后，保证系统持续健康高效工作应用开发管理：应用系统的构建，测试与发布，并在应用开发构建环节，实现对运维环节的支撑4蓝色为客户当前关注的范围，浅蓝色为对关注范围的直接支撑应用系统运行时的问题诊断诊断方案

应用类型诊断方法相关的IBM产品，能达到的程度客户的环境基于Web的应用应用类型关注点：速度和成败监控方法产品客户环境-基于J2EE,.NET架构HTTP/S交易的响应时间业务逻辑中各步骤对响应时间，和系统资源的消耗监控HTTP层面，终端客户的感受，以及终端响应时间在网络，客户端，服务段的消耗通过专业的J2EE/.NET应用管理工具，实现对可用性，性能，以及J2EE资源的全方位管理应用日志监控ITCAMforApplicationDiagnosticsITCAMforWebResponseTimeWebLogic10onHPUX-基于SOA/WebService架构Service调用的成败Service调用的时间在ESB内驻留的时间先明确SOA架构所涉及到的相关中间件和具体的SOA架构如果SOA架构基于专有的ESB系统,通过专业的SOA应用管理工具，如果是自开发ESB系统，需要根据具体的情况监控HTTP层面，终端客户的感受，以及终端响应时间在网络，客户端，服务段的消耗应用日志监控ITCAMforSOAPlatformITCAMforWebResponseTime-其他基于Web架构HTTP/S交易的响应时间监控HTTP层面，终端客户的感受，以及终端响应时间在网络，客户端，服务段的消耗应用植入API获取更多的交易追踪信息应用日志监控ITCAMforWebResponseTime非Web应用类型关注点：速度和成败诊断产品客户环境-Client/server架构C/S通信响应时间驻留client和服务端响应时间通过应用拓扑隔离故障节点应用植入API获取更多的交易追踪信息应用日志监控ITCAMfTT（TTAPI）TuxedoBased-基于分布式的交易和消息驱动的架构批处理类型关注点：成败-所有批处理任务批处理交易是否成功应用日志监控TivoliWorkloadScheduler-运行时应用的基础设施监控—KPI的设计（OS为例）XX银行网银架构7应用开发对应用监控的支撑（样例分析）8最右侧：有4个（DSR）个人营销：8个进出个人营销（1对），进出数据库（3对）应用开发对应用监控的支撑（样例分析）-方案19应用开发对应用监控的支撑（样例分析）-方案210应用开发对应用监控的支撑（样例分析）-对比数据11应用开发对应用监控的支撑（样例分析）-对比分析12根据以上数据分析：采用方案一时，基金最新净值查询交易（纯平台）处理能力约降低10%，应用服务器CPU资源消耗增加约19%；客户信息查询交易（上主机）处理能力降低约4%，应用服务器CPU资源消耗增加约5%，网关服务器CPU资源消耗增加约1%，主机CPU消耗增加约9%.采用方案二时，基金最新净值查询交易（纯平台）处理能力约降低2%，应用服务器CPU资源消耗增加约2%；客户信息查询交易（上主机）处理能力降低约8%，应用服务器CPU资源消耗增加约3.5%，网关服务器CPU资源消耗增加约3.5%，主机CPU消耗增加约7%.方案一和方案二对比，基金最新净值查询交易（纯平台）方案一处理能力约低8%，应用服务器CPU资源消耗增加约20%；客户信息查询交易（上主机）方案一处理能力高约5%，应用服务器CPU资源消耗增加约1%，网关服务器CPU资源消耗减少约3%，主机CPU消耗低约4%.综上所述，测试交易监控采用方案二整体性能较好，应用服务器CPU资源消耗增长不明显。主机由于需要启用CICSTTAPI监控软件，导致主机CPU资源消耗均有所增加，而且方案二需要修改网关、主机外联（EMUL程序）的程序，增加了一定的资源消耗。13应用系统监控接口带来的好处对容器的依赖：通过纯产品层面的应用交易监控，极度依赖客户的应用允许与何种容器，业界对J2EE容器的管理，MQ，MB很成熟；对Tuxedo，TXSeries，.NET平台尚可；但对standalone的

native程序，缺乏有效的手段。粒度的控制缺乏灵活性：交易的端到端跟踪，涉及到颗粒度的问题，粗可以到机器与机器之间的调用，细可以到每个函数的调用，而其中的权衡，完全需要根据客户的要求来定制。在运行时，不同颗粒度之间的动态切换，也很难通过产品直接实现。业务信息的携带：对交易的监控非常必要携带其执行的业务，很多客户的交易在技术层面是成功的（比如HTTP返回码200，但标示业务执行失败），纯技术层面的监控，不能准确的识别这类错误，并且，告警信息，不能告知所影响的业务和执行此业务的客户。控制开发质量：大型的金融客户的业务系统通常来有多个来源，外部，自开发，等等。监控接口的规范，其潜在的反应的被监控系统——即应用本身，在运维时被高度关注的执行环节，监控接口实现的位置，可一定程度统一来自不同开发团队的开发质量。Source: Ifapplicable,describesourceorigin对应用交易追踪的目的是精确的定位交易执行发生问题的位置14应用系统监控接口的实现原理通过在交易的开始，结束，外联，获得响应等关键位置，通过调用API（IBM的实现是TTAPI）向外抛出事件，通过一个服务集中汇聚，分析这些事件，形成交易拓扑，响应事件，交易执行成败的关键指标。Source: Ifapplicable,describesourceoriginTTAPITTAPITTAPITTAPITTAPI的事件1516应用系统端到端实现效果Source: Ifapplicable,describesourceorigin17应用系统端到端实现效果

（XXBANK案例）Source: Ifapplicable,describesourceoriginProcedureAccessOpStep是CTP中执行存储过程的opstep别名。ORACLE*是在op中定义的oracle存储过程别名。8OC10300是DSR网关调用的交易名TTAPI所收集的事件18TTAPI所支持的平台19支持的编程语言：

CC++EnterpriseCOBOL(z/OS®only)EnterprisePL/I(z/OSonly)IBMHighLevelAssembler(HLASM-z/OSonly)Java1.4and1.5支持的主机环境：C,C++andJavaapplicationsrunningin64bitmodeonz/OSCandC++XPLINKandnon-XPLINKprogramsonz/OSCandC++programsstaticallyanddynamicallylinkingTransactionTrackingAPICOBOLandPL/IprogramsstaticallylinkingTransactionTrackingAPI20应用系统监控接口对应用系统带来的影响对开发的工作量的影响：开发团队需要额外的工作量，来植入监控的代码，比如交易开始，调用OnTransactionStart(),交易结束，调用OnTransactionFinished()，外调服务，调用OnTransactionOutbould()，

等等，增加工作量的大小，取决于监控的颗粒度。对应用性能的影响：在一个进程内，初始化一个TTAPI的队列，进程初始化的过程，对TTAPI初始化，需要花费30~70毫秒（依据不同机器的性能而定），一次性初始化结束后，交易调用事件发送事件消耗约为0。对资源的消耗：根据大型银行测试结果，服务器CPU增加约2%。Source: Ifapplicable,describesourceorigin业务系统场景（应用系统监控的位置）21业务系统应用系统服务器系统存储系统网络系统LinkedDatafor

Monitoredresource

TopologyDelegated

Dialogs服务拓扑Service

Topologies(DEPENDENCIES)(entiretopologynotshown)Topologyresources

linkedto

monitoredresources业务系统管理

BusinessSystemsManagement问题管理Manages问题树ProblemTreeManages部署或者自动发现ManagesProblemslinkedtoservicetopology业务系统的依赖层次关系22业务系统

ServicesHealth应用系统

ApplicationsHealth主机服务器系统

ServersHealth存储系统

StorageVolumesHealth中间件系统

MiddlewareHealth(TPCServiceProvider)Availibility(up/down),CapacityUtilizationPerformace(reponsetimeinms)(ITMServiceProvider)Availibility(up/down)Memory,CPU,DiskUtilizationProcessorQueueLength(ITMServiceProvider)

Availibility(up/down)Middlewaretype(db,appserver,etc)Cachehits/misses,Connectionwaittime(ITCAMServiceProvider)

Availibility(up/down)Userreponsetime(ms)Numberofconcurrentusers(TBSMServiceProvider)Availibility(up/down)KeyPerformanceIndicators一项业务服务依赖一个或者多个业务应用一个业务应用，依赖一个或者多个中间件系统，比如，各种中间件，数据库各种中间件，数据库，依赖承载他们运行的主机和服务器服务器依赖于与后台的一个或者多个存储资源门户界面SolutionPortal(TIP)23监控整体架构图IBMConfidential自定义扩展页面LOBDashboards,ITOperationsDashboards,AppHealthDashboard,IsolationPageetc.DLAs集中事件平台OmnibusEventsITCAMforTransactionsITCAMforApps/ADITMforVE事件转发导入的IT基础设施事件丰富引擎ImpactITM监控框架IBMTivoliMonitoringTADDM基础设施依赖自动发现服务模型关联事件关联ITMforVEDashboardsTBSM(ServiceAdmin)Omnibus(AEL)TEPTADDMUI上下文关联打开业务服务管理TBSMServiceModelServiceStatus事件丰富在TIP中打开发现的IT基础设施数据仓库TDW通用报表引擎TCRTCRReportsSmartDeploymentDeploymentofSoftwareStack+Gluecode+TIPPages+AutomatedconfigurationCURIProvider历史数据ITDS单点登陆SSOSSOSSO网络管理ITNMITNPMITNCM事件关联IT基础设施应用运维和应用开发的集成24DevOps是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作应用系统管理规划路径25应用系统管理未来规划路线26提高收益高中低慢中快提高的时间顺序应用系统管理路线图–优先级应用配置管理应用基础资源的监控应用交易管理应用开发和应用运维集成应用与业务服务关联分析通过API植入进行交易追踪现有的系统，和应用系统管理位置27现有自开发系统，交易关系梳理工具。Omnibus事件集中管理平台。EventConsolidationOVO+OMS

监控了部分系统资源，如OS,DB。OS/DBMonitoring实现时间表（这是XX的例子）第一阶段（2012年）应用交易管理：实现交易层面监控，了解业务运行的质量应用基础设施管理的完善：补充OVO未能覆盖到的重要的应用基础资源监控应用系统API植入的尝试：挑选出典型的应用系统，考虑API植入的方式实现对个性化系统的监控第二阶段（2013年）推广：在第一阶段的基础上推广和完善交易管理，将最佳实践覆盖更多的应用系统（迭代）应用基础设施配置管理：应用基础设施的配置管理（新增）关联应用系统和业务服务，实现面向业务服务的管理：实现交易层面监控，了解业务运行的质量（新增）第一阶段（2014年）推广：在第二阶段的基础上推广和完善交易管理、和业务服务管理，将最佳实践覆盖更多的应用系统（迭代）系统运维和系统开发的集成管理：尝试系统开发和运维的整合⋯⋯（新增）28蓝色为XX银行当前关注的范围，浅蓝色为对关注范围的直接支撑29客户需要认真考虑的因素IT和企业的关系IT