《私有云下以业务为核心的监控产品知识课件》由会员分享，可在线阅读，更多相关《私有云下以业务为核心的监控产品知识课件（46页珍藏版）》请在金锄头文库上搜索。
1、,支付宝 XFLUSH私有云下以业务为核心的监控产品,Agenda,应运而生支付宝的运维环境需要何种监控 XFLUSH提供的监控产品 XFLUSH技术实现 Q&A,支付宝的运维环境需要何种监控,主机、网络、DB 监控 公有云、常规运维环境必备,主机监控： 服务器的性能指标，如load、cpu、内存等,网络监控： 交换机、主机等设备的网络流量信息等,数据库监控： 数据库的性能指标，如cpu、load、active session、Read/Write 等,支付宝的运维环境需要何种监控,应用监控 各集群、各服务器的各种指标,支付宝的运维环境需要何种监控,诉求总结： 业务监控 实时BI，T+0，秒级
2、 合作伙伴监控 与银行、淘宝、商户、机构的交互 SOA环境监控 处理高深度、高复杂度的依赖关系,业务分析 价值如何体现？ 实时业务BI 确定故障范围 业务与合作伙伴的关系 业务与应用的关系 业务与业务的关系 业务与管控策略的关系 业务与运维策略的关系,实时业务BI,有时候不是为了排查故障，而是为了确认没有故障，或是当前故障无甚影响,每天的曲线特点 是否满足基线 定点营销活动是否正常进行,大促的秒级交易峰值 大促刚开始那一分钟交易飙升情况的实况转播 ,确定故障范围,主交易下跌 淘宝交易下跌 商户交易下跌 无线交易下跌 快捷渠道下跌、网银渠道下跌 公共事业缴费异常 信任登陆异常 不同的业务表征，代
3、表了不同的故障影响范围， 不同的影响范围，应急人员会采取不同的应急策略 不同的影响范围，暗示着不同的业务链路,业务与合作伙伴,单个银行故障，则银行故障可能性较大 多个银行故障，则支付宝故障可能性较大 很土的统计方法学,业务与应用的关系,无论ABCDE是一个个单独的系统，还是单个系统中的逻辑模块，都能通过与业务数据的配合，确定故障的来龙去脉 假如故障的不是D而是B、C，那就是全站交易下跌 假如故障的是E，那商户交易会一切正常,A,B,C,D,E,A-B A-C-E 淘宝交易路径 A-B A-C-D 商户交易路径,业务与业务的关系,支付宝交易系统和旺旺登陆系统有什么关系？,支付宝交易系统和短信发送
4、系统有什么关系？,业务与运维策略的关系机房引流物理机房、逻辑机房的流量分配,业务与管控策略的关系,一般情况下，此表只有略微的BI价值,业务与管控策略的关系,应急小组制定大促秒杀策略 不同类目根据市场行情执行不同力度的营销宣传 类目A IPHONE+IPAD 类目B 三星系列 类目C 小米 OPPO 系列 类目D 其他（item种类繁多，但总量远小于主打产品）,架构师传承上级精神，设计分组隔离架构,按照不同类目的营销力度各自分组，每组分配适当的服务器资源,分组D单独隔离避免因为一些小item的非预期异常影响主打产品,此时不仅有BI价值（让人清晰的、快速的看到战绩） 还能反馈应用、服务器集群的健康
5、状态,业务与管控策略的关系,管控策略： 分组 业务有轻重缓急之分 降级 资源有限，业务需弃卒保车 限流 资源有限，业务不能超过容量水位 引流 业务渠道有优劣之分，需动态容错 现代互联网公司，是否有优雅的管控策略是一个重要的衡量标准，而管控策略的制定和业务息息相关,业务与管控策略的关系如何应对众多时好时坏的银行渠道？,Xflush在支付宝PAAS整体定位,Monitoring,Elastic Computing,Operations,ElasticComputing,Make Decisions,Executive Decisions,LOG,XFLUSH业务监控 支付宝弹性计算 公有云的弹性计
6、算 以资源为核心，计算、存储等物理资源的弹性调配 发现物理节点异常 自动化弹性控制 调整物理节点（扩容、回收） 支付宝私有云的弹性计算 以业务为核心，业务资源的弹性调配 发现业务渠道异常 自动化弹性控制 调整业务渠道优先级或业务策略、开关、阈值,如何应对互联网级别的SOA环境 单点服务器上抛异常了，我们可以去tailf一下error日志，看看Exception,如果面对的是 跟各种外部服务交互 服务器规模上万 应用集群成百上千 SOA依赖关系错综复杂 各种中间件组件相互协作 提问：此时假设仅有一台服务器僵死，如何才能快速发现,埋点主义 VS 现象主义 在常规做法中，就是对所有服务器都能做到埋点
7、检查，当它僵死之时，应该能够通过内存、load、端口检测等方式，发现僵死状态并汇报报警 而现象主义的出发点就是，埋点依赖穷举，而故障原因无穷无尽，与其被动的被它们牵着鼻子走，还不如把服务器运行的现象用最快最准确最直观的方式展现出来，依靠经验来推导故障源,现象主义,现象主义,如何为支付宝提供这些产品xflush基于日志的解决方案,日志能干什么？一个例子：,如果每个高速收费站都将 车辆过往信息打成日志： 2012-11-11 11:11:11 粤A123XX,广州北收费站,G25,广州,￥50 . 那从日志里我们可以分析得到：,1 每个收费站的车流量 2 G25高速流量过高，各来源占比 3 十一期
8、间进入上海总车辆数 4 浙A123XX的嫌犯车辆的逃亡路线,日志分析能提供什么,基础监控 只要有日志 应用监控 只要有日志（apache日志可用于PV、ibatis日志可用于dal） 业务分析 系统将自身每一笔业务以日志方式输出，日志格式与其领域模型相呼应 异常分析 所有异常信息集中输出，完整输出，不吞异常,Xflush如何实现日志分析,常规方案 Xflush计算架构 Xflush技术难点,常规方案,Log收集,2012-11-11 11:11:11 粤A123XX,广州北收费站,G25,广州,￥50 . 2012-11-11 11:11:11 粤A123XX,广州北收费站,G25,广州,￥5
9、0 . . .,HDFS,Hadoop Map/Reduce,HIVE、宽表、add-hoc,Hadoop 衍生产品,常规方案,支付宝实施传统方案的难点,成本 项目初期没有办法投入大规模的集群来搭建hadoop体系 希望用最小成本来实现最大价值，可以对监控内容做等级划分，在一段时期内可以接受99.9x%的可用率 时效性 Hadoop体系的后计算、批处理模式注定其不能达到很高的时效性要求。使用MAP/REDUCE的增量替代方案倒是可以考虑（如percolator的100倍提升） 平台化 业务监控类型繁多，对定制化能力要求很高。 可扩展性 必须支持随时随地的横向扩展以支撑日益增长的数据量 等等 在
10、这种历史背景下，自行定制了一套低成本高时效性的解决方案，直至目前的版本的xfush依然贯彻此原则。,Xflush计算架构目标,低侵入性 增量计算 不保存原始数据 对业务系统侵入性最低 保证时效性 保证数据准确性 保证可扩展性 避免冗余计算 计算逻辑可扩展性 等等,最近的发布成果： 延迟下降到15秒 成本下降40% 完全保障数据准确性 全量数据快速检索 （每天200W*1440） 通用平台化 自动化运维 ,计算架构类比 与MAP/REDUCE的比较,与传统MR类似，广义上都可理解为MAP和REDUCE两个处理过程 Map用于解析日志 Reduce用于关联汇聚、统计计算,计算架构类比解释 （MR的
11、不足）,而必须基于MR的思想进行改进的地方在于： 1 对流式、增量计算的支持 （参考percolator、storm） 2 对内存中计算的支持 （参考spark） 3 对计算关联共享的支持 （参考spark&RDDS）,Xflush如何实现日志分析,有状态谱系图增量计算 集群计算框架，比如MR和Dryad，被广泛用于大规模数据分析。这些系统让用户使用高级编程模型来编写并行计算程序，不需要担心分布式和容错等问题。这些框架为访问集群计算资源提供了很多抽象，但是这些抽象中却很少涉及分布式内存。这让它们在某些重要的新兴应用场景中显得低效：这些应用场景中需要跨多个计算过程，重用中间计算结果。比如在迭代式
12、机器学习和图算法中，数据重用是很普遍的需求，包括PageRank，K-means 聚类，和逻辑回归。另一个重要使用场景是迭代式数据挖掘，其中一个用户会对相同数据子集运行多个adhoc查询。不幸的是，在大多数当前框架中，在计算过程之间（比如在两个MR作业之间）重用数据的唯一方式是将数据写入一个外部的稳定存储系统，比如一个分布式文件系统。从而导致了大量因为数据复制、磁盘I/O、序列化而产生的负载，影响应用的执行耗时。 对于迭代式应用，Spark的处理速度是Hadoop的20倍以上；一个真实的数据分析报表应用在使用Spark后速度提升了40倍；交互式扫描1TB的数据集合延迟在5到7秒 Resilie
13、nt Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing,Xflush如何实现日志分析,有状态谱系图增量计算 在Google，Percolator的主要应用是实时构建web搜索索引。索引系统使用Percolator之后，我们能在文件被抓取时就单独的处理它。这几乎减少了100倍的平均文档处理延迟，而且搜索结果中文档的平均年龄也降低了50% Large-scale Incremental Processing Using Distributed Transactions and Not
14、ifications,Xflush计算架构概览,agent,agent,agent,业务系统 集群,TAP,TAP,TAP,TAP,Xflush 计算集群,BASIN,BASIN,BASIN,BASIN,BASIN,BASIN,BASIN,BASIN,高速日志传输,多数据源接入,快速日志解析,Buffer、Batch等优化控制,谱系图 分布式计算,计算关联共享,数据完整性检查,增量计算,路由协调控制,容器化动态部署,K/V存储,部署在业务系统的代理，负责传输日志,数据接入层，接入、解析各种源数据,数据计算层，执行图状分布式计算,基于定制化的分布式文件存储,有状态内存计算,Xflush如何实现日
15、志分析,技术难点 有状态谱系图增量计算 追求性能导致的一致性隐患 日志模型索引静态化 齐全性算法 计算结果如何存储,有状态谱系图增量计算,TAP接收持续涌入的日志数据，执行解析、为第一层BASIN执行预处理,Basin 将计算关联共享的图状节点负载均衡有条不紊的分布在服务器集群上，接收增量到来的新数据，立刻参与计算，缓存计算中的数据直到计算完成,Select 城市,高速,收费站,sum(收费) from xxx where 时间 between(x,x) group by 城市,高速,收费站,Select 城市,sum(收费) from xxx where 时间 between(x,x) gr
16、oup 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,B: Select 城市,sum(收费) from table1 group by 城市,Select 高速,sum(收费) from xxx where 时间 between(x,x) group by 高速,A: Select 城市,高速,收费站,sum(收费) from xxx where 时间 between(x,x) group by 城市,高速,收费站,Result Table : table3 G50=1350 G51= 600 G25= 180 G26= 70,
