Allow forwarding healthz/ to a different backend port

[ashi009]

For gRPC implementation in go, serving both HTTP and gRPC on the same port is still problematic, so a production service is unlikely to serve monitoring endpoints (healthz/, metricz/ and those *z/ ones) on the grpc port.

So I think it's a good idea to allow healthz/ to be forwarded to a different port other than the grpc port.

[lizan]

It is possible to do this with custom nginx.conf by adding something like this:

location /healthz {
  proxy_pass http://<point to another endpoint>;
}

before the regular grpc_pass directive. I haven't got chance to try but it should work.

[ashi009]

Yep, I know this would work but would love to have this out-of-the-box.

[lizan]

I see. We already have kind of support in nginx.conf template to let ESP return a hardcoded 200 here, feel free to open an PR to endpoints-tools to make it generates proxy_pass directive.

[ashi009]

Speaking of that, I found that providing a healthz/ handler with consistent 200 response is just misleading and for that case it should be called nullz/ instead.

[qiwzhang]

@ashi009 agreed that the new health port forwarding to the backend should be called healthz. But to be backward compatible (not to break existing customers), we may have to keep the current name. We have to come up a new name for the new port.

[qiwzhang]

revisit this issue. Not sure if it is still required.

Since backend is grpc, forward a healhz call to another http endpoint may not work. it is not really the health of the grpc backend unless the http endpoints monitors the grpc server.

So not sure if suggested solution will help

[ashi009]

Good point. Given that the grpc has standardized the health check service already, it should be possible to let esp provide healthz endpoint with data from there. It will allow http LB to probe the actual backend , also true for kubenetes liveness probe. So I'd probably suggest to add a flag to proxy healthz to grpc health service. Wayne Zhang <notifications@github.com>于2019年4月27日 周六上午3:16写道：

revisit this issue. Not sure if it is still required. Since backend is grpc, forward a healhz call to another http endpoint may not work. it is not really the health of the grpc backend unless the http endpoints monitors the grpc server. So not sure if suggested solution will help — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#404 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFH2B7DGWWKK33LLXEOYOTPSNIHBANCNFSM4FFM3H6Q> .

-- Sent from Gmail Mobile

[qiwzhang]

In this case, users just need to expose the grpc health check service in the service config, ESP will happily pass the call from LB to the grpc service. ESP doesn't need to do anything special.

[ashi009]

Um, is it possible to map health service to plain HTTP 1.x GET? AFAIK, the health service proto <https://github.com/grpc/grpc/blob/master/src/proto/grpc/health/v1/health.proto> doesn't have api annotations yet. Also, I don't think people want to expose health endpoint in their API config as an unauthenticated endpoint. Wayne Zhang <notifications@github.com>于2019年4月27日 周六上午10:34写道：

…

In this case, users just need to expose the grpc health check service in the service config, ESP will happily pass the call from LB to the grpc service. ESP doesn't need to do anything special. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#404 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFH2BY2LBYBQYIWZUYX4UDPSO3UVANCNFSM4FFM3H6Q> .