所有的输入、输出信息要在API端进行记录。请求参数、请求源、中转IP、请求头、用户信息、请求与回复的Body、业务上下文、时间戳、以及内部处理步骤。
调用服务与功能时，建议在较低日志级别上记录上下文数据，主要用于Debug
每个程序有自己的业务集与用户地图，能够为产品经理提供有价值的信息。
在大多数企业及业务应用中，为用户的数据操作（含用户调用、其它系统与服务的调用）保持一个独立的日志是非常必要的。
包含有：访问的Id、确切的服务实例、使用的角色权限、时间戳、数据层的查询条件、数据变化前后的快照等。
包含有：行为事件、转换模式、服务间通信、服务实例 ID、主动服务 API、主动侦听 IP 和端口范围、加载的配置、整体服务健康状况以及有助于理解系统行为的所有其他内容。
系统中每个事件日志的严重性由不同的日志级别来标识。在大多数日志框架中都可以访问以下级别。
识别可能导致程序中止的极其严重的错误事件。通常，这会导致灾难性故障。
识别可能仍然让软件运行但在受影响的路由中具有受限功能的错误事件。
描述破坏性低于错误的事件。它们通常不会导致程序功能的任何减少或完全失败。然而，它们是必须调查的红色标志。
在程序行为中，它表示重大事件的信息性消息。
表示特定且详细的数据，主要用于调试。
为了提供有关特定事件/上下文的最大信息，它表示最低级别的信息，例如代码的堆栈跟踪。这些日志允许我们检查变量值以及完整的错误堆栈。
受限于字符集。因此，在撰写日志消息时，请确保您尽量坚持使用英语。
如果记录的太少，可能无法收集足够的信息来确定每个关键事件的上下文。如果我们做得太多，我们会担心性能问题。
全面掌握系统的功能性和非功能性需求，规划合适的日志消息质量和数量，优化日志消息。使每条日志消息都有用并与情况相关，并始终保持简短和甜美。
良好的日志记录需要在所有日志文件中保持一致的标准日志文件结构。每个日志语句行应反映单个事件，包括：时间戳、主机名、服务和项目记录器名称等。线程或进程 ID、事件 ID、会话 ID 和用户 ID 都可以用作附加值。
其他重要的值可以连接到事件的环境，例如 ID、部署名称、应用程序版本或任何其他键值对。确保您的时间戳格式包含时区数据并使用高精度时间戳。
最后，请给每行日志一个唯一的 ID。添加错误 ID 以记录错误。
这些对于跨架构组件跟踪或关联问题是必要的。
Metrics是日志记录要求中的一个基本概念。
Metrics是对价值随时间推移的衡量标准，通常是定期进行的。
以下是常见Metrics的类型：
每个度量代表某个系统属性的一个条件。使用Metrics，可以拥有很多指标并将它们相互关联。
建议跟踪记录Metrics或将Metrics与日志分开记录。
不要将相同的日志消息复制并粘贴到许多文件中，这样会导致最终的日志聚合器工具聚合消息时，很难确定代码中触发事件的具体位置。
至少要在日志消息中指定日志源，以区分最终的日志位置。
日志是开发人员按照代码编写的。这意味着开发人员在将日志写入代码时是基于代码的上下文。阅读日志的人缺少上下文。每个日志行都应该有足够的信息让您准确了解发生了什么以及程序目前的状态。
如果代码出现问题并且已经知道该怎么做，请不要设置报警。相反，要从代码本身创建警报。
如果从可以序列化的远程服务中抛出异常，请确保客户端可以访问所有这些异常。
大多数 API 日志系统包括创建自定义日志解析器和过滤器。这些解析器允许我们以更有条理的方式存储日志数据，使查询更容易和更快。正确组织的日志数据也可以提供给日志监控和异常检测系统，以主动监控系统并预测未来事件。
这些技术非常复杂，它们通过基于时间序列的交互式仪表板和基于日志数据和其他来源的实时事件分析提供了奇妙的视觉体验。