本文档的用途是帮助您为日志记录选择正确的严重级别。Fuchsia 支持严重级别为 FATAL、ERROR、WARNING、INFO、DEBUG 或 TRACE 之一的日志记录。本文档总结了 RFC-0003：日志记录中的规范性准则。
| 严重程度 | 总结 |
FATAL |
不可恢复的错误事件。应导致终止。 |
ERROR |
程序可以从中恢复的意外事件，表示存在 bug 或意外的程序行为。 |
WARNING |
在系统的正常运行期间发生了意外事件。 |
INFO |
信息丰富的事件，通常符合预期。通常是 bug 报告中最低级别。 |
DEBUG |
用于开发的信息性事件。 |
TRACE |
用于开发的信息性事件，以精细粒度或高频率发出。 |
不确定要用哪个？
日志记录描述系统中的事件。为日志记录选择严重级别是描述事件本身的一种方法。
通常，对于不可恢复事件，应在 FATAL 中记录意外事件；对于表示不正确程序行为（即“bug”）的可恢复事件，记录在 ERROR 下；对于本身不是 bug，但可能会提供有关其他故障的重要背景信息，记录为 WARNING。
您应该将仅与在本地处理项目的贡献者相关的事件记录为 DEBUG 或 TRACE。如果事件符合预期，通常应将其记录为 INFO。
如果您仍不确定如何标记事件的严重程度，请考虑以下问题：
该事件导致了什么变化？活动前后有何不同？
这通常涉及写入或阅读相关活动的消息。如果系统未发生任何更改，最好完全跳过该事件。对于重要的检测信号事件，请考虑
TRACE严重级别。谁想了解这个活动？
默认情况下，严重程度不同的事件会在不同的上下文中提供，这实际上就是定义其受众群体。许多事件与项目的工程师相关，但会给其他团队带来过多干扰。通常，最好以
DEBUG或TRACE严重级别发出这些事件，因为这些事件默认会从 bug 报告中排除。由于
INFO及更高版本更加醒目，因此在调试时没有为实现者提供关键上下文的事件应限于对客户端或实现团队以外的其他人有用的信息。此活动是周期性活动还是持续性活动？
描述频繁的后台活动或持续失败状态的日志事件应限于
DEBUG或TRACE，并由 Inspect 和 Cobalt 进行报告，以避免产生生产日志垃圾。虽然记录进入失败状态可能很有用，但记录“仍处于失败状态”等事件通常没什么用。当故障状态为“波动”或定期自行解决和解除解析时，很难避免通过这种方式重复日志语句。按重复次数或时间间隔来限制速率限制是一个合适的响应方式，但 Fuchsia 的日志记录库目前没有为此提供开箱即用的工具。将来，如果出现一组更明确的模式和最佳做法，我们将进行探索。