Skip to content

Reorganize Fleet Server content #1274

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Nov 23, 2021
Merged

Reorganize Fleet Server content #1274

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1371f66
Reorganize Fleet Server content
dedemorton Nov 19, 2021
946011d
Fix chicken/egg link problem
dedemorton Nov 22, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 41 additions & 0 deletions docs/en/ingest-management/fleet/add-fleet-server.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
[[add-fleet-server]]
= Add a {fleet-server}

To use {fleet} for central management, a <<fleet-server,{fleet-server}>> must
be running and accessible to your hosts. This page describes how to add a
{fleet-server} to an {ecloud} or self-managed deployment.

[discrete]
[[fleet-server-compatibility]]
== Compatibility and prerequisites

{fleet-server} is compatible with the following Elastic products:

* {stack} 7.13 or later ({ess-product}[hosted {ess}] on {ecloud}, or
a self-managed cluster).
** For version compatibility: {es} >= {fleet-server} >= {agent} (except for
bugfix releases)
** {kib} should be on the same minor version as {es}.

* {ece} 2.9--requires you to self-manage the {fleet-server}.
* {ece} 2.10 or later--allows you to use a hosted {fleet-server} on {ecloud}.
+
--
** Requires additional wildcard domains and certificates (which normally only
cover `*.cname`, not `*.*.cname`). This enables us to provide the URL for
{fleet-server} of `https://.fleet.`.
** The deployment template must contain an APM & Fleet node.
--
+
For more information about hosting {fleet-server} on {ece}, refer to
{ece-ref}/ece-manage-apm-and-fleet.html[Manage your APM & {fleet-server}].

== How to add a {fleet-server}

The steps for running {fleet-server} on our {ess-product}[hosted {ess}] on
{ecloud} are different from the steps for running it as self-managed.

include::{tab-widgets}/add-fleet-server/widget.asciidoc[]

Now you're ready to add {agent}s to your host systems. To learn how, see
<<install-fleet-managed-elastic-agent>>.
63 changes: 63 additions & 0 deletions docs/en/ingest-management/fleet/fleet-server-deployment-models.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,63 @@
[[deployment-models]]
= {fleet-server} deployment models

Administrators deploying the {agent} have a few deployment choices
available to satisfy their organization's requirements. {fleet-server} can be
deployed:

* On {ecloud}, as part of our hosted {ess}, which is managed by Elastic, or
* On-prem and self-managed


[discrete]
[[deployed-in-cloud]]
== Deployed in {ecloud}

To simplify the deployment of {agent}, the {fleet-server} can be
provisioned and hosted in the {ecloud}. In this case, when the deployment is
created, a highly available set of {fleet-server}s are automatically deployed.

Administrators can choose the resources allocated to the {fleet-server} and
whether they want the {fleet-server} to be deployed in multiple availability
zones.

Once deployed on {ecloud} as a service, the full life cycle of the
{fleet-server} is managed by Elastic. {fleet-server} is scalable and highly
available with traffic ingress load balanced across multiple instances to
satisfy the scale requirements.

image::images/fleet-server-cloud-deployment.png[{fleet-server} Cloud deployment model]

[discrete]
[[deployed-on-prem]]
== Deployed on-prem and self-managed

{fleet-server} can be deployed on-premises and managed by the user. In this
deployment model, the administrator is responsible for {fleet-server} deployment
and lifecycle management. This mode of operation is predominantly chosen to
satisfy data governance requirements or used in scenarios where the agents only
have access to a private segmented network.

It’s recommended that the administrator provision multiple instances of the
{fleet-server} and use a load balancer to better scale the deployment.

//TODO: Replace with clean images when they are available.

image::images/fleet-server-on-prem-deployment.png[{fleet-server} on-prem deployment model]

[discrete]
[[fleet-server-HA-operations]]
== {fleet-server} High availability operations

{fleet-server} is stateless. Connections to the {fleet-server} therefore can be
load balanced as long as the {fleet-server} has capacity to accept more
connections. Load balancing is done on a round-robin basis.

In the {ecloud} deployment model, multiple {fleet-server}s are automatically
provisioned to satisfy the instance size chosen (instance sizes are modified to
satisfy the scale requirement). In addition, if you choose multiple
availability zones to address your fault-tolerance requirements, those
instances are also utilized to balance the load.

In an on-prem deployment, high-availability, fault-tolerance, and lifecycle
management of the {fleet-server} are the responsibility of the administrator.
71 changes: 71 additions & 0 deletions docs/en/ingest-management/fleet/fleet-server-monitoring.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,71 @@
[[fleet-server-monitoring]]
= {fleet-server} monitoring

Monitoring {fleet-server} is key since the operation of the {fleet-server} is
paramount to the health of the deployed agents and the services they offer. When
{fleet-server} is not operating correctly, it may lead to delayed check-ins,
status information, and updates for the agents it manages. The monitoring data
will tell you when to add capacity for {fleet-server}, and provide error logs
and information to troubleshoot other issues.

To enable monitoring for {fleet-server}, turn on agent monitoring in the agent
policy. For self-managed clusters, monitoring is on by default when you create a
new agent policy or use the existing Default {fleet-server} agent policy.
However, it is off by default in the {ecloud} agent policy because monitoring
requires additional RAM.

To turn on {fleet-server} monitoring in the agent policy:
Copy link
Contributor

@EricDavisX EricDavisX Nov 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dedemorton I believe the docs are wrong in that we don't allow this. The UI might have *seemed to let you do it, but we've recently fixed that I think. QA logged a bug about it and was confirmed, see notes in this issue:
elastic/kibana#110533 (comment)
and this is the 'question' bug that QA logged: elastic/kibana#117809

Copy link
Contributor Author

@dedemorton dedemorton Nov 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't new content; it's just moved from the long Fleet Server topic. So it has not been tested recently.

@nimarezainia Can you let me know how to proceed here? I can remove the content, but I don't want to make the call without your input.

Copy link
Contributor Author

@dedemorton dedemorton Nov 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@EricDavisX Actually, can you open an issue about this in the observability-docs repo? I don't want this PR to get stalled since the changes are structural, not content.


. In {fleet}, go to *Agent Policies* and click on the *{ecloud} agent policy*.
+
[role="screenshot"]
image::images/fleet-policy-page.png[Fleet Policy Page]

. Click the *Settings* tab and notice that Agent monitoring is
off by default.

. Under *Agent monitoring*, select *Collect agent logs* and
*Collect agent metrics*.
+
--
[role="screenshot"]
image::images/elastic-cloud-agent-policy-page.png[{ecloud} Policy Page]

The agent will now be able to collect logs and metrics from the {fleet-server}.

NOTE: The {fleet-server} is deployed as yet another agent in the system.
--

. Next, set the *Default namespace*.
+
Setting the default namespace lets you segregate {fleet-server} monitoring data
from other collected data. This makes it easier to search and visualize the
monitoring data. By default the monitoring data is sent to the *default*
namespace.

. To confirm your change, click *Save changes*.

To see the metrics collected for {fleet-server}, go to *Analytics > Discover*.

In the following example, `fleetserver` was configured as the namespace, and
you can see the metrics collected:

[role="screenshot"]
image::images/dashboard-with-namespace-showing.png[Namespace]

[role="screenshot"]
image::images/datastream-namespace.png[Datastream]

In {kib}, go to *Analytics > Dashboard* and search for the predefined dashboard
called *[Elastic Agent] Agent metrics*. Choose this dashboard, and run a query
based on the `fleetserver` namespace.

The following dashboard shows data for the query `data_stream.namespace:
"fleetserver"`. In this example, you can observe CPU and memory usage as a
metric and then resize the {fleet-server}, if necessary.

[role="screenshot"]
image::images/dashboard-datastream.png[Dashboard Datastream]

Note that as an alternative to running the query, you can hide all metrics
except `fleet_server` in the dashboard.
88 changes: 6 additions & 82 deletions docs/en/ingest-management/fleet/fleet-server-scaling.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,8 +1,7 @@
[discrete]
[[fleet-server-scalability]]
== {fleet-server} scalability
= {fleet-server} scalability

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

[discrete]
[[fleet-server-configuration]]
=== Advanced {fleet-server} options
== Advanced {fleet-server} options

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

[discrete]
[[scaling-recommendations]]
=== Scaling recommendations ({ecloud})
== Scaling recommendations ({ecloud})

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

[discrete]
[[resource-requirements-by-number-agents]]
==== Resource requirements by number of agents
=== Resource requirements by number of agents
|===
| Number of Agents | Memory | vCPU | {es} Cluster size

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

==== Recommended settings by number of deployed {agent}s
=== Recommended settings by number of deployed {agent}s

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

Expand Down Expand Up @@ -174,78 +173,3 @@ TIP: You might need to scroll to the right to see all the table columns.
8+s| Server runtime settings
| `gc_percent` | 20 | 20 | 20 | 20 | 20 | 20 | 20
|===


[discrete]
[[fleet-server-monitoring]]
== {fleet-server} monitoring

Monitoring {fleet-server} is key since the operation of the {fleet-server} is
paramount to the health of the deployed agents and the services they offer. When
{fleet-server} is not operating correctly, it may lead to delayed check-ins,
status information, and updates for the agents it manages. The monitoring data
will tell you when to add capacity for {fleet-server}, and provide error logs
and information to troubleshoot other issues.

To enable monitoring for {fleet-server}, turn on agent monitoring in the agent
policy. For self-managed clusters, monitoring is on by default when you create a
new agent policy or use the existing Default {fleet-server} agent policy.
However, it is off by default in the {ecloud} agent policy because monitoring
requires additional RAM.

To turn on {fleet-server} monitoring in the agent policy:

. In {fleet}, go to *Agent Policies* and click on the *{ecloud} agent policy*.
+
[role="screenshot"]
image::images/fleet-policy-page.png[Fleet Policy Page]

. Click the *Settings* tab and notice that Agent monitoring is
off by default.

. Under *Agent monitoring*, select *Collect agent logs* and
*Collect agent metrics*.
+
--
[role="screenshot"]
image::images/elastic-cloud-agent-policy-page.png[{ecloud} Policy Page]

The agent will now be able to collect logs and metrics from the {fleet-server}.

NOTE: The {fleet-server} is deployed as yet another agent in the system.
--

. Next, set the *Default namespace*.
+
Setting the default namespace lets you segregate {fleet-server} monitoring data
from other collected data. This makes it easier to search and visualize the
monitoring data. By default the monitoring data is sent to the *default*
namespace.

. To confirm your change, click *Save changes*.

To see the metrics collected for {fleet-server}, go to *Analytics > Discover*.

In the following example, `fleetserver` was configured as the namespace, and
you can see the metrics collected:

[role="screenshot"]
image::images/dashboard-with-namespace-showing.png[Namespace]

[role="screenshot"]
image::images/datastream-namespace.png[Datastream]

In {kib}, go to *Analytics > Dashboard* and search for the predefined dashboard
called *[Elastic Agent] Agent metrics*. Choose this dashboard, and run a query
based on the `fleetserver` namespace.

The following dashboard shows data for the query `data_stream.namespace:
"fleetserver"`. In this example, you can observe CPU and memory usage as a
metric and then resize the {fleet-server}, if necessary.

[role="screenshot"]
image::images/dashboard-datastream.png[Dashboard Datastream]

Note that as an alternative to running the query, you can hide all metrics
except `fleet_server` in the dashboard.

Loading