Go での無効なステートメントの効率的なロギング

クリティカル パスでは、動的に切り替えることができるデバッグ/トレース ロギング ステートメントを埋め込むと有益です。ランタイム。この方法は、オフラインにした実稼働システムのデバッグや、実稼働環境をミラーリングするテスト システムのデバッグに最適です。

ただし、このタイプのログ記録には重要な要件があります。それは、無効なステートメントがパフォーマンスに与える影響を最小限にする必要があります。 C/C では、これは、フラグがチェックされるまで引数の評価を抑制する LOG マクロによって実現されました。

Go での無効なロギングの実装

Go でのこの動作のエミュレーション課題を提示します。 log.Logger で io.Discard を使用することは、無効な場合でもログ メッセージをフォーマットするため、オプションではありません。

EnabledLogger 構造体を使用した最初の試行では、log.Logger インターフェイスが実装され、Enabled に基づいてロギングが有効/無効になります。フラグ。ただし、引数の評価は抑制されないため、任意の関数呼び出しでパフォーマンスの問題が発生する可能性があります。

2 つの回避策

これに対処するには、2 つの回避策があります:

1. ラッパー タイプ: ラッパー タイプを使用して関数呼び出しを延期し、式が確実に有効なチェックに合格するまで評価されません。
2. 手動チェック: 有効なチェックでロギング ステートメントを手動でラップし、無効な場合に実行されないようにします。

どちらのアプローチも冗長でエラーが発生しやすいコードとなり、潜在的なパフォーマンス低下への扉を開きます。

その他オプション

Go の静的評価ルールにもかかわらず、いくつかの追加オプションがあります:

• カスタム ログ フォーマッタ: fmt.Stringer と fmt.GoStringer の利用インターフェイスは実行時まで引数のフォーマットを遅らせることができます。
• Runtime Loggerスワッピング: ロガー インターフェイスまたはビルド制約を介してロギング メカニズム全体をスワップ アウトできます。
• Go コード生成: 高度なコード生成技術により、AST と特殊なデバッグ ビルドを生成します。

これらのソリューションは動的なランタイム構成には理想的ではありませんが、特定のパフォーマンスの向上をもたらすことができます。シナリオ。