-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add healthcheck endpoint #177
Conversation
kmakiela
commented
Jun 22, 2020
•
edited
Loading
edited
- Added healthcheck controller
- Added tests
- Created documentation for this endpoint
- Updated Sparrow
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR, looks good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for implementing the health check. I have 2 points to discuss:
- Documentation of the
/healthcheck
. I think it's important to say about the endpoint and explain that it's not recommended to do it frequently due to extra work added to the worker processes. - Is it possible, does it make sense to add spec of this endpoint to our OpenAPI spec?
- Open question. Is status 200 a good fit for a situation when all connections are dead? Software like load balancers decides if a service is a health based on the HTTP status code.
test/unit/healthcheck_test.exs
Outdated
end | ||
|
||
test "Successful connection to services" do | ||
{_, _, body} = API.get("/healthcheck") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it'd worth to check the status of the response as well. If I understand it correctly this is 200
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
3. Open question. Is status 200 a good fit for a situation when all connections are dead? Software like load balancers decides if a service is a health based on the HTTP status code.
I agree, I put 503 status response in that case. However, I'm not completely sure if this "service unavailable" would be about APNS and FCM or the MPush itself
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this can be used as a guideline: https://tools.ietf.org/id/draft-inadarei-api-health-check-01.html :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
9577b3b
to
de603a3
Compare
* Added healthcheck controller * Added tests * Created documentation for this endpoint * Updated Sparrow dependency
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just an article check and some small questions 🙂
Co-authored-by: Nelson Vides <nelson.vides@erlang-solutions.com>
README.md
Outdated
"connection_status": | ||
[ | ||
"connected", | ||
"connected" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if I get 100 workers does it mean that this list is 100 "connected" strings?
How about:
"connection_status": {
"connected": 2,
"disconnected": 0
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At first I thought we wanted to possibly give more information about the workers but since we stick with the connection status only I agree it's cleaner that way. However, the whole response is going to be restructured to match the draft RFC mentioned earlier
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making the response compatible with the proposed RFC and adding documentation. I had few additional, minor comments. Other than that it looks good.
case is_everything_disconnected do | ||
true -> | ||
503 | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this empty line is redundant and make the code less readable.
case pool_info[:connection_status][:connected] do | ||
0 -> | ||
true | ||
|
||
_ -> | ||
false | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about just this:
case pool_info[:connection_status][:connected] do | |
0 -> | |
true | |
_ -> | |
false | |
end | |
not (pool_info[:connection_status][:connected] > 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or could it be even pool_info[:connection_status][:connected] == 0
?
case status do | ||
503 -> | ||
"fail" | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
case is_pool_disconnected?(pool_info) do | ||
true -> | ||
"fail" | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These additional lines are all added and required by |
Yeah, often |
|
||
connections = | ||
stats | ||
|> Enum.map(&extract_connection_info_from_pool/1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The coding style remark is that it is considered a bad practise to use pipe only once. Please follow the style guide in future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, there were more pipes earlier that got removed
|
||
{_workers, connection_status} = | ||
workers | ||
|> Enum.map_reduce(%{connected: 0, disconnected: 0}, fn worker_info, acc -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And here as well :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent 😄