I see the distributed system observability

Author | Huang Dongxu

Zebian | Guo Rui

Today's article I want to talk about this from the blurry photos below, I believe that many small partners of this picture is not new, this is the picture of the human central black hole M87 for the first time last shot. From 1915, Einstein's theory of relativity predicted the existence of black holes in 2019 for the first time we finally "see" a black hole looks like, in the middle separated by a full 100 years, which for the human understanding of black holes and the universe is a recognized landmark event. Human is an emotional animal, so-called "a picture is worth a thousand words" information often convey a picture of more than a thousand words. I do not want to expand too much about black holes, and today we talk about "telescope."

M87 is located in the center of the supermassive black hole schematic (© EHT Collaboration)

A few days ago, in TiDB development branch 4.0, we introduced a new feature called: Key Visualizer (below referred KeyViz), speaking this gadget is not complicated, it is to use different colored boxes to display the entire database different frequency where the data access and traffic. We are only just beginning to position it as a DBA to assist to solve tuning gadgets database hot issues, but since last night I've been playing with this little thing, I suddenly felt it behind for a distributed database for the meaning far less than this, the CNCF definition of Cloud Native in, there is a called "Observability" universal translator called system of "observability", in the past I have been struggling to find an example to show what the system is called a "observable" in on KeyViz this project, I found the perfect manifestation of this point.

A few small examples of intuitive, you know what it's like TPC-C test "long" it? See below:

(KeyViz to TPC-C shot "photo")

Highlights the figure on the left is sporadic data import process, the horizontal axis represents time and the vertical axis is the distribution of data, you can see written dispersing a plurality of blocks on the right-intensive real-time color is read when the test run of the system write state. It represents a darker smaller the flow, the brighter the higher the flow rate, from the dense color we can see that, substantially uniform distribution of workload, but probably there are two distinct partial bright region, which has a top on a special significant local hotspot access (brightest that line).

第二个例子，你见过 Sysbench 测试「长」什么样子吗？看看下面。

左边比较密集的黄块是导入数据阶段，后半段明暗相间的部分是进行 oltp_point_select 测试，因为选取的模式是 uniform 模式，并且导入的时候是 32 线程 32 张测试表，可以看到的数据和分布和访问都比较均匀。

如果你看懂了上面两个小例子，下面是一个小作业，这是我们模拟的一个实际用户的生产环境的照片，这个用户的系统遇到了一些瓶颈，你能看出问题吗？

上面几个小例子是让大家对 KeyViz 有个感性的认识，在介绍这个东西背后的意义前，我想先介绍一下 TiDB 这类典型的分布式数据库的系统架构，方便大家更好的理解。

（一个典型的分布式数据库的数据分布策略）

顾名思义，分布式数据库，数据一定是分散在不同机器上的，对于一张表的数据，我们会在逻辑上切分成若干个连续的区间，将这些区间内的数据分给不同的机器存储，不管是写入还是读取，只需要知道目标数据属于哪个区间，就可以直接到那个机器上进行访问。然后加上对每一个区间的数据在物理上做多副本冗余实现高可用。如下图所示，Region 在 TiDB 的内部就是一个个连续的数据区间。

和很多分布式数据库不太一样的是，我们的 Region 的大小比较小（默认 96MB) ，另外数据的分布并不是静态的，而是动态的，Region 会像细胞一样分裂/合并，也会在不同机器之间移动进行动态的负载均衡。

现在回头看这个设计，还是觉得无比的简洁和优雅。对用户而言再也不用去思考怎么分库，怎么分表，数据在最底层的细胞就像有生命一样繁衍和迁徙。

然后问题就来了，对于这样的一种数据库而言，有没有一种办法能够直观的描述的系统的运行时状态？我怎么知道它是不是「生病」了？我能不能预测这个系统的未来？我能不能发现未知的风险？

过去，不管是业务开发者还是 DBA，衡量一个数据库的状态，来来回回就是几个指标，QPS 、TPS、查询时间、机器负载（CPU、网络、磁盘），但是很多时候就像是盲人摸象一样对于系统的全局我们是不清楚的，在加上在一个分布式的架构下，很多时候，我们可能会被海量的数字蒙蔽了双眼。有经验一些的 DBA 可能能从多个指标里通过自己的经验模糊构建出业务全局状态，但是到底这个经验常常是不可描述的，这就是为什么一些老运维，老 DBA 那么值钱的原因，但是我认为这种做事方式是很难 scale 的。现代医学有 CT 有 B 超有核磁共振，这些现代化的手段极大的促进了现代医学的发展，因为我们第一次能「看见」我们身体的内部状态，从而才能得出正确的判断，在计算机的世界道理也是相通的。

过去经常有朋友问我：「你说我这个业务适不适合使用 TiDB？」这时我们只能问，你的 QPS 多少 TPS 多少，数据量多少？读写比？典型查询？数据分布怎么样？表结构是什么呀？等等一连串的灵魂拷问，而且很多术语都非常专业，不是在这个行业摸爬滚打很久的老司机可能都搞不太清楚。有些信息可能是敏感的，也不方便共享。所以到底适不适合就成了一个玄学问题，这个问题困扰了我很久，很多时候也只能凭个人感觉和经验。

其实这个问题也并不是 TiDB 特有，尤其是最近几年，几乎所有现代的分布式系统都或多或少有类似的问题。在过去，一个物理机器的状态确实可以通过几个监控指标描述，但是随着我们的系统越来越复杂，我们的观测对象正渐渐的从「Infrastructure」转到「应用」，观察行为本身从「Monitoring（监控）」到「Observability（观测）」。虽然看上去这两者只是文字上的差别，但是请仔细思考背后的含义。关于这个话题，我很喜欢引用下面这张图：

这个坐标描述了一个我们对系统的理解程度和可收集信息的关系，在 X 轴的右侧（Known Knows 和 Known Unknowns）这些称为确定性的已知和未知，图中也给出了相对应的例子，这些信息通常是最基础的普适的事实，也就是在系统上线之前我们一定就能想到，一定能够监控起来的（CPU Load，内存，TPS，QPS之类的），我们过去已有的大多数运维监控都是围绕这些确定的东西。

但是有一些情况是这些基础信息很难描述和衡量的，例如这个坐标的左上角：Unknown Knowns，用通俗的话来说，叫做「假设」。举个数据库的例子：有经验的架构师在设计一个基于分布式数据库的应用时，通常不会将表的主键设成自增主键，会尽可能的用 UUID 或者其他方式打散数据，这样在即使有突发写入压力的时候，系统也能很好的扩展。

注意在这个例子中，其实假设的事情（写入压力突然增大）并没有发生，如果在日常压力不大，数据量不多的情况下，即使使用自增主键，从已有的基础监控中，可能也很难看出任何问题。但是到出事的时候，这个设计失误就会变成 Unknown Unkowns（意外），这是任何人都不想看到的。有经验的架构师能通过种种的蛛丝马迹证实自己的推测，也从无数次翻车的 Post-mortem 中将 Unknown Unknowns 的范围变小。但是更合理的做法是通过技术手段描绘系统更全面的状态，在 Cloud Native 和微服务的世界里，最近几年一个行业的大趋势是将系统的可观测性放在一个更高的位置（监控只是可观测性的一个子集），这是有道理的。

回到数据库的世界，TiDB KeyViz 的意义在于，就像上面提到的，这个工具不仅仅是一个监控工具，而且它能以一个非常低门槛且形象的方式让架构师具象化的看到自己对于业务的「假设」是否复合预期，这些「假设」不一定是能够通过监控反映的，以获得对业务更深刻的 Insight。

还是说回上面那个主键的小例子，对于两种不同的主键设计，KeyViz 这边是怎么表现的呢？看看下面两张图，是不是非常一目了然。

所以现在如果有朋友问我，这个业务适不适合 TiDB？我只需要通过录制线上流量，或者搭建一个从集群，只需要把 KeyViz 的图给我看一眼，我甚至都不需要压力测试就能判断这个业务是否适合，而且即使不适合，我也能准确的给出修改建议，因为 KeyViz 的图对我的「假设」的可解释性有了很强的支持。

不妨从这个方向我们再放飞一下想象力，为什么人类能够一眼就从这图片中理解这些信息，这说明这些图形背后有模式，有模式我们就可以识别，想象一下，如果所有的 TiDB 用户，都使用 KeyViz 将自己的系统具象化后分享出来（其实这些图片已经高度抽象，已经不具有任何的业务机密信息），我们是不是可以通过机器学习，挖掘背后更深层次的价值？AI 能不能通过这种形式更加理解我们的业务？

最后，我想以我最喜欢的科幻小说《三体：黑暗森林》中的一段话结束这篇文章，大致是面壁人希恩斯在冬眠后被妻子唤醒后的一个场景：

「...与此同时，希恩斯感觉到围绕着他们的白雾发生了变化，雾被粗化了，显然是对某一局部进行了放大。他这时发现所谓的雾其实是由无数发光的小微粒组成的，那月光般的光亮是由这些小微粒自身发出的，而不是对外界光源的散射。放大在继续，小微粒都变成了闪亮的星星。希恩斯所看到的，并不是地球上的那种星空，他仿佛置身于银河系的核心，星星密密麻麻，几乎没有给黑夜留出空隙。

“每一颗星星就是一个神经元。”山杉惠子说，一千亿颗星星构成的星海给他们的身躯镀上了银边。」

作者：黄东旭，分布式系统专家、架构师、开源软件作者。PingCAP 联合创始人兼 CTO，知名开源项目 Codis/TiDB/TiKV 主要作者，曾就职于微软亚洲研究院、网易有道及豌豆荚。2015 年创业，成立 PingCAP，致力于下一代开源分布式数据库的研发工作，擅长分布式存储系统设计与实现，高并发后端架构设计。

声明：本文系作者投稿，版权归作者个人所有。

【End】