A simple and flexible health check library for Go.

Overview

Health

A simple and flexible health check library for Go.

Build codecov Go Report Card GolangCI FOSSA Status

Documentation · Report Bug · Request Feature

Table of Contents

  1. Getting started
  2. Synchronous vs. Asynchronous Checks
  3. Caching
  4. Listening to Status Changes
  5. Middleware and Interceptors
  6. Compatibility With Other Libraries
  7. License

Getting Started

This library provides a http.Handler that acts as a health endpoint. It can be used by cloud infrastructure or other services to determine the availability of an application.

Rather than simply returning a response with HTTP status code 200, this library allows building health checks that test the availability of all required dependencies. The HTTP response contains the aggregated health result and details about the health status of each component.

Example

package main

import (
	"context"
	"database/sql"
	"fmt"
	"github.com/alexliesenfeld/health"
	_ "github.com/mattn/go-sqlite3"
	"log"
	"net/http"
	"time"
)

// This is a very simple example that shows the basic features of this library.
func main() {
	db, _ := sql.Open("sqlite3", "simple.sqlite")
	defer db.Close()

	// Create a new Checker.
	checker := health.NewChecker(

		// Set the time-to-live for our cache to 1 second (default).
		health.WithCacheDuration(1*time.Second),

		// Configure a global timeout that will be applied to all checks.
		health.WithTimeout(10*time.Second),

		// A check configuration to see if our database connection is up.
		// The check function will be executed for each HTTP request.
		health.WithCheck(health.Check{
			Name:    "database",      // A unique check name.
			Timeout: 2 * time.Second, // A check specific timeout.
			Check:   db.PingContext,
		}),

		// The following check will be executed periodically every 15 seconds
		// started with an initial delay of 3 seconds. The check function will NOT
		// be executed for each HTTP request.
		health.WithPeriodicCheck(15*time.Second, 3*time.Second, health.Check{
			Name: "search",
			// The check function checks the health of a component. If an error is
			// returned, the component is considered unavailable (or "down").
			// The context contains a deadline according to the configured timeouts.
			Check: func(ctx context.Context) error {
				return fmt.Errorf("this makes the check fail")
			},
		}),

		// Set a status listener that will be invoked when the health status changes.
		// More powerful hooks are also available (see docs).
		health.WithStatusListener(func(ctx context.Context, state health.CheckerState) {
			log.Println(fmt.Sprintf("health status changed to %s", state.Status))
		}),
	)

	// Create a new health check http.Handler that returns the health status
	// serialized as a JSON string. You can pass pass further configuration
	// options to NewHandler to modify default configuration.
	http.Handle("/health", health.NewHandler(checker))
	log.Fatalln(http.ListenAndServe(":3000", nil))
}

Because our search component is down, the request curl -u username:password http://localhost:3000/health would yield a response with HTTP status code 503 (Service Unavailable), and the following JSON response body:

{
  "status": "down",
  "details": {
    "database": {
      "status": "up",
      "timestamp": "2021-07-01T08:05:14.603364Z"
    },
    "search": {
      "status": "down",
      "timestamp": "2021-07-01T08:05:08.522685Z",
      "error": "this makes the check fail"
    }
  }
}

This example shows all features of this library.

Synchronous vs. Asynchronous Checks

With "synchronous" health checks we mean that every HTTP request initiates a health check and waits until all check functions complete before returning an aggregated health result. You can configure synchronous checks using the WithCheck configuration option (see example above).

Synchronous checks can be sufficient for smaller applications but might not scale well for more involved applications. Sometimes an application needs to read a large amount of data, can experience latency issues or make an expensive calculation to tell something about its health. With synchronous health checks the application will not be able to respond quickly to health check requests (see here why this is necessary to avoid service disruptions in modern cloud infrastructure).

Rather than executing health check functions on every HTTP request, periodic (or "asynchronous") health checks execute the check function on a fixed schedule. With this approach, the health status is always read from a local cache that is regularly updated in the background. This allows responding to HTTP requests instantly without waiting for check functions to complete.

Periodic checks can be configured using the WithPeriodicCheck configuration option (see example above).

This library allows you to mix synchronous and asynchronous check functions, so you can start out simple and easily transition into a more scalable and robust health check implementation later.

Caching

Health check responses are cached to avoid sending too many request to the services that your program checks and to mitigate "denial of service" attacks. The TTL is set to 1 second by default. If you do not want to use caching altogether, you can disable it using the health.WithDisabledCache() configuration option.

Listening to Status Changes

It can be useful to react to health status changes. For example, you might want to log status changes, so you can easier correlate logs during root cause analysis or perform actions to mitigate the impact of an unhealthy component.

This library allows you to configure listener functions that will be called when either the overall/aggregated health status changes, or that of a specific component.

Example

health.WithPeriodicCheck(5*time.Second, 0, health.Check{
    Name:   "search",
    Check:  myCheckFunc,
    StatusListener: func (ctx context.Context, name string, state CheckState) ) {
	    log.Printf("status of component '%s' changed to %s", name, state.Status)
    },
}),

health.WithStatusListener(func (ctx context.Context, state CheckerState)) {
    log.Printf("overall system health status changed to %s", state.Status)
}),

Middleware and Interceptors

It can be useful to hook into the checking lifecycle to do some processing before and after a health check. For example, you might want to add some tracing information to the Context before the check function executes, do some logging or modify the check result before sending the HTTP response (e.g., removing details on failed authentication).

This library provides two mechanisms that allow you to hook into processing:

  • Middleware gives you the possibility to intercept all calls of Checker.Check, which corresponds to every incoming HTTP request. In contrary to the usually used middleware pattern, this middleware allows you to access check related information and post-process a check result before sending it in an HTTP response.

    Middleware Description
    BasicAuth Reduces exposed health details based on authentication success. Uses basic auth for authentication.
    CustomAuth Same as BasicAuth middleware, but allows using an arbitrary function for authentication.
    FullDetailsOnQueryParam Disables health details unless the request contains a previously configured query parameter name.
    BasicLogger Basic request-oriented logging functionality.
  • Interceptors make it possible to intercept all calls to a check function. This is useful if you have cross-functional code that needs to be reusable and should have access to check state information.

    Interceptor Description
    BasicLogger Basic component check function logging functionality

Compatibility With Other Libraries

Most existing Go health check libraries come with their own implementations of tool specific check functions (such as for Redis, memcached, Postgres, etc.). Rather than reinventing the wheel and come up with yet another library specific implementation of check functions, the goal was to design this library in a way that makes it easy to reuse existing solutions. The following (non-exhaustive) list of health check implementations should work with this library without or minimal adjustments:

  • github.com/hellofresh/health-go ( see full example here)
    import httpCheck "github.com/hellofresh/health-go/v4/checks/http"
    ...
    health.WithCheck(health.Check{
       Name:    "google",
       Check:   httpCheck.New(httpCheck.Config{
          URL: "https://www.google.com",
       }),
    }),
  • github.com/etherlabsio/healthcheck ( see full example here)
    import "github.com/etherlabsio/healthcheck/v2/checkers"
    ...
    health.WithCheck(health.Check{
      Name:    "database",
      Check:   checkers.DiskSpace("/var/log", 90).Check,
    })
  • github.com/heptiolabs/healthcheck ( see full example here)
    import "github.com/heptiolabs/healthcheck"
    ...
    health.WithCheck(health.Check{
        Name: "google",
        Check: func(ctx context.Context) error {
           deadline, _ := ctx.Deadline()
           timeout := time.Now().Sub(deadline)
           return healthcheck.HTTPGetCheck("https://www.google.com", timeout)()
        },
    }),
  • github.com/InVisionApp/go-health ( see full example here)
      import "github.com/InVisionApp/go-health/checkers"
      ...
      // Create check as usual (no error checking for brevity)
      googleURL, err := url.Parse("https://www.google.com")
      check, err := checkers.NewHTTP(&checkers.HTTPConfig{
          URL: googleURL,
      })
      ...
      // Add the check in the Checker configuration.
      health.WithCheck(health.Check{
          Name: "google",
          Check: func(_ context.Context) error {
              _, err := check.Status() 
              return err
          },
      })

License

health is free software: you can redistribute it and/or modify it under the terms of the MIT Public License.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the MIT Public License for more details.

FOSSA Status

Comments
  • How to differentiate output based on auth status?

    How to differentiate output based on auth status?

    Commit 739c4a012ae74f2a6b7b2c9efebc7dcee916116a removed WithCustomAuth and WithBasicAuth.

    What's the recommended way to obtain the same behaviour now?

    opened by panta 9
  • Fix startup `MaxContiguousFails` and add contiguous success Check options

    Fix startup `MaxContiguousFails` and add contiguous success Check options

    Currently, when Check.MaxContiguousFails is set to n the first n-1 checks will return StatusUp even if it and all prior checks were a failure. This is because evaluateCheckStatus only returns StatusDown if the number of consecutive failures is >= MaxContigiousFails. The result is that on startup the status may be reported as Up when it has never actually had a successful check. The fix for this is to also return StatusDown if there were no previous successes (check that LastSuccessAt is not nil).

    Additionally, this implements Check.MinContiguousSuccesses and Check.MinTimeInSuccess which function as the inverse of Check.MaxContiguousFails and Check.MaxTimeInError, respectively.

    • Checks must be successful for MinContiguousSuccesses consecutive checks before it's considered healthy.
    • Checks must be successful for MinTimeInSuccess duration before it's considered healthy.

    If either threshold is not satisfied then the most recent check.Status is returned; this is so that on startup StatusUnknown will continue to be returned until the threshold(s) are reached to avoid returning a misleading StatusDown.

    opened by jscaltreto 3
  • In actual response content type is text/plain even for (default) http.JSONResultWriter

    In actual response content type is text/plain even for (default) http.JSONResultWriter

    opened by panta 2
  • Add Postgres check

    Add Postgres check

    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.
    enhancement 
    opened by alexliesenfeld 1
  • Bump github.com/stretchr/testify from 1.7.0 to 1.7.5

    Bump github.com/stretchr/testify from 1.7.0 to 1.7.5

    Bumps github.com/stretchr/testify from 1.7.0 to 1.7.5.

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 1
  • Bump github.com/stretchr/testify from 1.7.0 to 1.7.4

    Bump github.com/stretchr/testify from 1.7.0 to 1.7.4

    Bumps github.com/stretchr/testify from 1.7.0 to 1.7.4.

    Commits
    • 48391ba Fix panic in AssertExpectations for mocks without expectations (#1207)
    • 840cb80 arrays value types in a zero-initialized state are considered empty (#1126)
    • 07dc7ee Bump actions/setup-go from 3.1.0 to 3.2.0 (#1191)
    • c33fc8d Bump actions/checkout from 2 to 3 (#1163)
    • 3c33e07 Added Go 1.18.1 as a build/supported version (#1182)
    • e2b56b3 Bump github.com/stretchr/objx from 0.1.0 to 0.4.0
    • 41453c0 Update gopkg.in/yaml.v3
    • 285adcc Update go versions in build matrix
    • 6e7fab4 Bump actions/setup-go from 2 to 3.1.0
    • 106ec21 use RWMutex
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 1
  • Bump github.com/stretchr/testify from 1.7.0 to 1.7.2

    Bump github.com/stretchr/testify from 1.7.0 to 1.7.2

    Bumps github.com/stretchr/testify from 1.7.0 to 1.7.2.

    Commits
    • 41453c0 Update gopkg.in/yaml.v3
    • 285adcc Update go versions in build matrix
    • 6e7fab4 Bump actions/setup-go from 2 to 3.1.0
    • 106ec21 use RWMutex
    • a409ccf fix data race in the suit
    • 3586478 assert: fix typo
    • 7797738 Update versions supported to include go 1.16
    • 083ff1c Fixed didPanic to now detect panic(nil).
    • 1e36bfe Use cross Go version compatible build tag syntax
    • e798dc2 Add docs on 1.17 build tags
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 1
  • Bump github.com/hellofresh/health-go/v4 from 4.5.0 to 4.6.0 in /examples

    Bump github.com/hellofresh/health-go/v4 from 4.5.0 to 4.6.0 in /examples

    Bumps github.com/hellofresh/health-go/v4 from 4.5.0 to 4.6.0.

    Release notes

    Sourced from github.com/hellofresh/health-go/v4's releases.

    v4.6.0

    • InfluxDB health check (thx to @​nsuprun)
    • Min supported Go version is 1.17 as 1.16 reached EOL
    • Dependencies updated to the current latest versions
    Commits
    • e676461 Merge pull request #74 from hellofresh/patch/simplify-testing-workflow
    • 3f0abc0 Test summary depends on test
    • b1bc04d Fixed copy-pastd token value
    • 8ab9c68 Added summary job to allow required check for matrix job
    • 91bbbd5 Added info about influx to readme
    • 44c9494 Use the same services for local and ci testing
    • 00b91d7 Merge pull request #72 from nsuprun/feature-check-influxdb
    • 7ae8ea0 Updated github actions workflow
    • 1c8eee0 updates to comply with golangci-lint
    • ed093a2 modules update
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 1
  • Bump github.com/stretchr/testify from 1.7.0 to 1.7.1

    Bump github.com/stretchr/testify from 1.7.0 to 1.7.1

    Bumps github.com/stretchr/testify from 1.7.0 to 1.7.1.

    Commits
    • 083ff1c Fixed didPanic to now detect panic(nil).
    • 1e36bfe Use cross Go version compatible build tag syntax
    • e798dc2 Add docs on 1.17 build tags
    • 83198c2 assert: guard CanConvert call in backward compatible wrapper
    • 087b655 assert: allow comparing time.Time
    • 7bcf74e fix msgAndArgs forwarding
    • c29de71 add tests for correct msgAndArgs forwarding
    • f87e2b2 Update builds
    • ab6dc32 fix linting errors in /assert package
    • edff5a0 fix funtion name
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 1
  • Bump github.com/mattn/go-sqlite3 from 1.14.9 to 2.0.3+incompatible in /examples

    Bump github.com/mattn/go-sqlite3 from 1.14.9 to 2.0.3+incompatible in /examples

    Bumps github.com/mattn/go-sqlite3 from 1.14.9 to 2.0.3+incompatible.

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 1
  • Bump github.com/mattn/go-sqlite3 from 1.14.9 to 1.14.10 in /examples

    Bump github.com/mattn/go-sqlite3 from 1.14.9 to 1.14.10 in /examples

    Bumps github.com/mattn/go-sqlite3 from 1.14.9 to 1.14.10.

    Commits
    • 98c5219 Temporary disable test for dropping vtable
    • 7fbc50c Update amalgamation code
    • 8543684 Fix GitHub workflows
    • 4761e9c Do no test with go-acc on Windows (#980)
    • 48c6a56 Add go.mod and go.sum for upgrade (#978)
    • bb15a32 Drop old versions (#979)
    • 9537be5 Adds CIFuzz for fuzzing as continuous integration (#919)
    • a4fc68a sqlite3_test.go: Fix go test -run=...: Use standard sub-tests (#881)
    • 2b131e0 change angle bracket import to quotes (#868)
    • 5671e01 Update SQLite3_ The columntypescantype method of type (#909)
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 1
  • Add IMAP server health check

    Add IMAP server health check

    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.
    enhancement hacktoberfest 
    opened by alexliesenfeld 0
  • Add SMTP server health check

    Add SMTP server health check

    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.
    enhancement hacktoberfest 
    opened by alexliesenfeld 0
  • Add disk space check

    Add disk space check

    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.
    enhancement good first issue hacktoberfest 
    opened by alexliesenfeld 0
  • Add Mongo DB check

    Add Mongo DB check

    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.
    enhancement hacktoberfest 
    opened by alexliesenfeld 0
  • Add GRPC check

    Add GRPC check

    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.
    enhancement good first issue hacktoberfest 
    opened by alexliesenfeld 0
  • Add Memcached check

    Add Memcached check

    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.
    enhancement hacktoberfest 
    opened by alexliesenfeld 0
Releases(v0.6.0)
Owner
Alexander Liesenfeld
Alexander Liesenfeld
An extensible tool for creating your own in cluster health endpoints

healthyk8s an extensible tool for creating your own "in cluster" health endpoints Why? allows for creating a health endpoint for anything - external r

Nic Grobler 0 Oct 26, 2021
This is Reperio Health's GoLang backend assessment

reperio-backend-assessment This is Reperio Health's GoLang backend assessment. N

Andrew David Burt 1 Dec 22, 2021
This library provides a metrics package which can be used to instrument code, expose application metrics, and profile runtime performance in a flexible manner.

This library provides a metrics package which can be used to instrument code, expose application metrics, and profile runtime performance in a flexible manner.

null 0 Jan 18, 2022
Nomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications

Nomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications. Nomad is easy to operate and scale and has native Consul and Vault integrations.

HashiCorp 12.3k Sep 24, 2022
Flexible HTTP command line stress tester for websites and web services

Pewpew Pewpew is a flexible command line HTTP stress tester. Unlike other stress testers, it can hit multiple targets with multiple configurations, si

Ben Gadbois 354 Sep 15, 2022
Kubei is a flexible Kubernetes runtime scanner, scanning images of worker and Kubernetes nodes providing accurate vulnerabilities assessment, for more information checkout:

Kubei is a vulnerabilities scanning and CIS Docker benchmark tool that allows users to get an accurate and immediate risk assessment of their kubernet

Portshift 733 Sep 21, 2022
Connect, Subscribe and Publish over MQTT broker to check its status.

MQTT Blackbox Exporter Introduction In each probe it sends a message over MQTT broker and then wait for getting it over subscription. By measuring thi

Snapp Cab Incubators 12 Aug 27, 2022
A set of tests to check compliance with the Prometheus Remote Write specification

Prometheus Remote Write Compliance Test This repo contains a set of tests to check compliance with the Prometheus Remote Write specification. The test

Tom Wilkie 99 Sep 11, 2022
Kubedd – Check migration issues of Kubernetes Objects while K8s upgrade

Kubedd – Check migration issues of Kubernetes Objects while K8s upgrade

Devtron Labs 185 Sep 24, 2022
scenario system to check the behavior of kube-scheduler

kube-scheduler-simulator-cli: Kubernetes Scheduler simulator on CLI and scenario system. Hello world. This repository is scenario system for kube-sche

Kensei Nakada 2 Jan 25, 2022
GitHub Action: Compose multiple (conditional) checks into a single check based on file paths in a pull request

GitHub Action: Composite Example Usage --- name: All Checks on: pull_request: branches: - main jobs: meta: runs-on: - ubuntu-20.

Blend 16 Jul 19, 2022
Just a playground with some interesting concepts like pipelines aka middleware, handleFuncs, request validations etc. Check it out.

Pipeline a.k.a middleware in Go Just a playground with some interesting concepts like pipelines aka middleware, handleFuncs, request validations etc.

null 0 Dec 9, 2021
A tool that scans archives to check for vulnerable log4j versions

log4j-sniffer log4j-sniffer crawls for all instances of log4j that are earlier t

Palantir Technologies 187 Sep 25, 2022
A command-line debugging tool to check the latency of SSL handshake

ssl-handshake A command-line tool for testing SSL handshake latency, written in

Puru 40 Aug 10, 2022
Controller-check - Run checks against K8s controllers to verify if they meets certain conventions

controller-check Run checks against K8s controllers to verify if they meets cert

Sunny 2 Jan 4, 2022
Sensu-go-postgres-metrics - The sensu-go-postgres-metrics is a sensu check that collects PostgreSQL metrics

sensu-go-postgres-metrics Table of Contents Overview Known issues Usage examples

Scott Cupit 0 Jan 12, 2022
A tool to check whether docker images exist in the remote registry.

Check Docker Image A tool to check whether docker images exist in the remote registry. Build project: go build -o check-image . Example usage: REGISTR

Hao-Ming, Hsu 3 Jul 26, 2022
Gohalt 👮‍♀🛑: Fast; Simple; Powerful; Go Throttler library

Gohalt ??‍♀ ?? : Fast; Simple; Powerful; Go Throttler library go get -u github.com/1pkg/gohalt Introduction Gohalt is simple and convenient yet powerf

Kostiantyn Masliuk 256 Aug 16, 2022
A simple project (which is visitor counter) on kubernetesA simple project (which is visitor counter) on kubernetes

k8s playground This project aims to deploy a simple project (which is visitor counter) on kubernetes. Deploy steps kubectl apply -f secret.yaml kubect

null 12 Sep 5, 2022