Improve Summary quantiles with DataSketches

未关闭
#2,084 3 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
32/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
冷清
技术栈
java

调研方向

从 Summary.observe() 开始,跟踪 client_java 中当前基于 CKMS 的分位数路径。查看 ZooKeeper DataSketches Summary PR,并使用基准测试数据比较基于 KLL 的方案,包括准确性、内存占用和分位数可见性。完成的标准是形成有文档记录的方向,并有证据表明是否值得实现 opt-in 方案。

由索引模型根据 Issue 内容生成。

描述

Summary.observe() can become expensive when quantiles are recorded at high frequency. This can make the current quantile path visible on hot request paths.

We saw this in ZooKeeper's Prometheus metrics path. In an internal ZooKeeper 3.9.2 fork, a version inspired by ZooKeeper's unmerged DataSketches Summary PR improved peak throughput by about 2x.

DataSketches KLL may be a useful way to improve this in client_java. The goal would be to reduce the cost of the observe path while keeping the external Summary behavior as close as practical.

This would not have to replace the current CKMS-based Summary immediately. DataSketches KLL has a different accuracy model, memory cost, and quantile visibility behavior, so an explicit opt-in path may be a better first step.

Initial questions:

  • Does using DataSketches for Summary quantiles sound like a direction worth exploring?
  • If so, would a separate opt-in artifact be a reasonable way to introduce it?
  • What behavior details and benchmark data would be most useful before going further?
主要语言
Java
星标
2.3k
派生
833
平均合并
2 天 16 小时
30 天内合并 PR
86

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

prometheus/client_java 的其他 Issue

查看 prometheus/client_java 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。