在后端服务设计中，异常捕获是需要考虑的必不可少因素。
当异常发生异常时，重要的是首次捕获并获得足够的信息定位，这也是本文的内容。
一开始，首先提出了两个问题：
异常通常在以下位置出现
此外，除了积极捕获异常外，还可能错过一些异常，这可能导致该计划退出
当API层异常时，必须在将数据传输到客户端时构建异常，以便下一步报告下一步和结构化信息的分析以及前端的相应显示
以下使用表明，当发生异常时，应返回API的结构化信息
而且，当异常发生异常时，可以在顶部中间件中统一捕获异常作为错误处理。捕获时，您可以使用功能来统一中间件中的结构化异常信息
以下是每个字段的标志
指示错误标识代码以对错误进行分类，例如用户输入数据非法（验证Error），数据库异常和外部服务请求（requestError）
根据经验，我将代码分为以下类别
为了进行数据验证，数据库是异常的，请求失败，我们通常使用第三方库。这次，可以根据第三方库的错误自定义代码
这意味着人类可读的错误消息，但并不一定意味着它可以在前端显示。这里的人类代表开发人员，而不是用户。如果以下两条消息不适合在前端显示
您可以确定前端是否可以显示后端期待根据代码的信息，并且您还可以根据前端的代码进行全球集中处理
代表代码的一些更详细的信息
Originaler代表由此异常引起的错误API，通常包含更详细的上下文信息
指示当前错误的堆栈可以在发生异常时迅速定位该位置（尽管节点有时抛出的堆栈信息是从未见过的文件）
在开发和测试环境时，将原始eRror附加到API上，以快速找到问题。当生产环境时，请勿将您的原始ERROR放入API中。您可以在监视系统中找到完整的错误消息
您可以使用以下两个API来优化您
有关特定用法方法，请参阅V8堆栈跟踪API
表示接口返回的数据。当API报告错误时，数据返回吗？
不应是，当API报告错误时，可能只有某些字段存在问题，其余字段可以正常返回。由于该字段是由字段（字段）汇总的，这在表现中很明显。
当API处理过程中发生错误时，应返回400+状态代码
在本地开发时，通常不需要报告异常。在报告之前，在向异常过滤报告之前还提供了钩子
监视首先需要监视系统。我在这里推荐它。如何部署它可以参考我以前的文章：如何部署哨兵。
您还可以直接使用SaaS版本：Sentry Pay。个人免费版本的每月5K错误限制，这足以供个人使用。
与自行版本相比，SaaS用于避免日常的操作和维护工作。主要的是，自制造系统具有功能限制。
该文档在这里
除了异常监测本身外，还有更多指标。
异常监测的最重要目标是恢复异常并抛弃现场
从上面可以看出，集合指标的数据通常来自两个方面，HTTP数据包和环境变量