Skip to content

Commit 68369bd

Browse files
dedemortondedemorton
authored
Reorganize Fleet Server content (#1274)
* Reorganize Fleet Server content * Fix chicken/egg link problem
1 parent e6129a8 commit 68369bd

File tree

6 files changed

+195
-181
lines changed

6 files changed

+195
-181
lines changed

‎docs/en/ingest-management/fleet/add-fleet-server.asciidoc‎

Lines changed: 41 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,41 @@
1+
[[add-a-fleet-server]]
2+
= Add a {fleet-server}
3+
4+
To use {fleet} for central management, a <<fleet-server,{fleet-server}>> must
5+
be running and accessible to your hosts. This page describes how to add a
6+
{fleet-server} to an {ecloud} or self-managed deployment.
7+
8+
[discrete]
9+
[[fleet-server-compatibility]]
10+
== Compatibility and prerequisites
11+
12+
{fleet-server} is compatible with the following Elastic products:
13+
14+
* {stack} 7.13 or later ({ess-product}[hosted {ess}] on {ecloud}, or
15+
a self-managed cluster).
16+
** For version compatibility: {es} >= {fleet-server} >= {agent} (except for
17+
bugfix releases)
18+
** {kib} should be on the same minor version as {es}.
19+
20+
* {ece} 2.9--requires you to self-manage the {fleet-server}.
21+
* {ece} 2.10 or later--allows you to use a hosted {fleet-server} on {ecloud}.
22+
+
23+
--
24+
** Requires additional wildcard domains and certificates (which normally only
25+
cover `*.cname`, not `*.*.cname`). This enables us to provide the URL for
26+
{fleet-server} of `https://.fleet.`.
27+
** The deployment template must contain an APM & Fleet node.
28+
--
29+
+
30+
For more information about hosting {fleet-server} on {ece}, refer to
31+
{ece-ref}/ece-manage-apm-and-fleet.html[Manage your APM & {fleet-server}].
32+
33+
== How to add a {fleet-server}
34+
35+
The steps for running {fleet-server} on our {ess-product}[hosted {ess}] on
36+
{ecloud} are different from the steps for running it as self-managed.
37+
38+
include::{tab-widgets}/add-fleet-server/widget.asciidoc[]
39+
40+
Now you're ready to add {agent}s to your host systems. To learn how, see
41+
<<install-fleet-managed-elastic-agent>>.

‎docs/en/ingest-management/fleet/fleet-server-deployment-models.asciidoc‎

Lines changed: 63 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,63 @@
1+
[[deployment-models]]
2+
= {fleet-server} deployment models
3+
4+
Administrators deploying the {agent} have a few deployment choices
5+
available to satisfy their organization's requirements. {fleet-server} can be
6+
deployed:
7+
8+
* On {ecloud}, as part of our hosted {ess}, which is managed by Elastic, or
9+
* On-prem and self-managed
10+
11+
12+
[discrete]
13+
[[deployed-in-cloud]]
14+
== Deployed in {ecloud}
15+
16+
To simplify the deployment of {agent}, the {fleet-server} can be
17+
provisioned and hosted in the {ecloud}. In this case, when the deployment is
18+
created, a highly available set of {fleet-server}s are automatically deployed.
19+
20+
Administrators can choose the resources allocated to the {fleet-server} and
21+
whether they want the {fleet-server} to be deployed in multiple availability
22+
zones.
23+
24+
Once deployed on {ecloud} as a service, the full life cycle of the
25+
{fleet-server} is managed by Elastic. {fleet-server} is scalable and highly
26+
available with traffic ingress load balanced across multiple instances to
27+
satisfy the scale requirements.
28+
29+
image::images/fleet-server-cloud-deployment.png[{fleet-server} Cloud deployment model]
30+
31+
[discrete]
32+
[[deployed-on-prem]]
33+
== Deployed on-prem and self-managed
34+
35+
{fleet-server} can be deployed on-premises and managed by the user. In this
36+
deployment model, the administrator is responsible for {fleet-server} deployment
37+
and lifecycle management. This mode of operation is predominantly chosen to
38+
satisfy data governance requirements or used in scenarios where the agents only
39+
have access to a private segmented network.
40+
41+
It’s recommended that the administrator provision multiple instances of the
42+
{fleet-server} and use a load balancer to better scale the deployment.
43+
44+
//TODO: Replace with clean images when they are available.
45+
46+
image::images/fleet-server-on-prem-deployment.png[{fleet-server} on-prem deployment model]
47+
48+
[discrete]
49+
[[fleet-server-HA-operations]]
50+
== {fleet-server} High availability operations
51+
52+
{fleet-server} is stateless. Connections to the {fleet-server} therefore can be
53+
load balanced as long as the {fleet-server} has capacity to accept more
54+
connections. Load balancing is done on a round-robin basis.
55+
56+
In the {ecloud} deployment model, multiple {fleet-server}s are automatically
57+
provisioned to satisfy the instance size chosen (instance sizes are modified to
58+
satisfy the scale requirement). In addition, if you choose multiple
59+
availability zones to address your fault-tolerance requirements, those
60+
instances are also utilized to balance the load.
61+
62+
In an on-prem deployment, high-availability, fault-tolerance, and lifecycle
63+
management of the {fleet-server} are the responsibility of the administrator.

‎docs/en/ingest-management/fleet/fleet-server-monitoring.asciidoc‎

Lines changed: 71 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
1+
[[fleet-server-monitoring]]
2+
= {fleet-server} monitoring
3+
4+
Monitoring {fleet-server} is key since the operation of the {fleet-server} is
5+
paramount to the health of the deployed agents and the services they offer. When
6+
{fleet-server} is not operating correctly, it may lead to delayed check-ins,
7+
status information, and updates for the agents it manages. The monitoring data
8+
will tell you when to add capacity for {fleet-server}, and provide error logs
9+
and information to troubleshoot other issues.
10+
11+
To enable monitoring for {fleet-server}, turn on agent monitoring in the agent
12+
policy. For self-managed clusters, monitoring is on by default when you create a
13+
new agent policy or use the existing Default {fleet-server} agent policy.
14+
However, it is off by default in the {ecloud} agent policy because monitoring
15+
requires additional RAM.
16+
17+
To turn on {fleet-server} monitoring in the agent policy:
18+
19+
. In {fleet}, go to *Agent Policies* and click on the *{ecloud} agent policy*.
20+
+
21+
[role="screenshot"]
22+
image::images/fleet-policy-page.png[Fleet Policy Page]
23+
24+
. Click the *Settings* tab and notice that Agent monitoring is
25+
off by default.
26+
27+
. Under *Agent monitoring*, select *Collect agent logs* and
28+
*Collect agent metrics*.
29+
+
30+
--
31+
[role="screenshot"]
32+
image::images/elastic-cloud-agent-policy-page.png[{ecloud} Policy Page]
33+
34+
The agent will now be able to collect logs and metrics from the {fleet-server}.
35+
36+
NOTE: The {fleet-server} is deployed as yet another agent in the system.
37+
--
38+
39+
. Next, set the *Default namespace*.
40+
+
41+
Setting the default namespace lets you segregate {fleet-server} monitoring data
42+
from other collected data. This makes it easier to search and visualize the
43+
monitoring data. By default the monitoring data is sent to the *default*
44+
namespace.
45+
46+
. To confirm your change, click *Save changes*.
47+
48+
To see the metrics collected for {fleet-server}, go to *Analytics > Discover*.
49+
50+
In the following example, `fleetserver` was configured as the namespace, and
51+
you can see the metrics collected:
52+
53+
[role="screenshot"]
54+
image::images/dashboard-with-namespace-showing.png[Namespace]
55+
56+
[role="screenshot"]
57+
image::images/datastream-namespace.png[Datastream]
58+
59+
In {kib}, go to *Analytics > Dashboard* and search for the predefined dashboard
60+
called *[Elastic Agent] Agent metrics*. Choose this dashboard, and run a query
61+
based on the `fleetserver` namespace.
62+
63+
The following dashboard shows data for the query `data_stream.namespace:
64+
"fleetserver"`. In this example, you can observe CPU and memory usage as a
65+
metric and then resize the {fleet-server}, if necessary.
66+
67+
[role="screenshot"]
68+
image::images/dashboard-datastream.png[Dashboard Datastream]
69+
70+
Note that as an alternative to running the query, you can hide all metrics
71+
except `fleet_server` in the dashboard.

‎docs/en/ingest-management/fleet/fleet-server-scaling.asciidoc‎

Lines changed: 6 additions & 82 deletions
Original file line numberDiff line numberDiff line change
@@ -1,8 +1,7 @@
1-
[discrete]
21
[[fleet-server-scalability]]
3-
== {fleet-server} scalability
2+
= {fleet-server} scalability
43

5-
This section summarizes the resource and {fleet-server} configuration
4+
This page summarizes the resource and {fleet-server} configuration
65
requirements needed to scale your deployment of {agent}s. To scale
76
{fleet-server}, you need to modify settings in your deployment and the
87
{fleet-server} agent policy.
@@ -45,7 +44,7 @@ image::images/fleet-server-configuration.png[{fleet-server} configuration]
4544

4645
[discrete]
4746
[[fleet-server-configuration]]
48-
=== Advanced {fleet-server} options
47+
== Advanced {fleet-server} options
4948

5049
The following advanced settings are available to fine tune your {fleet-server}
5150
deployment.
@@ -113,7 +112,7 @@ Burst of enrollments to accept before falling back to the rate defined by
113112

114113
[discrete]
115114
[[scaling-recommendations]]
116-
=== Scaling recommendations ({ecloud})
115+
== Scaling recommendations ({ecloud})
117116

118117
The following tables provide resource requirements and scaling guidelines based
119118
on the number of agents required by your deployment:
@@ -126,7 +125,7 @@ on the number of agents required by your deployment:
126125

127126
[discrete]
128127
[[resource-requirements-by-number-agents]]
129-
==== Resource requirements by number of agents
128+
=== Resource requirements by number of agents
130129
|===
131130
| Number of Agents | Memory | vCPU | {es} Cluster size
132131

@@ -143,7 +142,7 @@ on the number of agents required by your deployment:
143142
[discrete]
144143
[[recommend-settings-scaling-agents]]
145144

146-
==== Recommended settings by number of deployed {agent}s
145+
=== Recommended settings by number of deployed {agent}s
147146

148147
TIP: You might need to scroll to the right to see all the table columns.
149148

@@ -174,78 +173,3 @@ TIP: You might need to scroll to the right to see all the table columns.
174173
8+s| Server runtime settings
175174
| `gc_percent` | 20 | 20 | 20 | 20 | 20 | 20 | 20
176175
|===
177-
178-
179-
[discrete]
180-
[[fleet-server-monitoring]]
181-
== {fleet-server} monitoring
182-
183-
Monitoring {fleet-server} is key since the operation of the {fleet-server} is
184-
paramount to the health of the deployed agents and the services they offer. When
185-
{fleet-server} is not operating correctly, it may lead to delayed check-ins,
186-
status information, and updates for the agents it manages. The monitoring data
187-
will tell you when to add capacity for {fleet-server}, and provide error logs
188-
and information to troubleshoot other issues.
189-
190-
To enable monitoring for {fleet-server}, turn on agent monitoring in the agent
191-
policy. For self-managed clusters, monitoring is on by default when you create a
192-
new agent policy or use the existing Default {fleet-server} agent policy.
193-
However, it is off by default in the {ecloud} agent policy because monitoring
194-
requires additional RAM.
195-
196-
To turn on {fleet-server} monitoring in the agent policy:
197-
198-
. In {fleet}, go to *Agent Policies* and click on the *{ecloud} agent policy*.
199-
+
200-
[role="screenshot"]
201-
image::images/fleet-policy-page.png[Fleet Policy Page]
202-
203-
. Click the *Settings* tab and notice that Agent monitoring is
204-
off by default.
205-
206-
. Under *Agent monitoring*, select *Collect agent logs* and
207-
*Collect agent metrics*.
208-
+
209-
--
210-
[role="screenshot"]
211-
image::images/elastic-cloud-agent-policy-page.png[{ecloud} Policy Page]
212-
213-
The agent will now be able to collect logs and metrics from the {fleet-server}.
214-
215-
NOTE: The {fleet-server} is deployed as yet another agent in the system.
216-
--
217-
218-
. Next, set the *Default namespace*.
219-
+
220-
Setting the default namespace lets you segregate {fleet-server} monitoring data
221-
from other collected data. This makes it easier to search and visualize the
222-
monitoring data. By default the monitoring data is sent to the *default*
223-
namespace.
224-
225-
. To confirm your change, click *Save changes*.
226-
227-
To see the metrics collected for {fleet-server}, go to *Analytics > Discover*.
228-
229-
In the following example, `fleetserver` was configured as the namespace, and
230-
you can see the metrics collected:
231-
232-
[role="screenshot"]
233-
image::images/dashboard-with-namespace-showing.png[Namespace]
234-
235-
[role="screenshot"]
236-
image::images/datastream-namespace.png[Datastream]
237-
238-
In {kib}, go to *Analytics > Dashboard* and search for the predefined dashboard
239-
called *[Elastic Agent] Agent metrics*. Choose this dashboard, and run a query
240-
based on the `fleetserver` namespace.
241-
242-
The following dashboard shows data for the query `data_stream.namespace:
243-
"fleetserver"`. In this example, you can observe CPU and memory usage as a
244-
metric and then resize the {fleet-server}, if necessary.
245-
246-
[role="screenshot"]
247-
image::images/dashboard-datastream.png[Dashboard Datastream]
248-
249-
Note that as an alternative to running the query, you can hide all metrics
250-
except `fleet_server` in the dashboard.
251-

0 commit comments

Comments
 (0)