贝壳『全新可观测平台』提效20倍，释放百亿日志生产力

导语

贝壳作为国内最大的房产服务公司，数据量级与系统个数可想而知。在系统如此复杂与庞大的状况下，却丝滑的完成了运维平台由自建到云上的迁移，这背后到底做对了什么？

一、现状分析

随着近些年房地产行业的蓬勃发展，贝壳原有系统局限性逐渐开始影响业务高速发展，包括：

• 数据联动少：贝壳需观测的内容繁多，包含了日志、监控、链路等各维度内容。很多老系统沿用至今的系统组件众多，这些系统数据彼此间缺乏联动，无法做到统一运维。
• 性能跟不上：数据写入上，因业务需统一时间结算、每天业务结算的时候数据量增长十倍以上，峰值压力很大；数据查询上，贝壳较大的业务单日的数据写入量已经超过百亿条，一旦查询范围稍大，会经常发生查询超时状况，影响运维效率。
• 数据没法用：当前所有的自建系统缺乏体系化的展示能力，首先是数据格式化不够，其次是数据聚合分析函数少，无法满足业务需求，比如一些IP地理函数，最后是开源展示工具不方便分享转发。

二、解决方案

贝壳业务部门众多，业务逻辑由各部门自己负责，但是所有的运维测内容由运维团队统一设计落地，为了解决上面问题且在不会大量侵入业务逻辑的情况下，运维部门急需构建一套能够统一运维且高性能、高可靠的可观测平台。支持多源数据接入，可高效分析处理数据，随时弹性扩缩容，同时提供直观灵活的可视化的能力。经过对业务系统需求的详细梳理、及多轮沟通，CLS 团队协助贝壳团队最终完成了全新统一观测平台系统架构设计。

三、方案详情

一、数据采集：解决写入延迟，维持原有写入逻辑

1、十倍峰值导致十几分钟延时，如何提效？

贝壳运维准备改造系统之初是为了解决写入延迟的问题。如上文所讲，在每天业务统一结算时，如果有大的延迟是不可接受的，常规业务部门会需要查询当天的数据进行核查，延迟上报非常影响效率；特殊情况还会影响排查效率。

选择 CLS 时， 以为 CLS 强大弹性能力可以轻易解决数据写入延迟的问题。但经首次测试却发现，延迟并没有很好的缓解。条件反射的方案，便是通过扩充云上资源来解决，然而效果并不明显。

为了解决上述问题，CLS 团队与贝壳团队一起进一步研究分析发现，性能瓶颈主要出在 FluentD kafka output 使用的 rdkafka 组件上，而仅通过调节 rdkafka 的参数来提升性、已经无法满足在贝壳量级下的数据传输；为此 CLS 团队自主研发了Fluentd Output 插件（已在社区发布）。

最终将原系统数据上报延迟降低到了分钟级，数据产生到可检索的时延从十几分钟到 1 分钟内。

2、多样的数据源如何快速接入？

贝壳在改原有系统时还有一个痛点是，无法找到合适的方案来统一融合所有组件来打造整体可观测性平台。

贝壳现有运维系统繁多，包含使用 Prometheus 自建的指标系统，使用 Skywalking 自建的 Tracing 系统，以及使用 ES 和 Loki 混合搭建的日志系统（包括网络、业务、安全等多种日志）。

在云原生改造的背景下，贝壳绝大多数的环境都已经切换到了容器环境，并使用 FluentD 做为日志收集开源组件，但是由于业务部门众多，每个部门都有独立的采集逻辑。

而对于 tracing 业务，虽然贝壳已经统一使用 skywalking 作为解决解决方案，但是由于性能和定制化的需求导致和社区开源的方案相差颇大。所以面对一个完全解耦的 skywalking，为了能把数据上云，需要替代的方案能够从数据接入到查询都能提供兼容原有逻辑的兼容能力和更优的性能优化。

在这种情况下，最简单快捷的迁移方式、便是有套系统可以兼容原有系统的传输协议，运维同学只需要修改传输的目标地址、无需替换采集方式；这样既节省了修改各个业务系统数据采集方式的繁重工作、又避免了新采集方式对多种系统适配可能带来的异常。

为此，CLS 打造了云上集成接入方式，可实现不同类型的传输协议分类接入，如：

• 日志数据（ES/Loki）：继续使用原采集器 Fluentd 、只需要修改上报的 endpoint，既可通过 Kafka 协议实现数据上传；
• 指标数据（Prometheus/Skywalking）：兼容原生 Skywaking 生态，使用 CLS-GO SDK 写入 Tracing 数据，和 ES API 查询数据。

通过以上的多种方式，贝壳的网络日志、安全日志、Tracing 等多个模块统一接入CLS 打造统一的运维平台。

除此之外，贝壳还根据业务需求，对关键业务模块配置了流量的变化告警，随时掌握流量情况，并通过流量变化提前感知业务异常，实现排障的主动出击。

二、 数据处理：可视化处理、百亿级日志秒级检索

1、 非结构化的原始数据如何高效处理？

贝壳由于业务部门众多，导致日志格式千奇百怪，常规的日志收集工具不能有效的格式化。同时由于各部门日志格式无法统一，就要求有可下放的解析规则配置页面，方便各条业务线能按照自己的格式来编排解析规则。

为了满足上面的需求，CLS 在所有日志集中上报后，提供了日志存入主题之前的数据处理通道，并且独家提供了可视化的数据处理画板，方便用户直接使用图形化界面按需编辑日志的结构化过程，直观又明了。参见下图示例，贝壳的业务日志先使用分割符切分，再通过正则提取对应的字段。

注：上图为模拟数据

2、 大量原始数据如何提取有效结果？

贝壳由于日志量非常大，且部分业务由于合规需求需要长期保存，这样一来存储时间长带来了很大的成本开销，二来如果需要聚合分析的时候，直接分析全量的数据会非常影响分析效率。

面对这两个痛点，使用CLS的定时SQL + 混合存储可以很好的解决问题。混合存储支持把长时间的存储分层，短期热数据满足分析，长期冷数据可以沉降为低频，随时支持查询又能兼顾成本。

同时数据加工可以定时聚合结果，把复杂的日志精简成直观的指标长期保存。以贝壳安全日志为例，所有员工的办公环境内、Windows 机器事件日志收集到 CLS 后，安全部门需要从庞大复杂的日志中分析安全隐患、并即时展示和触发告警。

CLS 提供的定时SQL 功能完美解决了上面业务逻辑，贝壳共设置了上千条SQL 逻辑，按照规则名称、告警等级、主机名多个维度汇总结果数据。定时SQL 每分钟汇总记录一次结果并保存，复杂无序的数据聚合成业务关心的逻辑指标，一来满足了业务展示告警的需求，能实施监控安全状态，二来精简了数据总量，方便长期保存。

3、 数百亿日志如何提升数据检索分析能力？

随着贝壳数据量爆发式的增长，原有系统的查询速度明显下降，尤其在业务高峰期，需要从 500 多亿条日志中检索结果、延迟甚至达到分钟级，充分考验了运维与运营人员的耐心，也严重降低了其工作效率。其运维团队迫切需要一个性能强劲、分析高效的运维平台。

切换至CLS后，贝壳 500多亿条日志单次实时检索平均用时仅需 10s，检索效率较原系统提升了6倍+，真正实现了可观测平台的实时性。

三、 结果展示：运维大盘开箱即用，3000+用户无感切换

1、 多种指标数据，如何直观展示与便捷分享？

贝壳之前的系统多为开源组件，使用 grafana 一类的展示组件时有两个问题，一是形式比较固定且配置比较繁琐，二是和国内办公化工具的结合成为大问题。一般grafana 只适合登录PC控制台查看，也不方便分享转发。

当数据采集至 CLS 后，贝壳运维同学仅需在产品控制台简单配置，便实现了多种可视化大盘，也方便快速分享到多端的设备：

• 实时网络看板：访问量、拦截情况、上行下行流量趋势等多维度数据。而这些内容通过在 CLS 预置仪表盘的模板基础上，经过简单配置就可完成，便捷易用。
• 运营大盘：一站式查看各部门业务数据的多维统计图表，还可跳转联动分析，实现数据快速下钻。
• 多端共享：通过使用独立控制台 DataSight，监控大盘可以便捷的在PC与移动端分享转发，方便不同部门间分享实时数据报表，减少沟通成本；或者将数据看板直接通过邮件或办公软件群发，同步或汇报数据结果。

贝壳运营大盘示例（图中均为模拟数据）

2、上千人员权限管控，如何无感知切换？

上云前，贝壳已有上千个独立的研发人员在用的“贝壳云” 运维平台，不同业务人员分权分域、数据隔离。系统上云，若为众多研发人员创建腾讯云账号非常不现实；且内网环境和人员的频繁变化，亦使账号管理繁复；同时，还需考虑原有人员的权限的沿用，保证其只看到自己负责的资源。

使用 CLS 独家的内嵌式、开箱即用的 DataSight 独立控制台，便可巧妙地解决上述问题，DataSight：

• 支持内嵌并提供内网外网多种方式接入，贝壳原有系统直接接入，使用习惯不变。
• 提供独立的日志入口，贝壳可定制账号密码登录、独立管理，不依赖腾讯云体系。
• 允许对接用户自己的 LDAP 来做权限管理，继承原系统已有账号权限。

四、方案总结

经过从数据采集、数据处理到结果展示各环节的改造，原有问题一一破解，贝壳全新可观测平台的雏形初步成形。

• 上千业务板块1人天无缝接入CLS，新旧系统切换丝滑，用户使用习惯不受影响。
• 10 倍峰值数据上传、耗时由十几分钟降至分钟级，整体业务效率20倍提升。
• 百亿条数据检索由分钟级降至秒级，检索时效提升6倍+，真正实现了可观测平台的实时性。
• 直观的可视化大盘，业务数据一目了然，流量变化告警监控，随时掌握。

END