业务监控管理方案建议书.docx

业务监控方案建议书业务监控方案建议书中国惠普有限公司2020年2月29日第 25 页 共 25 页n 文档属性文档属性内容项目/任务名称项目/任务编号文档名称文档版本号V X.X文档状态初稿/修订/终稿文档编写完成日期n 文档变更历史清单文档版本号变更日期修改人备注目 录目 录3业务监控解决方案41.1 解决方案功能模块41.1.1 主动式用户体验管理(BPM)及展现 产品架构及部署 主动式用户体验管理思路 展现平台（Dashboard）71.1.2 被动式用户体验管理(RUM) 模块概述 产品架构及工作原理 监测分析报告141.1.3 问题诊断(Diagnostics) 模块概述 产品特点与功能19业务监控解决方案1.1 解决方案功能模块1.1.1 主动式用户体验管理(BPM)及展现 产品架构及部署模块概述BPM全称Business Process Monitor，是业务可用性中心中一个模块，用于主动式用户体验管理。它是目前业界最出色的以业务为核心的应用监控方式，可以很好的填补目前运维管理中心在这方面的管理空白。从原理上说，HP的BPM采用了脚本技术来模拟最终用户对业务应用的访问，从而获得了业务应用系统在最终用户一端体现出的可用性和性能，类似的脚本技术在HP另外一个久负盛名的产品LoadRunner中也得到了使用，从这一点上我们可以看出BPM在技术上是十分成熟的。HP业务流程监控主要用来对关键业务进行主动监控。实时模拟和监测用户对包括SAP、Oracle、Peoplesoft、Siebel、终端模拟和Web在内应用系统的访问，这也是HP与其他厂商在应用监控上的主要区别之一。HP的业务流程监控可以从不同的地点进行监控，所以运行维护人员就可以在一个负载比较大的应用系统中精确的知道每个地点的性能情况。同时，如果用户在应用测试阶段已经采用了LoadRunner或QTP的话，HP还可以在对生产环境进行监控时重用测试过程中的脚本，从而对现有投资构成保护。HP业务流程监控的工作步骤：第一步 代表关键业务交易情况的最终用户动作被一个脚本记录下来第二步 这些脚本被安装在不同位置的监控代理上，这些不同的位置代表了几个不同的用户比较集中的区域第三步 这些交易按照预定的时间间隔，典型情况是15分钟，在不同的地点被执行。当发现可用性故障时，它会捕捉错误情况，从而使得运维人员确切地知道交易为什么会失败第四步 诸如交易响应时间和可用性这样的性能数据通过HTTP或HTTPS传送到HP应用管理控制台上。下图是典型的BPM部署架构：产品部署的关键是选择Business Process Monitor的部署位置和数量，这部分决定于被监控业务的类型。如典型的外网公众业务的用户通过公网来访问业务应用，所以通常监控外网业务的Business Process Monitor就应该部署在公网的环境中来准确获取相同环境中的用户使用感受；而对于内部的业务来说，Business Process Monitor也应该部署在企业内部的网络环境中。业务流程监控是一种主动监控方式，它依靠驱动一定的脚本来模拟最终用户对应用的访问，并对应用的返回信息进行分析从而得到应用在最终用户端体现出的可用性和性能。因此，针对业务流程监控，相应的需要准备相关的真实业务数据，如交易帐户、客户信息等，以完成这种模拟最终用户的业务操作。同时，针对不同应用监控的需求和应用现状，对业务种类的选择本着如下三个原则：业务系统中关键性的业务种类，如存取款交易业务系统中业务量比较大、操作频繁的业务种类，如各类帐务查询交易业务系统中性能明显比较差、而且对系统总体的性能影响比较大的业务种类，如个人储蓄的中间业务等根据业务系统的部署模式和业务系统的访问情况通常可以先在总部建立相应的应用监控的框架，随后再在各级地市部署监控网点，建立在总部进行中心管理、各地市级营业网点监控部署的架构。这里可以简单举一个电信的实施案例：在某省移动BOSS业务可用性管理建设中，根据业务需要，业务流程监控选择监控BOSS综合营帐系统中一些关键业务，如装机业务、收费业务、客户资料查询业务、业务变更等。被监控的网点包括全省11个地市，每个地市选取3个被监控营业网点。同时，在BOSS综合营帐系统为这些业务的应用监控准备了相关的一系列业务数据，如移动手机号码、客户资料等，这些数据只用于业务监控，不用于正常的营业厅业务，同时在系统的内部进行了相关的帐务处理，解决了因应用监控所带来的帐务问题。 主动式用户体验管理思路现有的系统监控工具采用的是一种以IT系统架构管理为基础、自底向上的管理方法，这种方法存在着固有的不足，会导致管理手段和管理目标的背离，典型的现象是一线业务人员可能埋怨业务系统性能与可用性很差，但是运维人员事先却毫无觉察，相关的管理系统上也没有反映。原因在于系统架构的监控不能反应出业务层面的运行状况。比如在系统架构层面，我们可能看到数据库、主机、网络等运行正常，但业务上可能一线操作人员已经感觉到业务处理很慢，甚至无法交易，原因在于可能系统架构各个单点上的性能没有问题，但他们联系一起形成业务的上层处理，就会反应出各个系统部件的相互操作的性能问题，而这种性能问题将反应在业务层面，如业务处理很慢，甚至不可用。主动式用户体验管理建设正是要求突破以往的思路和手段，采用以业务应用为核心，自顶向下的方法对业务系统的可用性进行管理，即管理的出发点或最初的着眼点由支撑业务应用的系统架构变成业务应用或者服务本身。这种最终用户的使用角度来看待业务系统的监控与管理，它的监控数据来源于最终用户，包括一线业务操作人员等，来源于最终用户对业务系统的真实体验，通过在被监控的业务网点模拟真实用户的业务操作，得到业务系统的性能和可用性的监控数据。在这样的监控模式中，管理人员可以首先查看一个业务应用视图，这个视图描述当前关键的业务处理流程是否都能正常完成各自的功能，如客户存取款交易、客户资料查询等；同时，HP业务可用性管理系统具备724的业务监控管理能理，无论当前是否有营业员或客户真的在进行业务操作。这个业务应用视图可以作为被管理业务运行状态监控和故障解决流程的起点，能够展现出每个业务应用处理是否能正常工作，它们的性能是保持稳定还是在恶化。通过这种以业务为中心的管理流程，业务人员和运维人员可以更好的结合起来提高工作效率，对业务系统可用性进行优化。 展现平台（Dashboard）主动式用户体验管理的前端展示平台是HP业务可用性中心的Dashboard，它使用图形的方法展示了企业业务系统的各个关键业务流程、各个IT资源组成部分、和他们之间存在着各种联系，通过实时的显示，管理人员就可以实时的得到从最终用户视角看到的关键业务流程的可用性和性能响应状态。企业各个部门的管理人员，如IT部门、业务部门的管理人员可以通过这个统一的平台进行以业务为中心的性能管理。在管理控制台Dashboard的顶部视图中，每个节点都有状态，状态通过不同的颜色来表示，缺省情况下绿色表示正常、黄色表示警告、红色表示错误。状态是通过应用系统的响应来判断的，缺省情况下一个具体的交易有两个相关的阀值，当应用的响应时间小于第一个阀值时，交易的状态为正常；在两个阀值之间时交易的状态为警告；大于第二个阀值时交易的状态为错误。每个节点的状态（除了叶子节点）都由它的子节点中状态最差的子节点决定。如上图所示，在上海电信的业务监控系统中，通过顶部视图可以直观的、实时的了解其客户关系管理系统的运行状况。可以了解到电话新装、宽带改性能、取消营销活动业务的实时性能状况和可用性情况，同时其相应的各个业务步骤的性能状态也直观的以树状结构反映出来。点击在每一个节点上可以了解其具体信息。如电话新装业务，我们看到当前的运行状况良好，其交易响应时间是27秒，设定的阀值是正常状态45秒和70秒，因此其目前是正常状态，节点为绿色。其业务可用性设定的阀值为90%、70、50、30四个级别，目前电话新装业务的可用性为100，所以其可用性状态也是绿色正常状态。如下图所示。又如宽带改性能业务，我们看到其当前的运行状况为红色警告状态，具体反映在其生产订单业务步骤的响应时间是12.5秒，设定的阀值是正常状态8秒和12秒，超过设定的阀值，节点为红色警告状态，并且其父节点宽带改性能业务当前也是处于性能比较差的红色警告状态。而其业务可用性为100，所以其可用性状态是绿色正常状态。如下图所示。下图示例是另一种更加细化的管理视图，能够实时展示客户关系管理系统的关键业务流程，例如新装、取消营销业务等等。管理员可以按照表示性能故障的“红线”由顶层向底层迅速进行挖掘。我们看到通过这个Dashboard展示平台可以使业务部门的管理人员拥有了一个高层次的业务流程的性能视图，通过视图可以观察受到影响的业务流程以及故障的具体内容。管理控制台同时使企业的IT部门的管理人员拥有了一个迅速查错的视图，管理员只要移动鼠标、向下挖掘或查看服务水平就可以迅速获得包含详细信息的趋势或影响报表。通过Dashboard展示平台，结合主动式用户体验管理，可以进行以下有效的管理：对关键的业务种类进行主动监控，如24x7的最终用户感受，及时了解系统的业务运行状况；先于业务操作人员发现应用故障，及早进入故障排除工作；将业务性能数据在统一的视图中表现，并为他们建立起相互的对应关系。使得业务部门和IT部门之间的沟通有了统一的语言和统一的交流界面，变得简单明了。1.1.2 被动式用户体验管理(RUM) 模块概述RUM全称Real User Monitor，是业务可用性中心中一个模块，用于和BPM互补，进行被动式用户体验管理监控。RUM(Real User Monitor)提供了真实的使用状况监测，可以24x7每天不间断的监测，可以从使用者的实际操作状况，侦测出目前的反应状况是否有变差，甚至可以监测到使用者使用到有问题的网页在哪里。RUM主要是针对网络上的Web 流量进行监测，在监测的模式上十分类似 Sniffer工具的监测方式，主要是透过封包分析的方法来监测使用者在操作Web交易时的效能状况。在实际的应用上，RUM是属于Server端的监测模式，所以并不需要在客户端部署监测点，如此一来只需要监测数个特定的入口网络，即可达到全面性的监测。透过所分析的数据，所显示的即为每一个真实的使用者的操作状况，在这当中可以追踪到所有使用者的反应时间与可用率，以及追踪实际的业务流程状况。 产品架构及工作原理1. 工作原理在目前规划的网络架构中，使用者透过因特网或是内部网络来进行相关的业务流程操作，所有的使用者不论是从何处连结上网络，最终都是会透过共同的网络路径存取到后端的业务系统。所以在监测的模式上，所采用的监测模式为非干扰式(Non Intrusive)监测，RUM只需要在入口网络的Core Switch(网络交换器)上设定Port Mirror(网络端口镜射)，将被监测的网络流量复制一份到另外一个Switch Port，无须在Server上安装任何的代理程序，即可分析出使用者的操作效能状况。2. 产品结构RUM的主要架构当中包含了三个主要的组成组件，包括了RUM Engine、Probe、MySQL数据库，其所负责的功能分别如下所描述： RUM Engine主要是负责收集来自Probe所收集到的资料，并且在将这些资料依据BAC Server的End User Management Administration所给予的定义加以重新整理与组合。RUM Engine会将所收集到的page、transaction、end-user、server等数据加以取样整理，然后再传送到Gateway Server( BAC Server)，再依据所设定的告警、报表与仪表板(Dashboard)的项目加以分类建立。透过这样的方式，透过RUM Engine的数据分类，可以降低Probe传递大量分析的数据到BAC Server上所会造成的流量问题，并可以提升对现行使用者的分析效率。 Probe通常将会依据重要应用系统的所在区域安装Probe来监测使用者的实际效能状况，所安装的数量可依实际架构来设计。由于Probe是介接在交换器(Switch)上，透过封包镜射的方式来得到数据，所以并不会对实际的网络产生任何的影响，Probe主要的监测对象为网络服务器(Web Server)，当使用者的流量通过交换器(Switch)时，透过封包镜射，Probe就可以收集到使用者对网络服务器(Web Server)进行要求(Requests)与响应(Response)的相关数据，所以Probe就会看到所有使用者的IP Address与网络服务器(Web Server)之间的互动状况。 数据库其主要是负责存放RUM Engine尚未传递到BAC Server的数据，可以在网络有发生暂时性中断时，依旧可以保存所有的分析数据。另外数据库也会存放RUM Engine的相关配置与设定数据。 监测分析报告RUM所提供的监测数据上，除了可以直接的监测到重要网络应用系统的效能与可用性报告，并且可以更进一步监测到细部的数据，可以提供的监测报告如下： Global StatisticsGlobal Statistics提供网页点击次数统计，可以将指定的网页定义为管理者所熟悉的业务流程名称，便可以了解相关的业务画面被执行的次数，例如：Login。 Page Summary网页的分析数据(Page Summary)，可以显示该网页的相关数据包括了： Availability：可用率 Page Time：下载(Download)时花费在客户端的所有时间 Server Time：下载(Download)时花费在服务器端的时间 Total Hits：所有的用户点击次数 Page Size：网页的下载资料量 Average Number of Components：该网页的平均组件数量从Page Summary另外还可以分析到更进一步的组件执行时间分析，当察觉服务器处理时间过长时，管理者可透过页面内Diagnostics组件分析诊断功能，深入了解服务器内之活动行为，其内容信息包含使用对象、程序执行之方法(Method)及数据库语法(SQL statement)。 Transaction Summary交易数据分析(Transaction Summary)，可以针对所设定的交易项目提供监测，例如对Login的交易动作，可以分析的数据包括有： Availability：可用率 Total Time：所有的下载(Download)时间 Net Time：下载(Download)时花费在网络的时间 Server Time：下载(Download)时花费在服务器端的时间 Runs：所有的执行次数 Transaction Size：交易的大小 End User Summary使用者数据分析(End User Summary)，可以设定对特定的使用者监测，可以显示出该使用者的数据包括有： Location：使用者的所在地(由管理者设定对照) Latency：网络延迟时间 Available Page Hits：有效的网页点击次数 Unavailable Page Hits：无效的网页点击次数 HTTP Traffic：HTTP流量 HTTPS Traffic：HTTPS流量 Server SummaryServer Summary可以显示被RUM监测的Server其相关的数据数据，包括有： Server Name：服务器名称 IP Address Server Availability %：服务器的可用率 HTTP Traffic：HTTP流量 HTTPS Traffic：HTTPS流量 Hits：点击次数 Component Hits：网页组件点击次数 Component Causing Server Errors：因网页组件所引起的服务器错误次数 Session AnalyzerSession Analyzer报告可以提供管理者，所有应用系统(Application)与使用者之间的通话(Session)纪录。在预设的模式当中，RUM并不会去将所有的通话记录加以分类，除非是透过End User Management Administration的设定，RUM才会开始去纪录特定应用系统(Application)与使用者之间的通话并且加以分类，其它没有设定的应用系统则会统一定义为Engine的名称。管理者还可以在针对单一笔的Session加以深入分析，其所包含的每一笔session纪录。Session Report可以显示的信息包括有： Active：该session是否尚有持续的再进行中 Application Errors：显示在该段Session中所发生的应用系统错误的统计数量：Duration ：Session持续在进行的时间长度 End User：显示终端用户的名称或是IP Address End User Group：透过End User Management Administration所定义的群组名称 Events：显示在进行Session的过程当中所遭遇到的事件数量统计 HTTP Errors：显示在进行Session的过程当中HTTP所遭遇到的事件数量统计 Page Hits：显示在每一个Session网页的点击次数统计 Slow Pages：显示在每一个session中page time执行时间过慢超过警戒门坎值的数量 Start Time：显示该Session被启动的日期与时间管理者透过Session来查看session的详细内容，除了可以了解到该session在资料查询期间的所有执行记录外，当该笔session有显示事件发生时，管理者可以查询它的网页快照，除此之外当发现Server Time过久的时候，可以直接连接到Diagnostics查询该笔Session所对应的Business Process的执行，再从该笔Business Process查询其Call Profile，如此一来就可以知道缓慢的问题是发生在后端的服务器的那一个Layer或是Application组件。 Event Count Over TimeEvent Count Over Time Report可以显示在查询期间所有发生事件的数量与分类。 Event SummaryEvent Summary可以显示所有事件的总和，并且可以在点选深入分析事件的发生时间与分类 Business Process DistributionBusiness Process Distribution report可以显示出Real User Monitor的交易(transactions)有哪一些是属于最常被执行的，并且可以显示其相关的反应时间与可用率。1.1.3 问题诊断(Diagnostics) 模块概述Diagnostics可以对J2EE、.NET、SAP R3/Netweaver、Siebel等应用系统进行诊断分析，协助发现并精确定位性能瓶颈、异常、内存泻漏等问题。对于J2EE应用程序，BAC的BPM可以得到每一支交易的响应时间曲线，在此基础上，借助Diagnostics 模块，可以对每一支交易进行分解（Breakdown）或钻取（Drill Down），从而得到交易由哪些服务请求（Server Request，SR）构成的，以及每个SR的方法调用链（Call Tree），调用链中给出了每个方法的时间消耗及所占比例。根据对调用链的分析，可以看出交易响应时间的具