目录
介绍
在本文中，我想分享一下我个人写日志的经验。错误的日志可能会使人发疯。好的日志可能成为魔杖。在我的职业生涯中，我写了一些日志，并得出了自己的经验法则。我不能说我的日志成为了我的终极魔杖，但是绝对可以肯定的是，当我遵循这些经验法则时，我的噩梦就会大大减少。本文不是关于哪个日志记录库更好的问题，而是关于如何编写日志的。
假设条件
- 系统至少包含2个模块（即服务器和客户端）。
- 至少有100个用户同时使用系统。
- 用户至少可以使用2种不同的流程来使用系统（应用程序）。
规则
1、日志是可交付的，应像对待UI，API和软件系统的其他组件一样对待和测试。
这条规则意味着——日志不是垃圾桶，我们在任何地方以及任何需要的地方都扔了垃圾。Log是见证人，我们将向他询问以下问题：
- 发生了什么？
- 什么时候发生的？
- 为什么会发生？
- 客户要求正确吗？
因此，日志的设计应与我们设计软件的所有组件一样。
2、在开发系统时记录更改。
规则说明：通常，当我们开始开发软件系统时，我们不知道将来会如何更改，以及自第一版软件发布一年或两年后会从产品部门或用户那里获得什么要求。可以更改软件，因此应该相应地更改日志。
3、日志必须具有统一的时间表。
如本文的假设部分所述，我们的软件系统至少包含2个组件（例如，客户端和服务器）。客户端模块在最终用户的计算机上运行，并且具有自己的时区，该时区可以与服务器的时区不同。我建议对所有日志组件使用UTC。在这里，您可以问：如果我们想在本地客户的时间知道事件的时间，该怎么办？然后，我建议再使用一个字段来存储客户事件的本地时间戳。
4、日志文件的大小应使您喜欢的文本编辑器可以轻松地加载和搜索。
每个组件的日志文件不应太大。应该由您喜欢的编辑器轻松加载。如果组件很冗长，并且写了很多日志，那么我建议使用文件滚动。大多数开源日志记录库都允许定义取决于文件大小的文件滚动参数。如果日志超出大小，则库将创建一个新文件并添加一个索引。
5、所有软件系统组件的日志都应存储在一个存储库中，这将便于查询和调查。
如果软件系统由几个组件组成，则每个组件都会写入其日志文件特定的位置。日志文件已滚动——组合所有文件并调查一些跨组件问题将非常复杂。日志存储库将解决此问题。顺便说一句，如果我们使用存储库，则可以忽略规则4。
6、日志应该是单调的。
规则说明：如果在X行中，则日志指出系统在时间T0处在状态A。在某个时刻，T1软件系统移至状态B，这意味着日志中应该有一条明确的行，表明系统状态在时间T1更改为B。换句话说：每个系统状态更改都应明确地写入日志文件中。我们不应该猜测系统处于什么状态——我们必须从日志中明确知道它。
7、如果系统做出决定，则应将其写入日志。
可以在一个示例中演示此规则。例如，我们正在记录用户身份验证过程。我们必须写出用户是否已通过身份验证。这两个决定都应写入日志中。之后阅读日志，我们可以明确地理解身份验证过程做出的决定。仅编写否定决策（也存在这种方法），我们可能会部分影响规则6：可能的日志不会变得单调。
8、日志消息应与源代码关联。
阅读日志，我们应该能够轻松找到负责特定日志消息的源代码部分。一些框架允许添加文件名和行号。
9、比其他消息更重要。
对我们来说，有些行比其他行更重要。例如，我们想以最快的方式知道系统中发生了异常。通常，我们对每条日志消息使用严重性。最常见的严重级别是FATAL——致命异常，ERROR——错误，INFO和DEBUG。有时，还会有更多严重级别，例如警告，跟踪等。
10、日志应该是连续的。
假设用户抱怨他/她看到了错误消息。我们的Dev或DevOps团队访问日志存储库查询中的错误消息，并找到适当的日志消息。很好，但是几乎没有用。为什么？因为知道用户是对的，这是件好事，但是如果能够知道在此特定情况下错误的根本原因，那就更好了。为了能够进行调查，显然我们将需要查看一些日志消息，这些消息是在错误发生前几分钟为该用户编写的。为了解决这个问题，我提出了连续的方法。连续方法：当用户开始一些流程时，我们将为其分配唯一的ID。我们将使用此唯一ID对该流的每个日志消息进行签名。当流程结束时，该ID将被关闭。回到示例中，一旦找到日志消息，与用户已经看到的错误消息有关，通过唯一的流ID，我们将能够找到在显示错误之前编写的所有日志消息。如果日志是根据这些规则编写的，我们将能够轻松了解是什么原因导致系统针对此特定用户的错误消息。
11、我们正在写日志以便有时阅读。
日志是为读取而写的——因此应该清楚！优选地，没有错别字。根据规则1：我们应该将日志视为可交付结果（例如UI）。我们不会发布既不清晰也不带有错字的UI，因此我们既不应该发布带有错字也不清晰的日志。
结论
以上是我编写日志时的经验法则。你是什么人，你怎么看待这件事？我将很乐于讨论和丰富我的知识。
