Document Docker autodiscovery with conditions and clarify provider/processor relationship

This issue tracks two related documentation gaps identified during review of #6573.

1. Missing Docker conditions-based autodiscovery page

There is no Docker-specific equivalent of [Conditions based autodiscover](https://www.elastic.co/docs/reference/fleet/conditions-based-autodiscover), which covers the Kubernetes case. The dynamic-input-configuration.md page covers Docker conditions generically, but there's no dedicated how-to showing Docker-specific patterns — for example, using arrayContains(${docker.labels}, ...) to selectively monitor containers by label.

2. Clarify the relationship between the Docker provider and add_docker_metadata

The Docker provider and the add_docker_metadata processor are independent — they run in separate processes (provider inside {{agent}}, processor inside the Beat/OTel collector). The provider resolves variables and renders input configurations (injecting add_fields processors with container metadata); add_docker_metadata is a separate, global processor that {{agent}} always enables across all Beats — it is not part of the input configuration and cannot be configured or influenced by any integration.

This distinction is not currently documented. The existing tip on the add_docker_metadata page ("Inputs that collect logs and metrics use this processor by default") is imprecise as a result.

Note: This global behavior is expected to change in 9.5.0, so it may be worth waiting for that release before updating the tip text.

---

## Elastic Docs AI Scoping 🤖

Docs issue scope

### Summary
The issue requests two documentation improvements identified during PR #6573 review: (1) a Docker-specific conditions-based autodiscovery how-to page similar to the existing Kubernetes page, and (2) clarification of the relationship between the Docker provider (runs in Agent) and the add_docker_metadata processor (runs in Beat/OTel collector). PR #6573 documented the Docker provider configuration and processor fields but did not create the Docker autodiscovery how-to or update the processor tip text.

### Request accuracy
Accurate. The issue correctly identifies two documentation gaps that remain after PR #6573.

### Next action for author
Create a new Docker conditions-based autodiscovery how-to page and update the add_docker_metadata processor tip when 9.5.0 ships.

### Impact: High

### Scope boundary
The generic dynamic-input-configuration.md page already exists and covers conditions syntax. This work is specifically about adding Docker-specific examples and patterns, not rewriting the conditions reference.

### Recommended documentation targets

| Page | URL | Action | Impact | Confidence | Why this page? |
|------|-----|--------|--------|------------|----------------|
| Docker conditions-based autodiscovery | New page | Create new page | High | High | Missing how-to for Docker autodiscovery patterns; direct parallel to existing Kubernetes conditions-based-autodiscover.md |
| dynamic-input-configuration.md | https://www.elastic.co/guide/en/fleet/current/dynamic-input-configuration.html | Review only | Low | High | Generic conditions reference; may benefit from Docker example in conditions section |
| add_docker_metadata-processor.md | https://www.elastic.co/guide/en/fleet/current/add_docker_metadata-processor.html | Update existing page | Medium | High | Tip text needs updating when 9.5.0 ships; existing processor reference page |
| docker-provider.md | https://www.elastic.co/guide/en/fleet/current/docker-provider.html | Review only | Low | High | Provider reference; already updated in PR #6573 |

### Recommendations

1. Create a new **Docker conditions-based autodiscovery** page following the structure of conditions-based-autodiscover.md. Include examples showing how to use `arrayContains(${docker.labels}, ...)` to selectively monitor containers by label, and demonstrate Docker-specific variable usage patterns.
2. Update the tip text on add_docker_metadata-processor.md to clarify that the processor runs in the Beat/OTel collector (separate from the Docker provider in Agent) after 9.5.0 ships and the global processor behavior changes.
3. Optionally add a Docker-specific example to the conditions section of dynamic-input-configuration.md to complement the existing host platform examples.
4. Review docker-provider.md to ensure cross-references to the new Docker autodiscovery page are added.

### Notes

- The new Docker autodiscovery page should be a how-to following the same pattern as the Kubernetes conditions-based-autodiscover.md page, which is a task-oriented page with examples.
- The issue notes that tip text updates should wait for 9.5.0 when global processor behavior changes, so recommendation #2 should be deferred until that release.
- The generic dynamic-input-configuration.md page serves as the conditions reference; the new Docker page would focus on Docker-specific patterns and use cases.
- Navigation and cross-references between docker-provider.md, the new Docker autodiscovery page, and dynamic-input-configuration.md will need attention during implementation.

> Generated by [Issue Scope Analyzer](https://github.com/elastic/docs-content/actions/runs/27210993972) for issue #6797 · ● 642.7K · [◷](https://github.com/search?q=repo%3Aelastic%2Fdocs-content+is%3Aissue+%22gh-aw-workflow-call-id%3A+elastic%2Fdocs-content%2Fgh-aw-docs-issue-scope%22&type=issues)

---

## Elastic Docs AI Scoping 🤖

Docs issue scope

### Summary
The issue requests documentation for Docker conditions-based autodiscovery following the pattern established by conditions-based-autodiscover.md (Kubernetes). PR #6573 documented the Docker provider variables and add_docker_metadata processor fields, establishing the foundation. The user has requested a refined focus on creating the Docker-specific autodiscovery how-to page.

### Request accuracy
Accurate. The Docker provider is documented, but there's no Docker-specific conditions-based autodiscovery how-to showing users patterns like `arrayContains(${docker.labels}, 'monitor')` to selectively monitor containers.

### Next action for author
Create a new Docker conditions-based autodiscovery how-to page in reference/fleet/ that parallels the structure of conditions-based-autodiscover.md.

### Impact: High

### Scope boundary
The generic dynamic-input-configuration.md conditions reference already exists. The Docker provider variables are documented in docker-provider.md. This work is specifically about creating a task-oriented how-to with Docker-specific examples.

### Recommended documentation targets

| Page | URL | Action | Impact | Confidence | Why this page? |
|------|-----|--------|--------|------------|----------------|
| Docker conditions-based autodiscovery | New page in reference/fleet/ | Create new page | High | High | Direct parallel to conditions-based-autodiscover.md; how-to for Docker autodiscovery patterns |
| docker-provider.md | https://www.elastic.co/guide/en/fleet/current/docker-provider.html | Update existing page | Low | High | Add cross-reference to new Docker autodiscovery page |
| dynamic-input-configuration.md | https://www.elastic.co/guide/en/fleet/current/dynamic-input-configuration.html | Review only | Low | Medium | May benefit from a Docker example in the conditions examples section |

### Recommendations

1. **Create docker-conditions-based-autodiscover.md** in reference/fleet/ following the structure of conditions-based-autodiscover.md:
- Introduction explaining Docker autodiscovery with conditions
- Example: Target containers by label using `arrayContains(${docker.labels}, 'monitor')` or specific label values like `${docker.container.labels.com.docker.compose.service} == 'redis'`
- Example: Dynamic log paths for containers using `${docker.container.id}`
- Show how to use `elastic-agent inspect --variables` to debug Docker autodiscovery configurations
- Include example Docker Compose manifests that demonstrate the label-based targeting

2. Add a cross-reference in docker-provider.md pointing users to the new Docker conditions-based autodiscovery page, similar to how kubernetes-provider.md links to conditions-based-autodiscover.md.

3. Optionally add a Docker-specific example to dynamic-input-configuration.md in the conditions examples section, showing `arrayContains(${docker.labels}, 'monitor')`.

### Notes

- Follow the same how-to structure as conditions-based-autodiscover.md: introduction, concrete examples with YAML configurations, generated policy snippets, and debugging guidance.
- The Docker provider exposes `docker.container.labels` as an object with dotted keys (e.g., `${docker.container.labels.com.docker.compose.service}`), while in events the labels are stored with underscores (e.g., `container.labels.com_docker_compose_service`). The new page should clarify this distinction in examples.
- Consider showing both standalone Agent and Fleet-managed Agent scenarios if applicable, though conditions-based-autodiscover.md notes that condition definition is supported in both scenarios.
- The second part of the original issue (clarifying processor/provider relationship and updating add_docker_metadata tip text for 9.5.0) is deferred and can be addressed separately when 9.5.0 ships.

> Generated by [Issue Scope Analyzer](https://github.com/elastic/docs-content/actions/runs/27214373706) for issue #6797 · ● 996.8K · [◷](https://github.com/search?q=repo%3Aelastic%2Fdocs-content+is%3Aissue+%22gh-aw-workflow-call-id%3A+elastic%2Fdocs-content%2Fgh-aw-docs-issue-scope%22&type=issues)