Croft 为 AI 生成应用内置 APM，可由 AI 助手自动修复故障

面向「用 AI 对话构建应用」的开发者，平台 Croft 宣布将可观测性能力直接植入其运行时：所有托管应用默认开启 APM（应用性能监控），无需额外接入 SDK、配置代理或搭建仪表盘，且不单独计费。配套的 MCP 工具则让 AI 助手可以读取错误、调用日志并完成修复部署，形成「出错—定位—改码—上线」的闭环。

为何需要「开箱即用」的监控

传统 APM（如 New Relic、Datadog、Sentry）需要先建账号、在代码中接入 SDK，并由工程师解读结果。但对一个用 Claude 或 ChatGPT 在几小时内拼出来的应用来说，这套链路过于笨重。Croft 的切入点是：让监控从部署第一天起就是基础设施的一部分，并在出问题时让 AI 助手「看见」并直接处理。

内置监控包含哪些能力

所有 Croft 应用默认获得以下监控数据，覆盖问题定位的主要维度：

响应时间分解：数据库、外部 API、代码执行的分层堆叠分析，类似 New Relic 的性能剖析能力。
吞吐与失败率：按时间维度展示成功、被拒、失败请求的曲线与突增点。
错误分组：相同错误自动聚合为一组，附带堆栈与受影响请求。
慢请求瀑布图：直观看到具体是数据库查询还是第三方调用耗时。
最慢 SQL 列表：直接给出应优先优化的查询。
7 天日志检索：按级别、时间或关键词过滤搜索。
健康检查与资源指标：CPU、内存、数据库体量趋势。
部署标记：图表上叠加每次发布的时间点，便于回溯变更影响。

数据每分钟刷新，不另收费用。

与 AI 助手联动的「修复循环」

监控的差异化之处在于打通 AI 助手。Croft MCP 暴露三组工具：

app_errors：列出未关闭的错误分组，读取堆栈与失败请求。
app_metrics：拉取响应时间、吞吐、失败率或服务器资源。
logs：搜索与读取最近 7 天的日志，支持级别与关键词过滤。

模型可以按这个链路自助处理：拉取错误→查看堆栈与日志→修改自身代码→重新部署。面板上另提供「Fix with Build」按钮，会直接把上下文交给 Croft Build 内置聊天界面，由其修复合部署。当新代码部署后未再观察到该错误时，分组自动关闭，无需人工清理。

告警策略与隐私边界

告警邮件聚焦三类事件：新错误、高失败率、应用不健康；每应用每天最多一封，避免告警疲劳。

隐私方面，日志、错误堆栈、慢请求详情均保存在用户自有 Croft 服务器，保留 7 天；仅聚合计数与时序（每秒请求、平均响应时间、失败率）上报控制平面用于出图。明确不记录查询字符串、请求体、Cookie 与 IP 地址。

该监控能力已纳入 Solo 与 Team 套餐，部署即生效，无需额外开通。从产品叙事看，Croft 想把对话式开发的速度与「可被业务长期依赖」的工程基础结合起来，监控被定位为这一步之后还会继续扩展的板块。