ロギング比率に対する理想的なコードは? 私が開発したほとんどのアプリケーションにはあまりログが記録されていないため、ログを書き込むことに慣れていません。
最近、私は仕事を変えましたが、log4net への呼び出しのアプリケーション コードが表示されていないことに気付きました。これは便利だと思いますが、debug ステートメントが多すぎるのは、まったくないのと同じくらい悪いことですか?
すべてのメソッドの開始時と終了時、およびそれらが何を返すかを示すログ ステートメントがあります。そして、ほとんどすべてのことが行われるとき。
リフレクションを使用してコンパイル時にログ ステートメントを追加するアドオンを用意して、コードを見ようとしているときに邪魔にならないようにする方が簡単ではないでしょうか?
また、最近の強力な IDE とリモート デバッグでは、それほど多くのログが本当に必要なのでしょうか?
log4net はリソースを詰まらせないという優れた機能を備えているため、デバッグ モードに変更する必要がある場合は、情報が多ければ多いほどよいため、ロギングについては少し冗長になる傾向があります。これが私が通常記録するものです：
デバッグ レベル
情報レベル
エラーレベル
致命的なレベル
また、ログの詳細がたくさんあると、エラー メッセージが表示されたときに何をしていたかをユーザーに尋ねることができなくなります。簡単に片付けてしまいます。
完全なログ ファイルは驚くほど便利です。アプリケーションが銀行のような場所にデプロイされている状況を考えてみましょう。そこに行って手動でデバッグすることはできません。彼らは確かにデータを送信するつもりはありません。取得できるのは、問題が発生した場所を示す完全なログです。多数のログ レベルがあると非常に便利です。通常、アプリケーションは、致命的なエラーまたは重大なエラーのみを報告するようなモードで実行されます。デバッグする必要がある場合、ユーザーはデバッグまたはトレース出力をオンにして、より多くの情報を取得できます。
表示されている種類のログは過剰に見えますが、アプリケーションとそれが展開される可能性のある場所について詳しく知らなければ、それが確実であるとは言えません。
また、最近の強力な IDE とリモート デバッグでは、それほど多くのログが本当に必要なのでしょうか?
はい、もちろんです。多くの熟練していない開発者が犯す間違いは、間違った方法でバグを修正しようとすることです。通常、デバッグする必要があるときにログを記録する傾向があります。それぞれに場所がありますが、ほぼ常にロギングが必要になる領域が少なくともいくつかあります。
// データファイルを開く
fp = fopen("data.bin", "rb");
上記のコメントは、ロギング呼び出しに簡単に配置できます。
const char *kDataFile = "data.bin";
log("データ ファイル %s を開いています", kDataFile);
fp = fopen(kDataFile, "rb");
そうは言っても、あなたはいくつかの点で正しいです。ロギング メカニズムを美化されたスタック トレース ロガーとして使用すると、非常に質の悪いログ ファイルが生成されます。したがって、ここで重要なのは明らかに、呼び出しのログを正しく慎重に使用することです。これは開発者の裁量にかかっていると思います。基本的に自分でログファイルを作成していることを考慮する必要があります。ユーザーはそれらを気にせず、通常はとにかくコンテンツをひどく誤解しますが、少なくともプログラムが誤動作した理由を判断するためにそれらを使用できます.
また、ログファイルが特定のバグの直接の原因を示していることはほとんどありません。私の経験では、通常、バグを再現する方法についてある程度の洞察が得られ、それを再現またはデバッグするプロセスによって、問題の原因を見つけることができます。
あなたが言うように、事後にロギングを追加するための素晴らしいライブラリが実際にあります、PostSharp。属性ベースのプログラミングを介してそれを行うことができ、ログ記録以外にも非常に便利なことがたくさんあります。
あなたの言うことは、ロギングには少し過剰であることに同意します。
いくつかの良い点、特に銀行のシナリオやその他のミッション クリティカルなアプリを取り上げている人もいます。極端なロギングに必要な場合や、少なくとも必要に応じてオンとオフを切り替えたり、さまざまなレベルを設定したりできるようにする必要がある場合があります。
それほど多くのログは必要ありません。各メソッドがいつ開始および終了するかを (本番環境で) 知る必要はありません。特定のメソッドでそれが必要な場合もありますが、ログ ファイルに多くのノイズがあると、効果的に分析することがほとんど不可能になります。
エラー、ユーザー ログイン (監査ログ)、トランザクションの開始、重要なデータの更新など、重要なことが発生したときにログを記録する必要があります。ログから把握できない問題がある場合は、必要に応じてさらに追加できます...ただし、必要な場合に限ります。
また、参考までに、コンパイル時にログインを追加することは、いわゆるAspect Oriented Programmingの一例です。ロギングは「分野横断的な関心事」です。
「ログとコードの比率」は問題の誤解だと思います。
私の仕事では、Java プログラムのバグが本番環境以外では再現できず、顧客が再発を望んでいないという状況に時々遭遇します。
次に、バグを修正するために利用できるのは、ログファイルに自分で入力した情報だけです。デバッグセッションはありません (本番環境では禁止されています) - 入力データを突っ込む必要はありません - 何もありません!
したがって、ログはバグが発生した時点にさかのぼるタイム マシンです。また、未知のバグを修正するために必要な情報を事前に予測できないため、最初からバグを修正することもできます。ログを記録する必要があります。たくさんのもの...
正確に何をするかはシナリオによって異なりますが、基本的には、どこで何が起こるかを疑うことはありません:)
当然、これは大量のロギングが行われることを意味します。次に、2 つのログを作成します。1 つは必要にならないことを確認するのに十分な期間のみ保持されるすべてのログで、もう 1 つはより長期間保持できる重要な情報です。
ログを過度に無視することは、通常、バグを修正する必要がなく、他に何もする必要がない人によって行われます:)
アプリケーションのベータ リリース中にバグに遭遇し、それを再現できない場合は、過剰なログ記録を行うべきだったことがわかります。同様に、クライアントがバグを報告しても、それを再現できない場合は、過剰なログ機能で問題を解決できます。
顧客のシナリオ (つまり、マシンに物理的にアクセスできない人) がある場合、「ログが多すぎる」のは、関数の再描画と、それらによって呼び出されるほぼすべてのもの (ほとんど何もないはずです) だけです。または、操作中に毎秒数百回呼び出される他の関数 (ただし、プログラムの起動は問題ありませんが、私の経験では、ほとんどの問題が発生する場所であるため、ルーチンを取得/設定するための数百回の呼び出しがログに記録されます)。
そうしないと、ユーザーのマシンの問題が何であるかを明確に示す重要なログ ポイントが欠落しているときに、自分自身を蹴ることになります。
(注: ここでは、ユーザー指向の通常操作ログではなく、開発者指向のログに対してトレース モードが有効になっている場合に発生するログについて言及しています。)
私の仕事では、多くのWindowsサービスを作成しています。私にとって、ロギングは贅沢ではありません。それは実際には私の唯一のUIです。本番環境にデプロイすると、デバッグにアクセスできなくなり、サービスが書き込むデータベースにさえアクセスできなくなります。ログに記録しないと、発生する問題の詳細を知る方法がありません。
そうは言っても、簡潔なロギングスタイルが最善のアプローチであると私は信じています。ログメッセージは、「入力された関数yyy」よりも「アカウントxxxから受信したメッセージ」などのアプリケーションのビジネスロジックに限定される傾向があります。例外、スレッドの開始、環境設定とタイミングのエコーをログに記録します。それを超えて、開発フェーズとQAフェーズで論理エラーを特定するためにデバッガーに注目します。
TDDを使い始めてから、ロギングの必要性ははるかに少なくなっています。バグがどこにあるかを判断するのがはるかに簡単になります。ただし、ロギングステートメントはコードで何が起こっているのかを理解するのに役立つことがわかりました。確かに、デバッガーは何が起こっているかについての低レベルのアイデアを提供するのに役立ちます。しかし、何が起こっているのかを高レベルで把握したい場合は、出力行をコード行に一致させる方が簡単です。
ただし、追加する必要があることの1つは、ログステートメントにログステートメントが含まれるモジュールが含まれていることを確認することです。戻ってログステートメントが実際にどこにあるかを見つけなければならなかった回数を数えることができません。
個人的には、まず第一に、厳格なルールはないと信じています。私は、LOT、メソッドのインとアウト、およびステータスの更新を途中でログに記録するアプリケーションをいくつか持っています。ただし、これらのアプリケーションはスケジュールされたプロセスであり、手動で実行され、ログは成功/失敗を保存する別のアプリケーションによって解析されます。
実際には、多くのユーザー アプリケーションは大量のログを必要としないことがわかりました。実際に問題が発生した場合、そこで値をトレースするためにデバッグすることになるからです。さらに、通常、ロギングの費用は必要ありません。
ただし、実際にはプロジェクトによって異なります。
これらの行のうち、デフォルトでログに記録されているのは何行ですか? 私はあなたが説明したのと非常によく似たシステムで作業しました-起動するだけで、ログが大きくなると20MBを超えるログが書き込まれますが、デバッグでさえ、すべてのモジュールで完全には上げませんでした. デフォルトでは、コードのモジュールが入力されたとき、および主要なシステム イベントがログに記録されます。QA はログをチケットに添付するだけでよいため、デバッグに最適でした。また、再現性がなくても、問題が発生したときに何が起こっていたかを確認できました。深刻なマルチスレッドが進行している場合でも、ロギングは、私が使用したどの IDE やデバッガーよりも優れています。
プログラミングを始めたとき、「Dillie-O」が説明したように、多かれ少なかれすべての詳細を記録したことを告白しなければなりません。
信じてください... 何百もの問題を解決するためにログ ファイルに大きく依存していた、運用展開の最初の数日間、これは非常に役立ちました。
システムが安定すると、付加価値が低下し始めたため、ログ エントリをゆっくりと削除し始めました。(その時点ではLog4jはありません。)
コードとログのエントリの比率はプロジェクトと環境に依存し、一定の比率である必要はないと思います。
最近では、Log4j などのパッケージを使用したログ記録、ログ レベルの動的有効化など、多くの柔軟性があります。
しかし、いつ使用するか、いつ INFO、DEBUG、ERROR などを使用しないかなど、プログラマーが適切に使用しない場合、およびログ メッセージの詳細 (「Hello X、Hello XX、 Hello XXX など」など、プログラマーのみが理解できます) 比率は高くなり続けますが、ROIは低くなります。
別の要因は、使用されているツールセット/プラットフォームとそれに付随する規則だと思います。たとえば、ロギングは J(2)EE の世界ではかなり普及しているようですが、Ruby on Rails アプリケーションでログ ステートメントを書いたことは覚えていません。