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")
...