7

アプリケーション内でどれだけの人がログに記録しているのか?

私はこれを見ました：

「私は通常、アプリケーションによってキャッチされた例外をログに記録するために ERROR ログ レベルを使用するのが好きです。メソッドを開始または終了するたびに表示する「第 1 レベル」のデバッグ スキームとして INFO ログ レベルを使用します。そこから使用します。詳細情報を追跡するための DEBUG ログ レベル。FATAL ログ レベルは、Web ベースのアプリケーションでキャッチできなかったすべての例外に使用されます。」

このコードサンプルが含まれていました：

Public Class LogSample

   Private Shared ReadOnly Log As log4net.ILog = log4net.LogManager.GetLogger(GetType(LogSample))

   Public Function AddNumbers(ByVal Number1 As Integer, ByVal Number2 As Integer) As Integer

      Dim intResults As Integer

      Log.Info("Starting AddNumbers Method...")
      Log.Debug("Number1 Specified: " & Number1)
      Log.Debug("Number2 Specified: " & Number2)

      intResults = Number1 + Number2

      Try

         intResults = Number1 + Number2

      Catch ex As Exception

         Log.Error("Error Adding Nubmers.", ex)

      End Try

      Log.Info("AddNumbers Method Complete.")

      Return intResults

   End Function

End Class

しかし、これは方法に多くを追加しているようです。たとえば、通常はおそらく 7 行のコードであるクラスが、突然 12 行のコードになります。この方法はまた、その明快さと単純さの一部を失います。

しかし、ロギングを適切に行うことの利点は良いと言えます。たとえば、実稼働システムでのパフォーマンス監視、実稼働での異常なバグの追跡 (このすべてのログを常にオンにしているわけではありません。

したがって、私は人々が何をしているのか疑問に思っています。乾杯アンソニー

4

6 に答える 6

4

...ねえ、SO の質問でトピックとして引用されるとバッジをもらえますか? 8^D

しかし、真剣に、上記のロギング コメントについて明確にしたいことの 1 つは、「詳細な」ロギングの正当化の一部は、log4net 自体の機能を活用しているという事実に基づいているということです。

私が提供したサンプルでは、​​そのメソッドは WARN モードで毎日ログを記録します。つまり、「デフォルトで」ログに記録されるのは、例外が発生した場合だけです。クライアントの 1 人からアプリケーションでエラーが発生したという電話を受けた場合、クライアントは画面上の不可解なメッセージを読む必要はありません。ログにジャンプして、何が起こっているかを確認できます。ほとんどの場合、答えはすぐそこにあります。

答えがすぐに得られない場合はどうなりますか? Log4net を使用すると、構成ファイルを更新して (再コンパイルは必要なく、システム管理者の承認を得て Web サーバー上の特別なシステム ファイルにアクセスする必要もありません)、INFO モードに入ることができます。これで、ロギングの 2 番目の層が見え始めます。コードが特定のループに到達しなかった可能性があります。データ取得のレコード セットが空の可能性があります。この 2 番目のレベルのデバッグは役に立ち、ログはわずかに大きくなります。これが完了したら、構成を再度変更して、ライト ログに戻ることができます。

当然のことながら、物事が本当にクレイジーな場合は、完全なデバッグ レベルに進み、各変数が何を報告しているか、どの DataRow を扱っているか、アプリケーションで何が起こっているかを知りたいと思います。私の現在の職場では、Web アプリケーションにリモート デバッグを実行する機能がありません。また、データを拡張する可能性がなければ、常に運用データベースを利用できるとは限らないため、この完全なデバッグを実行することが次善の策です。

過剰なロギングは実際にアプリケーションをダウンさせ、必要以上の問題を引き起こす可能性があるという大多数の人々に同意します。アプリケーションがセキュリティ上の理由でそれを保証しない限り、アプリケーションでこの種の詳細なログを記録することはお勧めしません。ただし、必要に応じてコードを再コンパイルせずに詳細ログを利用できることは、私の意見では大きな利点であり、簡単に許可できるフレームワーク (log4net など) がある場合は、ナイスで冗長になり、コード自体に戻る必要がある場合は、ログ コード参照を頭の中で除外するのは簡単です。

私が防御的または暴言を吐くように聞こえる場合は申し訳ありませんが、それは決して意味するものではありません. 上記の方法で log4net を使用してロギングをセットアップする方法と理由について、もう少し背景を説明したいと思います。8^D

于 2008-10-23T23:41:34.037 に答える
4

それはプログラミングのアート面です。

すべてをログに記録する必要はありません。ただし、システムの最も重要な部分をログに記録する必要があります。

プログラムを広い意味で考えて、本番環境で何かが壊れた場合に必要な情報を特定してみてください。

まず、アプリケーションのすべてのコア ロジック モジュールにログ機能が必要です。UI/アニメーションなどの装飾的な部分は、ログを記録する必要はありません。

私見、すべてのメソッドのエントリ/出口をログに記録するのはやり過ぎであり、特にスタックトレースを埋め込むことができるため、ノイズも発生します。

また、パフォーマンスのために、プロファイラーを使用してください。

于 2008-10-23T23:26:20.620 に答える
3

これにより、コードの読み取りと保守がより困難になることは間違いありません。1 つの推奨事項は、AOP (アスペクト指向プログラミング) ツールを調べて、ログ ロジックをアプリケーション ロジックから分離することを検討することです。Castle Windsor と Spring は、.Net コミュニティ内で思い浮かんだ 2 つの調査対象です。

于 2008-10-23T23:20:28.150 に答える
0

最低限、エラーと外部コンポーネントへの呼び出しをログに記録する必要があります...提供するサンプルは、私があまりにも多くのログと呼ぶものです...メソッドの開始時または途中にいることをログに記録するポイントはありませんメソッドの終わり、またはメソッドに渡されたパラメーターでさえ...ディスクスペースの無駄です。ログファイルはすぐに非常に大きくなります...

Rウェンディ

于 2008-10-24T01:23:46.793 に答える
0

どの程度のロギングで十分かを判断するのは簡単ではありません。例のように関数内のログ コードが多すぎると、実際のロジック コードが埋もれてしまいます。ログ エントリが多すぎると、ログが煩雑になります。しかし、ログが少なすぎるとあまり役に立ちません!!

.NET の場合、AOP ライブラリの PostSharp を使用して、関数の開始と終了を引数の値などと一緒にログに記録できます。

アプリケーションをどの程度ログに記録するかを決定するには、Marcus Ranum によるこの記事「System Logging and Log Analysis 」を参照してください。

お役に立てれば。

于 2016-05-20T20:17:55.110 に答える
0

セキュリティの観点から、ロギングは興味深いトピックになる可能性があります。数回の DDOS 攻撃を受けて、しばらく前に CSO Online にブログ エントリを書きました。これは、ロギングについて説明したセクションです。少し役立つことを願っています。

ログ スロットリング、書き込み専用ログ、ログ サーバーの使用などの手法により、システムの遡及的なセキュリティを強化できます。DDoS 攻撃が発生した可能性がある場合、企業は間違いなくその攻撃を調査したいと考えるでしょう。調査は、正しいレベルのロギングが使用されている場合にのみ可能です。多すぎると、ログがすぐにいっぱいになり、そもそも DoS の原因になる可能性があります。ログが少なすぎると、犯罪者を捕まえるのに十分な情報が含まれていないため、ログは無価値になります。

于 2008-10-23T23:20:49.350 に答える