The purpose of the doctor service is to do a complete check of the services status in the project in which is deployed.
To do this, the service will call a specific route, the
NB. the Doctor service is the only one who can call the
/-/check-up route of services.
NEVER call the
/-/check-up route of a service from the checkUpHandler of another service, the risk is to start a
/-/check-up calls loop.
The Doctor Service is easily deployable on every project by using the Console. You just need to add the service and configure it's configuration file.
The Doctor Service is simply based on one file, the configurations file.
With the configurations file it's easy to manage all services to
Specifically, the Doctor allows the user to do two things:
check-upall services in the configurations file by simply call the root path (e.g. http://api.foobar.it/playground/check-up);
check-upa subgroup of services by specify the tag → all services can have a list of tags (optional) and the Doctor will expose a dedicated route for each tag, that will return the
check-upof services with that tag.
NB. all the services call by the Doctor MUST have the
Following an overview of the steps that you have to do to integrate the Doctor Service in your project:
- Build the configurations file of the Doctor Service
- Create the service using the API Console
- Configure the Advanced configurations
- Check-up'em all
The following example is based on a Playground project.
As previously said, the Doctor Service just needs a configurations file that has to follow this schema:
As specified into the schema, the tags property is optional → a Doctor Service can have all services without tags and it still works on the root path.
Additionally, it is possible to specify an
options object in order to furtherly manage how the
/-/check-up route is called.
The following options can be provided:
prefix: to specify a prefix to append before
/-/check-uproute. Default is an empty string.
protocol: to specify a different protocol. Only
httpscan be specified. Default is
port: to specify a different port. Default is 1.
In the following example we will set just one tag, the core tag, just for core services:
This way, for
swagger-aggregator service, doctor-service will call the
/-/check-up route at
In this way, we should have the following routes:
baseUrl/check-up→ should return the
check-upresponse of all services
baseUrl/check-up/core→ should return the
check-upresponse just of services with the core tag
The configurations file is ready, let's continue.
Now it's time to create the real service.
Following the steps to create the services:
- Open the API Console and choose the project
- Click, on the left, on Microservices
- Click on the Create a Microservice button
- Search for doctor service and click on the Doctor Service plugin button
- Fill the form:
- Name: the name of the service (in the example is doctor-service)
- Description: the description of the service
- Click on the Create button
- Scroll down and click on Add a configuration
- Edit the environment variable SERVICES_LIST_PATH and set /home/node/app/config/services.json
- Fill the form:
- Configuration name: The name of the configuration (e.g. doctor-service-config)
- Runtime Mount Path: The folder path where will be created the configuration. Set to /home/node/app/config/
- Click on Add file, fill Name with services.json and click on Create
- Insert the previously created configurations file into the just created file
- Save (Commit and generate button)
/check-up route of the project is ready to be called like this:
projectBaseUrl/check-up→ for a check-up of all services
projectBaseUrl/check-up/core→ for a check-up of core services only (in this example)