You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/en/containers/guide/container-discovery-management.md
+12-9Lines changed: 12 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,12 +19,10 @@ By default, the Datadog Agent automatically discovers all containers available.
19
19
20
20
## Container discovery patterns
21
21
22
-
In a containerized environment, you should deploy the Datadog Agent once per host. Each Datadog Agent deployed automatically discovers and monitors all containers on its respective host.
22
+
In a containerized environment, you should deploy the Datadog Agent once per host. Each Datadog Agent deployed automatically discovers and monitors all containers on its respective host. When the logs [`containerCollectAll` option][1] is enabled, the Agent collects logs from all discovered containers.
23
23
24
24
You can adjust the discovery rules for the Agent to restrict metric and log collection. Any containers restricted from metric collection are also restricted for any [Autodiscovery][2]-based Agent integrations.
25
25
26
-
When the logs [`containerCollectAll` option][1] is enabled, the Agent collects logs from all discovered containers. These filtering options do not affect log collection if `containerCollectAll` is not enabled.
27
-
28
26
You can set exceptions in two ways:
29
27
30
28
- Provide environment variables to the Datadog Agent container as an allowlist/blocklist of containers. Recommended if you have a list of container names, images, or namespaces to exclude for the entire cluster.
@@ -267,15 +265,18 @@ Use the defined parameters for the container representation in the table below t
267
265
268
266
### Configuration structure
269
267
270
-
The `cel_workload_exclude` configuration is structured as a list of rule sets joined by logical **ORs**. Each rule set defines the `products` to exclude and the corresponding CEL `rules` to match against containers.
268
+
The `cel_workload_exclude` configuration option is structured as a list of rule sets joined by logical **ORs**. Each rule set defines the `products` to exclude and the corresponding CEL `rules` to match against containers.
271
269
272
270
The `products` field accepts `metrics`, `logs`, and `global` (exclude container from all listed products).
273
271
274
-
If the configuration contains typos or structural errors, the Agent process gracefully crashes to prevent collecting unintended telemetry which could impact billing. Additionally, the CEL compiler performs basic type checking to ensure valid operations on the container attributes.
272
+
<div class="alert alert-danger">
273
+
If the configuration contains structural errors or CEL syntax issues, the Agent exits with an error to prevent collecting unintended telemetry which could impact billing.
274
+
</div>
275
275
276
-
In the example below, metrics and logs are excluded for any `nginx` container running in the `staging` namespace. Additionally, logs are excluded for any container running the `redis` image, **or** any container within a pod that has the annotation `low_priority: "true"`.
276
+
In the example below, metrics and logs are excluded for any container with `nginx` in its name running in the `staging` namespace. Additionally, logs are excluded for any container running the `redis` image, **or** any container within a pod that has the annotation `low_priority: "true"`. This can be done by defining the configuration option directly on the [agent's configuration file][4].
0 commit comments