benoitc/gunicorn

Separate instrumentation and logging

Open

#1,564 opened on Aug 6, 2017

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

Description

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.

Contributor guide

Tech stack
python
Domain
backendobservability
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
mostly clear
Prerequisites
basic understanding of gunicorn
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
30
Research direction
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.