Notes
  • Blockchain
  • About this repository
  • References
  • Carret Position
  • Loggia and Balcony
  • automobile
    • Motorbike
  • computer
    • Kubernetes Event-driven Autoscaling (KEDA)
    • Protobuf
    • [[Amazon]] [[Identity and Access Management]] ([[IAM]])
    • Apdex
    • Architecture Decision Record
    • Audio
    • [[Amazon Web Services]] (AWS) Lambda
    • Blockchain
    • C/C++
    • Cache line
    • Caching strategies
    • Database
    • Design Patterns
    • Docker compose
    • Event Driven Design
    • False sharing
    • Git
    • [[Go]] common mistakes
    • [Go] [[subtests]]
    • Go
    • Janus
    • Jest
    • Kubernetes
    • Log-Structured Merge-tree
    • Media server
    • MySQL: Charset, Collation and UCA
    • Netflix
    • Opus Codec
    • Process, Thread
    • ReDoS - [[Regular expression]] Denial of Service
    • Rust
    • ScyllaDB
    • Shell Functions
    • Signals (The GNU Library)
    • Solidity
    • Sources
    • SQL
    • Transmission Control Protocol (TCP)
    • Ten design principles for Azure applications
    • Transient Fault Handling
    • twemproxy
    • Video
    • Web2 vs Web3
    • WebRTC
    • Microservice architecture
      • 3rd party registration
      • Command Query Responsibility Segregation (CQRS)
      • Access token
      • Aggregate
      • API Composition
      • API gateway/Backends for Frontends
      • Application metrics
      • Audit logging
      • Circuit Breaker
      • Client-side discovery
      • Client-side UI composition
      • Consumer-driven contract test
      • Consumer-side contract test
      • Database per Service
      • Decompose by business capability
      • Decompose by subdomain
      • Distributed tracing
      • Domain event
      • Domain-specific
      • Event sourcing
      • Exception tracking
      • Externalized configuration
      • Health check API
      • Log aggregation
      • Log deployments and changes
      • Messaging
      • Microservice architecture
      • Microservice Chassis
      • Multiple Service instances per host
      • Polling publisher
      • Remote Procedure invocation
      • Saga
      • Self-contained service
      • Self registration
      • Server-side discovery
      • Server-side page fragment composition
      • Serverless deployment
      • Service Component test
      • Service deployment platform
      • Service instance per Container
      • Service instance per VM
      • Service mesh
      • Service per team
      • Service registry
      • Service template
      • Shared database
      • Single Service instance per host
      • Transaction log tailling
      • Transactional outbox
  • food-and-beverage
    • Cheese
    • Flour
    • Japanese Plum liqueur or Umeshu
    • Sugar
  • management
    • Software Engineering processes
  • medic
    • Desease, disorder, condition, syndrome
    • Motion Sickess
  • others
    • Elliðaey
    • ASCII art
    • Empirical rule
    • Hindsight bias
    • Outcome bias
    • Tam giác Reuleaux
    • Luật Việt Nam
  • soft-skills
    • Emotional intelligence
Powered by GitBook
On this page
  • Context
  • Problem
  • Forces
  • Solution
  • Examples
  • Resulting Context
  • Related patterns
  1. computer
  2. Microservice architecture

Health check API

Context

You have applied the [[Microservice architecture]] pattern. Sometimes a service instance can be incapable of handling requests yet still be running. For example, it might have ran out of database connections. When this occurs, the monitoring system should generate a alert. Also, the load balancer or service registry should not route requests to the failed service instance.

Problem

How to detect that a running service instance is unable to handle requests?

Forces

  • An alert should be generated when a service instance fails

  • Requests should be routed to working service instances

Solution

A service has an health check API endpoint (e.g. HTTP /health) that returns the health of the service. The API endpoint handler performs various checks, such as

  • the status of the connections to the infrastructure services used by the service instance

  • the status of the host, e.g. disk space

  • application specific logic

A health check client - a monitoring service, [[service registry]] or load balancer - periodically invokes the endpoint to check the health of the service instance.

Examples

To enable a /health endpoint, first define actuator as a dependency:

dependencies {
  compile "org.springframework.boot:spring-boot-starter-actuator"

Second, enable Spring Boot autoconfiguration:

@SpringBootApplication
class UserRegistrationConfiguration {

At this point, your application will have a health check endpoint with default behavior.

You can customize this behavior by defining one or more Spring beans that implement the HealthIndicator interface:

class UserRegistrationConfiguration {
  @Bean
  def discoveryHealthIndicator(discoveryClient : EurekaClient ) : HealthIndicator = new DiscoveryHealthIndicator(discoveryClient)

A HealthIndicator must implement a health() method, which returns a Health value.

Resulting Context

This pattern has the following benefits:

  • The health check endpoint enables the health of a service instance to be periodically tested

This pattern has the following drawbacks:

  • The health check might not sufficiently comprehensive or the service instance might fail between health checks and so requests might still be routed to a failed service instance

Related patterns

[[Service registry]] - the service registry invokes the health check endpoint

PreviousExternalized configurationNextLog aggregation

Last updated 2 years ago

The is an example on an application implements a health check API. It is written in Scala and uses Spring Boot and Spring Cloud as the Microservice chassis. They provide various capabilities including a health check endpoint. The endpoint is implemented by the Spring Boot Actuator module. It configures a /health HTTP endpoint that invokes extensible health check logic.

Microservices Example application