zeekayandHanzo Dev
f993831e33
Six packages would not build, each from a migration that stopped one step short, and a package that does not compile reports nothing at all. The generated mocks had fallen behind their interfaces: Manager kept four of its eight methods, Server was missing SetRootInfoProvider, and there was no Factory mock under the name the tests used. All three are regenerated, and each package now carries the go:generate line that produces them, so a method added to an interface is a regeneration away rather than a puzzle in another package's tests. The interfaces had also taken a context that the expectations had not, so forty-six of them name it now. Aliases and the level test followed their types: the standalone atomic package rather than the compatibility re-export, and log's own Level constants beside the field that holds one. One table field was renamed in every place but the line that read it. Two services lost a behaviour along the way. Registration aliases every VM to its own id, and both GetVMs and LoadVMs handed that back as an alias of itself, which the tests had said all along they should not; and both read their context from a request the tests passed as nil, which segfaulted before a single expectation could run. chains/atomic still fails, deliberately: its fixture asserts a big-endian wire layout "so any on-disk record from the legacy build still parses", and luxfi/util's packer moved to little-endian on purpose. Which side gives is a question about records already on disk, not about this test. Co-authored-by: Hanzo Dev <[email protected]>
Health Checking
Health Check Types
Readiness
Readiness is a special type of health check. Readiness checks will only run until they pass for the first time. After a readiness check passes, it will never be run again. These checks are typically used to indicate that the startup of a component has finished.
Health
Health checks typically indicate that a component is operating as expected. The health of a component may flip due to any arbitrary heuristic the component exposes.
Liveness
Liveness checks are intended to indicate that a component has become unhealthy and has no way to recover.
Naming and Tags
All registered checks must have a unique name which will be included in the health check results.
Additionally, checks can optionally specify an arbitrary number of tags which can be used to group health checks together.
Special Tags
- "All" is a tag that is automatically added for every check that is registered.
- "Application" checks are checks that are globally applicable. This means that it is not possible to filter application-wide health checks from a response.
Health Check Worker
Readiness, Health, and Liveness checks are all implemented by using their own health check worker.
A health check worker starts a goroutine that updates the health of all registered checks every freq. By default freq is set to 30s.
When a health check is added it will always initially report as unhealthy.
Every health check runs in its own goroutine to maximize concurrency. It is guaranteed that no locks from the health checker are held during the execution of the health check.
When the health check worker is stopped, it will finish executing any currently running health checks and then terminate its primary goroutine. After the health check worker is stopped, the health checks will never run again.