It would be useful to have a library of commonly used health checks. In the scope of this issue, a health check should be implemented that checks if MySQL is alive (e.g. calling an sql.PingContext first and e.g. execute a query, such as 'SELECT 1 ' afterwards to see if MySQL is ready for query execution.
A few constraints to keep things clean and simple:
The check should be added to the checks module that you can find in the development branch.
As with all health check functions of this library, the check implementation should support accepting and forwarding context.Context that is being passed to each health check function.
If the health check requires external external modules or other dependencies, the check should be implemented as a separate Go module(similarly how it is done for the tests, that require dependencies to other packages as well). This is required to avoid that when people import the base library, they also need to import all dependencies of all provided checks.
The check should have a README.md in its root directory that describes how to use it and maybe what to look out for.
You should provide a test that checks at least the happy path. If a docker container is required to properly test the check, the docker container can be added to the docker-compose.yaml file in the checks base package.
Should you have questions or require help, please join our discord chat room.
It would be useful to have a small library of commonly used health checks. In the scope of this issue, a goroutine count check should be implemented (e.g. calling an count := runtime.NumGoroutine() and se if it is above a throeshold.
A few constraints to keep things clean and simple:
The check should be added to the checks module that you can find in the development branch.
As with all health check functions of this library, the check implementation should support accepting and forwarding context.Context that is being passed to each health check function.
If the health check requires external external modules or other dependencies, the check should be implemented as a separate Go module(similarly how it is done for the tests, that require dependencies to other packages as well). This is required to avoid that when people import the base library, they also need to import all dependencies of all provided checks.
The check should have a README.md in its root directory that describes how to use it and maybe what to look out for.
You should provide a test that checks at least the happy path. If a docker container is required to properly test the check, the docker container can be added to the docker-compose.yaml file in the checks base package.
Should you have questions or require help, please join our discord chat room.
It would be useful to have a small library of commonly used health checks. In the scope of this issue, a DNS resolver check should be implemented (e.g. using LookupHost method if net.Resolver). Optimally, the implementation should support timeouts from the context.Context value that is being passed to every health check function.
A few constraints to keep things clean and simple:
The check should be added to the checks module that you can find in the development branch.
As with all health check functions of this library, the check implementation should support accepting and forwarding context.Context that is being passed to each health check function.
If the health check requires external external modules or other dependencies, the check should be implemented as a separate Go module(similarly how it is done for the tests, that require dependencies to other packages as well). This is required to avoid that when people import the base library, they also need to import all dependencies of all provided checks.
The check should have a README.md in its root directory that describes how to use it and maybe what to look out for.
You should provide a test that checks at least the happy path. If a docker container is required to properly test the check, the docker container can be added to the docker-compose.yaml file in the checks base package.
Should you have questions or require help, please join our discord chat room.
It would be useful to have a library of commonly used health checks. In the scope of this issue, a health check should be implemented that checks if Elasticsearch is alive (e.g. calling an sql.PingContext first and e.g. execute a query, such as 'SELECT 1 ' afterwards to see if MySQL is ready for query execution.
A few constraints to keep things clean and simple:
The check should be added to the checks module that you can find in the development branch.
As with all health check functions of this library, the check implementation should support accepting and forwarding context.Context that is being passed to each health check function.
If the health check requires external external modules or other dependencies, the check should be implemented as a separate Go module(similarly how it is done for the tests, that require dependencies to other packages as well). This is required to avoid that when people import the base library, they also need to import all dependencies of all provided checks.
The check should have a README.md in its root directory that describes how to use it and maybe what to look out for.
You should provide a test that checks at least the happy path. If a docker container is required to properly test the check, the docker container can be added to the docker-compose.yaml file in the checks base package.
Should you have questions or require help, please join our discord chat room.
It would be useful to have a small library of commonly used health checks. In the scope of this issue, a garbage collection max pause check should be implemented (e.g. calling runtime.ReadMemStats and see if the PauseNs returns a value that is above a certain threshold.
A few constraints to keep things clean and simple:
The check should be added to the checks module that you can find in the development branch.
As with all health check functions of this library, the check implementation should support accepting and forwarding context.Context that is being passed to each health check function.
If the health check requires external external modules or other dependencies, the check should be implemented as a separate Go module(similarly how it is done for the tests, that require dependencies to other packages as well). This is required to avoid that when people import the base library, they also need to import all dependencies of all provided checks.
The check should have a README.md in its root directory that describes how to use it and maybe what to look out for.
You should provide a test that checks at least the happy path. If a docker container is required to properly test the check, the docker container can be added to the docker-compose.yaml file in the checks base package.
Should you have questions or require help, please join our discord chat room.
It would be useful to have a library of commonly used health checks. In the scope of this issue, a health check should be implemented that checks if a GRPC endpoint is reachable, e.g. by using a HealthClient instance from google.golang.org/grpc/health/grpc_health_v1 to retrieve its status and see if it is "serving" (I.e. HealthCheckResponse_SERVING).
A few constraints to keep things clean and simple:
The check should be added to the checks module that you can find in the development branch.
As with all health check functions of this library, the check implementation should support accepting and forwarding context.Context that is being passed to each health check function.
If the health check requires external external modules or other dependencies, the check should be implemented as a separate Go module(similarly how it is done for the tests, that require dependencies to other packages as well). This is required to avoid that when people import the base library, they also need to import all dependencies of all provided checks.
The check should have a README.md in its root directory that describes how to use it and maybe what to look out for.
You should provide a test that checks at least the happy path. If a docker container is required to properly test the check, the docker container can be added to the docker-compose.yaml file in the checks base package.
Should you have questions or require help, please join our discord chat room.
It would be useful to have a small library of commonly used health checks. In the scope of this issue, a TCP check should be implemented (e.g. calling net.DialTimeout("tcp", addr, timeout) and return it's result). Optimally, the implementation should respect the context.Context value that is being passed to each health check function (e.g., by using the Deadline from the context to pass it as a parameter to net.DialTimeout (or pass the entire context if there is a way to do that).
A few constraints to keep things clean and simple:
The check should be added to the checks module that you can find in the development branch.
As with all health check functions of this library, the check implementation should support accepting and forwarding context.Context that is being passed to each health check function.
If the health check requires external external modules or other dependencies, the check should be implemented as a separate Go module(similarly how it is done for the tests, that require dependencies to other packages as well). This is required to avoid that when people import the base library, they also need to import all dependencies of all provided checks.
The check should have a README.md in its root directory that describes how to use it and maybe what to look out for.
You should provide a test that checks at least the happy path. If a docker container is required to properly test the check, the docker container can be added to the docker-compose.yaml file in the checks base package.
Should you have questions or require help, please join our discord chat room.
It would be useful to have a library of commonly used health checks. In the scope of this issue, a health check should be implemented that checks if Memcached is alive (e.g. by pinging Memcached and see if the ping result is successful).
A few constraints to keep things clean and simple:
The check should be added to the checks module that you can find in the development branch.
As with all health check functions of this library, the check implementation should support accepting and forwarding context.Context that is being passed to each health check function.
If the health check requires external external modules or other dependencies, the check should be implemented as a separate Go module(similarly how it is done for the tests, that require dependencies to other packages as well). This is required to avoid that when people import the base library, they also need to import all dependencies of all provided checks.
The check should have a README.md in its root directory that describes how to use it and maybe what to look out for.
You should provide a test that checks at least the happy path. If a docker container is required to properly test the check, the docker container can be added to the docker-compose.yaml file in the checks base package.
Should you have questions or require help, please join our discord chat room.
It would be useful to have a library of commonly used health checks. In the scope of this issue, a health check should be implemented that checks the hosts disk space is above a preconfigured threshold (e.g. bny using syscall.Statfs and using the total and free disk blocks to see if the threshold constraints are met)
A few constraints to keep things clean and simple:
The check should be added to the checks module that you can find in the development branch.
As with all health check functions of this library, the check implementation should support accepting and forwarding context.Context that is being passed to each health check function.
If the health check requires external external modules or other dependencies, the check should be implemented as a separate Go module(similarly how it is done for the tests, that require dependencies to other packages as well). This is required to avoid that when people import the base library, they also need to import all dependencies of all provided checks.
The check should have a README.md in its root directory that describes how to use it and maybe what to look out for.
You should provide a test that checks at least the happy path. If a docker container is required to properly test the check, the docker container can be added to the docker-compose.yaml file in the checks base package.
Should you have questions or require help, please join our discord chat room.
It would be useful to have a library of commonly used health checks. In the scope of this issue, a health check should be implemented that checks if Mongo DB is alive (e.g. by pinging Mongo DB and see if the ping result is successful).
A few constraints to keep things clean and simple:
The check should be added to the checks module that you can find in the development branch.
As with all health check functions of this library, the check implementation should support accepting and forwarding context.Context that is being passed to each health check function.
If the health check requires external external modules or other dependencies, the check should be implemented as a separate Go module(similarly how it is done for the tests, that require dependencies to other packages as well). This is required to avoid that when people import the base library, they also need to import all dependencies of all provided checks.
The check should have a README.md in its root directory that describes how to use it and maybe what to look out for.
You should provide a test that checks at least the happy path. If a docker container is required to properly test the check, the docker container can be added to the docker-compose.yaml file in the checks base package.
Should you have questions or require help, please join our discord chat room.
This doesn't happen with unit tests, maybe there is a difference when using httptest?
With a real handler I get the response with a text/plain Content-Type. I guess this is because the status is emitted before the Content-Type (ultimately set here).
When a user created health check function panics, this health check library currently does not provide a means to recover from it automatically and continue. Instead, the application terminates. This behaviour is most likely is not wanted. Therefore, this library should provide a way to recover from panics right after the check function call (e.g.: here). The user should
be able to able to opt out of this by configuration (e.g. by disabling it with a configuration option) and
instead of panicking, the library should instead return an error.
It would be useful to have a library of commonly used health checks. In the scope of this issue, a health check should be implemented that checks if a Kafka procuder is alive. Strategies on how to do this can be discussed here prior to implementation.
A few constraints to keep things clean and simple:
The check should be added to the checks module that you can find in the development branch.
As with all health check functions of this library, the check implementation should support accepting and forwarding context.Context that is being passed to each health check function.
If the health check requires external external modules or other dependencies, the check should be implemented as a separate Go module(similarly how it is done for the tests, that require dependencies to other packages as well). This is required to avoid that when people import the base library, they also need to import all dependencies of all provided checks.
The check should have a README.md in its root directory that describes how to use it and maybe what to look out for.
You should provide a test that checks at least the happy path. If a docker container is required to properly test the check, the docker container can be added to the docker-compose.yaml file in the checks base package.
Should you have questions or require help, please join our discord chat room.
It would be useful to have a library of commonly used health checks. In the scope of this issue, a health check should be implemented that checks if a mail server (IMAP) is alive and can be used to receive/read emails, e.g. by using Golangs https://pkg.go.dev/net/smtp package.
A few constraints to keep things clean and simple:
The check should be added to the checks module that you can find in the development branch.
As with all health check functions of this library, the check implementation should support accepting and forwarding context.Context that is being passed to each health check function.
If the health check requires external external modules or other dependencies, the check should be implemented as a separate Go module(similarly how it is done for the tests, that require dependencies to other packages as well). This is required to avoid that when people import the base library, they also need to import all dependencies of all provided checks.
The check should have a README.md in its root directory that describes how to use it and maybe what to look out for.
You should provide a test that checks at least the happy path. If a docker container is required to properly test the check, the docker container can be added to the docker-compose.yaml file in the checks base package.
Should you have questions or require help, please join our discord chat room.
It should be possible to expose health checks as a prometheus gauge.
A few constraints to keep things clean and simple:
The check should be added to the checks module that you can find in the development branch.
As with all health check functions of this library, the check implementation should support accepting and forwarding context.Context that is being passed to each health check function.
If the health check requires external external modules or other dependencies, the check should be implemented as a separate Go module(similarly how it is done for the tests, that require dependencies to other packages as well). This is required to avoid that when people import the base library, they also need to import all dependencies of all provided checks.
The check should have a README.md in its root directory that describes how to use it and maybe what to look out for.
You should provide a test that checks at least the happy path. If a docker container is required to properly test the check, the docker container can be added to the docker-compose.yaml file in the checks base package.
Should you have questions or require help, please join our discord chat room.
It would be useful to have a library of commonly used health checks. In the scope of this issue, a health check should be implemented that checks if a mail server (SMTP) is alive and can be used to send emails, e.g. by using Golangs https://pkg.go.dev/net/smtp package.
A few constraints to keep things clean and simple:
The check should be added to the checks module that you can find in the development branch.
As with all health check functions of this library, the check implementation should support accepting and forwarding context.Context that is being passed to each health check function.
If the health check requires external external modules or other dependencies, the check should be implemented as a separate Go module(similarly how it is done for the tests, that require dependencies to other packages as well). This is required to avoid that when people import the base library, they also need to import all dependencies of all provided checks.
The check should have a README.md in its root directory that describes how to use it and maybe what to look out for.
You should provide a test that checks at least the happy path. If a docker container is required to properly test the check, the docker container can be added to the docker-compose.yaml file in the checks base package.
Should you have questions or require help, please join our discord chat room.
It would be useful to have a library of commonly used health checks. In the scope of this issue, a health check should be implemented that checks if Redis is alive (e.g. by pinging Redis and see if the ping result is successful).
A few constraints to keep things clean and simple:
The check should be added to the checks module that you can find in the development branch.
As with all health check functions of this library, the check implementation should support accepting and forwarding context.Context that is being passed to each health check function.
If the health check requires external external modules or other dependencies, the check should be implemented as a separate Go module(similarly how it is done for the tests, that require dependencies to other packages as well). This is required to avoid that when people import the base library, they also need to import all dependencies of all provided checks.
The check should have a README.md in its root directory that describes how to use it and maybe what to look out for.
You should provide a test that checks at least the happy path. If a docker container is required to properly test the check, the docker container can be added to the docker-compose.yaml file in the checks base package.
Should you have questions or require help, please join our discord chat room.
It would be useful to have a library of commonly used health checks. In the scope of this issue, a health check should be implemented that checks if Postgres is alive (e.g. calling an sql.PingContext first and do a 'SELECT VERSION()' afterwards to see if Postgres is ready for query execution.
A few constraints to keep things clean and simple:
As with all health check functions of this library, the check implementation should support accepting and forwarding context.Context that is being passed to each health check function.
If the health check requires external external modules or other dependencies, the check should be implemented as a separate Go module(similarly how it is done for the tests, that require dependencies to other packages as well). This is required to avoid that when people import the base library, they also need to import all dependencies of all provided checks.
The check should have a README.md in its root directory that describes how to use it and maybe what to look out for.
You should provide a test that checks at least the happy path. If a docker container is required to properly test the check, the docker container can be added to the docker-compose.yaml file in the checks base package.
It would be useful to have a library of commonly used health checks. In the scope of this issue, a health check should be implemented that checks if a Kafka consumer is alive. Strategies on how to do this can be discussed here prior to implementation.
A few constraints to keep things clean and simple:
The check should be added to the checks module that you can find in the development branch.
As with all health check functions of this library, the check implementation should support accepting and forwarding context.Context that is being passed to each health check function.
If the health check requires external external modules or other dependencies, the check should be implemented as a separate Go module(similarly how it is done for the tests, that require dependencies to other packages as well). This is required to avoid that when people import the base library, they also need to import all dependencies of all provided checks.
The check should have a README.md in its root directory that describes how to use it and maybe what to look out for.
You should provide a test that checks at least the happy path. If a docker container is required to properly test the check, the docker container can be added to the docker-compose.yaml file in the checks base package.
Should you have questions or require help, please join our discord chat room.
It would be useful to have a small library of commonly used health checks. In the scope of this issue, an HTTP check should be implemented (e.g. calling an http.Client HTTP method and return it's result). Optimally, the implementation should respect the context.Context value that is being passed to each health check function (e.g., by using the Deadline from the context to pass it as a paramter of http.Client (or pass the entire context if there is a way to do that).
A few constraints to keep things clean and simple:
The check should be added to the checks module that you can find in the development branch.
As with all health check functions of this library, the check implementation should support accepting and forwarding context.Context that is being passed to each health check function.
If the health check requires external external modules or other dependencies, the check should be implemented as a separate Go module(similarly how it is done for the tests, that require dependencies to other packages as well). This is required to avoid that when people import the base library, they also need to import all dependencies of all provided checks.
The check should have a README.md in its root directory that describes how to use it and maybe what to look out for.
You should provide a test that checks at least the happy path. If a docker container is required to properly test the check, the docker container can be added to the docker-compose.yaml file in the checks base package.
Should you have questions or require help, please join our discord chat room.
Currently, the Checker interface exposes a method Check(ctx context.Context) CheckerResult which runs all synchronous health checks. It should be possible to add a new method CheckByName(ctx context.Context, name string) (CheckResult, CheckerResult) which allows execution of a single synchronous check by name.