Start doing the minimum in /status checks #984
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
https://eaflood.atlassian.net/browse/WATER-4096 AWS ELBs require an endpoint they can hit to confirm whether an app is running. They are commonly referred to as health checks and are used to determine whether the ELB should route traffic through to an app instance. In our apps, it is the `/status` endpoint. The endpoint in all our repos currently reads in the `package.json` file to get the app's version number. This information is then used to support the `/service-status` page in the water-abstraction-ui. Some of the repos also include a test query to the DB to confirm it can connect. Having checks that confirm you can connect to dependent services (databases, other apps etc) is a good thing. But the ELB health checks are made multiple times a second across all instances. They only care whether an app is up or not. So if, for example, you include querying your DB in `/status` you're hitting your DB with multiple connections per second, multiplied by the number of server instances you have running. Including reading a file from disk each time means we're adding an unnecessary load on a service that already has performance and resource usage issues. We've already added a new `/health/info` endpoint to each repo and we do DB connection checks elsewhere. So, we can reduce the work of our `/status` endpoint across all the repos to the bare minimum; returning a static `{ "status": "alive" }` response.
Jozzey
added
the
housekeeping
Cruikshanks
approved these changes
Aug 22, 2023
StuAA78
approved these changes
Aug 22, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://eaflood.atlassian.net/browse/WATER-4096
AWS ELBs require an endpoint they can hit to confirm whether an app is running. They are commonly referred to as health checks and are used to determine whether the ELB should route traffic through to an app instance. In our apps, it is the
/statusendpoint.The endpoint in all our repos currently reads in the
package.jsonfile to get the app's version number. This information is then used to support the/service-statuspage in the water-abstraction-ui. Some of the repos also include a test query to the DB to confirm it can connect.Having checks that confirm you can connect to dependent services (databases, other apps etc) is a good thing. But the ELB health checks are made multiple times a second across all instances. They only care whether an app is up or not. So if, for example, you include querying your DB in
/statusyou're hitting your DB with multiple connections per second, multiplied by the number of server instances you have running.Including reading a file from disk each time means we're adding an unnecessary load on a service that already has performance and resource usage issues.
We've already added a new
/health/infoendpoint to each repo and we do DB connection checks elsewhere. So, we can reduce the work of our/statusendpoint across all the repos to the bare minimum; returning a static{ "status": "alive" }response.This issue was originally raised in DEFRA/water-abstraction-team#67