From f8473104ecd14cc617394bc38069022048e68c3d Mon Sep 17 00:00:00 2001 From: Morten Brekkevold Date: Fri, 20 Dec 2024 14:38:34 +0000 Subject: [PATCH] Stop logging proxied 5XX Graphite errors This adds what amounts to a dirty hack to the graphite-web proxy view (i.e. it reaches into Django internals) to prevent Django from doing a full error response log when proxying 5xx class errors from graphite-web. It does so by tricking `django.utils.log.log_response()` into thinking that the response has already been logged (since our view function has no other control over how its return values are logged by Django). The reason for the 5xx response codes are not bugs in our view code, and does not need to trigger site admin e-mails. --- python/nav/web/graphite/views.py | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/python/nav/web/graphite/views.py b/python/nav/web/graphite/views.py index 409c9cc293..76740e1e3f 100644 --- a/python/nav/web/graphite/views.py +++ b/python/nav/web/graphite/views.py @@ -73,6 +73,14 @@ def index(request, uri): else: response = HttpResponse(output, content_type=content_type, status=status) + # Dirty hack to prevent logging of 5XX errors. More specifically, this prevents + # a full Django error mail from being sent when Graphite is down or otherwise + # failing. (I.e. we're just proxying the status code, there is no error in our + # application that needs to be mailed to anyone). + if status >= 500: + # Tricks Django into thinking this response has already been logged: + response._has_been_logged = True + response['X-Where-Am-I'] = request.get_full_path() return response