The install guide provides a working config: one agent task on each Swarm node collects host metrics, container metrics, container logs, and data from instrumented applications. This page shows how to customize it in casting.yaml.
Prerequisites
- Docker Swarm Collection Agent installed with Foundry (see the install guide)
- SigNoz Cloud account or self-hosted SigNoz instance
- A shell on a manager node of the Swarm
- The
casting.yamlandfoundryctlyou installed with
Apply Changes
For each change:
-
Add the section's snippet to
casting.yaml. Foundry already generates the default receivers and processors, so add only what you change. -
Run this from the directory that contains
casting.yamlto apply the change:foundryctl cast -f casting.yamlA changed collector config becomes a new Swarm config, and Swarm replaces the agent's tasks to use it.
-
View the agent's logs to confirm there are no configuration errors:
docker service logs --since 5m signoz_collector-agent -
In SigNoz, confirm data in Infrastructure Monitoring for host metrics, the Docker container metrics dashboard for container metrics, Logs for container logs, and Traces for application traces.
Send Data from Applications to the Collector
Host metrics, container metrics, and container logs flow as soon as the agent is running.
Where and how to send data from your application
To send traces, metrics, and logs from an application, instrument it with OpenTelemetry (language guides), then point it at the agent. For an application that runs as a Swarm service, attach the agent to the application's overlay network as Attach the agent to an overlay network shows, then add this to the application's service in its stack file:
services:
<your-app>:
environment:
OTEL_EXPORTER_OTLP_ENDPOINT: http://signoz_collector-agent:4318
OTEL_SERVICE_NAME: <service-name>Verify these values:
<your-app>: Your application's service in its stack file.<service-name>: The name your application shows under in SigNoz.
The agent's service name balances requests across its tasks on all nodes. For an application on a node outside a container, use http://localhost:4318, and from outside the Swarm, a node's address: every node publishes the agent's ports in host mode. For OTLP over gRPC, set OTEL_EXPORTER_OTLP_PROTOCOL=grpc and port 4317.
Redeploy the application and send it some traffic. Within a minute it shows under Services in SigNoz.
Collect Host Metrics
To collect host metrics every 30s, add this to casting.yaml:
spec:
collector:
spec:
config:
data:
collector/agent/agent.yaml: |
receivers:
hostmetrics:
collection_interval: 30sTo stop a scraper, set it to null under scrapers, for example paging: null.
Exclude filesystem mounts
To stop reporting the filesystem mounted at /mnt/backup, add this to casting.yaml:
spec:
collector:
spec:
config:
data:
collector/agent/agent.yaml: |
receivers:
hostmetrics:
scrapers:
filesystem:
exclude_mount_points:
mount_points:
- /dev/*
- /proc/*
- /sys/*
- /run/*
- /run/credentials/*
- /run/k3s/containerd/*
- /var/lib/docker/*
- /var/lib/containers/storage/*
- /var/lib/kubelet/*
- /snap/*
- ^/mnt/backup$Lists replace, so restate Foundry's ten default entries, the ones above ^/mnt/backup$.
Collect Container Metrics
For the metrics and a dashboard, see Docker Container Metrics.
To collect container metrics every 30s, add this to casting.yaml:
spec:
collector:
spec:
config:
data:
collector/agent/agent.yaml: |
receivers:
docker_stats:
collection_interval: 30sFoundry collects container metrics every 60s by default.
Map container labels to resource attributes
To add the com.example.team container label to container metrics as team, add this to casting.yaml:
spec:
collector:
spec:
config:
data:
collector/agent/agent.yaml: |
receivers:
docker_stats:
container_labels_to_metric_labels:
com.example.team: teamThe map merges, so Foundry's default mappings of the Swarm stack, service, task, and node labels stay.
Exclude containers from metrics
To stop collecting metrics for containers by image, add this to casting.yaml:
spec:
collector:
spec:
config:
data:
collector/agent/agent.yaml: |
receivers:
docker_stats:
excluded_images:
- 'otel/opentelemetry-collector-contrib*'
- /.*pause.*/Entries match the image name exactly, as a glob, or as a regular expression between slashes.
Collect Container Logs
For Docker daemon logs and other log sources, see Collecting Docker Logs.
To keep a container's logs out of the agent's collection, add this to its service in its stack file and redeploy it:
services:
<your-app>:
logging:
driver: localVerify these values:
<your-app>: The service whose logs you keep out.
The agent collects the logs of containers that use the json-file log driver, Docker's default.
Disable Logs Collection
To stop collecting container logs, add this to casting.yaml:
spec:
collector:
spec:
config:
data:
collector/agent/agent.yaml: |
receivers:
filelog: null
service:
pipelines:
logs:
receivers: [otlp/http, otlp/grpc]Lists replace, so the logs pipeline is restated with Foundry's two OTLP receivers.
Resource Detection
To detect only host and Docker attributes on nodes outside AWS, GCP, and Azure, add this to casting.yaml:
spec:
collector:
spec:
config:
data:
collector/agent/agent.yaml: |
processors:
resourcedetection:
detectors: [env, system, docker]Lists replace, so detectors holds only the detectors you list.
Custom resource attributes
To add team=backend to all telemetry, add this to casting.yaml:
spec:
collector:
spec:
env:
OTEL_RESOURCE_ATTRIBUTES: deployment.environment=<your-environment>,team=backendVerify these values:
<your-environment>: Your deployment environment, for examplestagingorproduction.
Scrape Prometheus Metrics from Containers
Every agent task runs the scrape, so SigNoz receives a target's metrics from each node. The agent reaches a target by its service name on an overlay network they share, as Attach the agent to an overlay network shows.
To scrape a Prometheus endpoint every 60s, add this to casting.yaml:
spec:
collector:
spec:
config:
data:
collector/agent/agent.yaml: |
receivers:
prometheus:
config:
scrape_configs:
- job_name: my-app
scrape_interval: 60s
static_configs:
- targets: [my-app:9090]
service:
pipelines:
metrics:
receivers: [otlp/http, otlp/grpc, docker_stats, hostmetrics, prometheus]Lists replace, so the metrics pipeline is restated with Foundry's default receivers.
Tune Batch and Memory Limiter
For sizing guidance, see Collector Configuration Best Practices.
To send larger batches, add this to casting.yaml:
spec:
collector:
spec:
config:
data:
collector/agent/agent.yaml: |
processors:
batch:
send_batch_size: 2000
send_batch_max_size: 4000Foundry's defaults are send_batch_size: 1000, send_batch_max_size: 2048, and timeout: 10s.
Container Memory Limit
To cap the agent's memory at 1 GiB, add this patch to casting.yaml:
spec:
patches:
- target: collectionagent/compose.yaml
operations:
- op: add
path: /services/collector-agent/deploy/resources
value:
limits:
memory: 1GFoundry's memory_limiter processor uses a fixed limit_mib: 4000. Size it to the memory limit with percentages, in the same document:
spec:
collector:
spec:
config:
data:
collector/agent/agent.yaml: |
processors:
memory_limiter:
limit_mib: null
spike_limit_mib: null
limit_percentage: 80
spike_limit_percentage: 25Add Custom Processors to Pipelines
To add a processor to the traces pipeline, add this to casting.yaml:
spec:
collector:
spec:
config:
data:
collector/agent/agent.yaml: |
processors:
attributes/team:
actions:
- key: team
value: platform
action: insert
service:
pipelines:
traces:
processors: [memory_limiter, resourcedetection, attributes/team, batch]Lists replace, so restate Foundry's processors memory_limiter, resourcedetection, and batch, with yours before batch.
Common Deployment Scenarios
Run on the same Swarm as self-hosted SigNoz
Self-hosted SigNoz publishes ports 4317 and 4318 through the Swarm routing mesh on every node, so the agent publishes 14317 and 14318 instead and sends to SigNoz's ingester over the signoz-network overlay network.
To run the agent on a Swarm that runs self-hosted SigNoz, add this to casting.yaml:
metadata:
name: signoz-agent
spec:
collector:
spec:
env:
SIGNOZ_INGESTION_ENDPOINT: http://signoz-ingester:4318
patches:
- target: collectionagent/compose.yaml
operations:
- op: replace
path: /services/collector-agent/ports/0/published
value: 14317
- op: replace
path: /services/collector-agent/ports/1/published
value: 14318
- op: add
path: /services/collector-agent/networks
value: [signoz-network]
- op: add
path: /networks
value:
signoz-network:
external: trueThe agent then runs as signoz-agent_collector-agent in its own stack signoz-agent, the name commands and application endpoints use from then on, and applications on a node send to localhost:14318.
Attach the agent to an overlay network
To attach the agent to an overlay network, add this patch to casting.yaml:
spec:
patches:
- target: collectionagent/compose.yaml
operations:
- op: add
path: /services/collector-agent/networks
value: [<your-overlay-network>]
- op: add
path: /networks
value:
<your-overlay-network>:
external: trueVerify these values:
<your-overlay-network>: The overlay network your application's services use, asdocker network lsshows it.
Migrate to Foundry
If you run the agent as the signoz-collection-agent service with your own config.yaml, move it to Foundry so that casting.yaml holds its whole setup and every change follows Apply Changes.
-
To describe the agent in Foundry, check that every node runs Docker Engine 25.0 or newer, then install foundryctl and create casting.yaml as the install guide shows. On a Swarm that runs self-hosted SigNoz, also add the change in Run on the same Swarm as self-hosted SigNoz.
-
To keep your
config.yamlcustomizations, add them tocasting.yamlunderspec.collector.spec.config.data, keyedcollector/agent/agent.yaml, and your environment variables underspec.collector.spec.env. For example, for container metrics every 10s and ateamresource attribute:spec: collector: spec: env: OTEL_RESOURCE_ATTRIBUTES: deployment.environment=<your-environment>,team=backend config: data: collector/agent/agent.yaml: | receivers: docker_stats: collection_interval: 10sVerify these values:
<your-environment>: Your deployment environment, for examplestagingorproduction.
Foundry merges them over its own config: maps merge and lists replace, so restate whole lists, with Foundry's names
otlp/httpandotlp/grpcfor yourotlpreceiver andotlphttp/signozfor yourotlphttpexporter. -
To free the ports the Foundry agent publishes on every node, remove the old agent's service and leave the rest of the stack
signoz, such as self-hosted SigNoz, running. Run this on a manager node:docker service rm signoz_signoz-collection-agentIf
docker service lslists the old agent assignoz-collection-agent, remove that service instead. -
To deploy the agent with Foundry, run this from the directory that contains
casting.yaml:foundryctl cast -f casting.yamlThen verify the Collection Agent as Step 4 of the install guide shows.
Troubleshooting
Host or container metrics stop after adding a receiver
After a change that adds a receiver to the metrics pipeline, host or container metrics stop arriving in SigNoz.
Cause: the pipeline's receivers list replaces the whole list, so a list without hostmetrics and docker_stats drops them.
Fix: restate every receiver the pipeline still needs, as Scrape Prometheus Metrics from Containers shows, then apply the change as Apply Changes shows.
After the fix, host and container metrics arrive in SigNoz again.
A custom processor has no effect
After a change that adds a processor, its attribute or transformation is missing from the data in SigNoz.
Cause: the processor is defined under processors but not listed in a pipeline's processors.
Fix: list it before batch as Add Custom Processors to Pipelines shows, then apply the change as Apply Changes shows.
After the fix, the attribute or transformation appears on the signal in SigNoz Explorer.