1 / 46

支付宝 XFLUSH 私有云下以业务为核心的监控产品

支付宝 XFLUSH 私有云下以业务为核心的监控产品. ——ALIPAY 章邯. Agenda. 应运而生 —— 支付宝的运维环境需要何种监控 XFLUSH 提供的监控产品 XFLUSH 技术实现 Q&A. 支付宝的运维环境需要何种监控. 主机、网络、 DB… 监控 —— 公有云、常规运维环境必备. 网络监控： 交换机、主机等设备的网络流量信息等. 主机监控： 服务器的性能指标，如 load 、 cpu 、内存等. 数据库监控： 数据库 的性能指标，如 cpu 、 load 、 active session 、 Read/Write 等.

leon
Download Presentation

支付宝 XFLUSH 私有云下以业务为核心的监控产品

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 支付宝 XFLUSH私有云下以业务为核心的监控产品 ——ALIPAY 章邯

  2. Agenda • 应运而生——支付宝的运维环境需要何种监控 • XFLUSH提供的监控产品 • XFLUSH技术实现 • Q&A

  3. 支付宝的运维环境需要何种监控 • 主机、网络、DB… 监控 —— 公有云、常规运维环境必备 网络监控： 交换机、主机等设备的网络流量信息等 主机监控： 服务器的性能指标，如load、cpu、内存等 数据库监控： 数据库的性能指标，如cpu、load、active session、Read/Write 等

  4. 支付宝的运维环境需要何种监控 • 应用监控 各集群、各服务器的各种指标

  5. 支付宝的运维环境需要何种监控 • 更重要的诉求： • 当前交易量是否稳定？ • 淘宝交易创建请求的付款成功率？ • 作为开放平台，接入的几十万商户有哪些交易正常、哪些出现下跌？ • 成千上万的银行渠道中哪些在正常付款，哪些成功率低下？ • 几百个集群、成千上万台服务器按照错综复杂的依赖关系构建成的SOA环境是否正常的相互协作？ • 公共事业缴费机构是否运作正常？ • 营销活动账户的余额是否足够支撑？ • 限流、分流、引流等开关是否正常运作？ • ………………

  6. 支付宝的运维环境需要何种监控 诉求总结： • 业务监控 ——实时BI，T+0，秒级 • 合作伙伴监控 ——与银行、淘宝、商户、机构的交互 • SOA环境监控 ——处理高深度、高复杂度的依赖关系

  7. 业务分析价值如何体现？ • 实时业务BI • 确定故障范围 • 业务与合作伙伴的关系 • 业务与应用的关系 • 业务与业务的关系 • 业务与管控策略的关系 • 业务与运维策略的关系

  8. 实时业务BI • 有时候不是为了排查故障，而是为了确认没有故障，或是当前故障无甚影响 每天的曲线特点 是否满足基线 定点营销活动是否正常进行 大促的秒级交易峰值 大促刚开始那一分钟交易飙升情况的实况转播 ……

  9. 确定故障范围 • 主交易下跌 • 淘宝交易下跌 • 商户交易下跌 • 无线交易下跌 • 快捷渠道下跌、网银渠道下跌 • 公共事业缴费异常 • 信任登陆异常 • …… 不同的业务表征，代表了不同的故障影响范围， 不同的影响范围，应急人员会采取不同的应急策略 不同的影响范围，暗示着不同的业务链路

  10. 业务与合作伙伴 • 单个银行故障，则银行故障可能性较大 • 多个银行故障，则支付宝故障可能性较大 ——很土的统计方法学

  11. 业务与应用的关系 A • A-B A-C-E —— 淘宝交易路径 • A-B A-C-D —— 商户交易路径 • 无论ABCDE是一个个单独的系统，还是单个系统中的逻辑模块，都能通过与业务数据的配合，确定故障的来龙去脉 • 假如故障的不是D而是B、C，那就是全站交易下跌 • 假如故障的是E，那商户交易会一切正常 B C D E

  12. 业务与业务的关系 • 支付宝交易系统和旺旺登陆系统有什么关系？ • 支付宝交易系统和短信发送系统有什么关系？

  13. 业务与运维策略的关系机房引流物理机房、逻辑机房的流量分配业务与运维策略的关系机房引流物理机房、逻辑机房的流量分配

  14. 业务与管控策略的关系 • 一般情况下，此表只有略微的BI价值

  15. 业务与管控策略的关系 • 架构师传承上级精神，设计分组隔离架构 应急小组制定大促秒杀策略 不同类目根据市场行情执行不同力度的营销宣传 • 类目A IPHONE+IPAD • 类目B 三星系列 • 类目C 小米 OPPO 系列 • 类目D 其他（item种类繁多，但总量远小于主打产品） 按照不同类目的营销力度各自分组，每组分配适当的服务器资源 分组D单独隔离避免因为一些小item的非预期异常影响主打产品 • 此时不仅有BI价值（让人清晰的、快速的看到战绩） • 还能反馈应用、服务器集群的健康状态

  16. 业务与管控策略的关系 • 管控策略： • 分组 业务有轻重缓急之分 • 降级 资源有限，业务需弃卒保车 • 限流 资源有限，业务不能超过容量水位 • 引流 业务渠道有优劣之分，需动态容错 现代互联网公司，是否有优雅的管控策略是一个重要的衡量标准，而管控策略的制定和业务息息相关

  17. 业务与管控策略的关系——如何应对众多时好时坏的银行渠道？业务与管控策略的关系——如何应对众多时好时坏的银行渠道？

  18. Elastic Computing Make Decisions Xflush在支付宝PAAS整体定位 Elastic Computing Operations Monitoring Executive Decisions LOG

  19. XFLUSH业务监控@ 支付宝弹性计算 • 公有云的弹性计算 以资源为核心，计算、存储等物理资源的弹性调配 发现物理节点异常 自动化弹性控制 调整物理节点（扩容、回收……） • 支付宝私有云的弹性计算 以业务为核心，业务资源的弹性调配 发现业务渠道异常 自动化弹性控制 调整业务渠道优先级或业务策略、开关、阈值

  20. 如何应对互联网级别的SOA环境 单点服务器上抛异常了，我们可以去tailf一下error日志，看看Exception • 如果面对的是 • 跟各种外部服务交互 • 服务器规模上万 • 应用集群成百上千 • SOA依赖关系错综复杂 • 各种中间件组件相互协作 提问：此时假设仅有一台服务器僵死，如何才能快速发现

  21. 埋点主义 VS 现象主义 • 在常规做法中，就是对所有服务器都能做到埋点检查，当它僵死之时，应该能够通过内存、load、端口检测等方式，发现僵死状态并汇报报警 • 而现象主义的出发点就是，埋点依赖穷举，而故障原因无穷无尽，与其被动的被它们牵着鼻子走，还不如把服务器运行的现象用最快最准确最直观的方式展现出来，依靠经验来推导故障源

  22. 现象主义

  23. 现象主义

  24. 如何为支付宝提供这些产品xflush——基于日志的解决方案如何为支付宝提供这些产品xflush——基于日志的解决方案

  25. 日志能干什么？一个例子： 如果每个高速收费站都将 车辆过往信息打成日志： 2012-11-11 11:11:11 粤A123XX,广州北收费站,G25,广州,￥50……. 那从日志里我们可以分析得到： 1 每个收费站的车流量 2 G25高速流量过高，各来源占比 3 十一期间进入上海总车辆数 4 浙A123XX的嫌犯车辆的逃亡路线

  26. 日志分析能提供什么 • 基础监控 只要有日志 • 应用监控 只要有日志（apache日志可用于PV、ibatis日志可用于dal……） • 业务分析 系统将自身每一笔业务以日志方式输出，日志格式与其领域模型相呼应 • 异常分析 所有异常信息集中输出，完整输出，不吞异常

  27. Xflush如何实现日志分析 • 常规方案 • Xflush计算架构 • Xflush技术难点

  28. 常规方案 Log收集 2012-11-11 11:11:11 粤A123XX,广州北收费站,G25,广州,￥50 ……. 2012-11-11 11:11:11 粤A123XX,广州北收费站,G25,广州,￥50 ……. ……. ……. Hadoop 衍生产品 Hadoop Map/Reduce HDFS HIVE、宽表、add-hoc

  29. 常规方案

  30. 支付宝实施传统方案的难点 • 成本 • 项目初期没有办法投入大规模的集群来搭建hadoop体系 • 希望用最小成本来实现最大价值，可以对监控内容做等级划分，在一段时期内可以接受99.9x%的可用率 • 时效性 • Hadoop体系的后计算、批处理模式注定其不能达到很高的时效性要求。使用MAP/REDUCE的增量替代方案倒是可以考虑（如percolator的100倍提升） • 平台化 • 业务监控类型繁多，对定制化能力要求很高。 • 可扩展性 • 必须支持随时随地的横向扩展以支撑日益增长的数据量 等等 在这种历史背景下，自行定制了一套低成本高时效性的解决方案，直至目前的版本的xfush依然贯彻此原则。

  31. Xflush计算架构目标 • 低侵入性 • 增量计算 • 不保存原始数据 • 对业务系统侵入性最低 • 保证时效性 • 保证数据准确性 • 保证可扩展性 • 避免冗余计算 • 计算逻辑可扩展性 • 等等 • 最近的发布成果： • 延迟下降到15秒 • 成本下降40% • 完全保障数据准确性 • 全量数据快速检索 （每天200W*1440） • 通用平台化 • 自动化运维 • …………

  32. 计算架构类比 与MAP/REDUCE的比较 与传统MR类似，广义上都可理解为MAP和REDUCE两个处理过程 Map用于解析日志 Reduce用于关联汇聚、统计计算

  33. 计算架构类比解释 （MR的不足） 而必须基于MR的思想进行改进的地方在于： 1 对流式、增量计算的支持 （参考percolator、storm） 2 对内存中计算的支持 （参考spark） 3 对计算关联共享的支持 （参考spark&RDDS）

  34. Xflush如何实现日志分析 • 有状态谱系图增量计算 集群计算框架，比如MR和Dryad，被广泛用于大规模数据分析。这些系统让用户使用高级编程模型来编写并行计算程序，不需要担心分布式和容错等问题。这些框架为访问集群计算资源提供了很多抽象，但是这些抽象中却很少涉及分布式内存。这让它们在某些重要的新兴应用场景中显得低效：这些应用场景中需要跨多个计算过程，重用中间计算结果。比如在迭代式机器学习和图算法中，数据重用是很普遍的需求，包括PageRank，K-means 聚类，和逻辑回归。另一个重要使用场景是迭代式数据挖掘，其中一个用户会对相同数据子集运行多个adhoc查询。不幸的是，在大多数当前框架中，在计算过程之间（比如在两个MR作业之间）重用数据的唯一方式是将数据写入一个外部的稳定存储系统，比如一个分布式文件系统。从而导致了大量因为数据复制、磁盘I/O、序列化而产生的负载，影响应用的执行耗时。 对于迭代式应用，Spark的处理速度是Hadoop的20倍以上；一个真实的数据分析报表应用在使用Spark后速度提升了40倍；交互式扫描1TB的数据集合延迟在5到7秒 —— Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing

  35. Xflush如何实现日志分析 • 有状态谱系图增量计算 在Google，Percolator的主要应用是实时构建web搜索索引。索引系统使用Percolator之后，我们能在文件被抓取时就单独的处理它。这几乎减少了100倍的平均文档处理延迟，而且搜索结果中文档的平均年龄也降低了50% —— Large-scale Incremental Processing Using Distributed Transactions and Notifications

  36. Xflush计算架构概览 业务系统 集群 agent agent agent 高速日志传输 部署在业务系统的代理，负责传输日志 多数据源接入 快速日志解析 数据接入层，接入、解析各种源数据 Xflush 计算集群 TAP TAP TAP TAP Buffer、Batch等优化控制 路由协调控制 数据计算层，执行图状分布式计算 BASIN BASIN BASIN BASIN 增量计算 谱系图 分布式计算 容器化动态部署 BASIN BASIN BASIN BASIN 计算关联共享 数据完整性检查 基于定制化的分布式文件存储 K/V存储 有状态内存计算

  37. Xflush如何实现日志分析 • 技术难点 • 有状态谱系图增量计算 • 追求性能导致的一致性隐患 • 日志模型索引静态化 • 齐全性算法 • 计算结果如何存储

  38. 有状态谱系图增量计算 Basin 将计算关联共享的图状节点负载均衡有条不紊的分布在服务器集群上，接收增量到来的新数据，立刻参与计算，缓存计算中的数据直到计算完成 TAP接收持续涌入的日志数据，执行解析、为第一层BASIN执行预处理

  39. Select 城市,高速,收费站,sum(收费) from xxx where 时间 between(x,x) group by 城市,高速,收费站 Select 城市,sum(收费) from xxx where 时间 between(x,x) group by 城市 Select 高速,sum(收费) from xxx where 时间 between(x,x) group by 高速 • 计算关联共享示例 A: Select 城市,高速,收费站,sum(收费) from xxx where 时间 between(x,x) group by 城市,高速,收费站 B: Select 城市,sum(收费) from table1 group by 城市 Result Table : table1 城市 高速 收费站 收费 广州 G50 广州北 300 广州 G51 广州南100 广州 G50 广州南 600 广州 G51 广州西 500 广州 G50 广州东 400 南京 G25 南京西 30 南京 G26 南京西 70 南京 G25 南京东 150 南京 G50 南京东 50 Result Table : table2 广州=1900 南京=300 C: Select 高速,sum(收费) from table1 group by 高速 Result Table : table3 G50=1350 G51= 600 G25= 180 G26= 70

  40. Xflush如何实现日志分析 • 一致性隐患的解决思路 设计RDDs的主要挑战是定义一个有效容错的编程接口。目前集群内存存储已经有很多抽象，比如分布式共享内存[24]、keyvalue存储[25]、数据库和Piccolo[27]，它们提供的接口是基于对易变状态的细粒度更新（比如，table中的cell）。这种接口中，提供容错的唯一方法是跨机器复制数据，或者跨机器记录变更日志。在数据密集的应用场景中，两个方案都是昂贵的，因为它们需要在集群网络上拷贝大规模数据，网络带宽是远低于RAM的，从而引发了大量的存储负载。 与这些系统不同，RDDs的接口是基于粗粒度转变（比如，map、filter、和join），这些转变会对很多数据项实施相同的操作。这样只需记录转变日志就能实现有效的容错，而不需要记录真实的数据日志。如果一个RDD分区丢失了，RDD掌握了足够的信息关于它是如何从无到有被构建的，继而可以根据此信息重新计算此分区。因此，丢失的数据能被恢复，而且非常快速，不需要冗余复制的成本。 RDDs不需要浪费资源在存档上，因为它的数据能使用谱系图恢复。当故障发生时，也只有丢失的RDD分区需要被重新计算（在多个节点并行的计算），不需要回滚整个程序。 ——Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing

  41. 日志模型索引静态化 将日志模型里各种维度可能出现的值，都录制为静态索引（不支持动态变化，如果出现了新的维度实例，不经过审核是不参与计算的） 优势 1 日志不是值得信任的数据源，避免垃圾数据 2 降低内存成本和存储成本 3 帮助实现齐全性算法 劣势 1 管理成本升高 （半自动录制平台降低审核人员工作量） 2 不能及时更新合法新实例 （忍了，通过授信、半自动等方式将延迟降低到10分钟内） 3 更难支持发散性监控点 （放弃，本来就不准备支持，留给更合适的平台）

  42. 数据完整性判断 • 无论是采用批处理模型还是增量计算模型，原始数据的完整性判断都是问题。在增量计算中更难解决。 比如：当前要对N台服务器上的某个日志进行合并统计，如何判断原始日志已经全部到齐？ 当计算过程被拆解为图状分布式计算后，仅仅分析来源服务器数量已经无效，必须解决数据实例本身的完整性判断

  43. 齐全性算法 + + 计算谱系图 运维元数据 静态索引 在谱系图中根据自身节点的维度， 1 结合运维元数据判断agent的日志包是否到齐 2 结合静态索引判断上层节点实例是否到齐

  44. 计算结果的存储 设想，如果Facebook的所有图片大小保证一致，Haystack是否有优化空间？ 如果GFS的每个文件具备固化周期性，它是否有优化空间？ 定制的分布式文件存储产品——xstore 1 无限扩展 2 纯粹为周期统计型计算定制，最低I/O操作 3 为固化监控点场景定制，高速、无I/O的元数据检索 等等 分布式文件系统论文参考： http://www.importnew.com/3292.html http://www.importnew.com/3491.html

  45. Thank youQ&A

More Related