Need GET health check endpoint for deployment status

[robdoesstuff]

Running Parity 1.11.8

There is no documented health check which we can use for checking for service presence. Most services have a static GET /health, /status or /ping which returns either the current time as JSON or a static up:true or something that load balancers and monitoring systems can use to determine the service is running.

We have been trying to use the peer count endpoint to determine if it's up but that endpoint is unreliable, often timing out after several seconds and leading to false service outage errors for us.

[Tbaut]

The /api/health has been removed. We advise to use:

• eth_syncing for sync state
• parity_netPeers for network state

If you have problems with one of those, then please open an issue as it is expected to work reliably.

[robdoesstuff]

We were previously using net_peerCount but it's unreliable and times out often. I filed an issue for it last year (#8141) but it was ignored and the problem is not fixed. We still have timeouts with that call, and upon inspection of the underlying code in the service, it appears to do some major digging and possibly wait on locks, so it's not the kind of endpoint you'd want to use for a fast availability check.

Also the convention most load balancers use is just a simple GET. Setting up a POST with data is sometimes hard in some environments and with some services, and I'm seeing solutions being used where people are adding GET /health sidecars to their docker containers which do the health check.

I agree that fixing the peer count endpoint is a separate topic, but as it stands today, it's not a suitable replacement and is not the normal convention used for service up checks.

[Tbaut]

I filed an issue for it last year (#8141) but it was ignored and the problem is not fixed

If I read this correctly, it got anything but ignored.. questions were asked and not answered 🙄

so it's not the kind of endpoint you'd want to use for a fast availability check.

Also the convention most load balancers use is just a simple GET.

Agreed, we can discuss it here.

[debris]

@tomusdrw what is the status of it? Is parity-ethereum master already exposing it? :)

[tomusdrw]

Merged here: paritytech/jsonrpc#301 jsonrpc bump and implementation on Parity Ethereum side needed.

[prettymuchbryce]

@tomusdrw Thank you for addressing.

How will we take advantage of this when it is merged?

Previously we were hitting :8545/api/health. Will this still be the same?

[tomusdrw]

@prettymuchbryce yes, although the response will be a different JSON (definitely no time info).

[stephgosling]

Can I just say that with Constantinople happening on the 25th of October this is actually quite a big deal for folks who don't have a proxy service in place to monitor this health :/

[levino]

What is the status on this?

[tomusdrw]

@levino PR pending: #9847