From f74974c8a6274674896618ab2dacb776727b0d6b Mon Sep 17 00:00:00 2001 From: Arianna Laudazzi Date: Wed, 13 May 2026 10:17:28 +0200 Subject: [PATCH 1/3] Port fix from 9.0 --- .../fleet/fleet-server-scaling.asciidoc | 27 ++++++++++++------- 1 file changed, 17 insertions(+), 10 deletions(-) diff --git a/docs/en/ingest-management/fleet/fleet-server-scaling.asciidoc b/docs/en/ingest-management/fleet/fleet-server-scaling.asciidoc index 813a4af0c..298450883 100644 --- a/docs/en/ingest-management/fleet/fleet-server-scaling.asciidoc +++ b/docs/en/ingest-management/fleet/fleet-server-scaling.asciidoc @@ -96,8 +96,15 @@ Burst of check-ins allowed before falling back to the rate defined by `interval`. `checkin_limit.max_body_byte_size`::: -Maximum size in bytes of the checkin API request body. - +Maximum size in bytes of the checkin API request body. Defaults to `1048576` bytes (1 MiB). Deployments running many Synthetics monitors might need to increase this value to avoid check-in failures that cause agents to appear offline or unhealthy in the {fleet} UI despite monitors executing successfully. For example: + +```yaml +server: + limits: + max_body_byte_size: 104857600 + checkin_limit: + max_body_byte_size: 104857600 +``` `artifact_limit.max`::: Maximum number of agents that can call the artifact API concurrently. It allows the user to avoid overloading the {fleet-server} from artifact API calls. @@ -146,10 +153,10 @@ Burst of enrollments to accept before falling back to the rate defined by Maximum size in bytes of the enroll API request body. `status_limit.max`::: -Maximum number of agents that can call the status API concurrently. This setting allows the user to avoid overloading the Fleet Server from status API calls. +Maximum number of agents that can call the status API concurrently. This setting allows the user to avoid overloading the {fleet-server} from status API calls. `status_limit.interval`::: -How frequently agents can submit status requests to the Fleet Server. +How frequently agents can submit status requests to the {fleet-server}. `status_limit.burst`::: Burst of status requests to accomodate before falling back to the rate defined by interval. @@ -158,10 +165,10 @@ Burst of status requests to accomodate before falling back to the rate defined b Maximum size in bytes of the status API request body. `upload_start_limit.max`::: -Maximum number of agents that can call the uploadStart API concurrently. This setting allows the user to avoid overloading the Fleet Server from uploadStart API calls. +Maximum number of agents that can call the uploadStart API concurrently. This setting allows the user to avoid overloading the {fleet-server} from uploadStart API calls. `upload_start_limit.interval`::: -How frequently agents can submit file start upload requests to the Fleet Server. +How frequently agents can submit file start upload requests to the {fleet-server}. `upload_start_limit.burst`::: Burst of file start upload requests to accomodate before falling back to the rate defined by interval. @@ -170,10 +177,10 @@ Burst of file start upload requests to accomodate before falling back to the rat Maximum size in bytes of the uploadStart API request body. `upload_end_limit.max`::: -Maximum number of agents that can call the uploadEnd API concurrently. This setting allows the user to avoid overloading the Fleet Server from uploadEnd API calls. +Maximum number of agents that can call the uploadEnd API concurrently. This setting allows the user to avoid overloading the {fleet-server} from uploadEnd API calls. `upload_end_limit.interval`::: -How frequently agents can submit file end upload requests to the Fleet Server. +How frequently agents can submit file end upload requests to the {fleet-server}. `upload_end_limit.burst`::: Burst of file end upload requests to accomodate before falling back to the rate defined by interval. @@ -182,10 +189,10 @@ Burst of file end upload requests to accomodate before falling back to the rate Maximum size in bytes of the uploadEnd API request body. `upload_chunk_limit.max`::: -Maximum number of agents that can call the uploadChunk API concurrently. This setting allows the user to avoid overloading the Fleet Server from uploadChunk API calls. +Maximum number of agents that can call the uploadChunk API concurrently. This setting allows the user to avoid overloading the {fleet-server} from uploadChunk API calls. `upload_chunk_limit.interval`::: -How frequently agents can submit file chunk upload requests to the Fleet Server. +How frequently agents can submit file chunk upload requests to the {fleet-server}. `upload_chunk_limit.burst`::: Burst of file chunk upload requests to accomodate before falling back to the rate defined by interval. From c1172f7cc0b32f76ba977cab15b1bd371fec84aa Mon Sep 17 00:00:00 2001 From: Arianna Laudazzi <46651782+alaudazzi@users.noreply.github.com> Date: Wed, 13 May 2026 10:37:54 +0200 Subject: [PATCH 2/3] Apply suggestions from code review Co-authored-by: Visha Angelova <91186315+vishaangelova@users.noreply.github.com> --- .../ingest-management/fleet/fleet-server-scaling.asciidoc | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/en/ingest-management/fleet/fleet-server-scaling.asciidoc b/docs/en/ingest-management/fleet/fleet-server-scaling.asciidoc index 298450883..41019bb4f 100644 --- a/docs/en/ingest-management/fleet/fleet-server-scaling.asciidoc +++ b/docs/en/ingest-management/fleet/fleet-server-scaling.asciidoc @@ -98,13 +98,15 @@ Burst of check-ins allowed before falling back to the rate defined by `checkin_limit.max_body_byte_size`::: Maximum size in bytes of the checkin API request body. Defaults to `1048576` bytes (1 MiB). Deployments running many Synthetics monitors might need to increase this value to avoid check-in failures that cause agents to appear offline or unhealthy in the {fleet} UI despite monitors executing successfully. For example: -```yaml +[source,yaml] +---- server: limits: max_body_byte_size: 104857600 checkin_limit: max_body_byte_size: 104857600 -``` +---- + `artifact_limit.max`::: Maximum number of agents that can call the artifact API concurrently. It allows the user to avoid overloading the {fleet-server} from artifact API calls. From 994572b6ecdf826e5f3d40a424e368ce92ee9d99 Mon Sep 17 00:00:00 2001 From: Arianna Laudazzi <46651782+alaudazzi@users.noreply.github.com> Date: Wed, 13 May 2026 10:43:58 +0200 Subject: [PATCH 3/3] Update docs/en/ingest-management/fleet/fleet-server-scaling.asciidoc Co-authored-by: Visha Angelova <91186315+vishaangelova@users.noreply.github.com> --- docs/en/ingest-management/fleet/fleet-server-scaling.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/ingest-management/fleet/fleet-server-scaling.asciidoc b/docs/en/ingest-management/fleet/fleet-server-scaling.asciidoc index 41019bb4f..3604ac895 100644 --- a/docs/en/ingest-management/fleet/fleet-server-scaling.asciidoc +++ b/docs/en/ingest-management/fleet/fleet-server-scaling.asciidoc @@ -97,7 +97,7 @@ Burst of check-ins allowed before falling back to the rate defined by `checkin_limit.max_body_byte_size`::: Maximum size in bytes of the checkin API request body. Defaults to `1048576` bytes (1 MiB). Deployments running many Synthetics monitors might need to increase this value to avoid check-in failures that cause agents to appear offline or unhealthy in the {fleet} UI despite monitors executing successfully. For example: - ++ [source,yaml] ---- server: