Poor Logging Practice: Use of a System Output Stream

使用 Console.Out 或 Console.Error 而不是专门的日志记录工具，会导致难以监控程序的运行状况。

示例 1：开发人员学习编写的第一个 .NET 程序如下所示：

public class MyClass {
  ...
    Console.WriteLine("hello world");
  ...
}

当多数程序员深入了解 .NET 的许多精妙之处时，有一部分人仍会依赖于这一基础知识，始终使用 Console.WriteLine() 来编写消息以进行标准输出。

这里的问题是，直接在标准输出流或标准错误流中写入信息通常会作为一种非结构化日志记录形式使用。结构化日志记录系统提供了各种要素，如日志级别、统一的格式、日志标示符、次数统计，而且，可能最重要的是，将日志信息指向正确位置的功能。当系统输出流的使用与正确使用日志记录功能的代码混合在一起时，得出的结果往往是一个保存良好但缺少重要信息的日志。

开发者普遍认为需要使用结构化日志记录，但是很多人在“产前”的软件开发中仍使用系统输出流功能。如果您正在检阅的代码是在初始开发阶段之后生成的，那么 Console.WriteLine 的使用可能会在转向结构化日志记录系统的过程中导致一个漏洞。

使用 os.Stdout 或 os.Stderr 而不是专门的日志记录工具，会导致难以监控程序的运行状况。

示例 1：通常，开发人员学习编写的第一个 Go 程序如下所示：

...

func foo(){
    fmt.Println("Hello World")
}

多数开发人员深入了解 Go 的许多精妙之处后，一部分人员始终使用 fmt.Println() 编写进行标准输出的消息。

问题在于，直接在标准输出流或标准错误流中写入信息通常会作为一种非结构化日志记录形式使用。结构化日志记录系统提供了各种要素，如日志级别、统一的格式、日志标识符、时间戳，以及将日志信息指向正确位置的功能。当系统输出流的使用与正确使用日志记录功能代码混合在一起时，得出的结果往往是一个保存良好但缺少重要信息的日志。

开发者普遍接受结构化日志记录，但许多人在“产前”的软件开发中仍使用系统输出流功能。如果您正在检查的代码是在初始开发阶段之后生成的，那么使用 os.Stdout 或 os.Stderr 进行日志记录使用可能会在转向结构化日志记录系统的过程中导致漏洞。

使用 process.stdout 或 process.stderr 而不是专门的日志记录工具，会导致难以监控程序的运行状况。

示例 1：早期的 Node.js 开发人员编写的简单程序可从 stdin 读取并将其再次写回 stdout，可能如下所示：

process.stdin.on('readable', function(){
    var s = process.stdin.read();
    if (s != null){
      process.stdout.write(s);
    }
});

虽然大多数程序员继续学习，尤其是关于 JavaScript 和 Node.js 的细微之处，但很多程序员仍依赖于这一基础知识，始终使用 process.stdout.write() 编写标准输出的消息。

这里的问题是，直接在标准输出流或标准错误流中写入信息通常会作为一种非结构化日志记录形式使用。结构化日志记录系统提供了各种要素，如日志级别、统一的格式、日志标示符、次数统计，而且，可能最重要的是，将日志信息指向正确位置的功能。当系统输出流的使用与正确使用日志记录功能的代码混合在一起时，得出的结果往往是一个保存良好但缺少重要信息的日志。

开发者普遍认为需要使用结构化日志记录，但是很多人在“产前”的软件开发中仍使用系统输出流功能。如果您正在检查的代码是在开发阶段的初期生成的，那么对 process.stdout 或 process.stderr 的使用可能会在转向结构化日志记录系统的过程中导致漏洞。

使用 print 或 println 而不是专门的日志记录工具，会导致难以监控程序的运行状况。

示例 1：开发人员学习编写的第一个 Kotlin 程序如下所示：

class MyClass {
    ...
            println("hello world")
    ...
    }
}

多数程序员深入了解 Kotlin 的许多精妙之处后，有一部分人仍会依赖于这一基础知识，始终使用 print 或 println 编写进行标准输出的消息。

问题在于，直接在标准输出流或标准错误流中写入信息通常会作为一种非结构化日志记录形式使用。结构化日志记录系统提供了各种要素，如日志级别、统一的格式、日志标识符、时间戳，以及可能最重要的将日志信息指向正确位置的功能。当系统输出流的使用与正确使用日志记录功能的代码混合在一起时，得出的结果往往是一个保存良好但缺少重要信息的日志。

开发者普遍认为需要使用结构化日志记录，但是很多人在“产前”的软件开发中仍使用系统输出流功能。如果您正在检查的代码是在初始开发阶段之后生成的，那么使用标准输出或错误流可能会在转向结构化日志记录系统的过程中导致一个漏洞。

使用标准输出或标准错误而不是专门的日志记录工具，会导致难以监控程序运行状况。

示例 1：开发人员学习编写的第一个 Python 程序通常如下所示：

sys.stdout.write("hello world")

多数程序员深入了解 Python 的许多精妙之处后，有一部分人仍会依赖于这一基础知识，始终编写进行标准输出的消息。

这里的问题是，直接在标准输出流或标准错误流中写入信息通常会作为一种非结构化日志记录形式使用。结构化日志记录系统提供了各种要素，如日志级别、统一的格式、日志标示符、次数统计，而且，可能最重要的是，将日志信息指向正确位置的功能。当系统输出流的使用与正确使用日志记录功能的代码混合在一起时，得出的结果往往是一个保存良好但缺少重要信息的日志。

开发者普遍认为需要使用结构化日志记录，但是很多人在“产前”的软件开发中仍使用系统输出流功能。如果您正在检查的代码是在开发阶段的初期生成的，那么对 sys.stdout 或 sys.stderr 的使用可能会在转向结构化日志记录系统的过程中导致漏洞。

使用 Kernel.puts、Kernel.warn 或 Kernel.printf 而不是专门的日志记录工具，会导致难以监控程序的行为。

例 1：开发人员学习编写的第一个 Ruby 程序通常将包括如下功能：

...
puts "hello world"
...

多数程序员深入了解 Ruby 的许多精妙之处后，有一部分人仍会依赖于这一基础知识，始终使用 Kernel.puts 编写进行标准输出的消息。

这里的问题是，直接在标准输出流或标准错误流中写入信息通常会作为一种非结构化日志记录形式使用。结构化日志记录系统提供了各种要素，如日志级别、统一的格式、日志标示符、次数统计，而且，可能最重要的是，将日志信息指向正确位置的功能。当系统输出流的使用与正确使用日志记录功能的代码混合在一起时，得出的结果往往是一个保存良好但缺少重要信息的日志。

开发者普遍认为需要使用结构化日志记录，但是很多人在“产前”的软件开发中仍使用系统输出流功能。如果您正在检查的代码是在初始开发阶段之后生成的，那么对 Kernel.puts、Kernel.warn 或 Kernel.printf 的使用可能表示转向结构化日志记录系统过程中的一时疏忽。
如果公司策略规定不能使用这些 API，则仍然可以通过使用日志系统将信息打印到系统输出流来绕过此策略。

例 2：下面的代码使用了 Logger 类，但是将信息记录到系统输出流：

require 'logger'
...
logger = Logger.new($stdout)
logger.info("hello world")
...