背景

OceanBase 始创于 2010 年，是 100% 根自研的原生分布式数据库。OceanBase 基于单机分布式一体化架构，高度兼容 Oracle 和 MySQL，支持事务处理（TP）和实时分析处理（AP）等多工作负载，原生支持向量检索与多模数据混合检索，助力客户构建面向 AI 的一体化数据底座。已广泛应用于金融、运营商、零售、互联网及公共服务等行业，助力 2000+ 客户实现关键业务系统升级。

2022 年，OceanBase 正式推出云数据库 OB Cloud，通过一体化云数据库服务助力客户构建现代数据架构，简化技术栈。目前，OB Cloud 已覆盖全球 50+ 区域的 170+ 可用区，支持主流公有云基础设施，基于阿里云、华为云、腾讯云、百度智能云、AWS 和 Google Cloud 等提供全球范围内一致体验，满足客户多样的业务增长需求。

为了简化多云环境下的部署和运维，OB Cloud 选择了使用 Grafana Loki 来存储内部应用的日志。Grafana Loki 是一个高效的日志聚合系统，灵感来源于 Prometheus。与传统的日志管理工具不同，Loki 只索引日志的元数据（标签），而不是原始日志内容。Loki 也支持使用对象存储，具有较低的存储成本，是时下比较流行的日志存储方案。OB Cloud 基于 Loki 的日志存储架构如下图所示：

（图 1：OB Cloud 基于 Loki 的日志存储架构）

每个节点上部署的 Fluent Bit 负责采集该节点上各个应用 Pod 的日志，然后写入到 Loki 中；日志视图负责根据关键字等检索条件调用日志查询服务检索日志并将结果进行展示；日志查询服务会根据查询的条件构造 Loki 的查询并调用 Loki 的 API 查询日志。

随着业务的发展，Loki 的性能问题日益突出。对于数据量较大的日志，Loki 的检索经常会出现超时问题；此外，Loki 只支持对标签进行索引，无法通过索引来加速日志正文的检索；排查日志时只能把查询的时间范围缩短到分钟级，十分影响使用体验。这也导致日志视图页面的默认查询时间范围只能设置为数分钟。

在调研了多种日志存储方案后，OB Cloud 最终选择了使用 GreptimeDB 替换 Loki 来存储应用日志。在新的架构下，Fluent Bit 采集到的日志会写入到 GreptimeDB。而日志查询服务通过 SQL 协议查询 GreptimeDB 中的日志。将 Loki 替换成 GreptimeDB 后，原来在 Loki 上超时的日志查询在 GreptimeDB 上耗时可缩短到亚秒级到秒级。用户检索日志时可以指定更广的时间范围，体验得到了很大的提升。

（图 2：OB Cloud 基于 GreptimeDB 的日志存储架构）

GreptimeDB 在 OB Cloud 的实践

部署架构

OB Cloud 支持阿里云、华为云、腾讯云、AWS 和 Google Cloud 等主流云厂商的基础设施，其内部的日志服务也同样有多云部署的需求。OB Cloud 的 GreptimeDB 部署架构如下图所示：

（图 3：OB Cloud 的 GreptimeDB 部署架构）

OB Cloud 在不同的云上均部署了 GreptimeDB 的集群，并对接其日志系统。在不同的云上，GreptimeDB 直接使用该云厂商提供的对象存储服务，将数据存储在对应的云上。

由于 GreptimeDB 支持多种对象存储。用户可以很方便地在不同的云环境下部署 GreptimeDB，并使用对应云厂商的对象存储，而无需关心不同云厂商对象存储服务的差异。这天然适合 OB Cloud 这样有多云部署需求的用户。

GreptimeDB 对外暴露了统一的写入接口和基于 SQL 的查询接口，不仅可以降低用户的学习成本，也降低了开发适配的工作量。基于 GreptimeDB 统一的读写接口，OB Cloud 的日志系统能够在不同的云上提供一致的用户体验。同时，GreptimeDB 原生支持通过 k8s 部署和运维，内置的 Dashboard 组件也方便用户使用和调试。这些特性极大地提升了运维和管控的便利程度。

Pipeline 的应用

由于 Fluent Bit 写入往 GreptimeDB 写入日志是 JSON 格式的，因此 OB Cloud 通过 GreptimeDB 的 Pipeline 来对 JSON 格式的输入进行解析并提取字段，再写入到 GreptimeDB 的日志表中。例如，对于 JSON 中的日志文件名，服务器等字段，可以存到 GreptimeDB 相应的列上。这样用户在查询时可以指定相应的服务器名快速地筛选指定服务器上的日志。

在落地过程中我们发现，OB Cloud 部分应用的日志可能包含多个换行，不能简单地使用 dissect 进行切分。针对这类日志文件，我们最终使用了正则来提取日志的字段。

参考的 Pipeline 配置如下：

processors:
  - regex:
    fields:
     - message
    patterns:
     - ‘^(?P<timestamp>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}(\.\d+)?)[ ,](?P<message>(?s:.*))$’
    ignore_missing: true
  - date:
    fields:
     - message_timestamp
    formats:
     - ‘%Y-%m-%d %H:%M:%S%.3f’
     - ‘%Y-%m-%d %H:%M:%S%.6f’
     - ‘%Y-%m-%d %H:%M:%S%.9f’
     - ‘%Y-%m-%d %H:%M:%S%.f’
     - ‘%Y-%m-%d %H:%M:%S%’
    timezone: ‘Asia/Shanghai’
    ignore_missing: true
 transform:
  - fields:
    - message
   type: string
  - fields:
    - file
    - host
   type: string
   index: tag
  - fields:
    - message_timestamp,timestamp
   type: epoch, ns
   index: timestamp

Fluent Bit 调参

在使用 Fluent Bit 的过程中，我们发现在日志流量高峰期，很容易出现日志延迟的情况。在 Fluent Bit 侧，能够观察到有 mem buf overlimit 的日志。在排查的过程中，我们检查了 GreptimeDB 服务端的写入耗时，机器负载等各项指标，都没有发现明显的异常。瓶颈并不像是出现在服务端，而 Fluent Bit 自身的资源占用同样也并不高。

在研究了 Fluent Bit 的工作机制和进行了一些实验后，我们定位到了日志延迟的原因在 Fluent Bit 侧：

• Fluent Bit 内部维护了缓冲区（mem buf）用来存放采集到的日志，如果 mem_buf 写满了，Fluent Bit 就会暂停采集，出现 mem buf overlimit 的现象，即触发了反压；
• 用户可以通过 mem_buf_limit 参数设置缓冲区的大小，同时也能控制 Fluent Bit 的内存使用；
• Fluent Bit 的写入方式是定时将 mem_buf 中的数据写到输出端，间隔由 flush 参数控制；
• 如果 flush 设置得较大，而 mem_buf_limit 设置得较小，那么就可能出现 Fluent Bit 发送数据的速度跟不上业务数据产生速度的情况，在日志高峰期出现发送延迟；
• 如果日志发生了轮转，由于 Fluent Bit 默认检查文件列表的间隔是 60 秒，导致轮转后的文件需要较长时间才能被采集到。如有需要，用户可以调小检查的间隔，减少日志轮转时的采集延迟。这个参数由 Refresh_Interval 参数控制。

通过调整 Fluent Bit 的 flush 和 mem_buf_limit 等参数，能够极大地减少日志的延迟和出现反压的情况

索引的应用

与 Loki 不同，GreptimeDB 提供了更丰富和强大的索引方案。用户可以根据具体的场景，选择合适的索引来加速查询。在 OB Cloud，一个查询模式是根据关键字检索符合条件的日志文本。对于这种场景， Loki 只能暴力地进行日志匹配，而 Loki 的暴力匹配性能并不理想。

尽管 GreptimeDB 的暴力匹配性能也十分不错，但也提供了索引来加速文本的匹配。

用户可以按需开启：

CREATE TABLE db_log (
  ts TIMESTAMP TIME INDEX,
  message TEXT FULLTEXT INDEX
);

通过 matches_term 函数匹配出现了关键字 system failure 的日志：

SELECT * FROM db_log WHERE matches_term(message, 'system failure');

OB Cloud 为一些需要进行关键字匹配的日志文本创建了索引用于加速查询。

除此之外，如果用户的日志有明显的结构特征，还可以选择将常用的检索字段提取到新的列上，甚至为该字段单独创建索引。这样查询时可以直接指定该字段进行筛选，进一步提升查询速度。

效果与收益

目前，基于 GreptimeDB 的新日志架构已在 OB Cloud 的各个环境中上线，日均的日志写入量达亿行规模。使用 GreptimeDB 替代 Loki 为 OB Cloud 带来了以下收益：

面向大规模业务的日志管理与查询性能提升

日志查询的响应速度和准确性得到了显著的改善。GreptimeDB 支持更丰富的索引方式和高效的关键词检索，能够在大数据量的日志中更快地定位到特定的日志内容，从而大大提升了日志排查的效率。这为 OB Cloud 用户在处理大规模业务数据时，尤其在进行故障排查和性能监控时，提供更加流畅的体验。

多云原生，简化多云部署和运维

OB Cloud 的多云原生架构支持全球范围内的云平台部署。GreptimeDB 云原生、易于部署、与对象存储良好的兼容性等特点保证了其在不同云环境中的灵活性，帮助 OB Cloud 实现了多云部署和运维的简化。除此之外，这一特性还使得 OB Cloud 能够为全球客户提供一致的服务体验。对于企业用户，灵活的多云支持能够在保证高可用性的同时，增强系统的弹性与可扩展性。

增强用户体验和可扩展性

OB Cloud 在日志处理上的优化，尤其是对 Fluent Bit 的细粒度调优，进一步提高了系统的可扩展性和稳定性。GreptimeDB 与 Fluent Bit 的高效配合，使得 OB Cloud 能够在高流量、高负载的环境下，保持日志采集和存储的高效性。通过精细调节缓存和写入等参数，OB Cloud 能够有效减少流量高峰期时日志采集的延迟，避免日志积压的情况发生。这也保证了在用户业务需求激增的情况下，日志系统能够及时响应，保障用户体验。

参考文档

• Oceanbase 官网
• OB Cloud 云数据库
• GreptimeDB on Kubernetes
• Pipeline Configuration
• GreptimeDB 日志查询
• Fluent Bit Buffering & Storage
• Fluent Bit Tail