Node.js: Adding health check endpoints for a Kubernetes environment

[pacostas]

Summary

This PR adds the /actuator/health health check endpoint on the Node.js applications.

• This route is necessary in a Kubernetes environment to determine whether an application's status is healthy or not.
• This route exists on java applications, by adding them to the Node.js applications, we keep consistency across the samples.

This PR adds also a logging function for the Node.js apps to log any incoming requests, which is helpful to know whether the request has been received by the server.

Use Cases

Checklist

• I have viewed, signed, and submitted the Contributor License Agreement.
• I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
• I have added an integration test, if necessary.
• I have reviewed the styleguide for guidance on my code quality.
• I'm happy with the commit history on this PR (I have rebased/squashed as needed).

[dmikusa]

I'm curious why you need these specific paths exposed in the samples. Can you expand on that?

The samples already have health endpoints. They're also pretty simple so liveness/readiness are really the same thing. Adding more paths and options makes the sample apps more complicated. Just trying to weigh the pros/cons here. Thanks

[mhdawson]

Just wondering how you chose those endpoints. I was looking at https://nodeshift.dev/nodejs-reference-architecture/operations/healthchecks/#endpoints and from that we might use /readyz and /livez

[mhdawson]

I guess maybe it is to match the Java examples?

[pacostas]

Yes, to match the routes from the java example

[pacostas]

I'm curious why you need these specific paths exposed in the samples. Can you expand on that?

The samples already have health endpoints. They're also pretty simple so liveness/readiness are really the same thing. Adding more paths and options makes the sample apps more complicated. Just trying to weigh the pros/cons here. Thanks

The node.js examples do not have a readiness or a liveness endpoints.

[dmikusa]

I'm curious why you need these specific paths exposed in the samples. Can you expand on that?
The samples already have health endpoints. They're also pretty simple so liveness/readiness are really the same thing. Adding more paths and options makes the sample apps more complicated. Just trying to weigh the pros/cons here. Thanks

The node.js examples do not have a readiness or a liveness endpoints.

That's unnecessary though.

As it says in the K8s docs...

The kubernetes endpoints exposed by the application have to agree with the probe configuration:

So you could configure your probes like:

readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 3000
livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 3000

or you could just point them to the same place, all that matters is that you point them to an actual endpoint in the application. Since the sample apps don't treat liveness/readiness different, because of their simplicity, I'm not sure I see why we should introduce additional endpoints.

readinessProbe:
  httpGet:
    path: /actuator/health
    port: 3000
livenessProbe:
  httpGet:
    path: /actuator/health
    port: 3000

If you would like to put example configurations for K8s into the READMEs that would be great. Showing people how to configure K8s for the samples would be awesome, but I don't personally see a need for adding additional endpoints to the apps.

[mhdawson]

At one point I thought that some of the examples (the Java ones) already had health endpoints but that turns out not to be the case.

In that context I don't have a strong feeling one way or the other in terms of adding them. It could make it easier/better to use the samples in the context of deployment to Kubernetes environments, but its pretty easy to copy the examples when that is needed.

[mhdawson]

I will add though, that if we do want to show configuring the endpoints then I don't think we should be pointing them to the app endpoint and we'd want to use different endpoints for readiness and liveness.

[pacostas]

I see/agree @dmikusa, doesn't make sense to add more routes to the Java example than is unnecessary once you can configure it at a Kubernetes level and also breaks the consistency across the rest of the Java examples

For the node apps it would be nice to have a /health or /actuator/health (to match the java pattern) endpoint rather than the / endpoint which is meant to serve content. Of course is not going to be something more than a hardcoded {status: "UP} response, but we don't have something to actually check (e.g. a database) so I think it makes sense in that context.

+1 for adding the kubernetes configuration to the docs.

Thank you for your feedback :)

[dmikusa]

For the node apps it would be nice to have a /health or /actuator/health (to match the java pattern) endpoint rather than the / endpoint which is meant to serve content. Of course is not going to be something more than a hardcoded {status: "UP} response, but we don't have something to actually check (e.g. a database) so I think it makes sense in that context.

That sounds good to me. Making the samples more consistent across languages is 👍

[mhdawson]

Adding the single endpoint to the Node.js one to be consistent with the Java example sounds good to me.

[mhdawson]

LGTM

[pacostas]

@dmikusa It has three approvals, should we merge it?