feat(agent-config): add logs_enabled master toggle#138
Merged
Conversation
Adds the canonical dd-agent.yaml top-level `logs_enabled: bool` field to the upstream `Config` struct, sourced from `DD_LOGS_ENABLED` (env) and `logs_enabled` (datadog.yaml). Matches dd-agent's pkg/config/config_template.yaml documentation and defaults to `false`. Currently the lambda extension carries this as a source-side alias on its `LambdaConfigSource` that OR-merges into a separate `serverless_logs_enabled` field. Pushing `logs_enabled` upstream means consumers (lambda extension and any future embedder) have a real resolved config field for the canonical dd-agent toggle, instead of synthesizing one.
duncanista
requested review from
Lewis-E and
lym953
and removed request for
a team
Contributor
There was a problem hiding this comment.
Pull request overview
Adds the canonical top-level logs_enabled master toggle to the resolved Config in datadog-agent-config, sourcing it from DD_LOGS_ENABLED (env) and logs_enabled (datadog.yaml) with default false to match dd-agent behavior.
Changes:
- Introduces
Config::logs_enabled: boolwith defaultfalse. - Wires
logs_enabledinto both YAML and env sources viadeserialize_optional_bool_from_anythingand merges into the resolved config. - Extends existing tests and adds env-focused tests for override + default behavior.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| crates/datadog-agent-config/src/sources/yaml.rs | Adds YAML logs_enabled parsing/merge and updates YAML tests/fixtures. |
| crates/datadog-agent-config/src/sources/env.rs | Adds env DD_LOGS_ENABLED parsing/merge and adds tests for env override + default-unset behavior. |
| crates/datadog-agent-config/src/lib.rs | Adds resolved Config::logs_enabled field and default initialization. |
litianningdatadog
approved these changes
Jun 18, 2026
Address Copilot review: in the yaml broken-fallback test, every non-string field is set to an invalid type (e.g. [1, 2, 3]) to exercise graceful fallback to defaults. logs_enabled was inadvertently set to a valid boolean (true), which defeated the test's intent for this new field. Set it to [1, 2, 3] and assert the resolved value stays at the default (false). Now the test fails if graceful-fallback handling for logs_enabled ever regresses.
duncanista
added a commit
to DataDog/datadog-lambda-extension
that referenced
this pull request
Jun 18, 2026
…lias Upstream DataDog/serverless-components#138 landed `Config::logs_enabled` as a top-level field sourced from `DD_LOGS_ENABLED` / `logs_enabled` (yaml), default `false`. Bumps the pin from f76e911 -> 8ce37eb. The lambda extension's existing OR-merge contract is preserved exactly: DD_SERVERLESS_LOGS_ENABLED and DD_LOGS_ENABLED are still OR-merged into config.ext.serverless_logs_enabled, and the default-true is still kept only when neither env var is explicitly set. To do that without losing "was DD_LOGS_ENABLED explicitly set?" information, the alias source field on LambdaConfigSource is retained — the upstream parsing of the same env var into config.logs_enabled is intentional and runs in parallel for non-lambda consumers. Lambda call sites continue to gate log shipping on config.ext.serverless_logs_enabled. No behavior change for customers. Adds a regression test for the "DD_LOGS_ENABLED=false alone disables logs" edge case so a future refactor that breaks it fails loudly.
5 tasks
duncanista
added a commit
to DataDog/datadog-lambda-extension
that referenced
this pull request
Jun 22, 2026
…_enabled) (#1267) ## Summary Bumps the \`datadog-agent-config\` / \`dogstatsd\` / \`datadog-fips\` pin to \`8ce37eb\`, which contains two recently-merged upstream features: - [serverless-components#137](DataDog/serverless-components#137) — adds \`Config::dd_org_uuid: String\` (\`DD_ORG_UUID\` / yaml \`org_uuid\`) - [serverless-components#138](DataDog/serverless-components#138) — adds \`Config::logs_enabled: bool\` (\`DD_LOGS_ENABLED\` / yaml \`logs_enabled\`) ## What changes in bottlecap ### dd_org_uuid Drops the now-redundant local copy from \`LambdaConfig\`: - \`LambdaConfig\`: removed \`dd_org_uuid: String\`. - \`LambdaConfigSource\`: removed \`org_uuid: Option<String>\` and the \`merge_string!(self, dd_org_uuid, source, org_uuid)\` source-to-config renaming call in \`merge_from\`. - Consumers (\`secrets/decrypt.rs\`, \`secrets/delegated_auth/client.rs\`) switch from \`config.ext.dd_org_uuid\` → \`config.dd_org_uuid\`. - Tests assert on the upstream field. ### logs_enabled The lambda extension's existing OR-merge contract for log shipping is preserved **exactly**. The legacy semantics are: | \`DD_SERVERLESS_LOGS_ENABLED\` | \`DD_LOGS_ENABLED\` | resolved \`serverless_logs_enabled\` | |---|---|---| | unset | unset | **true** (default kept) | | any | true | true | | true | any | true | | false | false | false | | **unset** | **false** | **false** (alias alone can override default) | | false | unset | false | To preserve "was \`DD_LOGS_ENABLED\` explicitly set?" the alias source field is **retained** on \`LambdaConfigSource\` and the OR-merge in \`merge_from\` is kept. The upstream parsing of the same env var into \`config.logs_enabled\` runs in parallel — that field exists for any non-lambda consumer of the crate, but the lambda extension continues to gate log shipping on \`config.ext.serverless_logs_enabled\`. A regression test was added for the alias-only-false case (the trickiest invariant), so a future refactor that breaks it fails loudly. ## Why two PRs in one Both upstream PRs are merged and \`8ce37eb\` contains them as a single SHA. Bundling lets us bump once and avoid a transitional state where main is pinned to a SHA that has \`logs_enabled\` upstream but the lambda extension's source field still aliases it. ## Test plan - [x] \`cargo test --workspace --features default\` — all pass (lambda_config_tests now at 40, +2 for the new logs_enabled coverage) - [x] \`cargo clippy --workspace --all-targets --features default\` — clean - [x] \`cargo fmt -- --check\` — clean - [x] Regression test \`logs_enabled_alias_only_false_overrides_default\` exercises the invariant that \`DD_LOGS_ENABLED=false\` alone disables logs (overriding the default-true) - [x] No behavior change for customers — same env vars, same resolved field at lambda call sites
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds the canonical dd-agent.yaml top-level `logs_enabled: bool` field to the upstream `Config` struct, sourced from `DD_LOGS_ENABLED` (env) and `logs_enabled` (datadog.yaml).
Why
The dd-agent template (config_template.yaml:1215-1219) documents `logs_enabled` / `DD_LOGS_ENABLED` as the master toggle for log collection. The upstream Rust crate has scoped variants (`observability_pipelines_worker_logs_enabled`, `otlp_config_logs_enabled`) but not the canonical top-level switch.
Today `datadog-lambda-extension` works around this by carrying `logs_enabled` as a source-side alias on its `LambdaConfigSource` that OR-merges into a separate `serverless_logs_enabled` field. With the toggle upstream, the extension (and any future embedder) gets a real resolved config field instead of a synthesized one. The lambda extension will keep `serverless_logs_enabled` for backwards compatibility with `DD_SERVERLESS_LOGS_ENABLED`, but call sites can check both fields directly.
Behavior
Test plan
Follow-up
Once this lands and is pinned in `datadog-lambda-extension`, the extension can: