Skip to content

Manage Elastic Agents with Fleet

The managed platform uses an OpenTelemetry-first observability architecture.

For new observability workloads:

  • OpenTelemetry is the standard telemetry model for logs, metrics, and traces;
  • Elastic Agent is the standard collection and telemetry gateway layer;
  • Fleet centrally manages Elastic Agents, policies, and integrations;
  • Elasticsearch stores and analyzes the resulting telemetry;
  • Kibana provides visualization, investigation, and observability workflows.
Applications / Hosts / Kubernetes / Azure Services
                         ↓
                    Elastic Agent
                         ↓
             OpenTelemetry integrations
                         ↓
        OpenTelemetry logs, metrics, traces
                         ↓
                    Elasticsearch
                         ↓
                       Kibana

The goal is to normalize observability data around OpenTelemetry semantic conventions and OTel-native data streams regardless of where the telemetry originates.

OpenTelemetry is the common telemetry model

Logs, metrics, and traces should use OpenTelemetry conventions wherever supported.

This provides a common representation for telemetry coming from applications, virtual machines, Kubernetes, Azure services, databases, middleware, network and security systems, and custom sources.

Elastic integrations that still produce ECS-compatible events remain supported, but new observability designs should prefer OpenTelemetry-native telemetry where available.

Elastic Agent is the collection layer

Elastic Agent provides the common collection layer for the managed observability platform.

Depending on the workload, Elastic Agent can:

  • receive OTLP telemetry from applications and collectors;
  • collect host logs and metrics;
  • collect Kubernetes telemetry;
  • collect Azure service telemetry;
  • run Elastic integrations;
  • collect custom logs and metrics;
  • enrich telemetry with infrastructure and resource metadata.

The objective is for the resulting observability data to align with OpenTelemetry conventions before it is analyzed in Elasticsearch.

Fleet provides centralized management

Use Fleet in Kibana to manage Elastic Agents centrally.

Fleet manages:

  • agent enrollment;
  • agent policies;
  • OpenTelemetry integrations;
  • Elastic integrations;
  • configuration distribution;
  • agent health;
  • agent versions and upgrades;
  • enrollment and removal.

Avoid manually maintaining local configuration on Fleet-managed agents.

Understand agent policies

Each Fleet-managed Elastic Agent is assigned to an agent policy.

A policy defines the collection and OpenTelemetry configuration applied to a group of agents.

For example:

Kubernetes Policy
 ├─ OpenTelemetry integration
 ├─ Kubernetes telemetry
 ├─ Application OTLP receiver
 └─ Agent monitoring

Linux Server Policy
 ├─ OpenTelemetry integration
 ├─ System logs
 ├─ Host metrics
 └─ Agent monitoring

Multiple agents can share the same policy. Use policies to group systems with similar telemetry requirements.

Configure OpenTelemetry collection

For new observability workloads, first determine which OpenTelemetry signals are required:

  • logs;
  • metrics;
  • traces.

Then configure Elastic Agent to collect or receive those signals.

Application telemetry

Applications instrumented with OpenTelemetry can send OTLP telemetry to an Elastic Agent configured with the appropriate OpenTelemetry integration.

Application
    ↓ OTLP
Elastic Agent
    ↓
Elasticsearch

Kubernetes

Elastic Agent can collect Kubernetes infrastructure telemetry while also receiving OpenTelemetry telemetry from instrumented workloads.

Hosts and virtual machines

Elastic Agent can collect host logs and metrics and normalize them into the observability pipeline.

Azure services

Use supported Elastic Agent integrations to collect Azure telemetry and make it available alongside application and infrastructure telemetry.

Add an OpenTelemetry integration

In Kibana:

  1. Open Fleet.
  2. Open Integrations.
  3. Find the required OpenTelemetry integration.
  4. Configure the required signals and endpoints.
  5. Assign the integration to the appropriate agent policy.
  6. Save the policy.

Fleet distributes the updated configuration to all agents using that policy.

Enroll an Elastic Agent

To add a collector or telemetry gateway:

  1. Open Fleet > Agents.
  2. Select Add agent.
  3. Choose the appropriate agent policy.
  4. Follow the generated installation and enrollment instructions.
  5. Wait for the agent to appear in Fleet.
  6. Confirm that its status becomes Healthy.

Use the Fleet endpoint and enrollment information provided for your deployment. Do not construct endpoints from internal Azure resource names.

Verify OpenTelemetry ingestion

After the agent is healthy, verify that telemetry is reaching Elasticsearch.

Check each signal you expect:

  • logs;
  • metrics;
  • traces.

Also verify important OpenTelemetry metadata such as:

  • service.name;
  • service environment;
  • host attributes;
  • cloud attributes;
  • Kubernetes attributes;
  • resource attributes.

The goal is not only to confirm that events arrive, but also that telemetry from different platforms follows a consistent OpenTelemetry model.

Verify OTel-native data streams

Where OpenTelemetry-native ingestion is used, verify the expected signal-specific data streams.

Typical patterns include:

logs-*.otel-*
metrics-*.otel-*
traces-*.otel-*

ECS-based streams can continue to exist for integrations that require compatibility with existing Elastic content.

Change collection configuration

For a Fleet-managed agent, change telemetry configuration through the agent policy, not by editing local agent configuration.

  1. Open the appropriate policy.
  2. Modify the OpenTelemetry or Elastic integration.
  3. Save the policy.
  4. Wait for Fleet to distribute the update.
  5. Confirm that affected agents return to Healthy.
  6. Verify the resulting telemetry.

A policy change can affect many agents, so confirm the policy scope before applying major changes.

Monitor agent health

Use Fleet > Agents to monitor:

  • agent status;
  • last check-in;
  • policy assignment;
  • agent version;
  • configuration errors;
  • upgrade state.

A healthy agent should regularly check in and report Healthy.

If an agent is healthy but telemetry is missing, investigate the integration and OpenTelemetry pipeline rather than the Fleet connection itself.

Manage agents at scale

Use shared policies for systems with common telemetry requirements, such as:

  • production Kubernetes;
  • development Kubernetes;
  • Linux servers;
  • Windows servers;
  • application telemetry gateways.

Create separate policies when collection requirements are materially different. Avoid unnecessary one-agent policies.

Upgrade Elastic Agents

Fleet can centrally coordinate upgrades for supported Fleet-managed Elastic Agents.

Use a staged approach:

  1. upgrade a representative group;
  2. confirm Fleet health;
  3. verify OpenTelemetry logs, metrics, and traces;
  4. confirm expected data streams and attributes;
  5. continue with the remaining agents.

For Kubernetes deployments where Elastic Agent installation is controlled by GitOps or another deployment system, manage the runtime version through that deployment process while continuing to use Fleet for policies and integrations.

Remove an agent

When an Elastic Agent is no longer required:

  1. confirm the telemetry source is being retired or replaced;
  2. unenroll the agent from Fleet;
  3. remove the agent from the source environment using the supported process.

Existing telemetry remains in Elasticsearch according to its lifecycle and retention configuration.

Troubleshoot OpenTelemetry collection

If an agent cannot connect to Fleet, check:

  • DNS;
  • network connectivity;
  • TLS trust;
  • enrollment configuration.

If the agent is healthy but telemetry is missing, check:

  • the assigned policy;
  • OpenTelemetry integration configuration;
  • OTLP endpoint configuration;
  • application exporter configuration;
  • expected signal type;
  • agent logs;
  • expected OTel-native data streams.

For assistance:

  • AI chat: https://copilot.opsflw.io
  • Support portal: https://support.ivedha.com/

Provide the deployment reference and affected Elastic Agent information. Do not include enrollment tokens, API keys, passwords, or other secrets.

Next step

After Fleet, Elastic Agent, and OpenTelemetry collection are configured, continue with onboard observability data.