Add documentation about the Scheduler's built-in healthcheck system

bunkerity · Oct 23, 2024 · 2bcf8c5 · 2bcf8c5
1 parent 4abb20b
commit 2bcf8c5
Show file tree

Hide file tree

Showing 3 changed files with 9 additions and 0 deletions.
diff --git a/docs/concepts.md b/docs/concepts.md
@@ -147,6 +147,12 @@ Depending on the integration approach, the execution environment of the schedule
 
 By employing the scheduler, BunkerWeb streamlines the automation and coordination of essential tasks, enabling efficient and reliable operation of the entire system.
 
+### Instances healthcheck
+
+Since the 1.6.0-beta, the Scheduler possess a built-in healthcheck system, that will check the health of the instances. If an instance becomes unhealthy, the scheduler will stop sending the configuration to it. If the instance becomes healthy again, the scheduler will start sending the configuration to it again.
+
+The healthcheck interval is set by the `HEALTHCHECK_INTERVAL` environment variable with a default value of `30` which means that the scheduler will check the health of the instances every 30 seconds.
+
 ## Templates
 
 BunkerWeb leverages the power of templates to simplify the configuration process and enhance flexibility. Templates provide a structured and standardized approach to defining settings and custom configurations, ensuring consistency and ease of use.

diff --git a/docs/settings.md b/docs/settings.md
@@ -29,6 +29,7 @@ STREAM support :warning:
 | `LOG_FORMAT`                   | `$host $remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"` | global    | no       | The format to use for access logs.                                                                  |
 | `LOG_LEVEL`                    | `notice`                                                                                                                 | global    | no       | The level to use for error logs.                                                                    |
 | `DNS_RESOLVERS`                | `127.0.0.11`                                                                                                             | global    | no       | DNS addresses of resolvers to use.                                                                  |
+| `WORKERLOCK_MEMORY_SIZE`       | `48k`                                                                                                                    | global    | no       | Size of lua_shared_dict for initialization workers                                                  |
 | `DATASTORE_MEMORY_SIZE`        | `64m`                                                                                                                    | global    | no       | Size of the internal datastore.                                                                     |
 | `CACHESTORE_MEMORY_SIZE`       | `64m`                                                                                                                    | global    | no       | Size of the internal cachestore.                                                                    |
 | `CACHESTORE_IPC_MEMORY_SIZE`   | `16m`                                                                                                                    | global    | no       | Size of the internal cachestore (ipc).                                                              |

diff --git a/docs/upgrading.md b/docs/upgrading.md
@@ -396,6 +396,8 @@ Unlike the 1.5.X releases, the Scheduler service **no longer uses the *docker so
 
     **The instances will be automatically fetched by the controller**. You can also add custom instances to the list that may not be picked up by the controller.
 
+Since the 1.6.0-beta, the Scheduler also have a new [built-in healthcheck system](concepts.md#instances-healthcheck), that will check the health of the instances. If an instance becomes unhealthy, the scheduler will stop sending the configuration to it. If the instance becomes healthy again, the scheduler will start sending the configuration to it again.
+
 ### BunkerWeb container
 
 Another important change is that the **settings** that were previously declared on the BunkerWeb container **are now declared on the scheduler**. This means that you'll have to move your settings from the BunkerWeb container to the Scheduler container.