用 Sketch 算法把 OpenTelemetry 里的 GenA
前两天在 GitHub 上刷到 llm-measurement 组织新推的 otelcol-genai-sketches，瞄了一眼 README 发现它解决的正好是我上个月在生产环境踩过的坑：把几十万条带 prompt 的 span 直接扔进 Tempo 再跑 PromQL 聚合，基数爆炸不说，合规审计那关根本过不去——原始文本一旦离开业务 VPC 就算泄露。
Clone 下来跑
对比同场景下直接用 Datadog APM 或 Grafana Cloud Traces 存全量 span，存储成本差了两个数量级，查询延迟从 10 s 级降到 200 ms 以内。
下一篇
LilScript 号称比 terser 还能压 15% →
这个连接器的思路很硬核：在 Collector 里就把 trace 用 Count-Min Sketch + HyperLogLog 摘要成三类指标，完全不落盘原始 prompt：
- 精确计数：请求总数、token 总量（input/output 分开）
- 基数估算：去重用户数、去重 prompt 数
- 重点标记：token 占比最高的 Top-K 请求
Clone 下来跑
make example-up 大概两分钟，本地就能拉起 Collector + Prometheus + Grafana 全家桶。Dashboard 里直接能看到 genai_requests_total{model="gpt-4o"}、genai_unique_prompts_estimate 这种指标，配合 histogram_quantile(0.99, genai_token_bucket) 秒出 P99 延迟，根本不用写 LogQL 去解析 span attribute。实测跑了自家 12 万条真实调用 trace，内存稳在 40 MB 左右，误差率：
- 请求计数：0%（精确计数器）
- Token 总量：<0.3%（64-bit 计数器）
- 去重用户/提示词：≈1.8%（HLL p=14）
- Top-K 重点请求：全命中（CMS width=2000 depth=5）
对比同场景下直接用 Datadog APM 或 Grafana Cloud Traces 存全量 span，存储成本差了两个数量级，查询延迟从 10 s 级降到 200 ms 以内。
唯一要注意的：GENAI_SKETCH_SECRET 必须在所有 Collector 实例间保持一致，否则 Sketch 合并会算错。生产环境建议用 SealedSecret 或 Vault 注入，别硬编码在 ConfigMap 里。
源码里的 sketchlib 单独发包（llm-sketchkit），Go 调用零依赖，想嵌进自家 Collector 也只需 import 两行。作者在 README 里专门写了「Why not DataSketches」对比，核心是针对 GenAI 字段做了 schema-aware 优化，体积再砍 40%。
有同学在用 Otel 做 LLM 可观测性的，建议直接把这个 connector 插在 processor 链尾部，省得再搞一套偏线分析管道。
免费 AI 工具箱 · 全部完全免费
全部回复 （3）
老
老陈
专家
9小时前
看了下 repo，sketch 的 merge 策略是用的 Count-Min 还是 KMV？README 里没细说误差界。Phoronix 测过类似 sketch 在高基数流下的相对误差，实际跑一下 TPC-DS 能看到多少偏移star 了，回头把 HyperLogLog 和 Theta Sketch 拿同一批 trace 跑个对比，看看内存占比。有没有现成的 Python binding？Rust 侧 FFI 封装得sketch merge 能否增量 checkpoint？我们要在 Flink 里做 exactly-once 恢复，这块最头文档里提到的 “mergeable” 是指可结合性还是可交换性？两者在分布式聚合时语义差GitHub Actions 里跑基准测试了吗？想看看 10M keys 下 p99 延迟。刚好在调研 streaming cardinality estimation，这个库的 API 设计比 datasketches 直观不有没有考虑把 sketch 序列化成 Arrow/Parquet 直接落盘？省得再转一README 例程里的相对误差 2% 是在什么分
0
运
同问，cardinality explosion最烦人了，你是用什么方案缓解的？ cardinality爆炸太头疼了，最后是用relabel还是drop搞定之前也被cardinality坑惨了，后来改用recording rules预聚合才好这块儿踩过坑，label值别搞高基数的（像request_id、timestamp），直接炸 同款痛点，最后把高基数label全drop了，保留核心维度够用就cardinality控制全靠relabel_configs硬刚，写正则时手抖一次全完蛋 试过VictoriaMetrics的vmagent做预聚合，比Prometheus自带规则省心不主要还是label设计没想好，事后补救比较痛苦，新项目直接按低基数设计了如果是k8s环境，kube-state-metrics那些metric默认label太多，建议先relabel砍一我们团队规定：label value超过100个唯一值必须review，强制限制基数上之前用PromQL顶不住，改Thanos sidecar后查询层聚合，写入端压力小多cardinality问题本质是成本问题，我们直接上Gra
0
远
