Log the more precise reason for why API Umbrella rejects a request in the analytics

[GUI]

When the api-umbrella-gatekeeper component denies a request, it can be for a variety of reasons (no API key is supplied, invalid API key, over rate limit, etc). However from a logging and analytics perspective, all that we log is the HTTP response status code (as we do for all responses). While you can usually use this HTTP response status code to help discern why a request may have been rejected, it's not the easiest thing to query, and we're having a growing number of possible errors that have overlapping HTTP status codes (eg, there's multiple reasons why we might return a 403 forbidden error).

To solve this, I think it would be helpful for us to begin logging our internal error code we return when the gatekeeper component is responsible for denying the request.

I'll flush this issue out with a bit more detail shortly on where all the different components this touches are located.

[GUI]

So it turns out this is actually more implemented than I thought. I did vaguely recall implementing this, but I didn't see it when I was looking for it last week and hence the issue. However, there's still stuff to probably do here, since while we are storing the information in the analytics db, we haven't actually exposed the details via the admin analytics interface, which I think would be quite useful (so I don't forget about this again and think it needs to be done all over again :).

So if you're up for diving into more of the admin UI side of things, here's a bit more of a brain dump on things:

• For reference, here's how this bit of information flows out of the gatekeeper: https://github.com/NREL/api-umbrella-gatekeeper/blob/c141e5b61a88599a52ebb998d893fbb8281bcae0/lib/gatekeeper/worker.js#L176-L178 and then get aggregated with the other bits of log data we collect from nginx in the router's log_processor process: https://github.com/NREL/api-umbrella-router/blob/4be3f25051f9583d632e581e4e0c09421c16d861/lib/log_processor/worker.js#L230
• The next step would be to ensure this gatekeeper_denied_code field is being returned in the API that the returns the data for the "Filter Logs" table. Luckily, it already appears to be, since we return everything except for a couple fields: https://github.com/NREL/api-umbrella-web/blob/e951cfd8e799a29bc20590389e305dc052b0420b/app/views/admin/stats/logs.rabl (I'm not necessarily wild about these Rabl templates, but it's the stuff inside in the node :data block).
• From there, to display this in the admin UI, you'll need to add this as a field to the "Filter Logs" table. This table uses DataTables, and here's how we display the response_status field: https://github.com/NREL/api-umbrella-web/blob/master/app/assets/javascripts/admin/views/stats/logs_table_view.js#L109-L114 I think it should be fairly easy to drop this in as another field we display, or if we want to get fancier, we could inline the display along with the the existing status field (since this field will be empty in non-error cases, but I don't really have much of an opinion).
• I think the only other tidbit is to ensure that this field also gets returned with the "Download CSV" link that's available below the results table. Since that bulk downloads the entire dataset (without pagination), that will just hit a slightly different API endpoint, where we would also need to return this information: https://github.com/NREL/api-umbrella-web/blob/e951cfd8e799a29bc20590389e305dc052b0420b/app/controllers/admin/stats_controller.rb#L72-L92

[GUI]

This was addressed by @cmc333333 in NREL/api-umbrella-web#11 and has been deployed to production. Thanks!

I also forgot to mention this in the earlier description of this task, but one other small piece of that would be useful would be to add this field to the query builder interface to make it easier to filter on this field. I went ahead and tackled that in NREL/api-umbrella-web#14