Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add response timing middleware #4

Closed
brettlangdon opened this issue Apr 11, 2016 · 2 comments
Closed

Add response timing middleware #4

brettlangdon opened this issue Apr 11, 2016 · 2 comments

Comments

@brettlangdon
Copy link

The first thing I did in my app with this client was to add before_request and after_request handlers to get response time metrics into datadog. Seems like it might be a decent/common functionality people would want?

The gist of it looks like this:

import time

from flask import Flask, g, request
from flask.ext.datadog import StatsD

app = Flask(__name__)
statsd = StatsD(app=app)

def before_request():
    g.request_start_time = time.time()

def after_request(response):
    # Return early if we don't have the start time
    if hasattr(g, 'request_start_time'):
        return response

    # Get elapsed time in milliseconds
    elapsed = time.time() - g.request_start_time
    elapsed = int(round(1000 * elapsed))

    # Collect request/response tags
    tags = [
        'endpoint:{endpoint}'.format(endpoint=request.endpoint),
        'request_method:{method}'.format(method=request.method.lower()),
        'status_code:{status_code}'.format(status_code=response.status_code),
    ]

    # Record our response time metric
    statsd.timing('flask.response.time', elapsed, tags=g.request_tags + tags)

    # Return the original unmodified response
    return response

app.before_request(before_request)
app.after_request(after_request)

This might be something we can do by default when running init_app, or maybe just a method setup_middleware(app) for handling it.

Does this seem like a reasonable thing to try and tackle, or should we leave this middleware stuff as an exercise for the implementer?

@volker48
Copy link

Its definitely common functionality as its pretty much the first thing we did as well. If its done by default it should be able to be disabled. I kind of like the setup_middleware approach. I can see different projects wanting different tags or wanting/needing to use different names for their tags so as long as its customizable it would be a good thing to have.

Feel free to tackle it.

@brettlangdon
Copy link
Author

Yeah, maybe we can do something like:

def before_request():
    g.request_tags = []

def add_request_tags(tag):
    g.request_tags.append(tag)

def after_request():
    tags = [
        # Common request/response tags
    ] + g.request_tags

This way people can add custom tags in an endpoint or in other middleware.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants