为 Loki 添加 v2 存储驱动¶
本规范建议将 Loki 作为数据帧的新存储后端。
问题描述¶
CloudKitty 目前提供与多个存储后端(包括 Elasticsearch、OpenSearch 和 InfluxDB)的强大集成。虽然这些系统功能强大且适用于各种数据存储和查询需求,但它们的操作特性和资源占用对某些部署场景和用户生态系统提出了挑战。
Loki 正在容器化生态系统中成为日志存储和搜索的有力竞争者。凭借其相对简单的操作流程、对容器编排的原生支持以及与 Prometheus 的相似性,它似乎正在成为许多新的 Kubernetes/OpenShift 部署的首选。OpenShift 甚至将其作为其默认日志存储服务的一部分。
从技术角度来看,它是一个非常适合存储类似数据帧的数据的系统:带有动态字段的短 JSON 片段,并且易于快速搜索。Loki 是一个非常适合处理这种数据类型的摄取和搜索系统,并且具有非常好的性能:这正是它被设计用来解决的问题。
提议的变更¶
拟议的更改将为数据帧添加一个新的 v2 存储后端选项,该选项将实现与 OpenSearch 的功能对等,但基于 Loki。这意味着它将支持完整的 v1 和 v2 API 集,但不支持 summary API 中的 custom_fields。
该更改将包括单元测试、一个新的 Zuul 作业以及 tempest 测试,以及一个 Loki devstack 插件,用于 CI 和开发需求。
总结¶
通过支持 Loki 作为存储,我们将使 CloudKitty 保持更新并与可观察性生态系统中的最新趋势保持一致,为用户提供新的选择,并使 CloudKitty 更易于采用,如果他们已经为日志存储运营 Loki。
备选方案¶
无
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
Juan Larriba <jlarriba@redhat.com>
工作项¶
创建一个新的 Loki 文件夹来包含新驱动程序的文件
编写一个 LokiClient 类,以抽象 Loki API 交互
定义新存储系统接受的配置参数
编写一个 LokiStorage 类,该类扩展 BaseStorage 并使用 LokiClient 从 Loki 提取数据并将其格式化为 DataFrames
为 LokiClient 编写单元测试
将 TestStorageUnit 扩展为包含一个新的 FakeLokiClient 模拟类
更改 setup.cfg 以在 cloudkitty.storage.v2.backends 中包含 loki 作为新的存储选项
修改当前文档以添加 Loki 选项作为新的存储后端,突出显示新参数
开发一个新的 Loki devstack 插件,以便我们可以在 CI 中部署 Loki
编写一个新的 CI cloudkitty-tempest-full-v2-storage-loki Zuul 作业,以自动测试 Loki 集成
依赖项¶
无
测试¶
单元测试
使用 Loki devstack 插件和 tempest 进行功能测试
文档影响¶
需要修改文档以说明有新的存储后端选项可用,并描述特定于新选项的新参数。
参考资料¶
无