文档

错误追踪

捕获你的应用抛出的异常，并归并成问题，所有套餐都提供，免费套餐也不例外。它使用 Sentry 的协议，因此你可以保留已有的 SDK，只改一行配置。

如何接入

在控制台中创建一个项目并复制它的 DSN，然后把你现有的 SDK 指向它：

Sentry.init({
  dsn: "https://<key>@vitrinaengine.com/ingest/<project>",
});

这就是全部的接入工作。任何 Sentry SDK 都能用——JavaScript、Python、Ruby、Go、PHP、.NET——因为我们用的就是它们的传输协议，而不是某种类似的东西。

DSN 里的密钥不是机密。浏览器 SDK 会把它打包进页面里，所以它只用来标识一个项目，不授予任何其他权限。不要写出任何假定它是私密的东西。

错误如何变成问题

属于同一个故障的事件会归并到一个问题里。归并依据异常类型、消息和调用栈的形状——绝不依据行号，否则在文件开头加一条 import 就会把一个问题拆成两个，让一个由来已久的缺陷看上去像是新出现的。

你已经解决、之后又再次发生的问题，会作为回归重新打开并向你告警，而不是悄悄地给一个已关闭的问题再添一次出现记录。

Source map

上传某个版本的 map，压缩过的浏览器调用栈就会变得可读。用 API 从你的构建流程里上传——参见 API 参考。

map 先按 debug_id 匹配，其次按版本加文件名匹配。它们是在你读取问题时应用的，而不是在事件到达时，这带来一个有用的结果：在错误产生之后才上传的 map，同样会应用到这些错误上。而这通常正是事情发生的顺序。

附在事件上的错误

当监控开启一个事件时，它会收集你的应用在那次故障被确认期间抛出的错误，并把一份摘要附到事件本身上。

值得了解它为什么比事后再去搜索更有用：那个时间窗口在事件成立的那一刻就不复存在了，而错误事件有保留期限，会远早于事件本身过期。所以摘要是在还能采集的那一刻采集下来的，之后便随事件一起保存。

在代理商账户中，摘要的范围限定在工作区内，因此一个客户的事件不会把另一个客户的调用栈带进邮件里。

来自服务器与网络设备的日志

在 Business 及以上套餐中，项目还会接收您的机器本就在写的日志：来自 Linux 以及 Cisco 和 Juniper 设备的 syslog、Windows 事件日志，以及 macOS 统一日志。把您已经在用的日志转发器指 向项目的日志端点即可，该地址就在项目页面的 DSN 旁边。机器本身无需安装任何东西。

仅存储错误。低于 err 的 syslog 级别、低于 Error 的 Windows 级别，以及 macOS 日志中称为 Default 或更低的一切，都会在计数或计费之前被丢弃——因 此健康的主机不会产生任何费用，那些不足以呼叫值班人员的警告也不会塞满您的问题列表。

日志记录的归类方式与异常相同：按发出它的程序和消息内容归类，而不是按主机。一次错误的发布 影响二十台 Web 服务器，是一个被看到二十次的问题，而不是二十个问题。当设备为自己的消息命名 时，我们按该名称归类，因此接口中断是一个问题，无论它是哪个端口。

由于日志行的重复次数远多于异常，我们每小时为每个问题保留一个样本，其余的只做计数。出现次 数和图表都是精确的；您得不到的，只是第一百条完全相同的日志的单独副本。

配额

每个套餐都有每月事件额度——Free 5,000 个，Starter 50,000 个，Pro 250,000 个，Business 1,000,000 个。接收还会按项目限流，这才是真正会发生的情况：重试循环里的一个异常，否则可能在几分钟内烧掉一个月的配额。

单个事件按你套餐的错误保留期保存——Free 七天，Starter 三十天，Pro 六十天，Business 九十天。由它们生成的问题比事件活得更久：它们的计数以及首次和最后一次出现的时间，会一直保留到你套餐的历史保留期为止。

我们不做的事

没有会话回放，没有性能追踪，也没有性能剖析。这只是异常追踪，只不过它就在你的可用性监控旁边，于是「网站正常，却每分钟抛出五百个错误」是一块屏幕，而不是两个产品。