Create a fleet

A fleet is a named group of collectors managed together. There are three fleet types, chosen when you create the fleet:

• A server fleet for collectors on hosts and in containers. Each collector connects to Telflo itself and belongs to a deploy group.
• A Kubernetes bridge fleet, Kubernetes (Operator bridge) in the dialog, for operator-managed collectors in a Kubernetes cluster. One bridge connects to Telflo and manages the cluster's collectors. See Kubernetes fleets.
• A Kubernetes supervisor fleet, Kubernetes (Helm) in the dialog, for supervisor-managed collectors in a Kubernetes cluster, without the Operator. It is available in private preview. See Kubernetes fleets.

A Kubernetes fleet type that is not yet enabled for your account shows a Private Preview badge in the dialog and cannot be selected.

This page covers creating a server fleet. Creating one issues the fleet's install token and a deploy group named Default; you then assign a published configuration version to the group and install collectors from it.

Before you start

Have a configuration with a published version, unless you adopt collectors you already run. Only published versions can be assigned to a deploy group. See Versions & publishing.

Create a fleet

1. Go to Fleet and select New Fleet. The Create a new fleet dialog asks where the collectors will run, in two groups: Hosts & VMs and Kubernetes.
2. Select Linux servers & VMs. The New server fleet dialog opens.
3. Name. Enter a name for the fleet. The name must be unique within your organization.
4. Token expiry. Select how long the fleet's token stays valid: Never, 180 days, 1 year, or 2 years.
5. Select Create fleet.

The fleet opens on its detail page with a Set up this fleet checklist: assign a configuration, install a collector, and wait for the first collector to connect. The checklist tracks each step from the fleet's actual state and disappears once the first collector connects; reopen it later with the Setup guide button in the fleet header.

The fleet starts with one empty deploy group, named Default. A fleet has no configuration of its own: each deploy group holds its assigned configuration version.

Assign a configuration

Deploy groups are managed on the fleet's Deploy Groups tab, where each group appears as a row with Name, Configuration, and Variable Group columns; More opens the group's details, including its collector group ID.

1. Open the fleet and select the Deploy Groups tab.
2. Select Assign on the Default group. The Assign a configuration to Default dialog opens. The checklist's Assign step opens the same dialog.
3. Choose the published configuration and version the group serves.
4. Optionally choose an Assigned variable group. The default is None (org defaults only). See Vault.
5. Select Assign.

Once a group has a configuration, its Assign button becomes Edit, which changes the assigned version, and the row's Install button generates install commands for the group. To run different configurations for different subsets of the fleet, select New deploy group and create more groups. Collectors join a group by name at install time, so a group cannot be renamed after creation. A collector joins the group it was deployed from and keeps that group. Deploy groups can also be created and assigned from the Telflo CLI or the API: telflo deploy --fleet <fleet-id> --config <id> --name <name> creates a group serving the configuration's published version, and telflo fleet deployments <fleet-id> lists a fleet's groups. Creating a group needs a session or a write token; listing works with a read token too.

Volume mounts

A collector installed with the Container image (GHCR) — pull and run platform runs in a container and sees only what is mounted into it. When a group's configuration reads host files with a filelog receiver, or keeps checkpoints and queues with a file_storage extension, declare those paths as volume mounts on the deploy group. The dialog that assigns the configuration holds them.

1. Open the group's Assign or Edit dialog, or New deploy group.
2. Select Installing with Docker? Add volume mounts. The Volume mounts editor appears; a group that already has mounts opens with it visible.
3. Select Add mount, then enter the Host path on the machine and the Mount path inside the container, which follows the host path until you change it. Type offers Directory, DirectoryOrCreate, File, and Socket, a Kubernetes distinction that a Docker install ignores. Leave Read-only on for log collection; turning it off warns that the collector can then modify files on the host.
4. Select Create, Assign, or Save.

Once a published configuration is chosen, the dialog lists every path it reads or writes under Read/write paths, folded by default. The heading carries a count: the number of paths, all mounted once every path has a mount, or, for example, 2 without a volume. The list covers the include and exclude paths of filelog receivers and the directories of file_storage extensions; a glob such as /var/log/app/*.log is listed as its directory, /var/log/app. Components that read the host in other ways, such as hostmetrics, are not listed. With the editor shown, Add mount next to a listed path fills a mount in from it, read-only for a filelog path and read-write for a file_storage directory, and a path is marked Volume mount defined once a mount covers it or a parent directory. Typing in Host path suggests common log locations, such as /var/log, /var/log/journal, and /var/log/pods.

Both paths must be absolute. Clearing Read-only shows a warning that the collector can then modify files on the host; a sensitive host path such as /, /etc, /root, /var/lib/kubelet, or a Docker or containerd socket shows a warning and a risky badge on the mount, but is allowed. A path may contain only letters, digits, ., _, -, and /, with no .. segment; a mount whose path contains anything else is left out of the run command. The Type matters for Kubernetes supervisor fleets, whose deploy groups use the same editor; a Docker install uses only the host path, the mount path, and the read-only flag. Mounts are not shown in the group's More details; open the group's Edit dialog to see them.

Mounts affect the container run command only. Linux bundles, Quick Deploy links, and bare-metal collectors, which read host paths directly, ignore them. See Install collectors.

To adopt collectors you already run instead of assigning a configuration, leave the Default group's configuration empty and install with the Server: Import Configuration target: Telflo imports the YAML the first collector reports when it connects. Only the Default group can adopt an existing collector's configuration; any other group must have a configuration assigned before its Install button is enabled.

Server fleets and Kubernetes supervisor fleets can also be created with telflo fleet create --label <name> --type server-supervisor [--expires-in 180d|1y|2y|never] or through the Telflo API with a write token; creating a fleet this way issues its tokens and reports the token's ID and expiry, not its value, so install collectors with telflo fleet install. See CLI commands and API endpoints.

Install token

Each fleet has an install token that authenticates its collectors. The token is delivered with the fleet's install commands: the container run command and the Quick Deploy command carry it, and for a downloaded bundle you set it on the host as the OPAMP_TOKEN environment variable. The token identifies a collector as belonging to the fleet. It has no expiry, cannot be rotated or revoked from the Tokens tab, and is not affected by token rotation; if it is ever exposed, re-create the fleet. The fleet token collectors use at runtime carries the expiry you chose and can be rotated and revoked from the fleet's Tokens tab. See Tokens & security.

Next steps

Install collectors from a deploy group's Install button. See Install collectors.