2023年10月20日，博瑞数据2023秋季产品发布会圆满落幕，新一代一体化智能观测平台Bonree One 2023 Autumn发布，重点升级数据采集、全局拓扑、数据分析、会话回放等多个功能模块，为组织提供更轻量、更有序、更精准的超智能运维体验。 
文章信息
作者：博瑞数据中心-Holly数字智能中心大数据负责人;
本文由 InfoQ 发表。
背景
日志、指标和调用链是可观测性成功的三个要素，而这些要素的实现离不开数据采集、探头采集和上报数据、后端服务接收和处理分析数据以实现可观测性。 一般情况下，服务器性能数据、服务相关数据、服务间调用数据都是通过探针采集和上报的，经过ETL处理后，成为可观测性分析的重要依据。
探头收集的数据量取决于两个因素：
采样率：采样率越高，数据量越大，对应的可观测性分析越全面。
服务调用量：业务服务调用频率越高，对应的数据量越大，对应的可观测性分析也会越复杂。
2000探头的难度是什么？
由于私有化部署资源有限，需要尽可能满足企业的监控需求，因此博瑞数据的内测将以5台机器的集群为部署标准，在资源固定的前提下，随着探针数量的增加，主要难点如下：
业务场景有高峰波动，高峰时段服务呼叫是低峰时段的2倍+倍
业务数据同时存储在多个业务场景中，包括调用链数据、指标数据、服务快照数据等。
这五台机器是控制器服务、告警服务、业务查询服务、数据调用链存储、数据快照存储、数据指标存储、消息中间件等多种业务的混合体，在数据量写入较大的情况下，CPU、内存、磁盘IO的消耗是抢占的，影响了服务的稳定性。
如何优化**
鉴于上述困难，首先想到的是**，即减少服务组件的数量，减少服务资源的抢占。 二是业务存储迁移，摒弃高消耗组件，使用低消耗组件来满足业务需求。 最后，在合理的数据存储方案的前提下，对存储服务本身的性能进行优化，以满足业务查询的稳定性。
减少组件数量
Hadoop 存储套件节点数据量大，是 J**A 服务，消耗大量资源，需要大量内存。 Hadoop的主要业务端是AI服务，AI团队基于自研的数据处理框架构建了新一代的SwiftAI服务，只有一种组件类型，至少两种部署服务。
业务存储优化
目前，APM服务的存储分为指标数据、跟踪和快照三部分。 目前分别采用三种不同的存储系统对数据进行支撑：指标数据存储在ClickHouse中，Trace使用ES，快照数据存储在自研对象存储系统中。 在实际业务场景中，多个存储引擎交叉访问，在估算资源时没有合理的尺度来衡量资源的上下限。 如果在一台机器上部署多个存储引擎，势必会影响服务的稳定性，因此减少APM服务的存储组件成为可行的解决方案。
探针调用链数据基于ES存储，存在以下痛点：
跟踪数据的写入时间与关联的快照数据之间存在差异，并且写入基于 ES 的数据时存在延迟。 ·ES 消耗大量资源，但消耗大量 CPU 和 IO，影响其他服务的稳定性。·ES的查询效率不稳定，随着数据量的增加，甚至可能查询不对。
探针调用链的快照数据基于对象存储系统进行存储，存在以下痛点：
写入不稳定，并且存在故障。 ·它消耗大量的CPU和I/O，并且很容易达到瓶颈。
鉴于前两个组件存在明显的痛点，将数据迁移到ClickHouse进行存储，好处如下：
同时将Trace数据和关联的快照数据写入ClickHouse，以保证关联数据的一致性。 ·ClickHouse写入稳定，即使是检索数据，资源消耗小。·ClickHouse读取稳定，ClickHouse支持查询熔断、资源限制等方式，提高ClickHouse查询的稳定性。·基于合理的批量积累策略，ClickHouse整体资源消耗稳定，毛刺点波动小。
存储服务优化
如果将相关业务存储集中起来，势必会对ClickHouse服务产生影响，ClickHouse服务的优化和运维监控将更加重要。
在优化方面，我们从以下三个方向入手：
优化业务参数
外部分组依据前的最大字节数：当RAM消耗超过此阈值时，分组依据会将多余的临时数据输出到文件系统中，并在磁盘上进行处理，通常建议配置为当前服务内存的80%。
外部排序前的最大字节数：当涉及数据排序时，当 RAM 消耗超过此阈值时，Order By 会将多余的临时数据输出到文件系统中，并在磁盘上排序，通常建议配置为当前服务内存的 80%。
最大内存使用量：单个查询可以使用的最大内存，通常建议为当前服务内存的 80%。
最大执行时间：查询可以执行的最长时间，由服务响应时间的上限决定。
合理使用实例化视图、索引和投影
针对不同的场景采用不同的加速方式，解决查询效率问题。
高频查询应充分利用主键索引。
对于主键索引无法满足的高频查询，可以使用索引来加速。
在排序操作方面，使用投影和物化视图来加快速度，并且首选投影。
无法使用投影的场景可以使用实例化视图。
监控、容错支持。
为了解决多业务接入的复杂影响，需要对集群进行充分的监控，在容错方面需要考虑更多的因素。
监测
主要跟踪监控有写和读两个方向，如每分钟写入次数、写入消耗的时间、查询QPS。
监控节点的状态，如服务负载、合并任务数量、部分数量等，这些指标可以及时发现服务稳定性风险。
监控集群的余额，如分段数据同步的延迟时间、各节点的查询余额、各节点的写入余额等，防止集群偏差。
容错
单节点写入节点异常不会影响整体服务写入。
clickhouse单节点异常不会影响整个集群的写入或读取。
影响
AI 组件**。
将跟踪跟踪等相关数据迁移到 ck
为了实现最多可以支持2000个探头的5个簇，我们首先需要做的就是减去，以减少组件之间的冲击，这样单个组件才能发挥更大的效率。 然后，围绕这个组件，构建一个更全面的生态系统，包括监控、运维和运营。 最后，围绕业务使用场景进行深度优化，保证整体业务稳定性。
未来，我们将在ClickHouse内核上下功夫，不断拓展ClickHouse的使用场景，与开发者分享博睿数据在ClickHouse方向上的探索与实践，帮助Boree One朝着更快、更准确、更稳定的方向走得更远。
要了解有关Bonree One集成智能可观测性平台的更多信息，请单击本文末尾的“阅读更多”，免费**完整版《博瑞数据博瑞One集成智能观测平台***》。