There are various models for setting up {agents} to work with {es}. The recommended approach is to use {fleet}, a web-based UI in Kibana, to centrally manage all of your {agents} and their policies. Using {fleet} requires having an instance of {fleet-server} that acts as the interface between the {fleet} UI and your {agents}.
For an overview of {fleet-server}, including details about how it communicates with {es}, how to ensure high availability, and more, refer to What is {fleet-server}?.
The requirements for setting up {fleet-server} differ, depending on your particular deployment model:
- {serverless-full}
-
In a {serverless-short} environment, {fleet-server} is offered as a service, it is configured and scaled automatically without the need for any user intervention.
- {ess}
-
If you’re running {es} and {kib} hosted on {cloud}/ec-getting-started.html[{ess}], no extra setup is required unless you want to scale your deployment. {ess} runs a hosted version of {integrations-server} that includes {fleet-server}. For details about this deployment model, refer to Deploy on {ecloud}.
- {ess} with {fleet-server} on-premise
-
When you use a hosted {ess} deployment you may still choose to run {fleet-server} on-premise. For details about this deployment model and set up instructions, refer to Deploy {fleet-server} on-premises and {es} on Cloud.
- Docker and Kubernetes
-
You can deploy {fleet}-managed {agent} in Docker or on Kubernetes. Refer to Run {agent} in a container or Run {agent} on Kubernetes managed by {fleet} for all of the configuration instructions. For a Kubernetes install we also have a Helm chart available to simplify the installation. Details for configuring {fleet-server} are included with the {agent} install steps.
- {eck}
-
You can deploy {fleet}-managed {agent} in an {ecloud} Kubernetes environment that provides configuration and management capabilities for the full {stack}. For details, refer to {eck-ref}/k8s-elastic-agent-fleet.html[Run {fleet}-managed {agent} on ECK].
- Self-managed
-
For self-managed deployments, you must install and host {fleet-server} yourself. For details about this deployment model and set up instructions, refer to Deploy on-premises and self-managed.
{fleet-server} is a component that connects {agent}s to {fleet}. It supports many {agent} connections and serves as a control plane for updating agent policies, collecting status information, and coordinating actions across {agent}s. It also provides a scalable architecture. As the size of your agent deployment grows, you can deploy additional {fleet-server}s to manage the increased workload.
-
On-premises {fleet-server} is not currently available for use in an {serverless-full} environment. We recommend using the hosted {fleet-server} that is included and configured automatically in {serverless-short} {observability} and Security projects.
The following diagram shows how {agent}s communicate with {fleet-server} to retrieve agent policies:
-
When a new agent policy is created, the {fleet} UI saves the policy to a {fleet} index in {es}.
-
To enroll in the policy, {agent}s send a request to {fleet-server}, using the enrollment key generated for authentication.
-
{fleet-server} monitors {fleet} indices, picks up the new agent policy from {es}, then ships the policy to all {agent}s enrolled in that policy. {fleet-server} may also write updated policies to the {fleet} index to manage coordination between agents.
-
{agent} uses configuration information in the policy to collect and send data to {es}.
-
{agent} checks in with {fleet-server} for updates, maintaining an open connection.
-
When a policy is updated, {fleet-server} retrieves the updated policy from {es} and sends it to the connected {agent}s.
-
To communicate with {fleet} about the status of {agent}s and the policy rollout, {fleet-server} writes updates to {fleet} indices.
Does {fleet-server} run inside of {agent}?
{fleet-server} is a subprocess that runs inside a deployed {agent}. This means the deployment steps are similar to any {agent}, except that you enroll the agent in a special {fleet-Server} policy. Typically—especially in large-scale deployments—this agent is dedicated to running {fleet-server} as an {agent} communication host and is not configured for data collection.
{fleet-server} uses a service token to communicate with {es}, which contains
a fleet-server service account. Each {fleet-server} can use its own service
token, and you can share it across multiple servers (not recommended). The
advantage of using a separate token for each server is that you can invalidate
each one separately.
You can create a service token by either using the {fleet} UI or the {es} API. For more information, refer to [add-fleet-server-mixed] or [add-fleet-server-on-prem], depending on your deployment model.
{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.
How you handle high-availability, fault-tolerance, and lifecycle management of {fleet-server} depends on the deployment model you use.
To learn more about deploying and scaling {fleet-server}, refer to:
Secrets used to configure {fleet-server} can either be directly specified in configuration or provided through secret files. See [fleet-server-secrets] for more information.