随着阿里巴巴数据库规模的不断扩大，我们的数据库管控平台也经历了很多阶段，从脚本化、工具化、平台化到现在的DBPaaS，DBPaaS在2017年双十一期间，***全面覆盖了集团及各子公司本地数据库、公有云、混合云等各种场景。2017年双11，数据库全面实现容器化部署，线下资源灵活使用，公有云资源支持大促。全面优化的监控采集链路，实现全网所有数据库实例的秒级采集、监控、展示、诊断。每秒实时处理超过1000万个监控指标，让异常隐形。DBPaaS也在数据库管理的自动化、规模化、数字化、智能化等方面不断取得突破。其中，数据库监控系统的建设较为典型。在业务正常运行状态下，当线上系统出现故障时，如何在数以万计的数据库中发现异常并快速诊断，也是一项极具挑战性的工作。双11全链路压测期间，系统吞吐量未达到预期或业务出现RT抖动。快速诊断和定位数据库问题是一个实际问题。此外，对于复杂的数据库故障，根因排查、现场修复、历史事件跟踪也迫使我们构建覆盖所有线上环境、数据库实例、事件的监控体系，做到：1）覆盖所有机房阿里巴巴的全球子公司。2）涵盖阿里巴巴生态圈的新零售、新金融、新制造、新技术、新能源等所有业务。3）涵盖所有数据库主机、操作系统、容器、数据库和网络。4）所有性能指标应在1秒级连续不间断地监控。5)全天候连续稳定运行。DBPaaS监控双11运行概览2017年双11期间，DBPaaS平台二级监控系统平均每秒处理1000万个性能指标，峰值1400万个性能指标。在中国、美国、欧洲和东南亚在线发行。保证数据库实例的健康运行。实现实时秒级监控，也就是说任何时候，DBA同学都可以看到任何一个数据库实例在一秒前的所有性能趋势。DBPaaS监控系统仅使用数据库资源池中0.5%的机器就可以支撑整个采集链路、计算链路、存储、展示诊断系统。监控系统完整记录了今年的每一次全链路压测、每一次RT抖动站点，帮助DBA快速诊断数据库问题，为后续系统优化提供建议。双11大促保障期间，我们保证机器不扩容，服务不降级，让DBA同学喝茶过双11。在日常业务运营保障方面，我们也有7*24项服务能力。我们是怎么做到的实现一个支持数万数据库实例的实时秒级监控系统，需要解决很多技术难题。据说已经演化出一个优秀的架构，随着规模和复杂度的增加，监控系统的建设也不断迭代。截至2017年，监测体系经历了四个阶段的完善。***代监控系统***代监控系统的架构非常简单。采集代理直接将性能数据写入数据库，监控系统直接查询数据库。随着数据库集群规模的扩大，简单架构的劣势也非常明显。首先，单机数据库容量的可扩展性不足。随着监控数据库规模的扩大，每天的性能指标写入量非常大，数据库容量捉襟见肘。长期积累的监控历史数据经常会触发磁盘空间警告，我们经常被迫删除前向数据。二是监测指标可扩展性不足。一开始，数据库监控项只有十几个，但很快就发现不够用了。因为经常有人拿MySQL文档说，我要看这个，我要看那个，能不能放到监控系统里。表现性能指标的前提是存储，而存储层的可扩展性缺陷让我们很头疼。对于这种功能需求，无论是宽表还是窄表，都有明显的缺陷。如果使用宽表，每次添加一批性能指标都需要执行DDL。预定义的扩展字段虽然可以缓解问题，但最终还是限制了产品的想象力。窄表在结构上解决了任何性能指标的存储问题，但也带来了增加写入数据量和扩展存储空间的弊端。***，系统整体读写能力不高，不具备横向扩展能力。以上种种原因催生了第二代监控系统的诞生。第二代监控系统第二代监控系统引入了DataHub模块和分布式文档数据库。数据链路变成从采集Agent到DataHub再到分布式文档数据库，监控系统从分布式文档。采集代理侧重于性能数据采集逻辑，构建统一的数据格式，调用DataHub接口将数据传输到DataHub。收集代理不需要关心性能数据存在于何处。DataHub作为一个连接节点，实现了采集和存储的解耦。***，对采集Agent屏蔽数据存储细节，只暴露最简单的数据传递接口；第二，DataHub根据存储引擎的特点，采用***写模型接收数据，如采用批量写、压缩等；第三，利用LVS和LSB技术实现DataHub水平扩展。分布式文档数据库部分解决了可扩展性问题，水平扩展用于解决存储容量不足的问题，schemafree的特点可以提高性能指标的可扩展性问题。随着监控系统的不断运行，数据库实例规模不断扩大，性能指标不断提升，监控系统的用户不断扩大，也遇到了新的问题。***、DBA同学经常需要查看数据库跨越数月的性能趋势，以预测未来数据库流量的趋势。这个时候系统查询速度基本就达不到了。其次，存储一年的全量性能数据的成本越来越难以承受。每年双11压测，DBA同学总会问到去年双11的性能趋势。第三，DataHub存在采集数据丢失的隐患。由于原始数据先缓存在DataHub内存中，只要重启进程，内存中采集到的数据就会丢失。关于第三代监控系统查询速度慢，文档数据库和关系数据库一样，都是面向行的数据库，即读写的基础数据。性能数据每秒存储一行，一行有N个性能指标。性能指标存储在按时间键控的表中。虽然所有性能指标同时存储在同一行中，但它们之间的关系并不是那么密切。因为一个典型的监控诊断需求是查看同一个或几个指标在一段时间内的变化趋势，而不是同时查看指标（瞬时值），比如这样：为了找出性能某一个指标的趋势，数据库存储引擎，但是去扫描所有指标的数据，CPU和内存的成本是巨大的，很明显这些都是浪费。虽然ColumnFamily技术可以在一定程度上缓解上述问题，但是如何设置ColumnFamily是一个巨大的挑战。存储层的策略是否应该与监控诊断层的需求耦合？这看起来不是个好主意。因此，我们将目光投向了列式数据库。监控性能指标的读写特性非常适合列式数据库。以OpenTSDB为代表的时序数据库进入了我们的视野。OpenTSDB使用时间线，用时间序列描述每一个具体的对象，时间线的读写是独立的。毫无疑问，OpenTSDB成为第三代监控系统架构的一部分。为了消除DataHub稳定性的隐患，引入了分布式消息队列来削峰填谷。即使DataHub全线崩溃，也可以通过重新消费消息来解决。分布式消息队列，可以选择Kafka或者RocketMQ，这些分布式消息队列已经具备了高可用的能力。与过去相比，第三代架构有了很大的进步。2016年双11，实现全网数据库10秒级监控，核心数据库集群1秒级监控。随着阿里生态的扩大和全球化的深入，各全资子公司的业务已全面融入阿里体系。除中国大陆外，在美国、欧洲、俄罗斯、东南亚等地也有业务。与此同时，新技术在阿里巴巴数据库领域的应用层出不穷。部队部署已成为常态。容器化调度正在覆盖全网。存储和计算的分离在不断推进。同一个业务数据库集群在不同单元可能有不同的部署策略。相应的，DBA团队的规模也没有相应扩大。一个DBA同学支持多家子公司的业务很正常，有的DBA还负责新技术推广等工作。在数据库性能诊断方面，DBA需要力求效率，越来越迫切需要为DBA提供一条从宏观到微观到诊断的路径：从大磁盘到集群，到集群的一站式服务，units，toinstances，tohosts，tocontainer等等。在这样的诊断需求下，第三代监控架构有点力不从心，主要表现在查询上：1）高维性能诊断的查询速度慢。以集群QPS为例，由于每个实例的QPS数据都存储在OpenTSDB中，当需要查询集群维度QPS时，需要扫描集群中每个实例的QPS，然后按时间戳分组求和所有实例的QPS。这需要扫描大量原始数据。2）OpenTSDB不能支持复杂的监控需求，比如查看集群的平均RT趋势。集群的平均RT不是avg（所有实例的RT），而是sum（执行时间）/sum（执行次数）。为了达到目的，只能检测到2条时间线数据，在监控系统中计算出来，然后显示在页面上。用户响应时间过长。3）性能诊断时间长，速度慢。例如一个月的性能趋势，需要在秒级扫描原始的259.2万个数据点，并在浏览器中展示出来。考虑到浏览器的性能，实际上不可能也没有必要显示原始数据。二级数据。显示15分钟时间精度的数据就足够了。对于上述的预计算问题，OpenTSDB也意识到自2.4版本以来，其预计算能力较为简单，OpenTSDB在功能灵活性、系统稳定性、性能等方面无法满足DBPaaS的秒级监控需求。DBPaaS新一代架构新一代架构，我们将OpenTSDB升级为更强大的HiTSDB，同时基于流式计算开发的实时预聚合引擎替代了简单的DataHub，让秒级监控成为可能飞。在职责定义上，复杂的监控诊断需求交给实时预聚合引擎解决，而时序数据库的查询需求都限制在一个时间线内。这就要求时序数据库必须最大化单个时间线的性能。阿里巴巴兄弟团队开发的高性能时序数据库HiTSDB，实现了最大压缩和最大读写能力。对于值变化很小的特征，它做了大量的压缩。同时完全兼容OpenTSDB协议，并在阿里云进行了测试。新的架构让我们可以放开手，专注于监控和诊断需求，而不受存储层的束缚。***、针对高维性能趋势查询性能，预聚合引擎可以根据业务数据库集群、单元、实例等进行性能指标预计算，并写入HiTSDB。二是建立性能指标聚合计算函数库。所有性能指标的聚合计算公式都是可配置的，实现了监控指标的自由设置。第三，提前降低时间精度，分为6个精度：1秒、5秒、15秒、1分钟、5分钟、15分钟。不同时间精度的性能数据有不同的压缩策略。实时计算引擎实时计算引擎在实例、单元、集群三个维度实现逐级聚合，并将每一级的聚合bolt写入HiTSDB。流计算平台的选择是免费的。目前，我们的程序运行在JStorm计算平台上。JStorm让我们拥有了天然的高可用能力。实时计算引擎性能实时计算引擎使用数据库总机器大小的0.1%，实现全网秒级监控数据计算，平均每秒处理超过1000万个性能指标，平均写入600万TPS，峰值1400TPS万，下图是双11期间HiTSDBTPS趋势曲线，关键优化点用这么少的计算资源做到这么高的吞吐量，必须要用到很多黑科技使用。1）在预计算中，我们采用增量迭代计算。无论是5秒精度的数据还是15分钟精度的数据，我们都不需要等到时间窗口内的所有性能指标都采集完了才开始计算，而是要不管性能数据有多少，只保留中间结果，大大节省内存。与传统的计算方法相比，这种优化至少节省了95%的内存。2）采集端对性能数据包进行合并，将相似、相邻的数据包合并在一起，上报给Kafka，以便JStorm程序对数据进行批量处理。3）利用流式计算的特点实现数据局部性，同一集群单元的实例采集的数据在同一个kafka分区中。这样可以减少计算过程的网络传输和java序列化/反序列化。这个可以减少50%的网络传输。有兴趣的朋友可以想想为什么不能按实例分区，也不能按集群分区。会有什么问题？4）利用JStorm的自定义调度特性在同一个JVM中调度数据依赖的计算bolts。这是为了配合上面的第二步，实现数据尽可能在同一个JVM中流转。5）对于不得不发生的Map-Reduce数据传输，尽量使用批量传输，对传输的数据结构进行复用和裁剪，减少重复数据的传输，减轻序列化和反序列化的压力。未来展望阿里DBPaaS的全网秒级监控，让数据库管控实现数字化。经过这一年，我们积累了很多有价值的结构化数据。随着大数据技术和机器学习技术的发展，数据库管理和控制的智能化成为可能。1）智能诊断，在现有全方位无死角监控的基础上，结合事件跟踪，对问题进行智能定位。2）调度优化。通过分析每个数据库实例的配置文件特征，可以将资源互补的多个数据库实例调度在一起，最终节省成本。3）预算估算，通过分析数据库的历史运行状态，在每次大促前，根据业务交易量目标确定各数据库集群的容量需求，为自动扩容提供依据。
