You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: deploy-manage/monitor/autoops/ec-autoops-faq.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -115,8 +115,8 @@ $$$maintenance$$$ **Do I have to do any maintenance when using AutoOps for ECE,
115
115
* When using the ECK installation method, make sure your instance of {{agent}} meets the [version requirements](/deploy-manage/monitor/autoops/cc-connect-self-managed-to-autoops.md#prerequisites) for your license type.
116
116
117
117
$$$trial-ending$$$**I connected my ECE, ECK, or self-managed cluster to AutoOps during a free trial of {{ecloud}}. What happens after my trial ends?**
118
-
: After your free trial ends, your cluster remains connected and AutoOps continues to process your {{es}} metrics as long as:
119
-
* You have an [active {{ecloud}} account](../../cloud-organization/billing/add-billing-details.md).
118
+
: You don't need a paid {{ecloud}} subscription or an active {{ecloud}} trial to keep using AutoOps for ECE, ECK, or self-managed clusters. AutoOps is free across all [self-managed license types](https://www.elastic.co/subscriptions) through Cloud Connect. After your free trial ends, your cluster remains connected and AutoOps continues to process your {{es}} metrics as long as:
119
+
* You have an [active {{ecloud}} account](../../cloud-organization/billing/add-billing-details.md). Creating an {{ecloud}} account is free and doesn't require a paid subscription.
120
120
* {{agent}} is running and shipping metrics to {{ecloud}}.
121
121
122
122
$$$access-autoops$$$**Who has access to AutoOps in my cluster?**
[{{esql}} views](elasticsearch://reference/query-languages/esql/esql-views.md) aren't shown in the data source browser but they're visible through the autocomplete menu suggestions.
Copy file name to clipboardExpand all lines: reference/fleet/fleet-server-scalability.md
+7-3Lines changed: 7 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -66,6 +66,10 @@ stack: ga
66
66
67
67
The following advanced settings are available to fine tune your {{fleet-server}} deployment.
68
68
69
+
::::{note}
70
+
You can't configure agent offline detection through these settings. An agent is marked offline after it stops checking in with {{fleet-server}} for 5 minutes. This threshold is fixed and can't be changed.
71
+
::::
72
+
69
73
`cache`
70
74
: `num_counters`
71
75
: Size of the hash table. Best practice is to have this set to 10 times the max connections.
@@ -75,10 +79,10 @@ The following advanced settings are available to fine tune your {{fleet-server}}
75
79
76
80
`server.timeouts`
77
81
: `checkin_timestamp`
78
-
: How often {{fleet-server}} updates the "last activity" field for each agent. Defaults to `30s`. In a large-scale deployment, increasing this setting might improve performance. If this setting is higher than `2m`, most agents will be shown as "offline" in the Fleet UI. For a typical setup, it’s recommended that you set this value to less than `2m`.
82
+
: How often {{fleet-server}} updates the **Last activity** field for each agent. Defaults to `30s`. In a large-scale deployment, increasing this setting might improve performance. To avoid agents appearing offline in {{fleet}}, keep this value well below 5 minutes.
79
83
80
84
`checkin_long_poll`
81
-
: How long {{fleet-server}} allows a long poll request from an agent before timing out. Defaults to `5m`. In a large-scale deployment, increasing this setting might improve performance.
85
+
: How long {{fleet-server}} allows a long poll request from an agent before timing out. Defaults to `5m`. In a large-scale deployment, increasing this setting might improve performance. This setting controls the connection lifecycle between {{fleet-server}} and agents. It doesn't affect how quickly an agent is marked offline in {{fleet}}.
82
86
83
87
`server.limits`
84
88
: `policy_throttle`
@@ -101,7 +105,7 @@ The following advanced settings are available to fine tune your {{fleet-server}}
101
105
: Burst of check-ins allowed before falling back to the rate defined by `interval`.
102
106
103
107
`checkin_limit.max_body_byte_size`
104
-
: 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:
108
+
: 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 {{fleet}} despite monitors executing successfully. For example:
Copy file name to clipboardExpand all lines: reference/fleet/monitor-elastic-agent.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -55,7 +55,7 @@ The **Agents** tab in **{{fleet}}** displays a maximum of 10,000 agents, shown o
55
55
|**Unhealthy**| {{agent}}s have errors or are running in a degraded state. An agent will be reported as `unhealthy` as a result of a configuration problem on the host system. For example, an {{agent}} may not have the correct permissions required to run an integration that has been added to the {{agent}} policy. In this case, you may need to investigate and address the situation. |
56
56
|**Orphaned**| For {{agent}}s enrolled in {{elastic-defend}}, the `orphaned` status indicates an error in the communication between the {{agent}} service on the host system and the endpoint security service provided by {{elastic-defend}}. On agents reported as `orphaned`, the {{elastic-defend}} integration is still running and protecting the host. |
57
57
|**Updating**| {{agent}}s are updating the agent policy, updating the binary, or enrolling or unenrolling from {{fleet}}. |
58
-
|**Offline**| {{agent}}s have stayed in an unhealthy status for a period of time. Offline agent’s API keys remain valid. You can still see these {{agent}}s in the {{fleet}} UI and investigate them for further diagnosis if required. |
58
+
|**Offline**| {{agent}}s have stopped checking in with {{fleet-server}} for at least 5 minutes. This offline detection threshold is fixed at 5 minutes and can't be configured. The offline agents' API keys remain valid. You can still see these {{agent}}s in the {{fleet}} UI and investigate them for further diagnosis if required. |
59
59
|**Inactive**| {{agent}}s have been offline for longer than the time set in your [inactivity timeout](/reference/fleet/set-inactivity-timeout.md). These {{agent}}s are valid, but have been removed from the main {{fleet}} UI. |
60
60
|**Unenrolled**| {{agent}}s have been manually unenrolled and their API keys have been removed from the system. You can [unenroll](/reference/fleet/unenroll-elastic-agent.md) an offline {{agent}} using {{agent}} actions if you determine it’s offline and no longer valid.<br>These agents need to re-enroll in {{fleet}} to be operational again. |
61
61
|**Uninstalled**| {{agent}}s have been successfully uninstalled and removed from the host system. |
0 commit comments