在这其中，关于数据库监控系统建设比较典型。
在业务平时运行态，线上系统出现故障，在数万数据库中，如何发现异常、快速诊断亦是一件非常具有挑战的事情。在双十一全链路压测中，系统吞吐量未达预期或业务出现了 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 年，监控系统经历了四个阶段改进。
第一代监控系统
第一代监控系统架构非常简单，采集 Agent 直接把性能数据写入数据库，监控系统直接查询数据库即可。
随着数据库集群规模扩大，简易架构的缺点也非常明显。
首先，单机数据库容量扩展性不足，随着监控的数据库规模扩大，日常性能指标写入量非常大，数据库容量捉襟见肘，长时间积累的监控历史数据经常触发磁盘空间预警，我们经常被迫删除远期数据。
其次，监控指标的扩展性不足。一开始数据库监控项只有十几项，但是很快就发现不够用。因为经常有人拿着 MySQL 的文档说，我想看这个，我想看那个，能不能放到监控系统里。性能指标展现的前提是存储，在存储层的扩展性缺陷让我们头痛不已。对于这种功能需求，无论是宽表还是窄表，都存在明显的缺陷。如果用宽表，每新增一批性能指标，就要执行一次 DDL，虽然预定义扩展字段可以缓解，但终究约束了产品想象空间。窄表在结构上解决了任意个性能指标的存储问题，但是它也带来了写入数据量放大和存储空间膨胀的弊病。最后，系统整体读写能力也不高，而且不具备水平扩展性。
以上所有原因催生了第二代监控系统的诞生。
第二代监控系统
第二代监控系统引入了 DataHub 模块和分布式文档数据库。数据链路变成由采集 Agent 到 DataHub 到分布式文档数据库，监控系统从分布式文档。
采集 Agent 专注于性能数据采集逻辑，构造统一数据格式，调用 DataHub 接口把数据传输到 DataHub，采集 Agent 不需要关心性能数据存在哪里。DataHub 作为承上启下的节点，实现了采集与存储的解耦。第一，它对采集 Agent 屏蔽了数据存储细节，仅暴露最简单数据投递接口；第二，DataHub 收到根据存储引擎特性使用最优写入模型，比如使用批量写入、压缩等方式；第三，使用 LVS、LSB 技术可以实现 DataHub 水平扩展。分布式文档数据库部分了解决扩展性问题，水平扩容用于解决存储容量不足的问题，schema free 的特性可以性能指标扩展性问题。
随着监控系统持续运行，数据库实例规模扩大，性能指标持续增加，监控系统用户扩大，又遇到新的问题。第一，DBA 同学常常需要查看数据库跨越数月的性能趋势，以预估数据库流量未来趋势，这时系统查询速度基本不可用。第二，存储长达一年的全量性能数据，成本变得越来越不可承受，每年双 11 压测时，DBA 同学总会问起去年双 11 的性能趋势。第三，DataHub 存在丢失采集数据的隐患，由于采集原始数据是先 buffer 在 DataHub 内存中，只要进程重启，内存中的采集数据就会丢失。
第三代监控系统
关于查询速度慢的问题，文档型数据库和关系型数据库一样，都是面向行的数据库，即读写的基本数据，每一秒的性能数据存储一行，一行 N 个性能指标，性能指标被存储在以时间为 key 的一个表格中。虽然同一时刻的所有性能指标被存在同一行，但是它们的关系却没那么紧密。因为典型的监控诊断需求是查同一个或几个指标在一段时间的变化趋势，而不是查同一时刻的指标（瞬时值），比如这样的：
数据库存储引擎为了查出某个指标的性能趋势，却要扫描所有指标的数据，CPU 和内存都开销巨大，显而易见，这些都是在浪费。虽然 Column Family 技术可以在一定程度上缓解上面说的问题，但是如何设定 Column Family 是个巨大挑战，难道要存储层的策略要和监控诊断层的需求耦合吗？这看起来不是好办法。
所以，我们把目光投向列式数据库，监控性能指标读写特征非常合适列式数据库，以 OpenTSDB 为代表的时序数据库，进入我们考察视野。OpenTSDB 用时间线来描述每一个带有时间序列的特定对象，时间线的读写都是独立的。毫无疑问，OpenTSDB 成为第三代监控系统架构的一部分。
为了消除 DataHub 稳定性隐患，引入分布式消息队列，起到削峰填谷作用，即使 DataHub 全线崩溃，也可以采用重新消费消息的方式解决。分布式消息队列，可以选择 Kafka 或 RocketMQ，这些分布式消息队列已经具备了高可用能力。
第三代架构相比过去有巨大的进步，在 2016 年双 11 实现了全网数据库 10 秒级监控，核心数据库集群 1 秒级监控。
随着阿里生态扩大，全球化深入，各类全资子公司业务全面融合到阿里体系，除了中国大陆，还有美国、欧洲、俄罗斯、东南亚的业务。同时在阿里数据库领域的新技术应用层出不穷，单元化部署已经成为常态，容器化调度正在覆盖全网，存储计算分离正在不断推进，同一个业务数据库集群，在不同单元的部署策略可能也不同。与之对应的，DBA 团队的规模并没有相应扩大，一个 DBA 同学支持多个子公司业务是常态，有的 DBA 还要兼任新技术推广等工作。在数据库性能诊断这个环节，必须为 DBA 争效率，为 DBA 提供从宏观到微观到诊断路径显得越来越迫切：从大盘到集群、到单元、到实例、到主机、容器等一站式服务。
在这样的诊断需求下，第三代监控架构有点力不从心了，主要表现在查询：
1）高维度的性能诊断查询速度慢，以集群 QPS 为例，由于 OpenTSDB 里存储的每一个实例的 QPS 数据，当需要查询集群维度 QPS 就需要对扫描集群每一个实例的 QPS，再 group by 时间戳 sum 所有实例 QPS。这需要扫描大量原始数据。
2）OpenTSDB 无法支持复杂的监控需求，比如查看集群平均 RT 趋势，集群平均 RT 并不是 avg(所有实例的 RT)，而是 sum(执行时间)/sum(执行次数)。为了实现目标只能查出 2 条时间线数据，在监控系统内部计算完后再展现在页面中，用户响应时间太长。
3）长时间跨度的性能诊断速度慢，比如 1 个月的性能趋势，需要扫描原始的秒级 2592000 个数据点到浏览器中展现，考虑到浏览器展现性能，实际并不能也没必要展现原始秒级数据。展示 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 万项性能指标，平均写入 TPS 600 万，峰值 TPS 1400 万，下图是双 11 期间 HiTSDB TPS 趋势曲线。
关键优化点
用这么少的计算资源就实现了这么高吞吐量，必然用上了许多黑科技。
1）在预计算中，我们使用增量迭代计算，无论是 5 秒精度的数据，还是 15 分钟精度数据，我们不需要等时间窗口内所有的性能指标收集满了，再开始计算，而是来多少性能数据，就算多少，仅保留中间结果，极大的节省内存。这项优化，相比常规计算方法至少节省 95% 内存。
2）采集端，针对性能数据报文进行合并，把相似和相邻的报文合并在一起上报到 kafka，这样可以让 JStorm 程序批量处理数据。
3）利用流式计算的特性实现数据局部性，同一个集群单元的实例采集到的数据在同一个 kafka 分区。这样可以减少计算过程的网络传输及 java 序列化 / 反序列化。这一项可以减少 50% 的网络传输。有兴趣的朋友可以想想为什么不能按实例分区或按集群分区，会有什么问题呢？
4）使用 JStorm 自定义调度特性，让具有数据相关性的计算 Bolt 调度在同一个 JVM 中，这个是为了配合上面第二步，实现数据流转尽量发生在同一个 JVM 里。
5）对于不得不发生的 Map-Reduce 数据传输，尽量使用批量传输，并对传输的数据结构进行复用、裁剪，少传输重复数据，减少序列化、反序列化压力。
未来展望
阿里 DBPaaS 全网秒级监控让数据库管控实现了数字化，经过这一年，我们积累了许多有价值的结构化数据。随着大数据技术、机器学习技术的发展，为数据库管控进入智能化提供了可能性。
1）智能诊断，基于现有全方位无死角的监控，结合事件追踪，智能定位问题。
2）调度优化，通过分析每个数据库实例的画像特征，让资源互补性的几个数据库实例调度在一起，最终节省成本。
3）预算估计，通过分析数据库历史运行状况, 在每次大促前，根据业务交易量目标，确定每一个数据库集群容量需求，进而为自动化扩容提供依据。
