LXJH-L9E2EMRUM201509-CN-3题稿.pptx

L9 E2EM RUM 产品介绍 September 02, 2015 用户观点的 End-to-End 端到端视觉化性能监控 www.L-NINE.com 1 LXJH 2 L9 E2EM RUM 方案背景 为什么需要服务的性能监控 ? 40% 用户的期待值越来越高. 一般用户都期待您的网页会加载2秒以内 如超过3秒， 40%的客户就要放弃您的网站 [Forrester Consulting] 经历过延迟的 75%的客户不再购买该网站里的服务 体验过不满的 2%的客户发信息社交网或媒体吐露不满的经验 [Akamai Sponsored Research] Gone in 3 Seconds 64% 性能问题的 64%以最终用户来发现. [Forrester Consulting] 只有 2%的客户提起不满, 而另外 98%的客户中 45%的客户悄悄地离开该网站. [Gartner “How to Approach Customer Experience Management”] 用户提起问题之前都没法认知性能问题. Discovered by end users 3 为解决问题花太多人力及时间 目前我们的 IT部门…. Network Team Application Team Server Team 服务器也没什么问题呀. 不是网络的 问题. 应用与这问题 没有关系呀. 对用户性能不满没法提前对应,只能反复的事后对应 跨部门/组织,问题难以圆满沟通 单独部门有限的知识领域,只能使问题的解决更加困难 能证明问题的客观数据却不存在 最终用户 End-Users IT 运营者 提起性能问题 认知问题 事后处理,没法根本解决 4 缺乏性能监控对业务的影响 IT 费用投资对与业绩提升不成正比, ROI投资回收没达到预期要求 生产性 卖出 IT 运营费用 企业的竞争力下滑 IT 部门生产性的低下 对外销售卖出的额度低下 客户脱离使卖出额减少 IT运营费用的增加 盲目的IT投资 竞争力下滑 企业品牌价值的下跌 5 对性能问题解决方式的变化 对性能问题以迅速认知而提前对应的端到端监控的需求 对服务传送区间做视觉化可以掌控整体的服务状态 对IT部门之间发生的性能问题，提供客观的数据并明确区分处理负责部门 不是单一的组件,是最终用户体验的网页级别响应速度的监测 用户对服务的满意度提升,还可以做出 IT资源活用的极大化 对IT资源的总体及提供的服务性能,同时满足 需要确保从用户到数据中心机房的已扩展的可视性 通过分析用户体验/预测 做IT资源活用的极大化 网络线路的增设, 网络设备的升级,安全设备强化及构筑, 服务器增设,虚拟化构筑等总体观点的基础设施投资没法解决用户性能问题. 根据用户的地区类别,事务交易性能,响应速度等数据,对IT资源的容量做出预算及计划 把消极的用户体验做最小化从而提前对应就是IT服务质量评估的标准 6 7 L9 E2EM RUM 概述 8 L9 E2EM 可以扩展从用户到数据中心机房的可视性 应用认知网络监控 用户, 应用, 网络相关关系监控 (URL, 会话, 事务, 等待, 流量, 数据,延迟,PPS, RTT等) N-Tier N层架构区间类别延迟时间,视觉化监控 服务器/应用延迟时间及相应等待状态 (Server/Application latency, wait, SQL query) 用户环境类别分为体验速度的测量 (Web 页面加载时间) 用户事务实时追踪分析 E2E(用户-网络-服务器) 监控 服务器/应用的延迟 用户体验 User Experience 页面加载时间 网络往返时延请求/响应，延迟 延迟 延迟 9 把IDC数据中心的服务架构做出视觉化画面,监控各个架构类别性能问题 过去 现在 事件发生时间 特定时点的服务状态 重播 Replay 点击 点击 点击 点击 灵活的流动界面构成(最多 10个架构 Tier) 延迟 延迟 延迟 10 服务器动态 把数据中心的服务器性能问题 以每一秒单位监视监控 后端区间延迟速度 WEB服务器延迟速度 服务器响应 等待会话数 服务器错误数 当前在线人数 该项服务器的 详细服务管理界面 Click 服务器性能低下情况发生时发Beep音告警 如超出各个因素类别临界值给警报 11 用户和网络, 服务器关联在一起,可以迅速确认各部门领域的问题 把控APP服务器延迟 把控Query 延迟 服务发生延迟的用户 把控有错误的应用 用户请求延迟的应用 点击 12 能够精确测量用户的网页级别响应速度 单位服务类别 加载时间的测量 掌控体验性能 低下区间 期间类别性能低下区间的趋势分析 能够掌控实际用户使用服务的体验. 能够