最新

嗨，HN，我正在构建RocketLogs，这是一个智能可观察性层，位于Loki、Tempo和Prometheus之上。 我遇到的问题是：凌晨3点接到警报，打开Grafana，在六个仪表板之间切换，搜索日志，试图弄清楚哪个版本发布了，过了一个小时你或许找到了根本原因。你仍然需要深入代码找到罪魁祸首。数据都在那儿，但没有任何东西将它们连接起来。 RocketLogs试图解决这个问题： VS Code / Cursor扩展 - 从生产环境中获取你的慢速和出错的端点，并将它们连同延迟信息列在Cursor聊天侧边栏中。它使用Pyroscope分析将这些端点映射到你的代码库中。因此，你可以在代码库中直接查看指标 -> 跟踪 -> 配置文件 -> 代码。它显示延迟以及模块/函数对端点的影响热图。这样你可以迅速跳转到有问题的函数并在几分钟内修复，而无需切换上下文。 除此之外，它还是一个完整的可观察性堆栈：日志搜索、带有瀑布视图的分布式追踪、带有错误预算跟踪的服务水平目标（SLO）、带有AI生成摘要的事件管理、智能警报和Prometheus仪表板。 我们基于LGTM堆栈构建，因此如果你已经将数据发送到Loki/Tempo/Prometheus，你可以将RocketLogs指向你现有的基础设施。将其作为另一个可观察性层使用。如果你想使用多个供应商，也可以进行遥测分发。 非常希望得到反馈。你当前可观察性工作流程中最痛苦的部分是什么？

我构建了一个模拟器，模拟以下内容： • 完整的写入路径（WAL、内存表、不可变内存表、L0 刷新） • 分层压缩及级联合并 • 真实的布隆过滤器检查的读取路径（非模拟） • 实时写入、读取和空间放大指标

我为工作阅读了很多研究论文。我的工作流程围绕着不断增加的来自arXiv等网站的书签论文的收件箱发展而来。这对于探索非常有帮助，但很难跟踪我读过的内容。 Distillate将我已经使用的工具连接在一起：Zotero（文献管理）、reMarkable（阅读器 + 高亮工具）和Obsidian（笔记）。它自动化了整个流程： ``` $ distillate ``` 保存到Zotero ──> 自动同步到reMarkable ``` │ 在平板上阅读和高亮 完成后只需移动到Read/ │ V 自动保存笔记 + 高亮 ``` 它会定期检查Zotero中的新论文，通过rmapi将PDF上传到reMarkable，然后监视您在Read文件夹中完成阅读的论文。当它找到一篇时，它会： - 使用rmscene解析.rm文件以提取高亮文本（GlyphRange项目） - 使用PyMuPDF在原始PDF中搜索该文本并添加高亮注释 - 从Semantic Scholar丰富元数据（出版日期、会议、引用） - 创建一个结构化的Markdown笔记，包含元数据、高亮按页分组，以及注释后的PDF（我将其保存在Obsidian的库中） 核心工作流程只需要Zotero和reMarkable——不需要付费API，不需要云后端，您的笔记保留在您的机器上。如果您连接了其他选项，还可以获得： - 通过Claude的AI摘要（从您的高亮中提炼的一句话 + 关键学习） - 来自您的队列的每日阅读建议 - 通过Resend的每周邮件摘要 - 用于跟踪您阅读的Obsidian Bases数据库 技术栈：rmapi用于reMarkable Cloud，rmscene用于.rm解析，PyMuPDF用于PDF注释。支持Python 3.10+，可通过pip安装。 最棘手的部分是高亮提取：reMarkable将高亮文本存储为场景树中的GlyphRange项目，将该文本与原始PDF中的位置匹配需要模糊搜索和OCR清理，以及针对跨页高亮的特殊合并逻辑。很高兴地说，现在大约99%的时间都能正常工作。 安装：`pip install distillate && distillate --init` 代码： [https://github.com/rlacombe/distillate](https://github.com/rlacombe/distillate) 网站： [https://distillate.dev](https://distillate.dev) 我为自己构建了这个工具，但非常希望能收到反馈，特别是来自其他reMarkable和Zotero用户的反馈。您的工作流程中缺少什么？我还应该添加什么？