---
title: "discovery.dockerswarm | Grafana Alloy documentation"
description: "Learn about discovery.dockerswarm"
---

# `discovery.dockerswarm`

`discovery.dockerswarm` allows you to retrieve scrape targets from [Docker Swarm](https://docs.docker.com/engine/swarm/key-concepts/).

## Usage

Alloy ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```alloy
discovery.dockerswarm "<LABEL>" {
  host = "<DOCKER_DAEMON_HOST>"
  role = "<SWARM_ROLE>"
}
```

## Arguments

You can use the following arguments with `discovery.dockerswarm`:

Expand table

| Name                     | Type                | Description                                                                                                                   | Default | Required |
|--------------------------|---------------------|-------------------------------------------------------------------------------------------------------------------------------|---------|----------|
| `host`                   | `string`            | Address of the Docker daemon.                                                                                                 |         | yes      |
| `role`                   | `string`            | Role of the targets to retrieve. Must be `services`, `tasks`, or `nodes`.                                                     |         | yes      |
| `bearer_token_file`      | `string`            | File containing a bearer token to authenticate with.                                                                          |         | no       |
| `bearer_token`           | `secret`            | Bearer token to authenticate with.                                                                                            |         | no       |
| `enable_http2`           | `bool`              | Whether HTTP2 is supported for requests.                                                                                      | `true`  | no       |
| `follow_redirects`       | `bool`              | Whether redirects returned by the server should be followed.                                                                  | `true`  | no       |
| `http_headers`           | `map(list(secret))` | Custom HTTP headers to be sent along with each request. The map key is the header name.                                       |         | no       |
| `no_proxy`               | `string`            | Comma-separated list of IP addresses, CIDR notations, and domain names to exclude from proxying.                              |         | no       |
| `port`                   | `number`            | The port to scrape metrics from, when `role` is nodes, and for discovered tasks and services that don’t have published ports. | `80`    | no       |
| `proxy_connect_header`   | `map(list(secret))` | Specifies headers to send to proxies during CONNECT requests.                                                                 |         | no       |
| `proxy_from_environment` | `bool`              | Use the proxy URL indicated by environment variables.                                                                         | `false` | no       |
| `proxy_url`              | `string`            | HTTP proxy to send requests through.                                                                                          |         | no       |
| `refresh_interval`       | `duration`          | Interval at which to refresh the list of targets.                                                                             | `"60s"` | no       |

At most, one of the following can be provided:

- \[`authorization`]\[authorization] block
- \[`basic_auth`]\[basic\_auth] block
- [`bearer_token_file`](#arguments) argument
- [`bearer_token`](#arguments) argument
- \[`oauth2`]\[oauth2] block

`no_proxy` can contain IPs, CIDR notations, and domain names. IP and domain names can contain port numbers. `proxy_url` must be configured if `no_proxy` is configured.

`proxy_from_environment` uses the environment variables HTTP\_PROXY, HTTPS\_PROXY, and NO\_PROXY (or the lowercase versions thereof). Requests use the proxy from the environment variable matching their scheme, unless excluded by NO\_PROXY. `proxy_url` and `no_proxy` must not be configured if `proxy_from_environment` is configured.

`proxy_connect_header` should only be configured if `proxy_url` or `proxy_from_environment` are configured.

## Blocks

You can use the following blocks with `discovery.dockerswarm`:

No valid configuration blocks found.

### `authorization`

The `authorization` block configures generic authorization to the endpoint.

Expand table

| Name               | Type     | Description                                | Default | Required |
|--------------------|----------|--------------------------------------------|---------|----------|
| `credentials_file` | `string` | File containing the secret value.          |         | no       |
| `credentials`      | `secret` | Secret value.                              |         | no       |
| `type`             | `string` | Authorization type, for example, “Bearer”. |         | no       |

`credential` and `credentials_file` are mutually exclusive, and only one can be provided inside an `authorization` block.

> Warning
> 
> Using `credentials_file` causes the file to be read on every outgoing request. Use the `local.file` component with the `credentials` attribute instead to avoid unnecessary reads.

### `basic_auth`

The `basic_auth` block configures basic authentication to the endpoint.

Expand table

| Name            | Type     | Description                              | Default | Required |
|-----------------|----------|------------------------------------------|---------|----------|
| `password_file` | `string` | File containing the basic auth password. |         | no       |
| `password`      | `secret` | Basic auth password.                     |         | no       |
| `username`      | `string` | Basic auth username.                     |         | no       |

`password` and `password_file` are mutually exclusive, and only one can be provided inside a `basic_auth` block.

> Warning
> 
> Using `password_file` causes the file to be read on every outgoing request. Use the `local.file` component with the `password` attribute instead to avoid unnecessary reads.

### `filter`

The `filter` block limits the discovery process to a subset of available resources. You can define multiple `filter` blocks within the `discovery.dockerswarm` block. The list of available filters depends on the `role`:

- [nodes filters](https://docs.docker.com/engine/api/v1.40/#operation/NodeList)
- [services filters](https://docs.docker.com/engine/api/v1.40/#operation/ServiceList)
- [tasks filters](https://docs.docker.com/engine/api/v1.40/#operation/TaskList)

You can use the following arguments to configure a filter.

Expand table

| Name     | Type           | Description                                | Default | Required |
|----------|----------------|--------------------------------------------|---------|----------|
| `name`   | `string`       | Name of the filter.                        |         | yes      |
| `values` | `list(string)` | List of values associated with the filter. |         | yes      |

### `oauth2`

The `oauth2` block configures OAuth 2.0 authentication to the endpoint.

Expand table

| Name                     | Type                | Description                                                                                      | Default | Required |
|--------------------------|---------------------|--------------------------------------------------------------------------------------------------|---------|----------|
| `client_id`              | `string`            | OAuth2 client ID.                                                                                |         | no       |
| `client_secret_file`     | `string`            | File containing the OAuth2 client secret.                                                        |         | no       |
| `client_secret`          | `secret`            | OAuth2 client secret.                                                                            |         | no       |
| `endpoint_params`        | `map(string)`       | Optional parameters to append to the token URL.                                                  |         | no       |
| `no_proxy`               | `string`            | Comma-separated list of IP addresses, CIDR notations, and domain names to exclude from proxying. |         | no       |
| `proxy_connect_header`   | `map(list(secret))` | Specifies headers to send to proxies during CONNECT requests.                                    |         | no       |
| `proxy_from_environment` | `bool`              | Use the proxy URL indicated by environment variables.                                            | `false` | no       |
| `proxy_url`              | `string`            | HTTP proxy to send requests through.                                                             |         | no       |
| `scopes`                 | `list(string)`      | List of scopes to authenticate with.                                                             |         | no       |
| `token_url`              | `string`            | URL to fetch the token from.                                                                     |         | no       |

`client_secret` and `client_secret_file` are mutually exclusive, and only one can be provided inside an `oauth2` block.

> Warning
> 
> Using `client_secret_file` causes the file to be read on every outgoing request. Use the `local.file` component with the `client_secret` attribute instead to avoid unnecessary reads.

The `oauth2` block may also contain a separate `tls_config` sub-block.

`no_proxy` can contain IPs, CIDR notations, and domain names. IP and domain names can contain port numbers. `proxy_url` must be configured if `no_proxy` is configured.

`proxy_from_environment` uses the environment variables HTTP\_PROXY, HTTPS\_PROXY, and NO\_PROXY (or the lowercase versions thereof). Requests use the proxy from the environment variable matching their scheme, unless excluded by NO\_PROXY. `proxy_url` and `no_proxy` must not be configured if `proxy_from_environment` is configured.

`proxy_connect_header` should only be configured if `proxy_url` or `proxy_from_environment` are configured.

### `tls_config`

The `tls_config` block configures TLS settings for connecting to the endpoint.

Expand table

| Name                   | Type     | Description                                              | Default | Required |
|------------------------|----------|----------------------------------------------------------|---------|----------|
| `ca_pem`               | `string` | CA PEM-encoded text to validate the server with.         |         | no       |
| `ca_file`              | `string` | CA certificate to validate the server with.              |         | no       |
| `cert_pem`             | `string` | Certificate PEM-encoded text for client authentication.  |         | no       |
| `cert_file`            | `string` | Certificate file for client authentication.              |         | no       |
| `insecure_skip_verify` | `bool`   | Disables validation of the server certificate.           |         | no       |
| `key_file`             | `string` | Key file for client authentication.                      |         | no       |
| `key_pem`              | `secret` | Key PEM-encoded text for client authentication.          |         | no       |
| `min_version`          | `string` | Minimum acceptable TLS version.                          |         | no       |
| `server_name`          | `string` | ServerName extension to indicate the name of the server. |         | no       |

The following pairs of arguments are mutually exclusive and can’t both be set simultaneously:

- `ca_pem` and `ca_file`
- `cert_pem` and `cert_file`
- `key_pem` and `key_file`

When configuring client authentication, both the client certificate (using `cert_pem` or `cert_file`) and the client key (using `key_pem` or `key_file`) must be provided.

When `min_version` isn’t provided, the minimum acceptable TLS version is inherited from Go’s default minimum version, TLS 1.2. If `min_version` is provided, it must be set to one of the following strings:

- `"TLS10"` (TLS 1.0)
- `"TLS11"` (TLS 1.1)
- `"TLS12"` (TLS 1.2)
- `"TLS13"` (TLS 1.3)

## Exported fields

The following fields are exported and can be referenced by other components:

Expand table

| Name      | Type                | Description                               |
|-----------|---------------------|-------------------------------------------|
| `targets` | `list(map(string))` | The set of targets discovered from Swarm. |

## Roles

The `role` attribute decides the role of the targets to retrieve.

### `services`

The `services` role discovers all [Swarm services](https://docs.docker.com/engine/swarm/key-concepts/#services-and-tasks) and exposes their ports as targets. For each published port of a service, a single target is generated. If a service has no published ports, a target per service is created using the `port` attribute defined in the arguments.

Available meta labels:

- `__meta_dockerswarm_network_id`: The ID of the network.
- `__meta_dockerswarm_network_ingress`: Whether the network is ingress.
- `__meta_dockerswarm_network_internal`: Whether the network is internal.
- `__meta_dockerswarm_network_label_<labelname>`: Each label of the network.
- `__meta_dockerswarm_network_name`: The name of the network.
- `__meta_dockerswarm_network_scope`: The scope of the network.
- `__meta_dockerswarm_service_endpoint_port_name`: The name of the endpoint port, if available.
- `__meta_dockerswarm_service_endpoint_port_publish_mode`: The publish mode of the endpoint port.
- `__meta_dockerswarm_service_id`: The ID of the service.
- `__meta_dockerswarm_service_label_<labelname>`: Each label of the service.
- `__meta_dockerswarm_service_mode`: The mode of the service.
- `__meta_dockerswarm_service_name`: The name of the service.
- `__meta_dockerswarm_service_task_container_hostname`: The container hostname of the target, if available.
- `__meta_dockerswarm_service_task_container_image`: The container image of the target.
- `__meta_dockerswarm_service_updating_status`: The status of the service, if available.

### `tasks`

The `tasks` role discovers all [Swarm tasks](https://docs.docker.com/engine/swarm/key-concepts/#services-and-tasks) and exposes their ports as targets. For each published port of a task, a single target is generated. If a task has no published ports, a target per task is created using the `port` attribute defined in the arguments.

Available meta labels:

- `__meta_dockerswarm_container_label_<labelname>`: Each label of the container.
- `__meta_dockerswarm_network_id`: The ID of the network.
- `__meta_dockerswarm_network_ingress`: Whether the network is ingress.
- `__meta_dockerswarm_network_internal`: Whether the network is internal.
- `__meta_dockerswarm_network_label_<labelname>`: Each label of the network.
- `__meta_dockerswarm_network_label`: Each label of the network.
- `__meta_dockerswarm_network_name`: The name of the network.
- `__meta_dockerswarm_network_scope`: The scope of the network.
- `__meta_dockerswarm_node_address`: The address of the node.
- `__meta_dockerswarm_node_availability`: The availability of the node.
- `__meta_dockerswarm_node_hostname`: The hostname of the node.
- `__meta_dockerswarm_node_id`: The ID of the node.
- `__meta_dockerswarm_node_label_<labelname>`: Each label of the node.
- `__meta_dockerswarm_node_platform_architecture`: The architecture of the node.
- `__meta_dockerswarm_node_platform_os`: The operating system of the node.
- `__meta_dockerswarm_node_role`: The role of the node.
- `__meta_dockerswarm_node_status`: The status of the node.
- `__meta_dockerswarm_service_id`: The ID of the service.
- `__meta_dockerswarm_service_label_<labelname>`: Each label of the service.
- `__meta_dockerswarm_service_mode`: The mode of the service.
- `__meta_dockerswarm_service_name`: The name of the service.
- `__meta_dockerswarm_task_container_id`: The container ID of the task.
- `__meta_dockerswarm_task_desired_state`: The desired state of the task.
- `__meta_dockerswarm_task_id`: The ID of the task.
- `__meta_dockerswarm_task_port_publish_mode`: The publish mode of the task port.
- `__meta_dockerswarm_task_slot`: The slot of the task.
- `__meta_dockerswarm_task_state`: The state of the task.

The `__meta_dockerswarm_network_*` meta labels aren’t populated for ports which are published with mode=host.

### `nodes`

The `nodes` role is used to discover [Swarm nodes](https://docs.docker.com/engine/swarm/key-concepts/#nodes).

Available meta labels:

- `__meta_dockerswarm_node_address`: The address of the node.
- `__meta_dockerswarm_node_availability`: The availability of the node.
- `__meta_dockerswarm_node_engine_version`: The version of the node engine.
- `__meta_dockerswarm_node_hostname`: The hostname of the node.
- `__meta_dockerswarm_node_id`: The ID of the node.
- `__meta_dockerswarm_node_label_<labelname>`: Each label of the node.
- `__meta_dockerswarm_node_manager_address`: The address of the manager component of the node.
- `__meta_dockerswarm_node_manager_leader`: The leadership status of the manager component of the node (true or false).
- `__meta_dockerswarm_node_manager_reachability`: The reachability of the manager component of the node.
- `__meta_dockerswarm_node_platform_architecture`: The architecture of the node.
- `__meta_dockerswarm_node_platform_os`: The operating system of the node.
- `__meta_dockerswarm_node_role`: The role of the node.
- `__meta_dockerswarm_node_status`: The status of the node.

## Component health

`discovery.dockerswarm` is only reported as unhealthy when given an invalid configuration. In those cases, exported fields retain their last healthy values.

## Debug information

`discovery.dockerswarm` doesn’t expose any component-specific debug information.

## Debug metrics

`discovery.dockerswarm` doesn’t expose any component-specific debug metrics.

## Example

This example discovers targets from Docker Swarm tasks:

Alloy ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```alloy
discovery.dockerswarm "example" {
  host = "unix:///var/run/docker.sock"
  role = "tasks"

  filter {
    name = "id"
    values = ["0kzzo1i0y4jz6027t0k7aezc7"]
  }

  filter {
    name = "desired-state"
    values = ["running", "accepted"]
  }
}

prometheus.scrape "demo" {
  targets    = discovery.dockerswarm.example.targets
  forward_to = [prometheus.remote_write.demo.receiver]
}

prometheus.remote_write "demo" {
  endpoint {
    url = "<PROMETHEUS_REMOTE_WRITE_URL>"

    basic_auth {
      username = "<USERNAME>"
      password = "<PASSWORD>"
    }
  }
}
```

Replace the following:

- *`<PROMETHEUS_REMOTE_WRITE_URL>`* : The URL of the Prometheus remote\_write-compatible server to send metrics to.
- *`<USERNAME>`* : The username to use for authentication to the `remote_write` API.
- *`<PASSWORD>`* : The password to use for authentication to the `remote_write` API.

## Compatible components

`discovery.dockerswarm` has exports that can be consumed by the following components:

- Components that consume [Targets](../../../compatibility/#targets-consumers)

> Note
> 
> Connecting some components may not be sensible or components may require further configuration to make the connection work correctly. Refer to the linked documentation for more details.