Movatterモバイル変換

[0]ホーム
URL:

Loading
  1. Elastic Docs/
  2. Reference/
  3. Ingestion tools/
  4. Fleet and Elastic Agent/
  5. Manage Elastic Agents in Fleet/
  6. Elastic Agents

Migrate Fleet-managed Elastic Agents from one cluster to another

There are situations where you may need to move your installed Elastic Agents from being managed in one cluster to being managed in another cluster.

For a seamless migration, we advise that you create an identical agent policy in the new cluster that is configured in the same manner as the original cluster. There are a few methods to do this.

This guide takes you through the steps to migrate your Elastic Agents by snapshotting a source cluster and restoring it on a target cluster. These instructions assume that you have an Elastic Cloud deployment, but they can be applied to on-premise clusters as well.

Refer to the fullSnapshot and restore documentation for full details. In short, to create a new snapshot in an Elastic Cloud deployment:

  1. In Kibana, open the main menu, then clickManage this deployment.

  2. In the deployment menu, selectSnapshots.

  3. ClickTake snapshot now.

    Deployments Snapshots page

You can create a new cluster based on the snapshot taken in the previous step, and then migrate your Elastic Agents and Fleet to the new cluster. For best results, it’s recommended that the new target cluster be at the same version as the cluster that the agents are migrating from.

  1. Open the Elastic Cloud console and selectCreate deployment.

  2. SelectRestore snapshot data.

  3. In theRestore from field, select your source deployment.

  4. Choose your deployment settings, and, optimally, choose the same Elastic Stack version as the source cluster.

  5. ClickCreate deployment.

    Create a deployment page

Update settings in the target cluster

When the target cluster is available you’ll need to adjust a few settings. Take some time to examine the Fleet setup in the new cluster.

  1. Open the Kibana menu and selectFleet.

  2. On theAgents tab, your agents should visible, however they’ll appear asOffline. This is because these agents have not yet enrolled in the new, target cluster, and are still enrolled in the original, source cluster.

    Agents tab in Fleet showing offline agents

  • Open the FleetSettings tab.

  • Examine the configurations captured there for Fleet. These settings are copied from the snapshot of the source cluster and may not have a meaning in the target cluster, so they need to be modified accordingly.

    In the following example, both theFleet server hosts and theOutputs settings are copied over from the source cluster:

    Settings tab in Fleet showing source deployment host and output settings
    ×Settings tab in Fleet showing source deployment host and output settings

    • The next steps explain how to obtain the relevant Fleet Server host and Elasticsearch output details applicable to the new target cluster in Elastic Cloud.

    Modify the Elasticsearch output

    1. In the new target cluster on Elastic Cloud, in theOutputs section, on the FleetSettings tab, you will find an internal output namedElastic Cloud internal output. The host address is in the form:

      https://<cluster-id-target>.containerhost:9244

      Record this<cluster-id-target> from the target cluster. In the example shown, the ID isfcccb85b651e452aa28703a59aea9b00.

    2. Also in theOutputs section, notice that the default Elasticsearch output (that was copied over from the source cluster) is also in the form:

      https://<cluster-id-source>.<cloud endpoint address>:443.

      Modify the Elasticsearch output so that the cluster ID is the same as that forElastic Cloud internal output. In this example we also rename the output toNew Elasticsearch.

      Outputs section showing the new Elasticsearch host setting
      ×Outputs section showing the new Elasticsearch host setting

    In this example, theNew Elasticsearch output and theElastic Cloud internal output now have the same cluster ID, namelyfcccb85b651e452aa28703a59aea9b00.

    You have now created an Elasticsearch output that agents can use to write data to the new, target cluster. For on-premise environments not using Elastic Cloud, you should similarly be able to use the host address of the new cluster.

    Modify the Fleet Server host

    Like the Elasticsearch host, the Fleet Server host has also changed with the new target cluster. If you're deploying Fleet Server on premise, the host has probably not changed address and this setting does not need to be modified. We still recommend that you ensure the agents are able to reach the the on-premise Fleet Server host (which they should be able to as they were able to connect to it prior to the migration).

    The Elastic Cloud Fleet Server host has a similar format to the Elasticsearch output:

    https://<deployment-id>.fleet.<domain>.io

    To configure the correct Elastic Cloud Fleet Server host you will need to find the target cluster’s fulldeployment-id, and use it to replace the originaldeployment-id that was copied over from the source cluster.

    The easiest way to find thedeployment-id is from the deployment URL:

    1. From the Kibana menu selectManage this deployment.

    2. Copy the deployment ID from the URL in your browser’s address bar.

      Deployment management page
      ×Deployment management page

      In this example, the new deployment ID iseed4ae8e2b604fae8f8d515479a16b7b.

      Using that value fordeployment-id, the new Fleet Server host URL is:

      https://eed4ae8e2b604fae8f8d515479a16b7b.fleet.us-central1.gcp.cloud.es.io:443

    3. In the target cluster, underFleet server hosts, replace the original host URL with the new value.

      Fleet server hosts showing the new host URL
      ×Fleet server hosts showing the new host URL

    Reset the Elastic Cloud policy

    On your target cluster, certain settings from the original Elastic Cloud Elastic Agent policiy may still be retained, and need to be updated to reference the new cluster. For example, in the APM policy installed to the Elastic Cloud Elastic Agent policy, the original and outdated APM URL is preserved. This can be fixed by running thereset_preconfigured_agent_policies API request. When you reset the policy, all APM Integration settings are reset, including the secret key or any tail-based sampling.

    To reset the Elastic Cloud Elastic Agent policy:

    1. Choose one of the API requests below and submit it through a terminal window.

    Note

    After running the command, a warning message may appear in Fleet indicating that Fleet Server is not healthy. As well, the Elastic Agent associated with the Elastic Cloud agent policy may disappear from the list of agents. To remedy this, you can restart Integrations Server:

    1. From the Kibana menu, selectManage this deployment.
    2. In the deployment menu, selectIntegrations Server.
    3. On theIntegrations Server page, selectForce Restart.

    After the restart, Integrations Server will enroll a new Elastic Agent for the Elastic Cloud agent policy and Fleet Server should return to a healthy state.

    Confirm your policy settings

    Now that the Fleet settings are correctly set up, it pays to ensure that the Elastic Agent policy is also correctly pointing to the correct entities.

    1. In the target cluster, go toFleet → Agent policies.

    2. Select a policy to verify.

    3. Open theSettings tab.

    4. Ensure thatFleet Server,Output for integrations, andOutput for agent monitoring are all set to the newly created entities.

      An agent policy's settings showing the newly created entities
      ×An agent policy's settings showing the newly created entities
    Note

    If you modified the Fleet Server and the output in place these would have been updated accordingly. However if new entities are created, then ensure that the correct ones are referenced here.

    Agent policies in the new target cluster

    By creating the new target cluster from a snapshot, all of your policies should have been created along with all of the agents. These agents will be offline due to the fact that the actual agents are not checking in with the new, target cluster (yet) and are still communicating with the source cluster.

    The agents can now be re-enrolled into these policies and migrated over to the new, target cluster.

    Migrate Elastic Agents to the new target cluster

    Note

    Agents to be migrated cannot be tamper-protected or running as a Fleet Server.

    In order to ensure that all required API keys are correctly created, the agents in your current cluster need to be re-enrolled into the new target cluster.

    This is best performed one policy at a time. For a given policy, you need to capture the enrollment token and the URL for the agent to connect to. You can find these by running the in-product steps to add a new agent.

    1. On the target cluster, openFleet and selectAdd agent.

    2. Select your newly created policy.

    3. In the sectionInstall Elastic Agent on your host, find the sample install command. This contains the details you’ll need to enroll the agents, namely the enrollment token and the Fleet Server URL.

    4. Copy the portion of the install command containing these values. That is,–url=<path> –enrollment-token=<token for the new policy>.

      Install command from the Add Agent UI
      ×Install command from the Add Agent UI

    5. Choose an approach:

      Migrate remote agents directly from the Fleet UI:

      1. In the source cluster, select the agents you want to migrate. Click the three dots next to the agents, and selectMigrate agents.
      2. In the migration dialog, provide the URI and enrollment token you obtained from the target cluster.
      3. Usereplace_token (Optional): When you are migrating a single agent, you can use thereplace_token field to preserve the agent's original ID from the source cluster. This step helps with event matching, but will cause the migration to fail if the target cluster already has an agent with the same ID.

      Run theenroll command on each individual host:

      1. On the host machines where the current agents are installed, enroll the agents again using the URL and enrollment token you obtained from the target cluster:

        sudo elastic-agent enroll --url=<fleet server url> --enrollment-token=<token for the new policy>

        The command output should resemble this:

    1. The agent on each host will now check into the new Fleet Server and appear in the new target cluster. In the source cluster, the agents will go offline as they won’t be sending any check-ins.

      ×
    1. Repeat this procedure for each Elastic Agent policy.
    [8]ページ先頭
    ©2009-2026 Movatter.jp