【要約】ログを観測の単一ソースにする — CodeRouter v1.5.0 観測まわり 4 つの設計判断 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
- ・メトリクス専用コードの散乱による、ログと数値の乖離。
- ・タイムゾーン処理の不備による、集計ミスやデータの順序混乱。
- ・CLIとダッシュボード間で、表示される数値が異なる「乖離バグ」。
- ・外部ライブラリの過剰な導入による、依存関係の肥大化。
// Approach
1.
MetricsCollector を logging.Handler のサブクラスとして実装。既存の構造化ログから自動的にメトリクスを抽出する。2.集計は常にUTCで行い、表示層（CLI TUI / HTML）でのみタイムゾーン変換を実施。DST等のバグを構造的に排除する。
3.
/metrics.json を共通データソースとし、描画層（TUI / HTML）を分離。表示の整合性を担保する。4.
prometheus_client を使わず、手書きの文字列生成でPrometheus形式を出力。依存関係を最小化する。// Result
- ・業務ロジックへの計測コード追加をゼロに抑制。
- ・テスト数を 457 から 527 へ増加させ、品質を向上。
- ・依存ランタイムを5個に維持し、極めて軽量な構成を実現。
- ・ログとメトリクスの完全な整合性を確保。
Senior Engineer Insight
> 極めて理にかなった、堅牢な設計だ。特に「ログを単一のソースにする」判断は、分散システムにおける観測の乖離を防ぐ実践的な解である。
logging.Handler を利用することで、開発者がメトリクスを意識せずとも、ログを書くだけで観測が完了する。これは開発体験（DX）と運用信頼性の両立に寄与する。また、依存関係を最小化する姿勢も、プロダクション環境での安定稼働において高く評価できる。実戦投入に値する設計思想だ。