Add Plain HTTP Health Check Endpoint

[krapie]

What would you like to be added:

Currently, our system only has the ConnectRPC health check endpoint grpc.health.v1.Health/Check, which requires an HTTP POST request with an application/json header and an empty body. This type of health checking is not convenient for common uptime checkers, especially free 3rd-party uptime checkers.

To address this limitation, we should implement a simple Plain HTTP health check endpoint that can be accessed with an HTTP HEAD request for easier and more versatile health checking.

Why is this needed:

The current health check method is not user-friendly for common uptime checkers. Introducing a Plain HTTP health check endpoint will make it easier for users to monitor the health status of our system.

[krapie]

We need to add to also support NCP ALB. @hackerwins
If we don't provide plain http health check endpoint, NCP ALB will exclude target from the load balancing target group.

실패 임계값: 정상 상태의 Target이 실패하면 비정상 상태로 전환되어 부하 분산 Target에서 제외되는 횟수

Reference: https://guide.ncloud-docs.com/docs/loadbalancer-targetgroup-vpc#2-health-check-%EC%84%A4%EC%A0%95

[taeng0204]

Hello:) Could I work on this issue?

[devleejb]

@taeng0204
Of course. If you have any questions, feel free to ask.

[krapie]

@taeng0204 If you want more context about this issue, please tell me.

[taeng0204]

@krapie Are there any specific requirements or caveats to consider when setting up health checks in the Yorkie system?

[krapie]

@taeng0204 All we need to do is to implement HEAD or GET HTTP health check endpoint, but we want to minimize the change to implement this. Current ConnectRPC's health check endpoint requires POST method with body, but if we can tweak or change the behavior with something like interceptors, it will be great.

For more context, follow: https://bufbuild.slack.com/archives/CRZ680FUH/p1710158028178999

[taeng0204]

@krapie Thanks for the answer, but I thought that link was to the slack comment and it seems to have expired.

[krapie]

@taeng0204 Can you check it again?

[taeng0204]

@krapie Sorry, I tried a few times, but when I click on that link it says I can't see chats before April 17, 2024.
No chats are specifically focused on either.

https://bufbuild.slack.com/archives/CRZ680FUH/p1713373023394579
The chats on this link are the oldest chats I can see.

Can you give me the keywords for those chats? Then I'll do a search.

[krapie]

@taeng0204 Below is the screenshot of the thread.

[krapie]

@taeng0204 Any progress on this issue?

[taeng0204]

@krapie
I'm having trouble resolving this issue.

There seem to be two ways to solve this issue.
The first, which I think is the best, is to support the GET method in connectrpc/grpchealth-go itself.
If you check the documentation below, you will see that the GET method is available in the connect protocol.

• https://connectrpc.com/docs/protocol/

To do this, we need to make a setting in the proto file like this

• https://buf.build/blog/introducing-connect-cacheable-rpcs

Here's an example from connectrpc/grpchealth-go

• https://github.com/connectrpc/grpchealth-go/blob/main/internal/proto/connectext/grpc/health/v1/health.proto

// before
service Health {
  rpc Check(HealthCheckRequest) returns (HealthCheckResponse);
	...
}

// after
service Health {
  rpc Check(HealthCheckRequest) returns (HealthCheckResponse){
	  option idempotency_level = NO_SIDE_EFFECTS;
  }
	...
}

However, when I reached out to the Buf team via slack, I received the following response.

• https://bufbuild.slack.com/archives/CRZ680FUH/p1721810222059439

Do you have a good idea to convince the Buf team?
If not, I'd go with the second method, which is to implement a separate HTTP handler.

[krapie]

@taeng0204 I think it makes sense that gRPC don't have to consider about the HTTP method, because there is no "HTTP Method" concept in gRPC. And it seems like the Buf team is strictly following gRPC proto spec for the gRPC compatibility.

Let's discuss about this in the following weekly-sync session.