benoitc/gunicorn

Separate instrumentation and logging

Open

#1,564 opened on 2017年8月6日

GitHub で見る
 (9 comments) (4 reactions) (0 assignees)Python (9,334 stars) (1,707 forks)batch import
Feature/LoggingImprovementhelp wanted

説明

Issues like #1405 demonstrate that having statsd instrumentation built on top of the logging handlers means instrumentation and logging are coupled. Some have found this coupling surprising.

I would like to see proposals for ways to separate these functions.

This may be as simple as making the statsd Logger into a handler instead, so it can be invoked no matter which logger is being used.

コントリビューターガイド

技術スタック
python
領域
backendobservability
Issue 種別
feature
難度新しい貢献者にとっての実装難度です。1 は非常に小さな変更、5 は専門的な作業です。
3
推定時間経験ある貢献者が調査、実装、テスト、pull request 準備にかけるおおよその時間範囲です。
1-2 days
活動状況Issue が今どれだけ取り組みやすいかを示します。新しい、活発、古い、ブロック中、またはメンテナー入力待ちなどです。
stale
明確さ期待される変更、受け入れ条件、次の手順がどれだけ明確かを示します。
mostly clear
前提条件
basic understanding of gunicorn
初心者向け度初回貢献者にどれだけ取り組みやすいかを 1-100 で推定したスコアです。
30
調査方針
The issue requests a design to decouple statsd instrumentation from logging handlers in gunicorn. A starting point is to examine the existing statsd integration in gunicorn's handlers (e.g., 'gunicorn.instrument.statsd') and the logging configuration in 'gunicorn.glogging'. The discussion in comments suggests converting the statsd Logger into a separate handler. You should review the referenced issue #1405 and explore the codebase to understand current coupling before proposing a solution.