現在非推奨であり、削除される機能があります。いくつかのアラートメカニズムによって観察されるログステートメントを追加すると、機能がまだアクティブに使用されているかどうかを確認し、それを行うクライアントをアップグレードできます。
診断には必ずしも技術的に重要ではありませんが、意味的に適切なログレベルは何でしょうか。
または、言語/フレームワーク/エコシステムでサポートされている場合は、カスタムレベルを作成しますか?
私の過去の経験では、私は通常、実稼働環境で有効になっている最低レベル(INFO
?)を使用しています。次に、log msgの前にキーワードタグを付けます(例:DEPRECATED
)。ログモニター/アラートツール(私は社内ツールでしか経験していないため、どのツールも提案できません)で、キーワードタグを一致条件として指定します。 WARNING
は使用しないようにします。これらのログメッセージは、実際の問題から注意をそらす可能性があるためです。
--- 2/28に更新
考え直してみると、追跡が必要な非エラーにはINFO
を使用するため、私のアプローチはすべての組織で機能しない可能性があります。他の非エラーログはVERBOSE
またはDEBUG
に送られます。会社のログ戦略が異なる場合、大量の本番ログが作成される可能性があります。
ここでは、NLogを例として使用します。これは、私が最もよく使用するロギングフレームワークです。同様のフレームワークには同様の機能があると期待しています。
警告:最終的にすべてのクライアントをアップグレードする必要があるため。アップグレード後、これはエラーになります。
ここにあなたの推論があり、警告を構成するものについて一般的に使用されている定義が間違いなくここに当てはまります。ただし、この機能を使用しているときは常に、警告がログに大量に送信されるのではなく、単一の警告(起動時など)の場合にのみ、これを使用します。
これらのメッセージのスパム(つまり、実際のイベントの邪魔になる)による問題は、このメッセージを低レベルから警告にアップグレードしたという追加の利点よりも有害です。
INFO、それは単なる情報です。
私はこの推論にいくらか従うことができますが、私の意見では、それはさらに低いレベル(DEBUG/TRACE)に属しています。これは事実上、開発者にとっての情報であり、本質的にはDEBUG/TRACEの構築対象です。 INFOメッセージは、開発者と非開発者の両方を対象としています。このメッセージは、開発者にのみ関連しています。
または、言語/フレームワーク/エコシステムでサポートされている場合は、カスタムレベルを作成しますか?
可能な場合はこれを選択します。新しいレベルは、それ自体が単独のレベルである必要はありませんが、可能な場合は可能であり、関連があると見なされます。
たとえば、NLogを使用すると、別のレベルと同様に動作するが名前が異なるさまざまなレベルを追加できます。たとえば、機能的にDEBUGと同等の非推奨レベルを作成できます。
つまり、レベル範囲フィルタリング(TRACEからINFOにキャプチャするロガーなど)を使用する場合、DEPRECATEDメッセージは常にDEBUGメッセージと一緒にバンドルされますが、ログメッセージ自体には異なるラベルが付けられるため、一方を他方とすばやく区別できます。例えば非推奨のメッセージを知っていて、とりあえずそれらを除外したい場合。
カスタムログレベルを定義できるフレームワークがなくても、ログメッセージにDEPRECATEDキーワードを付加するか、カスタムログプロパティに登録することで、ログメッセージにタグを付けることができます(NLogでは、必要に応じて別のフィールドに保存できる値)
どちらでもない。
すべてのメソッドへの呼び出しの量/レートを記録するメトリックをサーバーに追加します。
または、接続しているクライアントのバージョンがさらに良い。
その後、必要に応じて使用状況を報告できます。
ロギングは、エラーではなく、エラーではないロギングで本番コードを実行したくないため、これには適していません。
どちらも、
これは、実行時にユーザーに役立つ情報ではありません。
C#のサンプルのように、独自のコードでプログラミング時にこれを通知することをお勧めします。
コードの廃止についてアドバイスし、代わりに使用する置換関数を提案するドキュメントにコードを追加することもできます。