浅谈可观测性生态的优化和丰富

本次分享主要介绍了蚂蚁集团统一可观测性平台的工程技术体系。通过对技术架构的分享，透视为何蚂蚁能将自基础设施到业务，乃至客户端的可观测能力融合到统一平台，为公司运维与稳定行保障提供基础底盘。分享中将会着重介绍两大核心技术点：大规模实时采集与预计算系统、自研并已开源的时序数据库 CeresDB。本次分享会逐步揭秘蚂蚁在可观测领域的技术选型与技术演进方面的思考。
为了探究云原生应用系统的内部状态，我们希望向观测数据中注入尽量丰富的标签，这些标签以往通过开发人员手动在代码中注入，或通过配置 Promtheus、OpenTelemetry 实现，一方面造成了很大的工作量和资源开销，另一方面也导致不同信号源的数据标签不一致形成数据孤岛。
DeepFlow 依靠 AutoTagging 机制可以为所有观测信号统一注入标准的、丰富的标签，很好的解决了这些问题。本次直播将会为大家解密支撑 AutoTagging 高性能的关键机制 SmartEncoding。通过对标签数据的分离编码和查询时关联，我们将存储开销降低了 10~50 倍，并且能支持无限量的 K8s label/annotation 等信息作为业务自定义标签。通过 deepflow-server 提供的 SQL API，这些编码和关联机制对使用者完全透明，就像在一张大宽表上直接查询。
Q1｜多集群场景下，时序数据库要如何 hold 住海量数据？
A：a）如果多个集群分布在地理上隔离很远的几个区域，比如上海到深圳甚至大西北，那么这个时序数据库不同集群的资源和节点数量需要对读写的区域分布进行匹配，这样可以获得最好的性能，数据就近存储。
b）另外 hold 海量数据其实和单集群的内部比较有关系，主要通过内部的分 shard 和表迁移的机制，提供水平扩缩容的能力。这些能力主要是由 ceresmeta 组件提供的。
c）实际在生产环境中，除了以上的时序数据库本身的功能需要提供支持外，还需要有对应的运维平台配套，保证生产环境的长周期稳定性。
Q2｜trace 相关蚂蚁内部仍然使用的 SOFAStack 吗，有考虑过新的迭代吗？
A：目前蚂蚁内部仍然在使用 sofa tracer。暂时 sofa tracer 对蚂蚁的系统可观测性来说是沟通的，因此短期内没有大的更新迭代。
Q3｜如何参与到 CeresDB 社区的贡献？
A：a）参与到 CeresDB 社区可以通过任何形式，我们在 github 代码仓库的 Issue 板块中分解了很多细粒度的工作任务，大家可以从里面选择感兴趣的 issue 进行提问或者贡献代码。有任何不清楚的内容也可以在 Issue 中发起新的提问，我们同事会尽快解答。
https://github.com/CeresDB/ceresdb/issues
b）关于文档，目前确实和我们的开发进度上有一些脱节，不过由于 CeresDB 在 2 月份会进行 1.0 版本的正式发布，我们会在发布前补全开发和使用文档。
Q4｜trace 的存储采用什么方案呢？
A：这个问题比较复杂，由于本次分享中主要是讲了 Metrics 的存储，因此不做过多展开。我们目前内部有自研的 trace 存储（本质上 trace 和日志存储我们是同等对待的），类似阿里云的 SLS。
Q5｜ 社区版和自用的功能上有啥区别？支持 Prometheus 吗？
A：a）CeresDB 社区版和内部版本是没有区别的，为保证版本永不分叉，目前我们在蚂蚁内部已不再有 CeresDB 代码仓库（直接删了），所有研发活动都在 github 上进行。
b）Prometheus 的支持工作将在 2 月份完成。
Q6｜蚂蚁的这个自研别人能用吗？
A：可以使用，我们的开源产品的许可证是 Apache 2.0，这个许可证保证用户可以不受限制的使用该产品，甚至进行二次开发。是一个宽松的许可证。
Q7｜这个 join 是时序写入时做的对吧？
A：概念上可以这么认为。不过明确的讲，具体是在预计算的阶段做。在数据完成第一轮清洗解析（非结构化数据转化成结构化 metric ）之后。spark 上处理这些预计算的时候，会从 dimservice 中读取需要 Join 的（小表）数据，然后进行 Join 操作。
Q8｜有哪些企业用了 CeresDB？
A：a）目前主要是蚂蚁集团，网商银行。服务了包括可观测性，金融投资分析平台等场景。
b）外部用户目前在接触中的有理想汽车，恒生电子，财通证券等。不过由于我们 1.0 版本要在下个月（2023 年 2 月）进行发布，client 的 API 可能还有潜在的变动，所以建议等 1.0 发布后使用。