Closed Bug 1227279 Opened 9 years ago Closed 8 years ago

200-inator service for FHR EOL

Categories

(Cloud Services Graveyard :: Metrics: Pipeline, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: whd, Assigned: whd)

References

Details

This is a proposed solution to monitoring FHR after EOL, any concerns should be addressed here before implementation.

Ops has provisioning logic for services that return a single status code:

https://github.com/mozilla-services/puppet-config/tree/master/n_inator

The idea is we set up a 200inator fronted by an ELB, enable ELB logging, and use the logs for monitoring FHRv2 health. In this way we will discard the payloads but still have IP, UA and request path, which should be sufficient for monitoring (we would need an ELB log decoder, but the format is easy to parse). The overhead and cost of running the service would be small, and setting it up would also be easy.
Blocks: 1227281
Priority: -- → P2
Please make sure this works for both kinds of Bagheera requests -- upload and delete.

Is the timeline for this planned to be at the moment of EOL? Quietly returning 200s will make client failures less of an issue, avoiding costly retries.
https://github.com/mozilla-services/puppet-config/pull/1873/files
https://github.com/mozilla-services/svcops/pull/922/files

Living at https://fhr.dev.mozaws.net and https://fhr.r53-2.services.mozilla.com. The latter is the production server with the production SSL cert that will be cut over to once things have been tested.
Assignee: nobody → whd
Priority: P2 → P1
closing as test is available, opening new bug for live cut over.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Product: Cloud Services → Cloud Services Graveyard
You need to log in before you can comment on or make changes to this bug.