Launch HN: Superlog (YC P26) – 自行安装并修复bug的可观测性工具

嘿，HN，我们是Nico和Arseniy，Superlog的联合创始人（<a href="https://superlog.sh">https://superlog.sh</a>）。我们正在构建一种自行安装、自我修复的可观测性工具，旨在不用打开。它有一个向导程序，每天设置适当的日志记录，还有一个代理程序，负责调查错误并生成PR。<p>超短演示：<a href="https://www.youtube.com/watch?v=xFhU9Mk247M" rel="nofollow">https://www.youtube.com/watch?v=xFhU9Mk247M</a>。<p>在我们之前的创业公司中，我们尝试过Sentry、Datadog、Grafana、Dash0，但没有一个足够好。正确的遥测和告警仍然需要大量手动设置。我们很难添加好的日志，因此调试很困难，尤其是在代码库快速增长的情况下。与此同时，Datadog/Dash0的账单不断攀升，我们仍然需要花费工程时间来学习、配置和维护我们的可观测性工具。<p>使用Sentry时，我们发现我们的Slack频道被大量告警淹没，大多数是重复的或缺乏上下文，因此告警疲劳/不断中断确实很痛苦。#ops通知在周六早上总是最糟糕的感觉。<p>我们见过太多次服务器内存和磁盘耗尽，三个AWS指标给出三个不同的值。仪表板上的一半图表通常是空的或过时的，手动点击UI，尤其是在团队规模较小时，似乎非常浪费时间。<p>在某个时候，我们意识到解决这个问题比我们一直在做的事情更有价值，而且我们有这方面的专业知识，因为Arseniy曾在Datadog工作多年，晚上会被叫起来调试生产事故。因此，我们决定构建一个能够直接工作的平台：代理优先，原生MCP，零设置。<p>以下是Superlog的工作原理：我们有一个向导程序，扫描你的仓库，并通过OpenTelemetry自动用结构良好的日志、追踪和指标检测代码。我们确保突出主要故障模式、端点性能、每个租户的使用情况以及LLM/上游成本（按调用点、租户和模型）。<p>错误会被指纹识别并分组到事件中，这样你看到的是一个单一问题，而不是上千个重复。当你收到Superlog的通知时，你会看到清晰的故障摘要、其推断的严重性和影响。<p>然后代理程序会调查并尝试解决问题。如果它有足够的上下文，它会生成一个简洁且经过测试的PR。如果没有，它会将调查结果发布给调查团队，并根据文档、之前的调查和Slack线程，自动拉入可能提供更多上下文的工程师。<p>无论哪种方式，输出都是每个事件一个干净的PR，发布在Slack中，你可以合并、忽略，或者作为Claude Code会话打开并修改。<p>我们认为与其他可观测性供应商相比，有三个不同之处：<p>(1) 我们解决了设置痛点。向导程序将使用原生OTel SDK检测所有内容，遵循语义约定，并进行适当的服务和环境标记。我们还正在开发原生的自动仪表板和告警，以便你可以一目了然地了解情况，并且不会错过微妙的故障模式。<p>(2) 我们的遥测不会衰减。向导程序每天运行，并在需要的地方不断添加日志、告警和仪表板。你不需要记住为新功能添加检测。下次出现问题时，调试所需的数据已经在那里。<p>(3) 我们的目标是解决告警疲劳。我们使用代理合并相似错误并优化摘要，让你预先获得相关信息。我们有一个自定义评估设置，确保我们的摘要简洁正确，严重性和影响准确。我们还为每个LLM增强的指标提供置信分数，以免错误猜测被夸大。<p>重要提示：Superlog遥测技术是中立的，因此你可以保留我们安装的所有日志/指标/追踪。定价在网站上。我们还在早期阶段，所以可能会有不完善之处，请告诉我们你发现的问题。<p>你可以在<a href="https://superlog.sh">https://superlog.sh</a>上尝试。我们很想知道你目前在使用什么，有什么问题，以及“每个事件一个可合并的PR”这个模式听起来有用还是可怕。特别期待听到运行集成密集型产品的人、自己打造可观测性的人，以及尝试过Sentry/Datadog MCP但放弃的人的意见。欢迎评论和反馈！