最新

这有点模糊，但作为一名工程师，走过办公室的其他部门时，看到有人在制作文档、演示文稿等，可能会感到惊讶，认为创造静态成果的价值竟然足以推动就业。我想知道是否有人对这项工作的价值所在有任何想法。我知道这与行业息息相关，所以如果你愿意分享，可以从你自己的角度谈谈。模糊和大胆的回答也欢迎。我希望能对此进行广泛的讨论。

/root/0有什么特别之处？

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

请使用以下命令安装 autodidact 并初始化： ``` pip install autodidact && autodidact init ```