Configuration strategies

Fleet Management gives you flexibility in how you balance local and remote configuration. You don’t have to go all-in on either approach. Choose the strategy that fits your situation.

Remote-first

Minimal local config, everything else managed remotely. Best when a dedicated team manages observability and you want maximum central control over the fleet.

remotecfg {
    url = "https://..."
    // ... auth config
    id = constants.hostname
    attributes = {"env" = "prod"}
}

// Everything else comes from Fleet Management

Local-first

Primary config stays local, Fleet Management for self-monitoring. Best when your main configuration is already managed through an existing deployment process and you want Fleet Management mainly for collector health.

// Local config: full configuration
remotecfg {
    url = "https://..."
    id = constants.hostname
    attributes = {"env" = "prod"}
}

// All your standard collection is here
prometheus.scrape "node" { /* ... */ }
prometheus.scrape "app" { /* ... */ }
loki.source.file "logs" { /* ... */ }

// Fleet Management used only for collector self-monitoring

Hybrid

Top-level config blocks stay local. Everything else is remote. Best when some configuration must stay local but your needs vary by environment, so the rest is easier to manage remotely.

// Local config: top-level blocks
logging { level = "info" }

livedebugging { enabled = true }

remotecfg {
    url = "https://..."
    id = constants.hostname
    attributes = {"env" = "prod"}
}

// All other config managed remotely in Fleet Management

Before you dive into the hands-on learning path, let’s talk about strategy. Fleet Management gives you flexibility in how you balance local and remote configuration, and choosing the right approach depends on your situation. Understanding these strategies will give you context for why the attributes categorization you’re about to do matters so much.

The first strategy is remote-first. You put minimal config in local files (just the remotecfg block) and manage everything else through Fleet Management. This maximizes central control and makes it easy to update configs across your fleet. It’s great when you have a dedicated team managing observability.

The second strategy is local-first with remote self-monitoring. You keep your primary configuration in local files, managed through your existing deployment process. Fleet Management is used for monitoring collector health using their internal telemetry.

The third strategy is hybrid. Configuration that needs to stay local, does. Everything else goes remote because it’s easier to update. If your observability needs vary depending on the environment, a hybrid approach can help.

Whatever strategy you choose, remember that local and remote configurations run in parallel and are isolated from each other. A bug in a remote pipeline won’t break your local config.

Configuration strategies