12

トラフィックの多いいくつかの Web サイトで数年間 Log4Net を使用してきましたが、満足のいく顧客とは言えません。だから、他の誰かが同じ懸念を持っているかどうかを見たかった:

  1. RollingFileAppendor の CPU オーバーヘッドは膨大です。私の Web サイトの中には、1 日あたり 5 ~ 10 GB をトレースする必要があるものがあります。ロギングを有効にすると、CPU 使用率が 2 倍以上になります。なぜそれほど多くのトレースが必要なのかについての議論は避けたいと思います。一部のミッション クリティカルなアプリでは、すべてのトランザクションのすべてのステップを追跡する必要があります。

  2. 日付によるローリングは信頼できないことがよくあります (日中は問題なくログに記録されますが、真夜中頃には前日のログ ファイルが台無しになります)。この動作には一貫性がありません。これについて不満を言う人がオンラインで数人いるようですが、誰も良い解決策を持っていないようです.

  3. 最後になりましたが、過去 3 年間、Apache Web サイトで新しいリリースを見たことがありません。そのため、これは放棄されたオープン ソース プロジェクトのように見え始めます。これは通常、別のフレームワークに移行する時期であることを意味します。

そのため、Log4Net をあきらめて、Microsoft Enterprise Library などを選ぶことを検討しています。ここに私と同じ問題を抱えている人はいますか?

4

6 に答える 6

3
  1. はい、CPUを使いすぎる傾向があります。私は1日あたり最大15GBを記録したアプリを持っていて、CPU使用率はやや高かった。ロギングを約4GB/日に削減しましたが、CPU使用率はまったく目立たなくなりました。
  2. 私はこの動作を見たことがありません(そして、トラフィックの多いWebサイトで1.1.1(3年)からlog4netを使用しています)
  3. はい、それはちょっと静かですが、それはおそらくそれが安定した成熟したプロジェクトだからです。そして、開発は完全に停止していません。svnリポジトリで、最近いくつかのコミットが行われていることがわかります。これについて懸念がある場合は、NLogをご覧ください。これは、より若く、より活発なプロジェクトです。

これが比較のための私のアペンダー設定です:

<appender name="LogFileAppender" type="log4net.Appender.RollingFileAppender, log4net" >
    <param name="File" value="log" />
    <param name="AppendToFile" value="true" />
    <rollingStyle value="Date" />
    <datePattern value="yyyyMMdd" />
    <maxSizeRollBackups value="7" />
    <layout type="log4net.Layout.PatternLayout, log4net">
        <param name="ConversionPattern" value="%d [%t] %-5p %c [%x] - %m%n" />
    </layout>
</appender>
于 2009-06-11T14:38:54.483 に答える
2

ASP.NET 2.0のヘルスモニタリングの使用、および方法:ASP.NET2.0でヘルスモニタリングを使用する方法を確認できます。

しかし、私はあなたが同様の問題を抱えていると思います。ロギングツールを監査ツールとして使用しようとしていますが、正確には設計されたものではありません。

「一部のミッションクリティカルなアプリは、すべてのトランザクションのすべてのステップを追跡する必要があります。」-これは、トランザクションの一部としてデータベースに記録する情報です。トランザクションの外部で実行される場合、情報が正しいことをどのように保証できますか?

于 2009-06-11T14:35:23.073 に答える
2

あなたの場合ではないかもしれませんが、このような大量のログデータでは、実行時に実際のアプリケーションにまったくまたは最小限の影響を与えるログ管理システムを使用する必要があると思います。アプリケーションがログを作成するだけでない限り、ギガバイトのログをロールアラウンドして管理するのはかなり面倒です。もう 1 つのポイント - 特にパフォーマンスに関して、entlib ロギングのユーザーから多くの不満を聞いています。それに切り替える前に、データ量がどのように処理されるかを確認します。しかし、たとえ log4net よりも優れていると感じたとしても、巨大なログ ファイルを自分で管理することになると思います。

于 2009-06-11T16:34:20.430 に答える
1

これまでのところ、すべてを日付ベースのローリング機能のせいにする傾向があります。いくつかのサーバーでサイズベースのローリングに切り替えてみましたが、データの損失は見られなくなりました。もちろん、これはかなりの回避策ではありません。1 日に 1 つのトレース ファイルがなくなるからです。また、サイズベースのローリングには、ファイルのローリングが早すぎたり遅すぎたりするバグがあるようです。しかし、これは元の問題ほど苦痛ではありません...

于 2009-06-15T15:11:28.797 に答える
0

パフォーマンスの問題については、log4netの優れた点は、log4netのアプリケーション使用がボトルネックになっている場所をいつでもプロファイリングして、1)ソリューションに自分で取り組むか、2)そのボトルネックがないロギングフレームワークを見つけることができることです。

私はあなたのアプリケーションを知らずにあまり助けることはできませんが、log4netソースをざっと見てみると、NextCheckDate()関数がすべてで呼び出されている ことに気づきましたvoid Append(LoggingEvent loggingEvent)。以下にNextCheckDateのソースの一部を含めましたが、これが大量のロギングシナリオでパフォーマンスの問題を引き起こしていることをはっきりと想像できました。

protected DateTime NextCheckDate(DateTime currentDateTime, RollPoint rollPoint){
// Local variable to work on (this does not look very efficient)
DateTime current = currentDateTime;

// Do different things depending on what the type of roll point we are going for is
switch(rollPoint) 
{
    case RollPoint.TopOfMinute:
        current = current.AddMilliseconds(-current.Millisecond);
        current = current.AddSeconds(-current.Second);
        current = current.AddMinutes(1);
        break;

    case RollPoint.TopOfDay:
        current = current.AddMilliseconds(-current.Millisecond);
        current = current.AddSeconds(-current.Second);
        current = current.AddMinutes(-current.Minute);
        current = current.AddHours(-current.Hour);
        current = current.AddDays(1);
        break;

    case RollPoint.TopOfMonth:
        current = current.AddMilliseconds(-current.Millisecond);
        current = current.AddSeconds(-current.Second);
        current = current.AddMinutes(-current.Minute);
        current = current.AddHours(-current.Hour);
        current = current.AddMonths(1);
        break;
}     
return current;}

アプリケーション用に最適化されたバージョンは、おそらく次のロールオーバー時間を事前にキャッシュし、それぞれに対して1つの比較のみを行います。Append

于 2011-03-23T08:27:45.417 に答える
0

そのため、Log4Net をあきらめて、Microsoft Enterprise Library などを使用することを検討しています。

考慮すべき代替ロギング フレームワークの比較については、http://essentialdiagnostics.codeplex.com/wikipage ?title=Comparison を参照してください。

.NET Framework System.Diagnostics (組み込み機能)、log4net、NLog、および Enterprise Library を比較し、パフォーマンスの比較も行います。

それぞれに長所と短所がありますが、EntLib はパフォーマンスの比較で特に劣っており、機能に関しては、組み込みの .NET Framework System.Diagnostics よりも少ない場合があります。

パフォーマンスが特に気になる場合は、log4net が .NET Framework System.Diagnostics と同様に若干優勢です。

NLog は、ログを記録しない場合 (つまり、コードにそのまま残す場合) のオーバーヘッドがほとんどなく、log4net や System.Diagnostics よりも高速ですが、ログの量が増えると遅れが生じ始めます。

System.Diagnostics を使用してログのローテーション (循環を含む) を使用した高パフォーマンスのログについては、最近ブログで取り上げた EventSchemaTraceListener を参照してください。良い。

心配な場合は、パフォーマンス テストを設定することをお勧めします。上記の比較については、パフォーマンス比較のソース コードがEssential Diagnosticsプロジェクトで入手できるため、自分で実行できますが、状況に合わせて調整する必要がある場合があります。

于 2013-04-21T07:22:34.813 に答える