最新

这有点模糊，但作为一名工程师，你可能会在办公室里路过其他部门，看到人们在创建 Word 文档、演示文稿等等，然后会有点震惊，觉得创建静态文档竟然有足够的价值来支撑就业。我想知道是否有人对这项工作的价值所在有任何想法。我知道这都非常依赖于行业，所以如果你愿意分享，可以从你自己的角度谈起。欢迎模糊和天马行空的回答。我希望就此展开一场广泛的讨论。

根号0有什么特别的？

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

``` pip install autodidact && autodidact init ```