ロギングを大幅に活用するプログラムを書いたことはありません。私がやったことのほとんどは、例外が発生したときにスタックトレースをキャプチャすることです。
他の人はどれくらいログを記録するのだろうかと思っていました 作成しているアプリケーションの種類に依存しますか？ログは実際に役立つと思いますか？
ロギングを大幅に活用するプログラムを書いたことはありません。私がやったことのほとんどは、例外が発生したときにスタックトレースをキャプチャすることです。
他の人はどれくらいログを記録するのだろうかと思っていました 作成しているアプリケーションの種類に依存しますか？ログは実際に役立つと思いますか？
回答:
仕事のために、私は非常に貴重なツールにログインして、主に組み込みアプリケーションを実行しました。コードの行を指すのに十分な情報で、少なくともエラーを記録する必要があります。次に、アプリケーション全体の主要な機能ポイントになります。管理者などがマシンにアクセスしました。より詳細なログを有効にできるシステムを使用します。これは通常、開発者固有です。機能のテスト中に開発者を支援するために使用されるか、顧客の問題の診断を支援するために使用される場合があります。
私は、開発したすべてのアプリケーションでロギングを個人的に使用しました。これにより、常にアプリケーションの流れをよりよく理解できるようになりました。特に顧客の手にあるとき。彼らは、（まれに）テストする対象にユースケースを制限しません。
私はそれがアプリケーションの種類に依存するとは思わない：ロギングはすべての（非自明な）アプリケーションで有用です。確かに、私は推測する、それがすることができ、より他のものよりいくつかの用途において有用で、私はそれが今までだとは思わない役に立ちません。
特に、エラーの場合、スタックトレースは正確な障害点でのプログラムの状態を示しますが、エラーの直前の状態についてはほとんど手掛かりがありません。その情報は、問題を追跡するのに非常に役立ちます。また、ログを記録することで、それに対する有益な洞察を得ることができます。それは、最も些細なプログラムを除いてすべてが恩恵を受けることができるものだと思います。
すべてのプログラムに役立つとは限らないロギングのもう1つの用途は、統計分析です。たとえば、Webサーバーは通常、着信するすべての要求をログに記録します。その後、これらのログを分析して、最も忙しい時間、最も人気のあるページなどのグラフを作成できるツールが多数あります。そのデータを使用してキャパシティプランニングを行うことができます（「より大きなサーバーが必要ですか？」など）。
ロギングが実行される理由は2つあります。
診断ログは既に他の人によって議論されており、私はそれ以上の点を酷使しません。ログ障害が発生した場合に何が起こるかを強く考えてください。アプリを通じて例外をスローしたり、別の方法で管理したりするのに十分ですか？これは「依存します」ですが、情報レベルのメッセージのロギングはおそらくスキップする必要があります。
監査ログはビジネス要件です。監査ログは、システム内の重要なイベントをキャプチャします。管理者と法務担当者が関心を持っているものです。これは、誰かがサインオフした人、編集者が行った人などです。これらに少しだけ興味を持っています。ただし、多くの場合、この種類のロギングはトランザクションの一部であり、完了できない場合はトランザクション全体が失敗するはずです。
2つを別々に考えることは、1つが「オプション」でもう1つが必須であるだけでなく、要件によっては実際に別々に実装する必要がある場合があるため、私にとって役立ちます。それらは両方とも果物である場合もありますが、1つはリンゴと他のオレンジです。通常、1つのロギングフレームワークで両方を処理できます。
ほとんどのサーバータスクでは、ログは非常に重要です。これは、管理者は通常、事態が発生したときにそこにいないため、事後をチェックする必要があるためです。
しかし、Googleのある人は、サーバープロセスはログを記録しないと言ったことがあります。代わりに、それらは「機器」です。つまり、すべてのプロセスにフックまたはポートがあり（メカニズムを指定しなかった）、他のプロセスがラッチして、パラメーターと統計を要求できます。ログに多くのものを保存するのはこれらの監視プロセスです。利点は、取得する情報が「ファイルを開く」、「これを書く」、「フェッチする」ことではないことです。「45,453個のファイルを開く」、「653個のサービスXのクライアント」、「クエリYの平均応答344ミリ秒」などの情報を取得します。
確かに別のアプローチであり、たとえそれが数桁小さいとしても、私はシステムをベビーシッターするときに心に留めておく傾向があるものです。
私はすべてを記録したwinforms N-Tieredアプリケーションから来ました。
それはあまり役に立ちませんでした。
確かに、例外のロギングは素晴らしいです。しかし、開発チームに例外をメールで送信できるのに、なぜクライアントのマシンにログを記録するのでしょうか？
情報を記録することは、価値が正当化されることはめったにない中毒になりやすい。無償でログを記録できるすべての状況では、ターゲットを絞った情報を収集し、必要な場所に送信することをお勧めします。
例外情報をキャプチャすることは、ある程度非常に役立つ場合があるため、必須です。ただし、アプリケーションのユーザー/クライアントが適切な情報でエラーを報告できない場合は特に、例外情報では不十分な場合があります。
ロギングはエラー情報のキャプチャのみに制限されていますか？
私の場合（Webアプリケーション）、私は常にどのページが訪問されたか、いつ、何がクリックされたか、IPとブラウザなどをログに記録します。最適化が必要です。できる限りログに記録していると言えます。
最初は、それがどれほど重要かは分かりませんでした。しかし、明らかにそれは多くのことに非常に役立ちます（デバッグ以外）：
統計情報を掘り起こすことが大好きな場合、ロギングはより重要になると思います。
私は、製品が海外に展開されている会社の開発者です。サポートチームが問題の定義について尋ねてきたとき、診断のための唯一のツールは、ログファイルと顧客のデータベースのコピーです。データベースと開発環境を使用して、モジュールと関連するアクションに着信データを記録するため、誤ったケースを再現する機会があります。収集したデータを使用してエラーを再現できる場合は、デバッグで修正できます。ログファイルがない場合は、顧客またはサポートチームがどのような場合に何が起こるか（誤解を招く可能性が高い）の説明に依存する必要があります。
次に、特定のアクションの日付と時刻をログに記録し、どのアクションがどのくらいの時間を消費するかを確認できるため、ロギングにより、デプロイされたサイトでモジュールのボトルネックを検出することができます。
それに加えて、ソリューションが6つのモジュールで構成されており、ログファイルにデータベースタイムアウトに関するエラーログが表示されているとします。これらのエラーが他の5つのモジュールにも記録されている場合、これがSQLサーバー関連の問題である可能性が大きくなります。これが私のモジュールでのみログに記録される場合、クエリがバグである可能性が大きくなります。これらの種類のものは有用な指標だと思います。
ログファイルに表示されるデータの種類については、ログレベルの構成によって異なります。これが新製品の場合、ログレベルを「すべて」に設定して、できるだけ多くのデータを収集します。しかし、製品を改善する場合、情報レベルのログなどではなく、エラーのみを記録するために、ログレベルを「エラー」のままにしておくことをお勧めします。
ロギングは、他のプログラムでは取得できない情報に役立ちます。
注：少なくとも2つのログファイルが必要です。
INFOが常にオンになっています。必要なときにDEBUGがオンになります。
いつかログファイルだけが必要な状況をデバッグしなければならないことを想定してログコードを記述します。正しく実行することが、解雇と昇格の違いになる可能性があります。
余分なマイルについては、すべての関数呼び出しで、Javaでスタックトレースにパラメーターを追加します。
public void sendEmail(String sender, String recipient) {
try {
...
} catch (Exception e) {
throw new RuntimeException("sendEmail(sender="+sender+", recipient="+recipient+")");
}
このアプローチは、パラメータ値でコールスタックを本質的に強化し、スタックトレースだけで状況を分析でき、ログファイルを表示する必要がない場合があります。
最も確実に、構築しているシステムのタイプに依存します。
ワードプロセッサなどのスタンドアロンのデスクトップアプリケーションを作成している場合、おそらくログは必要ありません。
組み込みシステムを作成している場合、ログなしでは生きられません。そうしないと、組み込みデバイスがフリーズしたときに、理由がわかりません。また、システムに複数のプロセスまたは相互に通信する複数の物理マシンが含まれる場合は常にログが必要です。繰り返しになりますが、システムがハングした場合、いつどのような理由でシステムのどの部分が停止したかを知る必要があります。ログを比較して、あるプロセスから別のプロセスにデータが移動したかどうかを判断できる必要があります。同様に、ユーザーの直接的な操作をほとんど必要とせずにシステムを長時間実行する場合は、常にログを記録する必要があります。