速度が重要なシステム (統計/分析、ソケット プログラミングなど) があるとします。トレースとログをどのように設計すればよいでしょうか。
より具体的に言うと、ログとトレースは一般的にパフォーマンスを低下させます (スイッチ オフ メカニズムまたは冗長拡張メカニズムがある場合でも)。このようなシナリオでは、問題が発生したときに (特に本番サイトで) 開発者/ポストプロダクション チームが実際の問題を特定できるように、ログ/トレースを「配置」する方法に関する参照ガイドラインはありますか?
PS: 私は、そのようなアプリケーションが C/C++ (Linux 上で実行される) で開発されているバックグラウンドを持っています。
Google Protocol Buffersを使用して記述および実装できるバッファ内にログを蓄積できます。別のスレッドで定期的 (5 分ごと) にこのバッファをディスクに空にするか、UNIX ドメイン ソケット(または他のLinux IPC メカニズム) を介してデーモンに送信し、リッスンして永続 DB に書き込むか、単にディスクに書き込むことができます。
ログを生成するマシンのディスクにアクセスしたくない場合は、通常のソケットを介してログを別のマシンに送信し、そのマシンのディスクに書き込むことができます。
複数のマシンからログを集約する場合は、メッセージ キューとして0MQまたはCrossRoadsを使用して、ログが永続的に保存されるマシンにネットワーク経由で渡すことを検討してください。Google Protocol Buffers と組み合わせて 0MQ を使用する方法については、こちらを参照してください。