Authored by @Ying Mo, @Hanqing Zhao, @JINSONG WANG, @Paras Kampasi

If you operate more than a handful of OpenTelemetry Collectors, "SSH into the box and edit YAML" stops scaling quickly. Instana's Fleet Management for OpenTelemetry Collectors uses the Open Agent Management Protocol (OpAMP) to give you a control-plane experience for your collector fleet: visibility, remote configuration, and lifecycle actions from the UI.

This feature reached general availability (GA) in February 2026.

This post is a quick, practical guide that assumes you already understand OpenTelemetry (OTel) basics and just want collector fleet management working.

What OpAMP brings

OpAMP is an open standard that lets you manage OTel Collectors centrally, so you can see their status, push configuration updates, trigger actions like restart, and so on.

Below is a list of actions supported by Instana's Fleet Management for OpenTelemetry Collectors:

• Status reporting (version, OS, health, capabilities)
• Remote configuration updates (centrally proposes a config; collectors acknowledge and report applied/failed status)
• Agent lifecycle operations (for example, restart, change log level)

How Instana manages your OTel collectors

In the Instana Distribution of OpenTelemetry Collector (IDOT) setup, a client-side component called the supervisor handles collector fleet management. It maintains the OpAMP connection to Instana, receives remote configuration updates and lifecycle commands, and applies them locally by managing the collector process.

Note: Telemetry reporting is independent of collector fleet management. IDOT can send OTel data to Instana either directly or via an Instana agent, regardless of whether collector fleet management is enabled. See Sending OpenTelemetry data to Instana.

Prerequisites

1) Collector prerequisites

• Use IDOT version 1.305+ (1.310+ recommended).
• Ensure the IDOT supervisor is enabled (see "Install or upgrade IDOT and enable the supervisor" below).

2) Instana prerequisites

• Instana SaaS: Collector fleet management is available by default.
• Self-hosted Instana: Collector fleet management support must be enabled via the feature flag feature.opamp.enabled=true.

For self-hosted enablement steps and prerequisites, see the Centralized OpenTelemetry Collector management documentation.

3) Network prerequisites

Your collectors (or the supervisor) need outbound access to the OpAMP endpoint.

• SaaS (WebSocket over TLS): wss://opamp-<region>-saas.instana.io:443/v1/opamp (where <region> is blue, red, green, etc.)
• Self-hosted (WebSocket over TLS): wss://opamp-acceptor.<your-instana-base-domain>:443/v1/opamp

Step 1: Install or upgrade IDOT and enable the supervisor

Collector fleet management features (restart, remote config editing, log level change, real-time logs) require the supervisor, so enable it during installation.

If you're installing IDOT with the installer script, enable the supervisor at install time:

sudo ./instana_otelcol_setup.sh \
  -e <INSTANA_OTEL_ENDPOINT_GRPC> \
  -a <INSTANA_KEY> \
  -H <INSTANA_OTEL_ENDPOINT_HTTP> \
  -u true

Then check the supervisor status (it manages the collector process):

cd /opt/instana/collector/bin
./instana_supervisor_service.sh status

Note: when the supervisor is enabled, avoid using service instana-collector stop/start for lifecycle operations. The supervisor monitors the collector and can restart it, so stopping the collector service directly often won't have the intended effect.

For install/upgrade details and platform-specific notes, refer to:

• Instana Distribution of OpenTelemetry Collector Overview

Step 2: Find your collectors in Instana

1. In the Instana UI, go to the Agents & collectors page.
2. Open the OpenTelemetry Collectors tab.
3. Select a collector to open its dashboard.

At this point, you should see fleet-level health and per-collector internal metrics.

Step 3: Use collector fleet management (day-2 operations)

Once a collector is connected via the supervisor, Instana can drive common operational tasks from the UI:

• Restart a collector remotely
• Edit collector configuration (with validation)
• Change log level dynamically (DEBUG, INFO, WARN, ERROR)
• Stream real-time logs for faster debugging

Tip: Use log level changes + live logs as a lightweight "debug session" instead of logging into the host.

A common use case: Debug a processor that mutates tags

Imagine this situation:

After a collector config change rollout on Linux hosts, telemetry is flowing and the collector remains healthy/visible in Instana, but your custom "ownership/routing" tags look wrong (for example, tags like team, tenant, cost_center, or env not being added, or get overwritten), which breaks how you scope dashboards and alerts by team, tenant, and environment.

You have 20+ collectors across environments.

You suspect a processor (for example, attributes, resource, or transform) is rewriting or deleting those resource attributes/tags, and you want to confirm and fix it without host access.

Without collector fleet management, you often end up chasing Linux hosts (SSH), locating the right config, updating YAML carefully, restarting processes, and hoping you touched the right instance.

With OpAMP + the supervisor, you can typically work the problem from Instana in a repeatable flow:

1. Select the affected collector(s) in Agents & collectors → OpenTelemetry Collectors.
2. Get quick state + context: version, health, and recent signals tell you whether this is isolated or fleet-wide.
3. Temporarily change log level to DEBUG to capture more detailed diagnostic information about what the pipeline is doing.
4. Stream real-time logs to confirm whether a processor rule is mutating attributes (rewrite/delete) in a way that breaks your tagging strategy (for example, team, tenant, and environment not present where you expect).
5. Apply a configuration update from the UI (with auto-validation) to fix the processor rule.
6. Verify the tags look correct again in Instana, then revert log level to INFO.

Troubleshooting (common issues)

• Collector not visible in UI:
  • Ensure the collector's entity.type resource attribute is set (Instana uses it to identify/list OTel collectors). See Troubleshooting the Instana Distribution of OpenTelemetry Collector.
  • Verify it's exporting to Instana (this is a collector reporting issue regardless of whether the supervisor is running):
    • If the collector reports directly to Instana SaaS, ensure TLS is properly configured:

      tls:
        insecure: false

    • If the collector reports to self-hosted Instana with a private CA certificate: prefer setting up the CA (see CA setup), or use a documented "skip verify" approach where acceptable, for example:

      tls:
        insecure: false
        insecure_skip_verify: true

• Collector is visible, but collector fleet management isn't working, for example: the Restart button doesn't work or the logs section is missing:
  • Verify the supervisor is running and has no failures/errors:

    Navigate to the IDOT installation directory, then check the supervisor status:

    cd /opt/instana/collector/bin
    ./instana_supervisor_service.sh status

These are two common issues. For more information, see Troubleshooting the Instana Distribution of OpenTelemetry Collector.

Get started today

Instana's Fleet Management for OpenTelemetry Collectors eliminates the operational overhead of managing distributed OTel collectors. Start with a few collectors to experience the workflow, then scale to your entire fleet. The combination of remote configuration, lifecycle management, and real-time debugging capabilities transforms how you operate collectors at scale.

Where to learn more

• OpAMP specification: https://opentelemetry.io/docs/specs/opamp/
• OTel Collector management overview: https://opentelemetry.io/docs/collector/management/

#OpenTelemetry