介绍

在本文中，我想分享一下我个人写日志的经验。错误的日志可能会使人发疯。好的日志可能成为魔杖。在我的职业生涯中，我写了一些日志，并得出了自己的经验法则。我不能说我的日志成为了我的终极魔杖，但是绝对可以肯定的是，当我遵循这些经验法则时，我的噩梦就会大大减少。本文不是关于哪个日志记录库更好的问题，而是关于如何编写日志的。

假设条件

系统至少包含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，因此我们既不应该发布带有错字也不清晰的日志。

结论

以上是我编写日志时的经验法则。你是什么人，你怎么看待这件事？我将很乐于讨论和丰富我的知识。

错误的日志可能会导致疯狂；好日志可能会成为魔杖相关推荐

Java自己文章只能自己修改_文章目录Java代码俯身指南，主要为Java开发人员提供代码复审参考，快捷有效提出修改意见。目的发现代码错误：一个人写的代码可能会有一些思想和设计盲点，多个人尽...
文章目录 Java代码俯身指南,主要为Java开发人员提供代码复审参考,快捷有效提出修改意见. 目的发现代码错误:一个人写的代码可能会有一些思想和设计盲点,多个人尽早的发现BUG. 统一代码风格:统一 ...
mysql5.6 错误日志_MySQL5.6.36 日志文件之错误日志，二进制日志，慢日志
(一)错误日志配置 vim /etc/my.cnf log-error=/var/log/mysql.log 查找错误日志位置 show variables like '%log_error%' 一般 ...
如何分析apache日志[access_log（访问日志）和error_log（错误日志）]
如何分析apache日志[access_log(访问日志)和error_log(错误日志)] 发布时间: 2013-12-17 浏览次数:205 分类: 服务器默认Apache运行会access_l ...
MySQL 运维日志 -- 错误日志、二进制日志、查询日志、慢查询日志
文章目录 1. 错误日志 2. 二进制日志 2.1 介绍 2.2 格式 2.3 查看 2.4 删除 3. 查询日志 4. 慢查询日志(可以记录用时较长的SQL) 4.1 开启慢查询日志 4.2 慢查询 ...
java基础巩固-宇宙第一AiYWM：为了维持生计，做项目经验之~SSM项目错误集锦Part3（项目蹦+pg数据库坏+100%--＞线上故障排查经验【业务bug第一步一定是先看日志，写好日志】）~整起
项目中遇到的一个问题:项目忽然蹦了,用我们的域名登陆不上去了. 根据之前的经验,一般比如我们项目登不上去了或者数据库不上数据了(数据不更新),直接在Xshell上远程reboot一下,再重启一下tom ...
logback日志配置（控制台日志、输出日志、错误日志）
logback日志配置(控制台日志.输出日志.错误日志) 一.logback.xml相关配置: <?xml version="1.0" encoding="UTF- ...
mysql日志文件名称_MySQL 日志文件说明
MySQL 5.5 官方文档上有关日志的分类: By default, nologs are enabled. The following log-specific sections provide ...
mysql重做日志恢复数据_MySQL中重做日志，回滚日志，以及二进制日志的简单总结...
MySQL中有六种日志文件, 分别是:重做日志(redo log).回滚日志(undo log).二进制日志(binlog).错误日志(errorlog).慢查询日志(slow query log). ...
mysql 表空间收缩_【135期】谈谈MySQL中的重做日志，回滚日志，以及二进制日志的区别及各自作用...
点击上方"Java面试题精选",关注公众号面试刷图,查缺补漏 >>号外:往期面试题,10篇为一个单位归置到本公众号菜单栏->面试题,有需要的欢迎翻阅阶段汇总集 ...

错误的日志可能会导致疯狂；好日志可能会成为魔杖

介绍

假设条件

规则

结论

错误的日志可能会导致疯狂；好日志可能会成为魔杖相关推荐

最新文章

热门文章