chore: remove db audit logging as it is handled by apitally#334
chore: remove db audit logging as it is handled by apitally#334suvanbanerjee wants to merge 1 commit into
Conversation
| allow_methods=["*"], | ||
| allow_headers=["*"], | ||
| ) | ||
| if conf.get_string("backend.source") != "dataplatform": |
There was a problem hiding this comment.
so this doesnt run for the dataplatform background.
What services are we getting this error for?
There was a problem hiding this comment.
can you see what API we are getting this warning from
There was a problem hiding this comment.
looks like they are hitting out server ip directly and not api.quartz.solar
uk-api on sentry has around 52k events in devleopemnt and 49.5k events on prod,
There was a problem hiding this comment.
and do you know which api it is?
There was a problem hiding this comment.
@peterdudfield I'm not entirely sure which environment is firing these, here's what I found:
I found this request in Sentry hitting http://54.155.28.70/:
When I visited http://54.155.28.70/docs it only serves substations endpoints, which points to uk-development-quartz-api with ROUTERS=substations:
However when I checked the AWS config for uk-development-quartz-api, it has SOURCE=dataplatform, which means the audit middleware guard skips it entirely:
So I'm not sure how it's still firing, do you have any idea what I'm missing here?
There was a problem hiding this comment.
on thing, not sure might be the cause, that the API version running on EBS is currently on 0.3.27 (fetched from EBS logs and checked on teraform)
and this dataplatfom exclusion code was added in d0f7eb1 on 27may (around a month back)
There was a problem hiding this comment.
ah ok, so we need to upgrade the substation api, from 0.3.27 to the latest. Would that solve it?
2 participants
Pull Request
Description
Remove the RequestLoggerMiddleware (db audit logging), as request logging is now handled by Apitally. This eliminates the Failed to log request to DB: Database client not found in app state Sentry events which were the dominant source of Sentry quota consumption (~101K out of 140K total requests in the last 90 days), mostly triggered by automated scanners hitting 404 endpoints.
How Has This Been Tested?
Tested locally by removing the audit middleware and sending a 404 request, confirmed no sentry error via local logs.
Checklist: