{
  "schemaVersion": 3,
  "dataset": {
    "version": 3,
    "date": "2026-08-13",
    "group": {
      "id": "observability",
      "name": "Observability & Reliability"
    },
    "repository": {
      "id": "datadog-agent",
      "repo": "DataDog/datadog-agent",
      "name": "Datadog Agent",
      "keywords": [
        "Datadog Agent"
      ]
    },
    "context": {
      "repository": "DataDog/datadog-agent",
      "url": "https://github.com/DataDog/datadog-agent",
      "description": "Main repository for Datadog Agent",
      "homepage": "https://docs.datadoghq.com/",
      "language": "Go",
      "topics": [
        "apm-agent",
        "apm-instrumentation",
        "datadog",
        "distributed-tracing",
        "go",
        "logging",
        "metrics",
        "monitoring",
        "observability",
        "open-telemetry",
        "otel",
        "profiling",
        "tracing"
      ],
      "license": "Apache-2.0",
      "defaultBranch": "main",
      "stars": 3701,
      "forks": 1472,
      "openIssues": 704,
      "archived": false,
      "collectedAt": "2026-08-13T18:02:00.791289+00:00"
    },
    "news": {
      "repository": "DataDog/datadog-agent",
      "collectedAt": "2026-08-13T18:02:00.791289+00:00",
      "latestRelease": {
        "repository": "DataDog/datadog-agent",
        "tag": "7.82.1",
        "title": "7.82.1",
        "url": "https://github.com/DataDog/datadog-agent/releases/tag/7.82.1",
        "publishedAt": "2026-08-10T15:37:55Z",
        "notes": "# Agent\r\n\r\n### Prelude\r\n\r\nReleased on: 2026-08-11\r\n\r\n- Please refer to the [7.82.1 tag on integrations-core](https://github.com/DataDog/integrations-core/blob/master/AGENT_CHANGELOG.md#datadog-agent-version-7821) for the list of changes on the Core Checks\r\n\r\n### Bug Fixes\r\n\r\n- Windows: Fixed an issue where an explicit `DDAGENTUSER_KEEP_RIGHTS` or `DDAGENTUSER_NAME` value passed as an install argument to a Fleet Automation-triggered Windows Agent install/upgrade could be silently overridden by a stale fallback value (respectively from the registry and from the running service account).\r\n- Fix an issue where GPU monitoring could trigger a kernel panic on multi-GPU nodes with Hopper/Blackwell GPUs.\r\n\r\n# Datadog Cluster Agent\r\n\r\n### Prelude\r\n\r\nReleased on: 2026-08-11 Pinned to datadog-agent v7.82.1: [CHANGELOG](https://github.com/DataDog/datadog-agent/blob/main/CHANGELOG.rst#7821).\r\n",
        "highlights": [
          "Prelude",
          "Please refer to the 7.82.1 tag on integrations-core for the list of changes on the Core Checks",
          "Bug Fixes",
          "Windows: Fixed an issue where an explicit DDAGENTUSERKEEPRIGHTS or DDAGENTUSERNAME value passed as an install argument to a Fleet Automation-triggered Windows Agent install/upgrade could be silently overridden by a stale fallback value (res",
          "Fix an issue where GPU monitoring could trigger a kernel panic on multi-GPU nodes with Hopper/Blackwell GPUs."
        ],
        "prerelease": false
      },
      "upcoming": [
        {
          "repository": "DataDog/datadog-agent",
          "kind": "milestone",
          "title": "Triage",
          "url": "https://github.com/DataDog/datadog-agent/milestone/22",
          "description": "",
          "progress": 100,
          "openIssues": 8,
          "closedIssues": 2826
        },
        {
          "repository": "DataDog/datadog-agent",
          "kind": "milestone",
          "title": "Release Maintenance",
          "url": "https://github.com/DataDog/datadog-agent/milestone/127",
          "description": "For PRs which aim at fixing release branch pipelines, not tied to a specific Agent release.",
          "progress": 100,
          "openIssues": 0,
          "closedIssues": 46
        },
        {
          "repository": "DataDog/datadog-agent",
          "kind": "milestone",
          "title": "no-mile",
          "url": "https://github.com/DataDog/datadog-agent/milestone/180",
          "progress": 100,
          "openIssues": 0,
          "closedIssues": 17
        }
      ],
      "communityDiscussions": []
    },
    "runs": [
      {
        "collectedAt": "2026-08-13T12:26:38.318Z",
        "since": "2026-08-12T12:26:38.318Z",
        "observedCount": 201,
        "changedCount": 201
      },
      {
        "collectedAt": "2026-08-13T13:48:00.446149Z",
        "since": "2026-08-12T13:48:00.446149Z",
        "observedCount": 199,
        "changedCount": 199
      },
      {
        "collectedAt": "2026-08-13T16:19:22.035158Z",
        "since": "2026-08-12T16:19:22.035158Z",
        "observedCount": 192,
        "changedCount": 83
      },
      {
        "collectedAt": "2026-08-13T17:43:20.785491Z",
        "since": "2026-08-12T17:43:20.785491Z",
        "observedCount": 184,
        "changedCount": 50
      },
      {
        "collectedAt": "2026-08-13T17:47:07.884300Z",
        "since": "2026-08-12T17:47:07.884300Z",
        "observedCount": 185,
        "changedCount": 7
      },
      {
        "collectedAt": "2026-08-13T18:01:55.420671Z",
        "since": "2026-08-12T18:01:55.420671Z",
        "observedCount": 188,
        "changedCount": 22
      }
    ],
    "signals": [
      {
        "id": "github:DataDog/datadog-agent:issue:33469",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "issue",
        "title": "Dependency Dashboard",
        "text": "This issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.<br>[View this repository on the Mend.io Web Portal](https://developer.mend.io/github/DataDog/datadog-agent). ## Deprecations / Replacements > [!WARNING] The following dependencies are either deprecated or have replacements available. | Datasource | Package | Replacement PR? | |------------|------|--------------| | nuget | [xunit](https://redirect.github.com/xunit/xunit) | ![Unavailable](https://img.shields.io/badge/unavailable-orange?style=flat-square) | ## Pending Approval The following branches are pending approval. To create them, click on a checkbox below. - [ ] <!-- approve-branch=renovate/github.com-alecthomas-participle-2.x -->Update module github.com/alecthomas/participle to v2 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-authorization-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/authorization/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-compute-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/compute/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-containerservice-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/containerservice/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-managedidentity-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/managedidentity/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-network-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/network/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-docker-sdk-v4-5.x -->Update module github.com/pulumi/pulumi-docker/sdk/v4 to v5 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-tls-sdk-v4-5.x -->Update module github.com/pulumi/pulumi-tls/sdk/v4 to v5 - [ ] <!-- approve-branch=renovate/github.com-sijms-go-ora-v2-3.x -->Update module github.com/sijms/go-ora/v2 to v3 - [ ] <!-- approve-branch=renovate/gitlab.com-gitlab-org-api-client-go-2.x -->Update module gitlab.com/gitlab-org/api/client-go to v2 - [ ] <!-- approve-branch=renovate/gopkg.in-datadog-dd-trace-go.v1-2.x -->Update module gopkg.in/DataDog/dd-trace-go.v1 to v2 - [ ] <!-- approve-all-pending-prs -->🔐 **Create all pending approval PRs at once** 🔐 ## Rate-Limited The following updates are currently rate-limited. To force their creation now, click on a checkbox below. - [ ] <!-- unlimit-branch=renovate/datadog-dd-apm-library-python-4.x -->Update dependency DataDog/dd-apm-library-python to v4.13.1 - [ ] <!-- unlimit-branch=renovate/linux-images-130715735.x -->Update dependency linux-images to v130715735 - [ ] <!-- unlimit-branch=renovate/linux-images-devcontainer-130715735.x -->Update dependency linux-images-devcontainer to v130715735 - [ ] <!-- unlimit-branch=renovate/windows-images-130715735.x -->Update dependency windows-images to v130715735 - [ ] <!-- unlimit-branch=renovate/github-actions -->Update github-actions (`DataDog/dd-sts-action`, `actions/checkout`, `aws-actions/configure-aws-credentials`, `docker/login-action`, `tcort/github-action-markdown-link-check`) - [ ] <!-- unlimit-branch=renovate/github.com-jarcoal-httpmock-1.x -->Update module github.com/jarcoal/httpmock to v1.4.2 - [ ] <!-- unlimit-branch=renovate/github.com-klauspost-compress-1.x -->Update module github.com/klauspost/compress to v1.19.2 - [ ] <!-- unlimit-branch=renovate/github.com-mattn-go-sqlite3-1.x -->Update module github.com/mattn/go-sqlite3 to v1.14.49 - [ ] <!-- unlimit-branch=renovate/github.com-pierrec-lz4-v4-4.x -->Update module github.com/pierrec/lz4/v4 to v4.1.28 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-random-sdk-v4-4.x -->Update module github.com/pulumi/pulumi-random/sdk/v4 to v4.21.1 - [ ] <!-- unlimit-branch=renovate/github.com-santhosh-tekuri-jsonschema-v6-6.x -->Update module github.com/santhosh-tekuri/jsonschema/v6 to v6.0.3 - [ ] <!-- unlimit-branch=renovate/github.com-vektra-mockery-v3-3.x -->Update module github.com/vektra/mockery/v3 to v3.7.2 - [ ] <!-- unlimit-branch=renovate/go.etcd.io-etcd-client-v2-2.x -->Update module go.etcd.io/etcd/client/v2 to v2.305.33 - [ ] <!-- unlimit-branch=renovate/go.temporal.io-api-1.x -->Update module go.temporal.io/api to v1.63.5 - [ ] <!-- unlimit-branch=renovate/clap-4.x-lockfile -->Update Rust crate clap to v4.6.6 - [ ] <!-- unlimit-branch=renovate/packaging-26.x -->Update dependency packaging to v26.3 - [ ] <!-- unlimit-branch=renovate/cloud.google.com-go-compute-1.x -->Update module cloud.google.com/go/compute to v1.65.0 - [ ] <!-- unlimit-branch=renovate/code.cloudfoundry.org-lager-v3-3.x -->Update module code.cloudfoundry.org/lager/v3 to v3.81.0 - [ ] <!-- unlimit-branch=renovate/github.com-apache-arrow-go-v18-18.x -->Update module github.com/apache/arrow-go/v18 to v18.7.0 - [ ] <!-- unlimit-branch=renovate/github.com-aquasecurity-trivy-0.x -->Update module github.com/aquasecurity/trivy to v0.73.0 - [ ] <!-- unlimit-branch=renovate/github.com-containerd-containerd-v2-2.x -->Update module github.com/containerd/containerd/v2 to v2.3.3 - [ ] <!-- unlimit-branch=renovate/github.com-datadog-dd-trace-go-contrib-net-http-v2-2.x -->Update module github.com/DataDog/dd-trace-go/contrib/net/http/v2 to v2.9.1 - [ ] <!-- unlimit-branch=renovate/github.com-datadog-orchestrion-1.x -->Update module github.com/DataDog/orchestrion to v1.12.0 - [ ] <!-- unlimit-branch=renovate/github.com-docker-cli-29.x -->Update module github.com/docker/cli to v29.7.2+incompatible - [ ] <!-- unlimit-branch=renovate/github.com-envoyproxy-gateway-1.x -->Update module github.com/envoyproxy/gateway to v1.8.3 - [ ] <!-- unlimit-branch=renovate/github.com-google-cel-go-0.x -->Update module github.com/google/cel-go to v0.30.0 - [ ] <!-- unlimit-branch=renovate/github.com-open-policy-agent-opa-1.x -->Update module github.com/open-policy-agent/opa to v1.19.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-aws-sdk-v7-7.x -->Update module github.com/pulumi/pulumi-aws/sdk/v7 to v7.40.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-awsx-sdk-v3-3.x -->Update module github.com/pulumi/pulumi-awsx/sdk/v3 to v3.8.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-eks-sdk-v4-4.x -->Update module github.com/pulumi/pulumi-eks/sdk/v4 to v4.3.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-gcp-sdk-v9-9.x -->Update module github.com/pulumi/pulumi-gcp/sdk/v9 to v9.33.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-sdk-v3-3.x -->Update module github.com/pulumi/pulumi/sdk/v3 to v3.256.0 - [ ] <!-- unlimit-branch=renovate/github.com-rabbitmq-amqp091-go-1.x -->Update module github.com/rabbitmq/amqp091-go to v1.13.0 - [ ] <!-- unlimit-branch=renovate/github.com-redis-go-redis-v9-9.x -->Update module github.com/redis/go-redis/v9 to v9.22.0 - [ ] <!-- unlimit-branch=renovate/go.temporal.io-sdk-1.x -->Update module go.temporal.io/sdk to v1.47.0 - [ ] <!-- unlimit-branch=renovate/sigs.k8s.io-gateway-api-1.x -->Update module sigs.k8s.io/gateway-api to v1.6.1 - [ ] <!-- unlimit-branch=renovate/redis-7.x -->Update redis Docker tag to v7.4 - [ ] <!-- unlimit-branch=renovate/confluentinc-cp-kafka-8.x -->Update confluentinc/cp-kafka Docker tag to v8 - [ ] <!-- unlimit-branch=renovate/major-github-actions -->Update github-actions (major) (`actions/cache`, `actions/labeler`, `actions/setup-go`, `actions/setup-node`, `actions/setup-python`, `actions/stale`, `slackapi/slack-github-action`) - [ ] <!-- unlimit-branch=renovate/postgres-17.x -->Update postgres Docker tag to v17 - [ ] <!-- unlimit-branch=renovate/redis-8.x -->Update redis Docker tag to v8 - [ ] <!-- create-all-rate-limited-prs -->🔐 **Create all rate-limited PRs at once** 🔐 ## Pending Status Checks The following updates await pending status checks. To force their creation now, click on a checkbox below. - [ ] <!-- approvePr-branch=renovate/confluentinc-cp-kafka-7.x -->Update confluentinc/cp-kafka Docker tag to v7.9.9 - [ ] <!-- approvePr-branch=renovate/rules_rs-0.x -->Update dependency rules_rs to v0.0.102 - [ ] <!-- approvePr-branch=renovate/franz-go -->Update module github.com/twmb/franz-go to v1.21.6 - [ ] <!-- approvePr-branch=renovate/google.golang.org-protobuf-1.x -->Update module google.golang.org/protobuf to v1.36.12 - [ ] <!-- approvePr-branch=renovate/dd_sds-0.x -->Update Rust crate dd_sds to v0.1.0-20260813-972b5d8d1827 - [ ] <!-- approvePr-branch=renovate/http-body-util-0.x-lockfile -->Update Rust crate http-body-util to v0.1.5 - [ ] <!-- approvePr-branch=renovate/thiserror-2.x-lockfile -->Update Rust crate thiserror to v2.0.20 - [ ] <!-- approvePr-branch=renovate/hatchling-1.x -->Update dependency hatchling to v1.32.0 - [ ] <!-- approvePr-branch=renovate/azure-sdk-for-go-monorepo -->Update module github.com/Azure/azure-sdk-for-go/sdk/azcore to v1.23.0 - [ ] <!-- approvePr-branch=renovate/github.com-datadog-datadog-api-client-go-v2-2.x -->Update module github.com/DataDog/datadog-api-client-go/v2 to v2.64.0 - [ ] <!-- approvePr-branch=renovate/github.com-sirupsen-logrus-1.x -->Update module github.com/sirupsen/logrus to v1.10.0 - [ ] <!-- approvePr-branch=renovate/public.ecr.aws-docker-library-alpine-3.x -->Update public.ecr.aws/docker/library/alpine Docker tag to v3.24.1 - [ ] <!-- approvePr-branch=renovate/ureq-3.x-lockfile -->Update Rust crate ureq to v3.4.0 - [ ] <!-- approvePr-branch=renovate/npm-sentry-dotagents-3.x -->Update dependency npm:@sentry/dotagents to v3 --- > [!WARNING] > Renovate failed to look up the following dependencies: `Failed to look up go package github.com/vishvananda/netlink: no-result`, `Failed to look up go package github.com/itchyny/gojq: no-result`. > > Files affected: `go.mod`, `pkg/fleet/installer/go.mod`, `pkg/util/jsonquery/go.mod` --- ## Other Branches The following updates are pending. To force the creation of a PR, click on a checkbox below. - [ ] <!-- other-branch=renovate/integrations-core-digest -->Update integrations-core digest to 84ce638 - [ ] <!-- other-branch=renovate/aws-sdk-go-v2 -->Update aws-sdk-go-v2 (`github.com/aws/aws-sdk-go-v2`, `github.com/aws/aws-sdk-go-v2/config`, `github.com/aws/aws-sdk-go-v2/credentials`, `github.com/aws/aws-sdk-go-v2/service/ec2`, `github.com/aws/aws-sdk-go-v2/service/ecr`, `github.com/aws/aws-sdk-go-v2/service/ecs`, `github.com/aws/aws-sdk-go-v2/service/eks`, `github.com/aws/aws-sdk-go-v2/service/rds`, `github.com/aws/aws-sdk-go-v2/service/s3`, `github.com/aws/aws-sdk-go-v2/service/secretsmanager`, `github.com/aws/aws-sdk-go-v2/service/ssm`, `github.com/aws/aws-sdk-go-v2/service/sts`) - [ ] <!-- other-branch=renovate/github.com-go-delve-delve-1.x -->Update module github.com/go-delve/delve to v1.27.1 - [ ] <!-- other-branch=renovate/github.com-google-go-containerregistry-0.x -->Update module github.com/google/go-containerregistry to v0.21.9 ## Open The following updates have all been created. To force a retry/rebase of any, click on a checkbox below. - [ ] <!-- rebase-branch=renovate/go-github.com-datadog-dd-trace-go-v2-vulnerability -->[Update module github.com/DataDog/dd-trace-go/v2 to v2.8.1 [SECURITY]](../pull/53708) - [ ] <!-- rebase-branch=renovate/datadog-datadog-agent-dev-0.x -->[Update dependency DataDog/datadog-agent-dev to v0.38.0](../pull/52555) - [ ] <!-- rebase-branch=renovate/sentry-dotagents-3.x -->[Update dependency @sentry/dotagents to v3](../pull/54802) - [ ] <!-- rebase-branch=renovate/github.com-datadog-dd-trace-go-v2-2.x -->[Update module github.com/DataDog/dd-trace-go/v2 to v2.9.1](../pull/52521) - [ ] <!-- rebase-branch=renovate/gawk-5.x -->[Update dependency gawk to v5.4.0](../pull/52963) - [ ] <!-- rebase-branch=renovate/kubernetes-monorepo -->[Update kubernetes monorepo to v0.36.3](../pull/51833) (`k8s.io/api`, `k8s.io/apiextensions-apiserver`, `k8s.io/apimachinery`, `k8s.io/cli-runtime`, `k8s.io/client-go`, `k8s.io/component-base`, `k8s.io/cri-api`, `k8s.io/cri-client`, `k8s.io/kube-aggregator`, `k8s.io/kubectl`, `k8s.io/kubelet`, `k8s.io/metrics`) - [ ] <!-- rebase-branch=renovate/github.com-godror-godror-0.x -->[Update module github.com/godror/godror to v0.51.0](../pull/53235) - [ ] <!-- rebase-branch=renovate/k8s.io-autoscaler-vertical-pod-autoscaler-1.x -->[Update module k8s.io/autoscaler/vertical-pod-autoscaler to v1.7.1](../pull/51852) - [ ] <!-- rebase-branch=renovate/k8s.io-kube-state-metrics-v2-2.x -->[Update module k8s.io/kube-state-metrics/v2 to v2.19.1](../pull/52895) - [ ] <!-- rebase-branch=renovate/sigs.k8s.io-custom-metrics-apiserver-1.x -->[Update module sigs.k8s.io/custom-metrics-apiserver to v1.36.0](../pull/52282) - [ ] <!-- rebase-branch=renovate/docker.io-library-ubuntu-26.x -->[Update docker.io/library/ubuntu Docker tag to v26](../pull/52153) - [ ] <!-- rebase-branch=renovate/docker.io-ubuntu-26.x -->[Update docker.io/ubuntu Docker tag to v26](../pull/50840) - [ ] <!-- rebase-branch=renovate/github.com-cloudfoundry-community-go-cfclient-v2-3.x -->[Update module github.com/cloudfoundry-community/go-cfclient/v2 to v3](../pull/53622) - [ ] <!-- rebase-branch=renovate/github.com-netsampler-goflow2-2.x -->[Update module github.com/netsampler/goflow2 to v2](../pull/53239) - [ ] <!-- rebase-branch=renovate/major-franz-go -->[Update module github.com/twmb/franz-go/pkg/kmsg to v2](../pull/53824) - [ ] <!-- rebase-all-open-prs -->**Click on this checkbox to rebase all open PRs at once** ## PR Closed (Blocked) The following updates are blocked by an existing closed PR. To recreate the PR, click on a checkbox below. - [ ] <!-- recreate-branch=renovate/rules_go-0.x -->[Update dependency rules_go to v0.62.0](../pull/54068) - [ ] <!-- recreate-branch=renovate/code.cloudfoundry.org-bbs-1.x -->[Update module code.cloudfoundry.org/bbs to v1.11.0](../pull/53818) - [ ] <!-- recreate-branch=renovate/github.com-aws-karpenter-provider-aws-1.x -->[Update module github.com/aws/karpenter-provider-aws to v1.14.0](../pull/53819) - [ ] <!-- recreate-branch=renovate/github.com-bazelbuild-rules_go-0.x -->[Update module github.com/bazelbuild/rules_go to v0.62.0](../pull/54057) - [ ] <!-- recreate-branch=renovate/gopkg.in-datadog-dd-trace-go.v1-1.x -->[Update module gopkg.in/DataDog/dd-trace-go.v1 to v1.74.8](../pull/52894) - [ ] <!-- recreate-branch=renovate/sigs.k8s.io-karpenter-1.x -->[Update module sigs.k8s.io/karpenter to v1.14.0](../pull/53820) - [ ] <!-- recreate-branch=renovate/chef-sugar-5.x -->[Update dependency chef-sugar to v5](../pull/51540) - [ ] <!-- recreate-branch=renovate/invoke-3.x -->[Update dependency invoke to v3](../pull/50838) - [ ] <!-- recreate-branch=renovate/code.cloudfoundry.org-bbs-models-1.x -->[Update module code.cloudfoundry.org/bbs/models to v1](../pull/53823) - [ ] <!-- recreate-branch=renovate/github.com-santhosh-tekuri-jsonschema-v5-6.x -->[Update module github.com/santhosh-tekuri/jsonschema/v5 to v6](../pull/54069) - [ ] <!-- recreate-branch=renovate/go.etcd.io-etcd-client-v2-3.x -->[Update module go.etcd.io/etcd/client/v2 to v3](../pull/53825) - [ ] <!-- recreate-branch=renovate/go.yaml.in-yaml-v2-3.x -->[Update module go.yaml.in/yaml/v2 to v3](../pull/53527) ## Detected Dependencies > [!NOTE] > Detected dependencies section has been truncated <details><summary>bazel-module (2)</summary> <blockquote> <details><summary>deps/repos.MODULE.bazel</summary> </details> <details><summary>MODULE.bazel (20)</summary> - `bazel_lib 3.7.1` - `bazel_skylib 1.9.2` - `gawk 5.3.2.bcr.7` → [Updates: `5.4.0`] - `gazelle 0.52.2` - `libarchive 3.8.1.bcr.2` - `platforms 1.1.0` - `re.bzl 0.3.1` - `rules_cc 0.2.22` - `rules_flex 0.4.1` - `rules_go 0.61.1` → [Updates: `0.62.0`] - `rules_m4 0.3.bcr.1` - `rules_multitool 1.11.1` - `rules_python 2.2.0` - `rules_rs 0.0.27` → [Updates: `0.0.102`] - `rules_rust 0.73.0` - `rules_rust_prost 0.73.0` - `rules_shell 0.8.0` - `toml.bzl 0.4.1` - `rules_testing 0.9.0` - `apple_support 2.8.0` </details> </blockquote> </details> <details><summary>bazelisk (1)</summary> <blockquote> <details><summary>.bazelversion</summary> </details> </blockquote> </details> <details><summary>bitbucket-pipelines (1)</summary> <blockquote> <details><summary>.gitlab/.pre/cancel-prev-pipelines.yml</summary> </details> </blockquote> </details> <details><summary>bundler (1)</summary> <blockquote> <details><summary>omnibus/Gemfile (2)</summary> - `chef-sugar v3.6.0` → [Updates: `v5.1.12`] - `mixlib-cli '~> 2.1.0'` </details> </blockquote> </details> <details><summary>cargo (9)</summary> <blockquote> <details><summary>Cargo.toml (57)</summary> - `anyhow 1.0.98` - `cap-std 4.0` - `dd_sds =0.1.0-20260803-1e4349aada52` → [Updates: `=0.1.0-20260813-972b5d8d1827`] - `caps 0.5` - `chrono 0.4` - `clap 4.5` → [Updates: `4.5`] - `elf 0.8.0` - `glob-match 0.2` - `http-body-util 0.1` → [Updates: `0.1`] - `hostname 0.4` - `hyper 1` - `hyper-util 0.1` - `libc 0.2` - `log 0.4` - `prost 0.14` - `prost-build 0.14` - `prost-types 0.14` - `protoc-gen-prost 0.5` - `protoc-gen-tonic 0.5` - `lru 0.18.0` - `memchr 2.7.6` - `nom 8.0` - `normalize-path 0.2` - `phf 0.14` - `rawzip 0.5.0` - `xml-rs 1.0` - `rmp-serde 1.3` - `serde 1.0.219` - `serde_json 1.0` - `serde_yaml 0.9` - `time 0.3` - `thiserror 2.0.12` → [Updates: `2.0.12`] - `tokio 1` - `tokio-stream 0.1` - `tonic 0.14` - `tonic-build 0.14` - `tonic-prost 0.14` - `tonic-prost-build 0.14` - `tonic-reflection 0.14` - `ureq 3.0` → [Updates: `3.0`] - `uzers 0.12` - `walkdir 2` - `saphyr-parser 0.0.11` - `yaml-rust2 0.11` - `zip 8.0` - `flate2 1.1` - `tower 0.5` - `uuid 1` - `windows-registry 0.6` - `windows-sys 0.61` - `dircpy 0.3.19` - `regex 1` - `memmap2 0.9` - `nix 0.31` - `scopeguard 1.2` - `temp-env 0.3` - `tempfile 3.0` </details> <details><summary>cmd/ai_prompt_logger/Cargo.toml</summary> </details> <details><summary>comp/core/log/rust/Cargo.toml</summary> </details> <details><summary>pkg/collector/sharedlibrary/rustchecks/checks/datasecurity/Cargo.toml (1)</summary> - `postgres 0.19` </details> <details><summary>pkg/collector/sharedlibrary/rustchecks/checks/example/Cargo.toml</summary> </details> <details><summary>pkg/collector/sharedlibrary/rustchecks/core/Cargo.toml</summary> </details> <details><summary>pkg/discovery/module/rust/Cargo.toml</summary> </details> <details><summary>pkg/privateactionrunner/par-control/Cargo.toml</summary> </details> <details><summary>pkg/procmgr/rust/Cargo.toml</summary> </details> </blockquote> </details> <details><summary>docker-compose (36)</summary> <blockquote> <details><summary>cmd/host-profiler/docker-compose.yml (1)</summary> - `registry.datadoghq.com/agent 7` </details> <details><summary>pkg/collector/corechecks/oracle/compose/docker-compose.yml</summary> </details> <details><summary>pkg/discovery/module/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/amqp/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/http/testutil/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/kafka/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/mongo/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/mysql/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/postgres/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/redis/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/tls/gotls/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/tls/nodejs/testdata/docker-compose-ubuntu.yml</summary> </details> <details><summary>pkg/network/protocols/tls/nodejs/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/tracer/testdata/dnsworkload/docker-compose.yml</summary> </details> <details><summary>pkg/network/usm/testdata/bio_leak_test/docker-compose.yml</summary> </details> <details><summary>pkg/network/usm/testdata/musl/docker-compose.yml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/dogstatsd/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/jmxfetch/docker-compose-all-metrics.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/jmxfetch/docker-compose-slow-metrics.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/jmxfetch/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/logger/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/redis/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/integration/etcd/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/integration/kafka/docker-compose.yaml (3)</summary> - `confluentinc/cp-kafka 7.9.8` → [Updates: `7.9.9`, `8.3.0`] - `confluentinc/cp-kafka 7.9.8` → [Updates: `7.9.9`, `8.3.0`] - `confluentinc/cp-kafka 7.9.8` → [Updates: `7.9.9`, `8.3.0`] </details> <details><summary>test/e2e-framework/components/integration/postgres/docker-compose.yaml (2)</summary> - `postgres 16` → [Updates: `17`] - `postgres 16` → [Updates: `17`] </details> <details><summary>test/e2e-framework/components/integration/redisdb/docker-compose.yaml (2)</summary> - `redis 7.2` → [Updates: `7.4`, `8.2`] - `redis 7.2` → [Updates: `7.4`, `8.2`] </details> <details><summary>test/fakeintake/docker-compose.yaml</summary> </details> <details><summary>test/new-e2e/examples/testfixtures/docker-compose.fake-process.yaml</summary> </details> <details><summary>test/new-e2e/examples/testfixtures/docker-compose.lighttpd.yaml</summary> </details> <details><summary>test/new-e2e/tests/agent-health/fixtures/docker-compose.busybox.yaml</summary> </details> <details><summary>test/new-e2e/tests/discovery/testdata/compose/docker-compose.configfilesdiscovery-kafka.yaml</summary> </details> <details><summary>test/new-e2e/tests/discovery/testdata/compose/docker-compose.configfilesdiscovery-redis.yaml</summary> </details> <details><summary>test/new-e2e/tests/discovery/testdata/compose/docker-compose.fake-krakend.yaml</summary> </details> <details><summary>test/new-e2e/tests/fips-compliance/fixtures/docker-compose-cluster-agent.yaml</summary> </details> <details><summary>test/new-e2e/tests/fips-compliance/fixtures/docker-compose-fips-server.yaml</summary> </details> <details><summary>test/new-e2e/tests/fips-compliance/fixtures/docker-compose.yaml</summary> </details> </blockquote> </details> <details><summary>dockerfile (15)</summary> <blockquote> <details><summary>Dockerfiles/agent-ddot/Dockerfile</summary> </details> <details><summary>Dockerfiles/agent-ddot/Dockerfile.agent-otel (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/agent/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/agent/windows/amd64/Dockerfile (1)</summary> - `mcr.microsoft.com/dotnet/sdk 9.0-windowsservercore-ltsc2019` </details> <details><summary>Dockerfiles/base-image/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/cluster-agent/Dockerfile (2)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/ddot-ebpf/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/dogstatsd/alpine/Dockerfile (1)</summary> - `public.ecr.aws/docker/library/alpine 3.23.3` → [Updates: `3.24.1`] </details> <details><summary>Dockerfiles/otel-agent/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>test/e2e-framework/resources/local/podman/data/Dockerfile (1)</summary> - `docker.io/library/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>test/fakeintake/Dockerfile (2)</summary> - `docker.io/library/golang 1.26.5` - `docker.io/library/alpine 3.24.1` </details> <details><summary>tools/ebpf/Dockerfiles/Dockerfile-process-agent-dev</summary> </details> <details><summary>tools/ebpf/Dockerfiles/Dockerfile-security-agent-dev</summary> </details> <details><summary>tools/gdb/Dockerfile (1)</summary> - `registry.datadoghq.com/agent 7` </details> <details><summary>tools/host-profiler/Dockerfile</summary> </details> </blockquote> </details> <details><summary>github-actions (45)</summary> <blockquote> <details><summary>.github/actions/bazel-cache/action.yml (2)</summary> - `actions/cache v6.1.0@55cc8345863c7cc4c66a329aec7e433d2d1c52a9` - `actions/cache v6.1.0@55cc8345863c7cc4c66a329aec7e433d2d1c52a9` </details> <details><summary>.github/actions/deps-tidy-push/action.yml</summary> </details> <details><summary>.github/actions/deps-tidy-setup/action.yml (1)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` </details> <details><summary>.github/actions/install-dda/action.yml (3)</summary> - `actions/cache v6.1.0@55cc8345863c7cc4c66a329aec7e433d2d1c52a9` - `DataDog/datadog-agent-dev install@00e4a423088309efce1d5ba6b8c5366eef648710` - `DataDog/datadog-agent-dev install@00e4a423088309efce1d5ba6b8c5366eef648710` </details> <details><summary>.github/workflows/add-dependabot-pr-to-mq.yml (3)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/add-label-community-pr.yml (2)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/add-label-pr.yml (3)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/add-milestone.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/agenttelemetry-metric-reminder.yml (1)</summary> - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/ask-review.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/assess-permissions.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/assign-issue.yml (1)</summary> - `DataDog/issue-triage-action v1.0.1@b39f0bc12abc52fe8aa70dc9b9353bf307a13219` </details> <details><summary>.github/workflows/backport-pr.yml (4)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/buildimages-update.yml (5)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/chase-for-qa-cards.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/check-issue-status.yml (5)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/check-skip.yml</summary> </details> <details><summary>.github/workflows/cla.yml (2)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `contributor-assistant/github-action v2.6.1@ca4a40a7d1004f18d9960b404b97e5f30a505a08` </details> <details><summary>.github/workflows/code-review-complexity.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/code-review.yml (1)</summary> - `DataDog/code-review-action v1.1.0@56d6862711348b11ec2603edfb29c52c09f4b84c` </details> <details><summary>.github/workflows/codex-review-draft.yml (1)</summary> - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/codex-review-ready-for-review.yml</summary> </details> <details><summary>.github/workflows/collector-generate-and-update.yml (5)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `slackapi/slack-github-action v3.0.5@0d95c9a7becc1e6e297d76df9bc735c44f4cbcbc` → [Updates: `v4.0.0`] </details> <details><summary>.github/workflows/create-rc-pr.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/cws-btfhub-sync.yml (11)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `actions/upload-artifact v7.0.1@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `actions/download-artifact v8.0.1@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c` - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `ubuntu 24.04` - `ubuntu 24.04` </details> <details><summary>.github/workflows/deps-tidy.yml (7)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `dtolnay/rust-toolchain v1@e97e2d8cc328f1b50210efc529dca0028893a2d9` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `rust stable` </details> <details><summary>.github/workflows/do-not-merge.yml</summary> </details> <details><summary>.github/workflows/docs-dev.yml (8)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/upload-artifact v7.0.1@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a` - `actions/download-artifact v8.0.1@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c` - `peaceiris/actions-gh-pages v4.1.0@84c30a85c19949d7eee79c4ff27748b70285e453` </details> <details><summary>.github/workflows/go-update-commenter.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/gohai.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] </details> <details><summary>.github/workflows/label-analysis.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/labeler.yml (1)</summary> - `actions/labeler v6.2.0@b8dd2d9be0f68b860e7dae5dae7d772984eacd6d` → [Updates: `v7.0.0`] </details> <details><summary>.github/workflows/markdown-lint-check.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `tcort/github-action-markdown-link-check v1.1.2@e7c7a18363c842693fadde5d41a3bd3573a7a225` → [Updates: `v1.1.3`] </details> <details><summary>.github/workflows/push-bazel-cache.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/report-merged-pr.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `DataDog/dd-sts-action v1.0.0@2e8187910199bd93129520183c093e19aa585c75` → [Updates: `v1.0.5`] </details> <details><summary>.github/workflows/slapr_backport.yml (1)</summary> - `DataDog/slapr 1.1.0@95312d6b8528460243ba27c7f8167bfe20a68bec` </details> <details><summary>.github/workflows/slapr.yml (3)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `DataDog/slapr 1.1.0@95312d6b8528460243ba27c7f8167bfe20a68bec` </details> <details><summary>.github/workflows/stale.yml (2)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/stale v10.4.0@1e223db275d687790206a7acac4d1a11bd6fe629` → [Updates: `v11.0.0`] </details> <details><summary>.github/workflows/test-devcontainer.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-node v6.5.0@249970729cb0ef3589644e2896645e5dc5ba9c38` → [Updates: `v7.0.0`] </details> <details><summary>.github/workflows/update-dependencies.yml (4)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/update-ebpf-profiler-branch.yml (4)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/update-kubernetes-versions.yml (8)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-python v6.3.0@ece7cb06caefa5fff74198d8649806c4678c61a1` → [Updates: `v7.0.0`] - `helm/kind-action v1.14.0@ef37e7f390d99f746eb8b610417061a60e82a6cc` - `aws-actions/configure-aws-credentials v6.2.2@517a711dbcd0e402f90c77e7e2f81e849156e31d` → [Updates: `v6.2.3`] - `docker/login-action v4.4.0@af1e73f918a031802d376d3c8bbc3fe56130a9b0` → [Updates: `v4.6.0`] - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `python 3.14` </details> <details><summary>.github/workflows/upgrade-python-patch-version.yml (5)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-python v6.3.0@ece7cb06caefa5fff74198d8649806c4678c61a1` → [Updates: `v7.0.0`] - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `python 3.14` </details> <details><summary>.github/workflows/validate-renovate-deps.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/warn-failed-dependabot-pr.yml</summary> </details> </blockquote> </details> <details><summary>gomod (80)</summary> <blockquote> <details><summary>comp/anomalydetection/observer/def/go.mod</summary> </details> <details><summary>comp/anomalydetection/recorder/def/go.mod</summary> </details> <details><summary>comp/anomalydetection/severityevents/def/go.mod</summary> </details> <details><summary>comp/api/api/def/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/agenttelemetry/def/go.mod</summary> </details> <details><summary>comp/core/agenttelemetry/fx/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/agenttelemetry/impl/go.mod (7)</summary> - `github.com/DataDog/zstd v1.5.8-0.20260421145859-31a7e515a571@31a7e515a571` → [Updates: `v1.5.8-0.20260421145859-31a7e515a571`] - `github.com/prometheus/client_model v0.6.2` - `github.com/robfig/cron/v3 v3.0.1` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/core/config/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/configstreamconsumer/def/go.mod</summary> </details> <details><summary>comp/core/configsync/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/delegatedauth/api/cloudauth/aws/go.mod (2)</summary> - `github.com/aws/aws-sdk-go-v2 v1.43.3` → [Updates: `v1.43.4`] - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/delegatedauth/go.mod (2)</summary> - `github.com/cenkalti/backoff/v7 v7.0.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/flare/builder/go.mod</summary> </details> <details><summary>comp/core/flare/types/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/hostname/hostnameinterface/def/go.mod</summary> </details> <details><summary>comp/core/hostname/hostnameinterface/go.mod</summary> </details> <details><summary>comp/core/hostname/hostnameinterface/mock/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/ipc/def/go.mod</summary> </details> <details><summary>comp/core/ipc/httphelpers/go.mod (2)</summary> - `github.com/mdlayher/vsock v1.3.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/ipc/impl/go.mod (2)</summary> - `github.com/gofrs/flock v0.13.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/ipc/mock/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/def/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/fx/go.mod</summary> </details> <details><summary>comp/core/log/impl-trace/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/impl/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/mock/go.mod</summary> </details> <details><summary>comp/core/secrets/def/go.mod</summary> </details> <details><summary>comp/core/secrets/fx/go.mod</summary> </details> <details><summary>comp/core/secrets/impl/go.mod (4)</summary> - `github.com/benbjohnson/clock v1.3.5` - `github.com/json-iterator/go v1.1.12` - `github.com/stretchr/testify v1.11.1` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/secrets/mock/go.mod (1)</summary> - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/secrets/noop-impl/go.mod</summary> </details> <details><summary>comp/core/secrets/utils/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/status/go.mod (4)</summary> - `github.com/dustin/go-humanize v1.0.1` - `github.com/fatih/color v1.19.0` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/status/statusimpl/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/tagger/def/go.mod</summary> </details> <details><summary>comp/core/tagger/fx-remote/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/tagger/generic_store/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/impl-remote/go.mod (5)</summary> - `github.com/cenkalti/backoff/v7 v7.0.0` - `github.com/google/uuid v1.6.0` - `github.com/mdlayher/vsock v1.3.0` - `github.com/stretchr/testify v1.11.1` - `google.golang.org/grpc v1.83.0` </details> <details><summary>comp/core/tagger/origindetection/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/subscriber/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/tags/go.mod</summary> </details> <details><summary>comp/core/tagger/telemetry/go.mod</summary> </details> <details><summary>comp/core/tagger/types/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/utils/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/telemetry/go.mod (6)</summary> - `github.com/prometheus/client_golang v1.24.1` - `github.com/prometheus/client_model v0.6.2` - `github.com/prometheus/common v0.70.1` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/def/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/forwarder/defaultforwarder/go.mod (6)</summary> - `github.com/benbjohnson/clock v1.3.5` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.uber.org/fx v1.24.0` - `go.uber.org/multierr v1.11.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/forwarder/orchestrator/orchestratorinterface/go.mod</summary> </details> <details><summary>comp/host-profiler/symboluploader/testdata/go.mod</summary> </details> <details><summary>comp/logs-library/go.mod (4)</summary> - `github.com/DataDog/agent-payload/v5 v5.0.209` - `github.com/benbjohnson/clock v1.3.5` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` </details> <details><summary>comp/logs/agent/config/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.yaml.in/yaml/v3 v3.0.5` </details> <details><summary>comp/netflow/payload/go.mod</summary> </details> <details><summary>comp/otelcol/collector-contrib/def/go.mod</summary> </details> <details><summary>comp/otelcol/collector-contrib/impl/go.mod</summary> </details> <details><summary>comp/otelcol/converter/def/go.mod</summary> </details> <details><summary>comp/otelcol/converter/impl/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/ddflareextension/def/go.mod</summary> </details> <details><summary>comp/otelcol/ddflareextension/impl/go.mod (6)</summary> - `github.com/google/go-cmp v0.7.0` - `github.com/google/uuid v1.6.0` - `github.com/mohae/deepcopy v0.0.0-20170929034955-c48cc78d4826@c48cc78d4826` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/otelcol/ddflareextension/types/go.mod</summary> </details> <details><summary>comp/otelcol/ddprofilingextension/def/go.mod</summary> </details> <details><summary>comp/otelcol/ddprofilingextension/impl/go.mod (3)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/DataDog/dd-trace-go/v2 v2.9.0` → [Updates: `v2.9.1`] - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/otelcol/logsagentpipeline/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/logsagentpipeline/logsagentpipelineimpl/go.mod</summary> </details> <details><summary>comp/otelcol/otlp/components/connector/datadogconnector/go.mod (5)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/google/go-cmp v0.7.0` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/otelcol/otlp/components/datadogconfig/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/otlp/components/exporter/datadogexporter/go.mod (4)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/otelcol/otlp/components/exporter/logsagentexporter/go.mod (4)</summary> - `github.com/DataDog/agent-payload/v5 v5.0.209` - `github.com/patrickmn/go-cache v2.1.0+incompatible` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/otlp/components/exporter/serializerexporter/go.mod (8)</summary> - `github.com/google/go-cmp v0.7.0` - `github.com/stretchr/testify v1.11.1` - `github.com/tinylib/msgp v1.6.4` - `go.uber.org/fx v1.24.0` - `go.uber.org/multierr v1.11.0` - `go.uber.org/zap v1.28.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] - `go.uber.org/atomic v1.11.0` </details> <details><summary>comp/otelcol/otlp/components/metricsclient/go.mod (2)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/otelcol/otlp/components/processor/infraattributesprocessor/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/otlp/testutil/go.mod (3)</summary> - `github.com/DataDog/sketches-go v1.4.8` - `github.com/stretchr/testify v1.11.1` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/otelcol/status/def/go.mod</summary> </details> <details><summary>comp/otelcol/status/impl/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.yaml.in/yaml/v3 v3.0.5` </details> <details><summary>comp/serializer/logscompression/go.mod</summary> </details> <details><summary>comp/serializer/metricscompression/go.mod</summary> </details> <details><summary>comp/trace/agent/def/go.mod</summary> </details> <details><summary>comp/trace/compression/def/go.mod</summary> </details> <details><summary>comp/trace/compression/impl-gzip/go.mod</summary> </details> <details><summary>comp/trace/compression/impl-zstd/go.mod (1)</summary> - `github.com/DataDog/zstd v1.5.8-0.20260421145859-31a7e515a571@31a7e515a571` → [Updates: `v1.5.8-0.20260421145859-31a7e515a571`] </details> <details><summary>go.mod (115)</summary> - `code.cloudfoundry.org/bbs v1.3.0` → [Updates: `v1.11.0`] - `code.cloudfoundry.org/bbs/models v0.0.0-20260618205254-dc4b9f8d5bc9@dc4b9f8d5bc9` → [Updates: `v1.8.0`] - `code.cloudfoundry.org/garden v0.0.0-20260617020226-a9e754564bb5@a9e754564bb5` → [Updates: `v0.0.0-20260811183727-158508cf0d71`] - `code.cloudfoundry.org/lager/v3 v3.78.0` → [Updates: `v3.81.0`] - `dario.cat/mergo v1.0.2` - `github.com/Azure/azure-sdk-for-go/sdk/azcore v1.22.0` → [Updates: `v1.23.0`] - `github.com/Azure/azure-sdk-for-go/sdk/azidentity v1.14.0` - `github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/azsecrets v1.5.0` - `github.com/CycloneDX/cyclonedx-go v0.11.0` - `github.com/DATA-DOG/go-sqlmock v1.5.2` - `github.com/DataDog/agent-payload/v5 v5.0.209` - `github.com/DataDog/datadog-api-client-go/v2 v2.62.0` → [Updates: `v2.64.0`] - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/DataDog/datadog-operator/api v0.0.0-20260807013103-1518bb55e423@1518bb55e423` → [Updates: `v0.0.0-20260812212652-5f8a87676244`] - `github.com/DataDog/datadog-traceroute v1.0.19` - `github.com/DataDog/dd-policy-engine/go v0.0.0-20260730181922-c5e419a4ec7d@c5e419a4ec7d` → [Updates: `v0.0.0-20260803230307-dd41045a4bb2`] - `github.com/DataDog/dd-trace-go/v2 v2.9.0` → [Updates: `v2.9.1`] - `github.com/DataDog/ddtrivy v0.0.0-20260519164847-bf6bcaf2f9b7@bf6bcaf2f9b7` → [Updates: `v0.0.0-20260519164847-bf6bcaf2f9b7`] - `github.com/DataDog/ebpf-manager v0.8.1` - `github.com/DataDog/go-acl v1.0.1` - `github.com/DataDog/go-sqllexer v0.2.4` - `github.com/DataDog/jsonapi v0.13.0` - `github.com/DataDog/rshell v0.0.24` - `github.com/DataDog/sketches-go v1.4.8` - `github.com/DataDog/watermarkpodautoscaler/apis v0.0.0-20250108152814-82e58d0231d1@82e58d0231d1` → [Updates: `v0.0.0-20260803084540-a82e1114b53b`] - `github.com/DataDog/zstd v1.5.8-0.20260421145859-31a7e515a571@31a7e515a571` → [Updates: `v1.5.8-0.20260421145859-31a7e515a571`] - `github.com/Masterminds/semver/v3 v3.5.0` - `github.com/Masterminds/sprig/v3 v3.3.0` - `github.com/Microsoft/go-winio v0.6.2` - `github.com/Microsoft/hcsshim v0.14.1` - `github.com/NVIDIA/go-nvml v0.13.1-0` - `github.com/ProtonMail/go-crypto v1.4.1` - `github.com/acobaugh/osrelease v0.1.0` - `github.com/alecthomas/units v0.0.0-20240927000941-0f3dac36c52b@0f3dac36c52b` - `github.com/aptly-dev/aptly v1.6.3` - `github.com/aquasecurity/trivy v0.72.0` → [Updates: `v0.73.0`] - `github.com/aquasecurity/trivy-db v0.0.0-20251222105351-a833f47f8f0d@a833f47f8f0d` → [Updates: `v0.0.0-20260813095258-0e0340a01b57`] - `github.com/aws/aws-sdk-go-v2 v1.43.3` → [Updates: `v1.43.4`] - `github.com/aws/aws-sdk-go-v2/config v1.32.34` → [Updates: `v1.32.35`] - `github.com/aws/aws-sdk-go-v2/credentials v1.19.33` → [Updates: `v1.19.34`] - `github.com/aws/aws-sdk-go-v2/service/ec2 v1.318.1` → [Updates: `v1.319.1`] - `github.com/aws/aws-sdk-go-v2/service/rds v1.120.1` → [Updates: `v1.124.1`] - `github.com/aws/aws-sdk-go-v2/service/secretsmanager v1.44.0` → [Updates: `v1.44.4`] - `github.com/aws/aws-sdk-go-v2/service/ssm v1.73.0` → [Updates: `v1.73.4`] - `github.com/aws/aws-sdk-go-v2/service/sts v1.45.3` → [Updates: `v1.45.4`] - `github.com/aws/karpenter-provider-aws v1.9.0` → [Updates: `v1.14.0`] - `github.com/aymerick/raymond v2.0.2+incompatible` - `github.com/bazelbuild/rules_go v0.61.1` → [Updates: `v0.62.0`] - `github.com/beevik/ntp v1.5.0` - `github.com/benbjohnson/clock v1.3.5` - `github.com/bhmj/jsonslice v1.1.3` - `github.com/blabber/go-freebsd-sysctl v0.0.0-20201130114544-503969f39d8f@503969f39d8f` - `github.com/bmatcuk/doublestar/v4 v4.10.0` - `github.com/cenkalti/backoff/v7 v7.0.0` - `github.com/cespare/xxhash/v2 v2.3.0` - `github.com/cilium/ebpf v0.22.0` - `github.com/clbanning/mxj/v2 v2.7.0` - `github.com/cloudflare/cbpfc v0.0.0-20260219140841-0661ad29132c@0661ad29132c` → [Updates: `v0.0.0-20260805072904-7ac485fd93e1`] - `github.com/cloudfoundry-community/go-cfclient/v2 v2.0.1-0.20230503155151-3d15366c5820@3d15366c5820` → [Updates: `v3.0.0-beta.1`] - `github.com/containerd/cgroups/v3 v3.1.3` - `github.com/containerd/containerd/api v1.11.1` - `github.com/containerd/containerd/v2 v2.2.5` → [Updates: `v2.3.3`] - `github.com/containerd/errdefs v1.0.0` - `github.com/containerd/typeurl/v2 v2.3.0` - `github.com/containernetworking/cni v1.3.0` - `github.com/coreos/go-semver v0.3.1` - `github.com/coreos/go-systemd/v22 v22.7.0` - `github.com/creack/pty v1.1.24` - `github.com/cri-o/ocicni v0.5.0` - `github.com/cyphar/filepath-securejoin v0.7.0` - `github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc@d8f796af33cc` - `github.com/distribution/reference v0.6.0` - `github.com/dustin/go-humanize v1.0.1` - `github.com/elastic/go-freelru v0.16.0` - `github.com/elastic/go-libaudit/v2 v2.6.2` - `github.com/elastic/go-seccomp-bpf v1.6.0` - `github.com/envoyproxy/gateway v1.7.4` → [Updates: `v1.8.3`] - `github.com/evanphx/json-patch/v5 v5.9.11` - `github.com/fatih/color v1.19.0` - `github.com/fatih/structtag v1.2.0` - `github.com/freddierice/go-losetup v0.0.0-20220711213114-2a14873012db@2a14873012db` - `github.com/ghodss/yaml v1.0.1-0.20220118164431-d8423dcdf344@d8423dcdf344` - `github.com/glaslos/ssdeep v1.0.0` - `github.com/go-delve/delve v1.27.0` → [Updates: `v1.27.1`] - `github.com/go-jose/go-jose/v4 v4.1.4` - `github.com/go-json-experiment/json v0.0.0-20250517221953-25912455fbc8@25912455fbc8` → [Updates: `v0.0.0-20260623181947-01eb4420fa68`] - `github.com/go-ole/go-ole v1.3.0` - `github.com/go-sql-driver/mysql v1.10.0` - `github.com/go-viper/mapstructure/v2 v2.5.0` - `github.com/go-zookeeper/zk v1.0.4` - `github.com/gobwas/glob v0.2.3` - `github.com/goccy/go-yaml v1.19.2` - `github.com/gocomply/scap v0.1.3` - `github.com/godbus/dbus/v5 v5.2.2` - `github.com/godror/godror v0.50.0` → [Updates: `v0.51.0`] - `github.com/gogo/protobuf v1.3.2` - `github.com/golang-jwt/jwt/v5 v5.3.1` - `github.com/golang/groupcache v0.0.0-20241129210726-2c02b8208cf8@2c02b8208cf8` - `github.com/golang/mock v1.7.0-rc.1` - `github.com/google/btree v1.1.3` - `github.com/google/cel-go v0.29.2` → [Updates: `v0.30.0`] - `github.com/google/go-cmp v0.7.0` - `github.com/google/go-containerregistry v0.21.7` → [Updates: `v0.21.9`] - `github.com/google/gofuzz v1.2.0` - `github.com/google/gopacket v1.1.19` - `github.com/google/uuid v1.6.0` - `github.com/gorilla/websocket v1.5.4-0.20250319132907-e064f32e3674@e064f32e3674` - `github.com/gosnmp/gosnmp v1.44.0` - `github.com/grpc-ecosystem/go-grpc-middleware/v2 v2.3.3` - `github.com/h2non/filetype v1.1.3` - `github.com/hashicorp/consul/api/v2 v2.0.0` - `github.com/hashicorp/go-multierror v1.1.1` - `github.com/hashicorp/go-retryablehttp v0.7.8` - `github.com/hashicorp/go-version v1.9.0` - `github.com/hashicorp/golang-lru/v2 v2.0.7` </details> </blockquote> </details> --- - [ ] <!-- manual job -->Check this box to trigger a request for Renovate to run again on this repository",
        "url": "https://github.com/DataDog/datadog-agent/issues/33469",
        "createdAt": "2025-01-28T12:05:52Z",
        "updatedAt": "2026-08-13T18:01:09Z",
        "timestamp": "2026-08-13T18:01:09Z",
        "metrics": {
          "reactions": 0,
          "comments": 0
        },
        "labels": [
          "team/agent-devx",
          "pending",
          "oss/0"
        ],
        "author": "renovate[bot]",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:issue:54728",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "issue",
        "title": "service.namespace is not mapped to a metric tag, unlike its service.* siblings",
        "text": "`service.namespace` is a stable OpenTelemetry semantic convention, and the natural way to distinguish multiple deployments of the same service that share a `service.name`. It doesn't reach Datadog metrics as a tag. In `pkg/opentelemetry-mapping-go/otlp/attributes/attributes.go`, `TagsFromAttributes` promotes resource attributes through `coreMapping`, `kubernetesMapping`, `kubernetesDDTags`, and `ContainerMappings`. `service.namespace` appears in none of them. `coreMapping`, whose comment points at Datadog's unified service tagging documentation, currently holds: ``` deployment.environment -> env deployment.environment.name -> env service.name -> service service.version -> version service.instance.id -> service.instance.id ``` Three of the four `service.*` conventions are mapped, both spellings of `deployment.environment` are mapped, and `service.namespace` is the remaining gap. The `service.instance.id` entry is precedent for exactly the shape being requested: a `service.*` convention mapped to a dotted, non-reserved tag key of the same name. `service.namespace` would work identically, so this needs no new mechanism and no new reserved Datadog tag name. ## Effect today All resource attributes become span meta, so `service.namespace` is queryable on spans as `@service.namespace`. On metrics it disappears. A deployment that sets it for the purpose the semantic convention describes can therefore group its traces by it, but cannot scope a single metric query by it. ## Why `resource_attributes_as_tags` isn't the answer If that flag were the intended path for standard semantic conventions, then `service.name`, `service.version`, and `service.instance.id` would not need to be in `coreMapping` either. The map exists so that conventional attributes are available without it. This request is for `service.namespace` to be treated the same as its siblings, not for special handling. Separately, the flag is all-or-nothing: it promotes every resource attribute, which makes it unusable for any pipeline whose signals also carry per-request or per-job resource attributes, since promoting everything creates unbounded metric tags. ## Request Add `service.namespace` to `coreMapping`, mapping to `service.namespace`, mirroring the existing `service.instance.id` entry. Happy to open a PR.",
        "url": "https://github.com/DataDog/datadog-agent/issues/54728",
        "timestamp": "2026-08-12T12:42:06Z",
        "metrics": {
          "reactions": 0,
          "comments": 4
        },
        "labels": [
          "team/opentelemetry-agent",
          "oss/0"
        ],
        "author": "jforest",
        "assignees": [],
        "change": "new"
      },
      {
        "id": "github:DataDog/datadog-agent:issue:54801",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "issue",
        "title": "NDM Agent Workload Balancing: switch RC product from NDM_AGENT_WORKLOAD_BALANCING to HA_AGENT",
        "text": "## Context PRs #54652, #54656, #54659, and #54795 implemented NDM Agent Workload Balancing's agent-side component (`comp/workloadbalancing`), registering its own Remote Config product, `NDM_AGENT_WORKLOAD_BALANCING`. The design RFC ([NDM Agent Workload Balancing: Device Handoff](https://datadoghq.atlassian.net/wiki/spaces/II/pages/7029621750)) has since been updated to reuse HA Agent's existing `HA_AGENT` Remote Config product instead, extending its schema with a second, discriminated payload type rather than registering a new product. This follows the same polymorphic-payload pattern already used by ASM and Network Path's `NETWORK_PATH` product, and was settled after a Slack discussion establishing that extending an existing RC pipeline runs roughly 1-2 weeks versus roughly 1-2 months for a new one (new product registration, delivery predicates, the full RC checklist including security review). ## What needs to change - `comp/workloadbalancing`'s Remote Config listener: subscribe to `state.ProductHaAgent` (`HA_AGENT`) instead of a new `NDM_AGENT_WORKLOAD_BALANCING` product. - The listener needs to only act on documents carrying workload-balancing's discriminator field (e.g. `group_id`), ignoring ordinary HA Agent election documents (`config_id`/`active_agent`) on the same product, per `comp/haagent`'s existing per-document filtering pattern. - Apply-status handling: skip `applyStateCallback` for documents this listener doesn't own, mirroring the existing pattern in `comp/core/autodiscovery/providers/networkpath/provider.go` and `comp/networkpath/npcollector/impl/remote_config.go`, which already share one RC product between two independent listeners. - The RC product schema itself (config validator's schema library) needs to move from a new `NDM_AGENT_WORKLOAD_BALANCING` directory to an extension of `HA_AGENT`'s existing `root.json`. - Backend-side writer (`WorkloadBalancingService.UpsertGroupAssignment`) needs to target `HA_AGENT` RC documents instead of a separate product. - Test suite in `test/new-e2e/tests/workload-balancing/` currently calls `RCAddConfig(..., state.ProductNDMAgentWorkloadBalancing, ...)` — needs updating to `state.ProductHaAgent` with the new payload shape. ## Why this is a separate follow-up This is a documentation-first change: the RFC update landed ahead of the code so reviewers are working from the current design. The already-merged agent code should be brought in line with it once the RFC's schema/discriminator details are finalized. > **Note:** This issue was created by Claude.",
        "url": "https://github.com/DataDog/datadog-agent/issues/54801",
        "createdAt": "2026-08-12T20:42:56Z",
        "updatedAt": "2026-08-13T14:07:16Z",
        "timestamp": "2026-08-13T14:07:16Z",
        "metrics": {
          "reactions": 0,
          "comments": 1
        },
        "labels": [
          "oss/0",
          "team/network-device-monitoring-core"
        ],
        "author": "matthewleese",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:36401",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Update OTel Collector dependencies to v",
        "text": "This PR updates the dependencies of the OTel Collector to v{OCB_VERSION} and generates the OTel Agent code.",
        "url": "https://github.com/DataDog/datadog-agent/pull/36401",
        "createdAt": "2025-04-23T12:18:54Z",
        "updatedAt": "2026-08-13T03:02:47Z",
        "timestamp": "2026-08-13T03:02:47Z",
        "metrics": {
          "reactions": 0,
          "comments": 6
        },
        "labels": [
          "medium review",
          "team/agent-devx",
          "stale",
          "auto-closed",
          "internal"
        ],
        "author": "github-actions[bot]",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:43554",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "DELA-251 - Initial implementation of cloud auth proof for an API key",
        "text": "### What does this PR do? This adds a new authentication method for the agent. This give the agent the ability to exchange a AWS Cloud Auth Proof for an API key which is automatically managed and rotated on behalf of the customer. This is essentially extending the https://docs.datadoghq.com/account_management/cloud_provider_authentication into the agent. The flow is as so: 1. Agent get AWS credentials from the environment the agent is running in 2. Agent signs a request to AWS which will prove it's access to the credentials 3. Agent passed the signed request to Datadog service 4. Service validates the signed request against AWS and validates it against Datadog configuration 5. Service response with a Managed and automatically rotated API key 6. Agent propagates that API key throughout it's config If the delegated auth flow fails it will fallback to using the API key provided in the yaml file. The allows customers to onboard with limited risk to their current flow. ### Motivation This should enable customers to not need to manage the API used by the agent and instead use the AWS credentials in the AWS environment the agent is deploy to. ### Describe how you validated your changes Ran the agent locally to validate changes and deployed to multiple staging clusters. ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/43554",
        "createdAt": "2025-11-26T19:53:13Z",
        "updatedAt": "2026-08-13T03:02:58Z",
        "timestamp": "2026-08-13T03:02:58Z",
        "metrics": {
          "reactions": 0,
          "comments": 4
        },
        "labels": [
          "team/agent-apm",
          "component/system-probe",
          "team/agent-security",
          "team/remote-config",
          "team/ebpf-platform",
          "team/agent-cspm",
          "team/container-platform",
          "long review",
          "team/ndm-core",
          "qa/rc-required",
          "team/ndm-integrations",
          "team/agent-integrations",
          "team/agent-runtimes",
          "team/agent-configuration",
          "team/agent-log-pipelines",
          "team/agent-metric-pipelines",
          "team/agent-devx",
          "team/container-experiences",
          "team/windows-products",
          "team/cloud-network-monitoring",
          "team/network-path",
          "team/action-platform",
          "internal"
        ],
        "author": "wynbennett",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:45535",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "See if we can hack a way around project.extra_package_file",
        "text": "See if we can hack a way around the `project.extra_package_file` by writing tarballs directly to OMNIBUS_PACKAGE_ARTIFACT_DIR. This would be a temporary solution until the time when we can completely replace the package-artifact.rb. After migration, we'll just depend on these special targets in the srcs of the package target. One of the key motivations is to be able to build the product without stomping /etc. That is a key step in being able to build without being root.",
        "url": "https://github.com/DataDog/datadog-agent/pull/45535",
        "createdAt": "2026-01-27T04:39:09Z",
        "updatedAt": "2026-08-13T03:02:12Z",
        "timestamp": "2026-08-13T03:02:12Z",
        "metrics": {
          "reactions": 0,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "medium review",
          "team/agent-build",
          "stale",
          "auto-closed",
          "internal"
        ],
        "author": "aiuto",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:45747",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[agenthealth] add e2e test",
        "text": "### What does this PR do? Adds end-to-end testing infrastructure for the agent health platform feature, including: - Agent health aggregator support in fakeintake for capturing and validating health reports - New E2E test suite (`new-e2e-agent-health`) that validates docker permission issue detection and reporting - GitLab CI configuration to run agent health E2E tests ### Motivation The agent health platform (added in previous PRs) needs E2E test coverage to ensure: - Health issues are correctly detected by the agent - Health reports are properly formatted and sent to the intake - The complete flow from issue detection to report submission works end-to-end ### Describe how you validated your changes - Added `test/fakeintake/aggregator/agenthealthAggregator_test.go` with unit tests for the aggregator - Created E2E test `test/new-e2e/tests/agent-health/docker_permission_test.go` that: - Provisions an EC2 instance with Docker and the Datadog agent - Deploys containers without proper Docker socket permissions - Verifies the agent detects and reports the docker permission issue - Validates the health report is received by fakeintake with correct issue details - Local linter passes with no issues ### Additional Notes - The E2E test runs manually and on changes to health platform code or E2E framework - Fakeintake now supports the `/api/v2/agenthealth` endpoint for testing health report submission - Test provisions infrastructure on AWS using Pulumi",
        "url": "https://github.com/DataDog/datadog-agent/pull/45747",
        "createdAt": "2026-01-30T17:20:32Z",
        "updatedAt": "2026-08-13T03:02:28Z",
        "timestamp": "2026-08-13T03:02:28Z",
        "metrics": {
          "reactions": 0,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "long review",
          "team/agent-devx",
          "internal"
        ],
        "author": "pducolin",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:45934",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[do not merge] Implement kubernetes_state.pod.time_to_ready [A]",
        "text": "### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/45934",
        "createdAt": "2026-02-04T15:11:12Z",
        "updatedAt": "2026-08-13T03:02:43Z",
        "timestamp": "2026-08-13T03:02:43Z",
        "metrics": {
          "reactions": 0,
          "comments": 3
        },
        "labels": [
          "team/container-platform",
          "long review",
          "team/kubernetes-experiences",
          "internal"
        ],
        "author": "triviajon",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:45964",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Paulcacheux/unmarshal binary opt",
        "text": "### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/45964",
        "createdAt": "2026-02-05T12:24:32Z",
        "updatedAt": "2026-08-13T03:02:24Z",
        "timestamp": "2026-08-13T03:02:24Z",
        "metrics": {
          "reactions": 0,
          "comments": 2
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "team/agent-security",
          "qa/done",
          "short review",
          "internal"
        ],
        "author": "paulcacheux",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:46209",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "system-probe: Run bazel build for checks",
        "text": "### What does this PR do? In .bazelrc, we run clippy and rustfmt checks in the build step using Bazel's aspects feature when in CI (using --config=ci, added by tools/bazel, which is automatically invoked by bazelisk, if the CI environment variable is present). However, it appears that these are only run when explicitly running the build step, not when, for example, a install step is run via \"bazel run\" which in turn depends on a build step. Since the system-probe build task only invokes the latter, the checks are not actually run. So add an explicit call to build before the install step. ### Motivation Actually catch rustfmt and clippy errors in CI. ### Describe how you validated your changes Introduced a formatting error and run CI https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1416891445",
        "url": "https://github.com/DataDog/datadog-agent/pull/46209",
        "createdAt": "2026-02-10T17:43:48Z",
        "updatedAt": "2026-08-13T03:02:50Z",
        "timestamp": "2026-08-13T03:02:50Z",
        "metrics": {
          "reactions": 0,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "team/ebpf-platform",
          "qa/done",
          "medium review",
          "team/agent-discovery",
          "internal"
        ],
        "author": "vitkyrka",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:46235",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Revert \"[SINT-3775] Use CI Identities IAM Role in Windows Jobs\"",
        "text": "Reverts DataDog/datadog-agent#40856",
        "url": "https://github.com/DataDog/datadog-agent/pull/46235",
        "createdAt": "2026-02-11T09:13:33Z",
        "updatedAt": "2026-08-13T03:02:39Z",
        "timestamp": "2026-08-13T03:02:39Z",
        "metrics": {
          "reactions": 0,
          "comments": 4
        },
        "labels": [
          "team/agent-delivery",
          "medium review",
          "team/agent-devx",
          "team/agent-build",
          "team/windows-products",
          "internal"
        ],
        "author": "KSerrania",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:46236",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "fix(ci):comment ci-identities calls",
        "text": "### What does this PR do? #incident-49349 ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/46236",
        "createdAt": "2026-02-11T09:24:18Z",
        "updatedAt": "2026-08-13T03:02:20Z",
        "timestamp": "2026-08-13T03:02:20Z",
        "metrics": {
          "reactions": 0,
          "comments": 1
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "team/agent-delivery",
          "short review",
          "team/agent-devx",
          "team/windows-products",
          "internal"
        ],
        "author": "chouetz",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:46240",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[TEST] [DONOTMERGE] Try out cross-pipeline job dependencies",
        "text": "### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/46240",
        "createdAt": "2026-02-11T09:37:26Z",
        "updatedAt": "2026-08-13T03:02:31Z",
        "timestamp": "2026-08-13T03:02:31Z",
        "metrics": {
          "reactions": 0,
          "comments": 6
        },
        "labels": [],
        "author": "Ishirui",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:49282",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[ACIX-1440]  Only sign and notarize packages on nightly",
        "text": "### What does this PR do? Stops code signing on main, and moves it only to nightly. ### Motivation Get back ~7 minutes of wait time on the post merge finalization of every commit. Discussion with delivery team indicates that doing this on nightly is sufficient to keep them alert for potential problems. ### Describe how you validated your changes If basic CI passes we merge this. If some time (a week? until next release candidate freeze?) goes by without anyone finding a problem, we don't roll back. We also take a look at time for macos dmg jobs over the week to verify a measureable decrease.",
        "url": "https://github.com/DataDog/datadog-agent/pull/49282",
        "createdAt": "2026-04-13T18:20:13Z",
        "updatedAt": "2026-08-12T19:45:47Z",
        "timestamp": "2026-08-12T19:45:47Z",
        "metrics": {
          "reactions": 0,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "medium review",
          "team/agent-build",
          "stale",
          "auto-closed",
          "internal"
        ],
        "author": "aiuto",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:50457",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[ABLD-457] Rust version of tool to make md5sums file of a tar file.",
        "text": "### What does this PR do? For debian packaging, we need to include a file of md5 sums of all the files in the data payload as the file md5sums in the control payload. This makes that available as a rule. I'll plug it into a wrapper for pkg_deb in a follow-up. ### Describe how you validated your changes - Tests - reading the generated code. It's pretty simple. ### Additional Notes I used lzma-rs because it is a pure rust implementation and that avoids having to do with integrating with the C library right now. That is easy enough to fix in the future if we decide we want to deal with that.",
        "url": "https://github.com/DataDog/datadog-agent/pull/50457",
        "createdAt": "2026-05-07T04:12:51Z",
        "updatedAt": "2026-08-12T19:45:24Z",
        "timestamp": "2026-08-12T19:45:24Z",
        "metrics": {
          "reactions": 0,
          "comments": 12
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "long review",
          "team/agent-devx",
          "team/agent-build",
          "stale",
          "auto-closed",
          "internal"
        ],
        "author": "aiuto",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:51295",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Add source to distributions via checks.",
        "text": "### What does this PR do? This adds the source to distributions that have been submitted by a Go check. ### Motivation Source was added to other metrics in #20690. This completes the source for distributions. ### Describe how you validated your changes Tested manually by creating a dummy go check, which was not added to this PR. ### Additional Notes [RFC outlining](https://datadoghq.atlassian.net/wiki/spaces/AM/pages/6773538856/RFC+-+Add+origin+to+check+distribution+metrics) the impact of this change. (TLDR there is no known negative impact)",
        "url": "https://github.com/DataDog/datadog-agent/pull/51295",
        "createdAt": "2026-05-26T11:16:34Z",
        "updatedAt": "2026-08-13T17:33:52Z",
        "timestamp": "2026-08-13T17:33:52Z",
        "metrics": {
          "reactions": 2,
          "comments": 8
        },
        "labels": [
          "qa/done",
          "short review",
          "team/agent-metric-pipelines",
          "internal"
        ],
        "author": "StephenWakely",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:51861",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "packaging/aix: use rmssys only in unconfig, drop odmdelete",
        "text": "### What does this PR do? Remove the `odmdelete` calls from the AIX `unconfig` lifecycle script, keeping only `rmssys`. ### Motivation `rmssys` atomically removes a subsystem from both the ODM file and the live srcmstr daemon. Calling `odmdelete` before actually makes `rmssys` fail silently, and leave a stale entry in `srcmstr`. The `postinst` script already documents this: \"Always use rmssys, never odmdelete.\" ### Describe how you validated your changes Verified on the AIX 7.3 VM. ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/51861",
        "createdAt": "2026-06-05T13:06:45Z",
        "updatedAt": "2026-08-13T15:48:46Z",
        "timestamp": "2026-08-13T15:48:46Z",
        "metrics": {
          "reactions": 2,
          "comments": 6
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "short review",
          "team/agent-runtimes",
          "team/agent-build",
          "internal"
        ],
        "author": "pgimalac",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:52174",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[NDM] Implement the `connectivityCheck` Private Action",
        "text": "This PR implements the Agent side of the `connectivityCheck` Private Action (`com.datadoghq.remoteaction.networkdevices`): it runs ICMP and SNMP reachability checks against network devices for NDM onboarding and returns a per-device result. The checks run in the **core Agent**, not in the runner. The action decrypts its SNMP credentials and hands the work to a new `networkdevices` component over the Agent's IPC endpoint: - `POST /agent/networkdevices/connectivity-check`, served by `comp/networkdevices` — same pattern `networkconfigmanagement` uses for `rollbackConfig`. - The runner keeps only credential decryption (it holds the per-task HPKE key, so the Agent cannot decrypt) and a JSON round-trip. It links neither `gosnmp` nor the pinger. - Credentials are sent once per check rather than once per target, so a 1000-IP check crosses the boundary once. - Ping via `pkg/networkdevice/pinger` (in-process unprivileged UDP ICMP, no system-probe dependency). - SNMP via `buildSNMPClient` (gosnmp): GET `sysName` (`1.3.6.1.2.1.1.5.0`), time the request round-trip, decode the device name. - Failures map to a granular `failureReason` via `errors.Is` on gosnmp's exported v3 USM sentinels and the `%w`-wrapped socket errnos (`authentication_failed` / `decryption_failed` / `unknown_user` / `unsupported_security_level` / `unknown_engine_id`, `connection_refused` / `host_unreachable` / `network_unreachable`, `timeout`); only the timeout — which gosnmp re-creates as a bare string — falls back to a substring match. Ping is `none` / `unreachable`. - Inputs are individual IPs (`targetIPs`); the back-end expands CIDRs, so the Agent does no expansion. - `runPing` / `runSNMP` return an error for unrunnable requests (missing options, a failed pinger/client build) so the task fails cleanly, while connectivity outcomes (unreachable, timeout, auth failure) stay per-device results. A cancelled or timed-out run returns `ctx.Err()` rather than a silently truncated success. - The Agent applies no defaults and runs exactly what it's told; the back-end sets every input value. - Registered in `registry.go` only, **not** in `registry_kubeapiserver.go`: reaching the endpoint needs a core Agent on localhost, and a Cluster Agent cannot run the SNMP check that would eventually poll these devices anyway. Contract / manifest (dd-source): https://github.com/DataDog/dd-source/pull/467935 ## Motivation Running the checks from the customer's own host validates reachability and SNMP credentials from inside their network, with no new back-end-to-device egress. Doing the probing in the runner meant linking `gosnmp`, `gosnmplib` and the pinger into the standalone `privateactionrunner` binary, which the Agent package ships in `embedded/bin`. That added +229.66 KiB to `agent_rpm_arm64` and `agent_suse_arm64`, whose `max_on_disk_size` sits within 0.02% of their current size, and broke both gates. The core Agent already links `gosnmp` and the pinger for the SNMP core check (`pkg/commonchecks`), so moving the work there costs it nothing. ## SNMP client construction We build the gosnmp client ourselves (`buildSNMPClient`) rather than reuse `pkg/snmp`'s `(*Authentication).BuildSNMPParams`. That helper is tied to the `snmp_listener` autodiscovery config: its `Timeout` is in seconds (this action's contract is millisecond-granular), it doesn't accept `\"2c\"`, and it doesn't wire a `context`. Reusing it would require a breaking change to that shared, YAML-loaded config struct (and its autodiscovery consumers) for marginal dedup. The part worth sharing — the gosnmp auth/priv protocol mapping — is already shared via `gosnmplib`, which both call. ## Coordination Pairs with DataDog/dd-source#467935 — the JSON tags here must match that manifest. ## Validation - Unit tests on `comp/networkdevices/impl` and the PAR bundle; CI. - Validated end-to-end on staging: a CI Agent on a CML host, enrolled as a PAR with `com.datadoghq.remoteaction.networkdevices.connectivityCheck` allowlisted and an execution group covering the host. The staging run predates moving the checks into the Agent, so it validated the action end-to-end but not the IPC hop — worth re-running before merge. <screenshot: connectivityCheck run output on staging> 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
        "url": "https://github.com/DataDog/datadog-agent/pull/52174",
        "timestamp": "2026-08-12T13:01:12Z",
        "metrics": {
          "reactions": 1,
          "comments": 16
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "long review",
          "team/agent-runtimes",
          "team/agent-build",
          "team/action-platform",
          "internal",
          "team/network-device-monitoring-core"
        ],
        "author": "Pierre-L42",
        "assignees": [],
        "change": "new"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:52200",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Revert \"SBOM e2e: scan host and container images across runtimes\"",
        "text": "Reverts DataDog/datadog-agent#51486 It overloads quota on an external server. https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1767647074 If tests pass on this, and the sbom test continues to fail on main, I'll merge this revert",
        "url": "https://github.com/DataDog/datadog-agent/pull/52200",
        "createdAt": "2026-06-12T18:34:44Z",
        "updatedAt": "2026-08-12T19:45:11Z",
        "timestamp": "2026-08-12T19:45:11Z",
        "metrics": {
          "reactions": 0,
          "comments": 6
        },
        "labels": [
          "changelog/no-changelog",
          "team/agent-security",
          "long review",
          "team/container-integrations",
          "team/agent-devx",
          "team/agent-build",
          "internal"
        ],
        "author": "aiuto",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:52587",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "add eviction configs",
        "text": "### What does this PR do? Pick up NCM eviction configurations from the datadog.yaml. Use these values in the eviction function. Call the eviction function after we write to the db to ensure that we do not exceed memory constraints. Evictions are tracked under a new Datadog internal metric: `datadog.ncm.store.configs_evicted` ### Motivation ### Describe how you validated your changes ### Additional Notes ### Local Validation That datadog.yaml is read correctly set `dev/dist/datadog.yaml`: ``` log_level: debug api_key: *** dd_url: 'https://dd.datad0g.com/' hostname: \"sophie-local\" process_config: process_collection: enabled: true network_devices: config_management: rollback: enabled: true store: min_configs_per_device: 2 max_configs_per_device: 24 max_raw_config_store_bytes: 2000000000 ``` run commands: ``` dda inv agent.build --build-exclude=systemd ./bin/agent/agent run -c ./bin/agent/dist/datadog.yaml ``` View debug logs: <img width=\"1439\" height=\"61\" alt=\"Screenshot 2026-06-23 at 11 59 38 AM\" src=\"https://github.com/user-attachments/assets/c2f526a1-76e4-407e-9569-be1adc573112\" /> ### CML eviction e2e test Confirmed eviction order with simulation on CML - set low number of bytes for store config - change configuration of network device, expecting removal of configurations in alignment with eviction policy - check evicted uuids in logs, confirm that inventory_reported_at does not continue to update for evicted configs in orgstore ### QA flow in CML 1) Configure datadog.yaml file inside of CML yaml file for test case, import lab to CML 2) Make needed configuration changes for test case 3) Validate Boltdb state with the following steps: ssh into vm running agent in cml, display device_config.db in cml as base 64: `sudo base64 /opt/datadog-agent/run/ncm_config.db` copy and paste the db output into a .txt file in local computer convert to a bin file: `base64 -d ~/Documents/cml_boltdb.txt > ~/Documents/cml_boltdb.bin` explore file using ncm show: ``` cd ~/go/src/github.com/DataDog/ndm-tools/ncmshow ./ncmshow ~Documents/cml_boltdb.bin ``` ### Manual test cases 1) Set configuration to: min_configs_per_device: 1, max_configs_per_device: 24, max_raw_config_store_bytes: 8 Get BoltDB state: <img width=\"849\" height=\"88\" alt=\"Screenshot 2026-08-05 at 9 51 16 AM\" src=\"https://github.com/user-attachments/assets/68b152bf-a4d2-4208-9651-84d014c6177d\" /> Change hostname Get BoltDB state: <img width=\"850\" height=\"92\" alt=\"Screenshot 2026-08-05 at 9 51 23 AM\" src=\"https://github.com/user-attachments/assets/bbffc9bb-ca2f-46b1-8c12-9996c39ae3ca\" /> (Should see 2 configs per device, even though min configs is set to 1 it should get overridden to 2. Min configs should override the config store requirement - will see that even after eviction not within this setting.) - note here, old running config was evicted so that the modified one could be stored <img width=\"969\" height=\"531\" alt=\"Screenshot 2026-08-05 at 10 12 01 AM\" src=\"https://github.com/user-attachments/assets/72e3942e-8cf5-43eb-9b65-21e1de3a3855\" /> 2) Set configuration to: min_configs_per_device: 1, max_configs_per_device: 3, max_raw_config_store_bytes: 1000000 Change hostname Change hostname <img width=\"561\" height=\"605\" alt=\"Screenshot 2026-08-05 at 12 32 52 PM\" src=\"https://github.com/user-attachments/assets/96d92227-ed84-4dcf-857b-8ad2d94adddb\" /> Get BoltDB state: <img width=\"853\" height=\"138\" alt=\"Screenshot 2026-08-05 at 12 32 43 PM\" src=\"https://github.com/user-attachments/assets/24adf9c7-a637-443c-80c3-ea50b14a23ad\" /> BoltDB only has 3 max configs for evictionCML2:10:10:1:2 even though there is enough space in the (db only 66000 bytes) because of the upper max_raw setting.",
        "url": "https://github.com/DataDog/datadog-agent/pull/52587",
        "createdAt": "2026-06-22T16:24:53Z",
        "updatedAt": "2026-08-13T15:11:56Z",
        "timestamp": "2026-08-13T15:11:56Z",
        "metrics": {
          "reactions": 0,
          "comments": 5
        },
        "labels": [
          "qa/done",
          "long review",
          "team/ndm-integrations",
          "team/agent-configuration",
          "team/agent-devx",
          "team/agent-build",
          "internal",
          "team/fleet-automation"
        ],
        "author": "Sophie-Ruetschi",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:52758",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[otel-agent] Use zstd compression for all signals",
        "text": "### What does this PR do? Makes the DDOT collector (`otel-agent`) compress **every** signal with `zstd`, replacing the previous per-signal mix (zlib for metrics, gzip for traces, zstd for logs): - **Metrics**: use the config-driven metrics compressor (`metricscompression/fx`) instead of the hardcoded zlib module; defaults to **zstd level 3**, overridable via `serializer_zstd_compressor_level`. - **Logs**: pin zstd and default `logs_config.zstd_compression_level` to **3** (overridable). - **Traces**: use the existing `fx-zstd` module (zstd at `BestSpeed`); the trace level is intentionally fixed. - **Host metadata**: rides the same serializer compressor as metrics (no dedicated knob), so it becomes zstd automatically. Also adds tests that guard against future per-signal compression divergence. ### Motivation The DDOT exporter used a different compression algorithm per signal, which is inconsistent and harder to reason about. Standardizing on `zstd` gives a consistent algorithm across metrics/traces/logs and a better compression ratio, with the level configurable per signal. ### Describe how you validated your changes - `dda inv otel-agent.build` passes; `dda inv linter.go` → **0 issues** on changed packages; `gofmt` clean. - **Unit** (`cmd/otel-agent/config`): asserts metrics and logs resolve to the **same** algorithm (zstd) at level 3, that the level stays env-overridable, and that **host metadata** uses that same serializer compressor (so it is zstd too). - **Integration** (`comp/otelcol/otlp/integrationtest`): now decodes trace payloads as zstd — verifies traces ship valid zstd end-to-end. Passes locally (`dda inv otel-agent.integration-test`). - **E2E** (`TestOTelAgentComplete/TestOTLPCompression`): asserts metrics, traces, and logs reach fakeintake with `Content-Encoding: zstd` (requires the e2e infra to run). ### Additional Notes - **Scope is the standalone `otel-agent`.** The core Agent, trace-agent, host-profiler, and OSS exporter are unaffected — they use their own compression modules (`metricscompression/fx`, `fx-zstd`, `fx-gzip`, `fx-otel` respectively). - **The v2 metrics intake is preserved** (`use_v3_api.series.enabled` stays `false`); moving series to v3 is a separate effort. ⚠️ **Reviewers:** please confirm the v2 series intake (`/api/v2/series`) accepts `Content-Encoding: zstd` — the core Agent uses zstd→v3 for series by default, so this exact combination isn't exercised today. The new e2e test validates it against fakeintake. - **Exhaustive compression coverage** (all the DD exporter's submission clients): after this change, every active intake submission in the otel-agent is zstd — **metrics (series/sketches), host metadata, logs, traces** — *except* **APM stats**, which stays **gzip** (hardcoded in `pkg/trace/writer/stats.go`, shared with the trace-agent; out of scope here, separate conversation). The orchestrator/K8s-objects sub-exporter already uses zstd and is disabled by default. Internal exporter telemetry (`metricsclient`, COAT/gateway gauges) is scraped Prometheus/OTel-meter telemetry, not an intake submission. 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
        "url": "https://github.com/DataDog/datadog-agent/pull/52758",
        "createdAt": "2026-06-25T00:02:17Z",
        "updatedAt": "2026-08-12T16:07:00Z",
        "timestamp": "2026-08-12T16:07:00Z",
        "metrics": {
          "reactions": 1,
          "comments": 10
        },
        "labels": [
          "long review",
          "qa/rc-required",
          "team/agent-devx",
          "team/agent-build",
          "internal"
        ],
        "author": "truthbk",
        "state": "closed",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:52945",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "feat(otel-logs): map instrumentation scope name to otel.scope.name",
        "text": "## Summary - Adds `otel.scope.name` to the OTLP → DD log translation in `opentelemetry-mapping-go/otlp/logs`, covering the **Datadog Agent OTLP receiver** and **DDOT** ingestion paths - Counterpart to [ddoghq/dd-source#3393](https://github.com/ddoghq/dd-source/pull/3393), which adds the same mapping for the direct `otlp.datad0g.com/v1/logs` intake path - The field is `otel.scope.name` in `AdditionalProperties`, consistent with the existing `otel.*` namespace for other log-record-level fields ## Test plan - [ ] `go test ./pkg/opentelemetry-mapping-go/otlp/logs/...` passes (new \"scope name\" test case added) - [ ] Verify `otel.scope.name` appears in Logs Explorer for logs ingested via Agent OTLP receiver 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
        "url": "https://github.com/DataDog/datadog-agent/pull/52945",
        "createdAt": "2026-06-29T20:28:58Z",
        "updatedAt": "2026-08-12T21:59:48Z",
        "timestamp": "2026-08-12T21:59:48Z",
        "metrics": {
          "reactions": 3,
          "comments": 4
        },
        "labels": [
          "qa/done",
          "medium review",
          "ask-review",
          "team/opentelemetry-agent",
          "internal"
        ],
        "author": "mabdinur",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:52986",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "LLMO PoC: emit spans + capture LLM request bodies via eBPF",
        "text": "### What does this PR do? First proof-of-concept for LLM Observability built on top of USM/go-tls. When USM observes an HTTP/2 request whose path looks like an LLM API call (e.g. /v1/chat/completions, /v1/messages), we emit one APM span per request (no aggregation) with the full request path as the resource. For connections flagged as LLM traffic, the go-tls write hook also captures a 256-byte window of the decrypted request body into an eBPF map; userspace parses it to enrich the span with the model and prompt. Components: - pkg/network/ebpf/c/protocols/tls/llmo.h: llm_monitored_connections (gate), llm_request_bodies, and a per-CPU scratch map; llmo_maybe_capture_body() copies the decrypted request body for flagged connections. - pkg/network/ebpf/c/runtime/usm.c: call the capture in the go-tls write hook BEFORE tls_process() (which ends in a tail call and never returns). - pkg/network/protocols/http/llmo.go: path detection, dd-trace-go span emission, tolerant body parser (model + first message content), and the connection-flag + body-read logic. Matching Go structs for the eBPF maps (explicit padding so the key marshals to the map key size). - pkg/network/protocols/http/statkeeper.go: emit the span + capture the body per transaction when the path is an LLM endpoint. - pkg/network/protocols/http2/protocol.go: wire the eBPF maps into the HTTP/2 statkeeper. - pkg/network/protocols/http/llmo_test.go: parser tests incl. HTTP/2 DATA-frame-prefixed, NUL-padded, and truncated bodies. Known PoC limitations: path-only detection (no Host/:authority), body capped at 256B and keyed by connection (not stream), first request on a connection is missed, and the span service name is a fixed placeholder. Token usage (response side) is not captured yet. ### Motivation support llmo with ebpf ### Describe how you validated your changes unit test ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/52986",
        "createdAt": "2026-06-30T15:02:30Z",
        "updatedAt": "2026-08-13T04:40:17Z",
        "timestamp": "2026-08-13T04:40:17Z",
        "metrics": {
          "reactions": 1,
          "comments": 7
        },
        "labels": [
          "component/system-probe",
          "team/universal-service-monitoring",
          "qa/done",
          "long review",
          "team/cloud-network-monitoring",
          "stale",
          "internal"
        ],
        "author": "BarFinsdd",
        "state": "open",
        "assignees": [
          "BarFinsdd"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:52993",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Unify converter features behavior",
        "text": "### What does this PR do? Make all extension-related converter features behave like `datadog` and `dogtel`: in the case where the relevant extension is defiled by the user but not added to `service.pipeline`, add this instance instead of defining a `/dd-autoconfigured` one ### Motivation Unify the user experience [OTAGENT-1127](https://datadoghq.atlassian.net/browse/OTAGENT-1127?atlOrigin=eyJpIjoiZjBlOGI1ODVhYzlhNGZjNWExMzczYTM4MjY0NTE5MWYiLCJwIjoiaiJ9) ### Describe how you validated your changes Tests ### Additional Notes [OTAGENT-1127]: https://datadoghq.atlassian.net/browse/OTAGENT-1127?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
        "url": "https://github.com/DataDog/datadog-agent/pull/52993",
        "createdAt": "2026-06-30T17:01:11Z",
        "updatedAt": "2026-08-13T14:01:09Z",
        "timestamp": "2026-08-13T14:01:09Z",
        "metrics": {
          "reactions": 2,
          "comments": 5
        },
        "labels": [
          "qa/done",
          "medium review",
          "team/opentelemetry-agent",
          "stale",
          "internal"
        ],
        "author": "agagniere",
        "state": "open",
        "assignees": [
          "agagniere"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:53030",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "feat(serverless-init): add shared infrastructure for AWS MicroVM cloud service",
        "text": "### What does this PR do? Adds the shared Go infrastructure that AWS MicroVM cloud-service support depends on. This is the first in a stack of PRs that together deliver full MicroVM observability. ### Motivation The Datadog Agent's serverless-init supports multiple cloud platforms (Cloud Run, Container Apps, etc.) via a `CloudService` abstraction. AWS Lambda MicroVMs are a new deployment target where the Agent runs as an init process inside a Firecracker microVM. Each new platform requires small additions in a few central places before the platform-specific code can be wired in cleanly. This PR makes those additions in isolation so the platform-specific MicroVM PR is a clean diff: - **`pkg/metrics/metricsource.go`** — adds `MetricSourceAWSMicroVMEnhanced`, the metric source tag used on all MicroVM enhanced metrics. - **`pkg/serverless/env/env.go`** — adds `MicroVMImageARNEnvVar` (`AWS_LAMBDA_MICROVM_IMAGE_ARN`), the env var the platform injects with the image ARN. - **`pkg/serializer/internal/metrics/origin_mapping.go`** — maps the new MetricSource to its origin string so metrics are routed correctly in the serializer. - **`comp/dogstatsd/server/impl/default_serverless.go` + `enrich.go`** — threads MicroVM origin/tag enrichment through DogStatsD's serverless path. - **`comp/logs-library/processor/json_serverless_init.go`** — adds a JSON log encoder for structured serverless-init logs, needed for MicroVM's log pipeline. ### Describe how you validated your changes - New unit tests cover the origin mapping and DogStatsD enrichment paths. - All changes are additive; no existing behaviour is altered. Run the unit tests for the packages touched by this PR: ``` dda inv test --targets=./comp/dogstatsd/server/impl,./comp/logs-library/processor,./pkg/metrics,./pkg/serializer/internal/metrics,./pkg/serverless/env ``` ### Additional Notes **PR stack** (each PR bases on the one above): 1. **This PR** — shared infrastructure 2. `microvm-02-cloudservice-run` — `Run()` method on `CloudService` interface 3. `microvm-03-lifecycle-config-childhandle` — lifecycle package primitives 4. `microvm-04-lifecycle-forwarder` — HTTP pass-through proxy 5. `microvm-05-lifecycle-heartbeat` — periodic heartbeat metric 6. `microvm-06-lifecycle-server-wire` — lifecycle HTTP server 7. `microvm-07-microvm-service-wiring` — MicroVM `CloudService` + main wiring 8. `microvm-08-sigusr2-on-run` — SIGUSR2 on `/run` for PRNG reseeding",
        "url": "https://github.com/DataDog/datadog-agent/pull/53030",
        "createdAt": "2026-06-30T21:34:33Z",
        "updatedAt": "2026-08-13T17:41:59Z",
        "timestamp": "2026-08-13T17:41:59Z",
        "metrics": {
          "reactions": 2,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "long review",
          "qa/rc-required",
          "team/agent-integrations",
          "team/agent-log-pipelines",
          "team/agent-metric-pipelines",
          "team/agent-devx",
          "team/agent-build",
          "internal",
          "aws-microvm"
        ],
        "author": "litianningdatadog",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:53033",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "feat(serverless-init): add MicroVM lifecycle HTTP forwarder",
        "text": "### What does this PR do? Adds `lifecycle/forwarder.go`: an HTTP proxy that passes MicroVM lifecycle hooks (`/ready`, `/validate`, `/run`, `/resume`, `/suspend`, `/terminate`) from the platform through to the user application, when `DD_AWS_MICROVM_USER_APP_PORT` is set. Key behaviours: - Mirrors status code, response body (up to 1 MiB), and `Content-Type` back to the platform so the platform sees the user app's response, not the agent's. - Does not follow redirects returned by the user app — a 3xx is mirrored back as-is instead of being silently followed, which would otherwise replay a POST as a GET (dropping the body) and report the redirect target's response instead of the hook's own. - `/ready` and `/validate` perform a TCP dial-wait before forwarding: the forwarder retries until the user app's port is reachable or the timeout expires. This absorbs the race between the platform's first `/ready` and the user app's TCP listener coming up. - `/run`, `/resume`, `/suspend`, `/terminate` forward with a short deadline (`DD_AWS_MICROVM_FORWARD_TIMEOUT_MS`, default 1 s), which is appropriate since these are informational hooks with tight platform deadlines. Also lowers `DefaultHeartbeatInterval` from 5 minutes to 10 seconds, per review feedback: relying on a steady multi-minute submission for billing is risky since a missed or double-submitted point has outsized impact. Emitting more frequently and deduping downstream is safer. ### Motivation By default the agent handles all lifecycle hooks autonomously — it answers `/ready` based on child-process liveness, emits metrics, flushes telemetry, and so on. But some user applications also need to react to lifecycle events (e.g. warm their own caches on `/run`, checkpoint state on `/suspend`). The forwarder enables this opt-in pass-through mode: the agent does its own work _and_ lets the user app participate in each hook. The TCP dial-wait on `/ready` and `/validate` is especially important: the platform sends `/ready` as soon as the VM boots, which is often before the user app has had time to bind its port. ### Describe how you validated your changes - `forwarder_test.go` covers: mirror of status/body/headers, TCP wait-for-port logic, dial-error → 503, deadline → 504, body truncation, the sidecar-mode guard, and that redirects from the user app are mirrored rather than followed. Run the relevant unit tests locally: ``` dda inv test --targets=./cmd/serverless-init/lifecycle ``` ### Additional Notes **PR stack** — this is PR 4/8: 1. `microvm-01-foundation` — shared infrastructure ✓ 2. `microvm-02-cloudservice-run` — `Run()` on `CloudService` ✓ 3. `microvm-03-lifecycle-config-childhandle` — lifecycle config + child-handle ✓ 4. **This PR** — HTTP pass-through forwarder 5. `microvm-05-lifecycle-heartbeat` — periodic heartbeat metric 6. `microvm-06-lifecycle-server-wire` — lifecycle HTTP server 7. `microvm-07-microvm-service-wiring` — MicroVM `CloudService` + main wiring 8. `microvm-08-sigusr2-on-run` — SIGUSR2 on `/run`",
        "url": "https://github.com/DataDog/datadog-agent/pull/53033",
        "createdAt": "2026-06-30T21:36:15Z",
        "updatedAt": "2026-08-13T17:49:32Z",
        "timestamp": "2026-08-13T17:49:32Z",
        "metrics": {
          "reactions": 2,
          "comments": 4
        },
        "labels": [
          "long review",
          "aws-microvm"
        ],
        "author": "litianningdatadog",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:53084",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "feat(serverless-init): wire MicroVM lifecycle server config from env vars",
        "text": "## Summary This adds the environment-variable-driven wiring code for the MicroVM lifecycle HTTP server: reading `DD_AWS_MICROVM_LIFECYCLE_PORT` and the other lifecycle-related env vars, and assembling the config needed to construct the server. No HTTP server or handlers are introduced yet — those land in the next PR in this stack. The motivation is to let the AWS MicroVM platform's serverless-init sidecar/init-container learn, purely from its environment, which port to listen on and how to configure the lifecycle server, without hardcoding values or requiring code changes per deployment. ## Stack This is **PR 1 of 4** in a split of https://github.com/DataDog/datadog-agent/pull/53035 (\"feat(serverless-init): add MicroVM lifecycle HTTP server and env-var wiring\"), which was too large to review as a single PR. The full stack, in merge order: 1. **(this PR)** wire MicroVM lifecycle server config from env vars 2. add standalone MicroVM lifecycle HTTP server 3. propagate MicroVM ID to logs and trace tags 4. add MicroVM lifecycle user-app forwarder pass-through The tip of PR 4 is byte-for-byte identical to the original `tianning.li/microvm-06-lifecycle-server-wire` branch. ## Test plan ``` bazel test //cmd/serverless-init/lifecycle:lifecycle_test ``` - [x] `bazel build //cmd/serverless-init/lifecycle:lifecycle` - [x] `bazel test //cmd/serverless-init/lifecycle:lifecycle_test` - [x] `dda inv linter.go --targets=./cmd/serverless-init/lifecycle` 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
        "url": "https://github.com/DataDog/datadog-agent/pull/53084",
        "createdAt": "2026-07-01T16:12:07Z",
        "updatedAt": "2026-08-13T17:53:08Z",
        "timestamp": "2026-08-13T17:53:08Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "long review",
          "aws-microvm"
        ],
        "author": "litianningdatadog",
        "state": "open",
        "assignees": [],
        "change": "new"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:53085",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "feat(serverless-init): add standalone MicroVM lifecycle HTTP server",
        "text": "## Summary This adds the MicroVM lifecycle HTTP server itself: an `http.Server` listening on the configured port, handling the six lifecycle hooks the AWS MicroVM platform sends — `/ready`, `/validate`, `/run`, `/resume`, `/suspend`, and `/terminate` — in **standalone** mode, i.e. the agent answers each hook itself rather than forwarding it to a user application (that pass-through mode is added later in this stack). The motivation is to give the agent visibility into a MicroVM's full lifecycle without requiring any cooperation from the user's own application: `/ready` reports child-process liveness so the platform knows when it's safe to snapshot; `/run`/`/resume`/`/suspend`/`/terminate` each emit an enhanced lifecycle metric (tagged with the MicroVM instance ID once known), and `/suspend`/`/terminate` additionally flush all pending telemetry (metrics, traces, logs) before responding, since those are the two points where telemetry could otherwise be lost — either frozen into a snapshot or torn down with the VM. `/run`'s request body (the `runHookPayload` a caller passes to `RunMicrovm`) is capped at **1 MiB** via `http.MaxBytesReader` before being buffered; a body exceeding the cap, or any other read error, aborts the handler with a 500 rather than silently forwarding a truncated body. This cap is a self-imposed defensive bound, not a value taken from an AWS-published limit — the AWS Lambda MicroVM reference docs describe `runHookPayload` only qualitatively (tenant IDs, signed URLs, secret references) and state no numeric size limit. ## Stack This is **PR 2 of 4** in a split of https://github.com/DataDog/datadog-agent/pull/53035 (\"feat(serverless-init): add MicroVM lifecycle HTTP server and env-var wiring\"), which was too large to review as a single PR. The full stack, in merge order: 1. wire MicroVM lifecycle server config from env vars 2. **(this PR)** add standalone MicroVM lifecycle HTTP server 3. propagate MicroVM ID to logs and trace tags 4. add MicroVM lifecycle user-app forwarder pass-through The tip of PR 4 is byte-for-byte identical to the original `tianning.li/microvm-06-lifecycle-server-wire` branch. Note: this PR is somewhat larger than the ~300-line target used elsewhere in the stack — the server skeleton (types, `NewServer`, all six handlers, the shared flush path) is a single cohesive, self-contained unit and its test suite cannot be meaningfully subdivided without breaking that self-containment. ## Test plan ``` bazel test //cmd/serverless-init/lifecycle:lifecycle_test ``` - [x] `bazel build //cmd/serverless-init/lifecycle:lifecycle` - [x] `bazel test //cmd/serverless-init/lifecycle:lifecycle_test` - [x] `dda inv linter.go --targets=./cmd/serverless-init/lifecycle` 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
        "url": "https://github.com/DataDog/datadog-agent/pull/53085",
        "createdAt": "2026-07-01T16:12:21Z",
        "updatedAt": "2026-08-13T17:57:27Z",
        "timestamp": "2026-08-13T17:57:27Z",
        "metrics": {
          "reactions": 2,
          "comments": 5
        },
        "labels": [
          "long review",
          "aws-microvm"
        ],
        "author": "litianningdatadog",
        "state": "open",
        "assignees": [],
        "change": "new"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:53092",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "feat(serverless-init): add ProcessHooks for subprocess liveness tracking",
        "text": "### What does this PR do? Adds a `*ProcessHooks` parameter (`OnAlive`/`OnDead`) to `mode.RunInit` and its internal `execute()`, so a caller can be notified when the spawned user process starts and exits. `mode.Conf.Runner` is dropped for init-container mode — its field type (`func(*serverlessLog.Config) error`) can no longer match `RunInit`'s new two-argument signature, so `main.go` switches from calling `modeConf.Runner(logConfig)` to `cloudService.Run(modeConf, logConfig)`, which already exists on the `CloudService` interface and produces identical behavior for every existing cloud service (sidecar → `RunSidecar`, init-container → `RunInit` with `nil` hooks). Also adds `cloudservice.MicroVM`, a `CloudService` implementation for AWS Lambda MicroVMs, and a `LifecycleContext` type carried on `TracingContext.LifecycleCtx`: - `GetTags` parses `DD_AWS_MICROVM_IMAGE_ARN` for `region`/`account_id`/`image_name` (falling back to `\"unknown\"` for any field it can't parse). - `GetEnhancedMetricTags` derives base/usage tag sets from those tags. - `Init` reads a `LifecycleContext` (metric/log flushers, trace-tag/log-tag setters, flush timeout, sidecar flag) and constructs + starts the lifecycle hook server. - `Run` spawns the user process via `mode.RunInit`, binding `ProcessHooks.OnAlive`/`OnDead` to the lifecycle server's child so its `/ready` check reflects real liveness. Sidecar mode is fatal for MicroVM — there's no child process to track, so `/ready` would silently return 503 forever instead of surfacing the misconfiguration. - `Shutdown` stops the lifecycle server within a bounded timeout so in-flight `/suspend`/`/terminate` requests can complete before the metric/trace agents tear down. - MicroVM supports both amd64 and arm64 (every other cloud service here is amd64-only). `MicroVM` is **not yet reachable**: `GetCloudServiceType` still doesn't know about it, so nothing in the running agent changes yet. Also fixes review feedback from Copilot on this PR: - `mode/initcontainer_mode.go`: `hooks.OnDead`'s defer was registered only inside the `hooks.OnAlive != nil` branch, and after `OnAlive()` ran. An `OnDead`-only hook never fired, and `OnDead` wouldn't fire if `OnAlive` panicked. Now deferred unconditionally right after `cmd.Start()` succeeds. - `main.go`: fixed a non-gofmt-compliant import grouping. - `cloudservice/microvm_test.go`: reworded stale `/launch` references (test names, a path variable, assertion messages) to `/run`, matching the route actually under test. ### Motivation The upcoming MicroVM `CloudService` needs to know whether the customer's process is currently alive so its lifecycle server can answer `/ready` correctly — there's no other signal available once `cmd.Start`/`cmd.Wait` are called deep inside `mode.execute()`. `ProcessHooks` is the minimal hook point for that. `MicroVM` is the core piece of the MicroVM integration: everything needed to answer the lifecycle server's HTTP hooks and track the user process's liveness, in one type that satisfies `CloudService` end-to-end. This is the split of #53036 (`tianning.li/microvm-07-microvm-service-wiring`). Originally planned as 5 independently-reviewable PRs; PR 2 (MicroVM CloudService implementation) has since been merged into this branch, so **this PR now covers PRs 1 and 2 combined**: 1. ~~ProcessHooks plumbing in `mode` package~~ (this PR) 2. ~~MicroVM CloudService implementation (`cloudservice/microvm.go`)~~ (this PR) 3. MicroVM tags/metrics/arch tests 4. MicroVM lifecycle-server tests 5. main.go wiring + CloudService registration (tip == original #53036) ### Describe how you validated your changes ``` dda inv test --targets=./cmd/serverless-init/... ``` 299 tests pass (4 platform-skips). New coverage: - `initcontainer_mode_test.go` pins `OnAlive`/`OnDead` ordering (start → alive → wait → dead), the nil-hooks no-op path, `Conf.Runner` nil-for-init/non-nil-for-sidecar, and two regression tests for the OnDead/OnAlive fix above (`TestExecute_OnDeadOnly_OnAliveNil_StillFires`, `TestExecute_OnAlivePanics_OnDeadStillFires` — both fail against the pre-fix code). - `mode_windows_test.go` covers the updated stub signature. - `cloudservice/microvm_test.go` and `cloudservice/service_test.go` cover `MicroVM`'s tag parsing, enhanced-metric tags, init/run/shutdown, and selection priority over Cloud Run. ### Additional Notes No `BUILD.bazel` changes needed — `cloudservice/`, `mode/`, and `cmd/serverless-init/*.go` are Gazelle-excluded (see root `BUILD.bazel` lines 97-100).",
        "url": "https://github.com/DataDog/datadog-agent/pull/53092",
        "createdAt": "2026-07-01T18:53:25Z",
        "updatedAt": "2026-08-13T17:57:27Z",
        "timestamp": "2026-08-13T17:57:27Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "aws-microvm"
        ],
        "author": "litianningdatadog",
        "state": "open",
        "assignees": [],
        "change": "new"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:53246",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "HA(e2e): Move tests to RC fakeintake to fix flakiness",
        "text": "### What does this PR do? Update HA Agent failover test to rely on the fakeintake RC instead of the real backend, that is very flaky because of conflicts ### Motivation Fix test and test new RC feature in fakeitake ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/53246",
        "createdAt": "2026-07-06T08:59:06Z",
        "updatedAt": "2026-08-12T14:40:34Z",
        "timestamp": "2026-08-12T14:40:34Z",
        "metrics": {
          "reactions": 2,
          "comments": 13
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "medium review",
          "team/container-integrations",
          "ask-review",
          "team/agent-devx",
          "team/agent-build",
          "internal",
          "team/network-device-monitoring-core"
        ],
        "author": "KevinFairise2",
        "state": "closed",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:53411",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "sbom: remove the Trivy on-disk cache",
        "text": "SBOM scanning kept a BoltDB cache on disk under sbom.cache_directory to reuse per-layer analysis results across scans. In practice it earned little. Only the legacy tarball scan path used it. The overlayfs path has run without it by default since #48004, filesystem scans never used it, and image rescans are off by default. Remove the cache subsystem entirely instead of porting it to memory. Every scan now uses the in-memory cache that the overlayfs and filesystem paths already used. It is created per scan and freed when the scan returns, so Trivy still gets the cache object it needs within a scan without anything touching disk. The in-memory cache is guarded by a mutex so a fast scan that analyzes image layers in parallel can store results safely. This drops the BoltDB layer, the persistent LRU cache, the workloadmeta garbage collector, and the scanner janitor. It also removes a leaked telemetry goroutine and a latent bug where the sbomgen CLI could create a fanal directory in the working directory. The options sbom.cache_directory, sbom.clear_cache_on_exit, sbom.cache.max_disk_size, sbom.cache.clean_interval, and sbom.container_image.overlayfs_disable_cache are removed and now ignored. The telemetry metrics sbom.cache_disk_size, sbom.cache_hits_total, and sbom.cache_misses_total are removed.",
        "url": "https://github.com/DataDog/datadog-agent/pull/53411",
        "createdAt": "2026-07-08T19:59:01Z",
        "updatedAt": "2026-08-12T15:47:51Z",
        "timestamp": "2026-08-12T15:47:51Z",
        "metrics": {
          "reactions": 0,
          "comments": 5
        },
        "labels": [
          "team/agent-security",
          "qa/done",
          "long review",
          "team/container-integrations",
          "team/agent-configuration",
          "team/agent-build",
          "stale",
          "internal"
        ],
        "author": "0intro",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:53415",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[DO NOT MERGE] One-off e2e run with ADP enabled by default",
        "text": "## Summary Temporarily flips \\`data_plane.enabled\\` from \\`false\\` to \\`true\\` in the agent's compiled-in config default so that every e2e test in the full suite runs against ADP without requiring per-test changes or test duplication. The change is throwaway — close without merging once the CI run completes. This is the same config knob used by the AMP ADP test helpers (DADP-72, see [Slack thread](https://dd.slack.com/archives/C070PQKLLP5/p1783453441368899)). ## How to kick off the full e2e suite Trigger a new pipeline on this branch and set the CI variable: \\`\\`\\` RUN_E2E_TESTS=on \\`\\`\\` That variable hits the \\`if_run_all_e2e_tests\\` rule in \\`.gitlab-ci.yml\\` and flips all e2e jobs from manual to \\`on_success\\`. ## CI findings (ADP 1.5.1, branch jszwedko/run-ci-adp-enabled) ### Fixed in this PR - **Windows MSI \\`status_command_infos\\`**: All MSI test variants fail because \\`agent_behaviour.go\\` asserts the status output contains \"DogStatsD\". When ADP handles DSD, the \\`DogStatsD\\` status section is absent (the \\`EnabledInternal()\\` guard prevents registering the status provider). Fixed by accepting either \"DogStatsD\" or \"Dogstatsd Metric Sample\" (always present in the Aggregator section). ### Known pre-existing failures (ADP limitations, tracked in Saluki) - **\\`TestReplayWithTagEnrichment\\`** — ADP doesn't enrich replayed DSD packets with current tagger state. Tracked in Saluki. ### New failures requiring Saluki fixes - **Container DSD tests (ECS \\`TestDogtstatsdUDP\\`, \\`TestDogtstatsdUDS\\`; Kind \\`dogstatsd-uds\\` pods)**: In container environments (ECS, K8s/Kind), fakeintake is configured as \\`DD_ADDITIONAL_ENDPOINTS\\` rather than \\`dd_url\\`. ADP doesn't appear to forward DogStatsD metrics to \\`additional_endpoints\\`, so no metrics arrive at fakeintake. In VM tests where fakeintake IS \\`dd_url\\` (primary endpoint), DSD forwarding works. This points to an \\`additional_endpoints\\` forwarding gap in ADP. - The Kind \\`dogstatsd-uds\\` pods fail to become Ready — the workload pods mount \\`/var/run/datadog/dsd.socket\\` as a HostPath volume (type \\`Socket\\`). With ADP enabled, the core agent's DSD server doesn't start (so no socket is created); ADP must create it but apparently doesn't complete socket setup in time or at the expected path. - Root cause: ADP \\`additional_endpoints\\` forwarding — active Saluki config migration work (issues #2312–#2316) may be the upstream cause. ### Other failures under investigation - **Anomaly detection tests** — under investigation, may be ADP-independent - **GPU tests** — under investigation ## Test plan - No new tests. The goal is to observe which existing e2e tests break when ADP is the default. - \\`new-e2e-amp-adp\\` (existing) runs the AMP suite filtered to \\`--run \"ADP\"\\` tests; this PR covers the rest. **DO NOT MERGE** — this default flip must not land on \\`main\\`.",
        "url": "https://github.com/DataDog/datadog-agent/pull/53415",
        "createdAt": "2026-07-08T21:31:58Z",
        "updatedAt": "2026-08-12T22:19:24Z",
        "timestamp": "2026-08-12T22:19:24Z",
        "metrics": {
          "reactions": 1,
          "comments": 6
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "long review",
          "team/agent-configuration",
          "team/agent-metric-pipelines",
          "team/agent-devx",
          "team/windows-products",
          "internal",
          "team/fleet-remediation",
          "team/fleet-automation"
        ],
        "author": "jszwedko",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:53496",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Add support for renamed settings",
        "text": "### What does this PR do? Add support for renamed settings This PR introduce a rename mechanism within the config. It also use the warning from the config to raise error about unknown keys.",
        "url": "https://github.com/DataDog/datadog-agent/pull/53496",
        "createdAt": "2026-07-10T10:19:18Z",
        "updatedAt": "2026-08-13T15:54:41Z",
        "timestamp": "2026-08-13T15:54:41Z",
        "metrics": {
          "reactions": 1,
          "comments": 2
        },
        "labels": [
          "changelog/no-changelog",
          "team/agent-apm",
          "team/ebpf-platform",
          "qa/done",
          "long review",
          "team/agent-configuration",
          "team/agent-devx",
          "team/agent-build",
          "internal",
          "team/fleet-remediation",
          "team/fleet-automation"
        ],
        "author": "hush-hush",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:53517",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "WIF-48: add delegated-auth dual-shipping foundation",
        "text": "## Summary This PR contains the reusable delegated-auth foundation for WIF dual shipping: - extends the delegated-auth component so an instance can update an additional-endpoint key in either map- or list-shaped configuration - adds shared helpers for normalizing list-shaped endpoints and reading case-insensitive fields - recognizes pending `DELA(...)` directives so consumers can avoid sending them as literal API keys - exchanges proofs against the configured target site rather than always using `dd_url` - covers token-domain parsing, component updates, and directive handling with unit tests The Agent subsystem integration is intentionally split into a stacked follow-up PR. It wires this foundation into config setup, forwarder, logs, process, orchestrator, and trace-agent reload/proxy behavior. ## Validation - `bazel test //comp/core/delegatedauth/... //pkg/config/utils/... --build_tests_only` ## Review note The local subagent reviewer service failed before startup, so its adversarial and security passes could not run. No review findings were produced.",
        "url": "https://github.com/DataDog/datadog-agent/pull/53517",
        "createdAt": "2026-07-10T17:39:01Z",
        "updatedAt": "2026-08-13T14:48:10Z",
        "timestamp": "2026-08-13T14:48:10Z",
        "metrics": {
          "reactions": 1,
          "comments": 7
        },
        "labels": [
          "team/agent-apm",
          "qa/done",
          "long review",
          "team/agent-runtimes",
          "team/agent-configuration",
          "team/agent-log-pipelines",
          "team/agent-metric-pipelines",
          "team/container-experiences",
          "team/agent-build",
          "team/kubernetes-experiences",
          "internal",
          "team/fleet-automation"
        ],
        "author": "wynbennett",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:53568",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[procmgr] Show profile and user in list and describe",
        "text": "### What does this PR do? Expose spawn identity in the process manager API and `dd-procmgr` CLI: - `list`: adds `profile` and `user` columns (table + JSON) - `describe`: adds `Profile`, `User`, and `Runtime User` (only when the process is running and lookup succeeds) Proto changes: - `Process`: `profile`, `user` - `ProcessDetail`: `profile`, `user`, `runtime_user` Implementation notes: - `profile` is derived from the process name (`agent` / `privileged`) - `user` is the intended / last-spawn account, stored on `ManagedProcess` and refreshed on spawn - `runtime_user` is resolved from the OS at describe time (Windows token owner / Linux `/proc` + `getpwuid`) - Windows display formatting is centralized in `AccountName` ### Motivation After Windows spawn profiles land, operators need a simple way to see how each managed child is spawned without reading code or registry state. Showing `profile` and `user` in `list`/`describe` makes SCM migration behavior visible (e.g. process-agent as `privileged` / `NT AUTHORITY\\SYSTEM` vs other children as `agent` / installer user). `runtime_user` in `describe` helps debug cases where the running PID differs from the intended spawn account. ### Describe how you validated your changes - `cargo test --lib --bin dd-procmgr` (procmgr Rust unit tests) - `dda inv test --targets=./pkg/procmgr/coat/...` - Updated procmgr CLI e2e tests for `profile` / `user` / `runtime_user` output ### Additional Notes - `user` reflects spawn policy (intended or last used), not a live registry re-read on every query - `runtime_user` is omitted from `list` and from `describe` when PID is unset or lookup fails (debug log only) - No COAT/metrics changes in this PR",
        "url": "https://github.com/DataDog/datadog-agent/pull/53568",
        "createdAt": "2026-07-13T08:47:55Z",
        "updatedAt": "2026-08-13T11:32:24Z",
        "timestamp": "2026-08-13T11:32:24Z",
        "metrics": {
          "reactions": 1,
          "comments": 26
        },
        "labels": [
          "qa/done",
          "long review",
          "team/agent-runtimes",
          "team/agent-devx",
          "team/agent-build",
          "team/windows-products",
          "internal"
        ],
        "author": "jose-manuel-almaza",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:53641",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Add Windows `powershell` check",
        "text": "### What does this PR do? Adds a new Windows `powershell` check that runs admin-allowlisted, read-only PowerShell cmdlets and maps their output objects to metrics and tags. The data model mirrors the WMI check — `metrics`, `tag_by`, `tags`, `filters`, and `tag_queries` (joins) — so each cmdlet output object is a \"row\" and its properties are \"columns.\" Key pieces: - **Config** (`config.go`): per-instance YAML parsing with dual positional-tuple / mapping forms; supports a \"virtual\" metric (constant value, tags carry the signal) for all-string cmdlet output. - **Allowlist** (`allowlist.go`): admin-owned policy read from the fixed, ACL-protected path `C:\\ProgramData\\Datadog\\protected\\powershell_allowlist.yaml`, constraining cmdlets, parameters, and values. Fails closed if the file is missing, malformed, or not owned by an administrator. - **Command generation** (`command.go`): parameter values are bound to the cmdlet as data (splatting + single-quoted literals + a runtime `Get-*` verb re-check), never interpolated, so untrusted values cannot inject PowerShell. - **Execution** (`powershell.go`): runs the cmdlet under a per-invocation timeout with a restricted environment and a capped output buffer, then maps rows to metrics and tags. Behavior refinements included: - A non-virtual metric whose property is missing or non-numeric causes `Run()` to error out (logged at error level, surfaced in `agent status`) rather than silently emitting nothing. - A negative per-instance `timeout` logs a warning and falls back to the default 30s. ### Motivation Windows Server exposes a large amount of operational data through PowerShell cmdlets that have no dedicated Datadog integration. This check lets customers point the Agent at a read-only cmdlet and turn its output into metrics and tags declaratively, with no custom code — the cmdlet analog of the WMI check. ### Describe how you validated your changes `dda inv test --targets=./pkg/collector/corechecks/system/powershell` — 27/27 pass, covering config parsing (incl. timeout handling), allowlist enforcement, injection-safe command generation, and value/tag mapping. ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/53641",
        "createdAt": "2026-07-14T14:38:46Z",
        "updatedAt": "2026-08-12T18:29:14Z",
        "timestamp": "2026-08-12T18:29:14Z",
        "metrics": {
          "reactions": 1,
          "comments": 6
        },
        "labels": [
          "long review",
          "qa/rc-required",
          "team/agent-runtimes",
          "team/agent-devx",
          "team/agent-build",
          "team/windows-products",
          "internal"
        ],
        "author": "mrafi97",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:53700",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[NTWK-799] Allow custom namespaces on Synthetics to enable NDM resolution",
        "text": "### What does this PR do? This PR modifies the Synthetics Collector to: - Send NDM namespace on Network Path tests by default (in line with the Network Path integration) - Allows the back end to send `namespace` as part of a test config and have that namespace propagate to the Network Path backend. UI changes would be required for this path to be used. ### Motivation NTWK-799, a customer reported that NDM devices aren't showing in their Network Paths, upon investigation these were Agent based Synthetic tests and the devices in question have a specific namespace that they're a part of. Today, the Synthetics runner never reads the `namespace` from anywhere. This change will put it in line with other Network Path tests and the customer should in the short-medium term just set this in the YAML until the changes can be implemented on the Synthetics UI. ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/53700",
        "createdAt": "2026-07-15T20:17:18Z",
        "updatedAt": "2026-08-12T15:53:59Z",
        "timestamp": "2026-08-12T15:53:59Z",
        "metrics": {
          "reactions": 1,
          "comments": 6
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "medium review",
          "team/agent-build",
          "team/network-path",
          "internal"
        ],
        "author": "ken-schneider",
        "state": "closed",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:53732",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "APM: Enable convert-traces feature by default (take 2)",
        "text": "This is attempt 2 due to needing to revert last version ## Summary - Flips the trace-agent's `convert-traces` v1.0 payload-conversion path to be **enabled by default**. - Introduces a new opt-out feature flag, `disable-convert-traces`, for teams/customers who need to revert to the legacy code path. - Updates `pkg/trace/api/api_test.go` to reflect the new default (removes the test-only force-enable of `convert-traces`; the \"without conversion\" test now sets `disable-convert-traces` instead of clearing the whole `Features` map). - Update serverless use cases to also affect v1 paths (e.g. modify span, discard span) The long term plan here is to deprecate and remove the non-V1 paths. This code change adds some duplicated code for the serverless v1 span usage, but the plan is to remove the old path entirely after we have confidence with customers running the conversion logic and no issues found. ## Test plan - [x] `dda inv trace-agent.build` succeeds - [x] `dda inv test --targets=./pkg/trace/api/...` — all 584 tests pass - [x] We have been dogfooding this conversion logic in staging and production across ALL DCs - [x] APM System-tests pass with conversion logic enabled - [ ] **TODO** Manually trigger APM system-tests to validate on all tracers",
        "url": "https://github.com/DataDog/datadog-agent/pull/53732",
        "createdAt": "2026-07-16T12:59:13Z",
        "updatedAt": "2026-08-12T18:36:49Z",
        "timestamp": "2026-08-12T18:36:49Z",
        "metrics": {
          "reactions": 1,
          "comments": 6
        },
        "labels": [
          "team/agent-apm",
          "long review",
          "team/injection-platform",
          "team/agent-build",
          "stale",
          "internal"
        ],
        "author": "ajgajg1134",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:53753",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "feat(remote-config): expose remote config state over the agent IPC HTTP API",
        "text": "> **⚠️ Deferred (2026-07-28).** Paused pending alignment with the remote-config team on whether `getRemoteConfigState` should be backend-sourced instead of Agent-local. During review, Dario Meloni pointed out the backend already receives this data on every RC poll; investigation confirmed that's true but found no viable customer-scoped backend replacement today (the internal `remote-config-admin` tool is support-only and warehouse-lagged; Fleet Automation's customer-scoped API lacks apply-state data). See the addendum in the [RFC](https://datadoghq.atlassian.net/wiki/spaces/FRM/pages/6996001355) for the full discussion. The other three read actions plus flare generation (#53754, #53756) do not depend on this endpoint and are proceeding independently — see the updated stacked series below. ### What does this PR do? Adds a `GET /agent/remote-config/state` endpoint to the Agent's authenticated IPC HTTP (CMD) API that returns the Remote Config repositories state as JSON. It exposes the same data as the existing `AgentSecure.GetConfigState` gRPC method, registered through the standard `agent_endpoint` provider group from the `rcservice` component (so it inherits the IPC auth-token middleware). When remote config is disabled it responds `503` with a not-initialized error. ### Motivation Originally the first change in a stacked series that exposes a subset of `datadog-agent` CLI actions through the Datadog MCP server, using Action Platform + the co-located Private Action Runner (PAR) as the transport. This endpoint would unblock the `getRemoteConfigState` PAR action (#53755) — now deferred alongside it (see above). ### Describe how you validated your changes `bazel build //comp/remote-config/rcservice/impl:impl` passes; pre-push `go-linter` and `go-test` hooks pass. ### Additional Notes **Status: deferred**, not closed — kept open/draft as the design question is resolved with the remote-config team. `getStatus`/`getDiagnose`/`getConfig`/`generateFlare` no longer depend on this PR (their branches have been rebased to drop this dependency; see #53754/#53756). --- ### Full stacked series **Shipping now (no dependency on this PR):** **datadog-agent** (Go execution layer): 1. DataDog/datadog-agent#53754 — `com.datadoghq.agent` bundle, read-only actions (`getStatus`, `getDiagnose`, `getConfig`) 2. DataDog/datadog-agent#53756 — `generateFlare` action (mutating, confirm-gated) **dd-source** (catalog + MCP tools + authz): 3. ddoghq/dd-source#22260 — `com.datadoghq.agent` private bundle manifest (three read actions + flare) 4. ddoghq/dd-source#22261 — read-only MCP tools 5. ddoghq/dd-source#22262 — confirm-gated mutating MCP tool 6. ddoghq/dd-source#22263 — MCP OBO allow-list (optional hardening) Cross-repo: land datadog-agent #53754/#53756 and dd-source #22260, and ship an agent build containing them, before the dd-source MCP tools (#22261–#22262) work end-to-end. **Deferred (this PR + its dependent):** - DataDog/datadog-agent#53753 — this PR - DataDog/datadog-agent#53755 — `getRemoteConfigState` action Parked pending alignment with the remote-config team — see the RFC addendum linked above.",
        "url": "https://github.com/DataDog/datadog-agent/pull/53753",
        "createdAt": "2026-07-16T15:46:14Z",
        "updatedAt": "2026-08-12T16:22:54Z",
        "timestamp": "2026-08-12T16:22:54Z",
        "metrics": {
          "reactions": 2,
          "comments": 6
        },
        "labels": [
          "team/remote-config",
          "qa/done",
          "medium review",
          "team/agent-build",
          "stale",
          "internal"
        ],
        "author": "louis-cqrl",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:53864",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "e2e: add local Docker-based Kind provisioner as a cheaper alternative to AWS-VM",
        "text": "## Summary - Adds a local Docker-based Kind provisioner (`testing/provisioners/local/kubernetes`) as a cheaper alternative to the existing AWS-VM-backed Kind provisioner — no dedicated EC2 VM needed for most Kind-based E2E tests. - Brings the local provisioner to feature parity with the AWS one: fakeintake options (memory/retention/dddev-forwarding), dogstatsd-standalone/test-workload/argo-rollout deployment helpers, and a diagnose-on-failure cluster-state dump. - Adds a `kindprovisioner` switch package (`testing/provisioners/kindprovisioner`) that picks between the AWS-VM and local provisioners based on `E2E_PROVISIONER=kind-local` / `E2E_DEV_LOCAL=true`, so test suites don't have to duplicate the switch logic. - Migrates `test/new-e2e/tests/containers/kindvm_test.go` (`TestKindSuite`) onto the shared switch helper. - Adds a new `new-e2e-containers-kind-local` GitLab CI job that runs `TestKindSuite` against a Kind cluster created directly on a `docker-in-docker:amd64` runner, in parallel with (not replacing) the existing `new-e2e-containers-k8s-latest` AWS-VM job — both required to pass. ## Test plan - [x] `dda inv linter.go` on all touched Go packages (0 issues) - [x] `dda inv gitlab.compute-gitlab-ci-config` to confirm the new job resolves correctly (before_script, needs, rules, variables) - [x] `dda inv linter.full-gitlab-ci` / `linter.gitlab-ci-shellcheck` (PASS) - [ ] Verify `new-e2e-containers-kind-local` and `new-e2e-containers-k8s-latest` both pass in this PR's pipeline with equivalent test behavior 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
        "url": "https://github.com/DataDog/datadog-agent/pull/53864",
        "createdAt": "2026-07-20T16:08:15Z",
        "updatedAt": "2026-08-12T16:22:47Z",
        "timestamp": "2026-08-12T16:22:47Z",
        "metrics": {
          "reactions": 1,
          "comments": 8
        },
        "labels": [
          "team/container-platform",
          "long review",
          "team/container-integrations",
          "team/agent-devx",
          "team/agent-build",
          "stale",
          "internal"
        ],
        "author": "KevinFairise2",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:53905",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[FA] Categorize installer OOM/resource-exhaustion errors",
        "text": "## Summary A week-long Error Tracking sweep of installer error categories surfaced this: when the fleet-automation daemon execs a fresh `datadog-installer` child process (for state refresh, install, or experiment operations) and that child crashes at Go-runtime bootstrap because the host is out of memory, threads, or paging capacity — e.g. `fatal error: pageAlloc: out of memory`, `out of memory allocating heap arena metadata`, `runtime: failed to create new OS thread ... errno=11`, `VirtualAlloc ... errno=1455`, `paging file is too small` — the raw multi-line Go panic stack trace gets wrapped verbatim into the returned error via `\"run failed: %w\\n%s\"`. This surfaces to users/Error Tracking as an opaque wall of Go-runtime internals with no actionable signal, indistinguishable from any other subprocess failure. ## Change `pkg/fleet/installer/exec/installer_exec.go`: - Added `isResourceExhaustionCrash(output []byte) bool`, which pattern-matches the known OOM/thread-exhaustion signatures listed above. - Added a sentinel `var ErrResourceExhausted = errors.New(\"installer subprocess crashed due to host resource exhaustion (memory/thread limit)\")`. - `(*installerCmd).Run()` now checks the subprocess's captured stderr against these signatures before falling back to the generic error path. On a match, it returns `fmt.Errorf(\"run failed: %w: %w\", ErrResourceExhausted, err)` — so `errors.Is(err, ErrResourceExhausted)` works for programmatic handling and Error Tracking — instead of echoing the full multi-KB stack trace into the primary error string. The full raw output is still preserved via `pkg/util/log.Debugf` for diagnostics. - Scoped strictly to error categorization/message quality: no retry logic, no pre-flight memory checks, no other call sites touched. `pkg/fleet/installer/exec/installer_exec_test.go` (new): - Table-driven unit tests for `isResourceExhaustionCrash` covering each known signature plus unrelated/empty output (expected `false`). - A test confirming `errors.Is` still unwraps correctly through the `%w: %w` double-wrap used in `Run()`. `pkg/fleet/installer/exec/BUILD.bazel`: - Added the `go_test` target for the new test file and the `pkg/util/log` dependency. ## Status Draft, pending review. This is split out of #53904, which combined this fix with an unrelated Windows-MSI-side fix; splitting per the reviewer's request since the two are independent (different languages, different files, no shared code paths). ## Test plan - [x] `go build ./pkg/fleet/installer/...` passes - [x] `go vet ./pkg/fleet/installer/exec/...` passes - [x] `go test ./pkg/fleet/installer/exec/...` passes, including the new tests - [x] Pre-commit hooks (`go-fmt`, `go-mod-tidy`, `copyright`) passed locally - [ ] Manual/synthetic verification that an installer subprocess OOM crash now returns an error satisfying `errors.Is(err, exec.ErrResourceExhausted)` in a real deployment",
        "url": "https://github.com/DataDog/datadog-agent/pull/53905",
        "createdAt": "2026-07-21T09:03:43Z",
        "updatedAt": "2026-08-12T16:22:44Z",
        "timestamp": "2026-08-12T16:22:44Z",
        "metrics": {
          "reactions": 1,
          "comments": 6
        },
        "labels": [
          "medium review",
          "team/agent-build",
          "team/windows-products",
          "stale",
          "internal"
        ],
        "author": "coignetp",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:53936",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "feat(privateactionrunner): sync kubernetes admissionregistration, networking, and cluster CRD bundles",
        "text": "## Intent This PR syncs new Kubernetes action bundles from [dd-source PR #26413](https://github.com/ddoghq/dd-source/pull/26413) into the private action runner embedded in the Datadog Agent. Three sets of changes are synced: **`pkg/privateactionrunner/bundles/kubernetes/admissionregistration/`** — new bundle, full CRUD for the four `admissionregistration/v1` types: `MutatingWebhookConfiguration`, `ValidatingWebhookConfiguration`, `ValidatingAdmissionPolicy`, and `ValidatingAdmissionPolicyBinding`. All four are cluster-scoped, so none of the handlers take a namespace input. **`pkg/privateactionrunner/bundles/kubernetes/networking/`** — new bundle, full CRUD for all five `networking/v1` resources: `Ingress`, `IngressClass`, `IPAddress`, `NetworkPolicy`, and `ServiceCIDR`. `Ingress` and `NetworkPolicy` are namespaced; the remaining three are cluster-scoped. **`pkg/privateactionrunner/bundles/kubernetes/customresources/`** — extends the existing bundle with seven cluster-scoped custom object actions: `getClusterCustomObject`, `listClusterCustomObject`, `createClusterCustomObject`, `updateClusterCustomObject`, `patchClusterCustomObject`, `deleteClusterCustomObject`, `deleteMultipleClusterCustomObjects`. These use the dynamic client without `.Namespace()`, enabling CRUD on cluster-scoped CRDs. All files were synced from the corresponding `dd-source` generated handlers with `PAR_SYNC_EXCLUDE` blocks stripped and import paths rewritten (`dd-source/domains/actionplatform/apps/private-runner/src/` → `DataDog/datadog-agent/pkg/privateactionrunner/`). The two new bundles are registered in `bundles/registry.go`. ## Surface changes No surface changes. New action FQNs are registered in the existing private action runner bundle map and are callable via the same `com.datadoghq.kubernetes.*` namespace used by all other Kubernetes AP actions. ## Automated review results | Agent | Findings | Fixed | Remaining | |-------|----------|-------|-----------| | Go best practices | 4 | 1 (TrimSuffix style) | 3 (pre-existing patterns shared with namespaced handlers) | ## QA guidelines CI is green. To validate locally, deploy a private action runner connected to a cluster and execute one of the new read actions (e.g. `com.datadoghq.kubernetes.networking.listIngress` or `com.datadoghq.kubernetes.admissionregistration.getMutatingWebhookConfiguration`) via the workflow automation UI.",
        "url": "https://github.com/DataDog/datadog-agent/pull/53936",
        "createdAt": "2026-07-21T17:35:13Z",
        "updatedAt": "2026-08-12T14:37:59Z",
        "timestamp": "2026-08-12T14:37:59Z",
        "metrics": {
          "reactions": 2,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "team/container-platform",
          "long review",
          "team/agent-build",
          "team/action-platform",
          "internal"
        ],
        "author": "BaptisteFoy",
        "state": "closed",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:53982",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Pedro.cordeiro/macos ec2 snapshot poc",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Introduces a shared pool of macOS EC2 Dedicated Hosts for the E2E test framework, so macOS test runs stop provisioning (and tearing down) a brand-new Dedicated Host + instance every time. - **Pool package** (`test/e2e-framework/resources/aws/ec2/pool`): discovers idle, tagged macOS EC2 instances and manages their lifecycle via lease records stored in S3, using conditional writes (ETag/If-Match) to arbitrate concurrent acquisition: - `Acquire` claims an idle instance from the pool (`AcquireIdleInstance`), or falls back to a per-developer local instance lookup/provisioning path (`LocalProvisionOptions`) outside CI. - Leases track `idle`/`in-use` status, owner, and `leased_at`, and are namespaced per owner to avoid collisions. - `RevertAndRelease` reverts an instance's root volume to the lease's baseline AMI and republishes it as `idle` on teardown; `RevertInPlace` re-reverts and re-publishes as `in-use` for local dev reuse. - `PublishInitialLease` registers a brand-new pool member's first lease out-of-band (used when auto-provisioning on a local cache miss). - **Provisioning wiring** (`test/e2e-framework/resources/aws/ec2/vm.go`): macOS VM creation now imports an existing pool member (pinning `HostID`/`SubnetID`/AMI via `pulumi.Import` + `IgnoreChanges`, and `RetainOnDelete` so Pulumi never destroys pooled instances) instead of always creating a fresh Dedicated Host. On a local cache miss, it provisions a new Dedicated Host/instance through ordinary Pulumi resources and registers it as a new pool member. - **Teardown wiring** (`test/e2e-framework/testing/e2e/suite.go`): `BaseSuite.releasePoolInstanceIfAny` reverts and releases the pool instance backing a suite's environment at teardown, replacing ad hoc destroy-based cleanup for macOS hosts. - **Bypass flag**: `E2E_MACOS_POOL_ENABLED` (default enabled) lets a run opt out of the pool entirely and fall back to the pre-existing per-run Dedicated Host provisioning; it's meant to be removed once the pool is validated and trusted as the default. - CI-run detection now checks the `CI` env var, so local runs consistently take the per-developer local-provisioning path. ### Motivation Every macOS E2E test run previously stood up a new AWS EC2 Dedicated Host that was used once and then torn down — but AWS bills Dedicated Host allocations in 24-hour minimum increments, so each single test run paid for a full day of macOS instance time. A shared pool of pre-baked, leasable hosts amortizes that 24h allocation across many runs via acquire/release against S3-backed lease state. See [WINA-2931](https://datadoghq.atlassian.net/browse/WINA-2931). ### Describe how you validated your changes - Ran `TestMacosInstallScript` locally in CI-mode (`E2E_PIPELINE_ID` forced) and in local-provisioning mode against a live pool, confirming warm-import acquisition and correct root-volume revert/release on teardown. - Ran four simultaneous `TestMacosInstallScript` invocations against a 2-member pool to exercise acquire-retry contention: the two extra runs correctly queued and waited on `pool.Acquire`'s retry loop until a member was released, then all four passed. - Validated the `E2E_MACOS_POOL_ENABLED=false` bypass path falls back to the pre-existing per-run Dedicated Host provisioning unchanged. ### Additional Notes [WINA-2931]: https://datadoghq.atlassian.net/browse/WINA-2931?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
        "url": "https://github.com/DataDog/datadog-agent/pull/53982",
        "createdAt": "2026-07-22T10:05:14Z",
        "updatedAt": "2026-08-12T15:31:09Z",
        "timestamp": "2026-08-12T15:31:09Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "long review",
          "team/agent-devx",
          "team/agent-build",
          "internal"
        ],
        "author": "PedroCordeiroDataDog",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54032",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Add experimental prepared startup for Agent rollouts",
        "text": "### What does this PR do? Adds a default-disabled prepared-startup primitive for the core Agent and direct trace Agent. Each process constructs its Fx graph, identifies its own Pod and DaemonSet through the local kubelet Pod list, and waits without starting Fx hooks when an older sibling Pod exists. It publishes `prepared` so native DaemonSet surge can consider the replacement Ready. After Kubernetes removes the old Pod, the replacement publishes `activating`, starts its hooks, then publishes `active`. A fresh install with no sibling activates immediately. Lifecycle state records the writer PID and Linux `/proc` start time so probes cannot accept a stale Prepared marker after a container restart. Kubelet errors, missing self data, and ambiguous Pod ordering fail closed. ### Motivation Agent DaemonSet updates currently delete the old Pod before the replacement image is pulled and its processes are constructed. Slow pulls and startup therefore become collection downtime. Prepared startup lets native `maxSurge` finish image pull, initialization, and Agent construction while the old Agent remains active. ### Describe how you validated your changes - Core lifecycle tests with and without kubelet support passed - Configuration tests passed - Focused Agent lint reported 0 issues - Core Agent and trace Agent builds passed - Commit and pre-push hooks passed, including Go tests and lint ### Additional Notes This is an experimental Linux-only primitive, disabled by default. The first pilot supports only the core Agent and direct trace Agent. Process Agent, system-probe, security Agent, logs, OTel, trace-loader socket activation, and other long-running node-Agent containers remain outside this PR. Coordinated branches: - Operator: https://github.com/DataDog/datadog-operator/pull/3298 - Experimental cluster configuration: https://github.com/DataDog/k8s-datadog-agent-ops/pull/9138",
        "url": "https://github.com/DataDog/datadog-agent/pull/54032",
        "createdAt": "2026-07-23T09:57:12Z",
        "updatedAt": "2026-08-12T16:22:36Z",
        "timestamp": "2026-08-12T16:22:36Z",
        "metrics": {
          "reactions": 1,
          "comments": 8
        },
        "labels": [
          "changelog/no-changelog",
          "team/agent-apm",
          "long review",
          "qa/rc-required",
          "team/agent-runtimes",
          "team/agent-configuration",
          "team/agent-build",
          "stale",
          "internal",
          "team/fleet-automation"
        ],
        "author": "AliDatadog",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54055",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "rtloader: Test ignored event_object field",
        "text": "### What does this PR do? Adds an explicit rtloader A/B regression test proving that otherwise identical Python events produce identical callback output with and without the unsupported `event_object` dictionary key. ### Motivation This documents the Agent-side behavior relied on by DataDog/integrations-core#24611, which removes an MD5-derived vSphere `event_object` value. The existing general event test supplied the key but did not explicitly assert that it is ignored. ### Describe how you validated your changes - `GOPROXY=https://proxy.golang.org,direct dda inv rtloader.test` - Pre-commit `go-fmt` and repository checks passed. - Pre-push modified-package `go-test` and `go-linter` checks passed. - Manual Agent 7.81.2 system proof: `agent check --json` retained an `aggregation_key` sentinel and omitted `event_object`; the decoded raw zstd `/intake/` request captured by fake intake did the same. ### Additional Notes This is test-only and does not change Agent runtime behavior, so it does not need a Reno release note.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54055",
        "createdAt": "2026-07-23T16:46:13Z",
        "updatedAt": "2026-08-12T15:12:47Z",
        "timestamp": "2026-08-12T15:12:47Z",
        "metrics": {
          "reactions": 2,
          "comments": 6
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "short review",
          "team/agent-runtimes",
          "stale",
          "internal"
        ],
        "author": "nubtron",
        "state": "closed",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54056",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[WP] Fix isolation re-apply mechanism",
        "text": "### What does this PR do? This PR prevent isolations from behind removed for some time during a ruleset loaded. ### Motivation This was supposed to be fixed in a previous PR but a bug was found. ### Describe how you validated your changes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54056",
        "createdAt": "2026-07-23T16:55:34Z",
        "updatedAt": "2026-08-12T13:48:22Z",
        "timestamp": "2026-08-12T13:48:22Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "team/agent-security",
          "category/bugfix",
          "qa/done",
          "short review",
          "internal"
        ],
        "author": "theop-dd",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54107",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[ABLD-536] Bazelify `gotestsum` usage across the repo",
        "text": "### What does this PR do? Route `gotestsum` through Bazel wherever it was invoked via `go install`, `$GOBIN`, or `$GOPATH`, and drop it from `install-tools`' `TOOL_LIST`. Replace every direct `gotestsum` invocation with `bazel run *:gotestsum` whenever possible. Otherwise install it by leveraging: 1. `platform_transition_filegroup` to cross-compile it without incurring the overhead of a full platform transition (for which some Bazel rules are not suited[^1]), 2. `pkg_install` for copying it out of the sandbox. Together, both of the above provide a flawless[^2] alternative in runtime environments where Bazel is not (yet) available. ### Initial Motivation `gotestsum`'s version and toolchain provenance were at best tracked by a runtime version check, and `go install` left it exposed to the \"gotestsum not found\" and wrong-arch incident class, leading us to land urgent PRs (e.g., #53993): - [#incident-56214](https://app.datadoghq.com/incidents/56214), - [#incident-56215](https://app.datadoghq.com/incidents/56215), - [#incident-56553](https://app.datadoghq.com/incidents/56553), - etc. => Bazel's hermetic build and efficient caching remove the failure mode at the source instead of patching around it again. ### Additional Motivation It introduces `platform_transition_filegroup` as a first working case that cross-compiles without having to globally alter `bazel --platforms` flags that would invalidate the action cache[^1][^2]. By adding the necessary GitLab `extends` as well as tweaking adhoc scripts, this also prepare jobs for: - switching from `bazel run *:gotestsum` to `bazel test`, - moving more non-hermetic tool invocations to `bazel run`, towards [ABLD-536](https://datadoghq.atlassian.net/browse/ABLD-536). ### Describe how you validated your changes `dda inv test` ran end to end through the new `bazel run` path: 18 tests passed with correct output and exit code. `kmt.py` and `system_probe.py`'s install paths were exercised directly, producing correct-arch binaries, verified via `file(1)`, for host, `arm64`, and `x86_64` targets, including the KMT cross-compile case. Existing unit test suites, `bazel_tests.py`, `e2e_testing_tests.py`, `setup_env_tests.py`, and `go_tests.py`, pass unchanged. ### Additional Notes [^1]: a bare `--platforms=` flag on the whole `bazel run` invocation doesn't just cost more, it breaks `pkg_install`'s own launcher outright (hit this directly: a garbled venv/Python launcher, `Syntax error: ')' unexpected`, zero output). [^2]: a naive `bazel build` followed by a copy of the resulting binary by gardening into Bazel's output is flawed: not only is the operation not atomic, but output paths collide across `--platforms` invocations. Also, build artifacts would get thrashed over `--platforms` switches. [ABLD-536]: https://datadoghq.atlassian.net/browse/ABLD-536?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
        "url": "https://github.com/DataDog/datadog-agent/pull/54107",
        "createdAt": "2026-07-24T16:50:19Z",
        "updatedAt": "2026-08-12T14:25:08Z",
        "timestamp": "2026-08-12T14:25:08Z",
        "metrics": {
          "reactions": 3,
          "comments": 7
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "team/agent-security",
          "team/database-monitoring",
          "team/ebpf-platform",
          "qa/no-code-change",
          "long review",
          "team/container-integrations",
          "team/agent-devx",
          "team/agent-build",
          "internal"
        ],
        "author": "rdesgroppes",
        "state": "closed",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54115",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[ABLD-395] MVP macos .pkg file rule.",
        "text": "### What does this PR do? Adds an MVP rule to create Mac PKG files. - bazel/rules/macos/pkg/pkg_mac_pkg.bzl - materialize srcs to diesk via a pkg_install-generated installer. sub-optimal but equivalent to what omnibus does today. Future work will improve that. - bazel/rules/macos/pkg/build_mac_pkg.sh — the pkgbuild wrapper - Adds packages/agent/macos/BUILD.bazel, to create a .pkg file for datadog-agent. This is obviously incomplete because //cmd/agent:agent is not ready yet. - packages/agent/product/BUILD.bazel — fixed a pre-existing bug where //cmd/loader:trace_loader (Linux-only target_compatible_with) was listed unconditionally, breaking any non-Linux consumer of :all_files. ### Motivation ### Describe how you validated your changes Claude's used lsbom to verify that the pkg format was valid. Hand compare the DMG built from the omnibus job to this output. ``` $ tree_size_compare --save pkg.json bazel-bin/packages/agent/macos/pkg.pkg $ tree_size_compare --save=dmg.json $HOME/Downloads/datadog-agent-7.83.0-devel.git.371.359005d.pipeline.126858256-1.arm64.dmg $ grep PKG@ dmg.json | sed -e 's/@PKG@/opt\\/datadog-agent/' >/tmp/dmg.files $ grep path pkg.json >/tmp/pkg.files $ grep system-prob /tmp/*.files /tmp/dmg.files: \"path\": \"opt/datadog-agent/bin/agent/dist/system-probe.yaml\", /tmp/dmg.files: \"path\": \"opt/datadog-agent/embedded/bin/system-probe\", /tmp/dmg.files: \"path\": \"opt/datadog-agent/etc/system-probe.yaml\", /tmp/dmg.files: \"path\": \"opt/datadog-agent/etc/system-probe.yaml.example\", /tmp/pkg.files: \"path\": \"opt/datadog-agent/etc/system-probe.yaml\", ``` The missing files are expected right now, because we have not done serious work at wiring up the dependencies. ### Next steps - tweak dependencies and config until we have fidelity with the omnibus packager. Brew the omnibus jobs to do this. - replace use of pkg_install to manifest the tree with a direct reader/writer. That is probably upstreamable to rules_pkg in a contrib section. I think I want a pkg_instantiate rule that will return a tree artifact. - Add signing (blocked on ABLD-386)",
        "url": "https://github.com/DataDog/datadog-agent/pull/54115",
        "createdAt": "2026-07-24T18:59:12Z",
        "updatedAt": "2026-08-13T16:18:09Z",
        "timestamp": "2026-08-13T16:18:09Z",
        "metrics": {
          "reactions": 1,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "medium review",
          "ask-review",
          "team/agent-build",
          "internal"
        ],
        "author": "aiuto",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54134",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "When uploading artifacts to yumtesting, also download the datadog-fip…",
        "text": "…s-proxy and upload it too <!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54134",
        "createdAt": "2026-07-27T14:25:56Z",
        "updatedAt": "2026-08-12T16:22:31Z",
        "timestamp": "2026-08-12T16:22:31Z",
        "metrics": {
          "reactions": 2,
          "comments": 5
        },
        "labels": [
          "short review",
          "team/agent-devx",
          "stale",
          "internal"
        ],
        "author": "jeremy-hanna",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54138",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[CWS] Persist profile when cgroup is deleted / agent shutdown",
        "text": "### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54138",
        "createdAt": "2026-07-27T16:44:18Z",
        "updatedAt": "2026-08-12T16:22:29Z",
        "timestamp": "2026-08-12T16:22:29Z",
        "metrics": {
          "reactions": 1,
          "comments": 3
        },
        "labels": [
          "component/system-probe",
          "team/agent-security",
          "short review",
          "stale",
          "internal"
        ],
        "author": "kovagsm",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54145",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[cisco-sdwan] Add config detail to max_pages pagination error",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Enriches the error returned when the Cisco SD-WAN paginated API hits the`max_pages` limit. The error now reports how many pages were fetched, that more data remains, and the current `max_count` / `max_pages` values: Example: `reached max_pages limit after fetching 20 pages and more data remains; increase max_count and/or max_pages to collect all data. current_configs: max_count=500, max_pages=20` ### Motivation On large SD-WAN environments endpoints can return more pages than `max_pages` allows, so collection stops and those metrics go missing for the collection period. The previous error was missing how much data was being pulled. Displaying the page count and the current config values helps with being able to tune the collection. ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54145",
        "createdAt": "2026-07-27T19:28:03Z",
        "updatedAt": "2026-08-12T16:22:26Z",
        "timestamp": "2026-08-12T16:22:26Z",
        "metrics": {
          "reactions": 1,
          "comments": 6
        },
        "labels": [
          "qa/no-code-change",
          "short review",
          "team/ndm-integrations",
          "stale",
          "internal"
        ],
        "author": "ddog-nasirthomas",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54147",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "experiment(observer): add configurable time-aware log count view",
        "text": "## What changed This adds a testbench-only, timestamp-aware detector view for log-derived occurrence counts. - Keep extractor output sparse in shared Observer storage. - Present completed fixed-window counts and causal forward zeros only when detectors read log `.count` series. - Never backfill zeros before a series is first observed. - Stop virtual zeros after a configurable idle TTL (300 seconds by default). - Leave ordinary metric-series missing-data semantics unchanged. - Expose `--time-aware-log-count-series`, `--log-count-window-seconds` (1, 5, or 10; default 5), and `--log-count-idle-ttl-seconds` through the testbench and Invoke eval tasks. - Record raw-storage versus logical-detector observation statistics in testbench output. - Add focused unit/integration coverage and save the detector-matrix results. ## Why Sparse log events are not evenly spaced metric samples, but the current detectors generally interpret adjacent points that way. Materializing zero-filled one-second series improved some detectors, but expanded storage and increased baseline false positives. This POC instead constructs an elapsed-time count view at the detector read boundary without writing synthetic points into shared storage. ## Results Across 12 log scenarios and Holt, ScanMW, ScanWelch, Tukey, and BOCPD: | Representation | Mean F1 | Baseline FPs | |---|---:|---:| | Sparse | 21.36% | 53 | | Materialized 1s | 29.81% | 143 | | Time-aware 1s | 20.65% | 138 | | **Time-aware 5s** | **39.15%** | **67** | | Time-aware 10s | 11.90% | 26 | The five-second configuration improves mean F1 by 17.79 percentage points over sparse input and 9.34 points over materialized one-second input, while keeping false positives much closer to the sparse control. The summarized results remain under `results/time-aware-count-view/`; raw scorer outputs are retained only on the local stacked experiment branch. These results were selected on the same scenario set and used the stacked fuzzy-tokenizer experiment, so they are evidence for continuing the design—not a held-out production accuracy estimate. ## Known limitations - This is intentionally testbench-only; it does not enable the representation in production wiring. - Detector warmups and windows are still point-count based. Changing bucket width therefore also changes their elapsed-time horizon. - The adapter currently reconstructs overlapping virtual ranges on reads. ScanMW/ScanWelch produced roughly 33 million logical observations in this evaluation, so caching/incremental maintenance is needed before production use. - Kafka regressed substantially and Cassandra regressed slightly at five seconds; those cases need dominant-series attribution before choosing a default. ## Validation - `dda inv test --targets=./comp/anomalydetection/observer/impl/` - `dda inv test --targets=./internal/qbranch/anomalydetection-testbench/...` - `dda inv anomalydetection.build-testbench` - CLI help and invalid-window validation smoke checks - modified-package Go linter: 0 issues - full repository pre-push hooks: passed",
        "url": "https://github.com/DataDog/datadog-agent/pull/54147",
        "createdAt": "2026-07-27T19:55:19Z",
        "updatedAt": "2026-08-12T16:22:24Z",
        "timestamp": "2026-08-12T16:22:24Z",
        "metrics": {
          "reactions": 1,
          "comments": 7
        },
        "labels": [
          "long review",
          "team/agent-build",
          "stale",
          "internal"
        ],
        "author": "Eokye",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54148",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Bump dd-compile-policy to v0.1.13",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? `dd-compile-policy` binary is pinned within the Agent at v0.1.2, which predates https://github.com/DataDog/dd-policy-engine/pull/68 in `dd-policy-engine` that added Docker container evaluators (CONTAINER_IMAGE_TAG, CONTAINER_IMAGE_DIGEST, CONTAINER_NAME, CONTAINER_LABEL) to the schema. `dd-compile-policy` embeds its FlatBuffers schema at build time, so the currently pinned binary has no knowledge of these evaluators. When a policy JSON references one, the generic FlatBuffers parser silently resolves it to `STRING_EVAL_UNKNOWN` (enum value 0) instead of erroring, so any WLS rule using a Docker attribute silently compiles into a no-op. This bumps the pin to v0.1.13, the first release of `dd-policy-engine` that includes the Docker container evaluators. ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54148",
        "createdAt": "2026-07-27T19:58:29Z",
        "updatedAt": "2026-08-12T16:46:44Z",
        "timestamp": "2026-08-12T16:46:44Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "short review",
          "team/agent-build",
          "stale",
          "internal"
        ],
        "author": "annacai21",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54157",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[WP] ICMPv4 packet flow classification",
        "text": "### What does this PR do? This PR adds proper IPv4 ICMP flow tracking so CWS can attribute outbound ICMP packets to the correct process in the TC classifier at snapshot, enabling cgroup-scoped network_filter actions (e.g. dropping ping traffic). Problem: The flow_pid map keys flows by (netns, source address, L4 identifier, protocol). For TCP/UDP, the L4 identifier is the source port. ICMP has no ports — only an echo identifier in the header — and security_sk_classify_flow runs too early for ICMP sockets: the flowi metadata is incomplete and the existing port-matching logic does not apply. Solution: Hook ip_finish_output, once the IPv4 packet (IP + ICMP headers) is built, and parse the sk_buff to extract: the source address (iph.saddr) the echo identifier (icmph.un.echo.id), stored in the existing port field of pid_route_t ICMP flow registration is skipped in security_sk_classify_flow and handled exclusively from this hook. On the TC egress path, resolve_pid_from_flow_pid is updated to look up ICMP flows using icmp.id instead of tcp_udp.sport. Refactor: Flow registration logic is extracted into register_flow_pid_classify_entry, shared by both hooks. Test: TestNetworkFilterICMPPingIsolation starts a long-running ping in a container, loads a cgroup-scoped network_filter rule (icmp and dst host 1.1.1.1), and verifies packet loss once the agent attaches the filter. ### Motivation Cgroup network isolation relies on resolving the emitting process (and its cgroup) from packets observed on the TC egress path. Without a correct flow_pid entry for ICMP, the classifier cannot attribute ping packets to the container process if the agent miss the create of the socket. This caused pings not to be dropped when the ping process started before the agent, even if an isolation was applied on this process / cgroup. TCP/UDP flows were already registered from security_sk_classify_flow, but that hook fires before the kernel has assembled the final ICMP with the address (chosen at runtime for ICMP) packet and does not expose a usable port for the port-matching checks. By moving registration to ip_finish_output and keying on the ICMP echo identifier, we align ICMP with the same flow_pid → PID → cgroup resolution path used for TCP/UDP.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54157",
        "createdAt": "2026-07-28T09:37:01Z",
        "updatedAt": "2026-08-13T16:52:46Z",
        "timestamp": "2026-08-13T16:52:46Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "team/agent-security",
          "qa/done",
          "medium review",
          "internal"
        ],
        "author": "theop-dd",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54159",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[CWS] Fix glob bypass",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54159",
        "createdAt": "2026-07-28T10:07:51Z",
        "updatedAt": "2026-08-12T16:22:20Z",
        "timestamp": "2026-08-12T16:22:20Z",
        "metrics": {
          "reactions": 2,
          "comments": 7
        },
        "labels": [
          "component/system-probe",
          "team/agent-security",
          "short review",
          "stale",
          "internal"
        ],
        "author": "kovagsm",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54162",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "DO NOT MERGE: validate datadog-agent-buildimages toolchains_mass branch",
        "text": "## Summary Points at the `linux_test_only` image and crosstool-ng toolchains published by the `chouquette/toolchains_mass` branch in `datadog-agent-buildimages` (new toolchain build+publish CI stage), to confirm the agent still builds with them before that branch merges. - `.gitlab-ci.yml`: `CI_IMAGE_LINUX` → test-only image from that branch's pipeline - `bazel/patches/gcc-toolchain/0001-adapt-to-our-ctng-toolchain.patch`: x86_64/aarch64 toolchain URLs → artifacts published to the `branches/` channel in `dd-agent-build-artifacts` **Do not merge**: the toolchain URLs are pinned to the `branches/` channel, specific to that feature branch. Once it merges to `main`, these need to move to the `main/` channel (or this PR gets closed once validated). ## Test plan - [ ] CI is green on this branch (regular Linux build + Bazel build)",
        "url": "https://github.com/DataDog/datadog-agent/pull/54162",
        "createdAt": "2026-07-28T11:05:51Z",
        "updatedAt": "2026-08-12T16:22:19Z",
        "timestamp": "2026-08-12T16:22:19Z",
        "metrics": {
          "reactions": 1,
          "comments": 8
        },
        "labels": [
          "short review",
          "team/agent-devx",
          "team/agent-build",
          "stale",
          "internal"
        ],
        "author": "chouquette",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54166",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[WP] Ignore unsupported socket types in flow_pid map during snapshot",
        "text": "### What does this PR do? This PR prevents keys unrelated to UDP or TCP sockets from being added to the `flow_pid` map when reading socket from procfs. ### Motivation The current mechanism is designed specifically for UDP and TCP. We should avoid adding other socket types until we support parsing them from procfs info",
        "url": "https://github.com/DataDog/datadog-agent/pull/54166",
        "createdAt": "2026-07-28T12:55:29Z",
        "updatedAt": "2026-08-12T17:51:46Z",
        "timestamp": "2026-08-12T17:51:46Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "team/agent-security",
          "qa/done",
          "short review",
          "internal"
        ],
        "author": "theop-dd",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54168",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "refactor(fleet): make procmgr an independent Linux service manager",
        "text": "### What does this PR do? Makes `procmgr` (`dd-procmgrd`) a first-class Linux service manager in the fleet installer, peer to systemd / upstart / sysvinit, instead of a systemd sub-unit that the installer cannot reason about. - New `service.ProcmgrType`, selected when the init system is systemd, `dd-procmgrd` is installed, and the operator has not opted out. New `pkg/fleet/installer/packages/service/procmgr` package whose unit-level verbs delegate to `systemd`, so no `ProcmgrType` branch calls `systemd.*` directly. - `agentService` gains a flat `Procmgr*` field group mirroring the existing `Upstart*`/`Sysvinit*` pairs, and every service-manager `switch` gains a `case service.ProcmgrType:`. `SystemdUnits*` drops `datadog-agent-procmgr.service`, so `systemd` means plain systemd again. - **Two generated unit trees**: `tmpl/gen/{systemd,procmgr}/<flavor>/`, each with its own `Wants=`. This is what makes the managers independent at the artifact level, and it replaces the `ConditionPathExists=!.../processes.d/datadog-agent-ddot.yaml` gate that had a systemd unit inspecting procmgr's state directory. New `embedded.GetProcmgrUnit` / `GetProcmgrConfig`. - The DDOT extension hooks stop touching procmgr configs entirely, and `writeDDOTProcmgrConfig`/`removeDDOTProcmgrConfig` are deleted. Process definitions are shipped unconditionally from `ProcmgrProcesses*`, exactly like units: `condition_path_exists` decides whether the payload runs, the same way `ConditionPathExists=` does for `datadog-agent-security.service`. ### Motivation From the installer's point of view procmgr was invisible: `agentService.SystemdUnitsStable` listed both `datadog-agent-ddot.service` and `datadog-agent-procmgr.service`, `datadog-agent.service` wanted both supervision paths, and mutual exclusion lived in a unit-file condition. The DDOT `processes.d` config was written from `postInstallDatadogAgent` outside the abstraction — and *not* written by `postStartExperiment`/`postPromoteExperiment`, which relied on the extension hook firing indirectly. That combination made classic-systemd/procmgr interactions hard to reason about and left no way to opt out on Linux. ### Describe how you validated your changes New tests, aimed at the invariants this design rests on: - `SystemdUnits*` contains no `-procmgr` unit and `ProcmgrUnits*` no `-ddot` unit; every name in each array resolves in its own generated tree for all four flavors (both write paths hard-fail on a missing embed, so drift would otherwise surface only at install time). - The generated `datadog-agent.service` `Wants=` matches the tree's array — the guarantee that replaced the deleted `ConditionPathExists=!` gate. - `procmgrInstallRoot` matches `DD_PM_CONFIG_DIR` in the generated procmgr units, for every package type and lifecycle half. This spans a Go helper and a generated unit, and nothing enforced it before; verified by injecting drift and confirming the test fails. Manual review of the generated trees: procmgr tree only defines datadog-agent.service with the specific Wants= sub-service that includes procmgr.service and excludes ddot.service. The yaml processes configuration are generated outside the platform scope: does depend on the platform only the package.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54168",
        "createdAt": "2026-07-28T14:14:25Z",
        "updatedAt": "2026-08-12T20:29:15Z",
        "timestamp": "2026-08-12T20:29:15Z",
        "metrics": {
          "reactions": 0,
          "comments": 4
        },
        "labels": [
          "qa/done",
          "long review",
          "team/container-integrations",
          "team/agent-runtimes",
          "team/agent-devx",
          "team/agent-build",
          "team/windows-products",
          "internal"
        ],
        "author": "Stanislas167",
        "state": "open",
        "assignees": [
          "Stanislas167"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54169",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "WIF-57: retry (not drop) 403s on delegated-auth-pending domains",
        "text": "## Summary Split out of #54062 (which grew to touch too many teams' code in one PR — see [discussion](https://github.com/DataDog/datadog-agent/pull/54062#issuecomment-5104702094)). This is the core mechanism; two follow-on PRs stack on top of this one to extend it to other products. Adds durable-delivery handling for delegated-auth (WIF)-managed domains, matching the treatment `secrets.Component.Refresh()` already gets on a 403 response: - `delegatedauth.Component` gains `IsManaged(Target)`, a query method backed by the component's instance registry, so callers can ask \"is this specific key/domain currently WIF-managed\" independently of what the config value looks like right now. String-sniffing the current `api_key` config value for a `DELA(...)` prefix almost never worked, since delegated auth resolves the directive to a real key synchronously during config load, before most `Endpoint`/`domainResolver` objects are ever constructed. - `pkg/config/utils.MakeEndpoints` keeps a pending `DELA(...)` directive as a placeholder API key instead of dropping it entirely, and guesses `HasPendingDelegatedAuth` from that literal prefix. Without this, a domain whose only key source was a pending directive got zero API keys, and since transactions are created one per resolver API key, it got zero transactions — meaning it silently dropped all its traffic rather than queuing it, and never got a chance to hit the new retry path below. - `comp/forwarder/defaultforwarder`'s `markPendingDelegatedAuthDomains` overwrites that initial guess with `IsManaged`'s authoritative answer once the forwarder is constructed, so a directive that was rejected as malformed/unsupported (and never actually registered as an instance) doesn't retry forever — it drops like a genuinely bad key. The transaction/resolver layers then gate the 403 drop-vs-retry decision on the corrected per-key `HasPendingDelegatedAuth`, and nudge delegated auth to refresh sooner instead of waiting out its normal backoff interval. ## How durable delivery works Before this PR, a domain whose only key was a not-yet-resolved `DELA(...)` directive got zero API keys and therefore zero transactions — it silently dropped everything rather than queuing it: ```mermaid flowchart TD A[\"additional_endpoints entry:<br/>DELA(org_uuid, provider)\"] --> B{\"Directive resolved yet?\"} B -->|\"no (still pending)\"| C[\"MakeEndpoints drops the domain —<br/>zero API keys, zero transactions,<br/>zero chance to ever retry\"] B -->|yes, real key| D[\"Normal delivery\"] ``` This PR replaces that dead end with a queue-and-retry path, correcting the initial guess once against the source of truth, then using it on every 403: ```mermaid sequenceDiagram participant MK as MakeEndpoints participant NF as NewDefaultForwarder participant DA as delegatedauth.Component participant DR as domainResolver participant FW as Forwarder transaction participant DD as Datadog Intake MK->>MK: additional_endpoints entry = DELA(...)<br/>keep it as a placeholder API key,<br/>guess HasPendingDelegatedAuth=true from the literal prefix NF->>DA: IsManaged(Target{domain}) — authoritative check alt directive was registered as a real instance DA-->>NF: true NF->>DR: HasPendingDelegatedAuth stays true else directive was rejected (malformed/unsupported) DA-->>NF: false NF->>DR: HasPendingDelegatedAuth corrected to false<br/>(so it can drop like a normal bad key, not retry forever) end DR->>FW: transaction created, queued for delivery FW->>DD: send payload using placeholder key DD-->>FW: 403 Forbidden FW->>FW: secrets.Refresh() resolved a new key? alt yes FW->>DD: retry immediately with the new key else no FW->>DR: HasPendingDelegatedAuth(apiKeyIdx)? DR-->>FW: true — this key is still a DELA(...) placeholder FW->>FW: requeue transaction instead of dropping it FW->>DA: Refresh() — nudge sooner than the normal backoff DA->>DA: exchange cloud auth proof for a real API key DA->>DR: merge real key into additional_endpoints DR->>FW: retry with the resolved key FW->>DD: send payload DD-->>FW: 200 OK end ``` A static, non-WIF domain that gets a genuine 403 (bad API key) still drops as it does today — `HasPendingDelegatedAuth` only changes behavior for domains delegated auth is actually managing, per key, so a domain mixing a static key with a DELA-managed one treats each independently. ## Test plan - [x] `dda inv test --targets=./comp/core/delegatedauth/...,./comp/forwarder/defaultforwarder/...,./pkg/config/utils/...,./pkg/config/setup/...` — 696 tests passed - [x] `dda inv linter.go` on the same targets — clean - [x] Adversarial code review and security review run on the full diff, no blocking findings 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
        "url": "https://github.com/DataDog/datadog-agent/pull/54169",
        "createdAt": "2026-07-28T14:49:11Z",
        "updatedAt": "2026-08-13T02:01:52Z",
        "timestamp": "2026-08-13T02:01:52Z",
        "metrics": {
          "reactions": 0,
          "comments": 6
        },
        "labels": [
          "long review"
        ],
        "author": "wynbennett",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54190",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "split org-wide and targeted policies into separate RC output files",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54190",
        "createdAt": "2026-07-29T05:37:25Z",
        "updatedAt": "2026-08-13T16:21:44Z",
        "timestamp": "2026-08-13T16:21:44Z",
        "metrics": {
          "reactions": 1,
          "comments": 6
        },
        "labels": [
          "medium review",
          "team/injection-platform",
          "stale",
          "internal"
        ],
        "author": "annacai21",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54195",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Improve E2E test-writing skill",
        "text": "### What does this PR do? Rewrites the `write-e2e` skill from a table of pointers into a procedure that carries a change from scope to merged test, with the lookup material split into five reference files loaded only when their trigger fires. The skill now works out what needs covering from the current diff when no target is named, gates that scope through `e2e-audit` before reading any implementation, steers authors into an existing suite instead of a new one, and finishes with verification gates that share a single provisioned environment rather than provisioning three times. Other notable changes: - Several documents named provisioner options, client methods, or package paths that do not exist, so copying from any of them produced a compile error or a dead link. Each now names something that exists, and `dockeragentparams.WithEnvironmentVariables` gained the doc comment separating it from the option that reaches the Agent process. - Root `AGENTS.md` described context inheritance as importing the parent `CLAUDE.md`, which re-reads files the harness has already loaded. It now says parent context arrives on its own, and the two files that followed the old pattern no longer import their parent. - `docs/public/guidelines/contributing.md` documented two of the three QA labels the tooling enforces; `qa/rc-required` is now defined alongside them. ### Motivation E2E tests are expensive to write and expensive to get wrong: a test that never runs in CI gives false confidence, and a suite sharing a Pulumi stack name with a sibling destroys that sibling's infrastructure mid-run with no error message. The previous skill was a list of files to read, which left every one of those decisions to be rediscovered. Several of the documents it pointed at were actively wrong. Copying the provisioner options from either Go doc comment, the framework `AGENTS.md` table, the Cursor rule, or the public how-to produced code that does not compile, and the how-to's sample violated the reliability rules in `test/new-e2e/codereview_guideline.md` that the same page links to. Recording those forms as traps to avoid only helps whoever loads the file that records them, so they are fixed where they were written. ### Describe how you validated your changes Every claim now written down was checked against the repository rather than carried over: provisioner paths and constructors, environment struct fields, OS descriptors, fakeintake client methods, GitLab job and template names, rule template names, agentparams options, and the section anchors of every cross-reference. The dynamic test skipping section was traced end to end before being written, through the rule in `.gitlab-ci.yml`, the `--impacted` flag and breakglass conditions in `.gitlab/test/e2e/e2e.yml`, the executor call in `tasks/new_e2e_tests.py`, and the skip-list computation in `tasks/libs/dynamic_test/index.py`. It previously said the executor selects jobs from coverage data and that a `changes` rule is a floor; it selects tests within a job that the rule has already created, which is the opposite trade, and the earlier wording would have led someone to write a narrower rule than they wanted. The QA label wording was taken from `tasks/github_tasks.py`, which holds the enforced set and the text of the bot message, rather than from the Confluence page both it and the bot link to, because that page misspells one of the three labels. ### Additional Notes Two framework issues are documented here rather than fixed, both worth their own change. - The stack name is derived from the suite's struct type name with no collision detection, so the rule that each entry point needs its own type is enforced only by whoever read the docs, and the existing tree is unguarded; failing fast in `e2e.Run` on a duplicate would replace a silent teardown with a clear error. - AWS provisioners nest their options while Azure, GCP, and local ones are flat, which is the single most-repeated fact across these files; thin forwarding options on the AWS provisioners would remove the need to state it at all. On the Confluence side, the page describing how to add an e2e job is now superseded by `references/ci-wiring.md`: it names a config file path that does not exist, an artifact job that has been renamed, and a target directory that was renamed, and it never mentions job ownership. It should be replaced by a pointer rather than migrated. The QA best-practices page that `tasks/github_tasks.py` links to can point at `contributing.md` now. The troubleshooting content in \"Common E2E issues\" has no in-repo equivalent and is the strongest candidate for migration into `docs/public`, but several of its entries reference tooling that has moved, so it needs per-entry verification instead of a copy.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54195",
        "createdAt": "2026-07-29T08:32:11Z",
        "updatedAt": "2026-08-12T15:38:35Z",
        "timestamp": "2026-08-12T15:38:35Z",
        "metrics": {
          "reactions": 1,
          "comments": 6
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "long review",
          "team/agent-devx",
          "internal"
        ],
        "author": "ofek",
        "state": "closed",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54225",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[CWS] Kill container and cgroup scopes with cgroup v2 cgroup.kill",
        "text": "### What does this PR do? Kill actions scoped to `container` or `cgroup` now kill the whole cgroup with a single write to the cgroup v2 `cgroup.kill` interface (Linux 5.14+), instead of signalling every PID of the cgroup one by one. The previous behaviour is kept as a fallback for everything `cgroup.kill` cannot express. A failed `cgroup.kill` write kills nothing, so falling back after one is always safe: | Situation | Behaviour | |---|---| | `container`/`cgroup` scope, `SIGKILL`, pure cgroup v2 | one `cgroup.kill` write | | Signal other than `SIGKILL` | per-process kill (`cgroup.kill` only delivers `SIGKILL`) | | `process` scope | per-process kill, unchanged | | Target cgroup has child cgroups | per-process kill (see Additional Notes) | | Hybrid/v1 hierarchy, kernel < 5.14, threaded cgroup, no writable path | per-process kill | ```mermaid flowchart TD A[kill action] --> B{scope is container or cgroup<br/>AND signal is SIGKILL<br/>AND pure cgroup v2?} B -- no --> Z[signal each PID] B -- yes --> C[resolve cgroup ID + inode<br/>from the cgroup resolver] C --> D{target holds the agent<br/>itself or an ancestor?} D -- yes --> R[refuse] D -- no --> E[for each candidate base:<br/>agent view, then /proc/1/root] E --> F{dir inode matches<br/>the resolved one?} F -- no --> E F -- yes --> N{cgroup has child cgroups?} N -- yes --> Z N -- no --> G[open cgroup.kill O_WRONLY] G -- EROFS/ENOENT --> E G -- ok --> H[write &quot;1&quot;] H -- ok --> I[whole cgroup tree killed] H -- EOPNOTSUPP/ENODEV --> Z E -- no base worked --> Z ``` ### Motivation [CWS-6377](https://datadoghq.atlassian.net/browse/CWS-6377). The per-PID loop has two problems. It can be outrun: a process that keeps forking can create children faster than we walk the PID list, and the loop has to carry a `createdAt` check to avoid killing a recycled PID. And it is expensive — roughly five procfs accesses per PID (`psutil.NewProcess` + `CreateTime` + `Exe` when enumerating, then `NewProcess` + `CreateTime` again when killing). `cgroup.kill` removes both. The kernel documents that it \"deal[s] with concurrent forks appropriately and is protected against migrations\", and it replaces the N kill syscalls with one write. ### Describe how you validated your changes **Unit tests** (`dda inv test --targets=./pkg/security/probe,./pkg/security/utils` — 337 tests pass): - one-shot kill is used for `cgroup`/`container` scope, and no process is signalled individually - fallback to per-process kills when the cgroup kill fails - `process` scope and non-`SIGKILL` signals never take the one-shot path - a queued kill (disarmer warmup) still uses one operation per cgroup - `cgroup.kill` receives exactly `\"1\"`, falls through to the next candidate base, and errors when the file is missing - inode mismatch and agent-own-cgroup targets are refused - unsafe cgroup IDs (`\"\"`, `/`, `..`) are rejected - `TestCgroupKillerKillsRealCgroup` exercises a real cgroup v2 hierarchy; it skips without root (same pattern as `pkg/gpu/cgroups_test.go`), so it does not run in the unit CI job — the functional tests below cover that in a root VM **Existing functional tests** already exercise the new path: the `cgroup`-scope kill tests in `pkg/security/tests/action_test.go` and `cgroup_test.go` run as root on a pure cgroup v2 VM with `SIGKILL`. **Kernel behaviour verified manually** on 6.8 before writing the code: - `cgroup.kill` kills the cgroup *and its descendant cgroups* (exit 137) - threaded cgroup → `EOPNOTSUPP` (errno 95); root cgroup has no `cgroup.kill` - writing through a read-only bind mount of cgroupfs → `EROFS` - writing via `/proc/1/root/sys/fs/cgroup/...` → succeeds, including when procfs itself is bind-mounted read-only - `open(cgroup.kill, O_WRONLY)` has no side effect — the kill only happens on write — which is what makes trying one base and falling back to the next safe `dda inv linter.go` reports 0 issues and `dda inv system-probe.build` succeeds. ### Additional Notes **No change in blast radius.** `cgroup.kill` would also kill the processes of descendant cgroups, which are not part of the PID list checked against the excluded binaries (the resolver keys one cache entry per cgroup and never walks children). Rather than kill processes that were never checked, the one-shot path is refused when the target has child cgroups, and those fall back to the per-process path. Container and service cgroups are leaves in practice, so this keeps the single write where it matters at the cost of one `readdir` — cheaper than walking the subtree and resolving every descendant executable on each kill. Note that validating descendants instead would only narrow a TOCTOU window rather than close it, since a process can enter a descendant between the check and the write. **Safety.** Process enumeration is unchanged, so the excluded-binaries check and the killed-PID reporting behave exactly as before — only the delivery mechanism changed. Two guards were added on top, because a single write reaches processes the PID list never named: - the target is refused if it is the agent's own cgroup *or an ancestor of it* (an ancestor is just as fatal, since descendants die too) - the cgroup directory's inode is checked against the one CWS resolved, so a stale or mismatching path cannot take down an unrelated workload - the one-shot path is skipped entirely when no process of the cgroup was resolved, so a cgroup we know nothing about is never killed unchecked **The read-only mount caveat.** `/host/sys/fs/cgroup` is mounted `readOnly: true` into every container in `Dockerfiles/manifests/`, so the obvious implementation fails with `EROFS` in Kubernetes while passing on host installs and in the functional-test VMs. The killer therefore tries the agent's own view first and then `/proc/1/root/<host cgroup2 mount>`, which reaches the same file through pid 1's mount namespace where it is still writable. That needs `hostPID: true` (set in the manifests here). **Automated tests cannot cover this**: they run as root with writable mounts, so they pass either way. The manual QA step for this PR is therefore a Kubernetes check that the one-shot path is actually taken (and confirming the Helm chart and datadog-operator set `hostPID`) — without it the fast path silently always falls back to the previous per-process behaviour. **No config flag.** Since the design falls back on any error there is no state to get stuck in, so no kill switch was added. Happy to add `runtime_security_config.enforcement.cgroup_kill_enabled` if reviewers want an explicit escape hatch for an enforcement-path change. [CWS-6377]: https://datadoghq.atlassian.net/browse/CWS-6377?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
        "url": "https://github.com/DataDog/datadog-agent/pull/54225",
        "createdAt": "2026-07-29T17:49:04Z",
        "updatedAt": "2026-08-13T08:13:30Z",
        "timestamp": "2026-08-13T08:13:30Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "team/agent-security",
          "team/ebpf-platform",
          "qa/done",
          "long review",
          "team/agent-build",
          "internal",
          "team/fleet-automation"
        ],
        "author": "homoeconomics",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54298",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Titouan.guesdon/clusteragent gomemlimit",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds support for `runtime.gomemlimit` in vertical scaling recommendations. When the backend recommendation includes a `Gomemlimit` value for a container, the cluster agent now: 1. Parses `RuntimeValues` (keyed by container name) from the autoscaling backend response 2. Includes `RuntimeValues` in the recommendation hash so changes are detected correctly 3. Injects/updates the `GOMEMLIMIT` environment variable on pods via the admission webhook (`pod_patcher`) 4. Forces a pod rollout (instead of in-place resize) when `RuntimeValues` are present, since env vars cannot be updated on running containers via `pods/resize` 5. Persists `RuntimeValues` to the DPA status annotation so HA follower replicas can reconstruct the full recommendation without hitting the backend ### Motivation Go applications expose a `GOMEMLIMIT` env var to cap the Go runtime's memory usage. Vertical scaling recommendations from the backend can now include this value alongside CPU/memory resource requests/limits, allowing the cluster agent to apply it end-to-end. ### Describe how you validated your changes Unit tests in `pod_patcher_test.go` cover: - Injection of `GOMEMLIMIT` when not present - Update of `GOMEMLIMIT` when the value changes - Clearing of `ValueFrom` when the env var was previously sourced from a ConfigMap/Secret (Kubernetes rejects env vars with both `Value` and `ValueFrom` set) ### Additional Notes - `RuntimeValues` are included in the `ResourcesHash` so any change to `GOMEMLIMIT` triggers a new recommendation cycle - Constraints filtering (`applyVerticalConstraints`) also prunes `RuntimeValues` for containers that are dropped, keeping hash consistency",
        "url": "https://github.com/DataDog/datadog-agent/pull/54298",
        "createdAt": "2026-07-31T12:37:49Z",
        "updatedAt": "2026-08-12T14:50:16Z",
        "timestamp": "2026-08-12T14:50:16Z",
        "metrics": {
          "reactions": 1,
          "comments": 7
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "medium review",
          "team/agent-build",
          "internal"
        ],
        "author": "TitouanGuesdon",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54330",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "docs(ncm): document network_config_management conf.yaml.example",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Populates `cmd/agent/dist/conf.d/network_config_management.d/conf.yaml.example` with the `init_config` and instance-level options supported by the Network Config Management (NCM) check, sourced from `pkg/networkconfigmanagement/config/config.go` (namespace, collection intervals, SSH connection settings, device `ip_address`/`profile`, and `auth` credentials). ### Motivation The example config was left empty (copied from an empty test fixture) when the NCM default profiles were moved to internal directories in #43357. ### Describe how you validated your changes - Verified the example parses as valid YAML. - Verified documented fields/defaults match `pkg/networkconfigmanagement/config/config.go` (`InitConfig`, `DeviceInstance`, `AuthCredentials`, `SSHConfig`). ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54330",
        "createdAt": "2026-08-03T04:38:45Z",
        "updatedAt": "2026-08-12T15:29:56Z",
        "timestamp": "2026-08-12T15:29:56Z",
        "metrics": {
          "reactions": 1,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "medium review",
          "team/ndm-integrations",
          "team/agent-integrations",
          "internal"
        ],
        "author": "ian28223",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54333",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Build with race detector",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Build with race detector. ### Motivation Make a custom build and give it a shot internally, to see if we can detect races. ### Describe how you validated your changes n/a ### Additional Notes [AGENTRUN-1159]: https://datadoghq.atlassian.net/browse/AGENTRUN-1159?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
        "url": "https://github.com/DataDog/datadog-agent/pull/54333",
        "createdAt": "2026-08-03T05:47:18Z",
        "updatedAt": "2026-08-13T17:58:50Z",
        "timestamp": "2026-08-13T17:58:50Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "do-not-merge/hold",
          "changelog/no-changelog",
          "team/agent-apm",
          "component/system-probe",
          "team/agent-security",
          "team/ebpf-platform",
          "qa/done",
          "long review",
          "team/agent-runtimes",
          "team/agent-metric-pipelines",
          "team/agent-devx",
          "team/container-experiences",
          "team/windows-products",
          "team/action-platform",
          "team/profiling-full-host",
          "internal",
          "team/fleet-automation"
        ],
        "author": "pgimalac",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54362",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[CONTINT-5415] Tag CronJob-owned Job events with kube_cronjob",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? This PR adds the `kube_cronjob` tag to Kubernetes Job events when they are spawned by a cronjob. It does this by parsing through the job name, the same as what is done in the [tagger](https://github.com/DataDog/datadog-agent/blob/9f1c7785f27a5a040377c1f0db4e4faf50cefe3d/comp/core/tagger/collectors/workloadmeta_extract.go#L1206) and [KSM](https://github.com/DataDog/datadog-agent/blob/9f1c7785f27a5a040377c1f0db4e4faf50cefe3d/pkg/collector/corechecks/cluster/ksm/kubernetes_state.go#L1479) check. ### Motivation Closes issue https://github.com/DataDog/datadog-agent/issues/52611 https://datadoghq.atlassian.net/browse/CONTINT-5415 ### Describe how you validated your changes On a kind cluster, built and deployed the agent with event bundling enabled, added a cronjob that spawns a new job with schedule `* * * * *`. Saw that events are emitted with the proper `kube_cronjob` tag: <img width=\"835\" height=\"387\" alt=\"image\" src=\"https://github.com/user-attachments/assets/e3991a91-a636-4a4a-96c7-84e61df2127f\" /> ### Additional Notes This change is _complete_ in that any job events spawned by a cronjob while have this tag, it's not _sound_ in that there could be jobs (not spawned by a cronjob) that could parse as a if its spawned by a cronjob, and the `kube_cronjob` tag will be emitted. Since other parts of the agent have accepted this risk, it's probably acceptable here too but I think worth noting.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54362",
        "createdAt": "2026-08-03T14:42:35Z",
        "updatedAt": "2026-08-13T17:25:54Z",
        "timestamp": "2026-08-13T17:25:54Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "qa/done",
          "medium review",
          "team/container-integrations",
          "team/agent-build",
          "internal"
        ],
        "author": "triviajon",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54375",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "configfilesdiscovery: collect redis env vars",
        "text": "### What does this PR do? Collects selected, non-secret Redis environment variables alongside Redis config files in `configfilesdiscovery`. It uses regex-based allow and deny rules plus the shared secret-name filter. Config-file selection follows `redis-server` argv, then `REDIS_CONF_FILE`, then known default paths. The shared reader accepts the optional fallback while Kafka retains its existing behavior by passing none. ### Motivation DSCVR-619 ### Describe how you validated your changes Unit tests. ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54375",
        "createdAt": "2026-08-03T15:53:00Z",
        "updatedAt": "2026-08-13T14:44:56Z",
        "timestamp": "2026-08-13T14:44:56Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "medium review",
          "team/agent-discovery",
          "internal"
        ],
        "author": "Yumasi",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54377",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[MVP] feat(instrumentation): Report runtime check failures in DDI status",
        "text": "### What does this PR do? This draft MVP surfaces runtime integration-check failures in the originating `DatadogInstrumentation` status instead of maintaining integration-specific validation schemas in admission. - Carries the originating DDI namespace, name, UID, generation, and check index through workload-targeted check configurations. - Reports check configuration and run-state transitions from the node Agent to the Cluster Agent. - Routes reports to the leader Cluster Agent and only allows the leader to write CR status. - Updates the `ChecksReady` condition with `AwaitingCheckStatus`, `CheckConfigurationFailed`, `CheckRunFailed`, or `Running`. - Sends node Agent status POSTs only when the observed state or error changes and skips identical CR status writes. - Scrubs and truncates reported errors before transmission. ### Motivation `DatadogInstrumentation` users can currently submit integration instance fields that pass structural admission validation but fail only after the check reaches the node Agent. Maintaining integration schemas in the Agent duplicates `integrations-core` models and would still miss custom and runtime validation. This MVP uses the regular check loading and execution lifecycle as the source of truth, then makes its failure visible on the CR that produced the configuration. MVP boundaries: - Workload-targeted DDI checks only; Service-targeted and Cluster Checks remain follow-up work. - Status is aggregated into the existing `ChecksReady` condition rather than new per-instance status fields. - Cluster Agent aggregation is currently in memory. - This does not test connectivity or resolve Autodiscovery templates at admission time. ### Describe how you validated your changes - `dda inv cluster-agent.build --skip-assets --no-force-policies-clone` - `dda inv agent.build --build-exclude=systemd,python --skip-assets --exclude-rtloader` - Repository pre-push hooks, including Go tests and linting. - Manual Injector Dev QA using the local Datadog Operator chart: - An invalid Redis `port: \"not-a-port\"` was admitted and transitioned to `ChecksReady=False` with reason `CheckConfigurationFailed`. - Replacing it with the valid `%%port%%` template transitioned the CR to `ChecksReady=True` with reason `Running`. ### Demo <!-- Add the demo video or recording link here. --> _TODO: Add demo video._ ### Additional Notes This is intentionally a draft MVP. Service-targeted checks, durable aggregation across Cluster Agent failover, finer-grained CRD status fields, tests, and a release note can be completed before marking it ready for review.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54377",
        "createdAt": "2026-08-03T15:57:42Z",
        "updatedAt": "2026-08-13T15:37:17Z",
        "timestamp": "2026-08-13T15:37:17Z",
        "metrics": {
          "reactions": 1,
          "comments": 2
        },
        "labels": [
          "qa/done",
          "team/container-platform",
          "long review",
          "team/container-integrations",
          "team/agent-runtimes",
          "team/agent-build",
          "team/kubernetes-experiences",
          "internal"
        ],
        "author": "Mathew-Estafanous",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54384",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[CNM-5556] Add diagnostics for TLS traffic reported as tls_encrypted:false",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds **observational-only** eBPF diagnostics to confirm a suspected root cause for encrypted traffic being reported as `tls_encrypted:false` in CNM. **No classification behaviour changes.** Five counters, one per link in the suspected chain, exposed as `datadog.system_probe.network_tracer.ebpf.*`: | Counter | Link | What a non-zero value proves | |---|---|---| | `tls_reject_record_exceeds_packet` | 1a | `is_tls()` rejected a valid record header solely because the record ran past the end of the packet | | `tls_reject_handshake_invalid` | 1b | The record fit, but `is_valid_tls_handshake()` rejected it (non-Hello type, coalesced, or fragmented) | | `applayer_match_on_tls_payload` | 2 | A db-layer classifier matched a buffer that *begins with a plausible TLS record header* | | `redis_match_on_nonstandard_port` | 2 | Redis matched on a port Redis never serves | | `tls_locked_out_by_applayer` | 3 | A TLS record header arrived on a connection whose app layer was already recorded, so `is_tls()` can never run again | Supporting pieces: - `is_tls_record_header_plausible()` in `tls.h` — validates `content_type` + `version` **without** the fits-in-packet bound. Needed because reusing `is_tls()` for diagnostics would be blind to precisely the case under investigation. Documented as diagnostic-only; deliberately not used for classification. - `tls_diag_events` — a bounded (1024-entry) hash map carrying per-connection detail, drained from the Prometheus `Collect()` path and logged at **info** level. Because the logging is userspace, a normal non-debug build at default log level is sufficient; eBPF cannot write agent logs at all. Rate limited to 5 lines per scrape, and every entry visited is deleted so the map cannot pin at capacity. - Everything is gated behind a `tls_diag_enabled` constant (kernel **6.0+**), so on older kernels the verifier prunes the branches entirely — see \"Additional Notes\". - Drive-by: corrects a stale comment claiming `connection_protocol` is an LRU map. It is a plain hash map, so it does not evict; leaked entries are reclaimed by the userspace map cleaner. ### Motivation Encrypted traffic is being reported as unencrypted across a broad slice of staging: **47 aggregate connections on one Kafka port, all classified `redis`**, spanning ~10 client services and ~10 kube clusters plus bare EC2, with Rust, Go and JVM clients all affected. Both endpoints' agents misclassify independently. The suspected mechanism, from reading the classifier: 1. On a connection whose TLS handshake was never observed, `is_tls()` rejects genuine TLS because `read_tls_record_header()` requires the whole record to fit in one packet. Records run to 16 KB; MSS is ~1460. 2. Classification falls through to the app-layer classifiers. `is_redis()` accepts on a **single byte** matching any of 14 RESP type markers, with no CRLF, length or structure check — so it matches arbitrary ciphertext ~5.5% of the time. 3. `mark_as_fully_classified()`, plus the `app_layer_proto == UNKNOWN || POSTGRES` gate on the `is_tls()` call, pin that wrong answer for the life of the map entry. Result: emitted protocol stack `[Redis]` → `tls_encrypted:false` on genuinely encrypted traffic. Note this does **not** mean the gate is wrong. Per the [Harden TLS socket filter classification RFC](https://datadoghq.atlassian.net/wiki/spaces/UT/pages/3954869126), which introduced it in #28198, the reasoning was *\"if the socket filter was able to classify the protocol, then it is not TLS\"* — sound, **provided classifiers do not false-positive**. This PR measures whether that proviso is being violated in practice. `redis_match_on_nonstandard_port` is the decisive signal: classification is purely content-based with no port heuristics anywhere, so Redis matched off 6379/6380/16379/26379 is a false positive by definition — no ground truth required. The other four are sampling-dependent (they need a packet to begin at a TLS record boundary), so treat their magnitudes as evidence of *mechanism*, not blast radius. **Falsification condition:** if all five stay zero while `tls_encrypted:false` persists on the affected port, the theory is wrong and the Redis verdict is arriving via some other path. ### Describe how you validated your changes - eBPF compiles for prebuilt, runtime and CO-RE; `cgo -godefs` regenerated via `bazel run //pkg/network/ebpf:kprobe_types_godefs{,_test_file}` (both generated files), 46/48 godefs tests pass (2 Windows-only skipped). - Verifier accepts `tracer.o` and `tracer-fentry.o` with no load failures. - Measured on 6.8/arm64 with the gate closed, confirming the branches are pruned rather than merely unreached: | program | diagnostics active | gated off | |---|---|---| | `socket__classifier_entry` | 5,245 processed | **2,946** (−44%) | | `socket__classifier_dbs` | 2,060 processed | **1,247** (−39%) | - Program sizes measured against the base commit: `_entry` 1,127 → 1,402, `_dbs` 703 → 922 instructions. `_grpc` and `_tls_handshake_client` are byte-identical to `main`. ### Additional Notes **This is an investigation aid, not the fix.** It changes no classification behaviour. The likely fix — tightening `is_redis` to require a well-formed RESP frame, using the validators that already exist unused in `redis/helpers.h` — is intentionally not in this PR so the diagnostics can be reviewed independently and so the fix lands with its own regression test. **Two earlier KMT failures shaped the design, both fixed here:** 1. `BPF_MAP_TYPE_LRU_HASH` was added in kernel **4.10**, but classification runs from 4.11 down through runtime compilation on older kernels, which builds against the *host's* headers — so debian_9 (4.9) and ubuntu_16.04 (4.4) failed to compile outright. No other map reachable from `tracer.c` used `BPF_LRU_MAP`. Now a plain hash map. 2. On ubuntu_18.04 / amazon_4.14 (**kernel 4.18**), the added branches stopped `socket__classifier_entry` loading in the *prebuilt* object while the runtime-compiled tracer passed on the same kernel and commit. Not program size — the diagnostics add 275 instructions to a 4,096 limit — but verifier **complexity**, where pre-5.2 kernels cap processed instructions at 131,072 and prune far less. The runtime object escapes because host-specific compilation drops the version-gated branches that make the prebuilt object more complex. Hence the kernel-6.0 gate. The threshold is 6.0 rather than the functional boundary of 5.2 (where `BPF_MAXINSNS` and the complexity limit both jump to 1M) because these diagnostics only ever run on 6.x staging hosts, so there is no reason to carry risk on older kernels. `TLSDiagnosticsSupported()` fails closed if the kernel version cannot be determined, and is ANDed with classification support. Known limitations: the gate reduces complexity but **not** program size (dead instructions still count toward `BPF_MAXINSNS`); `tls_diag_events` is still created on every kernel (~72 KB) because it is declared in the ELF; and KMT distros below 6.0 no longer exercise the diagnostic code, so a regression in it would not be caught there.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54384",
        "createdAt": "2026-08-03T17:50:45Z",
        "updatedAt": "2026-08-12T17:32:04Z",
        "timestamp": "2026-08-12T17:32:04Z",
        "metrics": {
          "reactions": 1,
          "comments": 6
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "qa/done",
          "long review",
          "team/agent-build",
          "team/cloud-network-monitoring",
          "internal"
        ],
        "author": "jmw51798",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54435",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[AAD-23] Remove unused correlators",
        "text": "### What does this PR do? This PR cleans up unused Observer correlators. - removes the disabled `cross_signal` correlator - moves `passthrough` out of the production catalog and keeps it as a testbench-only adapter for raw-anomaly evaluation ### Motivation Neither correlator is used in production. `cross_signal` only recognizes three fixed source combinations, while `passthrough` is only needed to expose raw anomalies during testbench evaluation. ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54435",
        "createdAt": "2026-08-04T18:13:08Z",
        "updatedAt": "2026-08-12T20:29:37Z",
        "timestamp": "2026-08-12T20:29:37Z",
        "metrics": {
          "reactions": 0,
          "comments": 6
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "long review",
          "team/agent-build",
          "internal",
          "team/fleet-automation"
        ],
        "author": "Eokye",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54437",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[AAD-23] Remove CUSUM detector",
        "text": "### What does this PR do? This PR removes the unused CUSUM detector and its configuration, tests, testbench UI, and evaluation wiring. ### Motivation CUSUM is disabled by default, is not used, and performs poorly in its current form. On the same 12 local eval scenarios, BOCPD + TimeCluster produced 6.08x higher mean F1 while CUSUM + TimeCluster produced 24.5x more baseline false positives and took 11.75x longer in detector execution. | Metric | CUSUM | BOCPD | |---|---:|---:| | Mean scenario F1 | 0.0212 | 0.1289 | | TimeCluster predictions | 2,923 | 287 | | Baseline false positives | 1,054 | 43 | | Raw detector anomalies | 571,833 | 1,315 | | Detector-phase time | 901.0s | 76.7s | ### Describe how you validated your changes - `dda inv test --targets=./comp/anomalydetection/observer/impl/` - `dda inv test --targets=./internal/qbranch/anomalydetection-testbench/` - `dda inv anomalydetection.build-testbench` - Python syntax validation for the anomaly-eval tasks - `git diff --check` - Repository pre-commit and pre-push hooks ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54437",
        "createdAt": "2026-08-04T19:08:27Z",
        "updatedAt": "2026-08-13T17:47:15Z",
        "timestamp": "2026-08-13T17:47:15Z",
        "metrics": {
          "reactions": 2,
          "comments": 10
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "long review",
          "team/agent-build",
          "internal",
          "team/fleet-automation"
        ],
        "author": "Eokye",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54438",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Remove deprecated Install-Datadog.ps1 script",
        "text": "### What does this PR do? Removes the deprecated `Install-Datadog.ps1` script and its build/sign/deploy CI jobs, and migrates the Windows e2e install coverage that depended on it over to `datadog-installer.exe`. ### Motivation The script was already deprecated in favor of `datadog-installer.exe` (see the [deprecation note](https://github.com/DataDog/datadog-agent/blob/main/releasenotes/notes/deprecated-install-ps1-0cba33afa6fa2347.yaml)). ### Describe how you validated your changes Existing e2e coverage for the script was merged into the exe-based suite rather than dropped; these suites run in CI on this PR. ### Additional Notes Also removed `TestInstallIgnoreMajorMinor` — the behavior it asserted is no longer true now that Windows honors those variables.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54438",
        "createdAt": "2026-08-04T19:12:08Z",
        "updatedAt": "2026-08-12T15:48:31Z",
        "timestamp": "2026-08-12T15:48:31Z",
        "metrics": {
          "reactions": 1,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "team/agent-delivery",
          "long review",
          "team/container-integrations",
          "team/agent-devx",
          "team/windows-products",
          "internal"
        ],
        "author": "clarkb7",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54444",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Update dependency DataDog/dd-apm-library-python to v4.13.0",
        "text": "This PR contains the following updates: | Package | Update | Change | |---|---|---| | DataDog/dd-apm-library-python | minor | `4.12.0` → `4.13.0` | --- > [!WARNING] > Some dependencies could not be looked up. Check the [Dependency Dashboard](../issues/33469) for more information. --- ### Configuration 📅 **Schedule**: (in timezone Europe/Paris) - Branch creation - At 12:00 AM through 04:59 AM and 10:00 PM through 11:59 PM, Monday through Friday (`* 0-4,22-23 * * 1-5`) - Only on Sunday and Saturday (`* * * * 0,6`) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/DataDog/datadog-agent). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0NC4xMS40IiwidXBkYXRlZEluVmVyIjoiNDQuMjQuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiY2hhbmdlbG9nL25vLWNoYW5nZWxvZyIsImRlcGVuZGVuY2llcyIsInFhL25vLWNvZGUtY2hhbmdlIl19-->",
        "url": "https://github.com/DataDog/datadog-agent/pull/54444",
        "createdAt": "2026-08-05T00:07:19Z",
        "updatedAt": "2026-08-12T15:25:37Z",
        "timestamp": "2026-08-12T15:25:37Z",
        "metrics": {
          "reactions": 2,
          "comments": 17
        },
        "labels": [
          "changelog/no-changelog",
          "dependencies",
          "qa/no-code-change",
          "short review",
          "ask-review",
          "stop-updating",
          "team/windows-products",
          "internal"
        ],
        "author": "renovate[bot]",
        "state": "closed",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54471",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[CWS-6177] Use dynamic sampling",
        "text": "### What does this PR do? Makes CWS event sampling react to event stream backpressure instead of applying a fixed rate limit. All rate-limit decisions for the sampled event types (`open`, `connect`, `bind`, `dns`) now route through a new eBPF helper, `sampling_admission_check()` in `pkg/security/ebpf/c/include/helpers/approvers.h`. It reads the current events ring buffer occupancy with `bpf_ringbuf_query()`, converts it to a pressure percentage against the configured ring buffer size, and picks one of three behaviors: | Ring buffer pressure | Behavior | |---|---| | `< threshold` (per event type) | Bypass the rate limiter, always sample | | `threshold` to 90% | Fall back to the existing token-bucket limiter | | `> 90%` (`SAMPLING_PRESSURE_CRITICAL`) | Drop the sample outright | Thresholds are per event type and configurable, defaulting to `open: 80`, `dns: 60`, `bind: 60`, `connect: 40`. A higher threshold means the limiter is bypassed for longer, so that event type is throttled later. The whole path is gated behind a new `event_sampling.dynamic.enabled` setting and behind `USE_RING_BUFFER` plus a runtime `use_ring_buffer` check. When either is off, behavior is identical to today. Also adds a `datadog.runtime_security.event_sample.pressure_level` gauge reporting the peak pressure observed per stats window. ### Config ``` # BEFORE — fixed rate, 500 events/sec per type regardless of load runtime_security_config: event_sampling: open: enabled: true rate: 500 connect: enabled: true rate: 500 bind: enabled: true rate: 500 dns: enabled: true rate: 500 ``` ``` # AFTER — same config still valid; opt in to pressure-aware sampling runtime_security_config: event_sampling: dynamic: enabled: true # new: turns on pressure-aware admission open: enabled: true rate: 500 # now the throttled-band rate, not a hard cap threshold: 80 # new: bypass the limiter below 80% buffer pressure connect: enabled: true rate: 500 threshold: 40 bind: enabled: true rate: 500 threshold: 60 dns: enabled: true rate: 500 threshold: 60 ```",
        "url": "https://github.com/DataDog/datadog-agent/pull/54471",
        "createdAt": "2026-08-05T13:37:32Z",
        "updatedAt": "2026-08-13T14:31:44Z",
        "timestamp": "2026-08-13T14:31:44Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "team/agent-security",
          "team/ebpf-platform",
          "qa/done",
          "medium review",
          "internal",
          "team/fleet-automation"
        ],
        "author": "mftoure",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54478",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[release] Update last stable to 7.82.0",
        "url": "https://github.com/DataDog/datadog-agent/pull/54478",
        "createdAt": "2026-08-05T15:03:55Z",
        "updatedAt": "2026-08-12T20:30:33Z",
        "timestamp": "2026-08-12T20:30:33Z",
        "metrics": {
          "reactions": 2,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "team/agent-delivery",
          "short review",
          "team/agent-integrations",
          "team/agent-devx",
          "team/agent-build",
          "internal"
        ],
        "author": "temporal-github-worker-1[bot]",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54496",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "apm: use url.template for OTLP HTTP client resource names",
        "text": "## What does this PR do? Uses the OpenTelemetry `url.template` attribute when generating resource names for HTTP client spans. Client spans now use `METHOD url.template` when available and retain the method-only fallback otherwise. Server spans continue to use `METHOD http.route`. Both the current and legacy OTLP resource-name paths are covered to keep behavior consistent when operation/resource name V2 is disabled. Fixes #31570. ## Motivation HTTP client resource names currently collapse to the HTTP method even when OpenTelemetry instrumentation provides a low-cardinality URL template. Using the template produces more useful resource grouping without falling back to high-cardinality raw URLs. ## Testing Added focused unit coverage for client URL templates, method-only fallback, and client/server attribute precedence. Local `dda inv test --targets=./pkg/trace/api,./pkg/trace/otel/traceutil` could not run because Windows Defender quarantined the standalone `dda.exe` after its PyPI bootstrap failed with a TLS handshake error. CI is expected to run the required test targets. ## Additional Notes The current commit is unsigned because no local signing key is configured; it will need to be replaced with a signed commit before merge.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54496",
        "createdAt": "2026-08-05T21:37:23Z",
        "updatedAt": "2026-08-13T16:24:31Z",
        "timestamp": "2026-08-13T16:24:31Z",
        "metrics": {
          "reactions": 2,
          "comments": 8
        },
        "labels": [
          "community",
          "team/agent-apm",
          "team/agent-security",
          "team/ebpf-platform",
          "team/opentelemetry",
          "team/container-platform",
          "team/agent-delivery",
          "team/agent-integrations",
          "team/container-integrations",
          "team/agent-discovery",
          "team/agent-runtimes",
          "team/agent-log-pipelines",
          "team/agent-metric-pipelines",
          "team/agent-devx",
          "team/container-experiences",
          "team/agent-build",
          "team/action-platform",
          "team/gpu-monitoring-agent",
          "team/fleet-automation",
          "team/agent-data-plane"
        ],
        "author": "niharikag09",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54504",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Add macOS thermal check reading AppleSMC sensors and thermal pressure",
        "text": "### What does this PR do? Adds a macOS implementation of the `thermal` corecheck, which until now existed only for Windows. The check is darwin-only (`//go:build darwin`) and is registered alongside the other core checks in `pkg/commonchecks/corechecks.go:154`. It collects two independent classes of signal: - **Hardware temperatures via AppleSMC.** `thermal_darwin.c` performs raw IOKit user-client struct calls against the private `AppleSMC` service to read named 4-character sensor keys. Per-chip-generation key tables cover Apple Silicon (M1 through M5) as well as Intel Macs, and for each sensor group the hottest in-range reading is taken as the representative value. - **macOS thermal pressure level**, read from the `com.apple.system.thermalpressurelevel` Darwin notification (`0=Nominal`, `1=Moderate`, `2=Heavy`, `3=Trapping`, `4=Sleeping`). Metrics emitted: | Metric | Tags | |---|---| | `system.thermal.temperature.cpu` | `macos`, `smc`, `cpu` | | `system.thermal.temperature.gpu` | `macos`, `smc`, `gpu` | | `system.thermal.temperature.ssd` | `macos`, `smc`, `ssd` | | `system.thermal.temperature.battery` | `macos`, `smc`, `battery` | | `system.thermal.pressure_level` | `macos`, `pressure_level:<nominal\\|moderate\\|heavy\\|trapping\\|sleeping\\|unknown>` | Any sensor that is unavailable on the running machine is skipped rather than reported as zero: unreadable keys are represented as an absent `OptionalFloat`/`OptionalInt` in C, surface as `nil` in Go, and are filtered out before the gauge is submitted. Files: - `pkg/collector/corechecks/system/thermal/thermal_darwin.c` (new) — AppleSMC struct-call plumbing, SMC key tables, thermal pressure lookup - `pkg/collector/corechecks/system/thermal/thermal_darwin.h` (new) — `OptionalFloat` / `OptionalInt` / `SmcInfo` / `ThermalInfo` structs and the `getThermalInfo()` declaration - `pkg/collector/corechecks/system/thermal/thermal_darwin.go` (new) — check definition, cgo conversion, metric submission - `pkg/collector/corechecks/system/thermal/BUILD.bazel` — cgo sources, `-framework IOKit -framework CoreFoundation` link flags, darwin/ios deps - `pkg/collector/corechecks/system/thermal/thermal_stub.go` — build tag narrowed from `!windows` to `!windows && !darwin` so the no-op factory no longer shadows the new darwin implementation ### Motivation https://datadoghq.atlassian.net/browse/WINA-2934 The Agent already ships a `thermal` check on Windows (`thermal_windows.go`, backed by PDH \"Thermal Zone Information\" counters), but macOS had only the no-op stub factory, so macOS hosts reported no thermal data at all. This closes that feature-parity gap. Thermal data is particularly meaningful on macOS laptops, where sustained thermal pressure is a direct explanation for CPU throttling and the performance degradation that follows. Exposing `system.thermal.pressure_level` alongside raw die temperatures lets users correlate a drop in host throughput with the thermal state that caused it. Note that the metric names intentionally do **not** match Windows one-for-one: Windows emits `system.thermal.temperature` and `system.thermal.passive_limit` tagged per ACPI thermal zone, whereas macOS exposes discrete named sensors (CPU/GPU/SSD/battery) and a single global pressure level, so the macOS metrics are namespaced per sensor instead. ### Describe how you validated your changes **Automated** - `bazel build //pkg/collector/corechecks/system/thermal/...` — passes, no compiler warnings from the cgo/C sources. - `dda inv linter.go --targets=./pkg/collector/corechecks/system/thermal/...` — 0 issues. - Verified the `BUILD.bazel` is exactly what `bazel run //:gazelle -- ./pkg/collector/corechecks/system/thermal` generates, and that `bazel run //bazel/buildifier` reports it as correctly formatted. - Verified programmatically that the SMC key tables contain no duplicate entries and no overlap between the CPU and GPU tables. **Manual hardware QA** Because every value in this check comes from real hardware sensors, the substantive validation is a load test on physical machines: 1. Build and run the Agent on an **M1** and an **M5** Mac, both on **macOS Tahoe**. 2. Confirm baseline readings are plausible at idle: ``` DD_LOG_LEVEL=debug ./bin/agent/agent check thermal ``` (`agent check` defaults its log level to off, so `DD_LOG_LEVEL=debug` is required to see the per-sensor lines.) 3. Drive the machine into thermal stress with parallel `stress-ng` load across all cores: ``` stress-ng --cpu 0 -t 600 ``` 4. In the Datadog portal, verify over the load window that: - `system.thermal.temperature.cpu` and `system.thermal.temperature.gpu` climb well above their idle baseline and recover after the run ends; - `system.thermal.pressure_level` escalates above `0`/`nominal` (expected to reach at least `1`/`moderate`, and `2`/`heavy` on the fanless/sustained-load case) and returns to nominal on cooldown; - the `pressure_level:<name>` tag tracks the numeric value. **Status of the manual QA:** <img width=\"1191\" height=\"857\" alt=\"Screenshot 2026-08-06 at 12 24 11 PM\" src=\"https://github.com/user-attachments/assets/d02c3289-f31d-4c37-ac85-efb35ba101b5\" /> <img width=\"2114\" height=\"1146\" alt=\"Screenshot 2026-08-06 at 1 30 16 PM\" src=\"https://github.com/user-attachments/assets/8321465a-a380-457b-aa7c-72bc978b3a91\" /> **Not covered** - There are **no unit tests** for SMC. the SMC path itself is not unit-testable without hardware or an IOKit fake. - No E2E/fakeintake coverage — the macOS E2E suites do not currently provision a thermally-loadable host. ### Additional Notes - **This is a private, reverse-engineered interface.** The AppleSMC struct call has no public header and no stability guarantee across macOS releases or hardware generations; A macOS update can silently change or remove keys, in which case the affected metric simply stops being submitted rather than erroring. - **Do not shrink `SMCKeyData_t.pLimitData` back to 14 bytes.** It must stay 16 to match Apple's real layout. A previous 14-byte declaration silently corrupted every subsequent field in the struct — this is called out in a comment at the struct definition. - **Intel coverage is unverified on hardware.** The Intel CPU/GPU keys (`TC0D`/`TC0P`/`TC0C`–`TC7C`, `TG0D`/`TG0P`, `TCGC`, …) were added because the `darwin` build tag also covers amd64, but the manual QA above exercises Apple Silicon only. Intel keys are inert on Apple Silicon and vice versa, so there is no cross-architecture regression risk — but Intel readings should be spot-checked if an Intel Mac is available. - **SMC keys are case-sensitive.** The Apple Silicon lowercase `Tg*` keys and the Intel uppercase `TG*` keys are different sensors, as are the Apple Silicon `TC10`–`TC53` cluster keys versus Intel's `TC0*`. They look like duplicates but must not be merged. - **SMC Fallback** Revert this commit [e19887247a4eac8bea45a058c9ca64bc43a2e34b](https://github.com/DataDog/datadog-agent/pull/54504/changes/e19887247a4eac8bea45a058c9ca64bc43a2e34b) to add a SMC fallback, this commit get the thermal data using IOHIDEventSystemClient",
        "url": "https://github.com/DataDog/datadog-agent/pull/54504",
        "createdAt": "2026-08-06T09:26:36Z",
        "updatedAt": "2026-08-13T07:06:10Z",
        "timestamp": "2026-08-13T07:06:10Z",
        "metrics": {
          "reactions": 2,
          "comments": 6
        },
        "labels": [
          "long review",
          "qa/rc-required",
          "team/agent-devx",
          "team/agent-build",
          "team/windows-products",
          "internal"
        ],
        "author": "PedroCordeiroDataDog",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54508",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "fix(cluster-agent): gate pprof/expvar debug endpoints to loopback",
        "text": "### What does this PR do? The Cluster Agent's metrics server (`0.0.0.0:metrics_port`, default `5000`) served the entire `http.DefaultServeMux`, exposing the `pprof` and `expvar` debug endpoints (registered via blank imports in `cmd/cluster-agent/main.go`) unauthenticated to anything that can reach the pod. This routes only `/metrics` on the public mux and gates everything under `/debug/` to loopback callers, returning `404` to non-loopback requests. ### Motivation Solves #CONTP-1771 and #VULN-87907. `/metrics` must stay reachable off-pod so the node Agent can scrape Cluster Agent telemetry, so a blanket localhost bind (like the core Agent's expvar server) isn't viable — hence a per-path loopback gate. This removes an unauthenticated, network-reachable debug/DoS surface while preserving telemetry scraping and local flare tooling. ### Describe how you validated your changes - Unit tests (`TestLoopbackOnly`, `TestMetricsMuxRouting`) covering loopback vs off-host for `/metrics` and `/debug/*` — 16/16 pass. - `dda inv cluster-agent.build` links clean; `dda inv linter.go` clean; release-note lint clean. - Generated a flare. - Deployed the built cluster-agent image to a local minikube cluster and curled the live DCA pod: - **In-pod** (loopback `127.0.0.1:5000`): `/metrics`, `/debug/vars`, `/debug/pprof/*` all `200` — flare/profiler unaffected. - **Off-pod** (from a separate pod → DCA pod IP): `/debug/*` = `404`, `/metrics` = `200`. - Verified nothing else is registered on the DCA's `DefaultServeMux` (only `pprof`/`expvar`), so no routes are dropped. ### Additional Notes Brings the DCA in line with the core Agent, which already binds its equivalent `pprof`/`expvar` server to `127.0.0.1`, while keeping `/metrics` public.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54508",
        "createdAt": "2026-08-06T12:20:07Z",
        "updatedAt": "2026-08-13T14:54:42Z",
        "timestamp": "2026-08-13T14:54:42Z",
        "metrics": {
          "reactions": 1,
          "comments": 8
        },
        "labels": [
          "qa/done",
          "team/container-platform",
          "medium review",
          "qa/skip-qa",
          "team/agent-build",
          "internal"
        ],
        "author": "wdhif",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54529",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[ACTP] package and activate par-control",
        "text": "### What does this PR do? Packages and activates `par-control` on Linux and Windows: - Adds Agent package and installer wiring. - Installs process-manager definitions for `par-control` and the executor. - Adds Windows executable resources and MSI integration. - Preserves a standard service `PATH` for Unix process-manager children. - Adds Linux and Windows split-runner lifecycle E2E suites and CI jobs. Runner ownership is handled by the preceding layer. Split activation is intentionally limited to supported host deployments; Docker and Kubernetes containers continue running monolithically until their three-process topology is implemented. This PR contains only host packaging, activation, and end-to-end coverage. ### Motivation Ship the split runner consistently across supported installation paths and verify its process lifecycle on both Linux and Windows. ### Validation - Installer package tests pass locally. - Buildifier passes for the affected Bazel definitions. - Linux and Windows split-runner E2E execution is delegated to CI. ### Stack PR 9 of 9. Based on #54594.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54529",
        "createdAt": "2026-08-06T16:54:57Z",
        "updatedAt": "2026-08-13T17:30:15Z",
        "timestamp": "2026-08-13T17:30:15Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "long review",
          "team/container-integrations",
          "team/agent-runtimes",
          "team/agent-devx",
          "team/agent-build",
          "team/windows-products",
          "team/action-platform",
          "internal",
          "team/fleet-automation"
        ],
        "author": "embeaken",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54539",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Update ownership/notifications for delegatedauth component+code",
        "text": "### What does this PR do? Update ownership configs for delegatedauth component & related code. Goals: - Make it clear that _either_ credential-management OR delegated-auth-login may approve PRs - Notify #workload-identity-federation channel instead of #aaa-auth-identity-help. I didn't realize it would be sending a message about every new PR to review. This will get PRs more directly to the right reviewers.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54539",
        "createdAt": "2026-08-06T19:27:53Z",
        "updatedAt": "2026-08-13T14:07:51Z",
        "timestamp": "2026-08-13T14:07:51Z",
        "metrics": {
          "reactions": 3,
          "comments": 4
        },
        "labels": [],
        "author": "srosenthal-dd",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54540",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Add `datadog.ncm.check_failure` metric",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds a new metric on the agent, `datadog.ncm.check_failure`, which counts NCM config-check failures. ### Motivation [Inspiring Slack thread](https://dd.slack.com/archives/C08NTAS3A1E/p1785854202017089) The idea is that customers should be able to see if an NCM config sync failed or succeeded, even if there was no net change on the config. ### Changes - Add `datadog.ncm.check_failure` count, tagged with device tags and an `error:<reason>` tag - Add new errors (`ErrConfigRetrievalFailed`, `ErrPayloadSendFailed`) to cover additional errors related to config syncing - Adds device profile to `DeviceContext.GetTags` since tags now need to be built before a connection succeeds ### Describe how you validated your changes Updated unit tests in `networkdeviceconfig_test.go` Verification by running a local agent pointed at an unreachable (nonexistent) device <img width=\"832\" height=\"759\" alt=\"image\" src=\"https://github.com/user-attachments/assets/3000cd8e-fbc7-45bb-8d06-66d5d49f9494\" /> - Specifically verified the \"profile unreachable\" error ### Additional Notes Next steps are to set up an OOTB monitor on this metric.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54540",
        "createdAt": "2026-08-06T20:19:10Z",
        "updatedAt": "2026-08-12T21:27:19Z",
        "timestamp": "2026-08-12T21:27:19Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "medium review",
          "qa/rc-required",
          "team/ndm-integrations",
          "internal"
        ],
        "author": "juliewangdd",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54546",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[WINA-2940] Break Group Policy passes into timed CSE invocations",
        "text": "### What does this PR do? Gives the existing `computer_group_policy` / `user_group_policy` milestones a drill-down: the client-side extensions (CSEs) that ran inside each boot Group Policy pass, and the Group Policy objects that fed each one. New `custom.group_policy_details` block, a sibling of the untouched `boot_timeline` and `durations`. This is the real block from the validation boot, verbatim apart from abbreviated GUIDs: ```json \"group_policy_details\": { \"computer\": [ { \"cse_id\": \"{35378EAC-…}\", \"cse_name\": \"Registry\", \"offset_ms\": 8058, \"duration_ms\": 127, \"result\": \"success\", \"gpos\": [{ \"id\": \"{11BBEC75-…}\", \"name\": \"ZZ Probe C & D\" }, { \"id\": \"{29227867-…}\", \"name\": \"ZZ Probe Beta\" }, { \"id\": \"{9905CA71-…}\", \"name\": \"ZZ Probe Alpha\" }, { \"id\": \"{31B2F340-…}\", \"name\": \"Default Domain Policy\" }] } ], \"user\": [ { \"cse_id\": \"{35378EAC-…}\", \"cse_name\": \"Registry\", \"offset_ms\": 6210, \"duration_ms\": 53, \"result\": \"success\", \"gpos\": [{ \"id\": \"{11BBEC75-…}\", \"name\": \"ZZ Probe C & D\" }, { \"id\": \"{29227867-…}\", \"name\": \"ZZ Probe Beta\" }] } ] } ``` Two more fields exist and are `omitempty`, so neither appears above: `async` (false throughout this boot) and `gpos_omitted` (nothing was dropped). The block is omitted entirely when no invocation was measured end to end. **Shape.** Flat `computer` / `user` arrays, so the JSON *is* the tree the UI renders. GPOs are inlined per invocation rather than pooled behind a GUID join, so a consumer needs no join — and the set is self-pruning, since a GPO reaches the wire only when a surviving boot-pass invocation references it. `offset_ms` comes from `bootOffsetFunc`, extracted out of `buildTimelineMilestones` so an invocation and its parent milestone sit on one axis: the login-screen gap collapse means a raw boot-relative offset would render a user-pass CSE *outside* its own pass. One duration field, the measured 4016→terminal interval, which is the same kind of wall-clock measurement as the 4000→8000 pass duration it is a slice of. **Attribution.** Events 4002–4007 (network-state change, `gpupdate`, periodic refresh) are not collected — their invocations are not part of the boot pass, and counting them there lets the child durations sum past the parent. Scope comes from a pass-activity table pinned by the **pass start events only**, 4000 and 4001. Taking the activity from the same event that sets the milestone timestamp is what makes a populated scope array imply its parent: this block cannot describe timed slices of a pass `boot_timeline` does not report. Three guards sit on the table: the zero GUID is refused, because events outside any pass genuinely carry it — 16 of them on the validation boot; one activity may not pin two scopes, or its bucket is emitted under both; and an activity ID matching no boot pass is dropped, never charged to the most recent pass. An earlier revision also seeded the table from 8000/8001, to recover a pass whose start event was missing. **The trace that motivated that does not have the shape it was read as having, and the claim is retracted.** Re-read with `Get-WinEvent -Path`, the trace lacking 4001 also lacks 8001: its second activity is a **4004/8004** pair, machine *manual* processing. So there is nothing to recover, and 8000/8001 carry no `PolicyActivityId` in any case. **Only measured invocations are emitted.** An unmatched terminal, an unmatched start, and an invocation still open when the trace ends have no interval to place on the timeline; a record without one is a collection diagnostic rather than latency data. A duplicate open start keeps the later one, and a terminal event that precedes its start is refused and leaves the start open. **Bounds.** Four constants cap what one payload may carry, fixed rather than configurable: 64 invocations per scope, 32 distinct GPO references per invocation, 128 bytes of CSE name, 512 bytes of GPO name. `TestSubmitEvent_WorstCasePayloadSize` couples all four through **one** byte budget — it builds the largest payload the caps permit and asserts it stays under 3 MB uncompressed, so raising any single cap fails that one test. Currently 2,373,734 bytes against the ceiling, 626 KB of margin. They are mandatory rather than prudent, because oversize fails silently and unrecoverably. The `event-management` pipeline uses `useStreamStrategy: true`, and `streamStrategy` has no size logic and never splits — `batch_max_content_size` and `logs_config.max_message_size_bytes` are both inert on this path. Oversize therefore surfaces only as an intake **HTTP 413**, which increments `tlmDropped` and returns a non-retryable `errClient`; `SendEventPlatformEventBlocking` has already returned `nil` by then, so the component can never learn its event was discarded. The payload size distribution is unmeasured, but an undetectable failure mode justifies a deterministic bound at any frequency. `retainMostRelevant` cuts an over-long invocation list: non-success outcomes first, then the longest durations, tie-broken on CSE ID. It has to run **before** the caller's chronological sort — sort-then-truncate would keep the head of the pass and drop whatever ran late in it, which is the opposite of useful. GPO overflow is reported per invocation as `gpos_omitted`, and the collector's `seen` set is what keeps that count exact: a GUID repeated past the cap is not a fresh loss. `truncateProviderText` cuts on a UTF-8 boundary, since a 512-byte cut through a multi-byte character would emit invalid UTF-8. **GPO lists.** `ApplicableGPOList`'s runtime format is now confirmed against a real boot: a **rootless `<GPO ID=\"{GUID}\"><Name>…</Name></GPO>` sequence carrying ID and Name only**. So IDs come from the `ID` attributes and display names come free from 4016, **and 5312 is not collected at all** — one walk yields both. This closes the open validation earlier revisions flagged: on the boot capture every name 5312 supplied for an emitted invocation was already on that invocation's own 4016, and on the earlier capture its `GPOInfoList` is empty on both events. Re-running `analyzeETL` over the boot ETL with the 5312 arm removed produces an unchanged block, all four display names included. `name` is `omitempty`, so the wire schema is unaffected. What survives is the shared GUID→name lookup, which is no longer a merged inventory but the thing that lets an invocation whose list ended early borrow a name from one that parsed cleanly. The braced-GUID scan is kept as a fallback for a fragment the token walk cannot finish and for a delimited or prose value. **It is only safe on `ApplicableGPOList`**: 5312's `GPOInfoList` carries a fuller entry that embeds `<Extensions>[{CSE GUID}{…}]</Extensions>`, so scanning that fragment would report an extension's own GUID as an applicable GPO. Not collecting 5312 makes that **structural rather than an ordering discipline** — the scan can only ever be handed `ApplicableGPOList`, which has no `<Extensions>` at all. **The fragments are not well-formed XML, and this cost real data.** Windows builds them by concatenation and does **not** escape display names, so a GPO named `R&D Baseline` arrives carrying a bare `&`. The validation boot had exactly that, first in every one of its four lists. Under Go's default strict decoder `DecodeElement` fails on that entry and the walk abandons everything behind it — the payload emitted all four GPO references with **no display name at all**. Two further failure modes sat one position away: when the offending name is not first, the partial tier-1 result satisfies the `len(ids) > 0` short-circuit and the scan fallback never runs, so the tail of the list is **dropped outright**; and on any fragment that does carry `<Extensions>`, the fallback reports the extension GUID as a GPO. `decoder.Strict = false` fixes the ampersand, but **only narrows the mid-list class rather than closing it**, which review caught. Non-strict decoding forgives malformed entities and missing end tags — it does not relax tag syntax. So a display name whose `<` does not open a well-formed tag, or a mismatched end tag like `</Nam>`, still ends the walk partway, and the short-circuit still returns the prefix. The walk now reports whether it reached end of input (`errors.Is(err, io.EOF)` — a clean end *is* `io.EOF`) and the fallback runs on **any** incomplete walk, appending the IDs it could not reach. Two table rows cover both malformations mid-list; reverting the guard fails exactly those two and nothing else. **Two supporting changes in `pkg/util/winutil/etw`:** - Expose `EVENT_HEADER.ActivityId`. Windows runs more than one instance of policy processing concurrently, so pairing on the extension GUID alone would cross unrelated passes. The boot capture makes this concrete: the **same** Registry CSE GUID `{35378EAC-…}` runs in both the computer and the user pass, and only the activity ID separates them. The header is also the *only* correlator available for a pass stop event: 4000/4001 do carry `PolicyActivityId` as property [0], equal to the header value, but **8000/8001 do not carry it at all** — their template is `PolicyElaspedTimeInSeconds, ErrorCode, PrincipalSamName, IsMachine, IsConnectivityFailure`. - `EventProperties` returns the properties decoded before a failure alongside the error instead of discarding all of them. A 4016 carries seven properties including three long strings, and one bad decode previously zeroed every field on the event. Parsing still stops at the first failure and never skips ahead — the property cursor is shared, so everything after a failure is garbage rather than merely missing. This is a **contract change to a shipped function** (\"nil map on error\" → \"possibly-populated map on error\") that the new block does not strictly require — without it the reader falls through to the per-property path, which still yields `\"\"`. Both callers repo-wide were checked: `GetEventPropertyString` tests `err` before touching the map, and `eventPropertyReader` is the intended consumer. Worth stating plainly that `pkg/util/winutil/etw` contains no test files, so this and the `ActivityId` population ship with no coverage in their own package. The recovery helps 4016 and does nothing for the stop events, because the templates disagree on property order: `CSEExtensionId` is property **[0]** on 4016 but **[3]** on 5016/6016/7016. A partial decode therefore *degrades* a start, losing the async flag and the GPO list, and *annihilates* a stop, losing the identity so its start is left open and dropped at finalize. `GetPropertyByName` is not a fallback for it — that path reads raw bytes as UTF-16, turning a 16-byte `win:GUID` into eight junk runes. `TestPartialDecodeDegradesAStartButDropsAStop` locks both directions. **One cleanup, not a fix:** `submitEvent` read `total_boot_duration_ms` back out of the payload map and formatted an `interface{}` with `%d`. That always worked — the boxed value is an `int64` — so it is fragility rather than a bug, and the new condition is provably identical: the old gate, `durations` present and carrying the key, is exactly `haveBoot && haveLogon`, which is `complete`. Note it leaves `impl_darwin.go` on the old pattern, so the two platforms now express this one line differently. ### Motivation Group Policy was reported as two aggregate milestones, each a single start/end pair. When Group Policy is the slow phase of a boot, that tells an operator *that* GP was slow and nothing about *what* in GP was slow. **No installer or autologger change is required**, and the validation boot proves it rather than arguing it: that ETL was captured by a **stock, released Agent 7.82.0 autologger** with no modification, and it contains every event this PR consumes. The GroupPolicy mask is `0x4000000000000000`, the channel-wide Operational keyword, and the session runs at `EnableLevel=4`; ETW treats level as a ceiling, so 4016/5016 (Informational), 6016 (Warning) and 7016 (Error) are all admitted. The only MSI edit here is comment-only. The file cap is 256 MB sequential and this capture came in at 6.2 MB, so truncation is not a factor either. ### Describe how you validated your changes Two real captures, on top of the unit suite. **1. A real autologger boot ETL from a domain-joined host** (6.2 MB, 43,250 events, `EventsLost 0`, three probe GPOs linked at the domain root all feeding the Registry CSE, plus HKCU settings so user-scope CSEs run). Decoded four independent ways — two `tracerpt` passes, `Get-WinEvent -Path`, and the analyzer itself — with agreeing event histograms. **`analyzeETL` ran clean end to end on real boot data for the first time.** No error, all 23 `BootTimeline` fields set, 11 milestones, 12 `durations` keys, and `group_policy_details` populated in **both** scopes — the payload quoted at the top of this description. An independent recomputation of `bootOffsetFunc` straight from raw ETW timestamps reproduced the analyzer's output exactly: `computer_group_policy` 7308 ms / 913 ms, `user_group_policy` 5956 ms / 318 ms, machine CSE 8058 ms / 127 ms, user CSE 6210 ms / 53 ms, `total_boot_duration_ms` 28394. Two independent derivations agreeing is what establishes the offset extraction is faithful. Confirmed by that boot: - **Nesting holds on real data.** Machine CSE [8058, 8185] sits inside `computer_group_policy` [7308, 8221]; user CSE [6210, 6263] inside `user_group_policy` [5956, 6274] — both after a 35215 ms gap collapse. This is the property `TestCSEOffsetsShareTheBootTimelineAxis` locks. - **Activity-ID scoping works as designed.** Three distinct activity IDs: the computer pass carrying 4000/5312/4016/5016/8000 on one thread, the user pass carrying 4001/5312/4016/5016/8001 on another, and **the zero GUID on 16 service-lifecycle events outside any pass** (including both occurrences of 4117). No CSE event carried an activity matching no pass. Refusing the zero GUID is confirmed necessary a second time. - **All four pass boundaries present**, each pass on its own activity ID and its own thread, which is what start-only pinning needs. - **A real non-boot refresh pass is observed being excluded** — on the earlier trace, not this one. It carries a **4004/8004 pair triggered over RPC by a third-party service**, with event 5321 recording the attribution verbatim: `Group Policy refresh via RPC. Target=Machine ParentProcess=\"…\\services.exe\" RpcClient=\"…\\lenovo\\UDC\\Service\\UDClientService.exe\" Account=\"NT AUTHORITY\\SYSTEM\"`. Re-running the analyzer over it, the refresh pass is absent from the payload. So the 4002–4007 exclusion has observational backing and not only a synthetic test. - The measured 4016→terminal interval tracks the provider's own `CSEElaspedTimeInMilliSeconds` within one timer tick: 127 vs 140 and 53 vs 46 here, 62.4 vs 63 and 46.7 vs 47 elsewhere. `TimerResolution` on this trace is 15.625 ms, which accounts for the spread. **2. A `logman` + `gpupdate /force` capture** at the identical provider GUID, keyword and level, to settle the `ApplicableGPOList` format without waiting for a boot. This is what produced the format finding and the unescaped-ampersand finding above. It also observed `IsExtensionAsyncProcessing=true` in the wild (the Security CSE), which the boot capture does not contain. **3. An earlier Agent-captured ETL** (1.4 MB, 10,017 events, 32 Group Policy events) read alongside the `Microsoft-Windows-GroupPolicy` manifest via `ProviderMetadata`. This is the trace whose mixed `IsMachine` renderings made scope-from-event-ID look justified — and the manifest now explains why they differ rather than leaving it a quirk: **4000/4001, 4002–4007 and 8000–8007 each ship a version 0 and a version 1 template, and `IsMachine` is `win:Boolean` in v0 but `win:UInt32` in v1.** On the validation boot all four boundary events are v1 and it reads a perfectly consistent `1/0/1/0`. Deriving scope from the event ID is still right, but because the field is version-dependent, not because it is unreliable. Two further claims previously made about this trace are **retracted**: it does not carry 8001 without 4001, per Attribution above, and its computer pass did not fail — `ErrorCode` is `0` on both 8000 and 8004, and no property anywhere in the trace equals 1355. It does carry two 5312 events, both with an empty `GPOInfoList`. `group_policy_details` is correctly absent, but because the trace contains no 4016 at all. None of the ETLs are committed as fixtures: they carry machine names, a domain, and user SAM names. **Unit tests.** `grouppolicy_test.go` drives synthetic events through the real `processEvent` dispatch, feeding the mock the exact strings TDH produces for each declared out-type. Six guard the attribution rules specifically: `TestPassStopAloneNeverPins` proves a pass stop event cannot pin a scope by itself, `TestZeroActivityIDNeverPins` guards the zero-GUID sweep, `TestPassActivityIsNotSharedBetweenScopes` stops one activity being emitted under both, `TestCSEWithNoBootPassIsOmitted` proves an unmatched activity is dropped rather than charged to the most recent pass, `TestGPUpdateInvocationsAreExcluded` proves a `gpupdate` CSE stays out of the boot pass, and `TestCSEOffsetsShareTheBootTimelineAxis` locks an invocation inside its parent milestone with a login-screen gap present. `TestGPONamesSurviveUnescapedAmpersand` and two new table rows in `TestGPORefsFromList` cover the escaping fix, in both the first and mid-list positions — reverting `decoder.Strict = false` fails all four with the three distinct symptoms described above. `TestInvocationBackstopKeepsTheLeastHealthyAndTheSlowest` locks the retention order against the chronological sort. `TestBuildTimelineMilestones` passes **unmodified**, which is what proves `bootOffsetFunc` is a faithful extraction. `dda inv test --targets=./comp/logonduration/impl` — 149 passing, none failing, none skipped. `dda inv linter.go` clean on both `./comp/logonduration/impl` and `./pkg/util/winutil/etw`. Writing the tests caught a real bug independently of the captures: dropping the XML tier in favour of a pure braced-GUID scan silently harvested the CSE GUID out of a 5312-shaped entry's `<Extensions>` element and reported it as an applicable GPO. ### Additional Notes **`error_code` is removed, and the field set is now deliberate rather than incidental.** Earlier revisions carried the provider's status on each invocation. It is gone. The block reports what ran inside a pass and for how long; *why* an extension failed is a Group Policy health question, and it is the only annotation here a consumer can recover elsewhere — the code is in the host's own Group Policy Operational log, whereas `result` and `async` exist nowhere but this payload and both govern how `duration_ms` must be read. Removing it also retires a wire contract that existed solely to carry it: a hex string rather than a JSON number, parsed base 0 because the property is declared `win:HexInt32`, so that a status above `0x7FFFFFFF` does not round-trip as a negative signed integer. A fleet-level view of *which* status a slow pass failed with is worth having, but it is a different feature from a CSE→GPO latency breakdown and belongs in its own PR with its own release note. The two fields that stay are load-bearing, not decoration. `result` is nearly free — 5016/6016/7016 have to be accepted regardless, because a CSE that ends in warning or error still consumed wall-clock time inside the pass, and without its terminal event its start is never closed and the invocation is dropped at `finalize`. Given the dispatch already switches on the ID, the outcome is a byproduct; dropping the field while keeping the events would render a 45 s invocation that timed out identically to a 45 s invocation that did work. `async` redefines the primary number: when `IsExtensionAsyncProcessing` is set the terminal event marks worker-thread dispatch, so `duration_ms` is the cost of the dispatch and not of the extension's work. The stop events still carry `ErrorCode` and the synthetic ones in the tests still populate it — now with a non-zero E_PENDING, so every test that asserts on an emitted invocation also proves the field does not leak back into it. `TestCSEPairingOutcomes` gains meaning from that: a 5016 carrying a non-zero status still reports `success`, because the event ID is what is read. The release note is unchanged, having always described the block as offset, duration, and outcome. Also incidental: a merge of `main` left this package's tests not compiling, because `newPayloadTestComponent` was still passing the `compression` argument #54480 removed. Fixed here. **Four pre-existing bugs the captures exposed**, each left for its own PR because each moves an already-shipped number and deserves its own release note: 1. Pass endpoints are first-write-wins per event ID with no ActivityID pairing, so a start from one processing instance can pair with an end from another. The activity table makes the *children* consistent; the parent duration is still unpaired. 2. Both Group Policy milestones key off the **start** event alone, so a trace carrying only 8000 or only 8001 discards the endpoint it does have and drops the milestone and its `durations` entry silently. Latent rather than observed — the 8001-without-4001 shape that first motivated this is the one retracted above, and neither capture actually contains it. It is still a real hole, and it is the same first-write-wins-with-no-pairing weakness as bug 1. 3. `offset_ms` is non-monotonic for a milestone inside the collapsed login-screen gap, and this now reproduces on two traces with different numbers. On the earlier one `computer_group_policy` is at 19859 ms while the later `logon_duration` is at 9984 ms; on the boot trace `computer_group_policy` at 7308 ms lands after both `user_group_policy` at 5956 ms and `logon_duration` at 5687 ms. The machine pass falls inside the gap but is `Before(SessionLogon)`, so it escapes the subtraction while everything after logon is pulled left. 4. **New:** the boot trace carries **two** Winlogon 103/104 pairs, and first-write-wins takes the 11 ms pair over the 112 ms pair that follows it 5 s later. That choice sets the gap to 35215 ms instead of 30259 ms and is what amplifies bug 3 on this trace — with the second pair the inversion disappears. It also changes `login_ui_start.duration_ms` from 11 to 112, so picking the right pair is a shipped-number change in its own right. Separately, `boot_timeline` is emitted in the source order of a hardcoded candidate list and never sorted by `offset_ms`, so `logon_duration` precedes `user_group_policy` in the array while trailing it in time. That one is structural rather than trace-dependent. 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
        "url": "https://github.com/DataDog/datadog-agent/pull/54546",
        "createdAt": "2026-08-07T01:10:23Z",
        "updatedAt": "2026-08-13T15:40:27Z",
        "timestamp": "2026-08-13T15:40:27Z",
        "metrics": {
          "reactions": 1,
          "comments": 6
        },
        "labels": [
          "qa/done",
          "long review",
          "team/agent-build",
          "team/windows-products",
          "internal"
        ],
        "author": "briantu",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54547",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "macos: notable-events collector health stats",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? [MacOS] Implement health stats for notable-events collector so operators can diagnose a stalled or saturated collector from a flare. ### Motivation This is follow-up of PR #54084. ### Describe how you validated your changes Inspect the heath stats with local tests and ensure CI pipeline passes. Commands used for validation: agent status agent status -j | jq '.systemProbeStats.notable_events' ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54547",
        "createdAt": "2026-08-07T01:26:07Z",
        "updatedAt": "2026-08-12T20:25:16Z",
        "timestamp": "2026-08-12T20:25:16Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "team/ebpf-platform",
          "qa/done",
          "long review",
          "ask-review",
          "team/agent-build",
          "team/windows-products",
          "internal",
          "team/fleet-remediation"
        ],
        "author": "guohdd",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54548",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[DSEC-232] Destroy scanner and free cache once rust check finish",
        "text": "### What does this PR do? Bumps `dd-sensitive-data-scanner` to `0.1.0-20260807-dcc653f6f465` and, in the `datasecurity` rust check, drops the scanner and clears dd-sds' global regex caches once scanning finishes. ### Motivation Keep the check's idle memory footprint near zero between runs by releasing the scanner and its cached compiled regexes as soon as they're no longer needed. ### Describe how you validated your changes `cargo build -p datasecurity --locked` and `cargo test -p datasecurity` pass. ### Additional Notes Caches are cleared even when a sub-task fails, and only after the scanner is dropped (dd-sds reclaims only unreferenced compiled regexes).",
        "url": "https://github.com/DataDog/datadog-agent/pull/54548",
        "createdAt": "2026-08-07T03:35:45Z",
        "updatedAt": "2026-08-13T12:26:18Z",
        "timestamp": "2026-08-13T12:26:18Z",
        "metrics": {
          "reactions": 2,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "medium review",
          "team/agent-devx",
          "team/agent-build",
          "internal"
        ],
        "author": "aimenebelfodil",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54549",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Add BUILD files for some straggler test tools",
        "text": "### What does this PR do? Create build files for some non-product manual test tools. ### Motivation They are not on any critical path, but we're adding the BUILD files for completeness.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54549",
        "createdAt": "2026-08-07T04:50:57Z",
        "updatedAt": "2026-08-12T20:32:12Z",
        "timestamp": "2026-08-12T20:32:12Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "qa/no-code-change",
          "medium review",
          "team/agent-build",
          "internal"
        ],
        "author": "aiuto",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54556",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[DOIO-171] Add MySQL query action dispatch",
        "text": "Data Observability query actions now dispatch remote configuration payloads to MySQL checks as well as Postgres and SAP HANA. The component uses one supported-integration allowlist for startup detection and instance matching, so unrelated integrations cannot activate the subscription or receive query configs. Closes https://linear.app/datadog/issue/DOIO-171",
        "url": "https://github.com/DataDog/datadog-agent/pull/54556",
        "createdAt": "2026-08-07T08:28:45Z",
        "updatedAt": "2026-08-13T17:47:03Z",
        "timestamp": "2026-08-13T17:47:03Z",
        "metrics": {
          "reactions": 2,
          "comments": 7
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "medium review",
          "team/data-jobs-monitoring",
          "internal"
        ],
        "author": "mobuchowski",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54563",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[EBPF] Gate NVML workloadmeta collector on GPU monitoring",
        "text": "### What does this PR do? Gates the NVML workloadmeta collector on `gpu.enabled`. ### Motivation Avoid NVML collection when GPU monitoring is disabled. ### Describe how you validated your changes Added unit coverage for disabled startup. ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54563",
        "createdAt": "2026-08-07T11:43:56Z",
        "updatedAt": "2026-08-13T07:46:17Z",
        "timestamp": "2026-08-13T07:46:17Z",
        "metrics": {
          "reactions": 1,
          "comments": 10
        },
        "labels": [
          "changelog/no-changelog",
          "team/ebpf-platform",
          "qa/done",
          "medium review",
          "team/agent-build",
          "internal",
          "team/gpu-monitoring-agent",
          "backport/7.82.x",
          "backport/7.83.x"
        ],
        "author": "gjulianm",
        "state": "closed",
        "assignees": [
          "gjulianm"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54566",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Split macOS-only corechecks into MACOS_CORECHECKS",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds a new `MACOS_CORECHECKS` list to `tasks/core_checks.py` (and its byte-identical mirror `cmd/agent/dist/core_checks.bzl`), moves `battery` and `wlan` out of `AGENT_CORECHECKS` into it, and adds both to `WINDOWS_CORECHECKS`. Wires the new list up the same way `WINDOWS_CORECHECKS` already is: - `tasks/agent.py`: `refresh_assets` gets a `sys.platform == 'darwin'` copy loop that installs each `MACOS_CORECHECKS` check's `conf.d` directory, alongside the existing Windows-only loop. - `cmd/agent/dist/conf.d/BUILD.bazel`: adds a `macos_checks_files` `pkg_files` target (globbing over `MACOS_CORECHECKS`), merged into the existing `@platforms//os:macos` select branch next to `:macos_files`. ### Motivation `AGENT_CORECHECKS` is meant for checks available on every platform, but `battery` and `wlan` only collect on macOS and Windows — `pkg/collector/corechecks/system/battery/battery_nix.go` and `pkg/collector/corechecks/net/wlan/wlan_nix.go` are both built with `//go:build !darwin && !windows` and return an error (\"battery/wifi info only supported on macOS and Windows\") everywhere else. Both configs are Autodiscovery templates (`ad_identifiers: [_end_user_device]`), so on Linux and AIX they were dead files in the package on a default install, and under `infrastructure_mode: end_user_device` they scheduled a check that could never collect. Giving macOS-only checks their own list, mirroring the existing `WINDOWS_CORECHECKS` pattern, keeps `AGENT_CORECHECKS` accurate and makes the per-platform packaging explicit. ### Why `WINDOWS_CORECHECKS` also changes `AGENT_CORECHECKS` feeds the `base_checks_files` target, which is included on *every* platform via the `//conditions:default` branch of the `select` in `cmd/agent/dist/conf.d/BUILD.bazel`. Removing `battery`/`wlan` from it would therefore have dropped both configs from the **Windows** package too, which would break `TestEUDMWindowsSuite` (`test/new-e2e/tests/agent-runtimes/infra_eudm_win_test.go`) — it asserts the `wlan` check is scheduled and runs in `end_user_device` mode. Adding both names to `WINDOWS_CORECHECKS` keeps the Windows package byte-identical to before this PR. ### Describe how you validated your changes - Built the agent natively on macOS/arm64 with `dda inv agent.build` and confirmed `bin/agent/dist/conf.d/` contains `battery.d/` and `wlan.d/`, verifying the new darwin-only copy path in `tasks/agent.py`. - `bazel run //bazel/buildifier` and `bazel run //:gazelle` are clean. - `//cmd/agent/dist:core_checks_list_sync_test` passes (the `.py` and `.bzl` copies are identical). - Verified per-platform package contents: ``` bazel cquery --platforms=@platforms//os:linux 'deps(//cmd/agent/dist/conf.d:all_files)' | grep -E 'battery|wlan' # expect empty bazel cquery --platforms=@platforms//os:macos 'deps(//cmd/agent/dist/conf.d:all_files)' | grep -E 'battery|wlan' # expect present bazel cquery --platforms=@platforms//os:windows 'deps(//cmd/agent/dist/conf.d:all_files)' | grep -E 'battery|wlan' # expect present ``` - Manually installed the agent on macOS/arm64 from a real CI pipeline build artifact (via the pipeline's `install_mac_os.sh` install script, fetched over a short-lived presigned S3 URL) and confirmed `battery.d/` and `wlan.d/` are present under the installed agent's `conf.d/`, alongside the standard cross-platform checks (e.g. `cpu.d/`, `memory.d/`) — validating the new macOS packaging end-to-end on a real installed build, not just the local dev build. ### Additional Notes `battery` and `wlan` work on both macOS and Windows, so they are listed in `MACOS_CORECHECKS` *and* `WINDOWS_CORECHECKS`. A check belongs in every platform list that can actually collect it. Labelled `qa/rc-required`: this changes package contents, and per-platform package contents are not verified by PR-branch CI.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54566",
        "createdAt": "2026-08-07T12:52:23Z",
        "updatedAt": "2026-08-12T13:58:03Z",
        "timestamp": "2026-08-12T13:58:03Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "medium review",
          "qa/rc-required",
          "team/agent-runtimes",
          "team/agent-devx",
          "team/agent-build",
          "internal"
        ],
        "author": "PedroCordeiroDataDog",
        "state": "closed",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54567",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[datasecurity] add malloc trim",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54567",
        "createdAt": "2026-08-07T13:06:39Z",
        "updatedAt": "2026-08-13T09:57:38Z",
        "timestamp": "2026-08-13T09:57:38Z",
        "metrics": {
          "reactions": 0,
          "comments": 4
        },
        "labels": [],
        "author": "aimenebelfodil",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54585",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "ebpf: validate runtime-compiler cache directory and open cached objects via verified fd",
        "text": "### What does this PR do? Tightens how system-probe's runtime-compiled eBPF object cache is created and consumed: - Adds `secureRuntimeDir`, which creates the runtime-compiler output directory root-only (`0700`) and verifies that it — and every ancestor up to the filesystem root — is a real directory owned by root and not writable by other users. The sticky bit is accepted for the default `/var/tmp` parent. If the tree is not under root's control, runtime compilation is skipped instead of using it. - Adds `VerifyAssetPermissionsAndOpen`, which opens the compiled object with `O_NOFOLLOW` and checks ownership/permissions on the returned file descriptor. The runtime compiler and `GetReader` now consume that descriptor directly instead of re-opening the file by path, so the bytes that are loaded are the same bytes that were verified. - Treats only a regular file as a valid cache entry (a non-regular entry is removed and recompiled). ### Motivation The runtime-compiler cache defaults to a location under the world-writable `/var/tmp`, and the compiled object was previously verified and then re-opened by path in two separate steps. Making the directory root-owned and reusing the verified descriptor keeps the whole compile → verify → kernel-load path under root's control and removes the second path resolution. Hardening / robustness improvement. ### Describe how you validated your changes - New unit tests for the rejection paths: `O_NOFOLLOW` symlink rejection and non-root-owned file rejection (`permissions_test.go`); non-root-owned and symlinked-component cache directory rejection (`asset_test.go`). - Ran `dda inv test --targets=./pkg/ebpf/bytecode/` and `--targets=./pkg/ebpf/bytecode/runtime/ --build-include=linux_bpf` — all pass. - Manually validated on an Ubuntu 24.04 (kernel 6.8, arm64) VM with `enable_runtime_compiler: true`, `enable_co_re: false`, `allow_precompiled_fallback: false`: - Correctly provisioned host: `tracer.c` / `conntrack.c` runtime-compiled and loaded into the kernel; cache tree created `root:root 0700`. No behavior change. - Directory pre-created by a non-root user: system-probe declines to use it (`refusing to use compiler output directory: … is not owned by root`) and the module falls back cleanly instead of loading from the untrusted location. ### Additional Notes No release note is included in this PR (a `changelog/no-changelog` label will be needed to satisfy the reno CI check).",
        "url": "https://github.com/DataDog/datadog-agent/pull/54585",
        "createdAt": "2026-08-07T15:49:30Z",
        "updatedAt": "2026-08-12T14:42:41Z",
        "timestamp": "2026-08-12T14:42:41Z",
        "metrics": {
          "reactions": 1,
          "comments": 6
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "team/ebpf-platform",
          "qa/done",
          "long review",
          "team/agent-build",
          "internal"
        ],
        "author": "mbertrone",
        "state": "closed",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54589",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[ACTP] add par-control process lifecycle",
        "text": "### What does this PR do? Adds the process-lifecycle boundary for `par-control`: - Uses the shared `dd-procmgr-client` connector for local IPC on Linux and Windows. - Loads the minimal configuration needed to gate split mode. - Exposes one-shot executor lifecycle operations to start or adopt the executor, inspect liveness and terminal state, and stop it. - Intentionally leaves the executor stopped during control-plane startup; the later orchestration layer invokes the lifecycle only after leasing a task rather than prewarming or continuously polling the executor. - Bounds process-manager RPCs and handles platform-specific shutdown, logging, and Windows `ConfigRoot` paths. - Tests the real generated gRPC client against an in-process fake `dd-procmgrd`. `par-control` and the executor are siblings owned by `dd-procmgrd`. A `Start` race that returns `FAILED_PRECONDITION` therefore adopts the already-alive executor. During its own shutdown, `par-control` does not call back into `dd-procmgrd`, which may already be waiting for it to exit. ### Validation - `dda env dev run -- bazel test //pkg/privateactionrunner/par-control:par-control_test` - `dda env dev run -- bazel build //pkg/privateactionrunner/par-control:par-control` - `dda env dev run -- env -u PKG_CONFIG_LIBDIR cargo clippy --manifest-path pkg/privateactionrunner/par-control/Cargo.toml --all-targets -- -D warnings`",
        "url": "https://github.com/DataDog/datadog-agent/pull/54589",
        "createdAt": "2026-08-07T17:44:51Z",
        "updatedAt": "2026-08-13T17:47:56Z",
        "timestamp": "2026-08-13T17:47:56Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "long review",
          "team/agent-devx",
          "team/agent-build",
          "team/action-platform",
          "internal"
        ],
        "author": "embeaken",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54590",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[ACTP] add par-control effective configuration",
        "text": "### What does this PR do? Adds the effective configuration and identity bootstrap layer for `par-control`: - Adds a Go helper subcommand that exports the Agent's resolved configuration. - Loads split-runner configuration from Rust. - Resolves local and Fleet-managed settings consistently. - Loads and persists runner identity. - Supports self-enrollment bootstrap. - Adds the required schema and setup wiring. Configuration production and consumption stay together in this PR so their contract can be reviewed as one behavior. ### Motivation Give the control process the same effective configuration as the Agent without duplicating configuration precedence or persisting a second plaintext configuration snapshot. ### Validation - Focused Go tests pass locally. - Portable Rust tests pass locally. - Relevant Go and Rust builds pass locally. ### Review fixes - **Process-manager socket**: falls back to dd-procmgrd's own `DD_PM_SOCKET_PATH` when `private_action_runner.procmgr_socket_path` is unset, before the platform default. Previously, relocating the daemon's socket also required setting a second, PAR-specific value. Resolution goes through the injected env lookup so it is testable without mutating process state, and an empty setting is treated as unset like the executor socket. - Carries the RPC deadlines, the `wait_for_failure` semantics, and the fake-daemon tests into the injected-socket `ProcmgrLifecycle` introduced here. - Same program-data-root log path, so the Windows log location no longer depends on where `--config` points. `platform.rs` also takes over the fleet-policies-dir registry lookup that was inline here. ### Stack PR 4 of 9. Based on #54589; followed by #54591.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54590",
        "createdAt": "2026-08-07T17:47:32Z",
        "updatedAt": "2026-08-13T17:49:14Z",
        "timestamp": "2026-08-13T17:49:14Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "long review",
          "team/agent-devx",
          "team/agent-build",
          "team/action-platform",
          "internal",
          "team/fleet-automation"
        ],
        "author": "embeaken",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54591",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[ACTP] add par-control executor channel",
        "text": "### What does this PR do? Defines the local control-to-executor channel and implements both ends of it: - Adds the executor gRPC protocol and generated bindings. - Exposes executor health and readiness. - Synchronizes workflow signing keys. - Streams action dispatch outcomes. - Adds the Rust mTLS client and transport support. - Keeps the shared terminal `Outcome` model with the executor layer. This layer provides communication primitives only; polling and process-lifecycle policy remain in later layers. ### Motivation Create a narrow, authenticated local contract between `par-control` and the existing Go executor before introducing OPMS polling or orchestration. ### Validation - Focused Go tests pass locally. - Private Action Runner Go build passes locally. - Portable Rust tests pass locally; native-tls identity coverage requires Linux/Windows. ### Review fixes - **Transport**: 5s connect timeout on both the plain and the mTLS channel, and no panic path in the named-pipe retry loop. Also corrects module docs that claimed Windows named-pipe support was a follow-up while the named-pipe client sits in the same file. - Dropped the redundant `tokio-stream` dev-dependency, since this layer promotes it to a regular dependency. - README records the build caveats: the dev VM's empty `PKG_CONFIG_LIBDIR` breaks `openssl-sys` under cargo, proto-touching changes must be Bazel-verified (under `--cfg=bazel` the bindings come from a separate crate, so the orphan rule differs), and the TLS tests are Linux-only. ### Stack PR 5 of 9. Based on #54590; followed by #54592.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54591",
        "createdAt": "2026-08-07T17:50:14Z",
        "updatedAt": "2026-08-13T18:00:24Z",
        "timestamp": "2026-08-13T18:00:24Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "long review",
          "team/agent-devx",
          "team/agent-build",
          "team/action-platform",
          "internal"
        ],
        "author": "embeaken",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54592",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[ACTP] add par-control OPMS client",
        "text": "### What does this PR do? Adds the authenticated OPMS client used by `par-control`: - Signs requests with runner JWT authentication. - Dequeues workflow tasks. - Publishes terminal task outcomes. - Sends task heartbeats. - Performs runner health checks. - Matches the existing Go wire contracts, proxy behavior, TLS settings, and retry pacing. The implementation and its HTTP/TLS contract tests are kept together in this layer. ### Motivation Separate the remote OPMS protocol from local executor communication and from the orchestration policy that composes them. ### Validation - 46 portable Rust tests pass locally. - Three native-tls tests require Linux/Windows and do not run successfully with the macOS Security Framework backend. ### Stack PR 6 of 9. Based on #54591; followed by #54593.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54592",
        "createdAt": "2026-08-07T17:51:46Z",
        "updatedAt": "2026-08-13T17:46:54Z",
        "timestamp": "2026-08-13T17:46:54Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "long review",
          "team/agent-devx",
          "team/agent-build",
          "team/action-platform",
          "internal"
        ],
        "author": "embeaken",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54593",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[ACTP] orchestrate par-control tasks",
        "text": "### What does this PR do? Composes the process manager, effective configuration, OPMS client, and executor channel into the production `par-control` loop: - Adds bounded task concurrency and retry policy. - Leaves the executor stopped while idle and starts it only after a task is dequeued. - Starts task heartbeats at dequeue and continues them through executor cold start, key synchronization, execution, and terminal publication. - Sends runner liveness reports independently of task flow. - Lazily synchronizes and caches signing keys for later executor starts. - Stops the executor after the configured idle period and drains in-flight work during shutdown. - Wires the final binary and updates its documentation. - Restores Windows compatibility for the Rust Bazel test by staging the Agent OpenSSL DLLs in runfiles and placing that directory on the test process's `PATH`. ### Motivation Keep orchestration policy separate from the independently tested lifecycle and network primitives it coordinates. In particular, the control process should preserve an OPMS lease while paying the executor's cold-start cost and should not keep the higher-RSS Go process alive when no work is available. ### Validation - `dda env dev run -- bazel test //pkg/privateactionrunner/par-control:par-control_test` - `dda env dev run -- env -u PKG_CONFIG_LIBDIR cargo clippy --manifest-path pkg/privateactionrunner/par-control/Cargo.toml --all-targets -- -D warnings` - Buildifier passes. - Windows-target Bazel analysis confirms both OpenSSL DLLs are inputs to the staging action. - Full Windows Rust execution is delegated to Windows CI. ### Review fixes - **No startup prewarming**: the executor remains stopped until a task is leased. Signing keys are synchronized during the first cold start and cached for later starts. - **Lease protection during cold start**: task heartbeats begin immediately after dequeue and stop only after terminal publication, covering process startup, readiness, and key synchronization. - **Start race**: dd-procmgrd rejects `Start` for every state covered by `ProcessState::is_alive()` (`Starting`, `Running`, and `Stopping`). Those states and a lost `Start` race are now adopted instead of failing the task spuriously. - **Windows graceful shutdown**: `par-control` listens for `CTRL_BREAK`, which is the event dd-procmgrd sends to Windows children, so shutdown drains work instead of waiting for the process-manager timeout and job-object kill. - **Bounded process-manager calls**: dispatch-path `Describe` and `Start` RPCs have deadlines, allowing a leased task to fail and publish an outcome instead of hanging without heartbeats. - **Windows logging and defaults**: restores the program-data-root log path, `ExitCode`, and the platform-correct `--config` default. - **Clean executor exits**: idle self-termination from #54670 remains non-fatal, so `restart: on-failure` does not immediately respawn the executor. - Tests cover stopped-at-start behavior, heartbeat timing through cold start and publication, adoption of `Starting`/`Running`/`Stopping`, tolerated start races, RPC deadlines, idle stop, drain behavior, and vanished process definitions. ### Stack PR 7 of 9. Based on #54592; followed by #54594.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54593",
        "createdAt": "2026-08-07T17:53:19Z",
        "updatedAt": "2026-08-13T17:49:05Z",
        "timestamp": "2026-08-13T17:49:05Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "long review",
          "team/agent-build",
          "team/action-platform",
          "internal"
        ],
        "author": "embeaken",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54594",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[ACTP] wire split runner ownership",
        "text": "### What does this PR do? Teaches the existing Go runner and Fx component to stand down when split mode is enabled on supported Linux and Windows host deployments, while retaining the executor subcommand used by `par-control`. Container deployments do not yet launch the replacement topology. Official Agent containers are detected through `configenv.IsContainerized()` (`DOCKER_DD_AGENT`), so a requested split deployment logs a warning and safely continues with the monolithic runner instead of black-holing PAR. Cluster Agent continues to use its existing in-process monolithic path. The resulting ownership invariant is explicit: exactly one process polls OPMS, and the monolith exits only when its replacement topology is available. ### Motivation Keep runner ownership and activation behavior separate from package and installer mechanics so reviewers can focus on preventing both duplicate polling and unsupported deployments standing down their only runner. ### Validation - `bazel test //comp/privateactionrunner/impl:impl_test` passes locally. - Focused coverage includes Linux and Windows hosts, Linux and Windows containers, and an unsupported host platform. - Private Action Runner build passes locally. ### Review fixes - Documented `idle_timeout_seconds`, which now drives two mechanisms: par-control stops an idle executor after this long, and the executor exits by itself after a longer multiple, which is what reclaims it when par-control is no longer running. - Documented that `procmgr_socket_path` falls back to the process manager's own `DD_PM_SOCKET_PATH` when unset. ### Stack PR 8 of 9. Based on #54593; followed by #54529.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54594",
        "createdAt": "2026-08-07T18:09:51Z",
        "updatedAt": "2026-08-13T18:00:51Z",
        "timestamp": "2026-08-13T18:00:51Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "medium review",
          "team/agent-build",
          "team/action-platform",
          "internal",
          "team/fleet-automation"
        ],
        "author": "embeaken",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54597",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[NDINT-652] [Agent] Accept CLI commands from payload sent via PAR",
        "text": "### What does this PR do? This PR adds a RunCommand action which, if enabled, allows a user to submit commands via PAR to be executed on a remote device. ### Motivation https://datadoghq.atlassian.net/browse/NDINT-652 ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54597",
        "createdAt": "2026-08-07T18:39:04Z",
        "updatedAt": "2026-08-13T17:57:15Z",
        "timestamp": "2026-08-13T17:57:15Z",
        "metrics": {
          "reactions": 0,
          "comments": 4
        },
        "labels": [
          "long review",
          "team/ndm-integrations",
          "team/agent-build",
          "team/action-platform",
          "internal"
        ],
        "author": "dplepage-dd",
        "state": "open",
        "assignees": [],
        "change": "new"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54601",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "dyninst/irgen: name the unsupported operation in condition errors",
        "text": "### What does this PR do? When a logpoint's condition uses an operation the Go debugger doesn't implement, the resulting error now names that operation. Also an unsupported operation can appear in two places, on its own or nested inside a comparison. Both now report the operation by name. ### Motivation A logpoint was created in staging against a Go service with a condition using `startsWith`, which Go does not implement. It never activated. The person debugging was told the target had passed validation but the service had not applied the logpoint. ### Describe how you validated your changes Added eight test probes covering every operation the shared expression language accepts but Go does not implement, in both positions an operation can occupy, and confirmed in the regenerated snapshots that each reports its own name. Ran the generator test suite and the eBPF integration test for the affected test program, to confirm the added failing probes don't disturb the probes that do attach.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54601",
        "createdAt": "2026-08-07T21:01:21Z",
        "updatedAt": "2026-08-12T21:44:25Z",
        "timestamp": "2026-08-12T21:44:25Z",
        "metrics": {
          "reactions": 2,
          "comments": 8
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "long review",
          "internal",
          "team/debugger"
        ],
        "author": "grantseltzer",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54603",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Add allowlist for valid conntrack_path values",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Validate `conntrack_path` configuration values are acceptable before initializing the network check to collect metrics from the tool. The allowed values are what we have seen configured for this feature. ### Motivation ### Describe how you validated your changes * unit tests ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54603",
        "createdAt": "2026-08-07T22:19:55Z",
        "updatedAt": "2026-08-12T20:37:02Z",
        "timestamp": "2026-08-12T20:37:02Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "long review",
          "team/agent-integrations",
          "team/agent-runtimes",
          "internal"
        ],
        "author": "jeremy-hanna",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54631",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[Backport main]  Changelog update for 7.82.1 release",
        "text": "Backport 13cef24437a2a0c3c3b8c202426c26ea1458c282 from #54627. ___",
        "url": "https://github.com/DataDog/datadog-agent/pull/54631",
        "createdAt": "2026-08-10T12:23:37Z",
        "updatedAt": "2026-08-12T15:46:07Z",
        "timestamp": "2026-08-12T15:46:07Z",
        "metrics": {
          "reactions": 2,
          "comments": 2
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "backport",
          "bot",
          "team/container-platform",
          "team/agent-delivery",
          "short review",
          "team/container-integrations",
          "internal"
        ],
        "author": "dd-octo-sts[bot]",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54633",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[AAD-39] Format logs in scorer events",
        "text": "### What does this PR do? > [!NOTE] > Context: https://github.com/DataDog/datadog-agent/pull/54572 For scorer events, we handled only metrics. This PR formats the metrics derived by logs such that we obtain log patterns instead of metric names. Example: ``` Top contributions: 1. 75% — log: ERROR: connection refused to db.prod:5432 — {service:api} 2. 25% — log: GET /checkout <*> returned 500 — {env:prod} ``` ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54633",
        "createdAt": "2026-08-10T12:28:52Z",
        "updatedAt": "2026-08-13T16:10:29Z",
        "timestamp": "2026-08-13T16:10:29Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "medium review",
          "internal"
        ],
        "author": "CelianR",
        "state": "open",
        "assignees": [
          "CelianR"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54634",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "optimize the complexity of the trace_contention_begin",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? This [commit](https://github.com/torvalds/linux/commit/e67ddd9b1cff7872d43ead73a1403c4e532003d9) landed in kernel v6.9 negatively effects the complexity of the `trace_contention_begin` bpf program. The verifier cannot effectively prune the state space of the binary search algorithm. In order to fix the load failures this PR moves the loop variables of the binary search into a percpu array map. Since the verifier cannot track the bounds of registers spilled to a map value, it can prune the state space more effectively. In order to make it reliable to use this scratch space the bpf program must now account for nested execution from different contexts. In order to handle this the PR introduce code to detect the execution context of the bpf program in the kernel and use that to select a slot to hold the loop variables. ### Motivation ### Describe how you validated your changes New tests cover the changes ### Additional Notes This PR is currently incomplete due to the lack of support for handling environments where kernel addresses from `/proc/kallsyms` are not readable such as when `kptr_restrict` is set and when `CAP_SYSLOG` is not available, in the cilium/ebpf loader. The loader automatically reads and caches addresses from /proc/kallsyms when `__ksyms` is used to mark global variables. I am working on upstreaming support for handling restricted environment to the cilium/ebpf loader.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54634",
        "createdAt": "2026-08-10T12:57:41Z",
        "updatedAt": "2026-08-13T16:34:01Z",
        "timestamp": "2026-08-13T16:34:01Z",
        "metrics": {
          "reactions": 1,
          "comments": 7
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "team/ebpf-platform",
          "qa/done",
          "long review",
          "ask-review",
          "team/agent-build",
          "internal"
        ],
        "author": "usamasaqib",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54645",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "fix: avoid data race in grpclog.SetLogger on otelcol collector start",
        "text": "### What does this PR do? Sets `SkipSettingGRPCLogger: true` on the `otelcol.CollectorSettings` for the otel-agent and host-profiler collectors, so `otelcol.(*Collector).Run` no longer calls the non-mutex-protected `grpclog.SetLogger` while other gRPC clients (e.g. remote-config/remote-tagger) are active in the same process. ### Motivation Fix a race, found via a race-detector-enabled build in staging. ### Describe how you validated your changes Ran `./comp/otelcol/...` and `./comp/host-profiler/collector/...` tests (including with `--race`) and built `otel-agent`/`host-profiler`, all passing; a real regression test isn't feasible since the race needs real concurrent gRPC/otelcol startup. ### Additional Notes No log routing is lost: `comp/core/tagger/impl-remote` (pulled in by both otel-agent and host-profiler) already sets a Datadog-logger-backed `grpclog` logger in its package `init()`, which runs once before `main()` and is therefore race-free. Skipping otelcol's later, racy `SetLogger` call just stops it from unsafely clobbering that existing assignment — grpc's internal logs keep flowing to our structured logger exactly as before. Similar to https://github.com/DataDog/datadog-agent/pull/15321 for the OTLP endpoint.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54645",
        "createdAt": "2026-08-10T13:59:56Z",
        "updatedAt": "2026-08-13T17:44:38Z",
        "timestamp": "2026-08-13T17:44:38Z",
        "metrics": {
          "reactions": 1,
          "comments": 8
        },
        "labels": [
          "changelog/no-changelog",
          "team/opentelemetry",
          "qa/done",
          "medium review",
          "team/profiling-full-host",
          "internal"
        ],
        "author": "pgimalac",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54652",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "feat(ndm): add Agent workload balancing",
        "text": "> **Note:** This PR was created by Claude. ### What does this PR do? Adds NDM Agent workload balancing: a device can be handed from one Agent to another without restarting either one. **The component** (`comp/workloadbalancing`) - `def/` — the `Component` interface and the `Active` / `Standby` / `Unmanaged` states - `impl/` — an `RWMutex`-guarded map of group ID to state, the `agent_workload_balancing.enabled` config read, and the Remote Config update callback - `fx/`, `mock/`, `helpers/` — the usual component scaffolding - `pkg/config/schema/yaml/core_schema.yaml` — the new `agent_workload_balancing.enabled` setting, default `false` **Remote Config** New `NDM_AGENT_WORKLOAD_BALANCING` product in `pkg/remoteconfig/state/products.go`. Each config names a group and the Agent that should actively poll it. The listener is registered only when the setting is enabled. **Where the group comes from** The SNMP instance setting `agent_workload_balancing_group` flows through `InstanceConfig` into `CheckConfig` and out via `Check#WorkloadBalancingGroupID()`, a new method on the `Check` interface that returns the empty string for everything else. It is deliberately left out of `DeviceDigest`, so moving a device between groups does not change its identity. **The gate** `pkg/collector/worker` skips a check only when workload balancing is enabled, the check names a group, and that group is not active on this Agent. **Wiring** `workloadbalancingfx.Module()` at 12 binary sites; the component is threaded into the collector and the check runner. ### Motivation First slice of the NDM Agent load balancing RFC. Today moving a device between Agents means editing config on both and restarting them, which leaves a monitoring gap. The design follows `comp/haagent` closely, with two deliberate differences: - **State is per group, not per Agent.** One Agent can be active for some groups and standby for others, so the component holds a map rather than a single value. - **It fails open.** HA treats an unknown state as a reason to suppress. Here a group we hold no assignment for is `Unmanaged` and runs, and only an explicit standby suppresses. Duplicate monitoring during a handoff is recoverable; a silent device is not. For the same reason an empty Remote Config update clears every group rather than suppressing everything, and a group that drops out of the set returns to unmanaged. ### Describe how you validated your changes - `go test -tags test ./comp/workloadbalancing/... ./pkg/collector/... ./comp/collector/...` — pass - `go build ./...` — clean - `dda inv linter.go` over the touched packages — clean apart from a pre-existing cgo typecheck failure in `pkg/collector/python`, which this PR does not touch - `bazel run //:gazelle` for the BUILD.bazel files - fx graph validation via `go test -tags test ./cmd/agent/subcommands/... ./cmd/dogstatsd/subcommands/... ./pkg/cli/subcommands/...` Unit tests cover: enabled/disabled config; the unmanaged-runs default; standby suppression; `RemoveGroup`; group independence; `GetGroupStates` returning a copy; Remote Config apply/error states for valid, malformed, and partially valid update sets; and the worker gate across active, standby, unmanaged, and disabled. No manual validation yet — the Remote Config product still needs backend registration before an end-to-end handoff can be exercised. ### Additional Notes Still draft. Remaining work, in its own PRs: the `datadog.agent.workload_balancing.running` metric, inventory metadata, and an e2e test (blocked on #53246 for Remote Config fakeintake support).",
        "url": "https://github.com/DataDog/datadog-agent/pull/54652",
        "createdAt": "2026-08-10T15:32:03Z",
        "updatedAt": "2026-08-13T14:02:24Z",
        "timestamp": "2026-08-13T14:02:24Z",
        "metrics": {
          "reactions": 0,
          "comments": 8
        },
        "labels": [
          "team/agent-apm",
          "team/remote-config",
          "qa/done",
          "team/container-platform",
          "long review",
          "team/agent-integrations",
          "team/agent-runtimes",
          "team/container-experiences",
          "team/agent-build",
          "internal",
          "team/network-device-monitoring-core",
          "team/fleet-automation"
        ],
        "author": "matthewleese",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54653",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[release] Update last stable to 7.82.1",
        "url": "https://github.com/DataDog/datadog-agent/pull/54653",
        "createdAt": "2026-08-10T15:43:20Z",
        "updatedAt": "2026-08-12T20:34:45Z",
        "timestamp": "2026-08-12T20:34:45Z",
        "metrics": {
          "reactions": 2,
          "comments": 6
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "team/agent-delivery",
          "short review",
          "team/agent-integrations",
          "team/agent-devx",
          "team/agent-build",
          "internal"
        ],
        "author": "temporal-github-worker-1[bot]",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54655",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Add test2json and UTOF output to bazel-driven go tests",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Generates test2json output and UTOF output for Bazel-run tests. ### Motivation We want to switch over to using Bazel for running our unit tests, this helps us produce output that is closer to the existing jobs to reduce friction during the switch. ### Describe how you validated your changes ### Additional Notes This generates a bit of noise on the UTOF output because it treats the multiple runs of the same tests (with different tag sets) as retries, which get printed out. This will be dealt with separately.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54655",
        "createdAt": "2026-08-10T16:12:30Z",
        "updatedAt": "2026-08-13T10:59:47Z",
        "timestamp": "2026-08-13T10:59:47Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "medium review",
          "ask-review",
          "team/agent-build",
          "internal"
        ],
        "author": "alopezz",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54656",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "feat(ndm): emit a metric per workload balancing group",
        "text": "> **Note:** This PR was created by Claude. Stacked on #54652 — review that one first. ### What does this PR do? Emits `datadog.agent.workload_balancing.running` once per NDM workload balancing group the Agent knows about, tagged with: - `workload_balancing_group:<id>` - `workload_balancing_state:active|standby|unmanaged` It follows the shape of the existing `datadog.agent.ha_agent.running` metric and is emitted from the same place, `BufferedAggregator.appendDefaultSeries`. Nothing is emitted when workload balancing is disabled, which is the default. The `workloadbalancing` component is threaded into the aggregator through the demultiplexer, which is most of the diff. ### Motivation The interesting signal is the gap, not the value. Each group should be reported as `active` by exactly one Agent. If the assigned Agent goes away and the reassignment does not land, the group stops being reported as active anywhere, and that absence is visible in a way that a silently unpolled device is not. ### Describe how you validated your changes - `go test -tags test ./pkg/aggregator/... ./comp/aggregator/...` — pass, including two new tests covering the tags and states emitted per group and that a disabled component emits nothing - `go vet -tags test ./...` — clean across the module - `dda inv linter.go --targets=./pkg/aggregator,./comp/aggregator/demultiplexer/impl` — 0 issues - `bazel run //:gazelle` for the BUILD.bazel files No manual validation: the Remote Config product that populates the group states still needs backend registration.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54656",
        "createdAt": "2026-08-10T16:25:18Z",
        "updatedAt": "2026-08-13T18:00:57Z",
        "timestamp": "2026-08-13T18:00:57Z",
        "metrics": {
          "reactions": 0,
          "comments": 9
        },
        "labels": [
          "qa/done",
          "long review",
          "team/agent-integrations",
          "team/agent-metric-pipelines",
          "internal",
          "team/network-device-monitoring-core",
          "team/fleet-automation"
        ],
        "author": "matthewleese",
        "state": "closed",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54658",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Add BUILD file for pkg/network/protocols/http/gotls/lookup/internal",
        "text": "### What does this PR do? Add BUILD file for pkg/network/protocols/http/gotls/lookup/internal. Remove the `go:build nobuild` tag preventing this from being seen by gazelle. ### Motivation Cleaning up. ### Describe how you validated your changes ``` bazel build //pkg/network/protocols/http/gotls/lookup/internal:generate_luts ```",
        "url": "https://github.com/DataDog/datadog-agent/pull/54658",
        "createdAt": "2026-08-10T16:31:57Z",
        "updatedAt": "2026-08-12T17:40:12Z",
        "timestamp": "2026-08-12T17:40:12Z",
        "metrics": {
          "reactions": 1,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "qa/no-code-change",
          "medium review",
          "ask-review",
          "team/agent-build",
          "internal"
        ],
        "author": "aiuto",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54659",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "feat(ndm): report workload balancing group state as inventory metadata",
        "text": "> **Note:** This PR was created by Claude. Stacked on #54652 — review that one first. ### What does this PR do? Adds a `comp/metadata/workloadbalancing` component, mirroring the existing `comp/metadata/haagent`. When Agent workload balancing is enabled it reports a `workload_balancing_metadata` inventory payload: ```json { \"hostname\": \"...\", \"workload_balancing_metadata\": { \"enabled\": true, \"groups\": {\"group-a\": \"active\", \"group-b\": \"standby\"} }, \"timestamp\": 1716985696922603000 } ``` It surfaces in three places: the inventory product, `agent status` (text and HTML), and the `/metadata/workload-balancing` endpoint. The flare picks it up as `workload-balancing.json`. Nothing is reported when workload balancing is disabled, which is the default. Unlike HA Agent, which has a single Agent-wide state, this Agent can hold a different state per group, so the payload carries a map rather than one string. ### Motivation `datadog.agent.workload_balancing.running` says a group is being run somewhere. It does not say which Agent holds it, or what the Agent itself thinks it holds. When a handoff does not land, the first question is which Agent believes it is active, and the inventory and status page are where that gets answered without shelling into a pod. ### Describe how you validated your changes - `go test -tags test ./comp/metadata/... ./cmd/agent/subcommands/run/... ./cmd/agent/subcommands/flare/...` — pass, including new tests for the payload, the copy semantics of the group map, the disabled case, and the status text/HTML renderers - `go build ./...` and `go vet -tags test ./comp/metadata/... ./cmd/agent/...` — clean - `dda inv linter.go --targets=./comp/metadata/workloadbalancing` — 0 issues - `dda inv components.lint-components --fix` and `bazel run //:gazelle` for the generated files No manual validation: the Remote Config product that populates the group states still needs backend registration.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54659",
        "createdAt": "2026-08-10T16:47:55Z",
        "updatedAt": "2026-08-13T18:00:57Z",
        "timestamp": "2026-08-13T18:00:57Z",
        "metrics": {
          "reactions": 0,
          "comments": 6
        },
        "labels": [
          "qa/done",
          "team/agent-runtimes",
          "team/fleet-remediation",
          "team/fleet-automation"
        ],
        "author": "matthewleese",
        "state": "closed",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54660",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "feat(autodiscovery): tag configuration-discovery instances to mitigate duplicate metrics risk",
        "text": "### What does this PR do? Adds a `dd_config_discovery:true` tag to every check instance scheduled via the Autodiscovery configuration-discovery mechanism (i.e. any `auto_conf.yaml` template with `discovery: {}`, resolved through `comp/core/autodiscovery/impl/configmgr_discovery.go`'s `applyDiscoveredConfigsLocked`). The tag used is `dd_config_discovery:true`, a plain `dd_`-prefixed key, following the precedent of other agent-added, customer-visible marker/provenance tags already in the codebase: - `dd_remote_config_id` / `dd_remote_config_rev` (`comp/core/tagger/tags/tags.go`) - `dd_enable_check_intake` (`pkg/collector/worker/worker.go`) ### Motivation [DSCVR-651](https://datadoghq.atlassian.net/browse/DSCVR-651): there is a risk that an agent on host A is monitoring a service on host B with a manually-configured check (e.g. a generic `openmetrics` check), while the agent running locally on host B also autodiscovers and schedules a dedicated integration for the same service via configuration discovery. Neither agent's local anti-duplication logic can see the other's config, so both submit metrics for the same underlying data. This tag doesn't prevent the duplication, but lets users identify and, if needed, exclude the autodiscovered side of it (e.g. `metric{!dd_config_discovery:true}`), both for the cross-host case above and for any single-host case the automatic suppression doesn't catch. ### Describe how you validated your changes Unit and E2E tests. --- 🤖 This PR description and implementation were generated with assistance from [Claude Code](https://claude.com/claude-code). [DSCVR-651]: https://datadoghq.atlassian.net/browse/DSCVR-651?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
        "url": "https://github.com/DataDog/datadog-agent/pull/54660",
        "createdAt": "2026-08-10T16:56:47Z",
        "updatedAt": "2026-08-13T14:24:27Z",
        "timestamp": "2026-08-13T14:24:27Z",
        "metrics": {
          "reactions": 3,
          "comments": 8
        },
        "labels": [
          "qa/done",
          "team/container-platform",
          "medium review",
          "team/agent-discovery",
          "team/agent-build",
          "internal",
          "backport/7.83.x"
        ],
        "author": "vitkyrka",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54662",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "add BUILD file for pkg/network/usm/debugger/cmd",
        "text": "### What does this PR do? - Add BUILD file for pkg/network/usm/debugger/cmd - Remove the go tags ### Motivation Cleanup and doing the last .1% of the migration. ### Describe how you validated your changes ``` # bazel run //pkg/network/usm/debugger/cmd:usm_debugger ... INFO: Build completed successfully, 1 total action INFO: Running command line: /root/.cache/bazel/_bazel_root/81a15fa9a2846e82038a778136785275/execroot/_main/bazel-out/aarch64-fastbuild-ST-9207cf685fa6/bin/pkg/network/usm/debugger/cmd/usm_debugger_/usm_debugger 2026-08-10 17:08:14 UTC | usm-debugger | DEBUG | (pkg/network/usm/debugger/cmd/ebpf_bytecode.go:52 in setupBytecode) | writing ebpf bytecode to /tmp/co-re/usm-debug.o 2026-08-10 17:08:14 UTC | usm-debugger | DEBUG | (pkg/network/usm/debugger/cmd/ebpf_bytecode.go:52 in setupBytecode) | writing ebpf bytecode to /tmp/co-re/shared-libraries-debug.o ... ``` ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54662",
        "createdAt": "2026-08-10T17:13:52Z",
        "updatedAt": "2026-08-12T20:30:49Z",
        "timestamp": "2026-08-12T20:30:49Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "qa/no-code-change",
          "medium review",
          "ask-review",
          "team/agent-build",
          "internal"
        ],
        "author": "aiuto",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54664",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[Backport 7.82.x]  feat(eudm): auto-enable logon_duration in end_user_device mode",
        "text": "Backport 1dbeb46efe19c82cc0f1f1064ea146467ea92be9 from #54434. ___ ### What does this PR do? Automatically enables the `logon_duration` feature when the Agent is in end-user-device mode (`infrastructure_mode: end_user_device`), so operators no longer have to set `logon_duration.enabled: true` separately. Two changes: 1. **`pkg/config/setup/config.go`** — `applyInfrastructureModeOverrides` now force-enables `logon_duration.enabled` (with `SourceInfraMode`) in the `end_user_device` branch, alongside the existing `process_collection`, `software_inventory`, and `notable_events` overrides. Because `SourceInfraMode` sits below explicit user config, a user who sets `logon_duration.enabled: false` still wins. 2. **`pkg/system-probe/config/config.go`** — the macOS `logon_duration` system-probe module gate now reads the flag from the **core** config (`datadog.yaml`) instead of the **system-probe** config (`system-probe.yaml`). Without this, the EUD override (which is applied to the core config) would enable the agent-side component but never start the system-probe module that actually collects the data on macOS. This mirrors how `software_inventory` is gated. ### Motivation WINA-3004 — reduce configuration friction for end-user-device deployments; `logon_duration` should be on by default in that mode. ### Describe how you validated your changes - Unit tests added in `pkg/config/setup/config_test.go`: EUD auto-enables `logon_duration.enabled`; non-EUD modes leave it at the default (`false`); an explicit user `false` overrides the EUD default. - `dda inv test --targets=./pkg/config/setup` and `--targets=./pkg/system-probe/config` both pass. ### Additional Notes - **Behavior change on macOS:** setting `logon_duration.enabled` only in `system-probe.yaml` no longer starts the module — the value must come from `datadog.yaml` (or `DD_LOGON_DURATION_ENABLED`). This matches `software_inventory`.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54664",
        "createdAt": "2026-08-10T17:48:21Z",
        "updatedAt": "2026-08-13T16:12:15Z",
        "timestamp": "2026-08-13T16:12:15Z",
        "metrics": {
          "reactions": 0,
          "comments": 3
        },
        "labels": [
          "team/ebpf-platform",
          "qa/done",
          "backport",
          "bot",
          "medium review",
          "team/agent-configuration",
          "internal",
          "team/fleet-automation"
        ],
        "author": "dd-octo-sts[bot]",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54665",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Add BUILD file for tools/retry_file_dump",
        "text": "### What does this PR do? Add BUILD file for tools/retry_file_dump ### Motivation Everything should be buildable with bazel. ### Describe how you validated your changes build and run ``` bazel run //tools/retry_file_dump:retry_file_dump ... INFO: Build completed successfully, 3 total actions INFO: Running command line: /root/.cache/bazel/_bazel_root/81a15fa9a2846e82038a778136785275/execroot/_main/bazel-out/aarch64-fastbuild/bin/tools/retry_file_dump/retry_file_dump_/retry_file_dump Invalid folder: Usage `./retry_file_dump --folder=/opt/datadog-agent/run/transactions_to_retry/c47da40ac935c8fd5ca1441a5ee3d068/` ```",
        "url": "https://github.com/DataDog/datadog-agent/pull/54665",
        "createdAt": "2026-08-10T18:15:00Z",
        "updatedAt": "2026-08-12T17:31:57Z",
        "timestamp": "2026-08-12T17:31:57Z",
        "metrics": {
          "reactions": 0,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "medium review",
          "ask-review",
          "team/agent-metric-pipelines",
          "team/agent-build",
          "internal"
        ],
        "author": "aiuto",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54667",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "tagger: refuse reserved tag names from workload-controlled metadata",
        "text": "### What does this PR do? Adds a `workload_tags_denylist` setting (default `[\"host\", \"pod_name\"]`) listing tag names the tagger refuses to build out of workload-controlled metadata. It is resolved once into a set held by the `TagList` for O(1) lookups, and honored by the new `AddLow/AddHigh/AddAutoFromWorkload` methods, which are used on the paths where the workload names the tag: - the `ad.datadoghq.com/tags` and `ad.datadoghq.com/<container>.tags` pod annotations (`parseJSONValue`) - the `com.datadoghq.ad.tags` container label - tracer process tags on process entities - pod labels/annotations and container labels/env vars mapped to a tag name via a `%%label%%`/`%%annotation%%`/`%%env%%` template (`AddWorkloadMetadataAsTags`) Matching is case-insensitive, ignores the `+` high-cardinality prefix, and cuts at the first `:` — otherwise `{\"host:attacker\": \"1\"}` would serialize to `host:attacker:1` and still be read as the `host` tag downstream. Deliberately **not** filtered, since the tag name there is not the workload's to choose: the tags the Agent computes itself, node/namespace/deployment metadata (`AddMetadataAsTags` is unchanged, so node labels as host tags keep working), and tag names an administrator hardcoded in a `*_labels_as_tags` mapping. ### Motivation VULN-92370 / CONTP-108: a tenant with `edit` on its own namespace could inject reserved infrastructure tags on its own workload and have the DCA ship them, poisoning cross-tenant tag attribution, monitor scoping and billing-by-tag. Confirmed as real — reproduced in a unit test that asserts the forged tags land on the entity when the denylist is empty. ### Describe how you validated your changes `go test -tags test ./comp/core/tagger/...` — all green. New coverage: - `taglist`: default denylist, custom/empty denylist, `+` prefix, casing, `:` in the tag name, `Copy` keeping the set, and that the Agent's own `AddLow`/`AddOrchestrator` are unaffected - `k8s_metadata`: template-named tag denied, admin-hardcoded name kept, admin-controlled `AddMetadataAsTags` unfiltered - `collectors`: end-to-end pod with a forged `ad.datadoghq.com/tags`, both with the default denylist (dropped) and with it disabled (the pre-fix behavior, i.e. the repro) Also ran the schema linter and `go vet` on the changed packages. ### Additional Notes - One behavior change to flag: `{\"pod_name\":\"%%kube_pod_name%%\"}` in `ad.datadoghq.com/tags` — the documented way to get `pod_name` at low cardinality — now drops that tag. Covered in the upgrade release note; admins can remove `pod_name` from the list. - The setting name is easy to change if you'd prefer something else. - Follow-up worth its own PR: in `labelsToTags`, `extractFromMapNormalizedWithFn(labels, containerLabelsAsTags, tags.AddAuto)` re-processes container labels a second time without resolving templates, emitting a literal `%%label%%:<value>` tag. Pre-existing and unrelated to this fix, so left alone. - Coordinate with CONTP-1959, which extends the same annotation path.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54667",
        "createdAt": "2026-08-10T18:25:59Z",
        "updatedAt": "2026-08-12T14:04:29Z",
        "timestamp": "2026-08-12T14:04:29Z",
        "metrics": {
          "reactions": 1,
          "comments": 10
        },
        "labels": [
          "team/container-platform",
          "medium review",
          "team/container-integrations",
          "team/agent-build",
          "internal",
          "team/fleet-automation"
        ],
        "author": "gabedos",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54670",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[ACTP] [PAR split deployment] shut down idle private action executor",
        "text": "### What does this PR do? Makes the new on-demand PAR executor terminate after an idle period. This should be triggered by `par-control` via `dd-procmgrd` so this is really a fallback for the daemon not working properly. Idle period is configured via `private_action_runner.idle_timeout_seconds` with a 60-second default. We use 3x that value as a backstop behind the control plane's normal explicit stop. This behavior is currently dormant in supported deployments: executor mode exists, but no deployment launches `privateactionrunner run-executor` until the later process-manager and packaging layers activate it. ### Motivation `par-control` and the PAR executor are siblings managed by `dd-procmgrd`. The control plane normally stops an idle executor, but if it crashes, exhausts its restart limit, or is stopped independently, nothing else reclaims the executor. The executor must therefore own a self-termination backstop. ### Describe how you validated your changes On the Linux development VM: - `bazel test //pkg/privateactionrunner/executor:executor_test` - `bazel test //comp/privateactionrunner/impl:impl_test` - `bazel test //cmd/privateactionrunner/subcommands/runexecutor:runexecutor_test` The executor test target also passed 10 consecutive runs after the idle tests were converted to use a mock clock. ### Additional Notes The watchdog is configured only by executor mode, so the existing monolithic runner is unchanged. A user could invoke `run-executor` manually, but no supported host, Docker, or Kubernetes deployment currently does so.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54670",
        "createdAt": "2026-08-10T18:41:18Z",
        "updatedAt": "2026-08-13T16:02:34Z",
        "timestamp": "2026-08-13T16:02:34Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "medium review",
          "team/agent-build",
          "team/action-platform",
          "internal",
          "team/fleet-automation"
        ],
        "author": "embeaken",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54675",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "add skeletal authored script action",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds skeletal implemenation for authored script actions. This is not available to users as the action is behind a feature flag. [This PR](https://github.com/ddoghq/dd-source/pull/48812) ### Motivation We will be supporting authored scripts where new scripts can be added without needing a new agent release. This is to add a skeletal handler to support it. Further details in [Datadog Authored Script](https://docs.google.com/document/d/1qB2R__ZUkL2xjCDLybJGoaKl5EhpJ-rpy907h0qlRm4/edit?tab=t.0#heading=h.qjl27megtr2p) and [Authored script download and storage RFC](https://datadoghq.atlassian.net/wiki/spaces/ACT/pages/7060063493/RFC+Authored+script+download+storage+and+isolation) ### Describe how you validated your changes Ran an authorized script action from a local agent. Screenshot attached <img width=\"1353\" height=\"771\" alt=\"Screenshot 2026-08-13 at 12 46 44 PM\" src=\"https://github.com/user-attachments/assets/5d729838-3aa4-4f8e-a7d0-ac6057dba557\" /> ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54675",
        "createdAt": "2026-08-10T19:53:19Z",
        "updatedAt": "2026-08-13T16:50:30Z",
        "timestamp": "2026-08-13T16:50:30Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "medium review",
          "team/agent-build",
          "team/action-platform",
          "internal"
        ],
        "author": "Madhu-TV",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54676",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[procmgr] Extract shared Rust client",
        "text": "### What does this PR do? Extracts a `dd-procmgr-client` Rust crate from client code in `dd-procmgrd`: - process-manager protobuf/gRPC bindings; - default endpoint and `DD_PM_SOCKET_PATH` handling; - Unix socket and Windows named-pipe connections; - Windows busy-pipe retry behavior. The `dd-procmgr` CLI now uses this crate. The daemon reuses its bindings and endpoint resolution, but keeps all server transport, process supervision, and lifecycle code. This is a code move and dependency cleanup. It does not change the protocol, endpoint defaults, retry policy, or process-manager behavior. ### Why? A later PR in the Private Action Runner split-mode stack (#54589) adds a second Rust client of `dd-procmgrd`. Without this crate, that client would either depend on the full daemon implementation or copy its platform-specific connection code. ### Validation ```text dda env dev run -- bazel test //pkg/procmgr/rust/... dda env dev run -- cargo clippy --manifest-path pkg/procmgr/rust/client/Cargo.toml --all-targets -- -D warnings dda env dev run -- cargo clippy --manifest-path pkg/procmgr/rust/Cargo.toml --all-targets --features test-helpers -- -D warnings ``` The Bazel suite covers the client, daemon, CLI, and CLI/daemon E2E tests.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54676",
        "createdAt": "2026-08-10T20:37:41Z",
        "updatedAt": "2026-08-13T15:58:22Z",
        "timestamp": "2026-08-13T15:58:22Z",
        "metrics": {
          "reactions": 2,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "long review",
          "team/agent-runtimes",
          "team/agent-devx",
          "team/agent-build",
          "team/windows-products",
          "internal"
        ],
        "author": "embeaken",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54680",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "AGNTLOG-706 Increase logging for fingerprinting tailing",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? A file that matches a log config but gets no tailer because its fingerprint is unusable used to be dropped silently, with no log line at any level. The only clue was an unexplained shortfall in `N files tailed out of M files matching`. This reports the gap when it opens, while it lasts, and when it closes. #### What an operator sees Setup: `byte_checksum` fingerprinting with `count` left at its default of 1024 bytes, a source matching `/var/log/app/*.log`, and `app.log` just rotated away to a 412-byte replacement. Scans run every second. ``` t=1s WARN Unable to tail /var/log/app/app.log. 412 bytes is too short for fingerprinting (needs 1024 bytes). Logs are not collected until the file grows. t=2..29s (silent: the warning is latched, so a file that stays short cannot fill the log. Every scan still shows the arithmetic at debug level.) t=30s INFO Now tailing /var/log/app/app.log, 30s after it was first skipped for an unusable fingerprint (insufficient_data). ``` While the gap is open, `agent status` carries it under the source whose pattern matched the file: ``` - Type: file Path: /var/log/app/*.log Status: OK 2 files tailed out of 3 files matching Not tailing /var/log/app/app.log: too short to fingerprint (needs 1024 bytes). Lower logs_config.fingerprint_config.count if this persists ``` The `2 files tailed out of 3` line already existed and was the whole of what an operator had to go on. The `Not tailing` line is new: which file, why, and the setting that governs it. It names `this source's fingerprint_config.count` instead when the source carries its own `fingerprint_config`, and names no setting at all when the threshold came from an internal fallback, so the suggestion always points at something that would change the outcome. Recovery is a delay in collection rather than a hole in it: these tailers start at the beginning of the file, so the 412 bytes written while it waited are read and sent once tailing starts. What the file held is only lost if it is destroyed before a tailer ever reaches it. Three variations on the ending: - **The file goes away while still short** — deleted, or `count` set too high. The closing line is a WARN rather than an INFO, so the gap is bounded either way: `Stopped tracking /var/log/app/app.log, never tailed for 45s because of an unusable fingerprint (insufficient_data). Logs written during that gap were not collected.` - **The Agent stops with skips outstanding** — one line: `Stopping with 1 file(s) still not tailed because their fingerprint was unusable.` - **The fingerprint fails to compute** rather than coming up short, a permissions error say. The warning and the status message report that instead of blaming the file's size. A file alternating between the two reasons warns once per reason, keeping its original start time, so one gap is still reported as one gap. ### Motivation The usual cause is benign and self-healing — a rotation leaving the file below `logs_config.fingerprint_config.count` — but collection stalls while it lasts, and a `count` set too high makes that permanent. Customers cannot query the Agent's telemetry, so this has to reach them through the log and `agent status`. ### Describe how you validated your changes `dda inv test --targets=./pkg/logs/launchers/file/...` — 110 tests pass. New tests cover the warn-once latching (including a file alternating between reasons), both closing outcomes and their durations, the status message and its removal, the message following a source that gets replaced, and two ways a skip could be wrongly reported as given up on: a scan already in flight when the source was added, and one that hit `open_files_limit` and so may have left out files that are still matched. `dda inv test --targets=./pkg/logs/launchers/file/provider/...` — 45 tests pass. The new one asserts that a wildcard matching no files is reported in both selection modes, which is the parity the provider fix restores: revert those six lines and only the `by_modification_time` case fails. Also verified `gofmt` and `bazel test //bazel/buildifier:test`. No E2E test covers this. ### Additional Notes - Inert by default: `logs_config.fingerprint_config.fingerprint_strategy` defaults to `disabled`. - Drive-by fix in the file provider: under `file_wildcard_selection_mode: by_modification_time`, a wildcard source that resolves to no files now reports the error, as it already does under the default `by_name` mode. That mode resolves wildcards in a pass of its own, separate from the one every other source goes through, which is how it came to drop them. Not in the release note.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54680",
        "createdAt": "2026-08-10T21:13:57Z",
        "updatedAt": "2026-08-12T19:00:06Z",
        "timestamp": "2026-08-12T19:00:06Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "qa/done",
          "long review",
          "ask-review",
          "team/agent-log-pipelines",
          "team/agent-build",
          "internal"
        ],
        "author": "DDuongNguyen",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54682",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[Backport 7.83.x]  pkg/dyninst: Fix procscan backoff",
        "text": "Backport 623b04cb6c31624398ed401ef0a17fdf6282910c from #54400. ___ ### What does this PR do? Changes how the live debugger finds processes to instrument. It used to look at each process exactly three times, when the process turned 3, 100 and 1000 seconds old. If the tracer inside that process had not announced itself by the third look, that process was never instrumented again for as long as it ran. Now every process is checked repeatedly, with a growing gap between checks, until it is either instrumented or gone. A slow start is a delay of seconds instead of a permanent miss. Two supporting changes come with it. Processes that are not Go programs are identified with a cheap check and set aside, so that looking at everything repeatedly stays affordable. And scans now run on a plain five second timer, where the old one stretched itself in proportion to how long the previous scan took, with no upper limit. Includes benchmarks for the cost of a scan. ### Motivation This came out of an investigation into a service that took roughly half an hour to upload its debugging symbols. Symbols are only uploaded once a service is being instrumented, so a discovery failure surfaces as an unexplained delay somewhere else entirely, which is what made it hard to track down. The tracer announces itself at the very end of its own startup, behind a network call that can hang for ten seconds. The first look happened a few seconds after the process started, so the tracer could not win that race, and the design gave it only two more chances ever. The same investigation turned up a second problem: because the timer grew with scan duration and had no ceiling, a single slow scan could push the next one out far enough to swallow two of the three chances a process ever got. ### Describe how you validated your changes Extended the existing table-driven scanner tests to cover the retry schedule, a tracer that only announces itself after many attempts, agent restart, process ID reuse, permission failures, processes that are not Go programs, and the fixed timer. Added benchmarks, since the new loop looks at every process every time. On a host with two thousand processes, an ordinary scan costs about 0.44% of one core, and the first scan after a restart costs about 2% of a core for that one scan. ### Additional Notes A process that starts as a shell script and later replaces itself with the real service keeps the same process ID, so if we happen to look at it while it is still the script, we write it off along with the service it becomes if it's not Go. Container enrypoints happen on proc start so this is not an issue except the case of a proc running as a script that does set up and does an exec. I don't think that really matters for support.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54682",
        "createdAt": "2026-08-10T21:28:31Z",
        "updatedAt": "2026-08-12T19:21:56Z",
        "timestamp": "2026-08-12T19:21:56Z",
        "metrics": {
          "reactions": 1,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "team/ebpf-platform",
          "qa/done",
          "backport",
          "bot",
          "long review",
          "team/agent-build",
          "internal",
          "team/debugger"
        ],
        "author": "dd-octo-sts[bot]",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54683",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "fix(e2e): retry ensure-adws-started on transient SSH/script failures",
        "text": "### What does this PR do? Adds an onError resource hook that retries the ensure-adws-started command when sshd dies mid-command or the command's own PowerShell errors out, without retrying dial-exhaustion failures or the whole stack up. ### Motivation ensure-adws-started fails flakily shortly after domain-controller promotion (WINA-2095) due to transient SSH/script issues that a retry fixes. Requires the CI Pulumi CLI/engine to be bumped to >= v3.219.0 for onError hook support (tracked separately). ### Describe how you validated your changes Windows e2e tests should pass.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54683",
        "createdAt": "2026-08-10T21:29:03Z",
        "updatedAt": "2026-08-13T05:11:09Z",
        "timestamp": "2026-08-13T05:11:09Z",
        "metrics": {
          "reactions": 1,
          "comments": 3
        },
        "labels": [
          "medium review",
          "team/agent-devx",
          "team/windows-products",
          "internal"
        ],
        "author": "clarkb7",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54691",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "fix(cws): register connected sockets in the `flow_pid` map",
        "text": "### What does this PR do? Registers the flow of a connecting IPv6 socket once `connect` returns. ### Motivation `tcp_v6_connect` classifies the flow before the ephemeral source port and the source address are picked, so until Linux 7.0 the socket was classified on its first transmit, once both were known. Linux 7.0 only routes on a dst cache miss in `inet6_csk_xmit`, and a connecting socket always ends up holding a route, so that second classification never happens and those flows are left unattributed. ### Describe how you validated your changes Existing functional tests running on Ubuntu 26.04 that this PR fixes. ### Additional Notes IPv4 flows are unaffected as these are still registered as part of the `security_sk_classify_flow` hook.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54691",
        "createdAt": "2026-08-10T22:39:08Z",
        "updatedAt": "2026-08-12T19:32:30Z",
        "timestamp": "2026-08-12T19:32:30Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "team/agent-security",
          "category/bugfix",
          "qa/done",
          "medium review",
          "internal"
        ],
        "author": "YoannGh",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54696",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[automated] Upgrade embedded Python patch version to 3.13.15",
        "text": "### What does this PR do? Upgrades the Agent's embedded Python interpreter from **3.13.14** to **3.13.15** (patch version update). ### Changes - Updated `omnibus/config/software/python3.rb` with new version and SHA256 - Updated `deps/cpython/cpython.MODULE.bazel` with new version and SHA256 - Updated `test/new-e2e/tests/agent-platform/common/agent_behaviour.go` with expected version - Created release note documenting the upgrade ### Motivation Keep embedded Python up-to-date with bug fixes and security patches. ### Verification SHA256 hash automatically fetched and verified against the official Python.org SBOM file. See the [official Python release page](https://www.python.org/downloads/release/python-31315/) for details. ### Describe how you validated your changes CI is considered enough to validate changes.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54696",
        "createdAt": "2026-08-11T04:30:20Z",
        "updatedAt": "2026-08-13T09:58:09Z",
        "timestamp": "2026-08-13T09:58:09Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "medium review",
          "team/agent-integrations",
          "ask-review",
          "team/agent-runtimes",
          "team/agent-devx",
          "team/agent-build",
          "internal"
        ],
        "author": "dd-octo-sts[bot]",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54702",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "fix(agent-integrations): bump AIX embedded Python version in patch upgrade task",
        "text": "### What does this PR do? Adds a new `_prepare_aix_update` step to `tasks/python_version.py` so the `python-version.update` task also bumps `PYTHON_VERSION` in `packaging/aix/lib/env.sh`. Also updates the `upgrade-python-patch-version` workflow's PR description to mention this file, and adds a unit test covering the new function. ### Motivation PR #54696 (the automated Python patch bump) only updated the Omnibus and Bazel Python references. As flagged in [review feedback](https://github.com/DataDog/datadog-agent/pull/54696#discussion_r3755248597), the AIX packaging path (`packaging/aix/lib/env.sh`, sourced by `packaging/aix/stages/02-python.sh`) has its own `PYTHON_VERSION` variable that was left out of sync, so AIX Agent builds continued embedding the old patch version. ### Describe how you validated your changes Ran the existing unit test suite plus the new `TestAixUpdate` test via `dda inv invoke-unit-tests.run --tests python_version` — all 17 tests pass.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54702",
        "createdAt": "2026-08-11T07:02:48Z",
        "updatedAt": "2026-08-12T17:01:24Z",
        "timestamp": "2026-08-12T17:01:24Z",
        "metrics": {
          "reactions": 2,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "short review",
          "team/agent-integrations",
          "team/agent-devx",
          "internal"
        ],
        "author": "chouetz",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54710",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[Backport 7.83.x]  [autoscaling] Filter Preview DPAs from pod patcher",
        "text": "Backport bb50da7066b760291cd2c0dbcd51f8d7162025d4 from #54697. ___ ### What does this PR do? Updates findAutoscaler in pod_patcher.go to filter out DatadogPodAutoscaler resources whose ApplyPolicy.Mode is set to Preview. Only autoscalers in `Apply` mode (or with no ApplyPolicy set) are considered when patching pods. ### Motivation It is valid to have multiple DPAs targeting the same workload - for example, one in Preview mode for observing recommendations and one in Apply mode for actually applying them. Previously, the pod patcher would find both and error out with \"Multiple autoscaler found\", preventing any patching from occurring. This fix allows Preview DPAs to coexist with an Apply DPA on the same target. ### Describe how you validated your changes Tested locally with a kind cluster running two DPAs targeting the same deployment.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54710",
        "createdAt": "2026-08-11T10:37:31Z",
        "updatedAt": "2026-08-12T18:51:10Z",
        "timestamp": "2026-08-12T18:51:10Z",
        "metrics": {
          "reactions": 1,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "component/cluster-agent",
          "qa/done",
          "backport",
          "bot",
          "component/autoscaling",
          "short review",
          "team/container-autoscaling",
          "internal"
        ],
        "author": "dd-octo-sts[bot]",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54713",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[SBOM] Derive image inUse from workloadmeta",
        "text": "### What does this PR do? The SBOM check computed inUse from imageUsers, a map of image identifier to running container IDs that it maintained from workloadmeta container events. The map was keyed by the Image.ID of the merged container entity, and that field changes shape over a container's lifetime. On Kubernetes the containerd collector reports the image config digest and the kubelet reports the repo digest, and workloadmeta merges its sources in alphabetical order, so the kubelet value wins as soon as it appears. A container starting on a containerd node is therefore registered first under the config digest, a moment later under the repo digest once the kubelet describes it too, and removed only from the second. The config digest entry stayed behind, and that is exactly the key the img.ID fallback looks up, so the image reported inUse=true until the Agent restarted. Nothing reconciled the map, so a dropped event bundle left the same residue. Ask workloadmeta which images have a running container instead. The store is already up to date when an event bundle is handed to the check, and the question is the one the container check behind Live Containers asks, so the two agree by construction and no cache can drift from either. What is left of the old map is the set of images reported in use by the previous bundle, used only to decide when to push an update, so a stale entry can now delay an emission but never produce a wrong inUse. This drops the event ordering and the stopped container cleanup added in #48586, which the store makes unnecessary. Matching a container against the image entity ID, from the same change, stays: it is how a container on containerd names its image. When an image and the container that just started it are described by the same event bundle, they no longer produce an SBOM each. The first of the two used to carry inUse=false, because the container had not been registered yet, and the second corrected it.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54713",
        "createdAt": "2026-08-11T12:21:46Z",
        "updatedAt": "2026-08-12T17:00:10Z",
        "timestamp": "2026-08-12T17:00:10Z",
        "metrics": {
          "reactions": 0,
          "comments": 7
        },
        "labels": [
          "team/agent-security",
          "qa/done",
          "medium review",
          "team/container-integrations",
          "internal"
        ],
        "author": "0intro",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54715",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[SBOM] Refresh every image when spreading the refresh",
        "text": "### What does this PR do? The spread refresher divides the image count by the number of steps it spreads a period over to decide how many images to refresh per step. The division truncates, so a host with fewer than ten images refreshed none of them, ever. An image SBOM was then sent only when the image changed or when a container first ran it, so inUse stayed true after the last container stopped. Above ten, unless the count was a multiple of ten, the refresh was merely slower than configured. Fifteen images took one and a half periods to cycle. Round the count up. Every image is then covered within one period, at the cost of at most nine extra refreshes per period. That overhead only matters where images are few, and a host with a single image now sends it once per step rather than once per period. The refresher is off by default, so this only affects hosts that set sbom.container_image.use_spread_refresher.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54715",
        "createdAt": "2026-08-11T12:21:55Z",
        "updatedAt": "2026-08-13T13:42:26Z",
        "timestamp": "2026-08-13T13:42:26Z",
        "metrics": {
          "reactions": 2,
          "comments": 4
        },
        "labels": [
          "team/agent-security",
          "qa/done",
          "medium review",
          "team/container-integrations",
          "team/agent-build",
          "internal"
        ],
        "author": "0intro",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54716",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[AAD-36] Use anomaly scorer by default",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? This uses anomaly scorer by default instead of time cluster which is now disabled by default. ### Motivation We want to enable the scorer by default since we rely on it for smart adaptive sampling feature so our current direction is towards detection change points instead of sending events when we have bad behaviors. ### Describe how you validated your changes Ran the benchmarks ### Additional Notes Scenario | Before F1 (time cluster) | After F1 (scorer) | Δ F1 -- | -- | -- | -- block-building-outage | 0.285714 | 0.634606 | +0.348892 cascading-payment-failure | 0.063224 | 0.000083 | -0.063141 cassandra-repair-degradation | 0.227017 | 0.000000 | -0.227017 dns-upstream-outage | 0.054111 | 0.297905 | +0.243794 kafka-partition-saturation | 0.177494 | 0.577355 | +0.399861 lock-contention | 0.618715 | 0.032148 | -0.586567 memcached-saturation | 0.000006 | 0.557888 | +0.557882 pool-saturation | 0.000259 | 0.814789 | +0.814530 redis-cascade-billing | ~0 | ~0 | ~0 redis-cpu-saturation | 0.615742 | 0.016948 | -0.598794 tiered-cache-header-corruption | 0.001845 | ~0 | -0.001845 **Average** | 0.185830 | 0.266520 | +0.080690 (+43.42%)",
        "url": "https://github.com/DataDog/datadog-agent/pull/54716",
        "createdAt": "2026-08-11T12:36:30Z",
        "updatedAt": "2026-08-13T11:07:06Z",
        "timestamp": "2026-08-13T11:07:06Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "medium review",
          "internal",
          "team/fleet-automation"
        ],
        "author": "CelianR",
        "state": "open",
        "assignees": [
          "CelianR"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54717",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "(fleet) add installer metadata payload over a read-only status socket",
        "text": "## Summary This PR adds an `installer_metadata` payload for the fleet installer, collected by the core Agent over a new read-only status socket on the installer daemon. Two pieces: 1. A second listener on the installer daemon serving one route, `GET /status`, returning the installer version and available disk space ([`pkg/fleet/daemon/status_api.go`](https://github.com/DataDog/datadog-agent/blob/arbll/installer-metadata-payload/pkg/fleet/daemon/status_api.go)). Its lifecycle is owned by a new [`comp/updater/statusapi`](https://github.com/DataDog/datadog-agent/blob/arbll/installer-metadata-payload/comp/updater/statusapi/impl/statusapi.go) component wired next to `localapi` in the daemon's fx graph. 2. [`comp/metadata/installer`](https://github.com/DataDog/datadog-agent/blob/arbll/installer-metadata-payload/comp/metadata/installer/impl/installer.go) in the core Agent, which reads that socket and emits the payload on the standard inventory cadence. Inspectable with `datadog-agent diagnose show-metadata installer`. **Scope is deliberately a skeleton.** Day one the payload carries the envelope, the installer version and the available disk space. Package/config state and the pre-flight eligibility signals are follow-ups. The point is to prove the transport end to end and freeze the payload key. ```json { \"hostname\": \"...\", \"timestamp\": 1754900000000000000, \"uuid\": \"...\", \"installer_metadata\": { \"installer_reachable\": true, \"installer_version\": \"7.76.0\", \"available_disk_space\": 12884901888 } } ``` ## Motivation The installer daemon has no way to report metadata about itself. The only host-side signals it can send today ride on the Remote Config state channel — [`pbgo.ClientUpdater.tags`](https://github.com/DataDog/datadog-agent/blob/main/pkg/proto/pbgo/core/remoteagent.pb.go) — chosen because it needed no proto change. That channel is the wrong shape for metadata: bounded, untyped, and owned by RC. This gives later installer metadata somewhere to go. ## Why a second socket The Agent cannot read the existing `installer.sock`. It is `chmod 0700` with no `chown` ([`local_api_unix.go`](https://github.com/DataDog/datadog-agent/blob/main/pkg/fleet/daemon/local_api_unix.go)) created by a root daemon, and the Agent runs as `dd-agent` — `EACCES`. Windows is blocked the same way by the pipe DACL. Widening it is not acceptable: every route on it except `/status` installs, removes or promotes packages as root. So the privileged socket is untouched and a separate read-only one is added, permissioned exactly like system-probe's ([`listener_unix.go`](https://github.com/DataDog/datadog-agent/blob/main/pkg/system-probe/api/server/listener_unix.go)): `0720` plus `RestrictAccessToUser` chowning to `dd-agent`. On Windows, the `D:PAI(A;;FA;;;BA)(A;;FA;;;SY)(A;NP;FRFW;;;<ddagentuser>)` DACL, including system-probe's fallback to SYSTEM+Administrators when the SID lookup fails. This is the security-relevant part of the PR and worth a close look. The handler reaches the daemon through a narrow `statusProvider` interface rather than `Daemon`, so a listener the Agent user can talk to structurally cannot reach the privileged methods. ## Tradeoffs - **Agent-collects rather than daemon-emits.** Wiring a forwarder and serializer into the daemon would work, but would make the installer the first process to send *host-scoped* metadata while a core Agent runs on the same host — the two other co-resident daemons, system-probe and security-agent, deliberately do not, and their payloads are produced by components inside the Agent. It would also cost forwarder-sized growth on the Agent package quality gates, since the installer ships inside the agent packages. - **No config key for the socket path** on day one; it is derived from `paths.RunPath`, the way `daemonchecker` already locates `installer.sock`. An `installer.status_socket` key can follow if e2e needs to override it. - **`GetStatus` does not take the daemon mutex.** The lock is held for the whole duration of an install, so taking it would stall the Agent's request past its timeout and make a busy installer look unreachable. Documented at the call site; the fields read are set once at construction. - **One stub payload is possible at startup** if the Agent collects before the daemon has created the socket. Self-heals within the runner's 10-minute max interval. No retry loop inside `getPayload` — the runner already provides the cadence. ## Blocked on `/api/v1/metadata` routes on the top-level JSON key, and an unrecognised key is accepted by the intake and then dropped. The `installer_metadata` mapping needs to land in dd-source before this payload does anything, and the key gets frozen at that point. **Draft until then.** ## Testing - Unit tests for the component with the client call stubbed: happy path, unreachable → non-nil stub, unknown disk space omitted, and an assertion that the literal top-level key `installer_metadata` is emitted (guards the backend contract against a silent rename). - Cross-process round trip over a real unix socket in `pkg/fleet/daemon`, plus a test pinning the socket mode at `0720` — if that regresses the Agent silently starts reporting the installer as unreachable. - `cmd/installer/subcommands/daemon` already runs `fxutil.TestRun`, which validates the new component's wiring across the whole daemon graph. **Not yet verified, and the reason this is a draft beyond the backend key:** the Windows sources are unbuilt locally (no mingw-w64 / cmake in my worktree — CI covers them), and the real-host checks are outstanding: reading the socket as `dd-agent` and as `ddagentuser`, `show-metadata installer` on a host with `remote_updates: true`, and the absence path with `remote_updates: false`. ## Not duplicated `install_method_*`, `package_version`, `feature_remote_updates_enabled` and `fleet_policies_applied` already exist in the `datadog_agent` payload and are left alone. Note `install_method_installer_version` is not a version number — [`installinfo.go`](https://github.com/DataDog/datadog-agent/blob/main/pkg/fleet/installer/installinfo/installinfo.go) sets it to `<install_type>_package` — so it does not collide with `installer_version`. ```mermaid flowchart LR subgraph root[\"installer daemon (root / SYSTEM)\"] D[daemonImpl] LA[\"localAPI<br/>installer.sock — 0700<br/>install / remove / promote\"] SA[\"statusAPI<br/>installer-status.sock — 0720<br/>GET /status, read-only\"] D -->|\"privileged<br/>Daemon\"| LA D -->|\"narrow<br/>statusProvider\"| SA end subgraph agent[\"core Agent (dd-agent / ddagentuser)\"] C[\"comp/metadata/installer\"] R[\"metadata runner<br/>1–10 min\"] R --> C end SA -.->|\"installer_version<br/>available_disk_space\"| C LA -. \"EACCES\" .-x C C -->|\"installer_metadata\"| I[\"/api/v1/metadata\"] ```",
        "url": "https://github.com/DataDog/datadog-agent/pull/54717",
        "timestamp": "2026-08-12T12:44:37Z",
        "metrics": {
          "reactions": 1,
          "comments": 6
        },
        "labels": [
          "qa/done",
          "long review",
          "team/agent-runtimes",
          "team/agent-build",
          "team/windows-products",
          "internal",
          "team/fleet-remediation",
          "team/fleet-automation"
        ],
        "author": "arbll",
        "assignees": [],
        "change": "new"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54718",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Use hermetic MSVC and msbuild to build cpython on Windows",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Previous implementation relied on the local installation of MSVC and msbuild to build cpython. A custom repository rule would verify version of the installed MSVC that worked perfectly fine inside of build images. Unfortunately, Windows Updates do bump MSVC as well, so at some point the build started to fail on the Windows host (not inside of the container) due to msbuild version mismatch. One of the potential solutions was to relax version check but that would inevitably introduce caching issues when we can't efficiently share cache across machines unable to ensure that everyone is using the same MSVC. Thus, this PR targets to introduce a fully hermetic MSVC and msbuild distribution that is fully managed by Bazel. We use [toolchains_msvc](https://github.com/Dragnalith/toolchains_msvc) as basis applying a patch on top of that to, first, stop filtering out msbuild and, second, expose additional headers and dlls that are required to make this whole enterprise work. There is one more consumer for msbuild - `libdatadog-interop.dll`. This will be handled in a follow up PR.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54718",
        "createdAt": "2026-08-11T13:10:35Z",
        "updatedAt": "2026-08-12T15:07:54Z",
        "timestamp": "2026-08-12T15:07:54Z",
        "metrics": {
          "reactions": 2,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "long review",
          "team/agent-devx",
          "team/agent-build",
          "internal"
        ],
        "author": "JSGette",
        "state": "closed",
        "assignees": [
          "JSGette"
        ],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54719",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[EBPF] Collect NVLink fields per port",
        "text": "### What does this PR do? Collects NVLink field values independently for each port. ### Motivation A field unsupported on one port should not suppress metrics from supported ports. ### Describe how you validated your changes `dda inv test --targets=./pkg/collector/corechecks/gpu/nvidia` ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54719",
        "createdAt": "2026-08-11T13:11:27Z",
        "updatedAt": "2026-08-13T10:56:30Z",
        "timestamp": "2026-08-13T10:56:30Z",
        "metrics": {
          "reactions": 0,
          "comments": 4
        },
        "labels": [
          "team/ebpf-platform",
          "medium review",
          "internal",
          "team/gpu-monitoring-agent"
        ],
        "author": "gjulianm",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54720",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[EBPF] gpu: Support ARM64 NVML library discovery",
        "text": "<!-- dd-meta {\"pullId\":\"df13230b-a434-451b-972e-ac9007c02168\",\"source\":\"chat\",\"resourceId\":\"86800824-17f2-4a85-9551-be5b7bf8a830\",\"workflowId\":\"2ce581a4-a03e-4c0a-a1a1-dda5b27f5a0c\",\"codeChangeId\":\"2ce581a4-a03e-4c0a-a1a1-dda5b27f5a0c\",\"sourceType\":\"bits_ai_sre\"} --> ### What does this PR do? Bits AI SRE Investigation • [View in Bits AI SRE Investigation](https://ddstaging.datadoghq.com/bits-ai/investigations/8418dc69-efd2-44d3-ad70-91e14223f69d) Add standard ARM64 (`aarch64-linux-gnu`) NVML library paths for host and NVIDIA GPU Operator installations. ### Motivation GPU checks on ARM64 GPU nodes fail because NVML discovery searches only x86_64 library directories. This causes all GPU metrics to fail on affected ARM64 nodes and can trigger incorrect health responses. ### Describe how you validated your changes Unit tests added ### Additional Notes --- PR by Bits - [View session in Datadog](https://ddstaging.datadoghq.com/code/86800824-17f2-4a85-9551-be5b7bf8a830) Comment @datadog to request changes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54720",
        "createdAt": "2026-08-11T13:28:10Z",
        "updatedAt": "2026-08-13T16:28:12Z",
        "timestamp": "2026-08-13T16:28:12Z",
        "metrics": {
          "reactions": 2,
          "comments": 9
        },
        "labels": [
          "changelog/no-changelog",
          "team/ebpf-platform",
          "qa/done",
          "team/container-platform",
          "medium review",
          "team/container-integrations",
          "Bits AI",
          "internal",
          "team/gpu-monitoring-agent",
          "team/fleet-automation",
          "backport/7.83.x"
        ],
        "author": "gjulianm",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54723",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Upgrade embedded Python patch version to 3.13.15",
        "text": "### What does this PR do? Upgrades the Agent's embedded CPython interpreter from **3.13.14** to **3.13.15** (patch version update). - Updated `omnibus/config/software/python3.rb` with the new version - Updated `deps/cpython/cpython.MODULE.bazel` with the new version and SHA256 - Updated `test/new-e2e/tests/agent-platform/common/agent_behaviour.go` with the expected version - Created a release note documenting the upgrade SHA256 hash automatically fetched and verified against the official Python.org SBOM file. See the [official Python release page](https://www.python.org/downloads/release/python-31315/) for details. ### Motivation Keep the embedded Python up to date with bug fixes and security patches. 3.13.15 (released 2026-08-05) remediates several CVEs tracked in the agent-integrations VULN queue, including tarfile symlink/hardlink filter issues (CVE-2026-11940, CVE-2026-4360), a tarfile DoS (CVE-2026-11972), an html.parser quadratic DoS (CVE-2026-15308), a configparser CR write injection (CVE-2026-0864), and an xml.etree findall DoS (CVE-2026-6879). ### Describe how you validated your changes CI is considered enough to validate changes. The E2E `ExpectedPythonVersion3` constant is updated in lockstep so the agent-platform behaviour tests assert the new version. ### Additional Notes Generated with `dda inv python-version.update`, mirroring the previous automated bump (#52085).",
        "url": "https://github.com/DataDog/datadog-agent/pull/54723",
        "createdAt": "2026-08-11T14:32:24Z",
        "updatedAt": "2026-08-12T14:29:34Z",
        "timestamp": "2026-08-12T14:29:34Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "medium review",
          "qa/rc-required",
          "team/agent-integrations",
          "ask-review",
          "team/agent-devx",
          "team/agent-build",
          "internal"
        ],
        "author": "Kyle-Neale",
        "state": "closed",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54725",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Fix AWS CLI install/download flakiness in Windows E2E host_cache",
        "text": "### What does this PR do? - Check msiexec's real exit code instead of just whether `Start-Process` launched it. - Retry the AWS CLI install and `aws s3 cp` to handle flaky network. - Collect the msiexec install log into the test artifacts folder on failure. ### Motivation Try to avoid flakes like https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1914723351. See https://datadoghq.atlassian.net/browse/WINA-3000",
        "url": "https://github.com/DataDog/datadog-agent/pull/54725",
        "createdAt": "2026-08-11T14:44:42Z",
        "updatedAt": "2026-08-13T03:41:44Z",
        "timestamp": "2026-08-13T03:41:44Z",
        "metrics": {
          "reactions": 0,
          "comments": 2
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "short review",
          "team/agent-devx",
          "team/windows-products",
          "internal"
        ],
        "author": "clarkb7",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54727",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[CONTP-1773] Fix(workloadmeta): signal initialization when no collector is applicable",
        "text": "### What does this PR do? Fixes GH issue #49480 / CONTP-1773: the Agent logs a spurious ERROR on every startup in environments where no workloadmeta collector is applicable (e.g. a container sidecar with no Kubernetes, no container runtime socket, no ECS, no GPU). Root cause: when all collector candidates fail to start with non-retriable \"disabled\" errors, `startCandidatesWithRetry` never closes `firstCollectorReady`, so the pull goroutine waits the full `firstPullWaitTimeout` (30s) before marking the store initialized. Autodiscovery only waits 10s, so it logs the ERROR first. Fix: close `firstCollectorReady` once all candidates have been processed, even when none started, so the pull goroutine proceeds immediately and signals initialization. ### Motivation Spurious startup ERROR alarms users and trips log-based alerts on every pod restart. ### Describe how you validated your changes Unit tests (`dda inv test --targets=./comp/core/workloadmeta/impl/...` and `./comp/core/autodiscovery/impl/...`). ### Additional Notes Regression introduced by #47178 (AGENTCFG-650). This fix restores prompt initialization when no collector is applicable without reintroducing that PR's race.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54727",
        "createdAt": "2026-08-11T15:18:05Z",
        "updatedAt": "2026-08-12T18:18:21Z",
        "timestamp": "2026-08-12T18:18:21Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "qa/done",
          "team/container-platform",
          "medium review",
          "team/agent-build",
          "internal"
        ],
        "author": "zhuminyi",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54729",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[EBPF] gpu: Skip unsupported vGPU max-clock queries",
        "text": "<!-- dd-meta {\"pullId\":\"00000000-0000-0000-0000-000000000000\",\"source\":\"chat\",\"resourceId\":\"b6950850-80dc-4801-bc2f-895d5b466cca\",\"workflowId\":\"c63cfe10-11dd-4bbc-800e-23188cad9c50\",\"codeChangeId\":\"c63cfe10-11dd-4bbc-800e-23188cad9c50\",\"sourceType\":\"bits_ai_sre\"} --> ### What does this PR do? Bits AI SRE Investigation • [View in Bits AI SRE Investigation](https://app.datadoghq.com/bits-ai/investigations/54d64295-b38b-44f1-85fa-fb1948786cba) - Detect vGPU devices in the NVIDIA stateless max-clock handlers. - Cache each device's NVML virtualization mode in `safenvml.DeviceInfo` during device initialization, so max-clock collection does not query NVML repeatedly. - Return the repository's typed unsupported-API error so all four max-clock handlers are filtered during collector initialization. - Log an error when the virtualization-mode lookup fails during device initialization. - Add regression coverage that makes vGPU max-clock calls return `ERROR_UNKNOWN`, verifies the cached mode, and confirms max-clock calls are never invoked or reported as collection errors. ### Motivation NVIDIA vGPU devices such as the A10-24Q configuration in the zekrom cluster do not support NVML `GetMaxClockInfo`. The API returns `Unknown Error` rather than `ERROR_NOT_SUPPORTED`, so the stateless collector previously retried the calls on every collection cycle and generated recurring collection-error noise. This fix suppresses those unsupported calls while preserving max-clock metrics for physical GPUs, caches the virtualization capability query used to make that decision, and reports failures to determine the mode. ### Describe how you validated your changes - Formatted the modified Go file with `gofmt` and ran `git diff --check`. - Verified the vGPU regression test observes one virtualization-mode query during device initialization and zero max-clock queries. ### Additional Notes The change is limited to the NVIDIA stateless collector, safenvml device metadata and logging, and regression coverage. --- PR by Bits - [View session in Datadog](https://app.datadoghq.com/code/b6950850-80dc-4801-bc2f-895d5b466cca) Comment @datadog to request changes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54729",
        "createdAt": "2026-08-11T15:26:57Z",
        "updatedAt": "2026-08-13T11:26:55Z",
        "timestamp": "2026-08-13T11:26:55Z",
        "metrics": {
          "reactions": 3,
          "comments": 11
        },
        "labels": [
          "changelog/no-changelog",
          "team/ebpf-platform",
          "qa/done",
          "short review",
          "Bits AI",
          "internal",
          "team/gpu-monitoring-agent",
          "backport/7.83.x"
        ],
        "author": "gjulianm",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54731",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[procmgr] Windows spawn profiles foundation",
        "text": "### What does this PR do? Introduces **Windows spawn profiles** in dd-procmgr so managed children can run under different security contexts: - **Privileged**: spawn as LocalSystem (supervisor primary token) - **AgentUser**: spawn as the agent service account (`ddagentuser`) Adds the Windows spawn stack (token logon, user profile load, supervision job, suspended `CreateProcessAsUserW`), COAT catalog enforcement for allowed profiles, and gRPC pipe caller authentication. **Stack context:** PR 1/4 split from [#53249](https://github.com/DataDog/datadog-agent/pull/53249). Config gates, secret backend resolution, and process-agent dual-mode integration land in follow-up PRs (`jose/procmgr-config-gates`, `jose/procmgr-secret-backend-gates`, `jose/procmgr-windows-process-agent`). This PR includes a **stub** `config_gate` module (gates always open) so the crate compiles until PR 2. ### Motivation Process-agent on Windows must run as LocalSystem and other agent children should stay on the agent user. Spawn profiles make that explicit and enforceable at spawn time, and are a prerequisite for moving process-agent supervision off legacy SCM in later PRs. ### Describe how you validated your changes - Windows procmgr Rust build/tests in CI - COAT unit tests (`pkg/procmgr/coat/...`) - Windows E2E: privileged spawn catalog enforcement (`test/new-e2e/tests/agent-runtimes/procmgr/...`) ### Additional Notes - No agent startup, fleet installer, or process-agent dual-mode changes in this PR. - [#53568](https://github.com/DataDog/datadog-agent/pull/53568) (list/describe profile + user) should rebase onto this branch once merged. - Supersedes the spawn/COAT portion of [#53249](https://github.com/DataDog/datadog-agent/pull/53249); that PR will be closed after the stack is open.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54731",
        "createdAt": "2026-08-11T15:45:26Z",
        "updatedAt": "2026-08-13T17:37:03Z",
        "timestamp": "2026-08-13T17:37:03Z",
        "metrics": {
          "reactions": 1,
          "comments": 30
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "long review",
          "team/agent-runtimes",
          "team/agent-build",
          "team/windows-products",
          "internal"
        ],
        "author": "jose-manuel-almaza",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54732",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[procmgr] Config gates for processes.d auto-start",
        "text": "### What does this PR do? Adds **config gates** to dd-procmgr so `processes.d` definitions can use `condition_config_any` to auto-start only when Agent config says they should. Implementation mirrors the Windows legacy SCM startup checks in `dependent_services_windows.go` and Agent config resolution: - YAML lookup (case-insensitive keys, flattened dotted keys, permissive parse fallback, merge keys) - Environment bindings (`DD_*`) with Agent precedence (ignore empty values, no trim before `ParseBool`, legacy `process_config.enabled` transforms) - Fleet policy merge - Derived `system_probe_config.enabled` (USM/NPM/security knobs, sk-tracer and discovery adjustments) - Windows: read `DD_*` overrides from the core Agent SCM `Environment` registry when not set in the procmgr process env Wires gate evaluation into `ManagedProcess` start/reload paths in the manager. **Stack context:** PR 2/4 split from [#53249](https://github.com/DataDog/datadog-agent/pull/53249). Builds on [#54731](https://github.com/DataDog/datadog-agent/pull/54731) (`jose/procmgr-spawn-profiles`). `ENC[...]` secret backend resolution lands in PR 3 (`jose/procmgr-secret-backend-gates`). Process-agent dual-mode integration lands in PR 4 (`jose/procmgr-windows-process-agent`). ### Motivation Moving subservices (starting with process-agent) to dd-procmgr requires the supervisor to apply the same start/stop rules as the Agent today. Without config gates, a `processes.d` entry would always spawn when registered, which breaks parity with legacy SCM and fleet policy. ### Describe how you validated your changes - Rust unit tests in `pkg/procmgr/rust/src/config_gate/` (env bindings, YAML load, system-probe derivations, gate evaluation) - Go unit tests for Windows config helpers (`pkg/config/setup/config_windows_test.go`) - Windows procmgr Rust build/tests in CI ### Additional Notes - No `ENC[...]` / secret backend resolution in this PR (fleet policy `ENC[...]` values are not resolved here either). - No agent startup, fleet installer, or legacy SCM suppression changes in this PR. - Schema comment sync in `pkg/config/schema/yaml/process_config.yaml` for env binding documentation. - Small exports in `pkg/system-probe/config/` so procmgr gate derivations stay aligned with Go `adjust*` logic.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54732",
        "createdAt": "2026-08-11T15:51:46Z",
        "updatedAt": "2026-08-13T16:47:33Z",
        "timestamp": "2026-08-13T16:47:33Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "team/ebpf-platform",
          "qa/done",
          "long review",
          "team/agent-runtimes",
          "team/agent-devx",
          "team/container-experiences",
          "team/agent-build",
          "team/windows-products",
          "internal",
          "team/fleet-automation"
        ],
        "author": "jose-manuel-almaza",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54734",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[procmgr] Secret backend resolution for config gates",
        "text": "### What does this PR do? Resolves `ENC[...]` values during config gate evaluation so dd-procmgr matches Agent secret handling. Adds: - `config_gate/secrets.rs`: resolve handles via `secret_backend_command`, native `secret_backend_type`, and `multi_secret_backends` (same precedence as the core Agent) - Platform secret backend runners (Windows `CreateProcessAsUserW` under the Agent account; Unix setuid when procmgr runs as root for Privileged children) - `secret_backend_exec.rs`: shared spawn, timeout, stdout drain, and response parsing - Windows ACL validation on secret backend executables before spawn - Agent config precedence for backend settings: `DD_SECRET_BACKEND_*` env (including core Agent SCM `Environment` on Windows) over `datadog.yaml` - Manager reload: invalidate secret caches when config changes Fleet policy `ENC[...]` values stay unresolved here, matching Agent `MergeFleetPolicy` running after secret resolution. **Stack context:** PR 3/4 split from [#53249](https://github.com/DataDog/datadog-agent/pull/53249). Builds on [#54732](https://github.com/DataDog/datadog-agent/pull/54732) (`jose/procmgr-config-gates`), which in turn builds on [#54731](https://github.com/DataDog/datadog-agent/pull/54731). Process-agent dual-mode integration lands in PR 4 (`jose/procmgr-windows-process-agent`). ### Motivation PR 2 config gates read YAML, env, and fleet policy, but many customers gate features with secret-backed settings (`ENC[api_key]`, secret-backed booleans, etc.). Without secret resolution, gates would mis-evaluate and auto-start behavior would diverge from the Agent. ### Describe how you validated your changes - Rust unit tests in `pkg/procmgr/rust/src/config_gate/secrets.rs` and config gate integration tests (serialized env to avoid cross-test leakage) - Windows procmgr Rust build/tests in CI - Linux CI: secret-backend tests run under the agent service user where required ### Additional Notes - Secret backends always run as the core Agent service account, not as the procmgr supervisor (LocalSystem) or a Privileged managed child. - No agent startup, fleet installer, or legacy SCM suppression changes in this PR. - Invokes `secret-generic-connector` when no custom `secret_backend_command` is configured.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54734",
        "createdAt": "2026-08-11T15:56:49Z",
        "updatedAt": "2026-08-13T17:08:58Z",
        "timestamp": "2026-08-13T17:08:58Z",
        "metrics": {
          "reactions": 2,
          "comments": 1
        },
        "labels": [
          "changelog/no-changelog",
          "team/ebpf-platform",
          "qa/done",
          "long review",
          "team/agent-runtimes",
          "team/agent-devx",
          "team/container-experiences",
          "team/agent-build",
          "team/windows-products",
          "internal",
          "team/fleet-automation"
        ],
        "author": "jose-manuel-almaza",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54735",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[procmgr] Supervise process-agent on Windows via dd-procmgr",
        "text": "### What does this PR do? Moves Windows **process-agent** supervision to **dd-procmgr** using the same dual-mode pattern as PAR: - Fleet installer writes `processes.d/datadog-agent-process.yaml` (Privileged spawn profile) - Legacy `datadog-process-agent` SCM service is suppressed when procmgr owns process-agent - Agent startup waits on `dd-procmgr-service` before starting gated legacy children; independent services (sysprobe, security-agent, installer) start without blocking on procmgr Also runs **dd-procmgr-service as LocalSystem** (MSI service custom action) so the supervisor can spawn Privileged children while agent-profile processes still spawn as `ddagentuser`. **Stack context:** PR 4/4 split from [#53249](https://github.com/DataDog/datadog-agent/pull/53249). Builds on [#54734](https://github.com/DataDog/datadog-agent/pull/54734) → [#54732](https://github.com/DataDog/datadog-agent/pull/54732) → [#54731](https://github.com/DataDog/datadog-agent/pull/54731). Spawn profiles, config gates, and secret backend resolution land in those PRs. ### Motivation We want subservices on dd-procmgr instead of SCM. Process-agent needs LocalSystem on Windows; other agent children should stay on the agent user. This PR wires the product integration once the procmgr foundation (PRs 1–3) is in place. ### Describe how you validated your changes - Go unit tests for dependent Windows service startup (`dependent_services_windows_test.go`) - Go unit tests for fleet installer templates and YAML path substitution (`processmanager/...`) - New Windows E2E: process-agent supervised by procmgr, runs as LocalSystem, legacy SCM stopped - E2E: dd-procmgr-service runs as LocalSystem; agent-profile children run as agent user - E2E: privileged spawn catalog enforcement when processes.d YAML is tampered with - PAR/procmgr Windows E2E regression ### Additional Notes - Linux process-agent stays on systemd for now. Legacy SCM service registration is not removed yet. - Process-agent `processes.d` config uses the shared `install_root` helper (same as PAR/ADP). MSI `RemoveFolderEx` handles uninstall/rollback cleanup; no per-file MSI rollback custom actions. - Includes release note `windows-process-procmgr-dual-mode-b7d2e4a1c8f03962.yaml`. - Closes/supersedes [#53249](https://github.com/DataDog/datadog-agent/pull/53249) once the full stack merges.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54735",
        "createdAt": "2026-08-11T16:07:07Z",
        "updatedAt": "2026-08-13T17:09:07Z",
        "timestamp": "2026-08-13T17:09:07Z",
        "metrics": {
          "reactions": 2,
          "comments": 1
        },
        "labels": [
          "qa/done",
          "long review",
          "team/agent-runtimes",
          "team/agent-build",
          "team/windows-products",
          "internal"
        ],
        "author": "jose-manuel-almaza",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54739",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[ABLD-366] Fix build file for cmd/loader so it can also build for macos.",
        "text": "### What does this PR do? Fix build file for cmd/loader so it can also build for macos. - Remove unneeded target_compatible_with - Adjust packaging to include it for macos. - Fix dd_agent_go_binary so we can select() `exact_gotags` We are blocked on ABLD-294 for using the loader in the real package, so we just have it named \"loader\" for now. We can build and verify that it works. ### Describe how you validated your changes Make sure the loader builds and runs on mac. Running it is subtle. ``` $ bazel build //cmd/trace-agent:trace-agent Target //cmd/trace-agent:trace-agent up-to-date: bazel-bin/cmd/trace-agent/trace-agent_/trace-agent INFO: Build completed successfully, 1 total action $ cp bazel-bin/cmd/trace-agent/trace-agent_/trace-agent /tmp $ bazel build //cmd/loader:loader Target //cmd/loader:loader up-to-date: bazel-bin/cmd/loader/loader_/loader $ bazel-bin/cmd/loader/loader_/loader /opt/datadog-agent/etc/datadog.yaml /tmp/trace-agent ... 2026-08-11 14:45:52 EDT | TRACE-LOADER | INFO | (pkg/util/log/log.go:734 in func1) | Starting to load the configuration 2026-08-11 14:45:52 EDT | TRACE-LOADER | ERROR | (pkg/util/log/log.go:815 in func1) | warning reading config ... ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54739",
        "createdAt": "2026-08-11T17:28:25Z",
        "updatedAt": "2026-08-12T17:58:08Z",
        "timestamp": "2026-08-12T17:58:08Z",
        "metrics": {
          "reactions": 2,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "short review",
          "team/agent-build",
          "internal"
        ],
        "author": "aiuto",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54741",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Add DD_LOG_LEVEL install-time option",
        "text": "### What does this PR do? Adds a `DD_LOG_LEVEL` install-time option to set the initial `log_level` in `datadog.yaml`: - The Datadog installer's setup script now maps a `DD_LOG_LEVEL` environment variable to `datadog.yaml`'s `log_level` (cross-platform, in `pkg/fleet/installer/setup`). - On Windows, the Agent MSI installer exposes a `DD_LOG_LEVEL` property (declared secure so it survives into the elevated deferred custom action) that's passed through to the Datadog installer. - Adds matching `WithLogLevel` e2e test install options in both `msi.InstallAgentParams` and `windowsAgent.InstallAgentParams`. ### Motivation https://datadoghq.atlassian.net/browse/WINA-3019 Windows E2E tests currently have no easy way to run the installed Agent at `debug` log level for better diagnostics when a test fails. This gives tests (and customers) a one-shot way to set it at install time instead of editing `datadog.yaml` or using a runtime `agent config set` call after the fact. ### Describe how you validated your changes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54741",
        "timestamp": "2026-08-12T12:30:52Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "medium review",
          "team/agent-devx",
          "team/windows-products",
          "internal"
        ],
        "author": "clarkb7",
        "assignees": [],
        "change": "new"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54743",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[CONTINT-5442] Add pod state handlers to container_lifecycle",
        "text": "### What does this PR do? This PR adds a `PodStateHandler` that emits transition events for pod `.status.phase` and `.status.conditions[*]` changes (except reason changes), using a per-pod shadow map to diff consecutive `workloadmeta` observations. Gated behind the existing `container_lifecycle.extended_set` flag. ### Motivation [CONTINT-5442](https://datadoghq.atlassian.net/browse/CONTINT-5442) ### Describe how you validated your changes Added unit tests. Also deployed the agent onto a kind cluster with telemetry enabled and an openmetrics check configured to scrape the agent telemetry ports, and saw the new `transition` `event_type` on the `datadog.agent.container_lifecycle_emitted_events` metric. <img width=\"1382\" height=\"401\" alt=\"image\" src=\"https://github.com/user-attachments/assets/8047b9ed-ff97-4e82-8785-8f547f964c06\" /> ### Additional Notes [CONTINT-5442]: https://datadoghq.atlassian.net/browse/CONTINT-5442?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
        "url": "https://github.com/DataDog/datadog-agent/pull/54743",
        "createdAt": "2026-08-11T18:45:10Z",
        "updatedAt": "2026-08-13T04:07:35Z",
        "timestamp": "2026-08-13T04:07:35Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "medium review",
          "team/container-integrations",
          "team/agent-build",
          "internal"
        ],
        "author": "triviajon",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54744",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "remove unneeded python spec in legcay omnibus",
        "text": "### What does this PR do? Removes unused python version spec. It is just confusing. ### Motivation ### Describe how you validated your changes CI",
        "url": "https://github.com/DataDog/datadog-agent/pull/54744",
        "createdAt": "2026-08-11T18:56:37Z",
        "updatedAt": "2026-08-12T18:05:46Z",
        "timestamp": "2026-08-12T18:05:46Z",
        "metrics": {
          "reactions": 1,
          "comments": 2
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "medium review",
          "team/agent-integrations",
          "team/agent-build",
          "internal"
        ],
        "author": "aiuto",
        "state": "open",
        "assignees": [
          "Kyle-Neale"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54746",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[ABLD-419]  Only install bazelisk with dda inv install-tools on macos",
        "text": "### What does this PR do? Cuts bazelisk out of tasks/install_tools. Except on mac, because for some reason it is not in the build image. ### Motivation We should not be installing bazelisk from tasks. That muddies the chain to source of trust because bazel is the root of the trusted tools. Bazelisk should come with the build image or be installed in some other trusted way. ### Describe how you validated your changes CI ### Additional notes Related: ABLD-306 This may break some individual users where bazelisk is not installed on the developer machine. That is desired. I want to find those cases and find ways to better manage their environment.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54746",
        "createdAt": "2026-08-11T19:55:59Z",
        "updatedAt": "2026-08-12T20:53:58Z",
        "timestamp": "2026-08-12T20:53:58Z",
        "metrics": {
          "reactions": 2,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "short review",
          "team/agent-devx",
          "internal"
        ],
        "author": "aiuto",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54748",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Read embedded Python version from Bazel in the python-version task",
        "text": "### What does this PR do? Migrates the `python-version` invoke task (`tasks/python_version.py`) to treat the Bazel module file `deps/cpython/cpython.MODULE.bazel` as the single source of truth for the embedded Python version: - `_get_current_python_version()` now reads `PYTHON_VERSION` from the Bazel file instead of `default_version` in `omnibus/config/software/python3.rb`. - Drops `_prepare_omnibus_update()` (and its call in `update()`), so the task no longer rewrites `default_version` on a bump. The Bazel file already carries both the version and the source-tarball `sha256`, and already drives the build. - Updates `tasks/unit_tests/python_version_tests.py` accordingly (Bazel-based fixtures for the read path; removes the now-obsolete omnibus-write test). ### Motivation PR #54744 removes the unused `default_version`/`relative_path` fields from `omnibus/config/software/python3.rb` (Bazel drives the CPython build now). As Codex flagged there, removing `default_version` would break the documented Python bump workflow, because `_get_current_python_version()` / `_prepare_omnibus_update()` still scan `python3.rb` for that marker and raise if it is absent. This change decouples the task from the omnibus marker so the bump workflow keeps working regardless of the order in which this PR and #54744 merge. It also aligns with the `tasks/AGENTS.md` \"single source of truth\" idiom. ### Describe how you validated your changes - `dda inv invoke-unit-tests.run` fixtures updated; ran `tasks/unit_tests/python_version_tests.py` (15 tests) — all pass. - Live check: `_get_current_python_version()` returns `3.13.14` on `main`, read from the Bazel file. - `ruff check` and `ruff format --check` clean on both changed files. ### Additional Notes Follows up on the discussion in #54744. No release note: this is developer tooling (invoke task) and is not shipped with the Agent.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54748",
        "createdAt": "2026-08-11T20:19:47Z",
        "updatedAt": "2026-08-13T15:54:05Z",
        "timestamp": "2026-08-13T15:54:05Z",
        "metrics": {
          "reactions": 1,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "medium review",
          "team/agent-integrations",
          "team/agent-devx",
          "internal"
        ],
        "author": "Kyle-Neale",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54749",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Bump AIX embedded Python to 3.13.15",
        "text": "### What does this PR do? Bumps the AIX embedded Python pin from 3.13.14 to 3.13.15 in `packaging/aix/lib/env.sh`. ### Motivation The AIX packaging build pins the embedded Python version in `packaging/aix/lib/env.sh`, and `packaging/aix/stages/02-python.sh` downloads and builds CPython from that value. This file is **not** touched by `dda inv python-version.update`, so the 3.13.15 upgrade (#54723) left AIX on 3.13.14 — meaning the AIX artifact would ship the vulnerable patch version while the rest of the platforms move to 3.13.15. This was flagged by Codex review on #54723 and confirmed by @aiuto. `02-python.sh` downloads the source tarball from python.org over `curl` with no pinned checksum and applies AIX patches via `sed` with graceful fallback, so the version string is the only change required for a patch bump. ### Describe how you validated your changes - Verified `packaging/aix/stages/02-python.sh` derives the tarball name, URL, and source dir entirely from `$PYTHON_VERSION` and performs no checksum verification, so no hash needs updating. - Confirmed `packaging/` has no other hardcoded `3.13.14` reference after the change. ### Additional Notes Companion to the main 3.13.15 upgrade in #54723; the \"embedded Python upgraded from 3.13.14 to 3.13.15\" release note in that PR covers this change for the AIX platform, so no separate release note is added here.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54749",
        "createdAt": "2026-08-11T20:26:03Z",
        "updatedAt": "2026-08-12T14:29:10Z",
        "timestamp": "2026-08-12T14:29:10Z",
        "metrics": {
          "reactions": 1,
          "comments": 2
        },
        "labels": [
          "changelog/no-changelog",
          "short review",
          "qa/rc-required",
          "team/agent-build",
          "internal"
        ],
        "author": "Kyle-Neale",
        "state": "closed",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54753",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "fix(logs): stop diluting leading timestamp matches",
        "text": "### What does this PR do? Modifies the auto multi-line timestamp detector's scoring so that a line opening with a long enough run of matching tokens is scored on that run alone. Adds regression cases for both sides of the default threshold. ### Motivation Consecutive IIS W3C access-log records were being concatenated into a single log. W3C extended records are single-line by specification, so each one must start its own group. This surfaced as a customer escalation ([AGENT-16759](https://datadoghq.atlassian.net/browse/AGENT-16759)) after 7.82.0 enabled `logs_config.auto_multi_line_detection` by default (#53007). The cause is in `maxSubsequence`. The detector tokenizes the line, then scores each adjacent pair of tokens `+1` if that pair appears in a known timestamp format and `-1` if it does not. `maxSubsequence` is Kadane's algorithm, so it selects the run of pairs with the highest *total*, and the reported probability is that total divided by the run's length. ``` input : 2026-08-11 10:34:49 W3SVC1 10.1.48.10 GET /ZenIT/Service/v13 tokens : DDDD-DD-DD DD:DD:DD CDCCCD DD.D.DD.DD CCC /CCCCC/CCCCCCC/CDD pairs : +++++++++++----+++--++++--------- ``` 34 tokens give 33 pairs, in sign blocks of `+11`, `-4`, `+3`, `-2`, `+4`, `-9`: | run | total | length | probability | |---|---|---|---| | first 11 pairs, the timestamp | +11 | 11 | 1.0000 | | first 24 pairs | +12 | 24 | **0.5000** | | all 33 pairs | +3 | 33 | 0.0909 | Extending from 11 pairs to 24 adds `-4 +3 -2 +4`, a net gain of one, so the total rises from 11 to 12 and the longer run wins. The timestamp scores perfectly on its own, but the algorithm walks past it for a single extra point of total and the reported probability halves. `0.5` is the default `logs_config.auto_multi_line.timestamp_detector_match_threshold` and the comparison is strictly greater-than, so each record fell through to the labeler's default `aggregate` and was appended to the preceding log. `MatchProbability` now measures the leading run of matching pairs up front and reports a full match when that run is at least `minimumTokenLength`. Answering there skips the Kadane scan altogether, so the function ends up faster than before rather than slower. ### Verification - Added the four IIS records to the `inputs` dataset. Two carry the `DD.D.DD.DD` client address and previously scored `0.5`. Two are controls that already scored `1.0`. - Added four continuation lines as `aggregate` cases. Each contains an IPv4 address that scores exactly `0.5` on its own, pinning the other side of the boundary. - `dda inv test --targets=./pkg/logs/internal/decoder/preprocessor/...` passes, 410 tests. `dda inv test --targets=./pkg/logs/...` passes, 1734 tests with 1 skipped. - Mutation-tested every part of the change. Reverting `token_graph.go` fails the two IIS cases at `0.500000`. Relaxing the comparison to `>=` fails all four continuation cases. An off-by-one on `minimumTokenLength` fails `TestLeadingRunIsFullMatch`. - Measured every dataset input at full float64 precision in a standalone harness at shipping defaults, then swept all 81 IPv4 octet digit-shapes plus 21 adversarial inputs (MAC addresses, UUIDs, version vectors, phone numbers, IPv6). The change flips no input other than the two IIS records. - `MatchProbability` has exactly one non-test caller, the timestamp detector. - Benchmarked against `main` on the detector's own corpus: `MatchProbability` goes from 2673 to 1830 ns/op, about 32% faster, with allocations unchanged at zero. A line opening with a timestamp drops from 68 to 13 ns/op because it no longer runs the scan. The worst case, a leading run one pair short of the minimum, costs 9% more. Behaviour was held identical across 400k randomised comparisons against the previous implementation. [AGENT-16759]: https://datadoghq.atlassian.net/browse/AGENT-16759?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
        "url": "https://github.com/DataDog/datadog-agent/pull/54753",
        "createdAt": "2026-08-11T21:03:46Z",
        "updatedAt": "2026-08-13T03:33:09Z",
        "timestamp": "2026-08-13T03:33:09Z",
        "metrics": {
          "reactions": 2,
          "comments": 4
        },
        "labels": [
          "qa/done",
          "medium review",
          "team/agent-log-pipelines",
          "internal"
        ],
        "author": "mwdd146980",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54755",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Add Observer pipeline telemetry",
        "text": "### What does this PR do? Reshapes Observer telemetry around four experiment questions. #### Ingress and admission - `observer.observations.accepted{kind,source}` counts logs and metrics successfully admitted to the Observer. - `observer.observations.dropped{kind,source}` counts observations rejected because the Observer channel is full. - `observer.logs.accepted_bytes{source}` counts admitted log-content bytes. - `observer.logs.input_rate_limiter.dropped{source,priority}` identifies logs rejected by the Observer ingress rate limiter. - `logs_adaptive_sampler.outcomes{severity,outcome}` counts eligible adaptive-sampling decisions under an applied AAD severity profile. In detection-only mode, `outcome:dropped` means the log would have been dropped. #### Retained state - `observer.log_pattern_extractor.pattern_count` is now a gauge representing all active extractor patterns, including patterns below the metric-emission threshold. - Existing `observer.series.count` and storage capacity/eviction telemetry are retained. #### Detection and output - `observer.detections.detector_emissions{detector,severity}` counts deduplicated detector output before scoring, correlation, and reporting. Severity uses `xlow|low|medium|high|xhigh`. - `observer.scorer.severity{scorer}` reports the current scorer state as `0=low`, `1=medium`, or `2=high`. - Existing `observer.scorer.ewma` and `observer.reports.emitted` are retained. #### Pipeline cost and health - `observer.log_extraction.processing_duration{extractor}` measures only each extractor's `ProcessLog` call in seconds, excluding output handling and storage. The two default-enabled extractors are `log_metrics_extractor` and `log_pattern_extractor`. - Existing in-flight, scheduler, storage, and detector-timing telemetry are retained. - The experiment will use existing Agent and Kubernetes telemetry for CPU and memory rather than introducing duplicate Observer metrics. ### Motivation We want to be able to monitor key parts of the observer pipeline. doc: [Observer Telemetry](https://datadoghq.atlassian.net/wiki/spaces/agent/pages/7070942507/Observer+Telemetry) ### Describe how you validated your changes - Unit coverage for metric types, labels, admission boundaries, extractor timing, pattern state, detector emissions, scorer severity, and adaptive-sampler outcomes. - Kind smoke test using the PR Agent image, verifying emitted metrics and labels. ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54755",
        "createdAt": "2026-08-11T21:17:39Z",
        "updatedAt": "2026-08-13T11:58:24Z",
        "timestamp": "2026-08-13T11:58:24Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "long review",
          "team/agent-log-pipelines",
          "team/agent-build",
          "internal"
        ],
        "author": "Eokye",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54756",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "fix(logs): score timestamps on window density, not run average",
        "text": "### What does this PR do? Changes how the auto multi-line timestamp detector turns a token-transition match into a probability. `MatchProbability` marks every token transition in a line as `1` (the graph has that edge) or `-1` (it does not), runs Kadane's algorithm to find the highest-*sum* run, and then reports the **average over that run** as the probability. Those are answers to two different questions. Extending a run by a stretch that sums positive raises its sum while lowering its average, so Kadane's keeps growing the window past a perfect match and the score that comes back is the diluted one. This PR splits the two roles apart: - `maxSumSubsequence` (Kadane's, unchanged logic) still finds the run and still acts as the gate. A line only gets scored at all if that run is at least `minimumTokenLength` long. This is the check that holds false positives down, so it is kept exactly as-is. - `maxAverageSubsequence` then reports the density of the best window inside that run, which is the probability. The new search only looks at windows shorter than `2*minLength`. Any longer window splits into two parts that each satisfy the minimum, and a weighted average never exceeds both of its parts, so one part always scores at least as high. Comparisons stay in integer arithmetic (`windowSum*bestLen > bestSum*windowLen`) with a single division at the end, the prefix sums live in a stack-allocated power-of-two ring, and the loop stops as soon as an all-match window is found because with `1`/`-1` values nothing can beat it. One incidental cleanup that the split required: the `matchForIndex` closure carried a `lastToken` variable that made it single-pass and order-dependent. The transition at `idx` is fully determined by `ts[idx]` and `ts[idx+1]`, so that state was redundant. Removing it is what lets the two passes share one lookup function. ### Motivation Reported on IIS W3C extended format access logs, which are single-line by specification. Consecutive records were being concatenated into one log and tagged `auto_multiline_detected:true`, which broke the downstream IIS pipeline: grok-parsed fields such as `server_name` and `status_code` received a concatenated block of raw log text instead of extracted values. The mechanism is the dilution above. For a record like: ``` 2026-08-11 10:34:49 W3SVC1 10.1.48.10 GET /svc/v13/core/Consent 443 - 200 0 0 19571 1051 ``` the timestamp matches perfectly, but the client address tokenizes to `DD.D.DD.DD`, which extends the highest-sum run well past the timestamp. The average over that longer run comes to exactly `0.5`, the default `logs_config.auto_multi_line.timestamp_detector_match_threshold`. The comparison is strictly greater-than, so the line is not labelled `startGroup`, falls through to the labeler's default `aggregate`, and is appended to the log before it. Two things about this made it hard to spot from the outside: - It is shape-specific, not format-specific. In the same file, a record with `fe80::b045:52da:3136:3f1c%3` or `192.168.1.1` in that field scores `1.00` and behaves correctly. Only the `DD.D.DD.DD` shape lands on the boundary, so records from one file are affected intermittently. - Landing on exactly `0.5` is a coincidence of this input. The underlying defect scores down any line whose timestamp is followed by a net-positive but imperfect stretch, and other inputs will land elsewhere below the threshold. ### Verification **The pre-existing accuracy dataset is unchanged, line for line.** `TestCorrectLabelIsAssigned` prints a probability per input. I captured that output on `main` and on this branch and diffed the 49 pre-existing rows: ``` lines: before=49 after=49 (no diff) ``` Every true positive still scores what it scored before, and every negative still scores `0.00`. That last part is the load-bearing one: on `main` all 26 negatives score exactly `0.00`, meaning they are rejected by the length gate rather than by a low score. Keeping the gate on the highest-sum run is what preserves that. **The four IIS cases added to the dataset, before and after:** | Input (client address field) | `main` | this PR | |---|---|---| | `10.1.48.10` | 0.50, wrong label | 1.00 | | `10.1.48.10` (second record) | 0.50, wrong label | 1.00 | | `fe80::b045:52da:3136:3f1c%3` | 1.00 | 1.00 | | `192.168.1.1` | 1.00 | 1.00 | On `main` the two `DD.D.DD.DD` rows fail `TestCorrectLabelIsAssigned` with `probability: 0.500000`; with this change all four pass. **New unit tests.** `TestMaxAverageSubsequence` covers the window search directly, including two cases built so that maximizing the sum gives a demonstrably worse answer (a perfect prefix followed by a net-positive suffix, and two runs of matches bridged through the gap between them). `TestMaxAverageSubsequenceSearchesOnlyTheGivenRange` asserts the search never reads outside the run it was handed. `TestExpectedMatch` gains a case at the `MatchProbability` level whose transitions are `1 1 1 1 1 -1 1 1 -1`: averaging over the largest subsequence reports `0.66`, the new path reports `1.00`. `TestMaxSumSubsequence` is the old `TestMaxSubsequence` with its expectations untouched, since Kadane's behaviour is unchanged. **Performance.** This is a per-log-line path, so I added `BenchmarkMatchProbability` and measured both sides (Apple M3 Max, `-benchtime 2000000x -count 5`, mean ns/op): | Case | `main` | this PR | |---|---|---| | `NoTimestamp` (rejected at the gate) | 20 | 18 | | `MaxInputBytes` (rejected at the gate) | 23 | 23 | | `Timestamp` | 67 | 92 | | `TimestampFollowedByAddress` | 82 | 108 | Zero allocations in every case, same as before. Lines rejected at the gate, which is the common case for non-log-start lines, are unaffected. Lines that get scored cost about a third more. The first draft of this was 4-10x slower; the integer comparison, power-of-two ring, and perfect-window early exit are what brought it down, and each is exact rather than approximate. **Full package suite:** `go test ./pkg/logs/internal/decoder/...` fails on `TestUserPatternsJSON` and `TestSingleLineHandlerProcess/Base_case`. Both reproduce identically on a pristine `main` checkout in my environment, so they are pre-existing and unrelated. Everything else passes. ### Additional Notes **Relationship to #54753.** #54753 is a one-character minimal fix for the same customer report: it makes the threshold comparison inclusive (`>=`), so a line landing exactly on the threshold counts as a match. That resolves the IIS symptom because this input happens to land on exactly `0.5`, but it does not address why a perfectly matching timestamp scored `0.5` in the first place. This PR does. **They are alternatives, not a stack** (both touch the same test file), and I would take this one and close #54753. The boundary question #54753 raises is real and independent, though, so it may be worth keeping as a separate follow-up on its own merits. **Not addressed here.** IIS `u_ex*.log` files open with W3C header comment lines (`#Software:`, `#Version:`, `#Date:`, `#Fields:`) that carry no timestamp. Those still get the labeler's default `aggregate` label and are folded into the first real record. That is a separate concern from this scoring defect and is out of scope for this PR. **Threshold semantics unchanged.** `timestamp_detector_match_threshold` keeps its `0.5` default and its meaning. This PR changes what the probability measures, not how it is compared.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54756",
        "createdAt": "2026-08-11T21:41:42Z",
        "updatedAt": "2026-08-13T03:34:58Z",
        "timestamp": "2026-08-13T03:34:58Z",
        "metrics": {
          "reactions": 2,
          "comments": 6
        },
        "labels": [
          "medium review",
          "team/agent-log-pipelines",
          "team/agent-build",
          "internal"
        ],
        "author": "mwdd146980",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54757",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[Backport 7.82.x] Bump google.golang.org/grpc to v1.82.1",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Bump google.golang.org/grpc to v1.82.1 ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54757",
        "createdAt": "2026-08-11T22:23:29Z",
        "updatedAt": "2026-08-12T19:42:33Z",
        "timestamp": "2026-08-12T19:42:33Z",
        "metrics": {
          "reactions": 2,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "long review",
          "internal"
        ],
        "author": "jeremy-hanna",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54758",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "feat(softinv): report OS updates and kernel-mode drivers",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Extends the software inventory beyond installed applications with three collectors, under two new software types, `os_update` and `driver`: | Platform | Type | Source | |---|---|---| | Windows | `driver` | `Win32_SystemDriver` — every registered kernel-mode driver | | Windows | `os_update` | CBS servicing store, packages with `CurrentState == 112` | | macOS | `os_update` | `SystemVersion.plist`, plus `InstallHistory.plist` receipts | **Drivers.** `Win32_SystemDriver` projects the kernel driver services under `HKLM\\SYSTEM\\CurrentControlSet\\Services`, so it covers software-only drivers — EDR minifilters, network and DLP filters — that have no PnP device node and no driver-store INF and so are invisible to `Win32_PnPSignedDriver`. Microsoft inbox drivers are included: inbox driver CVEs and version skew are real signal. The class carries no version or vendor, so both come from the version resource of the image path. Only the numeric `VS_FIXEDFILEINFO` file version is accepted — the `FileVersion` string is routinely decorated or comma-separated, and a driver without a numeric version is dropped rather than guessed at. Image paths are normalized first (`\\??\\`, `\\SystemRoot\\`, `%SystemRoot%`, relative), and display names stored as MUI references (`@<dll>,-<id>`) are resolved with `SHLoadIndirectString`. Identity is the service name, which Windows guarantees unique. The version stays out of it so a bump reads as an update rather than remove + install, and two services sharing one binary (`tcpip`/`tcpip6`) stay distinct entries. Known limitations: UMDF user-mode drivers register no kernel service, and a driver whose service entry is created, loaded, then deleted is invisible — this is an inventory of registered drivers, not of code in the kernel. **Updates.** Identified by KB number where the servicing store records one, by package family otherwise; matching only `Package_for_KB…` would drop monthly cumulative updates (`Package_for_RollupFix~…`) entirely. macOS uses a constant `com.apple.macos` product code for the running system. **Deadline.** Each collector is bounded at 90s in the shared snapshot runner. A timeout is fatal, because a timed-out enumeration is an unknown state and a missing row reads downstream as a removal; zero rows is still a valid result. A hung native call cannot be cancelled — the WMI library takes no context — so a collector that misses its deadline is not started again until it returns. ### Motivation The inventory only covered installed applications, leaving OS patch level and kernel drivers invisible — two of the most useful signals for fleet visibility and compliance. The deadline is a prerequisite rather than a nicety: these sources can block, and a single slow `Collect()` previously stalled the whole snapshot with no upper bound. ### Describe how you validated your changes - Unit tests pass (66 on macOS, including the macOS integration test against a real host with `-test.short=false`); `bazel test //pkg/inventory/software:software_test` passes. - `dda inv linter.go` clean, and clean again under `GOOS=windows`, which type-checks the Windows-tagged files and their tests. - Coverage: deadline and in-flight behaviour, driver path normalization and display-name resolution, the numeric-version requirement, CBS parsing including `RollupFix` and servicing-stack packages, FILETIME conversion, macOS receipt filtering, and entry-ID uniqueness once the new families merge with application entries. - Real-host integration tests, gated on `testing.Short()`: Windows checks collected drivers against the `Services` registry key and logs every driver dropped with its reason; macOS asserts the running-system version matches `sw_vers -productVersion`. - A driver payload from a real Windows host was inspected end to end. It caught two drivers reporting an unresolved MUI reference as their name, fixed in 2741b66. **The Windows-tagged tests are type-checked but have not been executed.** They need a Windows host or CI. The macOS path has been exercised end to end. ### Additional Notes - A fatal error from any single collector still drops the whole snapshot (existing behaviour). Relevant to the new fatal paths: if the CBS key cannot be opened — for instance when system-probe is not elevated — application entries are lost too. - Reporting all kernel drivers adds roughly 250–450 entries per Windows host. Worth a look at payload size before this ships. - Enable with `software_inventory.enabled: true`, which drives both the system-probe module and the core agent component. No status or flare changes were needed, since `populateStatus` already groups by `Source`. - Worst-case snapshot duration is bounded per collector, not globally, so it scales with collector count. A snapshot-wide ceiling would be a separate change.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54758",
        "createdAt": "2026-08-11T23:51:09Z",
        "updatedAt": "2026-08-13T16:11:43Z",
        "timestamp": "2026-08-13T16:11:43Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "long review",
          "team/agent-build",
          "team/windows-products",
          "internal"
        ],
        "author": "sar-shah",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54759",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "fix(flare): mark newly-failing flare tests as flaky",
        "text": "### What does this PR do? Mutes four flare-related tests in `flakes.yaml` that have started failing intermittently in CI. ### Motivation The following tests have been reported failing via CI monitoring, with tracking tickets: - `test/new-e2e/tests/agent-subcommands.TestLinuxFlareSuite/TestFlareDefaultFiles` — [FLREM-153](https://datadoghq.atlassian.net/browse/FLREM-153) - `test/new-e2e/tests/agent-subcommands.TestWindowsDiagnoseSuite/TestDiagnoseOtherCmdPort` — [FLREM-154](https://datadoghq.atlassian.net/browse/FLREM-154) - `comp/core/flare/helpers.TestSave` — [FLREM-148](https://datadoghq.atlassian.net/browse/FLREM-148) - `comp/core/flare/helpers.TestNewFlareBuilder` — [FLREM-155](https://datadoghq.atlassian.net/browse/FLREM-155) `TestLinuxFlareSuite` and `TestWindowsDiagnoseSuite` are testify suites with other subtests (`TestzzzFlareWithAllConfiguration`, `TestDiagnoseInclude`, `TestDiagnoseExclude`) that were never reported as flaky, so the entries are scoped to only the specific subtest confirmed failing in each linked Jira ticket, rather than muting the whole suite. Muting them here unblocks other PRs from spurious CI failures while the underlying flakiness is investigated under those tickets. ### Describe how you validated your changes Validated `flakes.yaml` parses correctly and follows the existing file's format/conventions. Confirmed via `tasks/testwasher.py`/`tasks/libs/testing/flakes.py` (and an empirical run of `consolidate_flaky_failures`) that muting a parent suite name would have also silenced its other subtests, which is why the two suite tests are scoped to their exact failing subtest paths instead. ### Additional Notes [FLREM-153]: https://datadoghq.atlassian.net/browse/FLREM-153?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [FLREM-154]: https://datadoghq.atlassian.net/browse/FLREM-154?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [FLREM-148]: https://datadoghq.atlassian.net/browse/FLREM-148?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [FLREM-155]: https://datadoghq.atlassian.net/browse/FLREM-155?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
        "url": "https://github.com/DataDog/datadog-agent/pull/54759",
        "createdAt": "2026-08-12T06:48:59Z",
        "updatedAt": "2026-08-13T12:07:35Z",
        "timestamp": "2026-08-13T12:07:35Z",
        "metrics": {
          "reactions": 1,
          "comments": 2
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "medium review",
          "internal"
        ],
        "author": "louis-cqrl",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54760",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Errortracking: pass pcs via context rather than record attribute",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? In errortracking log handler, pass the stacktrace pcs via context value rather than log record attributes. ### Motivation Log record attributes are meant to be readable and rendered, while context values are meant to pass extra info, so it's more idiomatic. Would conflict with https://github.com/DataDog/datadog-agent/pull/54394 otherwise. ### Describe how you validated your changes CI ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54760",
        "timestamp": "2026-08-12T12:58:41Z",
        "metrics": {
          "reactions": 2,
          "comments": 7
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "short review",
          "team/agent-runtimes",
          "internal"
        ],
        "author": "pgimalac",
        "assignees": [],
        "change": "new"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54761",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[Backport 7.83.x]  feat(wls): add K8S target through Remote Config",
        "text": "Backport 34e4e15f4654a23d43208c68be99fb2dd67ad4e9 from #54476. ___ feat(autoinstrumentation): wire remote-config SSI policies Subscribe the Cluster Agent auto-instrumentation webhook to the APM_POLICIES remote-config product and layer the delivered SSI policies on top of the configuration baseline at runtime. - TargetMutator now holds a base policy set plus an atomically swappable active set, so remote policies can be hot-reloaded without locking. - Remote policies take precedence over configuration targets (first-match-wins) and support explicit injection denies. - rc_policies.go parses the dd-wls document via dd-policy-engine and applies or clears policies on each remote-config update. This also add a SubscribeWithInitialConfig in RC Client to avoid a potential datarace between registration, initial config and first update if done without a mutex.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54761",
        "createdAt": "2026-08-12T08:04:00Z",
        "updatedAt": "2026-08-13T15:17:03Z",
        "timestamp": "2026-08-13T15:17:03Z",
        "metrics": {
          "reactions": 1,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "team/remote-config",
          "qa/done",
          "backport",
          "bot",
          "team/container-platform",
          "long review",
          "team/injection-platform",
          "team/agent-build",
          "internal"
        ],
        "author": "dd-octo-sts[bot]",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54762",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Improve support for Windows across Invoke tasks",
        "text": "### Motivation https://datadoghq.atlassian.net/browse/ACIX-1826 Address https://github.com/DataDog/datadog-agent/pull/53344#discussion_r3554689696",
        "url": "https://github.com/DataDog/datadog-agent/pull/54762",
        "createdAt": "2026-08-12T08:07:55Z",
        "updatedAt": "2026-08-13T12:32:46Z",
        "timestamp": "2026-08-13T12:32:46Z",
        "metrics": {
          "reactions": 2,
          "comments": 11
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "medium review",
          "team/agent-devx",
          "internal"
        ],
        "author": "ofek",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54764",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "fix(autoscaling): stop informer in test fixture to fix TestPodAutoscalerLocalOwnerObjectsLimit flake",
        "text": "### What does this PR do? Removes the `informer.Start(stopCh)` call from `RunControllerSync` in the autoscaling controller test fixture (`pkg/clusteragent/autoscaling/controller_fake.go`). ### Motivation `TestPodAutoscalerLocalOwnerObjectsLimit` (and `TestPodAutoscalerRemoteOwnerObjectsLimit`) have been [flaking](https://app.datadoghq.com/ci/ci-cd/explorer?query=test_level%3Atest%20%40test.status%3Afail%20%40test.name%3ATestPodAutoscalerLocalOwnerObjectsLimit&agg_m=count&agg_m_source=base&agg_t=count&ci_cd_explorer_tab=tests&citest_explorer_sort=%40duration%2Cdesc&cols=%40test.status%2C%40test.name%2C%40test.suite%2C%40test.is_known_flaky%2C%40duration%2C%40test.service%2Cerror.type&currentTab=overview&eventStack=&fromUser=false&index=citest&refresh_mode=sliding&start=1785920759493&end=1786525559493&paused=false) on `tests_macos_gitlab_amd64` with two symptoms: 1. Assertion failure at `controller_test.go:681`: expected `default/dpa-2` at heap top, got `default/dpa-1` 2. Immediate panic: `mock: I don't know what to return because the method call was unexpected` for `GetPodsForOwner` **Root cause**: `RunControllerSync` called `informer.Start(stopCh)`, which spawns background goroutines that fire `AddFunc` for every object already in the indexer. These callbacks call `c.enqueue(obj)` → `Workqueue.Add(key)` concurrently with the test's own `Workqueue.Add(objectID)`. Since `process()` dequeues exactly one item, it could pick up a background-enqueued key (e.g. `dpa-0`) instead of the intended target (e.g. `dpa-2`). Consequences: - The intended object (`dpa-2`) is never synced → never upserted → never inserted into the heap - Heap state assertions fail (`dpa-1` is at top instead of `dpa-2`) - The wrong object (`dpa-0`) is processed, reaches `validateAutoscaler` (passes, since it was just inserted into the heap), then calls `GetPodsForOwner` for which no mock was set up → panic **Fix**: do not start the informer. The indexer is already pre-seeded via `GetIndexer().Add()` in `newController`, so the lister works correctly without the informer running. The `alwaysReady` synced gate bypasses the cache-sync check. No background goroutines → no concurrent enqueues → deterministic `process()` behavior. ### Describe how you validated your changes - Ran `TestPodAutoscalerLocalOwnerObjectsLimit` 5× with `-count=5`: all pass - Ran the full `./pkg/clusteragent/autoscaling/...` test suite: all green",
        "url": "https://github.com/DataDog/datadog-agent/pull/54764",
        "createdAt": "2026-08-12T08:42:39Z",
        "updatedAt": "2026-08-13T11:30:55Z",
        "timestamp": "2026-08-13T11:30:55Z",
        "metrics": {
          "reactions": 2,
          "comments": 8
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "short review",
          "internal"
        ],
        "author": "chouetz",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54765",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Update integrations-core digest to 1524101",
        "text": "This PR contains the following updates: | Package | Update | Change | |---|---|---| | integrations-core ([changelog](https://redirect.github.com/DataDog/integrations-core/compare/c5443962a337c8283f8b0cab8edbd519fc151c30..1524101b8640b62e6e6f8988f311235208695fad)) | digest | `c544396` → `1524101` | --- > [!WARNING] > Some dependencies could not be looked up. Check the [Dependency Dashboard](../issues/33469) for more information. --- ### Configuration 📅 **Schedule**: (in timezone Europe/Paris) - Branch creation - Between 02:00 AM and 06:59 AM, only on Monday and Wednesday (`* 2-6 * * 1,3`) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/DataDog/datadog-agent). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0NC4yNC4wIiwidXBkYXRlZEluVmVyIjoiNDQuMjQuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiY2hhbmdlbG9nL25vLWNoYW5nZWxvZyIsImRlcGVuZGVuY2llcyIsInFhL25vLWNvZGUtY2hhbmdlIl19-->",
        "url": "https://github.com/DataDog/datadog-agent/pull/54765",
        "timestamp": "2026-08-12T12:58:19Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "dependencies",
          "qa/no-code-change",
          "team/agent-delivery",
          "short review",
          "team/agent-integrations",
          "team/agent-build",
          "internal"
        ],
        "author": "renovate[bot]",
        "assignees": [],
        "change": "new"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54767",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "aix: populate datadog.yaml from env vars in the config script",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Seeds `datadog.yaml` from `DD_API_KEY`/`DD_SITE`/`DD_HOSTNAME`/`DD_TAGS`/`DD_ENV`/`DD_INFRASTRUCTURE_MODE`/proxy env vars on first install, mirroring the Linux install script. ### Motivation installp has no mechanism to pass parameters at install time, so this is the only way to configure the agent unattended on AIX. ### Describe how you validated your changes Ran all creation/skip/`DD_INSTALL_ONLY` scenarios in a sandbox on a real AIX 7.3 host and confirmed the resulting YAML and file permissions. ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54767",
        "createdAt": "2026-08-12T09:07:16Z",
        "updatedAt": "2026-08-13T16:48:53Z",
        "timestamp": "2026-08-13T16:48:53Z",
        "metrics": {
          "reactions": 1,
          "comments": 1
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "medium review",
          "team/agent-runtimes",
          "team/agent-build",
          "internal"
        ],
        "author": "pgimalac",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54768",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Remove visual_studio.bzl",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? This PR fully eliminates usage of `visual_studio.bzl` that was just pinning version of a local MSVC installation. #54718 introduced a fully hermetic MSVC toolchain, as well as MSBuild tool and migrated cpython build process to it. This PR handles datadog-interop.dll, the last consumer of `msbuild` that was relying on `visual_studio` repository rule. - Remove `visual_studio.bzl` - Introduce `pkg/inventory/software/main_windows_test.go` to properly wire interop DLL into tests under Bazel. - Remove `-AsArray` from `pkg/inventory/software/integration_windows_test.go` as it is only supported in PowerShell 6+, for instance, my DD issued Windows laptop has 5.1, so this simply doesn't `work. - Enable `software_test` in CI. From now on it will be executed under `//...`",
        "url": "https://github.com/DataDog/datadog-agent/pull/54768",
        "createdAt": "2026-08-12T09:55:44Z",
        "updatedAt": "2026-08-13T12:21:53Z",
        "timestamp": "2026-08-13T12:21:53Z",
        "metrics": {
          "reactions": 2,
          "comments": 7
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "medium review",
          "team/agent-devx",
          "team/agent-build",
          "team/windows-products",
          "internal"
        ],
        "author": "JSGette",
        "state": "closed",
        "assignees": [
          "JSGette"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54769",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Split network-devices section in it's own file and fix ID links",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Split netowrk-devices section in it's own file and fix ID links",
        "url": "https://github.com/DataDog/datadog-agent/pull/54769",
        "createdAt": "2026-08-12T10:03:17Z",
        "updatedAt": "2026-08-13T16:50:54Z",
        "timestamp": "2026-08-13T16:50:54Z",
        "metrics": {
          "reactions": 1,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "team/agent-apm",
          "team/agent-security",
          "team/remote-config",
          "team/ebpf-platform",
          "team/agent-cspm",
          "qa/done",
          "team/container-platform",
          "long review",
          "team/container-integrations",
          "team/agent-runtimes",
          "team/agent-configuration",
          "team/agent-log-pipelines",
          "team/container-experiences",
          "team/agent-build",
          "team/kubernetes-experiences",
          "team/action-platform",
          "internal",
          "team/network-device-monitoring-core",
          "team/gpu-monitoring-agent",
          "team/fleet-remediation",
          "team/fleet-automation"
        ],
        "author": "hush-hush",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54770",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Clean bazelignore from invalid folder path",
        "text": "### What does this PR do? This path was added by mistake in previous PR and correspond to a local git worktree.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54770",
        "createdAt": "2026-08-12T10:08:12Z",
        "updatedAt": "2026-08-12T14:33:13Z",
        "timestamp": "2026-08-12T14:33:13Z",
        "metrics": {
          "reactions": 2,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "short review",
          "team/agent-build",
          "internal"
        ],
        "author": "hush-hush",
        "state": "closed",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54772",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Manage MSYS2 via Bazel",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Let Bazel manage MSYS2 installation. By default, Bazel will check if `bash` exists in `C:\\tools\\msys64`. In this case Bazel will just keep using it as is. If `bash` hasn't been found there or force install is requested via envvar Bazel will download MSYS2 and autotools stack and install it in `C:\\tools\\msys64` unless the install location is overwritten. There are 2 reasons why we decided to use `C:\\tools` as a default installation path: - That's what we already use in build images. This way our happy path keeps working and has no effect on cache hit rate, meaning that rebuilding openssl or python on Windows with Bazel managed MSYS2 will utilize the same cache regardless of currently installed MSYS2 version. This is somewhat incorrect but acceptable, given Windows has no sandboxing at all and everything is running `local`. - If users have an installation os MSYS2 already they can keep using it (as `C:\\tools` isn't a default installation path), Bazel will use its own copy that can, however, be used outside of Bazel for other activities. #### Things to keep in mind - As mentioned above, it is not technically correct to let Bazel use whatever MSYS2 is already present in `C:\\tools`, because in this case we don't treat autotools as build inputs, therefore, potentially introducing cache poisoning issues. This is, however, more of a hypothetical risk rather than the real one. We will make `rules_foreign_cc` make aware of `make` and co as action inputs in one of the follow ups. In the meantime we allow everyone to use the layout that they currently have with no action required. - We will enforce MSYS2 installation later on, so this should be properly documented and communicated to the users before rollout.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54772",
        "timestamp": "2026-08-12T13:44:48Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "medium review",
          "team/agent-devx",
          "team/agent-build",
          "internal"
        ],
        "author": "JSGette",
        "assignees": [],
        "change": "new"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54773",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[anomalydetection] Test: per source scorer",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Config: ```yaml anomaly_detection: tailer_match_telemetry: enabled: true report_interval: 5m max_tracked_metric_series: 1000 max_event_metric_items: 20 max_event_log_scopes: 20 reporting: events: enabled: true ``` ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54773",
        "createdAt": "2026-08-12T11:32:16Z",
        "updatedAt": "2026-08-13T07:06:49Z",
        "timestamp": "2026-08-13T07:06:49Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "long review",
          "team/agent-runtimes",
          "team/agent-build",
          "internal",
          "team/fleet-automation"
        ],
        "author": "CelianR",
        "state": "closed",
        "assignees": [
          "CelianR"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54774",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[CWS] Fix: handle activity dump endpoint host that already embeds a port",
        "text": "### What does this PR do? Fixes CWS activity dump uploads to dual-shipped `additional_endpoints` whose `host` already includes a port (e.g. `cws-intake.datadoghq.com.:443`). `GetEndpointURL` was appending the port a second time, producing a malformed `[host:port]:port` authority that failed URL parsing — so every upload to that endpoint failed with an `invalid port` error. The host is now split before joining, so an embedded port is honored instead of duplicated. An explicitly configured port still wins, and bare IPv6 literals are untouched. ### Motivation In prod, CWS activity dumps were failing to reach the secondary (dual-ship) endpoint.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54774",
        "createdAt": "2026-08-12T11:37:04Z",
        "updatedAt": "2026-08-13T14:23:51Z",
        "timestamp": "2026-08-13T14:23:51Z",
        "metrics": {
          "reactions": 2,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "team/agent-security",
          "qa/done",
          "short review",
          "team/agent-build",
          "internal"
        ],
        "author": "kovagsm",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54775",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "CONTINT-5539 - use correct kind version and kubeadm version",
        "text": "### What does this PR do? In order to run kubernetes version > v1.37.0 we need to use kind v0.32.0 at least and use kubemad API version v1alpha4. generate the correct kubeadm config file depending on the requested version. ### Motivation fix flaky test ### Describe how you validated your changes run the latest job with kube v1.37.0-rc.0 ✅ run the latest job with kube v1.36.3 ✅ ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54775",
        "createdAt": "2026-08-12T12:05:58Z",
        "updatedAt": "2026-08-12T16:24:55Z",
        "timestamp": "2026-08-12T16:24:55Z",
        "metrics": {
          "reactions": 1,
          "comments": 2
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "medium review",
          "team/agent-devx",
          "internal"
        ],
        "author": "lavigne958",
        "state": "open",
        "assignees": [
          "lavigne958"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54776",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Force LF line endings for text files by default on gitattributes",
        "text": "### What does this PR do? This PR sets a catch-all .gitattributes line that forces all files that git identifies as \"text\" (based on `text=auto`) to be checked out with LF endings by default (i.e. anything not matched by any other line in .gitattributes), regardless of platform and `core.autocrlf` setting. The PR also adjusts the .gitattributes file such that: - Existing individual settings of `text=auto eol=lf` are removed as they're covered by the new catch-all line. - It adds entries that allow us to make the change to .gitattributes without having to change any file as part of the same change. This means adding exceptions matching files that were identified as being stored with CRLF endings in git, as well as a golden file for a test which would fail under this new normalization. ### Motivation The original reason for this is that I was getting cache misses on Windows when trying to build python (`bazel build @cpython//:python_win`), which with help of execution logs I identified as coming from differences in the file https://github.com/DataDog/datadog-agent/blob/main/deps/cpython/redacted_compat.h. CI converts this file to add CRLF endings, whereas my local machine had at some point disabled `autocrlf` which meant my local file was using LF endings. Enabling [core.autocrlf](https://git-scm.com/docs/git-config#Documentation/git-config.txt-coreautocrlf) causes git to automatically decide, for files not matching any pattern in our .gitattributes file, whether to \"translate\" a file to using CRLF depending on the platform (on Windows, basically). The core rationale for this change is that it's extremely undesirable to have git config, which can differ from machine to machine, influence the bytes that you get on a checkout. This is even more so in a Bazel-enabled repo, where hashes of files are used everywhere for identity (caching, lockfiles, etc.). This change targets that behavior directly by ensuring we get no discrepancies in the future. I think this is justified even if the current default on windows git installs seems to enable autocrlf, because it implies our setup relying on something that is out of our control. ### Describe how you validated your changes Passing tests, confirmed `git add --renormalize .` doesn't touch anything, and `git ls-files --eol` reports the expected results. ### Additional Notes Existing checkouts won't automatically get the line endings matching the .gitattributes changes. For that, on a clean tree, something like this might be needed: ``` git rm --cached -r . git reset --hard HEAD ``` I'll be removing the individual exceptions in chunks, to limit the scope of the changes and make them easier to revert.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54776",
        "createdAt": "2026-08-12T12:21:26Z",
        "updatedAt": "2026-08-13T17:31:26Z",
        "timestamp": "2026-08-13T17:31:26Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "medium review",
          "team/agent-devx",
          "team/agent-build",
          "internal"
        ],
        "author": "alopezz",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54777",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "chore(devx): clean up and align CODEOWNERS",
        "text": "### What does this PR do? Cleans up `.github/CODEOWNERS`: - Removes two exact-duplicate rules (`/.agents/skills/create-runtime-setting/SKILL.md` and `/pkg/collector/`). - Adds ownership for files that had no matching CODEOWNERS rule: `/datadog-agent.map` (`@DataDog/agent-log-pipelines`), `/flakes.yaml` (`@DataDog/agent-devx`), `/k8s_versions.json` (`@DataDog/container-integrations`), `/rust/license-tool.toml`, and `/examples/` (both marked \"do not notify anyone\", consistent with neighboring LICENSE-style entries). - Aligns the owner columns within each blank-line-separated block for readability. The auto-generated `# BEGIN COMPONENTS` / `# END COMPONENTS` block (managed by `dda inv lint-components`) was left untouched, and the bottom-to-top match ordering of rules was preserved everywhere — no ownership semantics changed beyond the additions/removals above. ### Motivation `.github/CODEOWNERS` had accumulated duplicate rules and a handful of files with no owning team, plus inconsistent spacing between owner columns that made the file harder to scan and diff. ### Describe how you validated your changes - Verified every pattern in the file matches at least one path still present in the repo (no stale rules). - Verified every tracked file in the repo now matches at least one CODEOWNERS rule (0 unmatched, down from 14). - Diffed the file with all whitespace normalized to confirm the column-alignment pass didn't change any pattern or owner content.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54777",
        "createdAt": "2026-08-12T12:31:25Z",
        "updatedAt": "2026-08-13T08:36:06Z",
        "timestamp": "2026-08-13T08:36:06Z",
        "metrics": {
          "reactions": 2,
          "comments": 1
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "long review",
          "internal"
        ],
        "author": "chouetz",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54778",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Add design spec for e2ectl interactive dashboard",
        "text": "Documents the approved design for a cross-env dashboard and per-env action loop in e2ectl's interactive mode, plus the generalization needed to keep cmd/e2ectl provisioner/installer-agnostic (moving config-drift interpretation into the Installer interface). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com><!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54778",
        "createdAt": "2026-08-12T12:43:04Z",
        "updatedAt": "2026-08-13T08:58:43Z",
        "timestamp": "2026-08-13T08:58:43Z",
        "metrics": {
          "reactions": 1,
          "comments": 1
        },
        "labels": [
          "long review",
          "team/agent-devx",
          "team/agent-build",
          "internal"
        ],
        "author": "KevinFairise2",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54779",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Remove unused SyncCapture",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Remove unused `SyncCapture` code in log package. ### Motivation This is currently dead code. Discussed with the team which introduced this and it has been refactored so this is not needed anymore. ### Describe how you validated your changes No functional change expected. ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54779",
        "createdAt": "2026-08-12T13:05:34Z",
        "updatedAt": "2026-08-13T13:27:55Z",
        "timestamp": "2026-08-13T13:27:55Z",
        "metrics": {
          "reactions": 2,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "short review",
          "team/agent-runtimes",
          "internal"
        ],
        "author": "pgimalac",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54780",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Use bazel driven windows resources in windows_resources.py",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? `agent.build` task fails unable to find `windmc` tool in case it isn't accessible in `PATH`. This change handles this by letting tasks use `windmc` managed by Bazel. In this case we ensure that, regardless of the state of the build environment, `windmc` is there and accessible.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54780",
        "createdAt": "2026-08-12T13:23:33Z",
        "updatedAt": "2026-08-13T13:31:32Z",
        "timestamp": "2026-08-13T13:31:32Z",
        "metrics": {
          "reactions": 2,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "short review",
          "team/windows-products",
          "internal"
        ],
        "author": "JSGette",
        "state": "closed",
        "assignees": [
          "JSGette"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54781",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[ACTP][e2e][incident-59050] restore fake runner keys injection for PAR e2e test",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? \"revert\" of https://github.com/DataDog/datadog-agent/pull/54709 Try to reintroduce the fake intake usage for RC keys instead of `DD_INTERNAL_PAR_SKIP_TASK_VERIFICATION` The extra latency (which is a separate problem to solve with RC's help) seems to only appear if the PAR starts AFTER the core agent. By restarting the core agent we ### Motivation Trying to get rid of DD_INTERNAL_PAR_SKIP_TASK_VERIFICATION ### Describe how you validated your changes CI Ran, need to see if it does not become [flaky again](https://app.datadoghq.com/ci/ci-cd/explorer?query=ci_level%3Ajob%20%40ci.pipeline.name%3ADataDog%2Fdatadog-agent%20%40git.branch%3Amain%20%40ci.job.name%3A%22new-e2e-privateactionrunner%22%20%40ci.status%3Aerror&agg_m=%40ci.job.name&agg_m_source=base&agg_t=cardinality&analyticsOptions=%5B%22line%22%2C%22dog_classic%22%2Cnull%2Cnull%2C%22value%22%5D&ci_cd_explorer_tab=pipelines&cipipeline_explorer_sort=time%2Cdesc&colorByAttr=meta%5B%27ci.stage.name%27%5D&cols=%40git.branch%2C%40ci.status%2Ctimestamp%2C%40ci.pipeline.name%2C%40ci.stage.name%2C%40ci.job.name%2C%40duration%2C%40ci.pipeline.id%2C%40git.repository.name&currentTab=trace&fromUser=false&graphType=flamegraph&index=cipipeline&mode=sliding&refresh_mode=sliding&sort=time&spanViewType=metadata&step=86400000&tab=overview&viz=stream&start=1781426607918&end=1786610607918&paused=false) ### Additional Notes See #incident-59050",
        "url": "https://github.com/DataDog/datadog-agent/pull/54781",
        "createdAt": "2026-08-12T14:15:10Z",
        "updatedAt": "2026-08-13T15:03:38Z",
        "timestamp": "2026-08-13T15:03:38Z",
        "metrics": {
          "reactions": 2,
          "comments": 1
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "short review",
          "team/action-platform",
          "internal"
        ],
        "author": "dd-gplassard",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54782",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Add a typed file provisioner, to allow using existing infrastructure more easily",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Create a typed file provisioner. To use an environment already provisioned inside a test ### Motivation We want to separate provisioning from test execution, that part gives us a first step to be able to first provision the environment outputing, a state file and then reusing that existing environment directly in the test ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54782",
        "createdAt": "2026-08-12T14:18:45Z",
        "updatedAt": "2026-08-13T07:22:21Z",
        "timestamp": "2026-08-13T07:22:21Z",
        "metrics": {
          "reactions": 1,
          "comments": 11
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "medium review",
          "team/agent-devx",
          "team/agent-build",
          "internal"
        ],
        "author": "KevinFairise2",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54783",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Keep injected redacted_compat.h file out of the windows python's build inputs",
        "text": "### What does this PR do? It removes the `redacted_compat.h` file out of the sources for the Python build on Windows, such that it doesn't get used for cache computation. ### Motivation I didn't get remote cache hits on a local checkout with git core.autocrlf disabled (see also https://github.com/DataDog/datadog-agent/pull/54776) due to this specific file. Since the file is only intended for the `configure_make` rule that builds Python on Linux / macOS, we can simply remove the file from inputs to mitigate the problem (regardless of whether we go with https://github.com/DataDog/datadog-agent/pull/54776 or any other similar more general solution). ### Describe how you validated your changes CI. ### Additional Notes Due to the lack of windows sandboxing, the excluded sources for the rule are actually visible to the build action, so there's no guarantee that it doesn't get used by it. However, given that it's a file that we introduce ourselves and not looked at by Python's build system, it's fairly safe to assume that in practice this file doesn't cause any difference to the build outputs.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54783",
        "createdAt": "2026-08-12T14:27:15Z",
        "updatedAt": "2026-08-12T19:29:49Z",
        "timestamp": "2026-08-12T19:29:49Z",
        "metrics": {
          "reactions": 2,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "short review",
          "team/agent-build",
          "internal"
        ],
        "author": "alopezz",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54784",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "feat(fleet): Report installer status through local API",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Replaces the Fleet Automation process/service check in core Agent status with the installer local API. The local API wire contract and client now live in the updater components instead of `pkg/fleet/daemon`. Core Agent consumers receive a status-only client with a two-second request deadline, a 1 MiB response limit, disabled keep-alives, and no dependency on the installer daemon package. The existing installer CLI methods and wire format remain compatible. Agent status keeps the existing Fleet booleans and adds a stable `installerStatus` object containing reachability and sorted package state. Text and HTML output include non-empty package/configuration versions and task details. Errors degrade to `reachable: false` without failing status generation, and the secrets public key is never exposed. The obsolete `daemonchecker` component is removed. Existing Linux and Windows E2E coverage now checks the default unreachable case and verifies that a running core Agent can read installer package state during Fleet upgrade setup. ### Motivation The previous check only established whether the installer process or service appeared to be running. It could not distinguish an inaccessible installer API or expose the package, configuration, and task state needed to troubleshoot Fleet Automation operations. Reusing the existing local API provides the actual communication boundary and avoids introducing a second inventory/status API. Listener permissions and ACLs are intentionally unchanged and were validated separately. ### Describe how you validated your changes - `bazel test //comp/fleetstatus/impl:impl_test //comp/updater/localapiclient/impl:impl_test //pkg/fleet/daemon:daemon_test` - `bazel build --platforms=@rules_go//go/toolchain:windows_amd64 //comp/updater/localapiclient/impl:impl` - `dda inv agent.build --build-exclude=systemd` - `dda inv agent.build --flavor=iot --build-exclude=systemd` - Targeted `dda inv linter.go` for the changed core packages - `dda inv components.lint-components` - Verified `somepath(//comp/updater/localapiclient/impl:impl, //pkg/fleet/daemon:daemon)` is empty The legacy `dda inv test` wrapper could not start tests locally because its bundled Go 1.26.4 is older than the Go 1.26.5 required by `go.work`; the equivalent hermetic Bazel suites above pass. Full E2E compilation also exhausted local disk while compiling Pulumi dependencies, so the added provisioned Linux/Windows coverage remains for CI. ### Additional Notes Automated pre-PR review identified and prompted fixes for two issues before push: status reads no longer wait behind long-running installer operations, and Windows pipe dialing retains the previous two-second bound for mutation requests without an existing deadline.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54784",
        "createdAt": "2026-08-12T14:34:35Z",
        "updatedAt": "2026-08-12T19:12:47Z",
        "timestamp": "2026-08-12T19:12:47Z",
        "metrics": {
          "reactions": 1,
          "comments": 6
        },
        "labels": [
          "qa/done",
          "long review",
          "team/agent-runtimes",
          "team/agent-devx",
          "team/agent-build",
          "team/windows-products",
          "internal",
          "team/fleet-remediation"
        ],
        "author": "arbll",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54785",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Add telemetry to dogstatsd http server",
        "text": "### What does this PR do? Add telemetry to dogstatsd http server ### Motivation Track usage and performance of the new component ### Describe how you validated your changes Unit tests. Run agent with dogstatsd http enabled and metric filter configured. Check agent telemetry to include expected metrics. ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54785",
        "createdAt": "2026-08-12T14:39:56Z",
        "updatedAt": "2026-08-13T12:16:56Z",
        "timestamp": "2026-08-13T12:16:56Z",
        "metrics": {
          "reactions": 2,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "medium review",
          "team/agent-metric-pipelines",
          "team/agent-build",
          "internal"
        ],
        "author": "vickenty",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54786",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Pedro.cordeiro/macos ec2 snapshot poc 2",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54786",
        "createdAt": "2026-08-12T15:08:50Z",
        "updatedAt": "2026-08-12T16:09:31Z",
        "timestamp": "2026-08-12T16:09:31Z",
        "metrics": {
          "reactions": 1,
          "comments": 2
        },
        "labels": [],
        "author": "PedroCordeiroDataDog",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54787",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Pedro.cordeiro/macos ec2 snapshot poc 3",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54787",
        "createdAt": "2026-08-12T15:09:00Z",
        "updatedAt": "2026-08-12T16:01:59Z",
        "timestamp": "2026-08-12T16:01:59Z",
        "metrics": {
          "reactions": 1,
          "comments": 2
        },
        "labels": [],
        "author": "PedroCordeiroDataDog",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54788",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[NETPATH-1108] Remove flaky RC re-poll gate from Dynamic Path e2e test Setup",
        "text": "### What does this PR do? Removes the `SetupSuite` gate in `TestHostTrafficDynamicPathSuite` that waited for the agent's Remote Config poll counter to increase within 2 minutes of pushing the dynamic config. JIRA: [NETPATH-1108](https://datadoghq.atlassian.net/browse/NETPATH-1108) ### Motivation `TestHostTrafficDynamicPathSuite` has been intermittently failing on `main` (~105 failures / ~4,150 runs over 30 days, ~2.5%) since it was first introduced, always aborting in `SetupSuite` with: > `agent did not poll Remote Config after the dynamic config was added` The gate asserted the agent's RC poll counter strictly increment within a 2-minute window. But the agent's RC refresh cadence is `defaultRefreshInterval` (1m) plus exponential backoff on transient poll errors (`pkg/config/remote/service/service.go`), with a backoff ceiling of 2–5 minutes. A short run of transient errors legitimately pushes the next poll past the 2-minute deadline, failing the assertion and tearing down the entire suite before the real test runs. This is a fragile timing assumption in the test, not an agent regression. ### Describe how you validated your changes The gate is redundant: `TestHostTrafficDynamicNetworkPath` already waits (up to 5 minutes) for the RC-admitted network path to appear in fakeintake, which inherently proves the agent polled and applied the config — so removing the setup gate loses no coverage. The initial \"agent has polled at all\" check (`NotZero` polls) is kept, as it is not the flaky assertion. `go vet` passes on the package. E2E will exercise the change in CI.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54788",
        "createdAt": "2026-08-12T15:59:08Z",
        "updatedAt": "2026-08-12T16:52:48Z",
        "timestamp": "2026-08-12T16:52:48Z",
        "metrics": {
          "reactions": 1,
          "comments": 2
        },
        "labels": [
          "short review",
          "team/windows-products",
          "team/network-path",
          "internal"
        ],
        "author": "ken-schneider",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54789",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "feat(gpu): Add experimental Apple Silicon monitoring",
        "text": "### What does this PR do? Adds an experimental Apple Silicon backend to the standard `gpu` core check. The macOS implementation reads AGX device properties through unprivileged public IOKit APIs and emits only Apple-scoped metrics: - `gpu.apple.device.count` - `gpu.apple.core.count` - `gpu.apple.device.utilization` - `gpu.apple.system_memory.allocated` - `gpu.apple.system_memory.in_use` The system-memory metrics are explicitly defined as Apple driver-reported system memory associated with GPU clients; they do not claim discrete VRAM or total unified-memory semantics. The change keeps the Linux/NVML implementation unchanged, adds vendor-aware metric specifications and Apple-specific tag requirements, and keeps iOS on the unsupported stub. ### Motivation The Agent's GPU check was previously available only for Linux/NVIDIA systems. Apple Silicon hosts running Metal workloads—such as local inference, rendering, and macOS CI—need basic GPU inventory, activity, and GPU-client memory visibility. Apple does not provide an NVML-equivalent public system API. This implementation deliberately uses only IOKit registry properties available without root and treats missing or changed properties as optional. It avoids private frameworks, `powermetrics`, subprocess parsing, and mapping Apple values onto NVIDIA-shaped metric names. ### Describe how you validated your changes - `dda inv test --targets=./pkg/collector/corechecks/gpu` - `dda inv linter.go --targets=./pkg/collector/corechecks/gpu` - `bazel test //pkg/collector/corechecks/gpu:gpu_test_base //pkg/collector/corechecks/gpu/spec:spec_test_base --test_output=errors` - `bazel run //bazel/buildifier` - `dda inv schema.lint` - `dda inv agent.build --build-exclude=systemd` - Ran the built Agent's standard `gpu` check on an Apple M5 Pro and verified that exactly the five `gpu.apple.*` metrics were emitted. - Generated sustained Metal load using an already-local 35B Ollama model. Device utilization increased from a 39.4% mean at baseline to 88.9% under load, then returned to 36.8%. Driver-reported allocated/in-use system memory rose from about 5.1/0.8–1.1 GB to about 35.1/30.6–31.3 GB, then returned after model unload. ### Additional Notes The AGX registry property names are undocumented Apple driver data, so the feature is marked experimental and every property is optional. There is not yet an Apple Silicon fakeintake E2E environment; local QA covered the real packaged Agent registration, native reader, sender output, and hardware behavior.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54789",
        "createdAt": "2026-08-12T16:07:48Z",
        "updatedAt": "2026-08-12T23:03:06Z",
        "timestamp": "2026-08-12T23:03:06Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "team/ebpf-platform",
          "qa/done",
          "long review",
          "team/agent-devx",
          "team/agent-build",
          "internal",
          "team/gpu-monitoring-agent",
          "team/fleet-automation"
        ],
        "author": "scottopell",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54790",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "ci: default to GIT_DEPTH=1, full clone for jobs needing git history",
        "text": "### What does this PR do? Sets a repo-wide `GIT_DEPTH: 1` default in `.gitlab-ci.yml` to speed up job checkouts, and adds `GIT_DEPTH: 0` overrides on the jobs whose scripts (or the invoke tasks they call) run history-dependent git operations: - `.gitlab/build/source_test/golang_deps_diff.yml` (`golang_deps_diff` — `git merge-base` via `go-deps.diff`) - `.gitlab/test/e2e/e2e.yml` (`.new_e2e_template` — `git merge-base` for `--impacted` test selection) - `.gitlab/.pre/ci_configuration.yml` (`test_gitlab_compare_to`, `compute_gitlab_ci_config`, `lint_github_actions_shellcheck` — all use `git merge-base`) - `.gitlab/build/binary_build/fakeintake.yml` (`fakeintake_check_version_bump` — `git merge-base` + reading a file at the merge-base commit) - `.gitlab/deploy/internal_kubernetes_deploy/internal_kubernetes_deploy.yml` (`notify-slack` — `git log` over a commit range for the changelog) - `.gitlab/build/lint/technical_linters.yml` (`lint_releasenotes_rst` — `git merge-base`) - `.gitlab/.pre/setup/setup.yml` (`setup_agent_version` — `git describe --tags`, needs full history to find the nearest tag) Jobs that already had an explicit `GIT_DEPTH`/`GIT_STRATEGY` override (`regression_detector.yml`, `static_quality_gate.yml`, `files_inventory_check.yml`, the Windows bazel runner) were left untouched. The Windows `GIT_STRATEGY: \"clone\"` templates in `deploy/conditions.yml` / `agent7.yml` are unrelated to git history (they work around CIEXE-1152 for cancelled jobs) and don't need `GIT_DEPTH: 0`. ### Motivation Shallow clones reduce checkout time/bandwidth across the pipeline, which runs on every commit/PR. ### Describe how you validated your changes - Validated YAML syntax of all changed files. - Manually traced every git operation (`git merge-base`, `git log` ranges, `git describe --tags`) reachable from CI jobs, including through the invoke tasks they call (`tasks/libs/common/git.py`, `tasks/gotest.py`, `tasks/libs/releasing/version.py`, etc.) to confirm which jobs need full history. - Ran the `gitlab-configuration` pre-push linter (`dda inv linter.full-gitlab-ci -t main --pre-push-linters --fail-fast`) locally — passed with pre-existing warnings unrelated to this change. ### Additional Notes **Known risk, intentionally not addressed here:** the Linux/macOS/Windows unit-test jobs use `--only-impacted-packages` on essentially every dev-branch pipeline (via `FAST_TESTS=true`), which calls `git merge-base` through `tasks/gotest.py:get_impacted_packages` with **no error handling**. Under `GIT_DEPTH=1`, if the merge-base predates the 1-commit shallow window, this would hard-fail the test job rather than gracefully falling back to running all tests. This wasn't addressed in this PR to avoid setting `GIT_DEPTH: 0` on the largest and most CI-time-costly category of jobs, which would defeat much of the purpose of this change. Options going forward: harden the fallback in `get_impacted_packages` (deepen fetch or fall back to \"run all tests\" on merge-base failure), or scope `GIT_DEPTH: 0` to those jobs if the risk materializes.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54790",
        "createdAt": "2026-08-12T17:04:33Z",
        "updatedAt": "2026-08-13T14:41:40Z",
        "timestamp": "2026-08-13T14:41:40Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "team/agent-delivery",
          "medium review",
          "team/container-integrations",
          "team/agent-devx",
          "team/agent-build",
          "team/windows-products",
          "internal"
        ],
        "author": "KevinFairise2",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54791",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[MVP][CONTP-1967] feat(ddi): Support custom targer refs for DDI checks and logs",
        "text": "### What does this PR do? Adds configurable workload targets for DatadogInstrumentation checks and logs. The Cluster Agent now: - Builds a registry from built-in workloads and `instrumentation_crd_controller.custom_workload_targets`. - Resolves Pod controller ownership through configured `via` resources with the dynamic Kubernetes client. - Streams resolved target identity, including group, version, kind, namespace, name, and UID, to Node Agents through the Kubernetes metadata stream. - Uses `container.pod.resolved_targets` in CEL selectors for custom targets while preserving the existing `rootowner` path for built-in targets. - Starts the Pod workloadmeta store when custom workload targets are configured. For example, an OpenKruise `AdvancedCronJob` can be configured as a target reached through its intermediate `Job`: ```yaml instrumentation_crd_controller: custom_workload_targets: - target: apiVersion: apps.kruise.io/v1alpha1 kind: AdvancedCronJob resource: advancedcronjobs via: - apiVersion: batch/v1 kind: Job resource: jobs ``` Direct owners such as `CloneSet` use the same format without `via`. ### Motivation [CONTP-1967](https://datadoghq.atlassian.net/browse/CONTP-1967) DatadogInstrumentation currently relies on a hard-coded workload allowlist and root-owner metadata. That excludes arbitrary workload CRs, cannot distinguish identical kinds across API groups, and does not support ownership chains such as Pod to Job to AdvancedCronJob. This proof of concept makes workload support data-driven while keeping the existing behavior for built-in Kubernetes workloads. [CONTP-1967]: https://datadoghq.atlassian.net/browse/CONTP-1967?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
        "url": "https://github.com/DataDog/datadog-agent/pull/54791",
        "createdAt": "2026-08-12T17:28:19Z",
        "updatedAt": "2026-08-12T17:36:59Z",
        "timestamp": "2026-08-12T17:36:59Z",
        "metrics": {
          "reactions": 1,
          "comments": 2
        },
        "labels": [
          "team/container-platform",
          "long review",
          "team/container-integrations",
          "team/agent-runtimes",
          "team/agent-build",
          "internal",
          "team/fleet-automation"
        ],
        "author": "Mathew-Estafanous",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54792",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Increase Quality Gate memory thresholds for ADP pre-flight mode",
        "text": "ADP pre-flight mode (#54175) adds 23 MiB to peak PSS on every workload that exercises a default Agent configuration. Pre-flight is enabled by default and runs ADP for 90 seconds at startup in anticipation of turning it on by default. This PR re-baselines all Quality Gate memory thresholds. | Gate | Old (MiB) | Observed (MiB) | New (MiB) | |---|---|---|---| | `quality_gate_idle` | 154 | 174.89 | 178 | | `quality_gate_logs` | 195 | 216.59 | 229 | | `quality_gate_metrics_logs` | 430 | 417.52 | 439 | | `quality_gate_idle_all_features` | 512 | 524.74 | 538 | | `quality_gate_security_idle` | 330 | 330.55 | 335 | | `quality_gate_security_no_fs_load` | 320 | 319.31 | 343 | | `quality_gate_security_mean_fs_load` | 310 | 309.05 | 314 | | `quality_gate_private_action_runner` | 75 | 74.04 | 76 | Observed values come from `total_pss_bytes` on the comparison variant of last night's Quality Gate run. Bounds are sized to 1% over observed + 1 MiB, with the exception of `logs`, `metrics_logs`, and `security_no_fs_load`. Those three are sized against their three-week peak to account for variability that is not currently captured every night.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54792",
        "createdAt": "2026-08-12T17:54:22Z",
        "updatedAt": "2026-08-13T14:36:54Z",
        "timestamp": "2026-08-13T14:36:54Z",
        "metrics": {
          "reactions": 2,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "team/agent-security",
          "team/single-machine-performance",
          "qa/no-code-change",
          "medium review",
          "team/action-platform",
          "internal",
          "team/agent-data-plane"
        ],
        "author": "GeorgeHahn",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54793",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Remove schemaBuilder and createschema command",
        "text": "### What does this PR do? Remove the `createschema` command and the schema builder config implementation. We no longer need to generate the schema. ### Motivation Cleanup now that schema is live and in use. ### Describe how you validated your changes CI ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54793",
        "createdAt": "2026-08-12T18:13:12Z",
        "updatedAt": "2026-08-13T17:59:52Z",
        "timestamp": "2026-08-13T17:59:52Z",
        "metrics": {
          "reactions": 2,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "qa/done",
          "long review",
          "team/agent-runtimes",
          "team/agent-build",
          "internal",
          "team/fleet-remediation",
          "team/fleet-automation"
        ],
        "author": "dustmop",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54794",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "fix(data plane): run preflight mode for entire SMP experiment duration",
        "text": "### What does this PR do? This PR adds the ability to _increase_ the duration of preflight mode for ADP. ### Motivation Since preflight mode now influences SMP experiments, we see the RSS for quality gate experiments increased even though ADP only runs for 90 seconds. While we need to adjust those QG limits no matter what, we also want to make ADP run for the _entire_ duration so that we avoid increasing the limits and then potentially letting other changes to the Agent effectively \"hide\" behind the temporary ADP usage. ### Describe how you validated your changes - New and existing unit tests. ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54794",
        "createdAt": "2026-08-12T18:32:05Z",
        "updatedAt": "2026-08-13T12:11:55Z",
        "timestamp": "2026-08-13T12:11:55Z",
        "metrics": {
          "reactions": 2,
          "comments": 6
        },
        "labels": [
          "team/agent-security",
          "long review",
          "qa/skip-qa",
          "team/agent-devx",
          "team/action-platform",
          "internal",
          "team/fleet-remediation",
          "team/fleet-automation",
          "team/agent-data-plane"
        ],
        "author": "tobz",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54795",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "test(ndm): add e2e coverage for Agent Workload Balancing",
        "text": "> **Note:** This PR was created by Claude. ### What does this PR do? Adds the e2e test suite for Agent Workload Balancing that was called out as needed in #54652's original plan, and adds the one missing CLI surface found while auditing that plan for completeness. - `TestWorkloadBalancingRunningMetrics` / `TestWorkloadBalancingAddedToRCListeners` (`workloadbalancing_test.go`): mirrors `haagent_test.go`. Pushes an `NDM_AGENT_WORKLOAD_BALANCING` Remote Config payload via `RCAddConfig` against fakeintake, then asserts `datadog.agent.workload_balancing.running` (tagged `workload_balancing_group`/`workload_balancing_state`) and the `\"Add workload balancing RCListener\"` log line. - `TestWorkloadBalancingMetadata` (`workloadbalancing_metadata_test.go`): mirrors `haagent_metadata_test.go`. Pushes an RC assignment, then reads it back via `diagnose show-metadata workload-balancing`. - `cmd/agent/subcommands/diagnose/command.go`: adds the `show-metadata workload-balancing` subcommand. #54659 wired the metadata provider into inventory, flare, status, and the `/metadata/workload-balancing` HTTP endpoint, but left out the CLI subcommand that HA Agent has as `show-metadata ha-agent`. The metadata e2e test above needs it to read the payload the same way the HA Agent test does. - `.gitlab-ci.yml` / `.gitlab/test/e2e/e2e.yml`: adds a `new-e2e-workload-balancing` job and its change-triggering rule, following the `ha-agent` job pattern. - `.github/CODEOWNERS`: adds `/test/new-e2e/tests/workload-balancing`. ### Motivation This was the fourth piece of the originally planned agent-side work (component, metric, inventory metadata, e2e test), deferred because it was \"blocked on #53246 for Remote Config fakeintake support.\" That PR merged, so the blocker is gone. Not included here: a multi-host failover test analogous to `haagent_failover_test.go` (driving an actual handoff between two hosts). Left as a follow-up TODO in `workloadbalancing_test.go` rather than adding a large multi-VM test to this PR. ### Describe how you validated your changes - `go vet ./tests/workload-balancing/...` in `test/new-e2e` passes. - `gofmt` clean on all changed/added files. - Base branch merges (`mleese/ndm-device-handoff` + `mleese/ndm-workload-balancing-metric` + `mleese/ndm-workload-balancing-metadata`) were clean, no conflicts. - Not yet run against real infra (draft; depends on #54652, #54656, #54659 landing first). ### Additional Notes Stacked on top of `mleese/ndm-device-handoff` (#54652), and depends on `mleese/ndm-workload-balancing-metric` (#54656) and `mleese/ndm-workload-balancing-metadata` (#54659) both being merged into it — this branch already contains both of those changes merged in, since they're sibling branches rather than stacked on each other.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54795",
        "createdAt": "2026-08-12T19:04:08Z",
        "updatedAt": "2026-08-13T18:00:56Z",
        "timestamp": "2026-08-13T18:00:56Z",
        "metrics": {
          "reactions": 1,
          "comments": 7
        },
        "labels": [],
        "author": "matthewleese",
        "state": "closed",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54796",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "test(network/usm): run the USM and classification suites on the fentry tracer",
        "text": "### What does this PR do? Runs the USM and protocol-classification test suites against the **fentry** connection tracer, which they previously never exercised. Fentry was absent from `usmtestutil.SupportedBuildModes`, and four separate gates short-circuited on it even when it was selected: | Gate | Old behavior on fentry | |---|---| | `httpSupported()` / `httpsSupported()` (`usm/tests`) | returned `false` → suites skipped | | `setupTracer` (`tracer_classification_test.go`) | force-disabled `ProtocolClassificationEnabled` | | `TestTLSClassification` | `t.Skip(\"protocol classification not supported for fentry tracer\")` | | `httpSupported()` (`pkg/network/tracer`) | returned `false` → `TestGetStats` waived its `usm` telemetry assertion | The hardcoded gates are replaced with real capability queries: `classificationSupported` now dispatches to the fentry or kprobe tracer as appropriate. To make that possible, `fentry.classificationSupported` is exported as `ClassificationSupported`, matching `kprobe.ClassificationSupported` (first commit; no behavior change). Fentry eligibility in `usmtestutil.SupportedBuildModes` is delegated to `ebpftest.SupportedBuildModes()` rather than re-derived, since that gate (kernel floor / RCU-deadlock symbol boundary / `TEST_FENTRY_OVERRIDE`) is subtle and has regressed before when copied. Note that \"Fentry\" here selects the fentry *connection tracer* while `usm.o` still loads as CO-RE — `usm.o` has no fentry variant and needs none. ### Motivation Part of the fentry tracer cleanup and validation effort. The fentry tracer supports protocol classification in production, but no USM test ever ran against it, so that support was entirely unverified — a silent coverage hole rather than a known gap. ### Describe how you validated your changes Run on ubuntu-24 / 6.8.0-86 with `TEST_FENTRY_OVERRIDE=true` (this kernel carries the AUTOSEL backport of the RCU-exit deadlock fix, so it runs fentry despite being below the `kv >= 6.9` test gate). - **`TestUSMSuite/fentry`** — all 7 suite methods pass, across 3 full-suite runs. - **`TestTracerSuite/fentry`** — 109 pass, 5 skip, 0 fail. - **`TestGetStats/fentry`** — now *asserts* the `usm` telemetry section on fentry instead of waiving it, and passes on both `ebpf_conntracker` variants. This is a strictness increase, and it confirms fentry genuinely populates usm telemetry. **Skip audit.** All 27 skips across both suites were checked against their source conditions and are build-mode independent — unconditional \"flaky\" skips on the TLS variants, `skipIfUsingNAT` on the DNAT group, kernel-version and host-performance gates. The single exception is `TestKprobeAttachWithKprobeEvents`, which skips on fentry; see Additional Notes. **One flaky failure, investigated and cleared.** An initial run failed `without_nat/kafka/fetch_v11`. Measured over 9 further runs: | Scope | Runs | Failures | |---|---|---| | `without_nat/kafka` isolated | 4 | 0 | | `TestProtocolClassification` in-group | 3 | 0 | | full `TestUSMSuite/fentry` | 3 | 1 | Load-dependent, disappears under a narrower `-run` filter, and the failing Kafka API version varies run to run (v9/v11/v14/v16 all observed) — matching this test's known pre-existing flakiness on this VM across build modes. Not attributable to this change. It is not currently in `flakes.yaml`. ### Additional Notes `TestKprobeAttachWithKprobeEvents` still skips on fentry, and this PR deliberately leaves it that way. The reason is a **pre-existing production gap**: `AttachKprobesWithKprobeEventsABI` is silently ignored on the fentry path, because `initFentryTracer` never sets `DefaultKprobeAttachMethod` on its manager options, so the manager falls back to `AttachKprobeWithPerfEventOpen`. Fentry does retain 3 kprobes (`tcp_enter_loss`, `tcp_enter_recovery`, `tcp_send_probe0`), so the setting is meaningful there. Fixing it is a production change tracked separately and out of scope for this test-enablement PR.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54796",
        "createdAt": "2026-08-12T19:22:36Z",
        "updatedAt": "2026-08-12T20:25:56Z",
        "timestamp": "2026-08-12T20:25:56Z",
        "metrics": {
          "reactions": 2,
          "comments": 6
        },
        "labels": [
          "component/system-probe",
          "medium review",
          "team/agent-build",
          "team/cloud-network-monitoring",
          "internal"
        ],
        "author": "jmw51798",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54797",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Sign macos DMG only on nightly instead of main",
        "text": "### What does this PR do? Stops doing real signing and notarization of Macos DMG packages on main. Do it on nightly only so we maintain some testing of the process. ### Motivation We should not be creating notarized, installable packages off of main. That creates artifacts which could appear to be end-user consumable, but are not supported, nor necessarily validated. Notarization also slightly DOSes Apple. Ideally we should only do notarization on the release branches for candidate builds. We'll address that once we convert the build to bazel. ### Describe how you validated your changes CI ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54797",
        "createdAt": "2026-08-12T19:48:33Z",
        "updatedAt": "2026-08-13T16:33:42Z",
        "timestamp": "2026-08-13T16:33:42Z",
        "metrics": {
          "reactions": 1,
          "comments": 2
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "short review",
          "team/agent-build",
          "internal"
        ],
        "author": "aiuto",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54798",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[APM] Reduce allocations on the trace decode path",
        "text": "### What does this PR do? Two independent allocation reductions on the trace-agent receive/decode path. **1. Intern strings directly from the payload (v0.4 decode).** `parseStringBytesRef` materialized a Go string for every value just to look it up in the payload's string table, discarding it on a hit. **2. Reserve `bytes.MinRead` beyond the body when buffering a request.** `reserveBodySize` reserved exactly `Content-Length`, but `io.Copy` bottoms out in `bytes.Buffer.ReadFrom`, which needs `bytes.MinRead` of spare capacity for the read that reports EOF. Also fixes two swapped godoc names on `parseStringBytes` / `parseStringBytesRef`. ### Motivation Both were found in a staging heap profile of the trace-agent receiver. `pprof -traces` showed `bytes.Buffer.Grow` and `bytes.Buffer.ReadFrom` both allocating on the same `copyRequestBody` path — i.e. twice per request. ### Describe how you validated your changes New tests and benchmarks in both packages: - `pkg/proto/pbgo/trace/idx/string_intern_test.go` — `TestAddBytesMatchesAdd` asserts `AddBytes` and `Add` are behaviourally equivalent, so no decode divergence is introduced. - `pkg/proto/pbgo/trace/idx/string_intern_bench_test.go` — intern benchmarks across hit rates, including a `HitRate0` control arm. - `pkg/trace/api/body_buffer_test.go` — `TestReserveBodySizeLimit` pins the `MaxRequestBytes` boundary (at / one over / absent / unparseable), confirming the `MinRead` padding does not leak into the size check. `TestCopyRequestBodyNoRealloc` asserts the body lands in the same backing array that was reserved, by identity, rather than counting allocations. - `pkg/trace/api/body_buffer_bench_test.go` — `BenchmarkCopyRequestBody` over two regimes: `SmallWarmPool` (ordinary traffic, shows the change is neutral, 0 allocs/op) and `LargeColdBuffer` (the regime that actually generates the bytes). Also run: full `pkg/trace/api` and `pkg/proto/pbgo/trace/idx` suites, and `bazel test //pkg/proto/pbgo/trace/idx:idx_test //pkg/trace/api:api_test` — all pass. **Time** (benchstat, n=10, Apple M4 Max darwin/arm64; only `span.go` differs between arms) | Benchmark | before | after | delta | |---|---|---|---| | `StringTableIntern/HitRate100` | 24.42µ ± 4% | 14.74µ ± 1% | −39.6% | | `StringTableIntern/HitRate90` | 27.90µ ± 3% | 18.90µ ± 1% | −32.3% | | `StringTableIntern/HitRate50` | 31.80µ ± 2% | 25.63µ ± 1% | −19.4% | | `StringTableIntern/HitRate0` | 35.32µ ± 5% | 34.40µ ± 0% | −2.6% | | `SpanUnmarshalConvertedStrings` | 107.80µ ± 1% | 86.15µ ± 1% | −20.1% | All p=0.000. **Allocations** | Benchmark | before | after | delta | |---|---|---|---| | `HitRate100` | 1003 allocs / 48288 B | 4 allocs / 336 B | −99.6% / −99.3% | | `HitRate90` | 1005 allocs / 44.3KiB | 105 allocs / 9.1KiB | −89.6% / −79.4% | | `HitRate50` | 1005 allocs / 73.8KiB | 505 allocs / 54.2KiB | −49.8% / −26.5% | | `HitRate0` | 1007 allocs / 108.4KiB | 1007 allocs / 108.4KiB | ~ (identical) | | `SpanUnmarshalConvertedStrings` | 3607 allocs / 227.6KiB | 1231 allocs / 197.9KiB | −65.9% / −13.1% | Throughput on the end-to-end span decode: 417.5 → 522.4 MiB/s, +25.1%. ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54798",
        "createdAt": "2026-08-12T19:56:32Z",
        "updatedAt": "2026-08-13T13:09:33Z",
        "timestamp": "2026-08-13T13:09:33Z",
        "metrics": {
          "reactions": 2,
          "comments": 6
        },
        "labels": [
          "team/agent-apm",
          "qa/done",
          "medium review",
          "team/agent-build",
          "internal"
        ],
        "author": "ajgajg1134",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54799",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "ci: default GitLab jobs to shallow clones, keep full history where needed",
        "text": "## Summary - Default GitLab jobs to `GIT_DEPTH: 1` so most checkouts are a shallow clone of HEAD only. - Set `GIT_DEPTH: 0` on jobs that actually need git history (merge-base, ancestor walks, `git describe`, `git log` ranges). - `GIT_STRATEGY: clone` is not a full clone; clone with depth 1 is still shallow. Full history requires `GIT_DEPTH: 0`. ## Test plan - [ ] Confirm a typical build/lint job clones with depth 1 and still has the working tree. - [ ] Confirm jobs that compute merge-base still succeed (`golang_deps_diff`, e2e `--impacted`, `static_quality_gates`, `files_inventory_check`, SMP merge-base check). - [ ] Confirm `setup_agent_version` can still run `git describe --tags`. - [ ] Confirm unit-test jobs with `FAST_TESTS=true` still detect impacted packages. Made with [Cursor](https://cursor.com)",
        "url": "https://github.com/DataDog/datadog-agent/pull/54799",
        "createdAt": "2026-08-12T20:14:02Z",
        "updatedAt": "2026-08-13T14:01:36Z",
        "timestamp": "2026-08-13T14:01:36Z",
        "metrics": {
          "reactions": 1,
          "comments": 3
        },
        "labels": [
          "community",
          "changelog/no-changelog",
          "team/agent-apm",
          "team/ebpf-platform",
          "qa/no-code-change",
          "team/agent-delivery",
          "team/container-integrations",
          "team/agent-devx",
          "team/agent-build",
          "team/windows-products"
        ],
        "author": "mikesherovdd",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54800",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "perf: move #54639's `proto.Client` clone from `seen` to `activeClients`",
        "text": "### What does this PR do? Move the `proto.Clone()` call that guards `pbgo.Client` aliasing from `clients.seen()` to `clients.activeClients()`. ### Motivation Follow-up to #54639, discussed with its author beforehand. `seen()` runs on every `ClientGetConfigs` poll from every client, up to twice per request via the bypass path, while `activeClients()` runs once per `refresh()` cycle regardless of client count. Cloning in `seen()` therefore pays one allocation per poll instead of one per client per refresh cycle, and the gap widens with client count. A micro-benchmark with 200 clients showed 29% fewer allocations at 2 polls per client per refresh cycle, and 50% fewer at 5 polls per client. The only regime where the opposite holds is `activeClients()` being called more often than clients poll, which only `ConfigGetState` does, and that is a debug endpoint, not a hot path. ### Describe how you validated your changes `TestClientsSeenActiveClientsRace` and the rest of the package's test suite pass unchanged under `-race`: the invariant it guards, that whatever escapes the lock is never mutated again, holds regardless of where the clone happens.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54800",
        "createdAt": "2026-08-12T20:41:52Z",
        "updatedAt": "2026-08-12T21:45:53Z",
        "timestamp": "2026-08-12T21:45:53Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "team/remote-config",
          "qa/done",
          "short review",
          "internal"
        ],
        "author": "rdesgroppes",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54802",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Update dependency @sentry/dotagents to v3",
        "text": "This PR contains the following updates: | Package | Change | [Age](https://docs.renovatebot.com/merge-confidence/) | [Adoption](https://docs.renovatebot.com/merge-confidence/) | [Passing](https://docs.renovatebot.com/merge-confidence/) | [Confidence](https://docs.renovatebot.com/merge-confidence/) | |---|---|---|---|---|---| | @&#8203;sentry/dotagents | `1.19.0` → `3.0.1` | ![age](https://developer.mend.io/api/mc/badges/age/npm/@sentry%2fdotagents/3.0.1?slim=true) | ![adoption](https://developer.mend.io/api/mc/badges/adoption/npm/@sentry%2fdotagents/3.0.1?slim=true) | ![passing](https://developer.mend.io/api/mc/badges/compatibility/npm/@sentry%2fdotagents/1.19.0/3.0.1?slim=true) | ![confidence](https://developer.mend.io/api/mc/badges/confidence/npm/@sentry%2fdotagents/1.19.0/3.0.1?slim=true) | --- > [!WARNING] > Some dependencies could not be looked up. Check the [Dependency Dashboard](../issues/33469) for more information. --- ### Configuration 📅 **Schedule**: (in timezone Europe/Paris) - Branch creation - At 12:00 AM through 04:59 AM and 10:00 PM through 11:59 PM, Monday through Friday (`* 0-4,22-23 * * 1-5`) - Only on Sunday and Saturday (`* * * * 0,6`) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/DataDog/datadog-agent). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0NC4yNC4wIiwidXBkYXRlZEluVmVyIjoiNDQuMjQuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiY2hhbmdlbG9nL25vLWNoYW5nZWxvZyIsImRlcGVuZGVuY2llcyIsInFhL25vLWNvZGUtY2hhbmdlIl19-->",
        "url": "https://github.com/DataDog/datadog-agent/pull/54802",
        "createdAt": "2026-08-12T21:11:49Z",
        "updatedAt": "2026-08-12T21:44:24Z",
        "timestamp": "2026-08-12T21:44:24Z",
        "metrics": {
          "reactions": 1,
          "comments": 2
        },
        "labels": [
          "changelog/no-changelog",
          "dependencies",
          "qa/no-code-change",
          "short review",
          "team/agent-devx",
          "internal"
        ],
        "author": "renovate[bot]",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54803",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "WIF-48: wire delegated auth into endpoint subsystems",
        "text": "## Summary Stacked on #53517, this PR integrates delegated-auth-managed `DELA(...)` additional endpoints into Agent subsystems: - discovers delegated-auth directives in every supported map- and list-shaped additional-endpoints setting - preserves pending directives during startup and excludes them from outbound keys until resolution - updates forwarder, logs, process, and orchestrator endpoint handling - rebuilds trace proxy transports after delegated-auth resolution and reload; trace writers still require restart to add a previously unresolved endpoint The customer-facing release note is in the foundation PR, #53517. This stacked integration PR is labeled `changelog/no-changelog` to avoid duplicating it. ## Validation Focused tests passed: - forwarder resolver and logs endpoint behavior - trace reload callback and pending-directive transport behavior - config setup parsing, fallback resolution, redaction, map/list registration, and multi-org cases - orchestrator configuration Full trace-config and trace-API Bazel targets are blocked locally by sandbox limitations unrelated to this change: the trace-config external-hostname test cannot find `go` in the Bazel sandbox, and trace-API UDS tests cannot bind a temporary Unix socket in the macOS sandbox. The process-runner target is platform-skipped. ## Dependency Depends on #53517.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54803",
        "createdAt": "2026-08-13T02:02:43Z",
        "updatedAt": "2026-08-13T14:57:39Z",
        "timestamp": "2026-08-13T14:57:39Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "long review"
        ],
        "author": "wynbennett",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54804",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "fix(installer): embed -nocap systemd unit templates",
        "text": "## What does this PR do? Adds `//go:embed` directives for `tmpl/gen/oci-nocap/*.service` and `tmpl/gen/debrpm-nocap/*.service`, and the matching Bazel `embedsrcs` entries, so the `-nocap` systemd unit templates ship inside the installer binary. Adds `embed_test.go`, which enumerates units through the `embed.FS` and asserts `GetSystemdUnit` resolves every unit in both the ambient-capability and `-nocap` variants. ## Motivation This is to address this escalation: https://datadoghq.atlassian.net/browse/AGENT-16750 `GetSystemdUnit` selects the `-nocap` templates on hosts whose kernel does not support ambient capabilities (older than 4.3), but no `//go:embed` directive covered those directories. Unit generation failed at runtime with: ``` failed to write stable units: open tmpl/gen/debrpm-nocap/datadog-agent.service: file does not exist ``` The package manager scriptlet ignores that failure, so the install reported success while the host was left with no Datadog units and `systemctl start datadog-agent` returned `Unit not found`. Both the classic DEB/RPM path and Fleet Automation remote upgrades and config experiments (`oci-nocap`) were affected. The existing tests missed this because they read the template tree from disk instead of from the `embed.FS`, so the templates were always present regardless of the embed directives. ## Verification - `dda inv test --targets=./pkg/fleet/installer/packages/embedded` - 83 tests passed - `bazel test //pkg/fleet/installer/packages/embedded:all` - `embedded_test` and `tmpl_test` passed - The new `TestGetSystemdUnitEmbedsAllVariants` fails on `main` (`file does not exist` for every `-nocap` unit) and passes with this change - `TestGetSystemdUnitSelectsNocapVariant` confirms the `-nocap` unit actually has `AmbientCapabilities=` stripped, not just that it loads ### Known gap, not addressed here `tmpl/datadog-agent-data-plane.service.tmpl` emits `AmbientCapabilities` unconditionally, without the `{{ if .AmbiantCapabilitiesSupported }}` guard its siblings use, so its two variants are byte-identical. That is a pre-existing template defect, out of scope for this fix, and is documented in a comment on the test. 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
        "url": "https://github.com/DataDog/datadog-agent/pull/54804",
        "createdAt": "2026-08-13T03:52:11Z",
        "updatedAt": "2026-08-13T17:42:48Z",
        "timestamp": "2026-08-13T17:42:48Z",
        "metrics": {
          "reactions": 2,
          "comments": 4
        },
        "labels": [
          "qa/done",
          "medium review",
          "team/agent-build",
          "team/windows-products",
          "internal"
        ],
        "author": "mwdd146980",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54805",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[Backport 7.82.x]  [EBPF] Gate NVML workloadmeta collector on GPU monitoring",
        "text": "Backport d1520bca29c837ff691f91102b60a32a37c0112c from #54563. ___ ### What does this PR do? Gates the NVML workloadmeta collector on `gpu.enabled`. ### Motivation Avoid NVML collection when GPU monitoring is disabled. ### Describe how you validated your changes Added unit coverage for disabled startup. ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54805",
        "createdAt": "2026-08-13T07:47:49Z",
        "updatedAt": "2026-08-13T15:39:30Z",
        "timestamp": "2026-08-13T15:39:30Z",
        "metrics": {
          "reactions": 2,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "team/ebpf-platform",
          "qa/done",
          "backport",
          "bot",
          "medium review",
          "team/agent-build",
          "internal",
          "team/gpu-monitoring-agent"
        ],
        "author": "dd-octo-sts[bot]",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54806",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[Backport 7.83.x]  [EBPF] Gate NVML workloadmeta collector on GPU monitoring",
        "text": "Backport d1520bca29c837ff691f91102b60a32a37c0112c from #54563. ___ ### What does this PR do? Gates the NVML workloadmeta collector on `gpu.enabled`. ### Motivation Avoid NVML collection when GPU monitoring is disabled. ### Describe how you validated your changes Added unit coverage for disabled startup. ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54806",
        "createdAt": "2026-08-13T07:47:59Z",
        "updatedAt": "2026-08-13T15:20:09Z",
        "timestamp": "2026-08-13T15:20:09Z",
        "metrics": {
          "reactions": 2,
          "comments": 0
        },
        "labels": [
          "changelog/no-changelog",
          "team/ebpf-platform",
          "qa/done",
          "backport",
          "bot",
          "medium review",
          "team/agent-build",
          "internal",
          "team/gpu-monitoring-agent"
        ],
        "author": "dd-octo-sts[bot]",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54807",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Gitignore the .pi-subagents folder",
        "text": "## Summary - Add `.pi-subagents/` to `.gitignore` so this local tooling directory isn't tracked in the repo. ## Test plan - N/A (gitignore-only change)",
        "url": "https://github.com/DataDog/datadog-agent/pull/54807",
        "createdAt": "2026-08-13T08:15:49Z",
        "updatedAt": "2026-08-13T08:34:48Z",
        "timestamp": "2026-08-13T08:34:48Z",
        "metrics": {
          "reactions": 2,
          "comments": 0
        },
        "labels": [
          "short review",
          "team/agent-devx",
          "internal"
        ],
        "author": "KevinFairise2",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54808",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Make dda tasks use bazel's Go sdk",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54808",
        "createdAt": "2026-08-13T08:32:14Z",
        "updatedAt": "2026-08-13T11:13:43Z",
        "timestamp": "2026-08-13T11:13:43Z",
        "metrics": {
          "reactions": 1,
          "comments": 1
        },
        "labels": [
          "qa/no-code-change",
          "medium review",
          "team/agent-devx",
          "team/agent-build",
          "internal"
        ],
        "author": "JSGette",
        "state": "closed",
        "assignees": [
          "JSGette"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54809",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "feat(cancel): Force cancellation of running jobs",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Improve cleanup to also cancel running jobs. Move call to stack-cleaner to after_script, which is executed after a \"graceful\" (not forced) job cancel. Prevent cleanup of whitelisted jobs. ### Motivation Reduce pressure on infrastructure. ### Describe how you validated your changes Local tests and attempt to push a new commit on this precise branch ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54809",
        "createdAt": "2026-08-13T08:42:37Z",
        "updatedAt": "2026-08-13T13:50:05Z",
        "timestamp": "2026-08-13T13:50:05Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "medium review",
          "team/container-integrations",
          "team/agent-devx",
          "team/agent-build",
          "internal"
        ],
        "author": "chouetz",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54810",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Remove bazel strptime_cgo_testlib override",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Remove bazel strptime_cgo_testlib override. ### Motivation Fixed by https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/49516. ### Describe how you validated your changes CI ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54810",
        "createdAt": "2026-08-13T08:49:37Z",
        "updatedAt": "2026-08-13T14:34:51Z",
        "timestamp": "2026-08-13T14:34:51Z",
        "metrics": {
          "reactions": 2,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "short review",
          "internal"
        ],
        "author": "pgimalac",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54811",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[AAD-15] Add scoped anomaly scorer telemetry",
        "text": "### What does this PR do? Adds bounded service/source-scoped anomaly scorers and telemetry to measure input coverage against successfully started file and container log tailers. The global scorer and adaptive-sampling behavior are unchanged; scoped scores are telemetry-only. ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54811",
        "createdAt": "2026-08-13T08:53:27Z",
        "updatedAt": "2026-08-13T09:57:21Z",
        "timestamp": "2026-08-13T09:57:21Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "long review",
          "team/container-integrations",
          "team/agent-log-pipelines",
          "team/agent-metric-pipelines",
          "team/agent-build",
          "internal",
          "team/fleet-automation"
        ],
        "author": "CelianR",
        "state": "open",
        "assignees": [
          "CelianR"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54812",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Move tools/tar_checksums to bazel/tools",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Moves tar_checksums code to under `bazel/tools`, such that it falls under the agent-build team ownership. ### Motivation I made a PR that touched these files and no review from agent-build was requested, even though this is under our scope. This is also consistent with the contents of both folders (`bazel/tools` vs `tools`) as things stand today. ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54812",
        "createdAt": "2026-08-13T09:32:34Z",
        "updatedAt": "2026-08-13T13:48:08Z",
        "timestamp": "2026-08-13T13:48:08Z",
        "metrics": {
          "reactions": 2,
          "comments": 2
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "medium review",
          "team/agent-build",
          "internal"
        ],
        "author": "alopezz",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54813",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "chore: Update devcontainer prebuilt image reference",
        "text": "Prebuilt devcontainer image reference updated to reflect latest config. This automation in driven by the [workspaces-image-builder service](https://mosaic.us1.ddbuild.io/services/workspaces-imagebuilder/details) and the [github-devcontainer-prebuild service](https://mosaic.us1.ddbuild.io/services/github-devcontainer-prebuild/details). For workspaces on-call: If there are any unexpected behaviors with this automation, see the [troubleshooting runbook](https://datadoghq.atlassian.net/wiki/spaces/DEVX/pages/4880237711/Troubleshooting+Devcontainer+Pre-Builds).",
        "url": "https://github.com/DataDog/datadog-agent/pull/54813",
        "createdAt": "2026-08-13T09:32:49Z",
        "updatedAt": "2026-08-13T12:00:52Z",
        "timestamp": "2026-08-13T12:00:52Z",
        "metrics": {
          "reactions": 2,
          "comments": 1
        },
        "labels": [
          "campaigner-automated-change"
        ],
        "author": "gh-worker-campaigns-3e9aa4[bot]",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54814",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[AGENTRUN-1446] Skip nss failover e2e test it if the fakeintakes are still in use",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Due to a framework issue, the fakeintakes might still be in use (ie. an agent is still sending payloads to them) when the test starts, which makes the test flaky. We added a detection logic to fail early in this case (to avoid confusion when debugging). Update the logic to skip the test rather than fail it in this case. ### Motivation Avoid receiving notifications for failed test for a framework issue. ### Describe how you validated your changes CI ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54814",
        "createdAt": "2026-08-13T09:46:46Z",
        "updatedAt": "2026-08-13T17:28:50Z",
        "timestamp": "2026-08-13T17:28:50Z",
        "metrics": {
          "reactions": 2,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "short review",
          "team/agent-runtimes",
          "team/agent-build",
          "internal"
        ],
        "author": "pgimalac",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54815",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[DSEC] Move dd-sds dependency to shared workspace",
        "text": "### What does this PR do? Moves the `dd-sds` (`dd-sensitive-data-scanner`) dependency from the `datasecurity` check crate into the shared `[workspace.dependencies]` in the root `Cargo.toml`. The crate now references it via `dd_sds.workspace = true`. ### Motivation Centralize the pinned version and feature set so future check crates share a single source of truth instead of duplicating the spec. ### Tests Use docker image registry.ddbuild.io/ci/datadog-agent/agent:v130685756-40c89d95-7-amd64 generated in the CI and confirmed that data security check is correctly running. ```bash dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/aggregator/aggregator.go:182 in LogMsg) | datasecurity: sub task succeeded (1 match(es)) dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/aggregator/aggregator.go:182 in LogMsg) | datasecurity: running sub task (sub_task_id=455ECD24-5C11-45AA-801B-5C2C43C8533C, platform=postgres) dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (comp/core/agenttelemetry/impl/agenttelemetry.go:665 in run) | Starting agent telemetry run dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/aggregator/aggregator.go:182 in LogMsg) | datasecurity: sub task succeeded (1 match(es)) dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/aggregator/aggregator.go:182 in LogMsg) | datasecurity: check completed dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/worker/check_logger.go:59 in CheckFinished) | check:datasecurity | Done running check dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/worker/check_logger.go:65 in CheckFinished) | check:datasecurity | Check's one time execution has finished ```",
        "url": "https://github.com/DataDog/datadog-agent/pull/54815",
        "createdAt": "2026-08-13T10:12:22Z",
        "updatedAt": "2026-08-13T17:40:40Z",
        "timestamp": "2026-08-13T17:40:40Z",
        "metrics": {
          "reactions": 2,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "short review",
          "team/agent-devx",
          "team/agent-build",
          "internal"
        ],
        "author": "aimenebelfodil",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54816",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[Backport 7.83.x]  [EBPF] gpu: Skip unsupported vGPU max-clock queries",
        "text": "Backport e5a19fa15faff217145de62c45995fd1f2451ee1 from #54729. ___ <!-- dd-meta {\"pullId\":\"00000000-0000-0000-0000-000000000000\",\"source\":\"chat\",\"resourceId\":\"b6950850-80dc-4801-bc2f-895d5b466cca\",\"workflowId\":\"c63cfe10-11dd-4bbc-800e-23188cad9c50\",\"codeChangeId\":\"c63cfe10-11dd-4bbc-800e-23188cad9c50\",\"sourceType\":\"bits_ai_sre\"} --> ### What does this PR do? Bits AI SRE Investigation • [View in Bits AI SRE Investigation](https://app.datadoghq.com/bits-ai/investigations/54d64295-b38b-44f1-85fa-fb1948786cba) - Detect vGPU devices in the NVIDIA stateless max-clock handlers. - Cache each device's NVML virtualization mode in `safenvml.DeviceInfo` during device initialization, so max-clock collection does not query NVML repeatedly. - Return the repository's typed unsupported-API error so all four max-clock handlers are filtered during collector initialization. - Log an error when the virtualization-mode lookup fails during device initialization. - Add regression coverage that makes vGPU max-clock calls return `ERROR_UNKNOWN`, verifies the cached mode, and confirms max-clock calls are never invoked or reported as collection errors. ### Motivation NVIDIA vGPU devices such as the A10-24Q configuration in the zekrom cluster do not support NVML `GetMaxClockInfo`. The API returns `Unknown Error` rather than `ERROR_NOT_SUPPORTED`, so the stateless collector previously retried the calls on every collection cycle and generated recurring collection-error noise. This fix suppresses those unsupported calls while preserving max-clock metrics for physical GPUs, caches the virtualization capability query used to make that decision, and reports failures to determine the mode. ### Describe how you validated your changes - Formatted the modified Go file with `gofmt` and ran `git diff --check`. - Verified the vGPU regression test observes one virtualization-mode query during device initialization and zero max-clock queries. - The targeted Bazel test was previously attempted but could not start because the workspace could not download the required Bazel version. - The prescribed `dda` executable was unavailable in the workspace. ### Additional Notes The change is limited to the NVIDIA stateless collector, safenvml device metadata and logging, and regression coverage. --- PR by Bits - [View session in Datadog](https://app.datadoghq.com/code/b6950850-80dc-4801-bc2f-895d5b466cca) Comment @datadog to request changes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54816",
        "createdAt": "2026-08-13T10:18:43Z",
        "updatedAt": "2026-08-13T15:20:14Z",
        "timestamp": "2026-08-13T15:20:14Z",
        "metrics": {
          "reactions": 2,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "team/ebpf-platform",
          "qa/done",
          "backport",
          "bot",
          "short review",
          "Bits AI",
          "internal",
          "team/gpu-monitoring-agent"
        ],
        "author": "dd-octo-sts[bot]",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54817",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[EBPF] Disable parallel GPU collection by default",
        "text": "### What does this PR do? Disables parallel NVML collector collection by default in the GPU check. Operators can opt in with `gpu.parallel_collectors: true`. ### Motivation #incident-59170 ### Describe how you validated your changes Ran manually, checked that the parallel collectors being disabled removes the issue. ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54817",
        "createdAt": "2026-08-13T10:20:00Z",
        "updatedAt": "2026-08-13T12:46:29Z",
        "timestamp": "2026-08-13T12:46:29Z",
        "metrics": {
          "reactions": 1,
          "comments": 3
        },
        "labels": [
          "team/ebpf-platform",
          "qa/done",
          "short review",
          "internal",
          "team/gpu-monitoring-agent",
          "team/fleet-automation",
          "backport/7.82.x",
          "backport/7.83.x"
        ],
        "author": "gjulianm",
        "state": "open",
        "assignees": [
          "gjulianm"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54818",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Fail bazel build on Windows if vault isn't found",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Builds are notoriously slow on Windows so it was requested by @DataDog/windows-products to fail the agent build in case we can't utilize the cache. One of the main reasons for that is absence of `vault` tool that is used to acquire an access token for our `buildbarn` cluster that serves as a remote cache backend. With this change we: - immediately fail the build if `vault` hasn't been found. Users can still opt-out and build without cache. - print a hint explaining how to properly install `vault`",
        "url": "https://github.com/DataDog/datadog-agent/pull/54818",
        "createdAt": "2026-08-13T10:26:41Z",
        "updatedAt": "2026-08-13T15:35:06Z",
        "timestamp": "2026-08-13T15:35:06Z",
        "metrics": {
          "reactions": 2,
          "comments": 2
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "short review",
          "team/agent-build",
          "internal"
        ],
        "author": "JSGette",
        "state": "open",
        "assignees": [
          "JSGette"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54819",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Copy python files to avoid junction issues",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54819",
        "createdAt": "2026-08-13T10:45:46Z",
        "updatedAt": "2026-08-13T14:39:12Z",
        "timestamp": "2026-08-13T14:39:12Z",
        "metrics": {
          "reactions": 2,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "medium review",
          "team/agent-build",
          "internal"
        ],
        "author": "JSGette",
        "state": "open",
        "assignees": [
          "JSGette"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54820",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Pedro.cordeiro/macos thermal notable event",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54820",
        "createdAt": "2026-08-13T10:46:00Z",
        "updatedAt": "2026-08-13T11:47:55Z",
        "timestamp": "2026-08-13T11:47:55Z",
        "metrics": {
          "reactions": 1,
          "comments": 3
        },
        "labels": [
          "medium review",
          "team/agent-build",
          "team/windows-products",
          "internal"
        ],
        "author": "PedroCordeiroDataDog",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54821",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[EBPF] gpu: serialize NVML field value queries",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Ensures that calls to `GetFieldValues` are serialized as that is not a thread safe API. ### Motivation #incident-59170 - `nvlink_fields` collector might mark some ports as unsupported. This is an extra safety on top of #54817, in case parallel collection is enabled. ### Describe how you validated your changes Tested in an A100 instance. ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54821",
        "createdAt": "2026-08-13T10:55:17Z",
        "updatedAt": "2026-08-13T17:32:57Z",
        "timestamp": "2026-08-13T17:32:57Z",
        "metrics": {
          "reactions": 2,
          "comments": 6
        },
        "labels": [
          "team/ebpf-platform",
          "qa/done",
          "short review",
          "internal",
          "team/gpu-monitoring-agent",
          "backport/7.82.x",
          "backport/7.83.x"
        ],
        "author": "gjulianm",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54822",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[AAD-37] Optimize total series count",
        "text": "### What does this PR do? `TotalSeriesCount` was taking a lot of CPU time (and mostly for telemetry), removed overhead by O(1) CPU / memory. This removes 36.8% of CPU on the staging cluster I tested, quick win! ### Motivation ### Describe how you validated your changes [Profile](https://ddstaging.datadoghq.com/profiling/comparison?query=service%3Adatadog-agent%20kube_cluster_name%3Astingchameleon&compare_end_A=1786621749000&compare_end_B=1786626605000&compare_start_A=1786620495000&compare_start_B=1786625998000&compareValuesMode=absolute&my_code=enabled&profiling-flame-graph__filter=focus_on%28package%3Agithub.com%2FDataDog%2Fdatadog-agent%2Fcomp%2Fanomalydetection%29&viz=flame_graph&from_ts=1786623005144&to_ts=1786626605144&live=false) <img width=\"2375\" height=\"497\" alt=\"Screenshot 2026-08-13 at 15 21 37\" src=\"https://github.com/user-attachments/assets/126c3a5c-543e-4e92-8f02-4682e20e45e4\" /> ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54822",
        "createdAt": "2026-08-13T11:16:18Z",
        "updatedAt": "2026-08-13T14:51:48Z",
        "timestamp": "2026-08-13T14:51:48Z",
        "metrics": {
          "reactions": 2,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "medium review",
          "internal"
        ],
        "author": "CelianR",
        "state": "open",
        "assignees": [
          "CelianR"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54823",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "fix(aix): discover Python checks via integrations-core AIX manifest tag",
        "text": "### What does this PR do? Replaces the hardcoded AIX Python check list with dynamic discovery of every integrations-core check tagged `Supported OS::AIX`. ### Motivation Keep AIX in sync with integrations-core instead of drifting from a hand-maintained list. ### Describe how you validated your changes Ran the updated stage on an AIX 7.3 build host: it installed all currently AIX-tagged checks with no errors. ### Additional Notes `ibm_spectrum_lsf` is dropped — it was hardcoded before but never actually tagged for AIX upstream.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54823",
        "createdAt": "2026-08-13T11:32:13Z",
        "updatedAt": "2026-08-13T17:39:37Z",
        "timestamp": "2026-08-13T17:39:37Z",
        "metrics": {
          "reactions": 2,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "short review",
          "team/agent-build",
          "internal"
        ],
        "author": "pgimalac",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54824",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "feat(notableevents): add macOS shutdown-cause notable event",
        "text": "Reads the IOPMUBootFaultInfo IORegistry property to classify the previous boot's PMU fault tokens (thermal, power, crash, watchdog, hardware) and emit a notable event, independent of DiagnosticReports crash collection. Dedup is boot-scoped via a new ShutdownCause bookmark field, keeping the existing bookmark schema version at 1. <!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54824",
        "createdAt": "2026-08-13T11:42:34Z",
        "updatedAt": "2026-08-13T12:44:21Z",
        "timestamp": "2026-08-13T12:44:21Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "long review",
          "team/agent-build",
          "team/windows-products",
          "internal"
        ],
        "author": "PedroCordeiroDataDog",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54825",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "fix(flare): mark TestWindowsFlareSuite/TestFlareDefaultFiles as flaky",
        "text": "### What does this PR do? Mutes `test/new-e2e/tests/agent-subcommands.TestWindowsFlareSuite/TestFlareDefaultFiles` in `flakes.yaml`. ### Motivation This test has been reported failing intermittently in CI, tracked in [FLREM-146](https://datadoghq.atlassian.net/browse/FLREM-146). `TestWindowsFlareSuite` is a testify suite with other subtests that were never reported as flaky, so the entry is scoped to the exact failing subtest (`TestFlareDefaultFiles`) rather than muting the whole suite — same approach as #54759 for the sibling Linux/Windows flare suites. Muting it here unblocks other PRs from spurious CI failures while the underlying flakiness is investigated under that ticket. ### Describe how you validated your changes Validated `flakes.yaml` parses correctly and follows the existing file's format/conventions. ### Additional Notes [FLREM-146]: https://datadoghq.atlassian.net/browse/FLREM-146?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
        "url": "https://github.com/DataDog/datadog-agent/pull/54825",
        "createdAt": "2026-08-13T11:45:46Z",
        "updatedAt": "2026-08-13T12:20:03Z",
        "timestamp": "2026-08-13T12:20:03Z",
        "metrics": {
          "reactions": 2,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "short review",
          "internal"
        ],
        "author": "louis-cqrl",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54826",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[EBPF] Download gpu-burner for GPU tests",
        "text": "### What does this PR do? Downloads gpu-burner before GPU integration tests run. ### Motivation Allow the tests to use the gpu-burner mASS artifact. ### Describe how you validated your changes Confirmed the CI rules trigger `tests_gpu` for this file change. ### Additional Notes The referenced branch artifact expires after seven days.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54826",
        "createdAt": "2026-08-13T11:49:04Z",
        "updatedAt": "2026-08-13T13:58:45Z",
        "timestamp": "2026-08-13T13:58:45Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "team/ebpf-platform",
          "short review",
          "team/agent-devx",
          "team/agent-build",
          "internal",
          "team/gpu-monitoring-agent"
        ],
        "author": "gjulianm",
        "state": "open",
        "assignees": [
          "gjulianm"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54827",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[ACTP] Improve PAR error when an aciton is not allowed",
        "text": "## Description When a Private Action Runner (PAR) rejects an action because it's not in the runner's allowlist, the error message is unhelpful: action <fqn> is not in the allow list. Users have no guidance on how to resolve it.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54827",
        "createdAt": "2026-08-13T11:50:30Z",
        "updatedAt": "2026-08-13T12:58:51Z",
        "timestamp": "2026-08-13T12:58:51Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "short review",
          "team/action-platform",
          "internal"
        ],
        "author": "merchristK",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54828",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[EBPF] gpu: add NVLink capability tag",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds `gpu_nvlink_capable` and `gpu_nvlink_version` tags to GPU metrics. ### Motivation Knowing whether a GPU is NVlink-capable and the version of the NVlink system or not is useful to ensure the presence of certain metrics and to compare GPU performance. Another PR will also use part of this code to allow segmenting telemetry based on NVLink capability. ### Describe how you validated your changes Unit tests, manually validated in nvlink-enabled instance. ### Additional Notes Both tags might be slightly redundant but having two doesn't cost extra cardinality (gpu_uuid is already there, with one value per GPU) and it allows separating \"nvlink GPUs/non nvlink GPUs\" and between specific versions.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54828",
        "createdAt": "2026-08-13T11:52:04Z",
        "updatedAt": "2026-08-13T17:57:26Z",
        "timestamp": "2026-08-13T17:57:26Z",
        "metrics": {
          "reactions": 1,
          "comments": 6
        },
        "labels": [
          "team/ebpf-platform",
          "qa/done",
          "team/container-platform",
          "long review",
          "team/container-integrations",
          "internal",
          "team/gpu-monitoring-agent"
        ],
        "author": "gjulianm",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54829",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[EBPF] gpu: improve collector run telemetry",
        "text": "### What does this PR do? Improves the collector telemetry for the GPU check by adding a new counter for the number of runs per collector, and also adds device-related tags: device name, architecture, NVlink capabilities, MIG/vGPU state. ### Motivation Facilitate debugging and monitoring, with these tags we will be able to understand whether collectors are failing for specific GPU types for example. ### Describe how you validated your changes Ran the agent and validated that the telemetry has the necessary tags. ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54829",
        "createdAt": "2026-08-13T11:57:55Z",
        "updatedAt": "2026-08-13T14:25:28Z",
        "timestamp": "2026-08-13T14:25:28Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [],
        "author": "gjulianm",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54830",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Deflake `TestKeepTryingLockingIfPermissionDenied` with `synctest`",
        "text": "### What does this PR do? Wrap `TestKeepTryingLockingIfPermissionDenied`, `TestContextCancellation` and `TestHandleMultipleConcurrentWrites` in `synctest` \"bubbles\" by extracting their body into `sync<same name>` functions while dropping `t.Parallel()` (disallowed inside a bubble). Drop remaining `t.Parallel()` from the file's other 2 tests too (Bazel schedules this whole test binary as one action regardless of it). Also switch every `context.Background()` in the file to `t.Context()` for good measure (test-bound, canceled right before running Cleanup functions). ### Motivation `TestKeepTryingLockingIfPermissionDenied` races a 500ms retry loop against its own 2s context timeout using real time, so a scheduling stall near either boundary can flip a would-be success into a failure. It failed exactly that way in a local `bazel test` run on Linux: ``` --- FAIL: TestKeepTryingLockingIfPermissionDenied (3.00s) concurrent_write_test.go:212: Error Trace: pkg/util/filesystem/concurrent_write_test.go:212 Error: Received unexpected error: unable to read the artifact or acquire the lock in the given time open /tmp/TestKeepTryingLockingIfPermissionDenied252193597/001/test_artifact.lock: permission denied Test: TestKeepTryingLockingIfPermissionDenied concurrent_write_test.go:216: Error Trace: pkg/util/filesystem/concurrent_write_test.go:216 Error: Expected error with \"file does not exist\" in chain but got nil. Test: TestKeepTryingLockingIfPermissionDenied Messages: lock file should not exist after successful creation and concurrent reads ``` The flakiness may manifest itself in a slightly different way, like for instance in [a CI job](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1928209794#L476) on Windows where 2 `t.Parallel()` siblings in the same batch also ran multiple real seconds longer than their own logic requires, showing the whole binary stalled right when the retry loop needed to recheck the lock: ``` === NAME TestKeepTryingLockingIfPermissionDenied concurrent_write_test.go:212: Error Trace: pkg/util/filesystem/concurrent_write_test.go:212 Error: Received unexpected error: unable to read the artifact or acquire the lock in the given time Test: TestKeepTryingLockingIfPermissionDenied concurrent_write_test.go:216: Error Trace: pkg/util/filesystem/concurrent_write_test.go:216 Error: Expected error with \"file does not exist\" in chain but got nil. Test: TestKeepTryingLockingIfPermissionDenied Messages: lock file should not exist after successful creation and concurrent reads --- FAIL: TestKeepTryingLockingIfPermissionDenied (2.11s) ``` `TestContextCancellation` and `TestHandleMultipleConcurrentWrites` don't share that specific failure mode, but they do pay their timers' full real duration on every run regardless of load. ### Describe how you validated your changes Isolated timing before/after: - `TestKeepTryingLockingIfPermissionDenied`: 1.05s to 0.02s, - `TestContextCancellation`: 0.10s to 0.00s, - `TestHandleMultipleConcurrentWrites`: 0.50s to 0.05s. All tests pass 30/30 under `--config=gorace`, and the package passes 60/60 repeated runs under heavy artificial CPU oversubscription. ### Additional Notes Dropping `t.Parallel()` doesn't cost anything net: - ~1.65s before this change, - ~0.07s after. This is because virtualizing sleeps removes far more real time than serializing 5 tests loses.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54830",
        "createdAt": "2026-08-13T12:00:51Z",
        "updatedAt": "2026-08-13T15:28:26Z",
        "timestamp": "2026-08-13T15:28:26Z",
        "metrics": {
          "reactions": 2,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "short review",
          "team/agent-runtimes",
          "internal"
        ],
        "author": "rdesgroppes",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54831",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "test(e2e): add IBM MQ integration lab",
        "text": "### What does this PR do? Adds a deploy=true E2E-framework lab for the `ibm_mq` integration under `test/e2e-framework/scenarios/aws/integrations/ibm_mq`. The scenario self-provisions **IBM MQ Advanced for Developers 9.3** with a configurable number of queue managers and queues on a single amd64 RHEL 8 EC2 host, co-located with the Datadog Agent. A systemd-driven put/get load generator keeps queue depth and enqueue/dequeue metric families non-zero so the `ibm_mq` check has realistic work to do. It exposes knobs for: - queue-manager count and queues per manager - collection interval - queue selection strategy (auto-discovery / regex / explicit) - `collect_reset_queue_metrics` - metric exclusion patterns - integration and internal profiling Wiring: registered in the integrations `registry.go` + `BUILD.bazel`, and in the invoke task collection, giving the usual task surface: ``` dda inv aws.integrations.ibm-mq.{create,status,check,exec,ssh,destroy,reload-check} ``` ### Motivation Provide a reproducible, self-contained environment to investigate `ibm_mq` check CPU cost as queue-manager and queue counts scale — the check can become expensive with large queue counts and auto-discovery, and this lab makes that behavior easy to reproduce and profile in isolation. ### Describe how you validated your changes - `gofmt` clean on `registry.go` and all `ibm_mq/*.go`. - `go build ./scenarios/aws/integrations/...` in the `test/e2e-framework` module succeeds. - `dda inv aws.integrations -l` lists all `ibm-mq.*` tasks. - pre-commit hooks (shellcheck, go-fmt, copyright, python-linter, …) pass. ### Additional Notes Follows the existing integration-lab pattern (kafka, lustre, etc.). The scenario provisions billable EC2; remember to `dda inv aws.integrations.ibm-mq.destroy` when finished.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54831",
        "createdAt": "2026-08-13T13:26:11Z",
        "updatedAt": "2026-08-13T16:42:05Z",
        "timestamp": "2026-08-13T16:42:05Z",
        "metrics": {
          "reactions": 1,
          "comments": 2
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "long review",
          "team/agent-integrations",
          "team/agent-build",
          "internal"
        ],
        "author": "dkirov-dd",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54832",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Add a lightweight gate for prepared Agent rollouts",
        "text": "### What does this PR do? Adds an experimental Linux `agent-rollout-gate` binary to the Agent images used by the node Agent. The Operator can place this binary in front of each Agent container. The gate acquires a component-specific host lock before it starts the real process, so a replacement Pod can be pulled, created, and kept sleeping beside the serving Pod without initializing a second Agent. Each component hands off independently; a slow `system-probe` shutdown does not block the core or trace Agent. While sleeping, the gate's startup probe remains failed indefinitely. Readiness and liveness probes are unchanged and do not run until startup succeeds. After lock acquisition, the gate starts the Agent and preserves the original startup failure budget and termination behavior. ### Motivation Today a DaemonSet update deletes the old Agent before the replacement image is pulled and initialized. Slow or failed pulls therefore create node-level telemetry gaps. This gate supplies the Agent-side primitive for the paired-DaemonSet Operator PoC: prepare the replacement first, then hand over each node-local listener and UDS owner. This does **not** claim zero-gap telemetry. Agent caches, Cluster Agent assignments, metadata, and process state still start cold after handoff. ### Describe how you validated your changes - `dda inv test --targets=./cmd/agent-rollout-gate` — 6 tests passed on Darwin - `dda inv agent-rollout-gate.build` — passed - `dda inv linter.go --targets=./cmd/agent-rollout-gate` — 0 issues - mandatory pre-commit and pre-push hooks — passed The lock, signal, and startup-probe tests are Linux-only and must pass in CI. Experimental-cluster validation is intentionally deferred until both PoCs have been reviewed. The `qa/done` label is intentionally not set until that cluster validation is complete, so the repository's QA-label check is expected to remain red during review. ### Additional Notes - Experimental and Linux-only. - Must be deployed conventionally before opting a `DatadogAgent` into the Operator PoC. - Companion Operator PoC: https://github.com/DataDog/datadog-operator/pull/3355 - Capacity fallback may deliberately use delete-first replacement and reintroduce baseline downtime.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54832",
        "createdAt": "2026-08-13T13:47:40Z",
        "updatedAt": "2026-08-13T15:01:44Z",
        "timestamp": "2026-08-13T15:01:44Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "team/container-platform",
          "long review",
          "team/agent-runtimes",
          "team/agent-devx",
          "team/agent-build",
          "team/profiling-full-host",
          "internal",
          "team/fleet-remediation"
        ],
        "author": "AliDatadog",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54833",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "SMP experiment selection and codeowners v2",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Classifies SMP experiments into three modes: always: as the name implies, they always run, these are the quality gates codeowners: these experiments x, owned by team y, are automatically triggered if the the PR touches a file owned by y optional: fully manual, label triggered set of experiments used for specific features ### Motivation ### Describe how you validated your changes ### Additional Notes No need for review yet, this is a POC that will be split",
        "url": "https://github.com/DataDog/datadog-agent/pull/54833",
        "createdAt": "2026-08-13T13:59:48Z",
        "updatedAt": "2026-08-13T18:00:44Z",
        "timestamp": "2026-08-13T18:00:44Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "team/agent-security",
          "long review",
          "team/agent-log-pipelines",
          "team/agent-devx",
          "team/action-platform",
          "internal",
          "smp/logs/syslog"
        ],
        "author": "cmetz100",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54834",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "ci: default GitLab jobs to shallow clones, keep full history where needed",
        "text": "## Summary - Default GitLab jobs to `GIT_DEPTH: 1` so most checkouts are a shallow clone of HEAD only. - Set `GIT_DEPTH: 0` on jobs that actually need git history (merge-base, ancestor walks, `git describe`, `git log` ranges, three-dot diffs, or checkout of another branch). - Jobs that inherit a full-history template but never use merge-base stay at depth 1 (`new-e2e-unit-tests`, upgrade/RPM install-package jobs). - `GIT_STRATEGY: clone` is not a full clone; clone with depth 1 is still shallow. Full history requires `GIT_DEPTH: 0`. Supersedes https://github.com/DataDog/datadog-agent/pull/54799 (opened from a fork). ## Test plan - [ ] Confirm a typical build/lint job clones with depth 1 and still has the working tree. - [ ] Confirm jobs that compute merge-base still succeed (`golang_deps_diff`, e2e `--impacted`, `static_quality_gates`, `files_inventory_check`, SMP merge-base check). - [ ] Confirm `setup_agent_version` can still run `git describe --tags`. - [ ] Confirm unit-test jobs with `FAST_TESTS=true` still detect impacted packages. - [ ] Confirm `benchmark` can check out `BASE_BRANCH` and `prebuild-workspace-image-check` can three-dot diff against `COMPARE_TO_BRANCH`. Made with [Cursor](https://cursor.com)",
        "url": "https://github.com/DataDog/datadog-agent/pull/54834",
        "createdAt": "2026-08-13T14:03:09Z",
        "updatedAt": "2026-08-13T17:58:00Z",
        "timestamp": "2026-08-13T17:58:00Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "team/agent-apm",
          "team/agent-security",
          "team/ebpf-platform",
          "qa/no-code-change",
          "team/container-platform",
          "team/agent-delivery",
          "long review",
          "team/agent-integrations",
          "team/container-integrations",
          "team/agent-devx",
          "team/agent-build",
          "team/windows-products",
          "team/profiling-full-host",
          "internal"
        ],
        "author": "mikesherovdd",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54835",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[ACTP] PAR secret resolution v2",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54835",
        "createdAt": "2026-08-13T14:21:30Z",
        "updatedAt": "2026-08-13T16:05:19Z",
        "timestamp": "2026-08-13T16:05:19Z",
        "metrics": {
          "reactions": 2,
          "comments": 6
        },
        "labels": [
          "team/container-platform",
          "long review",
          "team/agent-build",
          "team/action-platform",
          "internal"
        ],
        "author": "dd-gplassard",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54836",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Commit the configuration examples to the repo",
        "text": "### What does this PR do? Those example will be updated each time we release a new Agent",
        "url": "https://github.com/DataDog/datadog-agent/pull/54836",
        "createdAt": "2026-08-13T14:54:10Z",
        "updatedAt": "2026-08-13T15:54:15Z",
        "timestamp": "2026-08-13T15:54:15Z",
        "metrics": {
          "reactions": 2,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "qa/done",
          "long review",
          "team/agent-runtimes",
          "team/agent-configuration",
          "team/agent-devx",
          "team/agent-build",
          "team/windows-products",
          "internal",
          "team/fleet-automation"
        ],
        "author": "hush-hush",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54837",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "feat(autodiscovery): tag configuration-discovery instances to mitigate duplicate metrics risk (#54660)",
        "text": "Adds a `dd_config_discovery:true` tag to every check instance scheduled via the Autodiscovery configuration-discovery mechanism (i.e. any `auto_conf.yaml` template with `discovery: {}`, resolved through `comp/core/autodiscovery/impl/configmgr_discovery.go`'s `applyDiscoveredConfigsLocked`). The tag used is `dd_config_discovery:true`, a plain `dd_`-prefixed key, following the precedent of other agent-added, customer-visible marker/provenance tags already in the codebase: - `dd_remote_config_id` / `dd_remote_config_rev` (`comp/core/tagger/tags/tags.go`) - `dd_enable_check_intake` (`pkg/collector/worker/worker.go`) [DSCVR-651](https://datadoghq.atlassian.net/browse/DSCVR-651): there is a risk that an agent on host A is monitoring a service on host B with a manually-configured check (e.g. a generic `openmetrics` check), while the agent running locally on host B also autodiscovers and schedules a dedicated integration for the same service via configuration discovery. Neither agent's local anti-duplication logic can see the other's config, so both submit metrics for the same underlying data. This tag doesn't prevent the duplication, but lets users identify and, if needed, exclude the autodiscovered side of it (e.g. `metric{!dd_config_discovery:true}`), both for the cross-host case above and for any single-host case the automatic suppression doesn't catch. Unit and E2E tests. --- 🤖 This PR description and implementation were generated with assistance from [Claude Code](https://claude.com/claude-code). [DSCVR-651]: https://datadoghq.atlassian.net/browse/DSCVR-651?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ Co-authored-by: vincent.whitchurch <vincent.whitchurch@datadoghq.com> (cherry picked from commit 0b134fce442c8d3c923e7159b07d614e050f5df1) Conflicts: test/new-e2e/tests/discovery/BUILD.bazel",
        "url": "https://github.com/DataDog/datadog-agent/pull/54837",
        "createdAt": "2026-08-13T15:12:02Z",
        "updatedAt": "2026-08-13T16:16:20Z",
        "timestamp": "2026-08-13T16:16:20Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [
          "qa/done",
          "team/container-platform",
          "medium review",
          "team/agent-discovery",
          "team/agent-build",
          "internal"
        ],
        "author": "vitkyrka",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54838",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[ACTP] test CONNECTION_TOKENS_V2 Agent secret resolution",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54838",
        "createdAt": "2026-08-13T15:20:01Z",
        "updatedAt": "2026-08-13T17:12:48Z",
        "timestamp": "2026-08-13T17:12:48Z",
        "metrics": {
          "reactions": 1,
          "comments": 4
        },
        "labels": [],
        "author": "dd-gplassard",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54839",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Remove buildschema legacy command",
        "text": "### What does this PR do? Now that the schema is the source of truth we no longer need that command",
        "url": "https://github.com/DataDog/datadog-agent/pull/54839",
        "createdAt": "2026-08-13T15:20:20Z",
        "updatedAt": "2026-08-13T15:28:41Z",
        "timestamp": "2026-08-13T15:28:41Z",
        "metrics": {
          "reactions": 2,
          "comments": 0
        },
        "labels": [
          "component/system-probe",
          "long review",
          "team/agent-runtimes",
          "team/agent-build",
          "internal",
          "team/fleet-remediation",
          "team/fleet-automation"
        ],
        "author": "hush-hush",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54840",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[CONTP-2006] feat(ddi): Add resolved target to workloadmeta",
        "text": "### What does this PR do? Adds group- and version-aware resolved workload targets to Kubernetes Pod workload metadata and the workload-filter CEL model. - Preserves `apiVersion` and `controller` from Kubernetes owner references in both Pod parsers. - Adds `KubernetesPod.ResolvedTargets` with group, version, kind, namespace, name, and UID identity. - Exposes resolved targets to CEL as `container.pod.resolved_targets`. This is an additive data-model change and does not alter current DatadogInstrumentation matching behavior. ### Motivation [CONTP-2006](https://datadoghq.atlassian.net/browse/CONTP-2006) DatadogInstrumentation currently matches workload Pods through `rootowner`, which only carries kind and name and relies on built-in ownership conventions. Supporting arbitrary workload CRs requires a structured, API-group-aware identity that can distinguish identical kinds from different API groups and carry targets resolved by the Cluster Agent to CEL evaluation. ### Describe how you validated your changes ### Additional Notes [CONTP-2006]: https://datadoghq.atlassian.net/browse/CONTP-2006?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
        "url": "https://github.com/DataDog/datadog-agent/pull/54840",
        "createdAt": "2026-08-13T15:44:42Z",
        "updatedAt": "2026-08-13T17:43:01Z",
        "timestamp": "2026-08-13T17:43:01Z",
        "metrics": {
          "reactions": 1,
          "comments": 6
        },
        "labels": [
          "changelog/no-changelog",
          "qa/no-code-change",
          "team/container-platform",
          "medium review",
          "team/container-integrations",
          "team/agent-runtimes",
          "team/agent-build",
          "internal"
        ],
        "author": "Mathew-Estafanous",
        "state": "open",
        "assignees": [
          "Mathew-Estafanous"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54841",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[CONTP-2006] feat(ddi): Stream resolved targets from DCA to node agent",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Streams per-Pod resolved workload targets from the Cluster Agent to Node Agents through the Kubernetes metadata stream. - Adds a generic `PodTargetResolver` interface to keep the transport independent from the DDI resolver implementation. - Includes resolved targets in initial full-state responses and incremental `SET` and `UNSET` updates scoped to each node. - Enriches Node Agent Pod workload metadata when resolved targets change. No production resolver is wired in this PR, so the new transport remains dormant until a later change supplies resolved targets. ### Motivation [CONTP-2006](https://datadoghq.atlassian.net/browse/CONTP-2006) Custom owner-chain resolution belongs in the Cluster Agent, where Kubernetes API access is centralized, while Autodiscovery CEL matching runs on each Node Agent. A node-scoped transport is therefore required to deliver resolved target identity without granting every Node Agent access to arbitrary workload resources. ### Describe how you validated your changes ### Additional Notes [CONTP-2006]: https://datadoghq.atlassian.net/browse/CONTP-2006?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
        "url": "https://github.com/DataDog/datadog-agent/pull/54841",
        "createdAt": "2026-08-13T15:46:01Z",
        "updatedAt": "2026-08-13T17:43:18Z",
        "timestamp": "2026-08-13T17:43:18Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "team/container-platform",
          "medium review",
          "team/container-integrations",
          "team/agent-build",
          "internal"
        ],
        "author": "Mathew-Estafanous",
        "state": "open",
        "assignees": [
          "Mathew-Estafanous"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54842",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[CONTP-2006] feat(ddi): Add pod workload target resolution",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds a registry and owner-chain resolver for DatadogInstrumentation workload targets. - Models built-in and customer-configured workload profiles using a `target` resource and optional `via` resources. - Identifies every resource by `apiVersion`, kind, and plural resource name. - Walks controller owner references with the dynamic Kubernetes client, validates owner UIDs, caches resolved owners, and limits traversal depth. This PR only introduces the resolver package. It does not expose or activate custom workload target configuration. ### Motivation [CONTP-2006](https://datadoghq.atlassian.net/browse/CONTP-2006) Hard-coding every operator-managed workload does not scale and cannot represent indirect ownership such as Pod to Job to a custom workload. Explicit target and traversal profiles provide a general mechanism that distinguishes API groups and allows deployments to grant read access only to the intermediate resources required for resolution. ### Describe how you validated your changes ### Additional Notes [CONTP-2006]: https://datadoghq.atlassian.net/browse/CONTP-2006?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
        "url": "https://github.com/DataDog/datadog-agent/pull/54842",
        "createdAt": "2026-08-13T15:51:31Z",
        "updatedAt": "2026-08-13T17:43:26Z",
        "timestamp": "2026-08-13T17:43:26Z",
        "metrics": {
          "reactions": 1,
          "comments": 5
        },
        "labels": [
          "changelog/no-changelog",
          "team/container-platform",
          "medium review",
          "team/agent-build",
          "internal"
        ],
        "author": "Mathew-Estafanous",
        "state": "open",
        "assignees": [
          "Mathew-Estafanous"
        ]
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54843",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[CONTP-2006] feat(ddi): Connect custom workload targets to DDI controller and streaming",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Connects configurable workload target resolution to DatadogInstrumentation checks and logs. - Adds `instrumentation_crd_controller.custom_workload_targets` configuration. - Starts the Pod workloadmeta store and resolver when at least one custom target is configured. - Accepts registered target GVKs and generates CEL selectors against `container.pod.resolved_targets`. - Includes `apiVersion` when detecting duplicate target references. - Preserves `rootowner` matching for built-in workloads and EndpointSlice delivery for core `v1` Services. For example, a workload reached through an intermediate Kubernetes Job can be configured as: ```yaml instrumentation_crd_controller: custom_workload_targets: - target: apiVersion: example.com/v1 kind: ScheduledWorkload resource: scheduledworkloads via: - apiVersion: batch/v1 kind: Job resource: jobs ``` ### Motivation [CONTP-2006](https://datadoghq.atlassian.net/browse/CONTP-2006) DatadogInstrumentation supports core Kubernetes workload kinds and Argo Rollouts out of the box, but customers also run workloads through controllers such as Ray, Kueue, OpenKruise, and Strimzi. Customers need an opt-in way to declare the workload resources they use and the ownership path from Pods, without relying on a generic fallback or requiring every custom kind to be added to the Agent. ### Describe how you validated your changes ### Additional Notes [CONTP-2006]: https://datadoghq.atlassian.net/browse/CONTP-2006?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
        "url": "https://github.com/DataDog/datadog-agent/pull/54843",
        "createdAt": "2026-08-13T15:53:26Z",
        "updatedAt": "2026-08-13T17:54:16Z",
        "timestamp": "2026-08-13T17:54:16Z",
        "metrics": {
          "reactions": 1,
          "comments": 6
        },
        "labels": [
          "team/container-platform",
          "long review",
          "team/container-integrations",
          "team/agent-build",
          "internal",
          "team/fleet-automation"
        ],
        "author": "Mathew-Estafanous",
        "state": "open",
        "assignees": [],
        "change": "updated"
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54845",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[release] Update release.json for 7.83.0-rc.3",
        "url": "https://github.com/DataDog/datadog-agent/pull/54845",
        "createdAt": "2026-08-13T16:01:16Z",
        "updatedAt": "2026-08-13T17:15:57Z",
        "timestamp": "2026-08-13T17:15:57Z",
        "metrics": {
          "reactions": 2,
          "comments": 4
        },
        "labels": [
          "changelog/no-changelog",
          "component/system-probe",
          "qa/no-code-change",
          "team/agent-delivery",
          "long review",
          "team/agent-runtimes",
          "internal"
        ],
        "author": "temporal-github-worker-1[bot]",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54846",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Add provisioner-independent agent installers",
        "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54846",
        "createdAt": "2026-08-13T16:25:15Z",
        "updatedAt": "2026-08-13T16:45:43Z",
        "timestamp": "2026-08-13T16:45:43Z",
        "metrics": {
          "reactions": 1,
          "comments": 2
        },
        "labels": [
          "long review",
          "team/agent-devx",
          "team/agent-build",
          "internal"
        ],
        "author": "KevinFairise2",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54847",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[Backport 7.83.x]  [EBPF] gpu: Support ARM64 NVML library discovery",
        "text": "Backport 5dcbd3081dd283e30cf25879eb5be7b55577e50a from #54720. ___ <!-- dd-meta {\"pullId\":\"df13230b-a434-451b-972e-ac9007c02168\",\"source\":\"chat\",\"resourceId\":\"86800824-17f2-4a85-9551-be5b7bf8a830\",\"workflowId\":\"2ce581a4-a03e-4c0a-a1a1-dda5b27f5a0c\",\"codeChangeId\":\"2ce581a4-a03e-4c0a-a1a1-dda5b27f5a0c\",\"sourceType\":\"bits_ai_sre\"} --> ### What does this PR do? Bits AI SRE Investigation • [View in Bits AI SRE Investigation](https://ddstaging.datadoghq.com/bits-ai/investigations/8418dc69-efd2-44d3-ad70-91e14223f69d) Add standard ARM64 (`aarch64-linux-gnu`) NVML library paths for host and NVIDIA GPU Operator installations. ### Motivation GPU checks on ARM64 GPU nodes fail because NVML discovery searches only x86_64 library directories. This causes all GPU metrics to fail on affected ARM64 nodes and can trigger incorrect health responses. ### Describe how you validated your changes Unit tests added ### Additional Notes --- PR by Bits - [View session in Datadog](https://ddstaging.datadoghq.com/code/86800824-17f2-4a85-9551-be5b7bf8a830) Comment @datadog to request changes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54847",
        "createdAt": "2026-08-13T16:30:11Z",
        "updatedAt": "2026-08-13T17:44:41Z",
        "timestamp": "2026-08-13T17:44:41Z",
        "metrics": {
          "reactions": 2,
          "comments": 3
        },
        "labels": [
          "changelog/no-changelog",
          "team/ebpf-platform",
          "qa/done",
          "backport",
          "bot",
          "team/container-platform",
          "medium review",
          "team/container-integrations",
          "Bits AI",
          "internal",
          "team/gpu-monitoring-agent",
          "team/fleet-automation"
        ],
        "author": "dd-octo-sts[bot]",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54848",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "fix(cloudfoundry): avoid nil panic on failed DCA connection",
        "text": "## TL;DR Fixes a nil pointer dereference in the `cloudfoundry-vm` workloadmeta collector that crashes the node Agent on Cloud Foundry when the connection to the Cluster Agent fails. Regressed in 7.81. ## Motivation Agents on Cloud Foundry running 7.81+ panic repeatedly with: ``` panic: runtime error: invalid memory address or nil pointer dereference clusteragent.(*DCAClient).buildURL(...) clusteragent.go:271 clusteragent.(*DCAClient).GetCFAppsMetadataForNode(0x0, ...) cloudfoundry/vm.(*collector).Pull(...) cf_vm.go:111 ``` Root cause: `getDCAClient()` assigns `clusteragent.GetClusterAgentClient()` (return type `(*DCAClient, error)`) directly into the `c.dcaClient` interface field *before* checking the error. On a failed connection the returned nil `*DCAClient` is boxed into the interface, producing a non-nil \"typed nil\". The next `Pull` passes the `c.dcaClient != nil` cache check and calls `GetCFAppsMetadataForNode` on the nil receiver, panicking. This became reachable in 7.81 when #50814 changed `GetClusterAgentClient`'s return type from `DCAClientInterface` to `*DCAClient`. Before that, the error path returned a true nil interface, so the field was never poisoned. 7.80.4 is unaffected. ## What this does - `getDCAClient`: assign the result to a local `*DCAClient` and only store it into `c.dcaClient` on success. - `Pull`: call the local `dcaClient` returned by `getDCAClient()` instead of the field `c.dcaClient`. ## Validation / Testing - Added `TestPullDCAConnectionFailureDoesNotPanic`: two `Pull`s with `dcaEnabled=true` and no reachable Cluster Agent; asserts the second does not panic. - Verified the test is a real regression guard: reverting the fix makes it panic at `cf_vm.go:111` (the exact crash line); with the fix all package tests pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
        "url": "https://github.com/DataDog/datadog-agent/pull/54848",
        "createdAt": "2026-08-13T16:38:07Z",
        "updatedAt": "2026-08-13T16:41:11Z",
        "timestamp": "2026-08-13T16:41:11Z",
        "metrics": {
          "reactions": 2,
          "comments": 2
        },
        "labels": [
          "short review",
          "team/agent-integrations",
          "internal"
        ],
        "author": "NouemanKHAL",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54849",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Draft: SMP - locally-rendered CI report",
        "text": "### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
        "url": "https://github.com/DataDog/datadog-agent/pull/54849",
        "createdAt": "2026-08-13T16:48:49Z",
        "updatedAt": "2026-08-13T17:01:59Z",
        "timestamp": "2026-08-13T17:01:59Z",
        "metrics": {
          "reactions": 2,
          "comments": 4
        },
        "labels": [
          "medium review",
          "internal"
        ],
        "author": "Arpafaucon",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54850",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Bump internal agent image to tmpl-v26 (check_intake_queue 1.5.0)",
        "text": "### What Points the uncompressed `-jmx` and `-fips` internal `datadog-agent` image builds at `datadog-agent/tmpl-v26` (was `tmpl-v25`) in the images repo. ```diff publish_internal_container_image-jmx / -fips: - COMPRESSION: \"\" - IMAGE_VERSION: tmpl-v25 + IMAGE_VERSION: tmpl-v26 ``` ### Why `tmpl-v26` bumps `check_intake_queue` `1.3.2 -> 1.5.0` (cell-tagged zero for empty intake queue; DataDog/integrations-internal#283). The new template was added in DataDog/images#11094 instead of modifying `tmpl-v25` in place — the in-place bump (images#11084) is being reverted in images#11093.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54850",
        "createdAt": "2026-08-13T17:13:48Z",
        "updatedAt": "2026-08-13T17:30:34Z",
        "timestamp": "2026-08-13T17:30:34Z",
        "metrics": {
          "reactions": 2,
          "comments": 3
        },
        "labels": [
          "community",
          "team/agent-delivery"
        ],
        "author": "alyssamui2",
        "state": "closed",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54851",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "Bump internal agent image to tmpl-v26 (check_intake_queue 1.5.0)",
        "text": "### What does this PR do? Points the uncompressed `-jmx` and `-fips` internal `datadog-agent` image builds at `datadog-agent/tmpl-v26` (was `tmpl-v25`) in the images repo: ```diff publish_internal_container_image-jmx / -fips: - COMPRESSION: \"\" - IMAGE_VERSION: tmpl-v25 + IMAGE_VERSION: tmpl-v26 ``` ### Motivation `tmpl-v26` bumps `check_intake_queue` `1.3.2 -> 1.5.0` (cell-tagged zero for an empty intake queue; DataDog/integrations-internal#283). The template was added in DataDog/images#11094 rather than editing `tmpl-v25` in place — the in-place bump (images#11084) is being reverted in images#11093. Only the uncompressed variant is bumped; `-nydus`/`-zstd` stay on `tmpl-v24` per request.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54851",
        "createdAt": "2026-08-13T17:30:18Z",
        "updatedAt": "2026-08-13T17:31:53Z",
        "timestamp": "2026-08-13T17:31:53Z",
        "metrics": {
          "reactions": 1,
          "comments": 2
        },
        "labels": [
          "community",
          "team/agent-delivery"
        ],
        "author": "alyssamui2",
        "state": "open",
        "assignees": []
      },
      {
        "id": "github:DataDog/datadog-agent:pull_request:54852",
        "source": "github",
        "group": "observability",
        "project": "DataDog/datadog-agent",
        "kind": "pull_request",
        "title": "[NTWK-812] Filter dynamic tests across all reverse-DNS names",
        "text": "What does this PR do? Fixes Network Path dynamic tests scheduling traceroutes against Datadog's own intake backends (e.g. l4-metrics-agent-*.elb.us-east-1.amazonaws.com) despite the default *.datadoghq.com connection-filter exclude. - Adds ConnFilter.EvaluateDomains(domains, ip), which evaluates every DNS name a destination IP reverse-resolves to (via the existing last-match-wins chain) instead of only the first. A connection is excluded if any of its names is excluded, and the returned hostname is the preferred name for the path test (an include-matched name, else the first included name). - Plumbs the full name list end-to-end: adds Domains []string to NetworkPathConnection, a getDNSNamesForIP helper in both connection builders (pkg/network/sender, pkg/process/checks), and wires npcollector to filter on it and use the selected hostname. - Adds l4-metrics-agent-*.elb.*.amazonaws.com to the default excludes as hardening for the case where only the ELB name is cached. Customer include filters still override the defaults, so Datadog domains can be re-enabled if desired. Motivation [NTWK-812 / ZD 2972181](https://datadoghq.atlassian.net/browse/NTWK-812). A destination IP for a Datadog intake endpoint reverse-resolves to more than one name: the queried *.datadoghq.com name and the AWS ELB hostname it's CNAME'd to (short A-record TTLs cause resolvers to re-query the ELB target directly). getDNSNameForIP collapsed that list to dnsEntry[0], so when the ELB name was selected first the *.datadoghq.com exclude never fired — nondeterministically, depending on cache ordering. For the reporting org this was ~37% of dynamic test runs (>3,000/day), which also drives unnecessary billing. Describe how you validated your changes - New unit tests in connfilter_test.go: - TestEvaluateDomains — the CNAME gap with both name orderings, ELB-name-only, unrelated names, the customer-include override case, and empty input. - TestEvaluateDomainsPrefersIncludeMatchedName — an RC-include-matched name is chosen as the path test hostname even when it isn't first. - Extended TestNewConnFilter with the intake-ELB default exclude (and a customer-ELB negative case). - dda inv test --targets=./comp/networkpath/npcollector/... ./pkg/process/checks/ — all networkpath + connection tests pass. (TestProcessDiscoveryCheck fails identically on main on this platform; unrelated and pre-existing.) Additional Notes - Behavior change worth a reviewer's eye: \"any excluded name → exclude the connection\" means if a customer excludes name A and the IP also resolves to a fine name B, the connection is now dropped. Intended (they asked to exclude that destination), but flagging it. - The l4-metrics-agent-* default only covers one intake family; with the multi-name fix it's a secondary safety net rather than the primary fix. If we want the other intake ELB prefixes as defaults, we'd need the authorie/networking team. - sender_linux.go / sender/dns.go are Linux-only and couldn't bemacOS (cgo cross-compile); their changes are a one-field additionplus a mirror of the existing getDNSNameForIP — relying on CI fold. Ran 1 shell command Commit a63bb24aa84 is ready on branch netpath-812-exclude-intake/-22). Push to origin/netpath-812-exclude-intake-elb-cnames? Once you confirm, I'll run git push origin netpath-812-exclude-intake-elb-cnames. Reminder before you decide: the two Linux-only files (sender_linux.go, sender/dns.go) couldn't be compiled locally (cgo cross-compile), so first CI on this branch is where they get a real build — worth watching that pipeline after the push. ✻ Brewed for 1m 2s ❯ confirmed Pushed to netpath-812-exclude-intake-elb-cnames Pushed successfully — branch netpath-812-exclude-intake-elb-cnames is now on origin (new branch, tracking set up earlier). Next steps you may want: - Open the PR: https://github.com/DataDog/datadog-agent/pull/new/netpath-812-exclude-intake-elb-cnames — I can do this via the create-pr skill (I'll flag the Linux-build/CI caveat and the \"any-excluded-name excludes ththe description). - Watch CI: this is where the two Linux-only files get their first real compile. I can follow the pipeline with the follow-pr skill once a PR exists. - Update NTWK-812: post a triage-format update linking the branch/PR. Want me to open the PR? ✻ Baked for 26s ❯ Can you create a PR description for me that I can copy/paste? Let me pull the repo's PR template so the description matches wh Read 1 file Here's a copy/paste-ready PR description following the repo template: --- ### What does this PR do? Fixes Network Path dynamic tests scheduling traceroutes against Datadog's own intake backends (e.g. l4-metrics-agent-*.elb.us-east-1.amazonaws.com) despite the default *.datadoghq.com connection-filter exclude. - Adds ConnFilter.EvaluateDomains(domains, ip), which evaluates every DNS name a destination IP reverse-resolves to (via the existing last-match-wins chain) instead of only the first. A connection is excluded if any of its names is excluded, and the returned hostname is the preferred name for the path test (an include-matched name, else the first included name). - Plumbs the full name list end-to-end: adds Domains []string togetDNSNamesForIP helper in both connection builders(pkg/network/sender, pkg/process/checks), and wires npcollector to filter on it and use the selected hostname. - Adds l4-metrics-agent-*.elb.*.amazonaws.com to the default excludes as hardening for the case where only the ELB name is cached. Customer include filters still override the defaults, so Datadog if desired. ### Motivation NTWK-812 / ZD 2972181. A destination IP for a Datadog intake endmore than one name: the queried *.datadoghq.com name and the AWSELB hostname it's CNAME'd to (short A-record TTLs cause resolvers to re-query the ELB target directly). getDNSNameForIP collapsed that list to dnsEntry[0], so when the ELB name was selected first the *.datadoghq.com exclude never fired — nondeterministically, depending on cache ordering. For the reporting org this was ~37% of dynamic test runs (>3,000/day), which also drives unnecessary billing. Describe how you validated your changes - New unit tests in connfilter_test.go: - TestEvaluateDomains — the CNAME gap with both name orderings, ELB-name-only, unrelated names, the customer-include override case, and empty input. - TestEvaluateDomainsPrefersIncludeMatchedName — an RC-include-matched name is chosen as the path test hostname even when it isn't first. - Extended TestNewConnFilter with the intake-ELB default excluative case). - dda inv test --targets=./comp/networkpath/npcollector/... ./pkg/process/checks/ — all networkpath + connection tests pass. (TestProcessDiscoveryCheck fails identically on main on this platform; unrelated and pre-ex ### Additional Notes - Behavior change worth a reviewer's eye: \"any excluded name → ens if a customer excludes name A and the IP also resolves to afine name B, the connection is now dropped. Intended (they asked to exclude that destination), but flagging it. - The l4-metrics-agent-* default only covers one intake family; 's a secondary safety net rather than the primary fix. If we wantthe other intake ELB prefixes as defaults, we'd need the authoritative list from the intake/networking team. - sender_linux.go / sender/dns.go are Linux-only and couldn't bemacOS (cgo cross-compile); their changes are a one-field additionplus a mirror of the existing getDNSNameForIP — relying on CI for the first real Linux build.",
        "url": "https://github.com/DataDog/datadog-agent/pull/54852",
        "createdAt": "2026-08-13T17:33:46Z",
        "updatedAt": "2026-08-13T17:57:36Z",
        "timestamp": "2026-08-13T17:57:36Z",
        "metrics": {
          "reactions": 1,
          "comments": 2
        },
        "labels": [
          "component/system-probe",
          "medium review",
          "team/cloud-network-monitoring",
          "team/network-path",
          "internal"
        ],
        "author": "ken-schneider",
        "state": "open",
        "assignees": [],
        "change": "updated"
      }
    ],
    "events": [
      {
        "id": "event:dc4db8d5e95f14d3316a",
        "signalId": "github:DataDog/datadog-agent:pull_request:54832",
        "event": "discovered",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54832",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add a lightweight gate for prepared Agent rollouts",
          "text": "### What does this PR do? Adds an experimental Linux `agent-rollout-gate` binary to the Agent images used by the node Agent. The Operator can place this binary in front of each Agent container. The gate acquires a component-specific host lock before it starts the real process, so a replacement Pod can be pulled, created, and kept sleeping beside the serving Pod without initializing a second Agent. Each component hands off independently; a slow `system-probe` shutdown does not block the core or trace Agent. While sleeping, the gate's startup probe remains failed indefinitely. Readiness and liveness probes are unchanged and do not run until startup succeeds. After lock acquisition, the gate starts the Agent and preserves the original startup failure budget and termination behavior. ### Motivation Today a DaemonSet update deletes the old Agent before the replacement image is pulled and initialized. Slow or failed pulls therefore create node-level telemetry gaps. This gate supplies the Agent-side primitive for the paired-DaemonSet Operator PoC: prepare the replacement first, then hand over each node-local listener and UDS owner. This does **not** claim zero-gap telemetry. Agent caches, Cluster Agent assignments, metadata, and process state still start cold after handoff. ### Describe how you validated your changes - `dda inv test --targets=./cmd/agent-rollout-gate` — 6 tests passed on Darwin - `dda inv agent-rollout-gate.build` — passed - `dda inv linter.go --targets=./cmd/agent-rollout-gate` — 0 issues - mandatory pre-commit and pre-push hooks — passed The lock, signal, and startup-probe tests are Linux-only and must pass in CI. Experimental-cluster validation is intentionally deferred until both PoCs have been reviewed. ### Additional Notes - Experimental and Linux-only. - Must be deployed conventionally before opting a `DatadogAgent` into the Operator PoC. - The paired Operator PR will be linked here after creation. - Capacity fallback may deliberately use delete-first replacement and reintroduce baseline downtime.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54832",
          "createdAt": "2026-08-13T13:47:40Z",
          "updatedAt": "2026-08-13T13:47:51Z",
          "timestamp": "2026-08-13T13:47:51Z",
          "metrics": {
            "reactions": 2,
            "comments": 1
          },
          "labels": [],
          "author": "AliDatadog",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:89447e8f961f18a8e9fe",
        "signalId": "github:DataDog/datadog-agent:pull_request:54645",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54645",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix: avoid data race in grpclog.SetLogger on otelcol collector start",
          "text": "### What does this PR do? Sets `SkipSettingGRPCLogger: true` on the `otelcol.CollectorSettings` for the otel-agent and host-profiler collectors, so `otelcol.(*Collector).Run` no longer calls the non-mutex-protected `grpclog.SetLogger` while other gRPC clients (e.g. remote-config/remote-tagger) are active in the same process. ### Motivation Fix a race, found via a race-detector-enabled build in staging. ### Describe how you validated your changes Ran `./comp/otelcol/...` and `./comp/host-profiler/collector/...` tests (including with `--race`) and built `otel-agent`/`host-profiler`, all passing; a real regression test isn't feasible since the race needs real concurrent gRPC/otelcol startup. ### Additional Notes No log routing is lost: `comp/core/tagger/impl-remote` (pulled in by both otel-agent and host-profiler) already sets a Datadog-logger-backed `grpclog` logger in its package `init()`, which runs once before `main()` and is therefore race-free. Skipping otelcol's later, racy `SetLogger` call just stops it from unsafely clobbering that existing assignment — grpc's internal logs keep flowing to our structured logger exactly as before. Similar to https://github.com/DataDog/datadog-agent/pull/15321 for the OTLP endpoint.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54645",
          "createdAt": "2026-08-10T13:59:56Z",
          "updatedAt": "2026-08-13T13:47:05Z",
          "timestamp": "2026-08-13T13:47:05Z",
          "metrics": {
            "reactions": 1,
            "comments": 8
          },
          "labels": [
            "changelog/no-changelog",
            "team/opentelemetry",
            "qa/done",
            "medium review",
            "team/profiling-full-host",
            "internal"
          ],
          "author": "pgimalac",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:b61bb3a91ed3bcae7f6b",
        "signalId": "github:DataDog/datadog-agent:pull_request:54829",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54829",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[EBPF] gpu: improve collector run telemetry",
          "text": "### What does this PR do? Improves the collector telemetry for the GPU check by adding a new counter for the number of runs per collector, and also adds device-related tags: device name, architecture, NVlink capabilities, MIG/vGPU state. ### Motivation Facilitate debugging and monitoring, with these tags we will be able to understand whether collectors are failing for specific GPU types for example. ### Describe how you validated your changes Ran the agent and validated that the telemetry has the necessary tags. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54829",
          "createdAt": "2026-08-13T11:57:55Z",
          "updatedAt": "2026-08-13T13:46:23Z",
          "timestamp": "2026-08-13T13:46:23Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [],
          "author": "gjulianm",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:09d47265811c37bc48fa",
        "signalId": "github:DataDog/datadog-agent:pull_request:54362",
        "event": "discovered",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54362",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CONTINT-5415] Tag CronJob-owned Job events with kube_cronjob",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? This PR adds the `kube_cronjob` tag to Kubernetes Job events when they are spawned by a cronjob. It does this by parsing through the job name, the same as what is done in the [tagger](https://github.com/DataDog/datadog-agent/blob/9f1c7785f27a5a040377c1f0db4e4faf50cefe3d/comp/core/tagger/collectors/workloadmeta_extract.go#L1206) and [KSM](https://github.com/DataDog/datadog-agent/blob/9f1c7785f27a5a040377c1f0db4e4faf50cefe3d/pkg/collector/corechecks/cluster/ksm/kubernetes_state.go#L1479) check. ### Motivation Closes issue https://github.com/DataDog/datadog-agent/issues/52611 https://datadoghq.atlassian.net/browse/CONTINT-5415 ### Describe how you validated your changes On a kind cluster, built and deployed the agent with event bundling enabled, added a cronjob that spawns a new job with schedule `* * * * *`. Saw that events are emitted with the proper `kube_cronjob` tag: <img width=\"835\" height=\"387\" alt=\"image\" src=\"https://github.com/user-attachments/assets/e3991a91-a636-4a4a-96c7-84e61df2127f\" /> ### Additional Notes This change is _complete_ in that any job events spawned by a cronjob while have this tag, it's not _sound_ in that there could be jobs (not spawned by a cronjob) that could parse as a if its spawned by a cronjob, and the `kube_cronjob` tag will be emitted. Since other parts of the agent have accepted this risk, it's probably acceptable here too but I think worth noting.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54362",
          "createdAt": "2026-08-03T14:42:35Z",
          "updatedAt": "2026-08-13T13:45:31Z",
          "timestamp": "2026-08-13T13:45:31Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "qa/done",
            "medium review",
            "team/container-integrations",
            "team/agent-build",
            "internal"
          ],
          "author": "triviajon",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:89845baaca2706fad336",
        "signalId": "github:DataDog/datadog-agent:pull_request:52993",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:52993",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Unify converter features behavior",
          "text": "### What does this PR do? Make all extension-related converter features behave like `datadog` and `dogtel`: in the case where the relevant extension is defiled by the user but not added to `service.pipeline`, add this instance instead of defining a `/dd-autoconfigured` one ### Motivation Unify the user experience [OTAGENT-1127](https://datadoghq.atlassian.net/browse/OTAGENT-1127?atlOrigin=eyJpIjoiZjBlOGI1ODVhYzlhNGZjNWExMzczYTM4MjY0NTE5MWYiLCJwIjoiaiJ9) ### Describe how you validated your changes Tests ### Additional Notes [OTAGENT-1127]: https://datadoghq.atlassian.net/browse/OTAGENT-1127?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/52993",
          "createdAt": "2026-06-30T17:01:11Z",
          "updatedAt": "2026-08-13T13:45:30Z",
          "timestamp": "2026-08-13T13:45:30Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "qa/done",
            "medium review",
            "team/opentelemetry-agent",
            "stale",
            "internal"
          ],
          "author": "agagniere",
          "state": "open",
          "assignees": [
            "agagniere"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:f6dd07e75449c64880f8",
        "signalId": "github:DataDog/datadog-agent:pull_request:54634",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54634",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "optimize the complexity of the trace_contention_begin",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? This [commit](https://github.com/torvalds/linux/commit/e67ddd9b1cff7872d43ead73a1403c4e532003d9) landed in kernel v6.9 negatively effects the complexity of the `trace_contention_begin` bpf program. The verifier cannot effectively prune the state space of the binary search algorithm. In order to fix the load failures this PR moves the loop variables of the binary search into a percpu array map. Since the verifier cannot track the bounds of registers spilled to a map value, it can prune the state space more effectively. In order to make it reliable to use this scratch space the bpf program must now account for nested execution from different contexts. In order to handle this the PR introduce code to detect the execution context of the bpf program in the kernel and use that to select a slot to hold the loop variables. ### Motivation ### Describe how you validated your changes New tests cover the changes ### Additional Notes This PR is currently incomplete due to the lack of support for handling environments where kernel addresses from `/proc/kallsyms` are not readable such as when `kptr_restrict` is set and when `CAP_SYSLOG` is not available, in the cilium/ebpf loader. The loader automatically reads and caches addresses from /proc/kallsyms when `__ksyms` is used to mark global variables. I am working on upstreaming support for handling restricted environment to the cilium/ebpf loader.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54634",
          "createdAt": "2026-08-10T12:57:41Z",
          "updatedAt": "2026-08-13T13:44:59Z",
          "timestamp": "2026-08-13T13:44:59Z",
          "metrics": {
            "reactions": 1,
            "comments": 8
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/ebpf-platform",
            "qa/done",
            "long review",
            "team/agent-build",
            "internal"
          ],
          "author": "usamasaqib",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:1b55d5de7edf02f264aa",
        "signalId": "github:DataDog/datadog-agent:pull_request:54821",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54821",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[EBPF] gpu: serialize NVML field value queries",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Ensures that calls to `GetFieldValues` are serialized as that is not a thread safe API. ### Motivation #incident-59170 - `nvlink_fields` collector might mark some ports as unsupported. This is an extra safety on top of #54817, in case parallel collection is enabled. ### Describe how you validated your changes Tested in an A100 instance. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54821",
          "createdAt": "2026-08-13T10:55:17Z",
          "updatedAt": "2026-08-13T13:44:37Z",
          "timestamp": "2026-08-13T13:44:37Z",
          "metrics": {
            "reactions": 2,
            "comments": 6
          },
          "labels": [
            "team/ebpf-platform",
            "qa/done",
            "short review",
            "internal",
            "team/gpu-monitoring-agent",
            "backport/7.82.x",
            "backport/7.83.x"
          ],
          "author": "gjulianm",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:68647d422c5072a010c7",
        "signalId": "github:DataDog/datadog-agent:issue:33469",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:issue:33469",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "issue",
          "title": "Dependency Dashboard",
          "text": "This issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.<br>[View this repository on the Mend.io Web Portal](https://developer.mend.io/github/DataDog/datadog-agent). ## Deprecations / Replacements > [!WARNING] The following dependencies are either deprecated or have replacements available. | Datasource | Package | Replacement PR? | |------------|------|--------------| | nuget | [xunit](https://redirect.github.com/xunit/xunit) | ![Unavailable](https://img.shields.io/badge/unavailable-orange?style=flat-square) | ## Pending Approval The following branches are pending approval. To create them, click on a checkbox below. - [ ] <!-- approve-branch=renovate/github.com-alecthomas-participle-2.x -->Update module github.com/alecthomas/participle to v2 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-authorization-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/authorization/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-compute-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/compute/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-containerservice-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/containerservice/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-managedidentity-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/managedidentity/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-network-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/network/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-docker-sdk-v4-5.x -->Update module github.com/pulumi/pulumi-docker/sdk/v4 to v5 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-tls-sdk-v4-5.x -->Update module github.com/pulumi/pulumi-tls/sdk/v4 to v5 - [ ] <!-- approve-branch=renovate/github.com-sijms-go-ora-v2-3.x -->Update module github.com/sijms/go-ora/v2 to v3 - [ ] <!-- approve-branch=renovate/gitlab.com-gitlab-org-api-client-go-2.x -->Update module gitlab.com/gitlab-org/api/client-go to v2 - [ ] <!-- approve-branch=renovate/gopkg.in-datadog-dd-trace-go.v1-2.x -->Update module gopkg.in/DataDog/dd-trace-go.v1 to v2 - [ ] <!-- approve-all-pending-prs -->🔐 **Create all pending approval PRs at once** 🔐 ## Rate-Limited The following updates are currently rate-limited. To force their creation now, click on a checkbox below. - [ ] <!-- unlimit-branch=renovate/linux-images-130715735.x -->Update dependency linux-images to v130715735 - [ ] <!-- unlimit-branch=renovate/linux-images-devcontainer-130715735.x -->Update dependency linux-images-devcontainer to v130715735 - [ ] <!-- unlimit-branch=renovate/windows-images-130715735.x -->Update dependency windows-images to v130715735 - [ ] <!-- unlimit-branch=renovate/github-actions -->Update github-actions (`DataDog/dd-sts-action`, `actions/checkout`, `aws-actions/configure-aws-credentials`, `docker/login-action`, `tcort/github-action-markdown-link-check`) - [ ] <!-- unlimit-branch=renovate/github.com-jarcoal-httpmock-1.x -->Update module github.com/jarcoal/httpmock to v1.4.2 - [ ] <!-- unlimit-branch=renovate/github.com-klauspost-compress-1.x -->Update module github.com/klauspost/compress to v1.19.2 - [ ] <!-- unlimit-branch=renovate/github.com-mattn-go-sqlite3-1.x -->Update module github.com/mattn/go-sqlite3 to v1.14.49 - [ ] <!-- unlimit-branch=renovate/github.com-pierrec-lz4-v4-4.x -->Update module github.com/pierrec/lz4/v4 to v4.1.28 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-random-sdk-v4-4.x -->Update module github.com/pulumi/pulumi-random/sdk/v4 to v4.21.1 - [ ] <!-- unlimit-branch=renovate/github.com-santhosh-tekuri-jsonschema-v6-6.x -->Update module github.com/santhosh-tekuri/jsonschema/v6 to v6.0.3 - [ ] <!-- unlimit-branch=renovate/github.com-vektra-mockery-v3-3.x -->Update module github.com/vektra/mockery/v3 to v3.7.2 - [ ] <!-- unlimit-branch=renovate/go.etcd.io-etcd-client-v2-2.x -->Update module go.etcd.io/etcd/client/v2 to v2.305.33 - [ ] <!-- unlimit-branch=renovate/go.temporal.io-api-1.x -->Update module go.temporal.io/api to v1.63.5 - [ ] <!-- unlimit-branch=renovate/packaging-26.x -->Update dependency packaging to v26.3 - [ ] <!-- unlimit-branch=renovate/cloud.google.com-go-compute-1.x -->Update module cloud.google.com/go/compute to v1.65.0 - [ ] <!-- unlimit-branch=renovate/code.cloudfoundry.org-lager-v3-3.x -->Update module code.cloudfoundry.org/lager/v3 to v3.81.0 - [ ] <!-- unlimit-branch=renovate/github.com-apache-arrow-go-v18-18.x -->Update module github.com/apache/arrow-go/v18 to v18.7.0 - [ ] <!-- unlimit-branch=renovate/github.com-aquasecurity-trivy-0.x -->Update module github.com/aquasecurity/trivy to v0.73.0 - [ ] <!-- unlimit-branch=renovate/github.com-containerd-containerd-v2-2.x -->Update module github.com/containerd/containerd/v2 to v2.3.3 - [ ] <!-- unlimit-branch=renovate/github.com-datadog-dd-trace-go-contrib-net-http-v2-2.x -->Update module github.com/DataDog/dd-trace-go/contrib/net/http/v2 to v2.9.1 - [ ] <!-- unlimit-branch=renovate/github.com-datadog-orchestrion-1.x -->Update module github.com/DataDog/orchestrion to v1.12.0 - [ ] <!-- unlimit-branch=renovate/github.com-docker-cli-29.x -->Update module github.com/docker/cli to v29.7.2+incompatible - [ ] <!-- unlimit-branch=renovate/github.com-envoyproxy-gateway-1.x -->Update module github.com/envoyproxy/gateway to v1.8.3 - [ ] <!-- unlimit-branch=renovate/github.com-google-cel-go-0.x -->Update module github.com/google/cel-go to v0.30.0 - [ ] <!-- unlimit-branch=renovate/github.com-open-policy-agent-opa-1.x -->Update module github.com/open-policy-agent/opa to v1.19.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-aws-sdk-v7-7.x -->Update module github.com/pulumi/pulumi-aws/sdk/v7 to v7.40.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-awsx-sdk-v3-3.x -->Update module github.com/pulumi/pulumi-awsx/sdk/v3 to v3.8.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-eks-sdk-v4-4.x -->Update module github.com/pulumi/pulumi-eks/sdk/v4 to v4.3.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-gcp-sdk-v9-9.x -->Update module github.com/pulumi/pulumi-gcp/sdk/v9 to v9.33.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-sdk-v3-3.x -->Update module github.com/pulumi/pulumi/sdk/v3 to v3.256.0 - [ ] <!-- unlimit-branch=renovate/github.com-rabbitmq-amqp091-go-1.x -->Update module github.com/rabbitmq/amqp091-go to v1.13.0 - [ ] <!-- unlimit-branch=renovate/github.com-redis-go-redis-v9-9.x -->Update module github.com/redis/go-redis/v9 to v9.22.0 - [ ] <!-- unlimit-branch=renovate/go.temporal.io-sdk-1.x -->Update module go.temporal.io/sdk to v1.47.0 - [ ] <!-- unlimit-branch=renovate/sigs.k8s.io-gateway-api-1.x -->Update module sigs.k8s.io/gateway-api to v1.6.1 - [ ] <!-- unlimit-branch=renovate/redis-7.x -->Update redis Docker tag to v7.4 - [ ] <!-- unlimit-branch=renovate/confluentinc-cp-kafka-8.x -->Update confluentinc/cp-kafka Docker tag to v8 - [ ] <!-- unlimit-branch=renovate/major-github-actions -->Update github-actions (major) (`actions/cache`, `actions/labeler`, `actions/setup-go`, `actions/setup-node`, `actions/setup-python`, `actions/stale`, `slackapi/slack-github-action`) - [ ] <!-- unlimit-branch=renovate/postgres-17.x -->Update postgres Docker tag to v17 - [ ] <!-- unlimit-branch=renovate/redis-8.x -->Update redis Docker tag to v8 - [ ] <!-- create-all-rate-limited-prs -->🔐 **Create all rate-limited PRs at once** 🔐 ## Pending Status Checks The following updates await pending status checks. To force their creation now, click on a checkbox below. - [ ] <!-- approvePr-branch=renovate/confluentinc-cp-kafka-7.x -->Update confluentinc/cp-kafka Docker tag to v7.9.9 - [ ] <!-- approvePr-branch=renovate/rules_rs-0.x -->Update dependency rules_rs to v0.0.102 - [ ] <!-- approvePr-branch=renovate/franz-go -->Update module github.com/twmb/franz-go to v1.21.6 - [ ] <!-- approvePr-branch=renovate/google.golang.org-protobuf-1.x -->Update module google.golang.org/protobuf to v1.36.12 - [ ] <!-- approvePr-branch=renovate/clap-4.x-lockfile -->Update Rust crate clap to v4.6.6 - [ ] <!-- approvePr-branch=renovate/dd_sds-0.x -->Update Rust crate dd_sds to v0.1.0-20260807-dd8be015454d - [ ] <!-- approvePr-branch=renovate/http-body-util-0.x-lockfile -->Update Rust crate http-body-util to v0.1.5 - [ ] <!-- approvePr-branch=renovate/thiserror-2.x-lockfile -->Update Rust crate thiserror to v2.0.20 - [ ] <!-- approvePr-branch=renovate/hatchling-1.x -->Update dependency hatchling to v1.32.0 - [ ] <!-- approvePr-branch=renovate/azure-sdk-for-go-monorepo -->Update module github.com/Azure/azure-sdk-for-go/sdk/azcore to v1.23.0 - [ ] <!-- approvePr-branch=renovate/github.com-datadog-datadog-api-client-go-v2-2.x -->Update module github.com/DataDog/datadog-api-client-go/v2 to v2.64.0 - [ ] <!-- approvePr-branch=renovate/public.ecr.aws-docker-library-alpine-3.x -->Update public.ecr.aws/docker/library/alpine Docker tag to v3.24.1 - [ ] <!-- approvePr-branch=renovate/ureq-3.x-lockfile -->Update Rust crate ureq to v3.4.0 - [ ] <!-- approvePr-branch=renovate/npm-sentry-dotagents-3.x -->Update dependency npm:@sentry/dotagents to v3 --- > [!WARNING] > Renovate failed to look up the following dependencies: `Failed to look up go package google.golang.org/grpc: no-result`, `Failed to look up go package github.com/hashicorp/go-retryablehttp: no-result`, `Failed to look up nuget package WixSharp_wix4: no-result`. > > Files affected: `comp/core/tagger/impl-remote/go.mod`, `go.mod`, `pkg/config/remote/go.mod`, `pkg/proto/go.mod`, `pkg/trace/go.mod`, `pkg/util/grpc/go.mod`, `tools/windows/DatadogAgentInstaller/CustomActions.Tests/CustomActions.Tests.csproj`, `tools/windows/DatadogAgentInstaller/WixSetup/WixSetup.csproj` --- ## Other Branches The following updates are pending. To force the creation of a PR, click on a checkbox below. - [ ] <!-- other-branch=renovate/integrations-core-digest -->Update integrations-core digest to b59c8b0 - [ ] <!-- other-branch=renovate/aws-sdk-go-v2 -->Update aws-sdk-go-v2 (`github.com/aws/aws-sdk-go-v2`, `github.com/aws/aws-sdk-go-v2/config`, `github.com/aws/aws-sdk-go-v2/credentials`, `github.com/aws/aws-sdk-go-v2/service/ec2`, `github.com/aws/aws-sdk-go-v2/service/ecr`, `github.com/aws/aws-sdk-go-v2/service/ecs`, `github.com/aws/aws-sdk-go-v2/service/eks`, `github.com/aws/aws-sdk-go-v2/service/rds`, `github.com/aws/aws-sdk-go-v2/service/s3`, `github.com/aws/aws-sdk-go-v2/service/secretsmanager`, `github.com/aws/aws-sdk-go-v2/service/ssm`, `github.com/aws/aws-sdk-go-v2/service/sts`) - [ ] <!-- other-branch=renovate/github.com-go-delve-delve-1.x -->Update module github.com/go-delve/delve to v1.27.1 - [ ] <!-- other-branch=renovate/github.com-google-go-containerregistry-0.x -->Update module github.com/google/go-containerregistry to v0.21.9 ## Open The following updates have all been created. To force a retry/rebase of any, click on a checkbox below. - [ ] <!-- rebase-branch=renovate/go-github.com-datadog-dd-trace-go-v2-vulnerability -->[Update module github.com/DataDog/dd-trace-go/v2 to v2.8.1 [SECURITY]](../pull/53708) - [ ] <!-- rebase-branch=renovate/datadog-datadog-agent-dev-0.x -->[Update dependency DataDog/datadog-agent-dev to v0.38.0](../pull/52555) - [ ] <!-- rebase-branch=renovate/sentry-dotagents-3.x -->[Update dependency @sentry/dotagents to v3](../pull/54802) - [ ] <!-- rebase-branch=renovate/github.com-datadog-dd-trace-go-v2-2.x -->[Update module github.com/DataDog/dd-trace-go/v2 to v2.9.1](../pull/52521) - [ ] <!-- rebase-branch=renovate/gawk-5.x -->[Update dependency gawk to v5.4.0](../pull/52963) - [ ] <!-- rebase-branch=renovate/kubernetes-monorepo -->[Update kubernetes monorepo to v0.36.3](../pull/51833) (`k8s.io/api`, `k8s.io/apiextensions-apiserver`, `k8s.io/apimachinery`, `k8s.io/cli-runtime`, `k8s.io/client-go`, `k8s.io/component-base`, `k8s.io/cri-api`, `k8s.io/cri-client`, `k8s.io/kube-aggregator`, `k8s.io/kubectl`, `k8s.io/kubelet`, `k8s.io/metrics`) - [ ] <!-- rebase-branch=renovate/github.com-godror-godror-0.x -->[Update module github.com/godror/godror to v0.51.0](../pull/53235) - [ ] <!-- rebase-branch=renovate/k8s.io-autoscaler-vertical-pod-autoscaler-1.x -->[Update module k8s.io/autoscaler/vertical-pod-autoscaler to v1.7.1](../pull/51852) - [ ] <!-- rebase-branch=renovate/k8s.io-kube-state-metrics-v2-2.x -->[Update module k8s.io/kube-state-metrics/v2 to v2.19.1](../pull/52895) - [ ] <!-- rebase-branch=renovate/sigs.k8s.io-custom-metrics-apiserver-1.x -->[Update module sigs.k8s.io/custom-metrics-apiserver to v1.36.0](../pull/52282) - [ ] <!-- rebase-branch=renovate/docker.io-library-ubuntu-26.x -->[Update docker.io/library/ubuntu Docker tag to v26](../pull/52153) - [ ] <!-- rebase-branch=renovate/docker.io-ubuntu-26.x -->[Update docker.io/ubuntu Docker tag to v26](../pull/50840) - [ ] <!-- rebase-branch=renovate/github.com-cloudfoundry-community-go-cfclient-v2-3.x -->[Update module github.com/cloudfoundry-community/go-cfclient/v2 to v3](../pull/53622) - [ ] <!-- rebase-branch=renovate/github.com-netsampler-goflow2-2.x -->[Update module github.com/netsampler/goflow2 to v2](../pull/53239) - [ ] <!-- rebase-branch=renovate/major-franz-go -->[Update module github.com/twmb/franz-go/pkg/kmsg to v2](../pull/53824) - [ ] <!-- rebase-all-open-prs -->**Click on this checkbox to rebase all open PRs at once** ## PR Closed (Blocked) The following updates are blocked by an existing closed PR. To recreate the PR, click on a checkbox below. - [ ] <!-- recreate-branch=renovate/rules_go-0.x -->[Update dependency rules_go to v0.62.0](../pull/54068) - [ ] <!-- recreate-branch=renovate/code.cloudfoundry.org-bbs-1.x -->[Update module code.cloudfoundry.org/bbs to v1.11.0](../pull/53818) - [ ] <!-- recreate-branch=renovate/github.com-aws-karpenter-provider-aws-1.x -->[Update module github.com/aws/karpenter-provider-aws to v1.14.0](../pull/53819) - [ ] <!-- recreate-branch=renovate/github.com-bazelbuild-rules_go-0.x -->[Update module github.com/bazelbuild/rules_go to v0.62.0](../pull/54057) - [ ] <!-- recreate-branch=renovate/gopkg.in-datadog-dd-trace-go.v1-1.x -->[Update module gopkg.in/DataDog/dd-trace-go.v1 to v1.74.8](../pull/52894) - [ ] <!-- recreate-branch=renovate/sigs.k8s.io-karpenter-1.x -->[Update module sigs.k8s.io/karpenter to v1.14.0](../pull/53820) - [ ] <!-- recreate-branch=renovate/chef-sugar-5.x -->[Update dependency chef-sugar to v5](../pull/51540) - [ ] <!-- recreate-branch=renovate/invoke-3.x -->[Update dependency invoke to v3](../pull/50838) - [ ] <!-- recreate-branch=renovate/code.cloudfoundry.org-bbs-models-1.x -->[Update module code.cloudfoundry.org/bbs/models to v1](../pull/53823) - [ ] <!-- recreate-branch=renovate/github.com-santhosh-tekuri-jsonschema-v5-6.x -->[Update module github.com/santhosh-tekuri/jsonschema/v5 to v6](../pull/54069) - [ ] <!-- recreate-branch=renovate/go.etcd.io-etcd-client-v2-3.x -->[Update module go.etcd.io/etcd/client/v2 to v3](../pull/53825) - [ ] <!-- recreate-branch=renovate/go.yaml.in-yaml-v2-3.x -->[Update module go.yaml.in/yaml/v2 to v3](../pull/53527) ## Detected Dependencies > [!NOTE] > Detected dependencies section has been truncated <details><summary>bazel-module (2)</summary> <blockquote> <details><summary>deps/repos.MODULE.bazel</summary> </details> <details><summary>MODULE.bazel (20)</summary> - `bazel_lib 3.7.1` - `bazel_skylib 1.9.2` - `gawk 5.3.2.bcr.7` → [Updates: `5.4.0`] - `gazelle 0.52.2` - `libarchive 3.8.1.bcr.2` - `platforms 1.1.0` - `re.bzl 0.3.1` - `rules_cc 0.2.22` - `rules_flex 0.4.1` - `rules_go 0.61.1` → [Updates: `0.62.0`] - `rules_m4 0.3.bcr.1` - `rules_multitool 1.11.1` - `rules_python 2.2.0` - `rules_rs 0.0.27` → [Updates: `0.0.102`] - `rules_rust 0.73.0` - `rules_rust_prost 0.73.0` - `rules_shell 0.8.0` - `toml.bzl 0.4.1` - `rules_testing 0.9.0` - `apple_support 2.8.0` </details> </blockquote> </details> <details><summary>bazelisk (1)</summary> <blockquote> <details><summary>.bazelversion</summary> </details> </blockquote> </details> <details><summary>bitbucket-pipelines (1)</summary> <blockquote> <details><summary>.gitlab/.pre/cancel-prev-pipelines.yml</summary> </details> </blockquote> </details> <details><summary>bundler (1)</summary> <blockquote> <details><summary>omnibus/Gemfile (2)</summary> - `chef-sugar v3.6.0` → [Updates: `v5.1.12`] - `mixlib-cli '~> 2.1.0'` </details> </blockquote> </details> <details><summary>cargo (9)</summary> <blockquote> <details><summary>Cargo.toml (56)</summary> - `anyhow 1.0.98` - `cap-std 4.0` - `caps 0.5` - `chrono 0.4` - `clap 4.5` → [Updates: `4.5`] - `elf 0.8.0` - `glob-match 0.2` - `http-body-util 0.1` → [Updates: `0.1`] - `hostname 0.4` - `hyper 1` - `hyper-util 0.1` - `libc 0.2` - `log 0.4` - `prost 0.14` - `prost-build 0.14` - `prost-types 0.14` - `protoc-gen-prost 0.5` - `protoc-gen-tonic 0.5` - `lru 0.18.0` - `memchr 2.7.6` - `nom 8.0` - `normalize-path 0.2` - `phf 0.14` - `rawzip 0.5.0` - `xml-rs 1.0` - `rmp-serde 1.3` - `serde 1.0.219` - `serde_json 1.0` - `serde_yaml 0.9` - `time 0.3` - `thiserror 2.0.12` → [Updates: `2.0.12`] - `tokio 1` - `tokio-stream 0.1` - `tonic 0.14` - `tonic-build 0.14` - `tonic-prost 0.14` - `tonic-prost-build 0.14` - `tonic-reflection 0.14` - `ureq 3.0` → [Updates: `3.0`] - `uzers 0.12` - `walkdir 2` - `saphyr-parser 0.0.11` - `yaml-rust2 0.11` - `zip 8.0` - `flate2 1.1` - `tower 0.5` - `uuid 1` - `windows-registry 0.6` - `windows-sys 0.61` - `dircpy 0.3.19` - `regex 1` - `memmap2 0.9` - `nix 0.31` - `scopeguard 1.2` - `temp-env 0.3` - `tempfile 3.0` </details> <details><summary>cmd/ai_prompt_logger/Cargo.toml</summary> </details> <details><summary>comp/core/log/rust/Cargo.toml</summary> </details> <details><summary>pkg/collector/sharedlibrary/rustchecks/checks/datasecurity/Cargo.toml (2)</summary> - `dd_sds =0.1.0-20260803-1e4349aada52` → [Updates: `=0.1.0-20260807-dd8be015454d`] - `postgres 0.19` </details> <details><summary>pkg/collector/sharedlibrary/rustchecks/checks/example/Cargo.toml</summary> </details> <details><summary>pkg/collector/sharedlibrary/rustchecks/core/Cargo.toml</summary> </details> <details><summary>pkg/discovery/module/rust/Cargo.toml</summary> </details> <details><summary>pkg/privateactionrunner/par-control/Cargo.toml</summary> </details> <details><summary>pkg/procmgr/rust/Cargo.toml</summary> </details> </blockquote> </details> <details><summary>docker-compose (36)</summary> <blockquote> <details><summary>cmd/host-profiler/docker-compose.yml (1)</summary> - `registry.datadoghq.com/agent 7` </details> <details><summary>pkg/collector/corechecks/oracle/compose/docker-compose.yml</summary> </details> <details><summary>pkg/discovery/module/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/amqp/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/http/testutil/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/kafka/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/mongo/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/mysql/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/postgres/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/redis/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/tls/gotls/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/tls/nodejs/testdata/docker-compose-ubuntu.yml</summary> </details> <details><summary>pkg/network/protocols/tls/nodejs/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/tracer/testdata/dnsworkload/docker-compose.yml</summary> </details> <details><summary>pkg/network/usm/testdata/bio_leak_test/docker-compose.yml</summary> </details> <details><summary>pkg/network/usm/testdata/musl/docker-compose.yml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/dogstatsd/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/jmxfetch/docker-compose-all-metrics.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/jmxfetch/docker-compose-slow-metrics.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/jmxfetch/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/logger/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/redis/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/integration/etcd/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/integration/kafka/docker-compose.yaml (3)</summary> - `confluentinc/cp-kafka 7.9.8` → [Updates: `7.9.9`, `8.3.0`] - `confluentinc/cp-kafka 7.9.8` → [Updates: `7.9.9`, `8.3.0`] - `confluentinc/cp-kafka 7.9.8` → [Updates: `7.9.9`, `8.3.0`] </details> <details><summary>test/e2e-framework/components/integration/postgres/docker-compose.yaml (2)</summary> - `postgres 16` → [Updates: `17`] - `postgres 16` → [Updates: `17`] </details> <details><summary>test/e2e-framework/components/integration/redisdb/docker-compose.yaml (2)</summary> - `redis 7.2` → [Updates: `7.4`, `8.2`] - `redis 7.2` → [Updates: `7.4`, `8.2`] </details> <details><summary>test/fakeintake/docker-compose.yaml</summary> </details> <details><summary>test/new-e2e/examples/testfixtures/docker-compose.fake-process.yaml</summary> </details> <details><summary>test/new-e2e/examples/testfixtures/docker-compose.lighttpd.yaml</summary> </details> <details><summary>test/new-e2e/tests/agent-health/fixtures/docker-compose.busybox.yaml</summary> </details> <details><summary>test/new-e2e/tests/discovery/testdata/compose/docker-compose.configfilesdiscovery-kafka.yaml</summary> </details> <details><summary>test/new-e2e/tests/discovery/testdata/compose/docker-compose.configfilesdiscovery-redis.yaml</summary> </details> <details><summary>test/new-e2e/tests/discovery/testdata/compose/docker-compose.fake-krakend.yaml</summary> </details> <details><summary>test/new-e2e/tests/fips-compliance/fixtures/docker-compose-cluster-agent.yaml</summary> </details> <details><summary>test/new-e2e/tests/fips-compliance/fixtures/docker-compose-fips-server.yaml</summary> </details> <details><summary>test/new-e2e/tests/fips-compliance/fixtures/docker-compose.yaml</summary> </details> </blockquote> </details> <details><summary>dockerfile (15)</summary> <blockquote> <details><summary>Dockerfiles/agent-ddot/Dockerfile</summary> </details> <details><summary>Dockerfiles/agent-ddot/Dockerfile.agent-otel (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/agent/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/agent/windows/amd64/Dockerfile (1)</summary> - `mcr.microsoft.com/dotnet/sdk 9.0-windowsservercore-ltsc2019` </details> <details><summary>Dockerfiles/base-image/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/cluster-agent/Dockerfile (2)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/ddot-ebpf/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/dogstatsd/alpine/Dockerfile (1)</summary> - `public.ecr.aws/docker/library/alpine 3.23.3` → [Updates: `3.24.1`] </details> <details><summary>Dockerfiles/otel-agent/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>test/e2e-framework/resources/local/podman/data/Dockerfile (1)</summary> - `docker.io/library/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>test/fakeintake/Dockerfile (2)</summary> - `docker.io/library/golang 1.26.5` - `docker.io/library/alpine 3.24.1` </details> <details><summary>tools/ebpf/Dockerfiles/Dockerfile-process-agent-dev</summary> </details> <details><summary>tools/ebpf/Dockerfiles/Dockerfile-security-agent-dev</summary> </details> <details><summary>tools/gdb/Dockerfile (1)</summary> - `registry.datadoghq.com/agent 7` </details> <details><summary>tools/host-profiler/Dockerfile</summary> </details> </blockquote> </details> <details><summary>github-actions (45)</summary> <blockquote> <details><summary>.github/actions/bazel-cache/action.yml (2)</summary> - `actions/cache v6.1.0@55cc8345863c7cc4c66a329aec7e433d2d1c52a9` - `actions/cache v6.1.0@55cc8345863c7cc4c66a329aec7e433d2d1c52a9` </details> <details><summary>.github/actions/deps-tidy-push/action.yml</summary> </details> <details><summary>.github/actions/deps-tidy-setup/action.yml (1)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` </details> <details><summary>.github/actions/install-dda/action.yml (3)</summary> - `actions/cache v6.1.0@55cc8345863c7cc4c66a329aec7e433d2d1c52a9` - `DataDog/datadog-agent-dev install@00e4a423088309efce1d5ba6b8c5366eef648710` - `DataDog/datadog-agent-dev install@00e4a423088309efce1d5ba6b8c5366eef648710` </details> <details><summary>.github/workflows/add-dependabot-pr-to-mq.yml (3)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/add-label-community-pr.yml (2)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/add-label-pr.yml (3)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/add-milestone.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/agenttelemetry-metric-reminder.yml (1)</summary> - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/ask-review.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/assess-permissions.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/assign-issue.yml (1)</summary> - `DataDog/issue-triage-action v1.0.1@b39f0bc12abc52fe8aa70dc9b9353bf307a13219` </details> <details><summary>.github/workflows/backport-pr.yml (4)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/buildimages-update.yml (5)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/chase-for-qa-cards.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/check-issue-status.yml (5)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/check-skip.yml</summary> </details> <details><summary>.github/workflows/cla.yml (2)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `contributor-assistant/github-action v2.6.1@ca4a40a7d1004f18d9960b404b97e5f30a505a08` </details> <details><summary>.github/workflows/code-review-complexity.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/code-review.yml (1)</summary> - `DataDog/code-review-action v1.1.0@56d6862711348b11ec2603edfb29c52c09f4b84c` </details> <details><summary>.github/workflows/codex-review-draft.yml (1)</summary> - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/codex-review-ready-for-review.yml</summary> </details> <details><summary>.github/workflows/collector-generate-and-update.yml (5)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `slackapi/slack-github-action v3.0.5@0d95c9a7becc1e6e297d76df9bc735c44f4cbcbc` → [Updates: `v4.0.0`] </details> <details><summary>.github/workflows/create-rc-pr.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/cws-btfhub-sync.yml (11)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `actions/upload-artifact v7.0.1@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `actions/download-artifact v8.0.1@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c` - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `ubuntu 24.04` - `ubuntu 24.04` </details> <details><summary>.github/workflows/deps-tidy.yml (7)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `dtolnay/rust-toolchain v1@e97e2d8cc328f1b50210efc529dca0028893a2d9` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `rust stable` </details> <details><summary>.github/workflows/do-not-merge.yml</summary> </details> <details><summary>.github/workflows/docs-dev.yml (8)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/upload-artifact v7.0.1@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a` - `actions/download-artifact v8.0.1@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c` - `peaceiris/actions-gh-pages v4.1.0@84c30a85c19949d7eee79c4ff27748b70285e453` </details> <details><summary>.github/workflows/go-update-commenter.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/gohai.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] </details> <details><summary>.github/workflows/label-analysis.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/labeler.yml (1)</summary> - `actions/labeler v6.2.0@b8dd2d9be0f68b860e7dae5dae7d772984eacd6d` → [Updates: `v7.0.0`] </details> <details><summary>.github/workflows/markdown-lint-check.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `tcort/github-action-markdown-link-check v1.1.2@e7c7a18363c842693fadde5d41a3bd3573a7a225` → [Updates: `v1.1.3`] </details> <details><summary>.github/workflows/push-bazel-cache.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/report-merged-pr.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `DataDog/dd-sts-action v1.0.0@2e8187910199bd93129520183c093e19aa585c75` → [Updates: `v1.0.5`] </details> <details><summary>.github/workflows/slapr_backport.yml (1)</summary> - `DataDog/slapr 1.1.0@95312d6b8528460243ba27c7f8167bfe20a68bec` </details> <details><summary>.github/workflows/slapr.yml (3)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `DataDog/slapr 1.1.0@95312d6b8528460243ba27c7f8167bfe20a68bec` </details> <details><summary>.github/workflows/stale.yml (2)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/stale v10.4.0@1e223db275d687790206a7acac4d1a11bd6fe629` → [Updates: `v11.0.0`] </details> <details><summary>.github/workflows/test-devcontainer.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-node v6.5.0@249970729cb0ef3589644e2896645e5dc5ba9c38` → [Updates: `v7.0.0`] </details> <details><summary>.github/workflows/update-dependencies.yml (4)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/update-ebpf-profiler-branch.yml (4)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/update-kubernetes-versions.yml (8)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-python v6.3.0@ece7cb06caefa5fff74198d8649806c4678c61a1` → [Updates: `v7.0.0`] - `helm/kind-action v1.14.0@ef37e7f390d99f746eb8b610417061a60e82a6cc` - `aws-actions/configure-aws-credentials v6.2.2@517a711dbcd0e402f90c77e7e2f81e849156e31d` → [Updates: `v6.2.3`] - `docker/login-action v4.4.0@af1e73f918a031802d376d3c8bbc3fe56130a9b0` → [Updates: `v4.6.0`] - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `python 3.14` </details> <details><summary>.github/workflows/upgrade-python-patch-version.yml (5)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-python v6.3.0@ece7cb06caefa5fff74198d8649806c4678c61a1` → [Updates: `v7.0.0`] - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `python 3.14` </details> <details><summary>.github/workflows/validate-renovate-deps.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/warn-failed-dependabot-pr.yml</summary> </details> </blockquote> </details> <details><summary>gomod (80)</summary> <blockquote> <details><summary>comp/anomalydetection/observer/def/go.mod</summary> </details> <details><summary>comp/anomalydetection/recorder/def/go.mod</summary> </details> <details><summary>comp/anomalydetection/severityevents/def/go.mod</summary> </details> <details><summary>comp/api/api/def/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/agenttelemetry/def/go.mod</summary> </details> <details><summary>comp/core/agenttelemetry/fx/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/agenttelemetry/impl/go.mod (7)</summary> - `github.com/DataDog/zstd v1.5.8-0.20260421145859-31a7e515a571@31a7e515a571` → [Updates: `v1.5.8-0.20260421145859-31a7e515a571`] - `github.com/prometheus/client_model v0.6.2` - `github.com/robfig/cron/v3 v3.0.1` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/core/config/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/configstreamconsumer/def/go.mod</summary> </details> <details><summary>comp/core/configsync/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/delegatedauth/api/cloudauth/aws/go.mod (2)</summary> - `github.com/aws/aws-sdk-go-v2 v1.43.3` → [Updates: `v1.43.4`] - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/delegatedauth/go.mod (2)</summary> - `github.com/cenkalti/backoff/v7 v7.0.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/flare/builder/go.mod</summary> </details> <details><summary>comp/core/flare/types/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/hostname/hostnameinterface/def/go.mod</summary> </details> <details><summary>comp/core/hostname/hostnameinterface/go.mod</summary> </details> <details><summary>comp/core/hostname/hostnameinterface/mock/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/ipc/def/go.mod</summary> </details> <details><summary>comp/core/ipc/httphelpers/go.mod (2)</summary> - `github.com/mdlayher/vsock v1.3.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/ipc/impl/go.mod (2)</summary> - `github.com/gofrs/flock v0.13.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/ipc/mock/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/def/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/fx/go.mod</summary> </details> <details><summary>comp/core/log/impl-trace/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/impl/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/mock/go.mod</summary> </details> <details><summary>comp/core/secrets/def/go.mod</summary> </details> <details><summary>comp/core/secrets/fx/go.mod</summary> </details> <details><summary>comp/core/secrets/impl/go.mod (4)</summary> - `github.com/benbjohnson/clock v1.3.5` - `github.com/json-iterator/go v1.1.12` - `github.com/stretchr/testify v1.11.1` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/secrets/mock/go.mod (1)</summary> - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/secrets/noop-impl/go.mod</summary> </details> <details><summary>comp/core/secrets/utils/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/status/go.mod (4)</summary> - `github.com/dustin/go-humanize v1.0.1` - `github.com/fatih/color v1.19.0` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/status/statusimpl/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/tagger/def/go.mod</summary> </details> <details><summary>comp/core/tagger/fx-remote/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/tagger/generic_store/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/impl-remote/go.mod (5)</summary> - `github.com/cenkalti/backoff/v7 v7.0.0` - `github.com/google/uuid v1.6.0` - `github.com/mdlayher/vsock v1.3.0` - `github.com/stretchr/testify v1.11.1` - `google.golang.org/grpc v1.83.0` </details> <details><summary>comp/core/tagger/origindetection/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/subscriber/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/tags/go.mod</summary> </details> <details><summary>comp/core/tagger/telemetry/go.mod</summary> </details> <details><summary>comp/core/tagger/types/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/utils/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/telemetry/go.mod (6)</summary> - `github.com/prometheus/client_golang v1.24.1` - `github.com/prometheus/client_model v0.6.2` - `github.com/prometheus/common v0.70.1` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/def/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/forwarder/defaultforwarder/go.mod (6)</summary> - `github.com/benbjohnson/clock v1.3.5` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.uber.org/fx v1.24.0` - `go.uber.org/multierr v1.11.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/forwarder/orchestrator/orchestratorinterface/go.mod</summary> </details> <details><summary>comp/host-profiler/symboluploader/testdata/go.mod</summary> </details> <details><summary>comp/logs-library/go.mod (4)</summary> - `github.com/DataDog/agent-payload/v5 v5.0.209` - `github.com/benbjohnson/clock v1.3.5` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` </details> <details><summary>comp/logs/agent/config/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.yaml.in/yaml/v3 v3.0.5` </details> <details><summary>comp/netflow/payload/go.mod</summary> </details> <details><summary>comp/otelcol/collector-contrib/def/go.mod</summary> </details> <details><summary>comp/otelcol/collector-contrib/impl/go.mod</summary> </details> <details><summary>comp/otelcol/converter/def/go.mod</summary> </details> <details><summary>comp/otelcol/converter/impl/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/ddflareextension/def/go.mod</summary> </details> <details><summary>comp/otelcol/ddflareextension/impl/go.mod (6)</summary> - `github.com/google/go-cmp v0.7.0` - `github.com/google/uuid v1.6.0` - `github.com/mohae/deepcopy v0.0.0-20170929034955-c48cc78d4826@c48cc78d4826` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/otelcol/ddflareextension/types/go.mod</summary> </details> <details><summary>comp/otelcol/ddprofilingextension/def/go.mod</summary> </details> <details><summary>comp/otelcol/ddprofilingextension/impl/go.mod (3)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/DataDog/dd-trace-go/v2 v2.9.0` → [Updates: `v2.9.1`] - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/otelcol/logsagentpipeline/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/logsagentpipeline/logsagentpipelineimpl/go.mod</summary> </details> <details><summary>comp/otelcol/otlp/components/connector/datadogconnector/go.mod (5)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/google/go-cmp v0.7.0` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/otelcol/otlp/components/datadogconfig/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/otlp/components/exporter/datadogexporter/go.mod (4)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/otelcol/otlp/components/exporter/logsagentexporter/go.mod (4)</summary> - `github.com/DataDog/agent-payload/v5 v5.0.209` - `github.com/patrickmn/go-cache v2.1.0+incompatible` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/otlp/components/exporter/serializerexporter/go.mod (8)</summary> - `github.com/google/go-cmp v0.7.0` - `github.com/stretchr/testify v1.11.1` - `github.com/tinylib/msgp v1.6.4` - `go.uber.org/fx v1.24.0` - `go.uber.org/multierr v1.11.0` - `go.uber.org/zap v1.28.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] - `go.uber.org/atomic v1.11.0` </details> <details><summary>comp/otelcol/otlp/components/metricsclient/go.mod (2)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/otelcol/otlp/components/processor/infraattributesprocessor/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/otlp/testutil/go.mod (3)</summary> - `github.com/DataDog/sketches-go v1.4.8` - `github.com/stretchr/testify v1.11.1` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/otelcol/status/def/go.mod</summary> </details> <details><summary>comp/otelcol/status/impl/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.yaml.in/yaml/v3 v3.0.5` </details> <details><summary>comp/serializer/logscompression/go.mod</summary> </details> <details><summary>comp/serializer/metricscompression/go.mod</summary> </details> <details><summary>comp/trace/agent/def/go.mod</summary> </details> <details><summary>comp/trace/compression/def/go.mod</summary> </details> <details><summary>comp/trace/compression/impl-gzip/go.mod</summary> </details> <details><summary>comp/trace/compression/impl-zstd/go.mod (1)</summary> - `github.com/DataDog/zstd v1.5.8-0.20260421145859-31a7e515a571@31a7e515a571` → [Updates: `v1.5.8-0.20260421145859-31a7e515a571`] </details> <details><summary>go.mod (114)</summary> - `code.cloudfoundry.org/bbs v1.3.0` → [Updates: `v1.11.0`] - `code.cloudfoundry.org/bbs/models v0.0.0-20260618205254-dc4b9f8d5bc9@dc4b9f8d5bc9` → [Updates: `v1.8.0`] - `code.cloudfoundry.org/garden v0.0.0-20260617020226-a9e754564bb5@a9e754564bb5` → [Updates: `v0.0.0-20260811183727-158508cf0d71`] - `code.cloudfoundry.org/lager/v3 v3.78.0` → [Updates: `v3.81.0`] - `dario.cat/mergo v1.0.2` - `github.com/Azure/azure-sdk-for-go/sdk/azcore v1.22.0` → [Updates: `v1.23.0`] - `github.com/Azure/azure-sdk-for-go/sdk/azidentity v1.14.0` - `github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/azsecrets v1.5.0` - `github.com/CycloneDX/cyclonedx-go v0.11.0` - `github.com/DATA-DOG/go-sqlmock v1.5.2` - `github.com/DataDog/agent-payload/v5 v5.0.209` - `github.com/DataDog/datadog-api-client-go/v2 v2.62.0` → [Updates: `v2.64.0`] - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/DataDog/datadog-operator/api v0.0.0-20260807013103-1518bb55e423@1518bb55e423` → [Updates: `v0.0.0-20260812212652-5f8a87676244`] - `github.com/DataDog/datadog-traceroute v1.0.19` - `github.com/DataDog/dd-policy-engine/go v0.0.0-20260730181922-c5e419a4ec7d@c5e419a4ec7d` → [Updates: `v0.0.0-20260803230307-dd41045a4bb2`] - `github.com/DataDog/dd-trace-go/v2 v2.9.0` → [Updates: `v2.9.1`] - `github.com/DataDog/ddtrivy v0.0.0-20260519164847-bf6bcaf2f9b7@bf6bcaf2f9b7` → [Updates: `v0.0.0-20260519164847-bf6bcaf2f9b7`] - `github.com/DataDog/ebpf-manager v0.8.1` - `github.com/DataDog/go-acl v1.0.1` - `github.com/DataDog/go-sqllexer v0.2.4` - `github.com/DataDog/jsonapi v0.13.0` - `github.com/DataDog/rshell v0.0.24` - `github.com/DataDog/sketches-go v1.4.8` - `github.com/DataDog/watermarkpodautoscaler/apis v0.0.0-20250108152814-82e58d0231d1@82e58d0231d1` → [Updates: `v0.0.0-20260803084540-a82e1114b53b`] - `github.com/DataDog/zstd v1.5.8-0.20260421145859-31a7e515a571@31a7e515a571` → [Updates: `v1.5.8-0.20260421145859-31a7e515a571`] - `github.com/Masterminds/semver/v3 v3.5.0` - `github.com/Masterminds/sprig/v3 v3.3.0` - `github.com/Microsoft/go-winio v0.6.2` - `github.com/Microsoft/hcsshim v0.14.1` - `github.com/NVIDIA/go-nvml v0.13.1-0` - `github.com/ProtonMail/go-crypto v1.4.1` - `github.com/acobaugh/osrelease v0.1.0` - `github.com/alecthomas/units v0.0.0-20240927000941-0f3dac36c52b@0f3dac36c52b` - `github.com/aptly-dev/aptly v1.6.3` - `github.com/aquasecurity/trivy v0.72.0` → [Updates: `v0.73.0`] - `github.com/aquasecurity/trivy-db v0.0.0-20251222105351-a833f47f8f0d@a833f47f8f0d` → [Updates: `v0.0.0-20260813095258-0e0340a01b57`] - `github.com/aws/aws-sdk-go-v2 v1.43.3` → [Updates: `v1.43.4`] - `github.com/aws/aws-sdk-go-v2/config v1.32.34` → [Updates: `v1.32.35`] - `github.com/aws/aws-sdk-go-v2/credentials v1.19.33` → [Updates: `v1.19.34`] - `github.com/aws/aws-sdk-go-v2/service/ec2 v1.318.1` → [Updates: `v1.319.1`] - `github.com/aws/aws-sdk-go-v2/service/rds v1.120.1` → [Updates: `v1.124.1`] - `github.com/aws/aws-sdk-go-v2/service/secretsmanager v1.44.0` → [Updates: `v1.44.4`] - `github.com/aws/aws-sdk-go-v2/service/ssm v1.73.0` → [Updates: `v1.73.4`] - `github.com/aws/aws-sdk-go-v2/service/sts v1.45.3` → [Updates: `v1.45.4`] - `github.com/aws/karpenter-provider-aws v1.9.0` → [Updates: `v1.14.0`] - `github.com/aymerick/raymond v2.0.2+incompatible` - `github.com/bazelbuild/rules_go v0.61.1` → [Updates: `v0.62.0`] - `github.com/beevik/ntp v1.5.0` - `github.com/benbjohnson/clock v1.3.5` - `github.com/bhmj/jsonslice v1.1.3` - `github.com/blabber/go-freebsd-sysctl v0.0.0-20201130114544-503969f39d8f@503969f39d8f` - `github.com/bmatcuk/doublestar/v4 v4.10.0` - `github.com/cenkalti/backoff/v7 v7.0.0` - `github.com/cespare/xxhash/v2 v2.3.0` - `github.com/cilium/ebpf v0.22.0` - `github.com/clbanning/mxj/v2 v2.7.0` - `github.com/cloudflare/cbpfc v0.0.0-20260219140841-0661ad29132c@0661ad29132c` → [Updates: `v0.0.0-20260805072904-7ac485fd93e1`] - `github.com/cloudfoundry-community/go-cfclient/v2 v2.0.1-0.20230503155151-3d15366c5820@3d15366c5820` → [Updates: `v3.0.0-beta.1`] - `github.com/containerd/cgroups/v3 v3.1.3` - `github.com/containerd/containerd/api v1.11.1` - `github.com/containerd/containerd/v2 v2.2.5` → [Updates: `v2.3.3`] - `github.com/containerd/errdefs v1.0.0` - `github.com/containerd/typeurl/v2 v2.3.0` - `github.com/containernetworking/cni v1.3.0` - `github.com/coreos/go-semver v0.3.1` - `github.com/coreos/go-systemd/v22 v22.7.0` - `github.com/creack/pty v1.1.24` - `github.com/cri-o/ocicni v0.5.0` - `github.com/cyphar/filepath-securejoin v0.7.0` - `github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc@d8f796af33cc` - `github.com/distribution/reference v0.6.0` - `github.com/dustin/go-humanize v1.0.1` - `github.com/elastic/go-freelru v0.16.0` - `github.com/elastic/go-libaudit/v2 v2.6.2` - `github.com/elastic/go-seccomp-bpf v1.6.0` - `github.com/envoyproxy/gateway v1.7.4` → [Updates: `v1.8.3`] - `github.com/evanphx/json-patch/v5 v5.9.11` - `github.com/fatih/color v1.19.0` - `github.com/fatih/structtag v1.2.0` - `github.com/freddierice/go-losetup v0.0.0-20220711213114-2a14873012db@2a14873012db` - `github.com/ghodss/yaml v1.0.1-0.20220118164431-d8423dcdf344@d8423dcdf344` - `github.com/glaslos/ssdeep v1.0.0` - `github.com/go-delve/delve v1.27.0` → [Updates: `v1.27.1`] - `github.com/go-jose/go-jose/v4 v4.1.4` - `github.com/go-json-experiment/json v0.0.0-20250517221953-25912455fbc8@25912455fbc8` → [Updates: `v0.0.0-20260623181947-01eb4420fa68`] - `github.com/go-ole/go-ole v1.3.0` - `github.com/go-sql-driver/mysql v1.10.0` - `github.com/go-viper/mapstructure/v2 v2.5.0` - `github.com/go-zookeeper/zk v1.0.4` - `github.com/gobwas/glob v0.2.3` - `github.com/goccy/go-yaml v1.19.2` - `github.com/gocomply/scap v0.1.3` - `github.com/godbus/dbus/v5 v5.2.2` - `github.com/godror/godror v0.50.0` → [Updates: `v0.51.0`] - `github.com/gogo/protobuf v1.3.2` - `github.com/golang-jwt/jwt/v5 v5.3.1` - `github.com/golang/groupcache v0.0.0-20241129210726-2c02b8208cf8@2c02b8208cf8` - `github.com/golang/mock v1.7.0-rc.1` - `github.com/google/btree v1.1.3` - `github.com/google/cel-go v0.29.2` → [Updates: `v0.30.0`] - `github.com/google/go-cmp v0.7.0` - `github.com/google/go-containerregistry v0.21.7` → [Updates: `v0.21.9`] - `github.com/google/gofuzz v1.2.0` - `github.com/google/gopacket v1.1.19` - `github.com/google/uuid v1.6.0` - `github.com/gorilla/websocket v1.5.4-0.20250319132907-e064f32e3674@e064f32e3674` - `github.com/gosnmp/gosnmp v1.44.0` - `github.com/grpc-ecosystem/go-grpc-middleware/v2 v2.3.3` - `github.com/h2non/filetype v1.1.3` - `github.com/hashicorp/consul/api/v2 v2.0.0` - `github.com/hashicorp/go-multierror v1.1.1` - `github.com/hashicorp/go-retryablehttp v0.7.8` - `github.com/hashicorp/go-version v1.9.0` </details> </blockquote> </details> --- - [ ] <!-- manual job -->Check this box to trigger a request for Renovate to run again on this repository",
          "url": "https://github.com/DataDog/datadog-agent/issues/33469",
          "createdAt": "2025-01-28T12:05:52Z",
          "updatedAt": "2026-08-13T13:44:26Z",
          "timestamp": "2026-08-13T13:44:26Z",
          "metrics": {
            "reactions": 0,
            "comments": 0
          },
          "labels": [
            "team/agent-devx",
            "pending",
            "oss/0"
          ],
          "author": "renovate[bot]",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:3fb6aea206ad86a8e409",
        "signalId": "github:DataDog/datadog-agent:pull_request:54731",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54731",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[procmgr] Windows spawn profiles foundation",
          "text": "### What does this PR do? Introduces **Windows spawn profiles** in dd-procmgr so managed children can run under different security contexts: - **Privileged**: spawn as LocalSystem (supervisor primary token) - **AgentUser**: spawn as the agent service account (`ddagentuser`) Adds the Windows spawn stack (token logon, user profile load, supervision job, suspended `CreateProcessAsUserW`), COAT catalog enforcement for allowed profiles, and gRPC pipe caller authentication. **Stack context:** PR 1/4 split from [#53249](https://github.com/DataDog/datadog-agent/pull/53249). Config gates, secret backend resolution, and process-agent dual-mode integration land in follow-up PRs (`jose/procmgr-config-gates`, `jose/procmgr-secret-backend-gates`, `jose/procmgr-windows-process-agent`). This PR includes a **stub** `config_gate` module (gates always open) so the crate compiles until PR 2. ### Motivation Process-agent on Windows must run as LocalSystem and other agent children should stay on the agent user. Spawn profiles make that explicit and enforceable at spawn time, and are a prerequisite for moving process-agent supervision off legacy SCM in later PRs. ### Describe how you validated your changes - Windows procmgr Rust build/tests in CI - COAT unit tests (`pkg/procmgr/coat/...`) - Windows E2E: privileged spawn catalog enforcement (`test/new-e2e/tests/agent-runtimes/procmgr/...`) ### Additional Notes - No agent startup, fleet installer, or process-agent dual-mode changes in this PR. - [#53568](https://github.com/DataDog/datadog-agent/pull/53568) (list/describe profile + user) should rebase onto this branch once merged. - Supersedes the spawn/COAT portion of [#53249](https://github.com/DataDog/datadog-agent/pull/53249); that PR will be closed after the stack is open.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54731",
          "createdAt": "2026-08-11T15:45:26Z",
          "updatedAt": "2026-08-13T13:43:33Z",
          "timestamp": "2026-08-13T13:43:33Z",
          "metrics": {
            "reactions": 1,
            "comments": 25
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "jose-manuel-almaza",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:af8d0c7396d05f9592f2",
        "signalId": "github:DataDog/datadog-agent:pull_request:54828",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54828",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[EBPF] gpu: add NVLink capability tag",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds `gpu_nvlink_capable` and `gpu_nvlink_version` tags to GPU metrics. ### Motivation Knowing whether a GPU is NVlink-capable and the version of the NVlink system or not is useful to ensure the presence of certain metrics and to compare GPU performance. Another PR will also use part of this code to allow segmenting telemetry based on NVLink capability. ### Describe how you validated your changes Unit tests, manually validated in nvlink-enabled instance. ### Additional Notes Both tags might be slightly redundant but having two doesn't cost extra cardinality (gpu_uuid is already there, with one value per GPU) and it allows separating \"nvlink GPUs/non nvlink GPUs\" and between specific versions.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54828",
          "createdAt": "2026-08-13T11:52:04Z",
          "updatedAt": "2026-08-13T13:43:08Z",
          "timestamp": "2026-08-13T13:43:08Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "team/ebpf-platform",
            "qa/done",
            "team/container-platform",
            "long review",
            "team/container-integrations",
            "internal",
            "team/gpu-monitoring-agent"
          ],
          "author": "gjulianm",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:fbc150468669c3cd6dd3",
        "signalId": "github:DataDog/datadog-agent:pull_request:54715",
        "event": "discovered",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54715",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[SBOM] Refresh every image when spreading the refresh",
          "text": "### What does this PR do? The spread refresher divides the image count by the number of steps it spreads a period over to decide how many images to refresh per step. The division truncates, so a host with fewer than ten images refreshed none of them, ever. An image SBOM was then sent only when the image changed or when a container first ran it, so inUse stayed true after the last container stopped. Above ten, unless the count was a multiple of ten, the refresh was merely slower than configured. Fifteen images took one and a half periods to cycle. Round the count up. Every image is then covered within one period, at the cost of at most nine extra refreshes per period. That overhead only matters where images are few, and a host with a single image now sends it once per step rather than once per period. The refresher is off by default, so this only affects hosts that set sbom.container_image.use_spread_refresher.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54715",
          "createdAt": "2026-08-11T12:21:55Z",
          "updatedAt": "2026-08-13T13:42:26Z",
          "timestamp": "2026-08-13T13:42:26Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "team/agent-security",
            "qa/done",
            "medium review",
            "team/container-integrations",
            "team/agent-build",
            "internal"
          ],
          "author": "0intro",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:8b265a6850728833b11c",
        "signalId": "github:DataDog/datadog-agent:pull_request:54822",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54822",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[AAD-37] Optimize total series count",
          "text": "### What does this PR do? `TotalSeriesCount` was taking a lot of CPU time (and mostly for telemetry), removed overhead by O(1) CPU / memory. This removes 36.8% of CPU on the staging cluster I tested, quick win! ### Motivation ### Describe how you validated your changes [Profile](https://ddstaging.datadoghq.com/profiling/comparison?query=service%3Adatadog-agent%20kube_cluster_name%3Astingchameleon&compare_end_A=1786621749000&compare_end_B=1786626605000&compare_start_A=1786620495000&compare_start_B=1786625998000&compareValuesMode=absolute&my_code=enabled&profiling-flame-graph__filter=focus_on%28package%3Agithub.com%2FDataDog%2Fdatadog-agent%2Fcomp%2Fanomalydetection%29&viz=flame_graph&from_ts=1786623005144&to_ts=1786626605144&live=false) <img width=\"2375\" height=\"497\" alt=\"Screenshot 2026-08-13 at 15 21 37\" src=\"https://github.com/user-attachments/assets/126c3a5c-543e-4e92-8f02-4682e20e45e4\" /> ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54822",
          "createdAt": "2026-08-13T11:16:18Z",
          "updatedAt": "2026-08-13T13:38:42Z",
          "timestamp": "2026-08-13T13:38:42Z",
          "metrics": {
            "reactions": 2,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "medium review",
            "internal"
          ],
          "author": "CelianR",
          "state": "open",
          "assignees": [
            "CelianR"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:9b0a42ac0b0ae28ff470",
        "signalId": "github:DataDog/datadog-agent:pull_request:54803",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54803",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "WIF-48: wire delegated auth into endpoint subsystems",
          "text": "## Summary Stacked on #53517, this PR integrates delegated-auth-managed `DELA(...)` additional endpoints into Agent subsystems: - discovers delegated-auth directives in every supported map- and list-shaped additional-endpoints setting - preserves pending directives during startup and excludes them from outbound keys until resolution - updates forwarder, logs, process, and orchestrator endpoint handling - rebuilds trace proxy transports after delegated-auth resolution and reload; trace writers still require restart to add a previously unresolved endpoint The customer-facing release note is in the foundation PR, #53517. This stacked integration PR is labeled `changelog/no-changelog` to avoid duplicating it. ## Validation Focused tests passed: - forwarder resolver and logs endpoint behavior - trace reload callback and pending-directive transport behavior - config setup parsing, fallback resolution, redaction, map/list registration, and multi-org cases - orchestrator configuration Full trace-config and trace-API Bazel targets are blocked locally by sandbox limitations unrelated to this change: the trace-config external-hostname test cannot find `go` in the Bazel sandbox, and trace-API UDS tests cannot bind a temporary Unix socket in the macOS sandbox. The process-runner target is platform-skipped. ## Dependency Depends on #53517.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54803",
          "createdAt": "2026-08-13T02:02:43Z",
          "updatedAt": "2026-08-13T13:37:51Z",
          "timestamp": "2026-08-13T13:37:51Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "long review"
          ],
          "author": "wynbennett",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:4a6475f24271f120bc98",
        "signalId": "github:DataDog/datadog-agent:pull_request:54823",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54823",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix(aix): discover Python checks via integrations-core AIX manifest tag",
          "text": "### What does this PR do? Replaces the hardcoded AIX Python check list with dynamic discovery of every integrations-core check tagged `Supported OS::AIX`. ### Motivation Keep AIX in sync with integrations-core instead of drifting from a hand-maintained list. ### Describe how you validated your changes Ran the updated stage on an AIX 7.3 build host: it installed all currently AIX-tagged checks with no errors. ### Additional Notes `ibm_spectrum_lsf` is dropped — it was hardcoded before but never actually tagged for AIX upstream.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54823",
          "createdAt": "2026-08-13T11:32:13Z",
          "updatedAt": "2026-08-13T13:37:41Z",
          "timestamp": "2026-08-13T13:37:41Z",
          "metrics": {
            "reactions": 2,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "short review",
            "team/agent-build",
            "internal"
          ],
          "author": "pgimalac",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:8d5ea52e65eb0ac4ff84",
        "signalId": "github:DataDog/datadog-agent:pull_request:54792",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54792",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Increase Quality Gate memory thresholds for ADP pre-flight mode",
          "text": "ADP pre-flight mode (#54175) adds 23 MiB to peak PSS on every workload that exercises a default Agent configuration. Pre-flight is enabled by default and runs ADP for 90 seconds at startup in anticipation of turning it on by default. This PR re-baselines all Quality Gate memory thresholds. | Gate | Old (MiB) | Observed (MiB) | New (MiB) | |---|---|---|---| | `quality_gate_idle` | 154 | 174.89 | 178 | | `quality_gate_logs` | 195 | 216.59 | 229 | | `quality_gate_metrics_logs` | 430 | 417.52 | 439 | | `quality_gate_idle_all_features` | 512 | 524.74 | 538 | | `quality_gate_security_idle` | 330 | 330.55 | 335 | | `quality_gate_security_no_fs_load` | 320 | 319.31 | 343 | | `quality_gate_security_mean_fs_load` | 310 | 309.05 | 314 | | `quality_gate_private_action_runner` | 75 | 74.04 | 76 | Observed values come from `total_pss_bytes` on the comparison variant of last night's Quality Gate run. Bounds are sized to 1% over observed + 1 MiB, with the exception of `logs`, `metrics_logs`, and `security_no_fs_load`. Those three are sized against their three-week peak to account for variability that is not currently captured every night.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54792",
          "createdAt": "2026-08-12T17:54:22Z",
          "updatedAt": "2026-08-13T13:36:59Z",
          "timestamp": "2026-08-13T13:36:59Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "team/agent-security",
            "team/single-machine-performance",
            "qa/no-code-change",
            "medium review",
            "team/action-platform",
            "internal",
            "team/agent-data-plane"
          ],
          "author": "GeorgeHahn",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:131050de34f0316ba3f0",
        "signalId": "github:DataDog/datadog-agent:pull_request:53517",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53517",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "WIF-48: add delegated-auth dual-shipping foundation",
          "text": "## Summary This PR contains the reusable delegated-auth foundation for WIF dual shipping: - extends the delegated-auth component so an instance can update an additional-endpoint key in either map- or list-shaped configuration - adds shared helpers for normalizing list-shaped endpoints and reading case-insensitive fields - recognizes pending `DELA(...)` directives so consumers can avoid sending them as literal API keys - exchanges proofs against the configured target site rather than always using `dd_url` - covers token-domain parsing, component updates, and directive handling with unit tests The Agent subsystem integration is intentionally split into a stacked follow-up PR. It wires this foundation into config setup, forwarder, logs, process, orchestrator, and trace-agent reload/proxy behavior. ## Validation - `bazel test //comp/core/delegatedauth/... //pkg/config/utils/... --build_tests_only` ## Review note The local subagent reviewer service failed before startup, so its adversarial and security passes could not run. No review findings were produced.",
          "url": "https://github.com/DataDog/datadog-agent/pull/53517",
          "createdAt": "2026-07-10T17:39:01Z",
          "updatedAt": "2026-08-13T13:36:37Z",
          "timestamp": "2026-08-13T13:36:37Z",
          "metrics": {
            "reactions": 1,
            "comments": 7
          },
          "labels": [
            "team/agent-apm",
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-configuration",
            "team/agent-log-pipelines",
            "team/agent-metric-pipelines",
            "team/container-experiences",
            "team/agent-build",
            "team/kubernetes-experiences",
            "internal",
            "team/fleet-automation"
          ],
          "author": "wynbennett",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:99787fc3fc81ef46a704",
        "signalId": "github:DataDog/datadog-agent:pull_request:54810",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54810",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Remove bazel strptime_cgo_testlib override",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Remove bazel strptime_cgo_testlib override. ### Motivation Fixed by https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/49516. ### Describe how you validated your changes CI ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54810",
          "createdAt": "2026-08-13T08:49:37Z",
          "updatedAt": "2026-08-13T13:36:02Z",
          "timestamp": "2026-08-13T13:36:02Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "internal"
          ],
          "author": "pgimalac",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:74e8fc8577eed7c8c3a7",
        "signalId": "github:DataDog/datadog-agent:pull_request:54831",
        "event": "discovered",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54831",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "test(e2e): add IBM MQ integration lab",
          "text": "### What does this PR do? Adds a deploy=true E2E-framework lab for the `ibm_mq` integration under `test/e2e-framework/scenarios/aws/integrations/ibm_mq`. The scenario self-provisions **IBM MQ Advanced for Developers 9.3** with a configurable number of queue managers and queues on a single amd64 RHEL 8 EC2 host, co-located with the Datadog Agent. A systemd-driven put/get load generator keeps queue depth and enqueue/dequeue metric families non-zero so the `ibm_mq` check has realistic work to do. It exposes knobs for: - queue-manager count and queues per manager - collection interval - queue selection strategy (auto-discovery / regex / explicit) - `collect_reset_queue_metrics` - metric exclusion patterns - integration and internal profiling Wiring: registered in the integrations `registry.go` + `BUILD.bazel`, and in the invoke task collection, giving the usual task surface: ``` dda inv aws.integrations.ibm-mq.{create,status,check,exec,ssh,destroy,reload-check} ``` ### Motivation Provide a reproducible, self-contained environment to investigate `ibm_mq` check CPU cost as queue-manager and queue counts scale — the check can become expensive with large queue counts and auto-discovery, and this lab makes that behavior easy to reproduce and profile in isolation. ### Describe how you validated your changes - `gofmt` clean on `registry.go` and all `ibm_mq/*.go`. - `go build ./scenarios/aws/integrations/...` in the `test/e2e-framework` module succeeds. - `dda inv aws.integrations -l` lists all `ibm-mq.*` tasks. - pre-commit hooks (shellcheck, go-fmt, copyright, python-linter, …) pass. ### Additional Notes Follows the existing integration-lab pattern (kafka, lustre, etc.). The scenario provisions billable EC2; remember to `dda inv aws.integrations.ibm-mq.destroy` when finished.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54831",
          "createdAt": "2026-08-13T13:26:11Z",
          "updatedAt": "2026-08-13T13:35:43Z",
          "timestamp": "2026-08-13T13:35:43Z",
          "metrics": {
            "reactions": 1,
            "comments": 0
          },
          "labels": [
            "long review",
            "team/agent-integrations",
            "team/agent-build",
            "internal"
          ],
          "author": "dkirov-dd",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:78fe318be429ade28fee",
        "signalId": "github:DataDog/datadog-agent:pull_request:51295",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:51295",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add source to distributions via checks.",
          "text": "### What does this PR do? This adds the source to distributions that have been submitted by a Go check. ### Motivation Source was added to other metrics in #20690. This completes the source for distributions. ### Describe how you validated your changes Tested manually by creating a dummy go check, which was not added to this PR. ### Additional Notes [RFC outlining](https://datadoghq.atlassian.net/wiki/spaces/AM/pages/6773538856/RFC+-+Add+origin+to+check+distribution+metrics) the impact of this change. (TLDR there is no known negative impact)",
          "url": "https://github.com/DataDog/datadog-agent/pull/51295",
          "createdAt": "2026-05-26T11:16:34Z",
          "updatedAt": "2026-08-13T13:35:42Z",
          "timestamp": "2026-08-13T13:35:42Z",
          "metrics": {
            "reactions": 2,
            "comments": 8
          },
          "labels": [
            "qa/done",
            "short review",
            "team/agent-metric-pipelines",
            "internal"
          ],
          "author": "StephenWakely",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:27cd048a9d40114f4542",
        "signalId": "github:DataDog/datadog-agent:pull_request:54471",
        "event": "discovered",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54471",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CWS-6177] Use dynamic sampling",
          "text": "### What does this PR do? Makes CWS event sampling react to event stream backpressure instead of applying a fixed rate limit. All rate-limit decisions for the sampled event types (`open`, `connect`, `bind`, `dns`) now route through a new eBPF helper, `sampling_admission_check()` in `pkg/security/ebpf/c/include/helpers/approvers.h`. It reads the current events ring buffer occupancy with `bpf_ringbuf_query()`, converts it to a pressure percentage against the configured ring buffer size, and picks one of three behaviors: | Ring buffer pressure | Behavior | |---|---| | `< threshold` (per event type) | Bypass the rate limiter, always sample | | `threshold` to 90% | Fall back to the existing token-bucket limiter | | `> 90%` (`SAMPLING_PRESSURE_CRITICAL`) | Drop the sample outright | Thresholds are per event type and configurable, defaulting to `open: 80`, `dns: 60`, `bind: 60`, `connect: 40`. A higher threshold means the limiter is bypassed for longer, so that event type is throttled later. The whole path is gated behind a new `event_sampling.dynamic.enabled` setting and behind `USE_RING_BUFFER` plus a runtime `use_ring_buffer` check. When either is off, behavior is identical to today. Also adds a `datadog.runtime_security.event_sample.pressure_level` gauge reporting the peak pressure observed per stats window. ### Config ``` # BEFORE — fixed rate, 500 events/sec per type regardless of load runtime_security_config: event_sampling: open: enabled: true rate: 500 connect: enabled: true rate: 500 bind: enabled: true rate: 500 dns: enabled: true rate: 500 ``` ``` # AFTER — same config still valid; opt in to pressure-aware sampling runtime_security_config: event_sampling: dynamic: enabled: true # new: turns on pressure-aware admission open: enabled: true rate: 500 # now the throttled-band rate, not a hard cap threshold: 80 # new: bypass the limiter below 80% buffer pressure connect: enabled: true rate: 500 threshold: 40 bind: enabled: true rate: 500 threshold: 60 dns: enabled: true rate: 500 threshold: 60 ```",
          "url": "https://github.com/DataDog/datadog-agent/pull/54471",
          "createdAt": "2026-08-05T13:37:32Z",
          "updatedAt": "2026-08-13T13:34:57Z",
          "timestamp": "2026-08-13T13:34:57Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/agent-security",
            "team/ebpf-platform",
            "qa/done",
            "medium review",
            "internal",
            "team/fleet-automation"
          ],
          "author": "mftoure",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:dd13ef10acb78f859214",
        "signalId": "github:DataDog/datadog-agent:pull_request:54508",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54508",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix(cluster-agent): gate pprof/expvar debug endpoints to loopback",
          "text": "### What does this PR do? The Cluster Agent's metrics server (`0.0.0.0:metrics_port`, default `5000`) served the entire `http.DefaultServeMux`, exposing the `pprof` and `expvar` debug endpoints (registered via blank imports in `cmd/cluster-agent/main.go`) unauthenticated to anything that can reach the pod. This routes only `/metrics` on the public mux and gates everything under `/debug/` to loopback callers, returning `404` to non-loopback requests. ### Motivation Solves #CONTP-1771 and #VULN-87907. `/metrics` must stay reachable off-pod so the node Agent can scrape Cluster Agent telemetry, so a blanket localhost bind (like the core Agent's expvar server) isn't viable — hence a per-path loopback gate. This removes an unauthenticated, network-reachable debug/DoS surface while preserving telemetry scraping and local flare tooling. ### Describe how you validated your changes - Unit tests (`TestLoopbackOnly`, `TestMetricsMuxRouting`) covering loopback vs off-host for `/metrics` and `/debug/*` — 16/16 pass. - `dda inv cluster-agent.build` links clean; `dda inv linter.go` clean; release-note lint clean. - Generated a flare. - Deployed the built cluster-agent image to a local minikube cluster and curled the live DCA pod: - **In-pod** (loopback `127.0.0.1:5000`): `/metrics`, `/debug/vars`, `/debug/pprof/*` all `200` — flare/profiler unaffected. - **Off-pod** (from a separate pod → DCA pod IP): `/debug/*` = `404`, `/metrics` = `200`. - Verified nothing else is registered on the DCA's `DefaultServeMux` (only `pprof`/`expvar`), so no routes are dropped. ### Additional Notes Brings the DCA in line with the core Agent, which already binds its equivalent `pprof`/`expvar` server to `127.0.0.1`, while keeping `/metrics` public.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54508",
          "createdAt": "2026-08-06T12:20:07Z",
          "updatedAt": "2026-08-13T13:34:46Z",
          "timestamp": "2026-08-13T13:34:46Z",
          "metrics": {
            "reactions": 1,
            "comments": 8
          },
          "labels": [
            "qa/done",
            "team/container-platform",
            "medium review",
            "qa/skip-qa",
            "team/agent-build",
            "internal"
          ],
          "author": "wdhif",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:a5d197681d047b5d27e7",
        "signalId": "github:DataDog/datadog-agent:pull_request:54776",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54776",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Force LF line endings for text files by default on gitattributes",
          "text": "### What does this PR do? This PR sets a catch-all .gitattributes line that forces all files that git identifies as \"text\" (based on `text=auto`) to be checked out with LF endings by default (i.e. anything not matched by any other line in .gitattributes), regardless of platform and `core.autocrlf` setting. The PR also adjusts the .gitattributes file such that: - Existing individual settings of `text=auto eol=lf` are removed as they're covered by the new catch-all line. - It adds entries that allow us to make the change to .gitattributes without having to change any file as part of the same change. This means adding exceptions matching files that were identified as being stored with CRLF endings in git, as well as a golden file for a test which would fail under this new normalization. ### Motivation The original reason for this is that I was getting cache misses on Windows when trying to build python (`bazel build @cpython//:python_win`), which with help of execution logs I identified as coming from differences in the file https://github.com/DataDog/datadog-agent/blob/main/deps/cpython/redacted_compat.h. CI converts this file to add CRLF endings, whereas my local machine had at some point disabled `autocrlf` which meant my local file was using LF endings. Enabling [core.autocrlf](https://git-scm.com/docs/git-config#Documentation/git-config.txt-coreautocrlf) causes git to automatically decide, for files not matching any pattern in our .gitattributes file, whether to \"translate\" a file to using CRLF depending on the platform (on Windows, basically). The core rationale for this change is that it's extremely undesirable to have git config, which can differ from machine to machine, influence the bytes that you get on a checkout. This is even more so in a Bazel-enabled repo, where hashes of files are used everywhere for identity (caching, lockfiles, etc.). This change targets that behavior directly by ensuring we get no discrepancies in the future. I think this is justified even if the current default on windows git installs seems to enable autocrlf, because it implies our setup relying on something that is out of our control. ### Describe how you validated your changes Passing tests, confirmed `git add --renormalize .` doesn't touch anything, and `git ls-files --eol` reports the expected results. ### Additional Notes Existing checkouts won't automatically get the line endings matching the .gitattributes changes. For that, on a clean tree, something like this might be needed: ``` git rm --cached -r . git reset --hard HEAD ``` I'll be removing the individual exceptions in chunks, to limit the scope of the changes and make them easier to revert.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54776",
          "createdAt": "2026-08-12T12:21:26Z",
          "updatedAt": "2026-08-13T13:34:20Z",
          "timestamp": "2026-08-13T13:34:20Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "alopezz",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:f971126d8641f0512ff4",
        "signalId": "github:DataDog/datadog-agent:pull_request:54814",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54814",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[AGENTRUN-1446] Skip nss failover e2e test it if the fakeintakes are still in use",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Due to a framework issue, the fakeintakes might still be in use (ie. an agent is still sending payloads to them) when the test starts, which makes the test flaky. We added a detection logic to fail early in this case (to avoid confusion when debugging). Update the logic to skip the test rather than fail it in this case. ### Motivation Avoid receiving notifications for failed test for a framework issue. ### Describe how you validated your changes CI ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54814",
          "createdAt": "2026-08-13T09:46:46Z",
          "updatedAt": "2026-08-13T13:34:04Z",
          "timestamp": "2026-08-13T13:34:04Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "team/agent-runtimes",
            "team/agent-build",
            "internal"
          ],
          "author": "pgimalac",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:44488044be9bccb3a84d",
        "signalId": "github:DataDog/datadog-agent:pull_request:54375",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54375",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "configfilesdiscovery: collect redis env vars",
          "text": "### What does this PR do? Collects selected, non-secret Redis environment variables alongside Redis config files in `configfilesdiscovery`. It uses regex-based allow and deny rules plus the shared secret-name filter. Config-file selection follows `redis-server` argv, then `REDIS_CONF_FILE`, then known default paths. The shared reader accepts the optional fallback while Kafka retains its existing behavior by passing none. ### Motivation DSCVR-619 ### Describe how you validated your changes Unit tests. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54375",
          "createdAt": "2026-08-03T15:53:00Z",
          "updatedAt": "2026-08-13T13:33:57Z",
          "timestamp": "2026-08-13T13:33:57Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "medium review",
            "team/agent-discovery",
            "internal"
          ],
          "author": "Yumasi",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:87c26d688f9f9ae385b2",
        "signalId": "github:DataDog/datadog-agent:pull_request:54815",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54815",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[DSEC] Move dd-sds dependency to shared workspace",
          "text": "### What does this PR do? Moves the `dd-sds` (`dd-sensitive-data-scanner`) dependency from the `datasecurity` check crate into the shared `[workspace.dependencies]` in the root `Cargo.toml`. The crate now references it via `dd_sds.workspace = true`. ### Motivation Centralize the pinned version and feature set so future check crates share a single source of truth instead of duplicating the spec. ### Tests Use docker image registry.ddbuild.io/ci/datadog-agent/agent:v130685756-40c89d95-7-amd64 generated in the CI and confirmed that data security check is correctly running. ```bash dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/aggregator/aggregator.go:182 in LogMsg) | datasecurity: sub task succeeded (1 match(es)) dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/aggregator/aggregator.go:182 in LogMsg) | datasecurity: running sub task (sub_task_id=455ECD24-5C11-45AA-801B-5C2C43C8533C, platform=postgres) dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (comp/core/agenttelemetry/impl/agenttelemetry.go:665 in run) | Starting agent telemetry run dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/aggregator/aggregator.go:182 in LogMsg) | datasecurity: sub task succeeded (1 match(es)) dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/aggregator/aggregator.go:182 in LogMsg) | datasecurity: check completed dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/worker/check_logger.go:59 in CheckFinished) | check:datasecurity | Done running check dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/worker/check_logger.go:65 in CheckFinished) | check:datasecurity | Check's one time execution has finished ```",
          "url": "https://github.com/DataDog/datadog-agent/pull/54815",
          "createdAt": "2026-08-13T10:12:22Z",
          "updatedAt": "2026-08-13T13:33:53Z",
          "timestamp": "2026-08-13T13:33:53Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "short review",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "aimenebelfodil",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:92c38a8861c380c120b8",
        "signalId": "github:DataDog/datadog-agent:pull_request:54819",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54819",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Copy python files to avoid junction issues",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54819",
          "createdAt": "2026-08-13T10:45:46Z",
          "updatedAt": "2026-08-13T13:33:35Z",
          "timestamp": "2026-08-13T13:33:35Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/agent-build",
            "internal"
          ],
          "author": "JSGette",
          "state": "open",
          "assignees": [
            "JSGette"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:dcc337edaba576b42a3b",
        "signalId": "github:DataDog/datadog-agent:pull_request:54735",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54735",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[procmgr] Supervise process-agent on Windows via dd-procmgr",
          "text": "### What does this PR do? Moves Windows **process-agent** supervision to **dd-procmgr** using the same dual-mode pattern as PAR: - Fleet installer writes `processes.d/datadog-agent-process.yaml` (Privileged spawn profile) - Legacy `datadog-process-agent` SCM service is suppressed when procmgr owns process-agent - Agent startup waits on `dd-procmgr-service` before starting gated legacy children; independent services (sysprobe, security-agent, installer) start without blocking on procmgr Also runs **dd-procmgr-service as LocalSystem** (MSI service custom action) so the supervisor can spawn Privileged children while agent-profile processes still spawn as `ddagentuser`. **Stack context:** PR 4/4 split from [#53249](https://github.com/DataDog/datadog-agent/pull/53249). Builds on [#54734](https://github.com/DataDog/datadog-agent/pull/54734) → [#54732](https://github.com/DataDog/datadog-agent/pull/54732) → [#54731](https://github.com/DataDog/datadog-agent/pull/54731). Spawn profiles, config gates, and secret backend resolution land in those PRs. ### Motivation We want subservices on dd-procmgr instead of SCM. Process-agent needs LocalSystem on Windows; other agent children should stay on the agent user. This PR wires the product integration once the procmgr foundation (PRs 1–3) is in place. ### Describe how you validated your changes - Go unit tests for dependent Windows service startup (`dependent_services_windows_test.go`) - Go unit tests for fleet installer templates and YAML path substitution (`processmanager/...`) - New Windows E2E: process-agent supervised by procmgr, runs as LocalSystem, legacy SCM stopped - E2E: dd-procmgr-service runs as LocalSystem; agent-profile children run as agent user - E2E: privileged spawn catalog enforcement when processes.d YAML is tampered with - PAR/procmgr Windows E2E regression ### Additional Notes - Linux process-agent stays on systemd for now. Legacy SCM service registration is not removed yet. - Process-agent `processes.d` config uses the shared `install_root` helper (same as PAR/ADP). MSI `RemoveFolderEx` handles uninstall/rollback cleanup; no per-file MSI rollback custom actions. - Includes release note `windows-process-procmgr-dual-mode-b7d2e4a1c8f03962.yaml`. - Closes/supersedes [#53249](https://github.com/DataDog/datadog-agent/pull/53249) once the full stack merges.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54735",
          "createdAt": "2026-08-11T16:07:07Z",
          "updatedAt": "2026-08-13T13:32:35Z",
          "timestamp": "2026-08-13T13:32:35Z",
          "metrics": {
            "reactions": 2,
            "comments": 1
          },
          "labels": [
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "jose-manuel-almaza",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:64f84ff1db84fee3e47c",
        "signalId": "github:DataDog/datadog-agent:pull_request:54732",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54732",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[procmgr] Config gates for processes.d auto-start",
          "text": "### What does this PR do? Adds **config gates** to dd-procmgr so `processes.d` definitions can use `condition_config_any` to auto-start only when Agent config says they should. Implementation mirrors the Windows legacy SCM startup checks in `dependent_services_windows.go` and Agent config resolution: - YAML lookup (case-insensitive keys, flattened dotted keys, permissive parse fallback, merge keys) - Environment bindings (`DD_*`) with Agent precedence (ignore empty values, no trim before `ParseBool`, legacy `process_config.enabled` transforms) - Fleet policy merge - Derived `system_probe_config.enabled` (USM/NPM/security knobs, sk-tracer and discovery adjustments) - Windows: read `DD_*` overrides from the core Agent SCM `Environment` registry when not set in the procmgr process env Wires gate evaluation into `ManagedProcess` start/reload paths in the manager. **Stack context:** PR 2/4 split from [#53249](https://github.com/DataDog/datadog-agent/pull/53249). Builds on [#54731](https://github.com/DataDog/datadog-agent/pull/54731) (`jose/procmgr-spawn-profiles`). `ENC[...]` secret backend resolution lands in PR 3 (`jose/procmgr-secret-backend-gates`). Process-agent dual-mode integration lands in PR 4 (`jose/procmgr-windows-process-agent`). ### Motivation Moving subservices (starting with process-agent) to dd-procmgr requires the supervisor to apply the same start/stop rules as the Agent today. Without config gates, a `processes.d` entry would always spawn when registered, which breaks parity with legacy SCM and fleet policy. ### Describe how you validated your changes - Rust unit tests in `pkg/procmgr/rust/src/config_gate/` (env bindings, YAML load, system-probe derivations, gate evaluation) - Go unit tests for Windows config helpers (`pkg/config/setup/config_windows_test.go`) - Windows procmgr Rust build/tests in CI ### Additional Notes - No `ENC[...]` / secret backend resolution in this PR (fleet policy `ENC[...]` values are not resolved here either). - No agent startup, fleet installer, or legacy SCM suppression changes in this PR. - Schema comment sync in `pkg/config/schema/yaml/process_config.yaml` for env binding documentation. - Small exports in `pkg/system-probe/config/` so procmgr gate derivations stay aligned with Go `adjust*` logic.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54732",
          "createdAt": "2026-08-11T15:51:46Z",
          "updatedAt": "2026-08-13T13:32:30Z",
          "timestamp": "2026-08-13T13:32:30Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "team/ebpf-platform",
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-devx",
            "team/container-experiences",
            "team/agent-build",
            "team/windows-products",
            "internal",
            "team/fleet-automation"
          ],
          "author": "jose-manuel-almaza",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:9e6717808a3ddbb8ad61",
        "signalId": "github:DataDog/datadog-agent:pull_request:54734",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54734",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[procmgr] Secret backend resolution for config gates",
          "text": "### What does this PR do? Resolves `ENC[...]` values during config gate evaluation so dd-procmgr matches Agent secret handling. Adds: - `config_gate/secrets.rs`: resolve handles via `secret_backend_command`, native `secret_backend_type`, and `multi_secret_backends` (same precedence as the core Agent) - Platform secret backend runners (Windows `CreateProcessAsUserW` under the Agent account; Unix setuid when procmgr runs as root for Privileged children) - `secret_backend_exec.rs`: shared spawn, timeout, stdout drain, and response parsing - Windows ACL validation on secret backend executables before spawn - Agent config precedence for backend settings: `DD_SECRET_BACKEND_*` env (including core Agent SCM `Environment` on Windows) over `datadog.yaml` - Manager reload: invalidate secret caches when config changes Fleet policy `ENC[...]` values stay unresolved here, matching Agent `MergeFleetPolicy` running after secret resolution. **Stack context:** PR 3/4 split from [#53249](https://github.com/DataDog/datadog-agent/pull/53249). Builds on [#54732](https://github.com/DataDog/datadog-agent/pull/54732) (`jose/procmgr-config-gates`), which in turn builds on [#54731](https://github.com/DataDog/datadog-agent/pull/54731). Process-agent dual-mode integration lands in PR 4 (`jose/procmgr-windows-process-agent`). ### Motivation PR 2 config gates read YAML, env, and fleet policy, but many customers gate features with secret-backed settings (`ENC[api_key]`, secret-backed booleans, etc.). Without secret resolution, gates would mis-evaluate and auto-start behavior would diverge from the Agent. ### Describe how you validated your changes - Rust unit tests in `pkg/procmgr/rust/src/config_gate/secrets.rs` and config gate integration tests (serialized env to avoid cross-test leakage) - Windows procmgr Rust build/tests in CI - Linux CI: secret-backend tests run under the agent service user where required ### Additional Notes - Secret backends always run as the core Agent service account, not as the procmgr supervisor (LocalSystem) or a Privileged managed child. - No agent startup, fleet installer, or legacy SCM suppression changes in this PR. - Invokes `secret-generic-connector` when no custom `secret_backend_command` is configured.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54734",
          "createdAt": "2026-08-11T15:56:49Z",
          "updatedAt": "2026-08-13T13:32:22Z",
          "timestamp": "2026-08-13T13:32:22Z",
          "metrics": {
            "reactions": 2,
            "comments": 1
          },
          "labels": [
            "changelog/no-changelog",
            "team/ebpf-platform",
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-devx",
            "team/container-experiences",
            "team/agent-build",
            "team/windows-products",
            "internal",
            "team/fleet-automation"
          ],
          "author": "jose-manuel-almaza",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:feccada90007f0278ea6",
        "signalId": "github:DataDog/datadog-agent:pull_request:54780",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54780",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Use bazel driven windows resources in windows_resources.py",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? `agent.build` task fails unable to find `windmc` tool in case it isn't accessible in `PATH`. This change handles this by letting tasks use `windmc` managed by Bazel. In this case we ensure that, regardless of the state of the build environment, `windmc` is there and accessible.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54780",
          "createdAt": "2026-08-12T13:23:33Z",
          "updatedAt": "2026-08-13T13:31:32Z",
          "timestamp": "2026-08-13T13:31:32Z",
          "metrics": {
            "reactions": 2,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "team/windows-products",
            "internal"
          ],
          "author": "JSGette",
          "state": "closed",
          "assignees": [
            "JSGette"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:7431e5b18da3d42b0642",
        "signalId": "github:DataDog/datadog-agent:pull_request:54809",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54809",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(cancel): Force cancellation of running jobs",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Improve cleanup to also cancel running jobs. Move call to stack-cleaner to after_script, which is executed after a \"graceful\" (not forced) job cancel. Prevent cleanup of whitelisted jobs. ### Motivation Reduce pressure on infrastructure. ### Describe how you validated your changes Local tests and attempt to push a new commit on this precise branch ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54809",
          "createdAt": "2026-08-13T08:42:37Z",
          "updatedAt": "2026-08-13T13:29:19Z",
          "timestamp": "2026-08-13T13:29:19Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/container-integrations",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "chouetz",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:4feae066bc883e7d5262",
        "signalId": "github:DataDog/datadog-agent:pull_request:54779",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54779",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Remove unused SyncCapture",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Remove unused `SyncCapture` code in log package. ### Motivation This is currently dead code. Discussed with the team which introduced this and it has been refactored so this is not needed anymore. ### Describe how you validated your changes No functional change expected. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54779",
          "createdAt": "2026-08-12T13:05:34Z",
          "updatedAt": "2026-08-13T13:27:55Z",
          "timestamp": "2026-08-13T13:27:55Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "short review",
            "team/agent-runtimes",
            "internal"
          ],
          "author": "pgimalac",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:836942e60e9573b9f3ed",
        "signalId": "github:DataDog/datadog-agent:pull_request:54826",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54826",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[EBPF] Download gpu-burner for GPU tests",
          "text": "### What does this PR do? Downloads gpu-burner before GPU integration tests run. ### Motivation Allow the tests to use the gpu-burner mASS artifact. ### Describe how you validated your changes Confirmed the CI rules trigger `tests_gpu` for this file change. ### Additional Notes The referenced branch artifact expires after seven days.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54826",
          "createdAt": "2026-08-13T11:49:04Z",
          "updatedAt": "2026-08-13T13:25:24Z",
          "timestamp": "2026-08-13T13:25:24Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "team/ebpf-platform",
            "short review",
            "team/agent-devx",
            "team/agent-build",
            "internal",
            "team/gpu-monitoring-agent"
          ],
          "author": "gjulianm",
          "state": "open",
          "assignees": [
            "gjulianm"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:f848df970cbbbcfb596b",
        "signalId": "github:DataDog/datadog-agent:pull_request:54676",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54676",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[procmgr] Extract shared Rust client",
          "text": "### What does this PR do? Extracts a `dd-procmgr-client` Rust crate from client code in `dd-procmgrd`: - process-manager protobuf/gRPC bindings; - default endpoint and `DD_PM_SOCKET_PATH` handling; - Unix socket and Windows named-pipe connections; - Windows busy-pipe retry behavior. The `dd-procmgr` CLI now uses this crate. The daemon reuses its bindings and endpoint resolution, but keeps all server transport, process supervision, and lifecycle code. This is a code move and dependency cleanup. It does not change the protocol, endpoint defaults, retry policy, or process-manager behavior. ### Why? A later PR in the Private Action Runner split-mode stack (#54589) adds a second Rust client of `dd-procmgrd`. Without this crate, that client would either depend on the full daemon implementation or copy its platform-specific connection code. ### Validation ```text dda env dev run -- bazel test //pkg/procmgr/rust/... dda env dev run -- cargo clippy --manifest-path pkg/procmgr/rust/client/Cargo.toml --all-targets -- -D warnings dda env dev run -- cargo clippy --manifest-path pkg/procmgr/rust/Cargo.toml --all-targets --features test-helpers -- -D warnings ``` The Bazel suite covers the client, daemon, CLI, and CLI/daemon E2E tests.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54676",
          "createdAt": "2026-08-10T20:37:41Z",
          "updatedAt": "2026-08-13T13:21:58Z",
          "timestamp": "2026-08-13T13:21:58Z",
          "metrics": {
            "reactions": 2,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "long review",
            "team/agent-runtimes",
            "team/agent-devx",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:98e8a1a1548604d35d12",
        "signalId": "github:DataDog/datadog-agent:pull_request:54660",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54660",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(autodiscovery): tag configuration-discovery instances to mitigate duplicate metrics risk",
          "text": "### What does this PR do? Adds a `dd_config_discovery:true` tag to every check instance scheduled via the Autodiscovery configuration-discovery mechanism (i.e. any `auto_conf.yaml` template with `discovery: {}`, resolved through `comp/core/autodiscovery/impl/configmgr_discovery.go`'s `applyDiscoveredConfigsLocked`). The tag used is `dd_config_discovery:true`, a plain `dd_`-prefixed key, following the precedent of other agent-added, customer-visible marker/provenance tags already in the codebase: - `dd_remote_config_id` / `dd_remote_config_rev` (`comp/core/tagger/tags/tags.go`) - `dd_enable_check_intake` (`pkg/collector/worker/worker.go`) ### Motivation [DSCVR-651](https://datadoghq.atlassian.net/browse/DSCVR-651): there is a risk that an agent on host A is monitoring a service on host B with a manually-configured check (e.g. a generic `openmetrics` check), while the agent running locally on host B also autodiscovers and schedules a dedicated integration for the same service via configuration discovery. Neither agent's local anti-duplication logic can see the other's config, so both submit metrics for the same underlying data. This tag doesn't prevent the duplication, but lets users identify and, if needed, exclude the autodiscovered side of it (e.g. `metric{!dd_config_discovery:true}`), both for the cross-host case above and for any single-host case the automatic suppression doesn't catch. ### Describe how you validated your changes Unit and E2E tests. --- 🤖 This PR description and implementation were generated with assistance from [Claude Code](https://claude.com/claude-code). [DSCVR-651]: https://datadoghq.atlassian.net/browse/DSCVR-651?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54660",
          "createdAt": "2026-08-10T16:56:47Z",
          "updatedAt": "2026-08-13T13:18:58Z",
          "timestamp": "2026-08-13T13:18:58Z",
          "metrics": {
            "reactions": 3,
            "comments": 8
          },
          "labels": [
            "qa/done",
            "team/container-platform",
            "medium review",
            "team/agent-discovery",
            "team/agent-build",
            "internal",
            "backport/7.83.x"
          ],
          "author": "vitkyrka",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:3052025e9816563f56fe",
        "signalId": "github:DataDog/datadog-agent:pull_request:54774",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54774",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CWS] Fix: handle activity dump endpoint host that already embeds a port",
          "text": "### What does this PR do? Fixes CWS activity dump uploads to dual-shipped `additional_endpoints` whose `host` already includes a port (e.g. `cws-intake.datadoghq.com.:443`). `GetEndpointURL` was appending the port a second time, producing a malformed `[host:port]:port` authority that failed URL parsing — so every upload to that endpoint failed with an `invalid port` error. The host is now split before joining, so an embedded port is honored instead of duplicated. An explicitly configured port still wins, and bare IPv6 literals are untouched. ### Motivation In prod, CWS activity dumps were failing to reach the secondary (dual-ship) endpoint.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54774",
          "createdAt": "2026-08-12T11:37:04Z",
          "updatedAt": "2026-08-13T13:12:51Z",
          "timestamp": "2026-08-13T13:12:51Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/agent-security",
            "qa/done",
            "short review",
            "team/agent-build",
            "internal"
          ],
          "author": "kovagsm",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:8f83609521f342f103eb",
        "signalId": "github:DataDog/datadog-agent:pull_request:54798",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54798",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[APM] Reduce allocations on the trace decode path",
          "text": "### What does this PR do? Two independent allocation reductions on the trace-agent receive/decode path. **1. Intern strings directly from the payload (v0.4 decode).** `parseStringBytesRef` materialized a Go string for every value just to look it up in the payload's string table, discarding it on a hit. **2. Reserve `bytes.MinRead` beyond the body when buffering a request.** `reserveBodySize` reserved exactly `Content-Length`, but `io.Copy` bottoms out in `bytes.Buffer.ReadFrom`, which needs `bytes.MinRead` of spare capacity for the read that reports EOF. Also fixes two swapped godoc names on `parseStringBytes` / `parseStringBytesRef`. ### Motivation Both were found in a staging heap profile of the trace-agent receiver. `pprof -traces` showed `bytes.Buffer.Grow` and `bytes.Buffer.ReadFrom` both allocating on the same `copyRequestBody` path — i.e. twice per request. ### Describe how you validated your changes New tests and benchmarks in both packages: - `pkg/proto/pbgo/trace/idx/string_intern_test.go` — `TestAddBytesMatchesAdd` asserts `AddBytes` and `Add` are behaviourally equivalent, so no decode divergence is introduced. - `pkg/proto/pbgo/trace/idx/string_intern_bench_test.go` — intern benchmarks across hit rates, including a `HitRate0` control arm. - `pkg/trace/api/body_buffer_test.go` — `TestReserveBodySizeLimit` pins the `MaxRequestBytes` boundary (at / one over / absent / unparseable), confirming the `MinRead` padding does not leak into the size check. `TestCopyRequestBodyNoRealloc` asserts the body lands in the same backing array that was reserved, by identity, rather than counting allocations. - `pkg/trace/api/body_buffer_bench_test.go` — `BenchmarkCopyRequestBody` over two regimes: `SmallWarmPool` (ordinary traffic, shows the change is neutral, 0 allocs/op) and `LargeColdBuffer` (the regime that actually generates the bytes). Also run: full `pkg/trace/api` and `pkg/proto/pbgo/trace/idx` suites, and `bazel test //pkg/proto/pbgo/trace/idx:idx_test //pkg/trace/api:api_test` — all pass. **Time** (benchstat, n=10, Apple M4 Max darwin/arm64; only `span.go` differs between arms) | Benchmark | before | after | delta | |---|---|---|---| | `StringTableIntern/HitRate100` | 24.42µ ± 4% | 14.74µ ± 1% | −39.6% | | `StringTableIntern/HitRate90` | 27.90µ ± 3% | 18.90µ ± 1% | −32.3% | | `StringTableIntern/HitRate50` | 31.80µ ± 2% | 25.63µ ± 1% | −19.4% | | `StringTableIntern/HitRate0` | 35.32µ ± 5% | 34.40µ ± 0% | −2.6% | | `SpanUnmarshalConvertedStrings` | 107.80µ ± 1% | 86.15µ ± 1% | −20.1% | All p=0.000. **Allocations** | Benchmark | before | after | delta | |---|---|---|---| | `HitRate100` | 1003 allocs / 48288 B | 4 allocs / 336 B | −99.6% / −99.3% | | `HitRate90` | 1005 allocs / 44.3KiB | 105 allocs / 9.1KiB | −89.6% / −79.4% | | `HitRate50` | 1005 allocs / 73.8KiB | 505 allocs / 54.2KiB | −49.8% / −26.5% | | `HitRate0` | 1007 allocs / 108.4KiB | 1007 allocs / 108.4KiB | ~ (identical) | | `SpanUnmarshalConvertedStrings` | 3607 allocs / 227.6KiB | 1231 allocs / 197.9KiB | −65.9% / −13.1% | Throughput on the end-to-end span decode: 417.5 → 522.4 MiB/s, +25.1%. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54798",
          "createdAt": "2026-08-12T19:56:32Z",
          "updatedAt": "2026-08-13T13:09:33Z",
          "timestamp": "2026-08-13T13:09:33Z",
          "metrics": {
            "reactions": 2,
            "comments": 6
          },
          "labels": [
            "team/agent-apm",
            "qa/done",
            "medium review",
            "team/agent-build",
            "internal"
          ],
          "author": "ajgajg1134",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:3ace6839ba486caea517",
        "signalId": "github:DataDog/datadog-agent:pull_request:54830",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54830",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Deflake `TestKeepTryingLockingIfPermissionDenied` with `synctest`",
          "text": "### What does this PR do? Wrap `TestKeepTryingLockingIfPermissionDenied`, `TestContextCancellation` and `TestHandleMultipleConcurrentWrites` in `synctest` \"bubbles\" by extracting their body into `sync<same name>` functions while dropping `t.Parallel()` (disallowed inside a bubble). Drop remaining `t.Parallel()` from the file's other 2 tests too (Bazel schedules this whole test binary as one action regardless of it). Also switch every `context.Background()` in the file to `t.Context()` for good measure (test-bound, canceled right before running Cleanup functions). ### Motivation `TestKeepTryingLockingIfPermissionDenied` races a 500ms retry loop against its own 2s context timeout using real time, so a scheduling stall near either boundary can flip a would-be success into a failure. It failed exactly that way in a local `bazel test` run on Linux: ``` --- FAIL: TestKeepTryingLockingIfPermissionDenied (3.00s) concurrent_write_test.go:212: Error Trace: pkg/util/filesystem/concurrent_write_test.go:212 Error: Received unexpected error: unable to read the artifact or acquire the lock in the given time open /tmp/TestKeepTryingLockingIfPermissionDenied252193597/001/test_artifact.lock: permission denied Test: TestKeepTryingLockingIfPermissionDenied concurrent_write_test.go:216: Error Trace: pkg/util/filesystem/concurrent_write_test.go:216 Error: Expected error with \"file does not exist\" in chain but got nil. Test: TestKeepTryingLockingIfPermissionDenied Messages: lock file should not exist after successful creation and concurrent reads ``` The flakiness may manifest itself in a slightly different way, like for instance in [a CI job](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1928209794#L476) on Windows where 2 `t.Parallel()` siblings in the same batch also ran multiple real seconds longer than their own logic requires, showing the whole binary stalled right when the retry loop needed to recheck the lock: ``` === NAME TestKeepTryingLockingIfPermissionDenied concurrent_write_test.go:212: Error Trace: pkg/util/filesystem/concurrent_write_test.go:212 Error: Received unexpected error: unable to read the artifact or acquire the lock in the given time Test: TestKeepTryingLockingIfPermissionDenied concurrent_write_test.go:216: Error Trace: pkg/util/filesystem/concurrent_write_test.go:216 Error: Expected error with \"file does not exist\" in chain but got nil. Test: TestKeepTryingLockingIfPermissionDenied Messages: lock file should not exist after successful creation and concurrent reads --- FAIL: TestKeepTryingLockingIfPermissionDenied (2.11s) ``` `TestContextCancellation` and `TestHandleMultipleConcurrentWrites` don't share that specific failure mode, but they do pay their timers' full real duration on every run regardless of load. ### Describe how you validated your changes Isolated timing before/after: - `TestKeepTryingLockingIfPermissionDenied`: 1.05s to 0.02s, - `TestContextCancellation`: 0.10s to 0.00s, - `TestHandleMultipleConcurrentWrites`: 0.50s to 0.05s. All tests pass 30/30 under `--config=gorace`, and the package passes 60/60 repeated runs under heavy artificial CPU oversubscription. ### Additional Notes Dropping `t.Parallel()` doesn't cost anything net: - ~1.65s before this change, - ~0.07s after. This is because virtualizing sleeps removes far more real time than serializing 5 tests loses.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54830",
          "createdAt": "2026-08-13T12:00:51Z",
          "updatedAt": "2026-08-13T12:59:40Z",
          "timestamp": "2026-08-13T12:59:40Z",
          "metrics": {
            "reactions": 2,
            "comments": 6
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "team/agent-runtimes",
            "internal"
          ],
          "author": "rdesgroppes",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:2f6b1667bf53bbdbb4b2",
        "signalId": "github:DataDog/datadog-agent:pull_request:54827",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54827",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] Improve PAR error when an aciton is not allowed",
          "text": "## Description When a Private Action Runner (PAR) rejects an action because it's not in the runner's allowlist, the error message is unhelpful: action <fqn> is not in the allow list. Users have no guidance on how to resolve it.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54827",
          "createdAt": "2026-08-13T11:50:30Z",
          "updatedAt": "2026-08-13T12:58:51Z",
          "timestamp": "2026-08-13T12:58:51Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "short review",
            "team/action-platform",
            "internal"
          ],
          "author": "merchristK",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:5c9ccb8679f1099d0fea",
        "signalId": "github:DataDog/datadog-agent:pull_request:54817",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54817",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[EBPF] Disable parallel GPU collection by default",
          "text": "### What does this PR do? Disables parallel NVML collector collection by default in the GPU check. Operators can opt in with `gpu.parallel_collectors: true`. ### Motivation #incident-59170 ### Describe how you validated your changes Ran manually, checked that the parallel collectors being disabled removes the issue. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54817",
          "createdAt": "2026-08-13T10:20:00Z",
          "updatedAt": "2026-08-13T12:46:29Z",
          "timestamp": "2026-08-13T12:46:29Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "team/ebpf-platform",
            "qa/done",
            "short review",
            "internal",
            "team/gpu-monitoring-agent",
            "team/fleet-automation",
            "backport/7.82.x",
            "backport/7.83.x"
          ],
          "author": "gjulianm",
          "state": "open",
          "assignees": [
            "gjulianm"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:9155e3bfa0bbdc8e1f8a",
        "signalId": "github:DataDog/datadog-agent:pull_request:54824",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54824",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(notableevents): add macOS shutdown-cause notable event",
          "text": "Reads the IOPMUBootFaultInfo IORegistry property to classify the previous boot's PMU fault tokens (thermal, power, crash, watchdog, hardware) and emit a notable event, independent of DiagnosticReports crash collection. Dedup is boot-scoped via a new ShutdownCause bookmark field, keeping the existing bookmark schema version at 1. <!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54824",
          "createdAt": "2026-08-13T11:42:34Z",
          "updatedAt": "2026-08-13T12:44:21Z",
          "timestamp": "2026-08-13T12:44:21Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "long review",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "PedroCordeiroDataDog",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:7429f3e8b4bf847591b3",
        "signalId": "github:DataDog/datadog-agent:pull_request:54812",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54812",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Move tools/tar_checksums to bazel/tools",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Moves tar_checksums code to under `bazel/tools`, such that it falls under the agent-build team ownership. ### Motivation I made a PR that touched these files and no review from agent-build was requested, even though this is under our scope. This is also consistent with the contents of both folders (`bazel/tools` vs `tools`) as things stand today. ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54812",
          "createdAt": "2026-08-13T09:32:34Z",
          "updatedAt": "2026-08-13T12:43:48Z",
          "timestamp": "2026-08-13T12:43:48Z",
          "metrics": {
            "reactions": 2,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/agent-build",
            "internal"
          ],
          "author": "alopezz",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:721a98b4774954d0d064",
        "signalId": "github:DataDog/datadog-agent:pull_request:54762",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54762",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Improve support for Windows across Invoke tasks",
          "text": "### Motivation https://datadoghq.atlassian.net/browse/ACIX-1826 Address https://github.com/DataDog/datadog-agent/pull/53344#discussion_r3554689696",
          "url": "https://github.com/DataDog/datadog-agent/pull/54762",
          "createdAt": "2026-08-12T08:07:55Z",
          "updatedAt": "2026-08-13T12:32:46Z",
          "timestamp": "2026-08-13T12:32:46Z",
          "metrics": {
            "reactions": 2,
            "comments": 11
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/agent-devx",
            "internal"
          ],
          "author": "ofek",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:f76f1eae6cb7c96ced4a",
        "signalId": "github:DataDog/datadog-agent:pull_request:54548",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54548",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[DSEC-232] Destroy scanner and free cache once rust check finish",
          "text": "### What does this PR do? Bumps `dd-sensitive-data-scanner` to `0.1.0-20260807-dcc653f6f465` and, in the `datasecurity` rust check, drops the scanner and clears dd-sds' global regex caches once scanning finishes. ### Motivation Keep the check's idle memory footprint near zero between runs by releasing the scanner and its cached compiled regexes as soon as they're no longer needed. ### Describe how you validated your changes `cargo build -p datasecurity --locked` and `cargo test -p datasecurity` pass. ### Additional Notes Caches are cleared even when a sub-task fails, and only after the scanner is dropped (dd-sds reclaims only unreferenced compiled regexes).",
          "url": "https://github.com/DataDog/datadog-agent/pull/54548",
          "createdAt": "2026-08-07T03:35:45Z",
          "updatedAt": "2026-08-13T12:26:18Z",
          "timestamp": "2026-08-13T12:26:18Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "medium review",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "aimenebelfodil",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:dc998563a59db0a8461c",
        "signalId": "github:DataDog/datadog-agent:pull_request:54768",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54768",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Remove visual_studio.bzl",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? This PR fully eliminates usage of `visual_studio.bzl` that was just pinning version of a local MSVC installation. #54718 introduced a fully hermetic MSVC toolchain, as well as MSBuild tool and migrated cpython build process to it. This PR handles datadog-interop.dll, the last consumer of `msbuild` that was relying on `visual_studio` repository rule. - Remove `visual_studio.bzl` - Introduce `pkg/inventory/software/main_windows_test.go` to properly wire interop DLL into tests under Bazel. - Remove `-AsArray` from `pkg/inventory/software/integration_windows_test.go` as it is only supported in PowerShell 6+, for instance, my DD issued Windows laptop has 5.1, so this simply doesn't `work. - Enable `software_test` in CI. From now on it will be executed under `//...`",
          "url": "https://github.com/DataDog/datadog-agent/pull/54768",
          "createdAt": "2026-08-12T09:55:44Z",
          "updatedAt": "2026-08-13T12:21:53Z",
          "timestamp": "2026-08-13T12:21:53Z",
          "metrics": {
            "reactions": 2,
            "comments": 7
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/agent-devx",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "JSGette",
          "state": "closed",
          "assignees": [
            "JSGette"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:a5c9e8f12274031a6a0f",
        "signalId": "github:DataDog/datadog-agent:pull_request:54790",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54790",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "ci: default to GIT_DEPTH=1, full clone for jobs needing git history",
          "text": "### What does this PR do? Sets a repo-wide `GIT_DEPTH: 1` default in `.gitlab-ci.yml` to speed up job checkouts, and adds `GIT_DEPTH: 0` overrides on the jobs whose scripts (or the invoke tasks they call) run history-dependent git operations: - `.gitlab/build/source_test/golang_deps_diff.yml` (`golang_deps_diff` — `git merge-base` via `go-deps.diff`) - `.gitlab/test/e2e/e2e.yml` (`.new_e2e_template` — `git merge-base` for `--impacted` test selection) - `.gitlab/.pre/ci_configuration.yml` (`test_gitlab_compare_to`, `compute_gitlab_ci_config`, `lint_github_actions_shellcheck` — all use `git merge-base`) - `.gitlab/build/binary_build/fakeintake.yml` (`fakeintake_check_version_bump` — `git merge-base` + reading a file at the merge-base commit) - `.gitlab/deploy/internal_kubernetes_deploy/internal_kubernetes_deploy.yml` (`notify-slack` — `git log` over a commit range for the changelog) - `.gitlab/build/lint/technical_linters.yml` (`lint_releasenotes_rst` — `git merge-base`) - `.gitlab/.pre/setup/setup.yml` (`setup_agent_version` — `git describe --tags`, needs full history to find the nearest tag) Jobs that already had an explicit `GIT_DEPTH`/`GIT_STRATEGY` override (`regression_detector.yml`, `static_quality_gate.yml`, `files_inventory_check.yml`, the Windows bazel runner) were left untouched. The Windows `GIT_STRATEGY: \"clone\"` templates in `deploy/conditions.yml` / `agent7.yml` are unrelated to git history (they work around CIEXE-1152 for cancelled jobs) and don't need `GIT_DEPTH: 0`. ### Motivation Shallow clones reduce checkout time/bandwidth across the pipeline, which runs on every commit/PR. ### Describe how you validated your changes - Validated YAML syntax of all changed files. - Manually traced every git operation (`git merge-base`, `git log` ranges, `git describe --tags`) reachable from CI jobs, including through the invoke tasks they call (`tasks/libs/common/git.py`, `tasks/gotest.py`, `tasks/libs/releasing/version.py`, etc.) to confirm which jobs need full history. - Ran the `gitlab-configuration` pre-push linter (`dda inv linter.full-gitlab-ci -t main --pre-push-linters --fail-fast`) locally — passed with pre-existing warnings unrelated to this change. ### Additional Notes **Known risk, intentionally not addressed here:** the Linux/macOS/Windows unit-test jobs use `--only-impacted-packages` on essentially every dev-branch pipeline (via `FAST_TESTS=true`), which calls `git merge-base` through `tasks/gotest.py:get_impacted_packages` with **no error handling**. Under `GIT_DEPTH=1`, if the merge-base predates the 1-commit shallow window, this would hard-fail the test job rather than gracefully falling back to running all tests. This wasn't addressed in this PR to avoid setting `GIT_DEPTH: 0` on the largest and most CI-time-costly category of jobs, which would defeat much of the purpose of this change. Options going forward: harden the fallback in `get_impacted_packages` (deepen fetch or fall back to \"run all tests\" on merge-base failure), or scope `GIT_DEPTH: 0` to those jobs if the risk materializes.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54790",
          "createdAt": "2026-08-12T17:04:33Z",
          "updatedAt": "2026-08-13T12:21:02Z",
          "timestamp": "2026-08-13T12:21:02Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "team/agent-delivery",
            "medium review",
            "team/container-integrations",
            "team/agent-devx",
            "internal"
          ],
          "author": "KevinFairise2",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:093cece9ba677ab367b9",
        "signalId": "github:DataDog/datadog-agent:pull_request:54825",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54825",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix(flare): mark TestWindowsFlareSuite/TestFlareDefaultFiles as flaky",
          "text": "### What does this PR do? Mutes `test/new-e2e/tests/agent-subcommands.TestWindowsFlareSuite/TestFlareDefaultFiles` in `flakes.yaml`. ### Motivation This test has been reported failing intermittently in CI, tracked in [FLREM-146](https://datadoghq.atlassian.net/browse/FLREM-146). `TestWindowsFlareSuite` is a testify suite with other subtests that were never reported as flaky, so the entry is scoped to the exact failing subtest (`TestFlareDefaultFiles`) rather than muting the whole suite — same approach as #54759 for the sibling Linux/Windows flare suites. Muting it here unblocks other PRs from spurious CI failures while the underlying flakiness is investigated under that ticket. ### Describe how you validated your changes Validated `flakes.yaml` parses correctly and follows the existing file's format/conventions. ### Additional Notes [FLREM-146]: https://datadoghq.atlassian.net/browse/FLREM-146?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54825",
          "createdAt": "2026-08-13T11:45:46Z",
          "updatedAt": "2026-08-13T12:20:03Z",
          "timestamp": "2026-08-13T12:20:03Z",
          "metrics": {
            "reactions": 2,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "short review",
            "internal"
          ],
          "author": "louis-cqrl",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:10c2b1c7d57587ad0594",
        "signalId": "github:DataDog/datadog-agent:pull_request:54785",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54785",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add telemetry to dogstatsd http server",
          "text": "### What does this PR do? Add telemetry to dogstatsd http server ### Motivation Track usage and performance of the new component ### Describe how you validated your changes Unit tests. Run agent with dogstatsd http enabled and metric filter configured. Check agent telemetry to include expected metrics. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54785",
          "createdAt": "2026-08-12T14:39:56Z",
          "updatedAt": "2026-08-13T12:16:56Z",
          "timestamp": "2026-08-13T12:16:56Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "medium review",
            "team/agent-metric-pipelines",
            "team/agent-build",
            "internal"
          ],
          "author": "vickenty",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:7bc0d98bdb71ea48f0ca",
        "signalId": "github:DataDog/datadog-agent:pull_request:54748",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54748",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Read embedded Python version from Bazel in the python-version task",
          "text": "### What does this PR do? Migrates the `python-version` invoke task (`tasks/python_version.py`) to treat the Bazel module file `deps/cpython/cpython.MODULE.bazel` as the single source of truth for the embedded Python version: - `_get_current_python_version()` now reads `PYTHON_VERSION` from the Bazel file instead of `default_version` in `omnibus/config/software/python3.rb`. - Drops `_prepare_omnibus_update()` (and its call in `update()`), so the task no longer rewrites `default_version` on a bump. The Bazel file already carries both the version and the source-tarball `sha256`, and already drives the build. - Updates `tasks/unit_tests/python_version_tests.py` accordingly (Bazel-based fixtures for the read path; removes the now-obsolete omnibus-write test). ### Motivation PR #54744 removes the unused `default_version`/`relative_path` fields from `omnibus/config/software/python3.rb` (Bazel drives the CPython build now). As Codex flagged there, removing `default_version` would break the documented Python bump workflow, because `_get_current_python_version()` / `_prepare_omnibus_update()` still scan `python3.rb` for that marker and raise if it is absent. This change decouples the task from the omnibus marker so the bump workflow keeps working regardless of the order in which this PR and #54744 merge. It also aligns with the `tasks/AGENTS.md` \"single source of truth\" idiom. ### Describe how you validated your changes - `dda inv invoke-unit-tests.run` fixtures updated; ran `tasks/unit_tests/python_version_tests.py` (15 tests) — all pass. - Live check: `_get_current_python_version()` returns `3.13.14` on `main`, read from the Bazel file. - `ruff check` and `ruff format --check` clean on both changed files. ### Additional Notes Follows up on the discussion in #54744. No release note: this is developer tooling (invoke task) and is not shipped with the Agent.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54748",
          "createdAt": "2026-08-11T20:19:47Z",
          "updatedAt": "2026-08-13T12:12:22Z",
          "timestamp": "2026-08-13T12:12:22Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/agent-integrations",
            "team/agent-devx",
            "internal"
          ],
          "author": "Kyle-Neale",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:cfcbe0b46ca3caa7a164",
        "signalId": "github:DataDog/datadog-agent:pull_request:54794",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54794",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix(data plane): run preflight mode for entire SMP experiment duration",
          "text": "### What does this PR do? This PR adds the ability to _increase_ the duration of preflight mode for ADP. ### Motivation Since preflight mode now influences SMP experiments, we see the RSS for quality gate experiments increased even though ADP only runs for 90 seconds. While we need to adjust those QG limits no matter what, we also want to make ADP run for the _entire_ duration so that we avoid increasing the limits and then potentially letting other changes to the Agent effectively \"hide\" behind the temporary ADP usage. ### Describe how you validated your changes - New and existing unit tests. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54794",
          "createdAt": "2026-08-12T18:32:05Z",
          "updatedAt": "2026-08-13T12:11:55Z",
          "timestamp": "2026-08-13T12:11:55Z",
          "metrics": {
            "reactions": 2,
            "comments": 6
          },
          "labels": [
            "team/agent-security",
            "long review",
            "qa/skip-qa",
            "team/agent-devx",
            "team/action-platform",
            "internal",
            "team/fleet-remediation",
            "team/fleet-automation",
            "team/agent-data-plane"
          ],
          "author": "tobz",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:2590bfc3711cbd2ae972",
        "signalId": "github:DataDog/datadog-agent:pull_request:54759",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54759",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix(flare): mark newly-failing flare tests as flaky",
          "text": "### What does this PR do? Mutes four flare-related tests in `flakes.yaml` that have started failing intermittently in CI. ### Motivation The following tests have been reported failing via CI monitoring, with tracking tickets: - `test/new-e2e/tests/agent-subcommands.TestLinuxFlareSuite/TestFlareDefaultFiles` — [FLREM-153](https://datadoghq.atlassian.net/browse/FLREM-153) - `test/new-e2e/tests/agent-subcommands.TestWindowsDiagnoseSuite/TestDiagnoseOtherCmdPort` — [FLREM-154](https://datadoghq.atlassian.net/browse/FLREM-154) - `comp/core/flare/helpers.TestSave` — [FLREM-148](https://datadoghq.atlassian.net/browse/FLREM-148) - `comp/core/flare/helpers.TestNewFlareBuilder` — [FLREM-155](https://datadoghq.atlassian.net/browse/FLREM-155) `TestLinuxFlareSuite` and `TestWindowsDiagnoseSuite` are testify suites with other subtests (`TestzzzFlareWithAllConfiguration`, `TestDiagnoseInclude`, `TestDiagnoseExclude`) that were never reported as flaky, so the entries are scoped to only the specific subtest confirmed failing in each linked Jira ticket, rather than muting the whole suite. Muting them here unblocks other PRs from spurious CI failures while the underlying flakiness is investigated under those tickets. ### Describe how you validated your changes Validated `flakes.yaml` parses correctly and follows the existing file's format/conventions. Confirmed via `tasks/testwasher.py`/`tasks/libs/testing/flakes.py` (and an empirical run of `consolidate_flaky_failures`) that muting a parent suite name would have also silenced its other subtests, which is why the two suite tests are scoped to their exact failing subtest paths instead. ### Additional Notes [FLREM-153]: https://datadoghq.atlassian.net/browse/FLREM-153?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [FLREM-154]: https://datadoghq.atlassian.net/browse/FLREM-154?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [FLREM-148]: https://datadoghq.atlassian.net/browse/FLREM-148?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [FLREM-155]: https://datadoghq.atlassian.net/browse/FLREM-155?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54759",
          "createdAt": "2026-08-12T06:48:59Z",
          "updatedAt": "2026-08-13T12:07:35Z",
          "timestamp": "2026-08-13T12:07:35Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "medium review",
            "internal"
          ],
          "author": "louis-cqrl",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:556a0de26649b300803f",
        "signalId": "github:DataDog/datadog-agent:pull_request:54767",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54767",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "aix: populate datadog.yaml from env vars in the config script",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Seeds `datadog.yaml` from `DD_API_KEY`/`DD_SITE`/`DD_HOSTNAME`/`DD_TAGS`/`DD_ENV`/`DD_INFRASTRUCTURE_MODE`/proxy env vars on first install, mirroring the Linux install script. ### Motivation installp has no mechanism to pass parameters at install time, so this is the only way to configure the agent unattended on AIX. ### Describe how you validated your changes Ran all creation/skip/`DD_INSTALL_ONLY` scenarios in a sandbox on a real AIX 7.3 host and confirmed the resulting YAML and file permissions. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54767",
          "createdAt": "2026-08-12T09:07:16Z",
          "updatedAt": "2026-08-13T12:03:56Z",
          "timestamp": "2026-08-13T12:03:56Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "short review",
            "team/agent-build",
            "internal"
          ],
          "author": "pgimalac",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:a866bc646d20590ade13",
        "signalId": "github:DataDog/datadog-agent:pull_request:54813",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54813",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "chore: Update devcontainer prebuilt image reference",
          "text": "Prebuilt devcontainer image reference updated to reflect latest config. This automation in driven by the [workspaces-image-builder service](https://mosaic.us1.ddbuild.io/services/workspaces-imagebuilder/details) and the [github-devcontainer-prebuild service](https://mosaic.us1.ddbuild.io/services/github-devcontainer-prebuild/details). For workspaces on-call: If there are any unexpected behaviors with this automation, see the [troubleshooting runbook](https://datadoghq.atlassian.net/wiki/spaces/DEVX/pages/4880237711/Troubleshooting+Devcontainer+Pre-Builds).",
          "url": "https://github.com/DataDog/datadog-agent/pull/54813",
          "createdAt": "2026-08-13T09:32:49Z",
          "updatedAt": "2026-08-13T12:00:52Z",
          "timestamp": "2026-08-13T12:00:52Z",
          "metrics": {
            "reactions": 2,
            "comments": 1
          },
          "labels": [
            "campaigner-automated-change"
          ],
          "author": "gh-worker-campaigns-3e9aa4[bot]",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:dd3ee0933255a6b438f7",
        "signalId": "github:DataDog/datadog-agent:pull_request:51861",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:51861",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "packaging/aix: use rmssys only in unconfig, drop odmdelete",
          "text": "### What does this PR do? Remove the `odmdelete` calls from the AIX `unconfig` lifecycle script, keeping only `rmssys`. ### Motivation `rmssys` atomically removes a subsystem from both the ODM file and the live srcmstr daemon. Calling `odmdelete` before actually makes `rmssys` fail silently, and leave a stale entry in `srcmstr`. The `postinst` script already documents this: \"Always use rmssys, never odmdelete.\" ### Describe how you validated your changes Verified on the AIX 7.3 VM. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/51861",
          "createdAt": "2026-06-05T13:06:45Z",
          "updatedAt": "2026-08-13T11:59:03Z",
          "timestamp": "2026-08-13T11:59:03Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "short review",
            "team/agent-runtimes",
            "team/agent-build",
            "internal"
          ],
          "author": "pgimalac",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:3c79f412ef967560e189",
        "signalId": "github:DataDog/datadog-agent:pull_request:54755",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54755",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add Observer pipeline telemetry",
          "text": "### What does this PR do? Reshapes Observer telemetry around four experiment questions. #### Ingress and admission - `observer.observations.accepted{kind,source}` counts logs and metrics successfully admitted to the Observer. - `observer.observations.dropped{kind,source}` counts observations rejected because the Observer channel is full. - `observer.logs.accepted_bytes{source}` counts admitted log-content bytes. - `observer.logs.input_rate_limiter.dropped{source,priority}` identifies logs rejected by the Observer ingress rate limiter. - `logs_adaptive_sampler.outcomes{severity,outcome}` counts eligible adaptive-sampling decisions under an applied AAD severity profile. In detection-only mode, `outcome:dropped` means the log would have been dropped. #### Retained state - `observer.log_pattern_extractor.pattern_count` is now a gauge representing all active extractor patterns, including patterns below the metric-emission threshold. - Existing `observer.series.count` and storage capacity/eviction telemetry are retained. #### Detection and output - `observer.detections.detector_emissions{detector,severity}` counts deduplicated detector output before scoring, correlation, and reporting. Severity uses `xlow|low|medium|high|xhigh`. - `observer.scorer.severity{scorer}` reports the current scorer state as `0=low`, `1=medium`, or `2=high`. - Existing `observer.scorer.ewma` and `observer.reports.emitted` are retained. #### Pipeline cost and health - `observer.log_extraction.processing_duration{extractor}` measures only each extractor's `ProcessLog` call in seconds, excluding output handling and storage. The two default-enabled extractors are `log_metrics_extractor` and `log_pattern_extractor`. - Existing in-flight, scheduler, storage, and detector-timing telemetry are retained. - The experiment will use existing Agent and Kubernetes telemetry for CPU and memory rather than introducing duplicate Observer metrics. ### Motivation We want to be able to monitor key parts of the observer pipeline. doc: [Observer Telemetry](https://datadoghq.atlassian.net/wiki/spaces/agent/pages/7070942507/Observer+Telemetry) ### Describe how you validated your changes - Unit coverage for metric types, labels, admission boundaries, extractor timing, pattern state, detector emissions, scorer severity, and adaptive-sampler outcomes. - Kind smoke test using the PR Agent image, verifying emitted metrics and labels. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54755",
          "createdAt": "2026-08-11T21:17:39Z",
          "updatedAt": "2026-08-13T11:58:24Z",
          "timestamp": "2026-08-13T11:58:24Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "long review",
            "team/agent-log-pipelines",
            "team/agent-build",
            "internal"
          ],
          "author": "Eokye",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:3046fa17d08348e81819",
        "signalId": "github:DataDog/datadog-agent:pull_request:54820",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54820",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Pedro.cordeiro/macos thermal notable event",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54820",
          "createdAt": "2026-08-13T10:46:00Z",
          "updatedAt": "2026-08-13T11:47:55Z",
          "timestamp": "2026-08-13T11:47:55Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "medium review",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "PedroCordeiroDataDog",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:45aabd837e9535c75d43",
        "signalId": "github:DataDog/datadog-agent:pull_request:54781",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54781",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP][e2e][incident-59050] restore fake runner keys injection for PAR e2e test",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? \"revert\" of https://github.com/DataDog/datadog-agent/pull/54709 Try to reintroduce the fake intake usage for RC keys instead of `DD_INTERNAL_PAR_SKIP_TASK_VERIFICATION` The extra latency (which is a separate problem to solve with RC's help) seems to only appear if the PAR starts AFTER the core agent. By restarting the core agent we ### Motivation Trying to get rid of DD_INTERNAL_PAR_SKIP_TASK_VERIFICATION ### Describe how you validated your changes CI Ran, need to see if it does not become [flaky again](https://app.datadoghq.com/ci/ci-cd/explorer?query=ci_level%3Ajob%20%40ci.pipeline.name%3ADataDog%2Fdatadog-agent%20%40git.branch%3Amain%20%40ci.job.name%3A%22new-e2e-privateactionrunner%22%20%40ci.status%3Aerror&agg_m=%40ci.job.name&agg_m_source=base&agg_t=cardinality&analyticsOptions=%5B%22line%22%2C%22dog_classic%22%2Cnull%2Cnull%2C%22value%22%5D&ci_cd_explorer_tab=pipelines&cipipeline_explorer_sort=time%2Cdesc&colorByAttr=meta%5B%27ci.stage.name%27%5D&cols=%40git.branch%2C%40ci.status%2Ctimestamp%2C%40ci.pipeline.name%2C%40ci.stage.name%2C%40ci.job.name%2C%40duration%2C%40ci.pipeline.id%2C%40git.repository.name&currentTab=trace&fromUser=false&graphType=flamegraph&index=cipipeline&mode=sliding&refresh_mode=sliding&sort=time&spanViewType=metadata&step=86400000&tab=overview&viz=stream&start=1781426607918&end=1786610607918&paused=false) ### Additional Notes See #incident-59050",
          "url": "https://github.com/DataDog/datadog-agent/pull/54781",
          "createdAt": "2026-08-12T14:15:10Z",
          "updatedAt": "2026-08-13T11:40:13Z",
          "timestamp": "2026-08-13T11:40:13Z",
          "metrics": {
            "reactions": 2,
            "comments": 1
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "team/action-platform",
            "internal"
          ],
          "author": "dd-gplassard",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:53919193d463dbbdb2fb",
        "signalId": "github:DataDog/datadog-agent:pull_request:54157",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54157",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[WP] ICMPv4 packet flow classification",
          "text": "### What does this PR do? This PR adds proper IPv4 ICMP flow tracking so CWS can attribute outbound ICMP packets to the correct process in the TC classifier at snapshot, enabling cgroup-scoped network_filter actions (e.g. dropping ping traffic). Problem: The flow_pid map keys flows by (netns, source address, L4 identifier, protocol). For TCP/UDP, the L4 identifier is the source port. ICMP has no ports — only an echo identifier in the header — and security_sk_classify_flow runs too early for ICMP sockets: the flowi metadata is incomplete and the existing port-matching logic does not apply. Solution: Hook ip_finish_output, once the IPv4 packet (IP + ICMP headers) is built, and parse the sk_buff to extract: the source address (iph.saddr) the echo identifier (icmph.un.echo.id), stored in the existing port field of pid_route_t ICMP flow registration is skipped in security_sk_classify_flow and handled exclusively from this hook. On the TC egress path, resolve_pid_from_flow_pid is updated to look up ICMP flows using icmp.id instead of tcp_udp.sport. Refactor: Flow registration logic is extracted into register_flow_pid_classify_entry, shared by both hooks. Test: TestNetworkFilterICMPPingIsolation starts a long-running ping in a container, loads a cgroup-scoped network_filter rule (icmp and dst host 1.1.1.1), and verifies packet loss once the agent attaches the filter. ### Motivation Cgroup network isolation relies on resolving the emitting process (and its cgroup) from packets observed on the TC egress path. Without a correct flow_pid entry for ICMP, the classifier cannot attribute ping packets to the container process if the agent miss the create of the socket. This caused pings not to be dropped when the ping process started before the agent, even if an isolation was applied on this process / cgroup. TCP/UDP flows were already registered from security_sk_classify_flow, but that hook fires before the kernel has assembled the final ICMP with the address (chosen at runtime for ICMP) packet and does not expose a usable port for the port-matching checks. By moving registration to ip_finish_output and keying on the ICMP echo identifier, we align ICMP with the same flow_pid → PID → cgroup resolution path used for TCP/UDP.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54157",
          "createdAt": "2026-07-28T09:37:01Z",
          "updatedAt": "2026-08-13T11:33:15Z",
          "timestamp": "2026-08-13T11:33:15Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/agent-security",
            "qa/done",
            "medium review",
            "internal"
          ],
          "author": "theop-dd",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:e9a95691dbcef07de1d2",
        "signalId": "github:DataDog/datadog-agent:pull_request:53568",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53568",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[procmgr] Show profile and user in list and describe",
          "text": "### What does this PR do? Expose spawn identity in the process manager API and `dd-procmgr` CLI: - `list`: adds `profile` and `user` columns (table + JSON) - `describe`: adds `Profile`, `User`, and `Runtime User` (only when the process is running and lookup succeeds) Proto changes: - `Process`: `profile`, `user` - `ProcessDetail`: `profile`, `user`, `runtime_user` Implementation notes: - `profile` is derived from the process name (`agent` / `privileged`) - `user` is the intended / last-spawn account, stored on `ManagedProcess` and refreshed on spawn - `runtime_user` is resolved from the OS at describe time (Windows token owner / Linux `/proc` + `getpwuid`) - Windows display formatting is centralized in `AccountName` ### Motivation After Windows spawn profiles land, operators need a simple way to see how each managed child is spawned without reading code or registry state. Showing `profile` and `user` in `list`/`describe` makes SCM migration behavior visible (e.g. process-agent as `privileged` / `NT AUTHORITY\\SYSTEM` vs other children as `agent` / installer user). `runtime_user` in `describe` helps debug cases where the running PID differs from the intended spawn account. ### Describe how you validated your changes - `cargo test --lib --bin dd-procmgr` (procmgr Rust unit tests) - `dda inv test --targets=./pkg/procmgr/coat/...` - Updated procmgr CLI e2e tests for `profile` / `user` / `runtime_user` output ### Additional Notes - `user` reflects spawn policy (intended or last used), not a live registry re-read on every query - `runtime_user` is omitted from `list` and from `describe` when PID is unset or lookup fails (debug log only) - No COAT/metrics changes in this PR",
          "url": "https://github.com/DataDog/datadog-agent/pull/53568",
          "createdAt": "2026-07-13T08:47:55Z",
          "updatedAt": "2026-08-13T11:32:24Z",
          "timestamp": "2026-08-13T11:32:24Z",
          "metrics": {
            "reactions": 1,
            "comments": 26
          },
          "labels": [
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-devx",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "jose-manuel-almaza",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:b929f32469732a788e7a",
        "signalId": "github:DataDog/datadog-agent:pull_request:54764",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54764",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix(autoscaling): stop informer in test fixture to fix TestPodAutoscalerLocalOwnerObjectsLimit flake",
          "text": "### What does this PR do? Removes the `informer.Start(stopCh)` call from `RunControllerSync` in the autoscaling controller test fixture (`pkg/clusteragent/autoscaling/controller_fake.go`). ### Motivation `TestPodAutoscalerLocalOwnerObjectsLimit` (and `TestPodAutoscalerRemoteOwnerObjectsLimit`) have been [flaking](https://app.datadoghq.com/ci/ci-cd/explorer?query=test_level%3Atest%20%40test.status%3Afail%20%40test.name%3ATestPodAutoscalerLocalOwnerObjectsLimit&agg_m=count&agg_m_source=base&agg_t=count&ci_cd_explorer_tab=tests&citest_explorer_sort=%40duration%2Cdesc&cols=%40test.status%2C%40test.name%2C%40test.suite%2C%40test.is_known_flaky%2C%40duration%2C%40test.service%2Cerror.type&currentTab=overview&eventStack=&fromUser=false&index=citest&refresh_mode=sliding&start=1785920759493&end=1786525559493&paused=false) on `tests_macos_gitlab_amd64` with two symptoms: 1. Assertion failure at `controller_test.go:681`: expected `default/dpa-2` at heap top, got `default/dpa-1` 2. Immediate panic: `mock: I don't know what to return because the method call was unexpected` for `GetPodsForOwner` **Root cause**: `RunControllerSync` called `informer.Start(stopCh)`, which spawns background goroutines that fire `AddFunc` for every object already in the indexer. These callbacks call `c.enqueue(obj)` → `Workqueue.Add(key)` concurrently with the test's own `Workqueue.Add(objectID)`. Since `process()` dequeues exactly one item, it could pick up a background-enqueued key (e.g. `dpa-0`) instead of the intended target (e.g. `dpa-2`). Consequences: - The intended object (`dpa-2`) is never synced → never upserted → never inserted into the heap - Heap state assertions fail (`dpa-1` is at top instead of `dpa-2`) - The wrong object (`dpa-0`) is processed, reaches `validateAutoscaler` (passes, since it was just inserted into the heap), then calls `GetPodsForOwner` for which no mock was set up → panic **Fix**: do not start the informer. The indexer is already pre-seeded via `GetIndexer().Add()` in `newController`, so the lister works correctly without the informer running. The `alwaysReady` synced gate bypasses the cache-sync check. No background goroutines → no concurrent enqueues → deterministic `process()` behavior. ### Describe how you validated your changes - Ran `TestPodAutoscalerLocalOwnerObjectsLimit` 5× with `-count=5`: all pass - Ran the full `./pkg/clusteragent/autoscaling/...` test suite: all green",
          "url": "https://github.com/DataDog/datadog-agent/pull/54764",
          "createdAt": "2026-08-12T08:42:39Z",
          "updatedAt": "2026-08-13T11:30:55Z",
          "timestamp": "2026-08-13T11:30:55Z",
          "metrics": {
            "reactions": 2,
            "comments": 8
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "internal"
          ],
          "author": "chouetz",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:7d8fe061d689a7048b27",
        "signalId": "github:DataDog/datadog-agent:pull_request:54818",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54818",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Fail bazel build on Windows if vault isn't found",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Builds are notoriously slow on Windows so it was requested by @DataDog/windows-products to fail the agent build in case we can't utilize the cache. One of the main reasons for that is absence of `vault` tool that is used to acquire an access token for our `buildbarn` cluster that serves as a remote cache backend. With this change we: - immediately fail the build if `vault` hasn't been found. Users can still opt-out and build without cache. - print a hint explaining how to properly install `vault`",
          "url": "https://github.com/DataDog/datadog-agent/pull/54818",
          "createdAt": "2026-08-13T10:26:41Z",
          "updatedAt": "2026-08-13T11:28:59Z",
          "timestamp": "2026-08-13T11:28:59Z",
          "metrics": {
            "reactions": 2,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "team/agent-build",
            "internal"
          ],
          "author": "JSGette",
          "state": "open",
          "assignees": [
            "JSGette"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:9ee606b55b5d015a3d05",
        "signalId": "github:DataDog/datadog-agent:pull_request:54816",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54816",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[Backport 7.83.x]  [EBPF] gpu: Skip unsupported vGPU max-clock queries",
          "text": "Backport e5a19fa15faff217145de62c45995fd1f2451ee1 from #54729. ___ <!-- dd-meta {\"pullId\":\"00000000-0000-0000-0000-000000000000\",\"source\":\"chat\",\"resourceId\":\"b6950850-80dc-4801-bc2f-895d5b466cca\",\"workflowId\":\"c63cfe10-11dd-4bbc-800e-23188cad9c50\",\"codeChangeId\":\"c63cfe10-11dd-4bbc-800e-23188cad9c50\",\"sourceType\":\"bits_ai_sre\"} --> ### What does this PR do? Bits AI SRE Investigation • [View in Bits AI SRE Investigation](https://app.datadoghq.com/bits-ai/investigations/54d64295-b38b-44f1-85fa-fb1948786cba) - Detect vGPU devices in the NVIDIA stateless max-clock handlers. - Cache each device's NVML virtualization mode in `safenvml.DeviceInfo` during device initialization, so max-clock collection does not query NVML repeatedly. - Return the repository's typed unsupported-API error so all four max-clock handlers are filtered during collector initialization. - Log an error when the virtualization-mode lookup fails during device initialization. - Add regression coverage that makes vGPU max-clock calls return `ERROR_UNKNOWN`, verifies the cached mode, and confirms max-clock calls are never invoked or reported as collection errors. ### Motivation NVIDIA vGPU devices such as the A10-24Q configuration in the zekrom cluster do not support NVML `GetMaxClockInfo`. The API returns `Unknown Error` rather than `ERROR_NOT_SUPPORTED`, so the stateless collector previously retried the calls on every collection cycle and generated recurring collection-error noise. This fix suppresses those unsupported calls while preserving max-clock metrics for physical GPUs, caches the virtualization capability query used to make that decision, and reports failures to determine the mode. ### Describe how you validated your changes - Formatted the modified Go file with `gofmt` and ran `git diff --check`. - Verified the vGPU regression test observes one virtualization-mode query during device initialization and zero max-clock queries. - The targeted Bazel test was previously attempted but could not start because the workspace could not download the required Bazel version. - The prescribed `dda` executable was unavailable in the workspace. ### Additional Notes The change is limited to the NVIDIA stateless collector, safenvml device metadata and logging, and regression coverage. --- PR by Bits - [View session in Datadog](https://app.datadoghq.com/code/b6950850-80dc-4801-bc2f-895d5b466cca) Comment @datadog to request changes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54816",
          "createdAt": "2026-08-13T10:18:43Z",
          "updatedAt": "2026-08-13T11:27:46Z",
          "timestamp": "2026-08-13T11:27:46Z",
          "metrics": {
            "reactions": 2,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "team/ebpf-platform",
            "qa/done",
            "backport",
            "bot",
            "short review",
            "Bits AI",
            "internal",
            "team/gpu-monitoring-agent"
          ],
          "author": "dd-octo-sts[bot]",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:8dda3c22cf5239f906fe",
        "signalId": "github:DataDog/datadog-agent:pull_request:54729",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54729",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[EBPF] gpu: Skip unsupported vGPU max-clock queries",
          "text": "<!-- dd-meta {\"pullId\":\"00000000-0000-0000-0000-000000000000\",\"source\":\"chat\",\"resourceId\":\"b6950850-80dc-4801-bc2f-895d5b466cca\",\"workflowId\":\"c63cfe10-11dd-4bbc-800e-23188cad9c50\",\"codeChangeId\":\"c63cfe10-11dd-4bbc-800e-23188cad9c50\",\"sourceType\":\"bits_ai_sre\"} --> ### What does this PR do? Bits AI SRE Investigation • [View in Bits AI SRE Investigation](https://app.datadoghq.com/bits-ai/investigations/54d64295-b38b-44f1-85fa-fb1948786cba) - Detect vGPU devices in the NVIDIA stateless max-clock handlers. - Cache each device's NVML virtualization mode in `safenvml.DeviceInfo` during device initialization, so max-clock collection does not query NVML repeatedly. - Return the repository's typed unsupported-API error so all four max-clock handlers are filtered during collector initialization. - Log an error when the virtualization-mode lookup fails during device initialization. - Add regression coverage that makes vGPU max-clock calls return `ERROR_UNKNOWN`, verifies the cached mode, and confirms max-clock calls are never invoked or reported as collection errors. ### Motivation NVIDIA vGPU devices such as the A10-24Q configuration in the zekrom cluster do not support NVML `GetMaxClockInfo`. The API returns `Unknown Error` rather than `ERROR_NOT_SUPPORTED`, so the stateless collector previously retried the calls on every collection cycle and generated recurring collection-error noise. This fix suppresses those unsupported calls while preserving max-clock metrics for physical GPUs, caches the virtualization capability query used to make that decision, and reports failures to determine the mode. ### Describe how you validated your changes - Formatted the modified Go file with `gofmt` and ran `git diff --check`. - Verified the vGPU regression test observes one virtualization-mode query during device initialization and zero max-clock queries. ### Additional Notes The change is limited to the NVIDIA stateless collector, safenvml device metadata and logging, and regression coverage. --- PR by Bits - [View session in Datadog](https://app.datadoghq.com/code/b6950850-80dc-4801-bc2f-895d5b466cca) Comment @datadog to request changes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54729",
          "createdAt": "2026-08-11T15:26:57Z",
          "updatedAt": "2026-08-13T11:26:55Z",
          "timestamp": "2026-08-13T11:26:55Z",
          "metrics": {
            "reactions": 3,
            "comments": 11
          },
          "labels": [
            "changelog/no-changelog",
            "team/ebpf-platform",
            "qa/done",
            "short review",
            "Bits AI",
            "internal",
            "team/gpu-monitoring-agent",
            "backport/7.83.x"
          ],
          "author": "gjulianm",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:a97b16f73ad057f1ec80",
        "signalId": "github:DataDog/datadog-agent:pull_request:54808",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54808",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Make dda tasks use bazel's Go sdk",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54808",
          "createdAt": "2026-08-13T08:32:14Z",
          "updatedAt": "2026-08-13T11:13:43Z",
          "timestamp": "2026-08-13T11:13:43Z",
          "metrics": {
            "reactions": 1,
            "comments": 1
          },
          "labels": [
            "qa/no-code-change",
            "medium review",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "JSGette",
          "state": "closed",
          "assignees": [
            "JSGette"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:553f301c4a186ee88f83",
        "signalId": "github:DataDog/datadog-agent:pull_request:54716",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54716",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[AAD-36] Use anomaly scorer by default",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? This uses anomaly scorer by default instead of time cluster which is now disabled by default. ### Motivation We want to enable the scorer by default since we rely on it for smart adaptive sampling feature so our current direction is towards detection change points instead of sending events when we have bad behaviors. ### Describe how you validated your changes Ran the benchmarks ### Additional Notes Scenario | Before F1 (time cluster) | After F1 (scorer) | Δ F1 -- | -- | -- | -- block-building-outage | 0.285714 | 0.634606 | +0.348892 cascading-payment-failure | 0.063224 | 0.000083 | -0.063141 cassandra-repair-degradation | 0.227017 | 0.000000 | -0.227017 dns-upstream-outage | 0.054111 | 0.297905 | +0.243794 kafka-partition-saturation | 0.177494 | 0.577355 | +0.399861 lock-contention | 0.618715 | 0.032148 | -0.586567 memcached-saturation | 0.000006 | 0.557888 | +0.557882 pool-saturation | 0.000259 | 0.814789 | +0.814530 redis-cascade-billing | ~0 | ~0 | ~0 redis-cpu-saturation | 0.615742 | 0.016948 | -0.598794 tiered-cache-header-corruption | 0.001845 | ~0 | -0.001845 **Average** | 0.185830 | 0.266520 | +0.080690 (+43.42%)",
          "url": "https://github.com/DataDog/datadog-agent/pull/54716",
          "createdAt": "2026-08-11T12:36:30Z",
          "updatedAt": "2026-08-13T11:07:06Z",
          "timestamp": "2026-08-13T11:07:06Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "medium review",
            "internal",
            "team/fleet-automation"
          ],
          "author": "CelianR",
          "state": "open",
          "assignees": [
            "CelianR"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:a6261d7d841ad175abeb",
        "signalId": "github:DataDog/datadog-agent:pull_request:54655",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54655",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add test2json and UTOF output to bazel-driven go tests",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Generates test2json output and UTOF output for Bazel-run tests. ### Motivation We want to switch over to using Bazel for running our unit tests, this helps us produce output that is closer to the existing jobs to reduce friction during the switch. ### Describe how you validated your changes ### Additional Notes This generates a bit of noise on the UTOF output because it treats the multiple runs of the same tests (with different tag sets) as retries, which get printed out. This will be dealt with separately.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54655",
          "createdAt": "2026-08-10T16:12:30Z",
          "updatedAt": "2026-08-13T10:59:47Z",
          "timestamp": "2026-08-13T10:59:47Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "ask-review",
            "team/agent-build",
            "internal"
          ],
          "author": "alopezz",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:1d934ee9a4ee93d37b9c",
        "signalId": "github:DataDog/datadog-agent:pull_request:54719",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54719",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[EBPF] Collect NVLink fields per port",
          "text": "### What does this PR do? Collects NVLink field values independently for each port. ### Motivation A field unsupported on one port should not suppress metrics from supported ports. ### Describe how you validated your changes `dda inv test --targets=./pkg/collector/corechecks/gpu/nvidia` ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54719",
          "createdAt": "2026-08-11T13:11:27Z",
          "updatedAt": "2026-08-13T10:56:30Z",
          "timestamp": "2026-08-13T10:56:30Z",
          "metrics": {
            "reactions": 0,
            "comments": 4
          },
          "labels": [
            "team/ebpf-platform",
            "medium review",
            "internal",
            "team/gpu-monitoring-agent"
          ],
          "author": "gjulianm",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:794dae938681d060c8ca",
        "signalId": "github:DataDog/datadog-agent:pull_request:54696",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54696",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[automated] Upgrade embedded Python patch version to 3.13.15",
          "text": "### What does this PR do? Upgrades the Agent's embedded Python interpreter from **3.13.14** to **3.13.15** (patch version update). ### Changes - Updated `omnibus/config/software/python3.rb` with new version and SHA256 - Updated `deps/cpython/cpython.MODULE.bazel` with new version and SHA256 - Updated `test/new-e2e/tests/agent-platform/common/agent_behaviour.go` with expected version - Created release note documenting the upgrade ### Motivation Keep embedded Python up-to-date with bug fixes and security patches. ### Verification SHA256 hash automatically fetched and verified against the official Python.org SBOM file. See the [official Python release page](https://www.python.org/downloads/release/python-31315/) for details. ### Describe how you validated your changes CI is considered enough to validate changes.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54696",
          "createdAt": "2026-08-11T04:30:20Z",
          "updatedAt": "2026-08-13T09:58:09Z",
          "timestamp": "2026-08-13T09:58:09Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "medium review",
            "team/agent-integrations",
            "ask-review",
            "team/agent-runtimes",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "dd-octo-sts[bot]",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:8a4ddc38708632dc60a6",
        "signalId": "github:DataDog/datadog-agent:pull_request:54567",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54567",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[datasecurity] add malloc trim",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54567",
          "createdAt": "2026-08-07T13:06:39Z",
          "updatedAt": "2026-08-13T09:57:38Z",
          "timestamp": "2026-08-13T09:57:38Z",
          "metrics": {
            "reactions": 0,
            "comments": 4
          },
          "labels": [],
          "author": "aimenebelfodil",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:57c69c15d6a17b30399b",
        "signalId": "github:DataDog/datadog-agent:pull_request:54811",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54811",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[AAD-15] Add scoped anomaly scorer telemetry",
          "text": "### What does this PR do? Adds bounded service/source-scoped anomaly scorers and telemetry to measure input coverage against successfully started file and container log tailers. The global scorer and adaptive-sampling behavior are unchanged; scoped scores are telemetry-only. ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54811",
          "createdAt": "2026-08-13T08:53:27Z",
          "updatedAt": "2026-08-13T09:57:21Z",
          "timestamp": "2026-08-13T09:57:21Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "long review",
            "team/container-integrations",
            "team/agent-log-pipelines",
            "team/agent-metric-pipelines",
            "team/agent-build",
            "internal",
            "team/fleet-automation"
          ],
          "author": "CelianR",
          "state": "open",
          "assignees": [
            "CelianR"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:c1868085413e6e216f79",
        "signalId": "github:DataDog/datadog-agent:pull_request:54778",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54778",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add design spec for e2ectl interactive dashboard",
          "text": "Documents the approved design for a cross-env dashboard and per-env action loop in e2ectl's interactive mode, plus the generalization needed to keep cmd/e2ectl provisioner/installer-agnostic (moving config-drift interpretation into the Installer interface). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com><!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54778",
          "createdAt": "2026-08-12T12:43:04Z",
          "updatedAt": "2026-08-13T08:58:43Z",
          "timestamp": "2026-08-13T08:58:43Z",
          "metrics": {
            "reactions": 1,
            "comments": 1
          },
          "labels": [
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "KevinFairise2",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:95e882b49fc25b5cda36",
        "signalId": "github:DataDog/datadog-agent:pull_request:54777",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54777",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "chore(devx): clean up and align CODEOWNERS",
          "text": "### What does this PR do? Cleans up `.github/CODEOWNERS`: - Removes two exact-duplicate rules (`/.agents/skills/create-runtime-setting/SKILL.md` and `/pkg/collector/`). - Adds ownership for files that had no matching CODEOWNERS rule: `/datadog-agent.map` (`@DataDog/agent-log-pipelines`), `/flakes.yaml` (`@DataDog/agent-devx`), `/k8s_versions.json` (`@DataDog/container-integrations`), `/rust/license-tool.toml`, and `/examples/` (both marked \"do not notify anyone\", consistent with neighboring LICENSE-style entries). - Aligns the owner columns within each blank-line-separated block for readability. The auto-generated `# BEGIN COMPONENTS` / `# END COMPONENTS` block (managed by `dda inv lint-components`) was left untouched, and the bottom-to-top match ordering of rules was preserved everywhere — no ownership semantics changed beyond the additions/removals above. ### Motivation `.github/CODEOWNERS` had accumulated duplicate rules and a handful of files with no owning team, plus inconsistent spacing between owner columns that made the file harder to scan and diff. ### Describe how you validated your changes - Verified every pattern in the file matches at least one path still present in the repo (no stale rules). - Verified every tracked file in the repo now matches at least one CODEOWNERS rule (0 unmatched, down from 14). - Diffed the file with all whitespace normalized to confirm the column-alignment pass didn't change any pattern or owner content.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54777",
          "createdAt": "2026-08-12T12:31:25Z",
          "updatedAt": "2026-08-13T08:36:06Z",
          "timestamp": "2026-08-13T08:36:06Z",
          "metrics": {
            "reactions": 2,
            "comments": 1
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "long review",
            "internal"
          ],
          "author": "chouetz",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:bb3750d277cd29a1292a",
        "signalId": "github:DataDog/datadog-agent:pull_request:54807",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54807",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Gitignore the .pi-subagents folder",
          "text": "## Summary - Add `.pi-subagents/` to `.gitignore` so this local tooling directory isn't tracked in the repo. ## Test plan - N/A (gitignore-only change)",
          "url": "https://github.com/DataDog/datadog-agent/pull/54807",
          "createdAt": "2026-08-13T08:15:49Z",
          "updatedAt": "2026-08-13T08:34:48Z",
          "timestamp": "2026-08-13T08:34:48Z",
          "metrics": {
            "reactions": 2,
            "comments": 0
          },
          "labels": [
            "short review",
            "team/agent-devx",
            "internal"
          ],
          "author": "KevinFairise2",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:d84f05b9e704d8ff9c80",
        "signalId": "github:DataDog/datadog-agent:pull_request:54670",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54670",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] [PAR split deployment] shut down idle private action executor",
          "text": "### What does this PR do? Makes the new on-demand PAR executor terminate after an idle period. This should be triggered by `par-control` via `dd-procmgrd` so this is really a fallback for the daemon not working properly. Idle period is configured via `private_action_runner.idle_timeout_seconds` with a 60-second default. We use 3x that value as a backstop behind the control plane's normal explicit stop. This behavior is currently dormant in supported deployments: executor mode exists, but no deployment launches `privateactionrunner run-executor` until the later process-manager and packaging layers activate it. ### Motivation `par-control` and the PAR executor are siblings managed by `dd-procmgrd`. The control plane normally stops an idle executor, but if it crashes, exhausts its restart limit, or is stopped independently, nothing else reclaims the executor. The executor must therefore own a self-termination backstop. ### Describe how you validated your changes On the Linux development VM: - `bazel test //pkg/privateactionrunner/executor:executor_test` - `bazel test //comp/privateactionrunner/impl:impl_test` - `bazel test //cmd/privateactionrunner/subcommands/runexecutor:runexecutor_test` The executor test target also passed 10 consecutive runs after the idle tests were converted to use a mock clock. ### Additional Notes The watchdog is configured only by executor mode, so the existing monolithic runner is unchanged. A user could invoke `run-executor` manually, but no supported host, Docker, or Kubernetes deployment currently does so.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54670",
          "createdAt": "2026-08-10T18:41:18Z",
          "updatedAt": "2026-08-13T08:15:34Z",
          "timestamp": "2026-08-13T08:15:34Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/agent-build",
            "team/action-platform",
            "internal",
            "team/fleet-automation"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:2e84dd14026d2e9b1c3f",
        "signalId": "github:DataDog/datadog-agent:pull_request:54225",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54225",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CWS] Kill container and cgroup scopes with cgroup v2 cgroup.kill",
          "text": "### What does this PR do? Kill actions scoped to `container` or `cgroup` now kill the whole cgroup with a single write to the cgroup v2 `cgroup.kill` interface (Linux 5.14+), instead of signalling every PID of the cgroup one by one. The previous behaviour is kept as a fallback for everything `cgroup.kill` cannot express. A failed `cgroup.kill` write kills nothing, so falling back after one is always safe: | Situation | Behaviour | |---|---| | `container`/`cgroup` scope, `SIGKILL`, pure cgroup v2 | one `cgroup.kill` write | | Signal other than `SIGKILL` | per-process kill (`cgroup.kill` only delivers `SIGKILL`) | | `process` scope | per-process kill, unchanged | | Target cgroup has child cgroups | per-process kill (see Additional Notes) | | Hybrid/v1 hierarchy, kernel < 5.14, threaded cgroup, no writable path | per-process kill | ```mermaid flowchart TD A[kill action] --> B{scope is container or cgroup<br/>AND signal is SIGKILL<br/>AND pure cgroup v2?} B -- no --> Z[signal each PID] B -- yes --> C[resolve cgroup ID + inode<br/>from the cgroup resolver] C --> D{target holds the agent<br/>itself or an ancestor?} D -- yes --> R[refuse] D -- no --> E[for each candidate base:<br/>agent view, then /proc/1/root] E --> F{dir inode matches<br/>the resolved one?} F -- no --> E F -- yes --> N{cgroup has child cgroups?} N -- yes --> Z N -- no --> G[open cgroup.kill O_WRONLY] G -- EROFS/ENOENT --> E G -- ok --> H[write &quot;1&quot;] H -- ok --> I[whole cgroup tree killed] H -- EOPNOTSUPP/ENODEV --> Z E -- no base worked --> Z ``` ### Motivation [CWS-6377](https://datadoghq.atlassian.net/browse/CWS-6377). The per-PID loop has two problems. It can be outrun: a process that keeps forking can create children faster than we walk the PID list, and the loop has to carry a `createdAt` check to avoid killing a recycled PID. And it is expensive — roughly five procfs accesses per PID (`psutil.NewProcess` + `CreateTime` + `Exe` when enumerating, then `NewProcess` + `CreateTime` again when killing). `cgroup.kill` removes both. The kernel documents that it \"deal[s] with concurrent forks appropriately and is protected against migrations\", and it replaces the N kill syscalls with one write. ### Describe how you validated your changes **Unit tests** (`dda inv test --targets=./pkg/security/probe,./pkg/security/utils` — 337 tests pass): - one-shot kill is used for `cgroup`/`container` scope, and no process is signalled individually - fallback to per-process kills when the cgroup kill fails - `process` scope and non-`SIGKILL` signals never take the one-shot path - a queued kill (disarmer warmup) still uses one operation per cgroup - `cgroup.kill` receives exactly `\"1\"`, falls through to the next candidate base, and errors when the file is missing - inode mismatch and agent-own-cgroup targets are refused - unsafe cgroup IDs (`\"\"`, `/`, `..`) are rejected - `TestCgroupKillerKillsRealCgroup` exercises a real cgroup v2 hierarchy; it skips without root (same pattern as `pkg/gpu/cgroups_test.go`), so it does not run in the unit CI job — the functional tests below cover that in a root VM **Existing functional tests** already exercise the new path: the `cgroup`-scope kill tests in `pkg/security/tests/action_test.go` and `cgroup_test.go` run as root on a pure cgroup v2 VM with `SIGKILL`. **Kernel behaviour verified manually** on 6.8 before writing the code: - `cgroup.kill` kills the cgroup *and its descendant cgroups* (exit 137) - threaded cgroup → `EOPNOTSUPP` (errno 95); root cgroup has no `cgroup.kill` - writing through a read-only bind mount of cgroupfs → `EROFS` - writing via `/proc/1/root/sys/fs/cgroup/...` → succeeds, including when procfs itself is bind-mounted read-only - `open(cgroup.kill, O_WRONLY)` has no side effect — the kill only happens on write — which is what makes trying one base and falling back to the next safe `dda inv linter.go` reports 0 issues and `dda inv system-probe.build` succeeds. ### Additional Notes **No change in blast radius.** `cgroup.kill` would also kill the processes of descendant cgroups, which are not part of the PID list checked against the excluded binaries (the resolver keys one cache entry per cgroup and never walks children). Rather than kill processes that were never checked, the one-shot path is refused when the target has child cgroups, and those fall back to the per-process path. Container and service cgroups are leaves in practice, so this keeps the single write where it matters at the cost of one `readdir` — cheaper than walking the subtree and resolving every descendant executable on each kill. Note that validating descendants instead would only narrow a TOCTOU window rather than close it, since a process can enter a descendant between the check and the write. **Safety.** Process enumeration is unchanged, so the excluded-binaries check and the killed-PID reporting behave exactly as before — only the delivery mechanism changed. Two guards were added on top, because a single write reaches processes the PID list never named: - the target is refused if it is the agent's own cgroup *or an ancestor of it* (an ancestor is just as fatal, since descendants die too) - the cgroup directory's inode is checked against the one CWS resolved, so a stale or mismatching path cannot take down an unrelated workload - the one-shot path is skipped entirely when no process of the cgroup was resolved, so a cgroup we know nothing about is never killed unchecked **The read-only mount caveat.** `/host/sys/fs/cgroup` is mounted `readOnly: true` into every container in `Dockerfiles/manifests/`, so the obvious implementation fails with `EROFS` in Kubernetes while passing on host installs and in the functional-test VMs. The killer therefore tries the agent's own view first and then `/proc/1/root/<host cgroup2 mount>`, which reaches the same file through pid 1's mount namespace where it is still writable. That needs `hostPID: true` (set in the manifests here). **Automated tests cannot cover this**: they run as root with writable mounts, so they pass either way. The manual QA step for this PR is therefore a Kubernetes check that the one-shot path is actually taken (and confirming the Helm chart and datadog-operator set `hostPID`) — without it the fast path silently always falls back to the previous per-process behaviour. **No config flag.** Since the design falls back on any error there is no state to get stuck in, so no kill switch was added. Happy to add `runtime_security_config.enforcement.cgroup_kill_enabled` if reviewers want an explicit escape hatch for an enforcement-path change. [CWS-6377]: https://datadoghq.atlassian.net/browse/CWS-6377?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54225",
          "createdAt": "2026-07-29T17:49:04Z",
          "updatedAt": "2026-08-13T08:13:30Z",
          "timestamp": "2026-08-13T08:13:30Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/agent-security",
            "team/ebpf-platform",
            "qa/done",
            "long review",
            "team/agent-build",
            "internal",
            "team/fleet-automation"
          ],
          "author": "homoeconomics",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:30ac84d80638cb8f762d",
        "signalId": "github:DataDog/datadog-agent:pull_request:54806",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54806",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[Backport 7.83.x]  [EBPF] Gate NVML workloadmeta collector on GPU monitoring",
          "text": "Backport d1520bca29c837ff691f91102b60a32a37c0112c from #54563. ___ ### What does this PR do? Gates the NVML workloadmeta collector on `gpu.enabled`. ### Motivation Avoid NVML collection when GPU monitoring is disabled. ### Describe how you validated your changes Added unit coverage for disabled startup. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54806",
          "createdAt": "2026-08-13T07:47:59Z",
          "updatedAt": "2026-08-13T08:05:06Z",
          "timestamp": "2026-08-13T08:05:06Z",
          "metrics": {
            "reactions": 2,
            "comments": 0
          },
          "labels": [
            "changelog/no-changelog",
            "team/ebpf-platform",
            "qa/done",
            "backport",
            "bot",
            "medium review",
            "team/agent-build",
            "internal",
            "team/gpu-monitoring-agent"
          ],
          "author": "dd-octo-sts[bot]",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:d1f022193da820e00975",
        "signalId": "github:DataDog/datadog-agent:pull_request:54805",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54805",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[Backport 7.82.x]  [EBPF] Gate NVML workloadmeta collector on GPU monitoring",
          "text": "Backport d1520bca29c837ff691f91102b60a32a37c0112c from #54563. ___ ### What does this PR do? Gates the NVML workloadmeta collector on `gpu.enabled`. ### Motivation Avoid NVML collection when GPU monitoring is disabled. ### Describe how you validated your changes Added unit coverage for disabled startup. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54805",
          "createdAt": "2026-08-13T07:47:49Z",
          "updatedAt": "2026-08-13T07:56:01Z",
          "timestamp": "2026-08-13T07:56:01Z",
          "metrics": {
            "reactions": 2,
            "comments": 0
          },
          "labels": [
            "changelog/no-changelog",
            "team/ebpf-platform",
            "qa/done",
            "backport",
            "bot",
            "medium review",
            "team/agent-build",
            "internal",
            "team/gpu-monitoring-agent"
          ],
          "author": "dd-octo-sts[bot]",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:e3119df8cb40434da514",
        "signalId": "github:DataDog/datadog-agent:pull_request:54563",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54563",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[EBPF] Gate NVML workloadmeta collector on GPU monitoring",
          "text": "### What does this PR do? Gates the NVML workloadmeta collector on `gpu.enabled`. ### Motivation Avoid NVML collection when GPU monitoring is disabled. ### Describe how you validated your changes Added unit coverage for disabled startup. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54563",
          "createdAt": "2026-08-07T11:43:56Z",
          "updatedAt": "2026-08-13T07:46:17Z",
          "timestamp": "2026-08-13T07:46:17Z",
          "metrics": {
            "reactions": 1,
            "comments": 10
          },
          "labels": [
            "changelog/no-changelog",
            "team/ebpf-platform",
            "qa/done",
            "medium review",
            "team/agent-build",
            "internal",
            "team/gpu-monitoring-agent",
            "backport/7.82.x",
            "backport/7.83.x"
          ],
          "author": "gjulianm",
          "state": "closed",
          "assignees": [
            "gjulianm"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:303e738c41fe6d302e89",
        "signalId": "github:DataDog/datadog-agent:pull_request:54782",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54782",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add a typed file provisioner, to allow using existing infrastructure more easily",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Create a typed file provisioner. To use an environment already provisioned inside a test ### Motivation We want to separate provisioning from test execution, that part gives us a first step to be able to first provision the environment outputing, a state file and then reusing that existing environment directly in the test ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54782",
          "createdAt": "2026-08-12T14:18:45Z",
          "updatedAt": "2026-08-13T07:22:21Z",
          "timestamp": "2026-08-13T07:22:21Z",
          "metrics": {
            "reactions": 1,
            "comments": 11
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "KevinFairise2",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:fc8a34aef48c889dd59a",
        "signalId": "github:DataDog/datadog-agent:pull_request:54773",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54773",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[anomalydetection] Test: per source scorer",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Config: ```yaml anomaly_detection: tailer_match_telemetry: enabled: true report_interval: 5m max_tracked_metric_series: 1000 max_event_metric_items: 20 max_event_log_scopes: 20 reporting: events: enabled: true ``` ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54773",
          "createdAt": "2026-08-12T11:32:16Z",
          "updatedAt": "2026-08-13T07:06:49Z",
          "timestamp": "2026-08-13T07:06:49Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/agent-runtimes",
            "team/agent-build",
            "internal",
            "team/fleet-automation"
          ],
          "author": "CelianR",
          "state": "closed",
          "assignees": [
            "CelianR"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:bdcd48379ae79455eefc",
        "signalId": "github:DataDog/datadog-agent:pull_request:54504",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54504",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add macOS thermal check reading AppleSMC sensors and thermal pressure",
          "text": "### What does this PR do? Adds a macOS implementation of the `thermal` corecheck, which until now existed only for Windows. The check is darwin-only (`//go:build darwin`) and is registered alongside the other core checks in `pkg/commonchecks/corechecks.go:154`. It collects two independent classes of signal: - **Hardware temperatures via AppleSMC.** `thermal_darwin.c` performs raw IOKit user-client struct calls against the private `AppleSMC` service to read named 4-character sensor keys. Per-chip-generation key tables cover Apple Silicon (M1 through M5) as well as Intel Macs, and for each sensor group the hottest in-range reading is taken as the representative value. - **macOS thermal pressure level**, read from the `com.apple.system.thermalpressurelevel` Darwin notification (`0=Nominal`, `1=Moderate`, `2=Heavy`, `3=Trapping`, `4=Sleeping`). Metrics emitted: | Metric | Tags | |---|---| | `system.thermal.temperature.cpu` | `macos`, `smc`, `cpu` | | `system.thermal.temperature.gpu` | `macos`, `smc`, `gpu` | | `system.thermal.temperature.ssd` | `macos`, `smc`, `ssd` | | `system.thermal.temperature.battery` | `macos`, `smc`, `battery` | | `system.thermal.pressure_level` | `macos`, `pressure_level:<nominal\\|moderate\\|heavy\\|trapping\\|sleeping\\|unknown>` | Any sensor that is unavailable on the running machine is skipped rather than reported as zero: unreadable keys are represented as an absent `OptionalFloat`/`OptionalInt` in C, surface as `nil` in Go, and are filtered out before the gauge is submitted. Files: - `pkg/collector/corechecks/system/thermal/thermal_darwin.c` (new) — AppleSMC struct-call plumbing, SMC key tables, thermal pressure lookup - `pkg/collector/corechecks/system/thermal/thermal_darwin.h` (new) — `OptionalFloat` / `OptionalInt` / `SmcInfo` / `ThermalInfo` structs and the `getThermalInfo()` declaration - `pkg/collector/corechecks/system/thermal/thermal_darwin.go` (new) — check definition, cgo conversion, metric submission - `pkg/collector/corechecks/system/thermal/BUILD.bazel` — cgo sources, `-framework IOKit -framework CoreFoundation` link flags, darwin/ios deps - `pkg/collector/corechecks/system/thermal/thermal_stub.go` — build tag narrowed from `!windows` to `!windows && !darwin` so the no-op factory no longer shadows the new darwin implementation ### Motivation https://datadoghq.atlassian.net/browse/WINA-2934 The Agent already ships a `thermal` check on Windows (`thermal_windows.go`, backed by PDH \"Thermal Zone Information\" counters), but macOS had only the no-op stub factory, so macOS hosts reported no thermal data at all. This closes that feature-parity gap. Thermal data is particularly meaningful on macOS laptops, where sustained thermal pressure is a direct explanation for CPU throttling and the performance degradation that follows. Exposing `system.thermal.pressure_level` alongside raw die temperatures lets users correlate a drop in host throughput with the thermal state that caused it. Note that the metric names intentionally do **not** match Windows one-for-one: Windows emits `system.thermal.temperature` and `system.thermal.passive_limit` tagged per ACPI thermal zone, whereas macOS exposes discrete named sensors (CPU/GPU/SSD/battery) and a single global pressure level, so the macOS metrics are namespaced per sensor instead. ### Describe how you validated your changes **Automated** - `bazel build //pkg/collector/corechecks/system/thermal/...` — passes, no compiler warnings from the cgo/C sources. - `dda inv linter.go --targets=./pkg/collector/corechecks/system/thermal/...` — 0 issues. - Verified the `BUILD.bazel` is exactly what `bazel run //:gazelle -- ./pkg/collector/corechecks/system/thermal` generates, and that `bazel run //bazel/buildifier` reports it as correctly formatted. - Verified programmatically that the SMC key tables contain no duplicate entries and no overlap between the CPU and GPU tables. **Manual hardware QA** Because every value in this check comes from real hardware sensors, the substantive validation is a load test on physical machines: 1. Build and run the Agent on an **M1** and an **M5** Mac, both on **macOS Tahoe**. 2. Confirm baseline readings are plausible at idle: ``` DD_LOG_LEVEL=debug ./bin/agent/agent check thermal ``` (`agent check` defaults its log level to off, so `DD_LOG_LEVEL=debug` is required to see the per-sensor lines.) 3. Drive the machine into thermal stress with parallel `stress-ng` load across all cores: ``` stress-ng --cpu 0 -t 600 ``` 4. In the Datadog portal, verify over the load window that: - `system.thermal.temperature.cpu` and `system.thermal.temperature.gpu` climb well above their idle baseline and recover after the run ends; - `system.thermal.pressure_level` escalates above `0`/`nominal` (expected to reach at least `1`/`moderate`, and `2`/`heavy` on the fanless/sustained-load case) and returns to nominal on cooldown; - the `pressure_level:<name>` tag tracks the numeric value. **Status of the manual QA:** <img width=\"1191\" height=\"857\" alt=\"Screenshot 2026-08-06 at 12 24 11 PM\" src=\"https://github.com/user-attachments/assets/d02c3289-f31d-4c37-ac85-efb35ba101b5\" /> <img width=\"2114\" height=\"1146\" alt=\"Screenshot 2026-08-06 at 1 30 16 PM\" src=\"https://github.com/user-attachments/assets/8321465a-a380-457b-aa7c-72bc978b3a91\" /> **Not covered** - There are **no unit tests** for SMC. the SMC path itself is not unit-testable without hardware or an IOKit fake. - No E2E/fakeintake coverage — the macOS E2E suites do not currently provision a thermally-loadable host. ### Additional Notes - **This is a private, reverse-engineered interface.** The AppleSMC struct call has no public header and no stability guarantee across macOS releases or hardware generations; A macOS update can silently change or remove keys, in which case the affected metric simply stops being submitted rather than erroring. - **Do not shrink `SMCKeyData_t.pLimitData` back to 14 bytes.** It must stay 16 to match Apple's real layout. A previous 14-byte declaration silently corrupted every subsequent field in the struct — this is called out in a comment at the struct definition. - **Intel coverage is unverified on hardware.** The Intel CPU/GPU keys (`TC0D`/`TC0P`/`TC0C`–`TC7C`, `TG0D`/`TG0P`, `TCGC`, …) were added because the `darwin` build tag also covers amd64, but the manual QA above exercises Apple Silicon only. Intel keys are inert on Apple Silicon and vice versa, so there is no cross-architecture regression risk — but Intel readings should be spot-checked if an Intel Mac is available. - **SMC keys are case-sensitive.** The Apple Silicon lowercase `Tg*` keys and the Intel uppercase `TG*` keys are different sensors, as are the Apple Silicon `TC10`–`TC53` cluster keys versus Intel's `TC0*`. They look like duplicates but must not be merged. - **SMC Fallback** Revert this commit [e19887247a4eac8bea45a058c9ca64bc43a2e34b](https://github.com/DataDog/datadog-agent/pull/54504/changes/e19887247a4eac8bea45a058c9ca64bc43a2e34b) to add a SMC fallback, this commit get the thermal data using IOHIDEventSystemClient",
          "url": "https://github.com/DataDog/datadog-agent/pull/54504",
          "createdAt": "2026-08-06T09:26:36Z",
          "updatedAt": "2026-08-13T07:06:10Z",
          "timestamp": "2026-08-13T07:06:10Z",
          "metrics": {
            "reactions": 2,
            "comments": 6
          },
          "labels": [
            "long review",
            "qa/rc-required",
            "team/agent-devx",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "PedroCordeiroDataDog",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:196c32efa23c05be56e4",
        "signalId": "github:DataDog/datadog-agent:pull_request:54633",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54633",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[AAD-39] Format logs in scorer events",
          "text": "### What does this PR do? > [!NOTE] > Context: https://github.com/DataDog/datadog-agent/pull/54572 For scorer events, we handled only metrics. This PR formats the metrics derived by logs such that we obtain log patterns instead of metric names. Example: ``` Top contributions: 1. 75% — log: ERROR: connection refused to db.prod:5432 — {service:api} 2. 25% — log: GET /checkout <*> returned 500 — {env:prod} ``` ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54633",
          "createdAt": "2026-08-10T12:28:52Z",
          "updatedAt": "2026-08-13T07:05:41Z",
          "timestamp": "2026-08-13T07:05:41Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "medium review",
            "internal"
          ],
          "author": "CelianR",
          "state": "open",
          "assignees": [
            "CelianR"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:39aff1e317c6633f8163",
        "signalId": "github:DataDog/datadog-agent:pull_request:54683",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54683",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix(e2e): retry ensure-adws-started on transient SSH/script failures",
          "text": "### What does this PR do? Adds an onError resource hook that retries the ensure-adws-started command when sshd dies mid-command or the command's own PowerShell errors out, without retrying dial-exhaustion failures or the whole stack up. ### Motivation ensure-adws-started fails flakily shortly after domain-controller promotion (WINA-2095) due to transient SSH/script issues that a retry fixes. Requires the CI Pulumi CLI/engine to be bumped to >= v3.219.0 for onError hook support (tracked separately). ### Describe how you validated your changes Windows e2e tests should pass.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54683",
          "createdAt": "2026-08-10T21:29:03Z",
          "updatedAt": "2026-08-13T05:11:09Z",
          "timestamp": "2026-08-13T05:11:09Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "medium review",
            "team/agent-devx",
            "team/windows-products",
            "internal"
          ],
          "author": "clarkb7",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:7c4fafc5748d3b420952",
        "signalId": "github:DataDog/datadog-agent:pull_request:52986",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:52986",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "LLMO PoC: emit spans + capture LLM request bodies via eBPF",
          "text": "### What does this PR do? First proof-of-concept for LLM Observability built on top of USM/go-tls. When USM observes an HTTP/2 request whose path looks like an LLM API call (e.g. /v1/chat/completions, /v1/messages), we emit one APM span per request (no aggregation) with the full request path as the resource. For connections flagged as LLM traffic, the go-tls write hook also captures a 256-byte window of the decrypted request body into an eBPF map; userspace parses it to enrich the span with the model and prompt. Components: - pkg/network/ebpf/c/protocols/tls/llmo.h: llm_monitored_connections (gate), llm_request_bodies, and a per-CPU scratch map; llmo_maybe_capture_body() copies the decrypted request body for flagged connections. - pkg/network/ebpf/c/runtime/usm.c: call the capture in the go-tls write hook BEFORE tls_process() (which ends in a tail call and never returns). - pkg/network/protocols/http/llmo.go: path detection, dd-trace-go span emission, tolerant body parser (model + first message content), and the connection-flag + body-read logic. Matching Go structs for the eBPF maps (explicit padding so the key marshals to the map key size). - pkg/network/protocols/http/statkeeper.go: emit the span + capture the body per transaction when the path is an LLM endpoint. - pkg/network/protocols/http2/protocol.go: wire the eBPF maps into the HTTP/2 statkeeper. - pkg/network/protocols/http/llmo_test.go: parser tests incl. HTTP/2 DATA-frame-prefixed, NUL-padded, and truncated bodies. Known PoC limitations: path-only detection (no Host/:authority), body capped at 256B and keyed by connection (not stream), first request on a connection is missed, and the span service name is a fixed placeholder. Token usage (response side) is not captured yet. ### Motivation support llmo with ebpf ### Describe how you validated your changes unit test ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/52986",
          "createdAt": "2026-06-30T15:02:30Z",
          "updatedAt": "2026-08-13T04:40:17Z",
          "timestamp": "2026-08-13T04:40:17Z",
          "metrics": {
            "reactions": 1,
            "comments": 7
          },
          "labels": [
            "component/system-probe",
            "team/universal-service-monitoring",
            "qa/done",
            "long review",
            "team/cloud-network-monitoring",
            "stale",
            "internal"
          ],
          "author": "BarFinsdd",
          "state": "open",
          "assignees": [
            "BarFinsdd"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:ae5b4512cee22f22f35c",
        "signalId": "github:DataDog/datadog-agent:pull_request:54758",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54758",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(softinv): report OS updates and OEM driver packages",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Extends the software inventory beyond installed applications with three new collectors, tagged with two new software types, `os_update` and `driver`: | Platform | Source | |---|---| | Windows | `Win32_PnPSignedDriver` over WMI, scoped to OEM (`oemNN.inf`) packages | | Windows | CBS servicing store, packages with `CurrentState == 112` | | macOS | `SystemVersion.plist` for the running system, plus `InstallHistory.plist` receipts | It also bounds each collector in the shared snapshot runner at 90s. A timeout is fatal, because a timed-out enumeration is an unknown state and a missing row reads downstream as a removal. A collector that succeeds with zero rows stays a valid empty result. Since a hung native call cannot be cancelled (the WMI library has no context support), a collector that misses its deadline is not started again until it returns, so repeated collections cannot stack up blocked goroutines. Identity is chosen so that an update reads as a version change rather than remove + install: - **Drivers** are grouped by INF name, which is the real package boundary, but the product code is derived from provider, class and description — never the INF name, since Windows reassigns the `oemNN` number on republish. - **Windows updates** are identified by KB number where the servicing store records one, and by package family otherwise. Matching only `Package_for_KB…` would drop monthly cumulative updates (`Package_for_RollupFix~…`) entirely; rolling families keep one entry whose version advances. - **macOS** uses a constant `com.apple.macos` product code for the running system. The unused `softwareTypeMSU` placeholder is removed in favour of `os_update`. Driver `deployment_time` is deliberately empty: WMI only exposes `DriverDate`, a vendor build date rather than an install time. ### Motivation The inventory only covered installed applications, leaving OS patch level and third-party drivers invisible — two of the most useful signals for fleet visibility and compliance. The deadline is a prerequisite rather than a nicety: these sources (WMI, the registry, plist receipts) can block, and a single slow `Collect()` previously stalled the whole snapshot with no upper bound. ### Describe how you validated your changes - 66/66 unit tests pass, including with `-test.short=false` so the macOS integration test runs against a real host. - `dda inv linter.go` clean, and clean again cross-linted with `GOOS=windows`, which type-checks the Windows-tagged files and their tests. - `bazel test //pkg/inventory/software:software_test` passes; `comp/softwareinventory` and `cmd/system-probe/modules` unaffected (20/20 tests, clean Windows lint). - New coverage: deadline and in-flight behaviour, driver grouping across multi-model INFs and product-code collisions, CBS parsing including `RollupFix` and servicing-stack packages, FILETIME conversion, macOS receipt filtering with fatal-vs-warning paths, and entry-ID uniqueness once the new families merge with application entries. - Real-host integration tests, gated on `testing.Short()`: Windows cross-checks collected drivers against `pnputil /enum-drivers` and logs the KB-identified vs by-family split; macOS asserts the running-system version matches `sw_vers -productVersion`. **The Windows code is type-checked but has not been executed anywhere yet.** The WMI field mapping, the CBS package mix on a real host, and the shape of `pnputil` output are unverified until the Windows CI job or manual QA runs them. The macOS path has been exercised end to end. ### Additional Notes - A fatal error from any single collector still drops the whole snapshot (existing behaviour). Relevant to the new fatal paths: if the CBS key cannot be opened — for instance when system-probe is not elevated — application entries are lost too. - Enable with `software_inventory.enabled: true`, which drives both the system-probe module and the core agent component. No status or flare changes were needed, since `populateStatus` already groups by `Source`. - Worst-case snapshot duration is bounded per collector, not globally, so it scales with collector count. A snapshot-wide ceiling would be a separate change.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54758",
          "createdAt": "2026-08-11T23:51:09Z",
          "updatedAt": "2026-08-13T04:33:29Z",
          "timestamp": "2026-08-13T04:33:29Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "long review",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "sar-shah",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:7df2b4fd46941b594042",
        "signalId": "github:DataDog/datadog-agent:pull_request:54743",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54743",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CONTINT-5442] Add pod state handlers to container_lifecycle",
          "text": "### What does this PR do? This PR adds a `PodStateHandler` that emits transition events for pod `.status.phase` and `.status.conditions[*]` changes (except reason changes), using a per-pod shadow map to diff consecutive `workloadmeta` observations. Gated behind the existing `container_lifecycle.extended_set` flag. ### Motivation [CONTINT-5442](https://datadoghq.atlassian.net/browse/CONTINT-5442) ### Describe how you validated your changes Added unit tests. Also deployed the agent onto a kind cluster with telemetry enabled and an openmetrics check configured to scrape the agent telemetry ports, and saw the new `transition` `event_type` on the `datadog.agent.container_lifecycle_emitted_events` metric. <img width=\"1382\" height=\"401\" alt=\"image\" src=\"https://github.com/user-attachments/assets/8047b9ed-ff97-4e82-8785-8f547f964c06\" /> ### Additional Notes [CONTINT-5442]: https://datadoghq.atlassian.net/browse/CONTINT-5442?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54743",
          "createdAt": "2026-08-11T18:45:10Z",
          "updatedAt": "2026-08-13T04:07:35Z",
          "timestamp": "2026-08-13T04:07:35Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "medium review",
            "team/container-integrations",
            "team/agent-build",
            "internal"
          ],
          "author": "triviajon",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:1447c51dd50e4db73598",
        "signalId": "github:DataDog/datadog-agent:pull_request:54496",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54496",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "apm: use url.template for OTLP HTTP client resource names",
          "text": "## What does this PR do? Uses the OpenTelemetry `url.template` attribute when generating resource names for HTTP client spans. Client spans now use `METHOD url.template` when available and retain the method-only fallback otherwise. Server spans continue to use `METHOD http.route`. Both the current and legacy OTLP resource-name paths are covered to keep behavior consistent when operation/resource name V2 is disabled. Fixes #31570. ## Motivation HTTP client resource names currently collapse to the HTTP method even when OpenTelemetry instrumentation provides a low-cardinality URL template. Using the template produces more useful resource grouping without falling back to high-cardinality raw URLs. ## Testing Added focused unit coverage for client URL templates, method-only fallback, and client/server attribute precedence. Local `dda inv test --targets=./pkg/trace/api,./pkg/trace/otel/traceutil` could not run because Windows Defender quarantined the standalone `dda.exe` after its PyPI bootstrap failed with a TLS handshake error. CI is expected to run the required test targets. ## Additional Notes The current commit is unsigned because no local signing key is configured; it will need to be replaced with a signed commit before merge.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54496",
          "createdAt": "2026-08-05T21:37:23Z",
          "updatedAt": "2026-08-13T03:59:50Z",
          "timestamp": "2026-08-13T03:59:50Z",
          "metrics": {
            "reactions": 2,
            "comments": 7
          },
          "labels": [
            "community",
            "team/agent-apm",
            "team/agent-security",
            "team/ebpf-platform",
            "team/opentelemetry",
            "team/container-platform",
            "team/agent-delivery",
            "team/agent-integrations",
            "team/container-integrations",
            "team/agent-discovery",
            "team/agent-runtimes",
            "team/agent-log-pipelines",
            "team/agent-metric-pipelines",
            "team/agent-devx",
            "team/container-experiences",
            "team/agent-build",
            "team/action-platform",
            "team/gpu-monitoring-agent",
            "team/fleet-automation",
            "team/agent-data-plane"
          ],
          "author": "niharikag09",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:11b225caa81fa86dcc9a",
        "signalId": "github:DataDog/datadog-agent:pull_request:54804",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54804",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix(installer): embed -nocap systemd unit templates",
          "text": "## What does this PR do? Adds `//go:embed` directives for `tmpl/gen/oci-nocap/*.service` and `tmpl/gen/debrpm-nocap/*.service`, and the matching Bazel `embedsrcs` entries, so the `-nocap` systemd unit templates ship inside the installer binary. Adds `embed_test.go`, which enumerates units through the `embed.FS` and asserts `GetSystemdUnit` resolves every unit in both the ambient-capability and `-nocap` variants. ## Motivation This is to address this escalation: https://datadoghq.atlassian.net/browse/AGENT-16750 `GetSystemdUnit` selects the `-nocap` templates on hosts whose kernel does not support ambient capabilities (older than 4.3), but no `//go:embed` directive covered those directories. Unit generation failed at runtime with: ``` failed to write stable units: open tmpl/gen/debrpm-nocap/datadog-agent.service: file does not exist ``` The package manager scriptlet ignores that failure, so the install reported success while the host was left with no Datadog units and `systemctl start datadog-agent` returned `Unit not found`. Both the classic DEB/RPM path and Fleet Automation remote upgrades and config experiments (`oci-nocap`) were affected. The existing tests missed this because they read the template tree from disk instead of from the `embed.FS`, so the templates were always present regardless of the embed directives. ## Validation/Testing - `dda inv test --targets=./pkg/fleet/installer/packages/embedded` - 83 tests passed - `bazel test //pkg/fleet/installer/packages/embedded:all` - `embedded_test` and `tmpl_test` passed - The new `TestGetSystemdUnitEmbedsAllVariants` fails on `main` (`file does not exist` for every `-nocap` unit) and passes with this change - `TestGetSystemdUnitSelectsNocapVariant` confirms the `-nocap` unit actually has `AmbientCapabilities=` stripped, not just that it loads ### Known gap, not addressed here `tmpl/datadog-agent-data-plane.service.tmpl` emits `AmbientCapabilities` unconditionally, without the `{{ if .AmbiantCapabilitiesSupported }}` guard its siblings use, so its two variants are byte-identical. That is a pre-existing template defect, out of scope for this fix, and is documented in a comment on the test. 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
          "url": "https://github.com/DataDog/datadog-agent/pull/54804",
          "createdAt": "2026-08-13T03:52:11Z",
          "updatedAt": "2026-08-13T03:54:47Z",
          "timestamp": "2026-08-13T03:54:47Z",
          "metrics": {
            "reactions": 1,
            "comments": 1
          },
          "labels": [
            "medium review",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "mwdd146980",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:bb2af3bbe51cea566187",
        "signalId": "github:DataDog/datadog-agent:pull_request:54725",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54725",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Fix AWS CLI install/download flakiness in Windows E2E host_cache",
          "text": "### What does this PR do? - Check msiexec's real exit code instead of just whether `Start-Process` launched it. - Retry the AWS CLI install and `aws s3 cp` to handle flaky network. - Collect the msiexec install log into the test artifacts folder on failure. ### Motivation Try to avoid flakes like https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1914723351. See https://datadoghq.atlassian.net/browse/WINA-3000",
          "url": "https://github.com/DataDog/datadog-agent/pull/54725",
          "createdAt": "2026-08-11T14:44:42Z",
          "updatedAt": "2026-08-13T03:41:44Z",
          "timestamp": "2026-08-13T03:41:44Z",
          "metrics": {
            "reactions": 0,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "team/agent-devx",
            "team/windows-products",
            "internal"
          ],
          "author": "clarkb7",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:bb8b94e6cde8c6c43085",
        "signalId": "github:DataDog/datadog-agent:pull_request:54756",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54756",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix(logs): score timestamps on window density, not run average",
          "text": "### What does this PR do? Changes how the auto multi-line timestamp detector turns a token-transition match into a probability. `MatchProbability` marks every token transition in a line as `1` (the graph has that edge) or `-1` (it does not), runs Kadane's algorithm to find the highest-*sum* run, and then reports the **average over that run** as the probability. Those are answers to two different questions. Extending a run by a stretch that sums positive raises its sum while lowering its average, so Kadane's keeps growing the window past a perfect match and the score that comes back is the diluted one. This PR splits the two roles apart: - `maxSumSubsequence` (Kadane's, unchanged logic) still finds the run and still acts as the gate. A line only gets scored at all if that run is at least `minimumTokenLength` long. This is the check that holds false positives down, so it is kept exactly as-is. - `maxAverageSubsequence` then reports the density of the best window inside that run, which is the probability. The new search only looks at windows shorter than `2*minLength`. Any longer window splits into two parts that each satisfy the minimum, and a weighted average never exceeds both of its parts, so one part always scores at least as high. Comparisons stay in integer arithmetic (`windowSum*bestLen > bestSum*windowLen`) with a single division at the end, the prefix sums live in a stack-allocated power-of-two ring, and the loop stops as soon as an all-match window is found because with `1`/`-1` values nothing can beat it. One incidental cleanup that the split required: the `matchForIndex` closure carried a `lastToken` variable that made it single-pass and order-dependent. The transition at `idx` is fully determined by `ts[idx]` and `ts[idx+1]`, so that state was redundant. Removing it is what lets the two passes share one lookup function. ### Motivation Reported on IIS W3C extended format access logs, which are single-line by specification. Consecutive records were being concatenated into one log and tagged `auto_multiline_detected:true`, which broke the downstream IIS pipeline: grok-parsed fields such as `server_name` and `status_code` received a concatenated block of raw log text instead of extracted values. The mechanism is the dilution above. For a record like: ``` 2026-08-11 10:34:49 W3SVC1 10.1.48.10 GET /svc/v13/core/Consent 443 - 200 0 0 19571 1051 ``` the timestamp matches perfectly, but the client address tokenizes to `DD.D.DD.DD`, which extends the highest-sum run well past the timestamp. The average over that longer run comes to exactly `0.5`, the default `logs_config.auto_multi_line.timestamp_detector_match_threshold`. The comparison is strictly greater-than, so the line is not labelled `startGroup`, falls through to the labeler's default `aggregate`, and is appended to the log before it. Two things about this made it hard to spot from the outside: - It is shape-specific, not format-specific. In the same file, a record with `fe80::b045:52da:3136:3f1c%3` or `192.168.1.1` in that field scores `1.00` and behaves correctly. Only the `DD.D.DD.DD` shape lands on the boundary, so records from one file are affected intermittently. - Landing on exactly `0.5` is a coincidence of this input. The underlying defect scores down any line whose timestamp is followed by a net-positive but imperfect stretch, and other inputs will land elsewhere below the threshold. ### Verification **The pre-existing accuracy dataset is unchanged, line for line.** `TestCorrectLabelIsAssigned` prints a probability per input. I captured that output on `main` and on this branch and diffed the 49 pre-existing rows: ``` lines: before=49 after=49 (no diff) ``` Every true positive still scores what it scored before, and every negative still scores `0.00`. That last part is the load-bearing one: on `main` all 26 negatives score exactly `0.00`, meaning they are rejected by the length gate rather than by a low score. Keeping the gate on the highest-sum run is what preserves that. **The four IIS cases added to the dataset, before and after:** | Input (client address field) | `main` | this PR | |---|---|---| | `10.1.48.10` | 0.50, wrong label | 1.00 | | `10.1.48.10` (second record) | 0.50, wrong label | 1.00 | | `fe80::b045:52da:3136:3f1c%3` | 1.00 | 1.00 | | `192.168.1.1` | 1.00 | 1.00 | On `main` the two `DD.D.DD.DD` rows fail `TestCorrectLabelIsAssigned` with `probability: 0.500000`; with this change all four pass. **New unit tests.** `TestMaxAverageSubsequence` covers the window search directly, including two cases built so that maximizing the sum gives a demonstrably worse answer (a perfect prefix followed by a net-positive suffix, and two runs of matches bridged through the gap between them). `TestMaxAverageSubsequenceSearchesOnlyTheGivenRange` asserts the search never reads outside the run it was handed. `TestExpectedMatch` gains a case at the `MatchProbability` level whose transitions are `1 1 1 1 1 -1 1 1 -1`: averaging over the largest subsequence reports `0.66`, the new path reports `1.00`. `TestMaxSumSubsequence` is the old `TestMaxSubsequence` with its expectations untouched, since Kadane's behaviour is unchanged. **Performance.** This is a per-log-line path, so I added `BenchmarkMatchProbability` and measured both sides (Apple M3 Max, `-benchtime 2000000x -count 5`, mean ns/op): | Case | `main` | this PR | |---|---|---| | `NoTimestamp` (rejected at the gate) | 20 | 18 | | `MaxInputBytes` (rejected at the gate) | 23 | 23 | | `Timestamp` | 67 | 92 | | `TimestampFollowedByAddress` | 82 | 108 | Zero allocations in every case, same as before. Lines rejected at the gate, which is the common case for non-log-start lines, are unaffected. Lines that get scored cost about a third more. The first draft of this was 4-10x slower; the integer comparison, power-of-two ring, and perfect-window early exit are what brought it down, and each is exact rather than approximate. **Full package suite:** `go test ./pkg/logs/internal/decoder/...` fails on `TestUserPatternsJSON` and `TestSingleLineHandlerProcess/Base_case`. Both reproduce identically on a pristine `main` checkout in my environment, so they are pre-existing and unrelated. Everything else passes. ### Additional Notes **Relationship to #54753.** #54753 is a one-character minimal fix for the same customer report: it makes the threshold comparison inclusive (`>=`), so a line landing exactly on the threshold counts as a match. That resolves the IIS symptom because this input happens to land on exactly `0.5`, but it does not address why a perfectly matching timestamp scored `0.5` in the first place. This PR does. **They are alternatives, not a stack** (both touch the same test file), and I would take this one and close #54753. The boundary question #54753 raises is real and independent, though, so it may be worth keeping as a separate follow-up on its own merits. **Not addressed here.** IIS `u_ex*.log` files open with W3C header comment lines (`#Software:`, `#Version:`, `#Date:`, `#Fields:`) that carry no timestamp. Those still get the labeler's default `aggregate` label and are folded into the first real record. That is a separate concern from this scoring defect and is out of scope for this PR. **Threshold semantics unchanged.** `timestamp_detector_match_threshold` keeps its `0.5` default and its meaning. This PR changes what the probability measures, not how it is compared.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54756",
          "createdAt": "2026-08-11T21:41:42Z",
          "updatedAt": "2026-08-13T03:34:58Z",
          "timestamp": "2026-08-13T03:34:58Z",
          "metrics": {
            "reactions": 2,
            "comments": 6
          },
          "labels": [
            "medium review",
            "team/agent-log-pipelines",
            "team/agent-build",
            "internal"
          ],
          "author": "mwdd146980",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:e25c00b8e15f853a86d3",
        "signalId": "github:DataDog/datadog-agent:pull_request:54753",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54753",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix(logs): stop diluting leading timestamp matches",
          "text": "### What does this PR do? Modifies the auto multi-line timestamp detector's scoring so that a line opening with a long enough run of matching tokens is scored on that run alone. Adds regression cases for both sides of the default threshold. ### Motivation Consecutive IIS W3C access-log records were being concatenated into a single log. W3C extended records are single-line by specification, so each one must start its own group. This surfaced as a customer escalation ([AGENT-16759](https://datadoghq.atlassian.net/browse/AGENT-16759)) after 7.82.0 enabled `logs_config.auto_multi_line_detection` by default (#53007). The cause is in `maxSubsequence`. The detector tokenizes the line, then scores each adjacent pair of tokens `+1` if that pair appears in a known timestamp format and `-1` if it does not. `maxSubsequence` is Kadane's algorithm, so it selects the run of pairs with the highest *total*, and the reported probability is that total divided by the run's length. ``` input : 2026-08-11 10:34:49 W3SVC1 10.1.48.10 GET /ZenIT/Service/v13 tokens : DDDD-DD-DD DD:DD:DD CDCCCD DD.D.DD.DD CCC /CCCCC/CCCCCCC/CDD pairs : +++++++++++----+++--++++--------- ``` 34 tokens give 33 pairs, in sign blocks of `+11`, `-4`, `+3`, `-2`, `+4`, `-9`: | run | total | length | probability | |---|---|---|---| | first 11 pairs, the timestamp | +11 | 11 | 1.0000 | | first 24 pairs | +12 | 24 | **0.5000** | | all 33 pairs | +3 | 33 | 0.0909 | Extending from 11 pairs to 24 adds `-4 +3 -2 +4`, a net gain of one, so the total rises from 11 to 12 and the longer run wins. The timestamp scores perfectly on its own, but the algorithm walks past it for a single extra point of total and the reported probability halves. `0.5` is the default `logs_config.auto_multi_line.timestamp_detector_match_threshold` and the comparison is strictly greater-than, so each record fell through to the labeler's default `aggregate` and was appended to the preceding log. `MatchProbability` now measures the leading run of matching pairs up front and reports a full match when that run is at least `minimumTokenLength`. Answering there skips the Kadane scan altogether, so the function ends up faster than before rather than slower. ### Verification - Added the four IIS records to the `inputs` dataset. Two carry the `DD.D.DD.DD` client address and previously scored `0.5`. Two are controls that already scored `1.0`. - Added four continuation lines as `aggregate` cases. Each contains an IPv4 address that scores exactly `0.5` on its own, pinning the other side of the boundary. - `dda inv test --targets=./pkg/logs/internal/decoder/preprocessor/...` passes, 410 tests. `dda inv test --targets=./pkg/logs/...` passes, 1734 tests with 1 skipped. - Mutation-tested every part of the change. Reverting `token_graph.go` fails the two IIS cases at `0.500000`. Relaxing the comparison to `>=` fails all four continuation cases. An off-by-one on `minimumTokenLength` fails `TestLeadingRunIsFullMatch`. - Measured every dataset input at full float64 precision in a standalone harness at shipping defaults, then swept all 81 IPv4 octet digit-shapes plus 21 adversarial inputs (MAC addresses, UUIDs, version vectors, phone numbers, IPv6). The change flips no input other than the two IIS records. - `MatchProbability` has exactly one non-test caller, the timestamp detector. - Benchmarked against `main` on the detector's own corpus: `MatchProbability` goes from 2673 to 1830 ns/op, about 32% faster, with allocations unchanged at zero. A line opening with a timestamp drops from 68 to 13 ns/op because it no longer runs the scan. The worst case, a leading run one pair short of the minimum, costs 9% more. Behaviour was held identical across 400k randomised comparisons against the previous implementation. [AGENT-16759]: https://datadoghq.atlassian.net/browse/AGENT-16759?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54753",
          "createdAt": "2026-08-11T21:03:46Z",
          "updatedAt": "2026-08-13T03:33:09Z",
          "timestamp": "2026-08-13T03:33:09Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "qa/done",
            "medium review",
            "team/agent-log-pipelines",
            "internal"
          ],
          "author": "mwdd146980",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:c90cc76235639b9d21fb",
        "signalId": "github:DataDog/datadog-agent:pull_request:43554",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:43554",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "DELA-251 - Initial implementation of cloud auth proof for an API key",
          "text": "### What does this PR do? This adds a new authentication method for the agent. This give the agent the ability to exchange a AWS Cloud Auth Proof for an API key which is automatically managed and rotated on behalf of the customer. This is essentially extending the https://docs.datadoghq.com/account_management/cloud_provider_authentication into the agent. The flow is as so: 1. Agent get AWS credentials from the environment the agent is running in 2. Agent signs a request to AWS which will prove it's access to the credentials 3. Agent passed the signed request to Datadog service 4. Service validates the signed request against AWS and validates it against Datadog configuration 5. Service response with a Managed and automatically rotated API key 6. Agent propagates that API key throughout it's config If the delegated auth flow fails it will fallback to using the API key provided in the yaml file. The allows customers to onboard with limited risk to their current flow. ### Motivation This should enable customers to not need to manage the API used by the agent and instead use the AWS credentials in the AWS environment the agent is deploy to. ### Describe how you validated your changes Ran the agent locally to validate changes and deployed to multiple staging clusters. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/43554",
          "createdAt": "2025-11-26T19:53:13Z",
          "updatedAt": "2026-08-13T03:02:58Z",
          "timestamp": "2026-08-13T03:02:58Z",
          "metrics": {
            "reactions": 0,
            "comments": 4
          },
          "labels": [
            "team/agent-apm",
            "component/system-probe",
            "team/agent-security",
            "team/remote-config",
            "team/ebpf-platform",
            "team/agent-cspm",
            "team/container-platform",
            "long review",
            "team/ndm-core",
            "qa/rc-required",
            "team/ndm-integrations",
            "team/agent-integrations",
            "team/agent-runtimes",
            "team/agent-configuration",
            "team/agent-log-pipelines",
            "team/agent-metric-pipelines",
            "team/agent-devx",
            "team/container-experiences",
            "team/windows-products",
            "team/cloud-network-monitoring",
            "team/network-path",
            "team/action-platform",
            "internal"
          ],
          "author": "wynbennett",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:b6e1ac6bfccfd1c77b20",
        "signalId": "github:DataDog/datadog-agent:pull_request:46209",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:46209",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "system-probe: Run bazel build for checks",
          "text": "### What does this PR do? In .bazelrc, we run clippy and rustfmt checks in the build step using Bazel's aspects feature when in CI (using --config=ci, added by tools/bazel, which is automatically invoked by bazelisk, if the CI environment variable is present). However, it appears that these are only run when explicitly running the build step, not when, for example, a install step is run via \"bazel run\" which in turn depends on a build step. Since the system-probe build task only invokes the latter, the checks are not actually run. So add an explicit call to build before the install step. ### Motivation Actually catch rustfmt and clippy errors in CI. ### Describe how you validated your changes Introduced a formatting error and run CI https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1416891445",
          "url": "https://github.com/DataDog/datadog-agent/pull/46209",
          "createdAt": "2026-02-10T17:43:48Z",
          "updatedAt": "2026-08-13T03:02:50Z",
          "timestamp": "2026-08-13T03:02:50Z",
          "metrics": {
            "reactions": 0,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/ebpf-platform",
            "qa/done",
            "medium review",
            "team/agent-discovery",
            "internal"
          ],
          "author": "vitkyrka",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:7f916c0255e6b38a693f",
        "signalId": "github:DataDog/datadog-agent:pull_request:36401",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:36401",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Update OTel Collector dependencies to v",
          "text": "This PR updates the dependencies of the OTel Collector to v{OCB_VERSION} and generates the OTel Agent code.",
          "url": "https://github.com/DataDog/datadog-agent/pull/36401",
          "createdAt": "2025-04-23T12:18:54Z",
          "updatedAt": "2026-08-13T03:02:47Z",
          "timestamp": "2026-08-13T03:02:47Z",
          "metrics": {
            "reactions": 0,
            "comments": 6
          },
          "labels": [
            "medium review",
            "team/agent-devx",
            "stale",
            "auto-closed",
            "internal"
          ],
          "author": "github-actions[bot]",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:0af52f2a389a01354d3a",
        "signalId": "github:DataDog/datadog-agent:pull_request:45934",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:45934",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[do not merge] Implement kubernetes_state.pod.time_to_ready [A]",
          "text": "### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/45934",
          "createdAt": "2026-02-04T15:11:12Z",
          "updatedAt": "2026-08-13T03:02:43Z",
          "timestamp": "2026-08-13T03:02:43Z",
          "metrics": {
            "reactions": 0,
            "comments": 3
          },
          "labels": [
            "team/container-platform",
            "long review",
            "team/kubernetes-experiences",
            "internal"
          ],
          "author": "triviajon",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:bd4dd9e5ccee6b4a3b64",
        "signalId": "github:DataDog/datadog-agent:pull_request:46235",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:46235",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Revert \"[SINT-3775] Use CI Identities IAM Role in Windows Jobs\"",
          "text": "Reverts DataDog/datadog-agent#40856",
          "url": "https://github.com/DataDog/datadog-agent/pull/46235",
          "createdAt": "2026-02-11T09:13:33Z",
          "updatedAt": "2026-08-13T03:02:39Z",
          "timestamp": "2026-08-13T03:02:39Z",
          "metrics": {
            "reactions": 0,
            "comments": 4
          },
          "labels": [
            "team/agent-delivery",
            "medium review",
            "team/agent-devx",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "KSerrania",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:c81226323c5b5a3683a2",
        "signalId": "github:DataDog/datadog-agent:pull_request:46240",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:46240",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[TEST] [DONOTMERGE] Try out cross-pipeline job dependencies",
          "text": "### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/46240",
          "createdAt": "2026-02-11T09:37:26Z",
          "updatedAt": "2026-08-13T03:02:31Z",
          "timestamp": "2026-08-13T03:02:31Z",
          "metrics": {
            "reactions": 0,
            "comments": 6
          },
          "labels": [],
          "author": "Ishirui",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:16569eee81b01e1b350b",
        "signalId": "github:DataDog/datadog-agent:pull_request:45747",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:45747",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[agenthealth] add e2e test",
          "text": "### What does this PR do? Adds end-to-end testing infrastructure for the agent health platform feature, including: - Agent health aggregator support in fakeintake for capturing and validating health reports - New E2E test suite (`new-e2e-agent-health`) that validates docker permission issue detection and reporting - GitLab CI configuration to run agent health E2E tests ### Motivation The agent health platform (added in previous PRs) needs E2E test coverage to ensure: - Health issues are correctly detected by the agent - Health reports are properly formatted and sent to the intake - The complete flow from issue detection to report submission works end-to-end ### Describe how you validated your changes - Added `test/fakeintake/aggregator/agenthealthAggregator_test.go` with unit tests for the aggregator - Created E2E test `test/new-e2e/tests/agent-health/docker_permission_test.go` that: - Provisions an EC2 instance with Docker and the Datadog agent - Deploys containers without proper Docker socket permissions - Verifies the agent detects and reports the docker permission issue - Validates the health report is received by fakeintake with correct issue details - Local linter passes with no issues ### Additional Notes - The E2E test runs manually and on changes to health platform code or E2E framework - Fakeintake now supports the `/api/v2/agenthealth` endpoint for testing health report submission - Test provisions infrastructure on AWS using Pulumi",
          "url": "https://github.com/DataDog/datadog-agent/pull/45747",
          "createdAt": "2026-01-30T17:20:32Z",
          "updatedAt": "2026-08-13T03:02:28Z",
          "timestamp": "2026-08-13T03:02:28Z",
          "metrics": {
            "reactions": 0,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "long review",
            "team/agent-devx",
            "internal"
          ],
          "author": "pducolin",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:eb8600d39fc1b44729dc",
        "signalId": "github:DataDog/datadog-agent:pull_request:45964",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:45964",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Paulcacheux/unmarshal binary opt",
          "text": "### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/45964",
          "createdAt": "2026-02-05T12:24:32Z",
          "updatedAt": "2026-08-13T03:02:24Z",
          "timestamp": "2026-08-13T03:02:24Z",
          "metrics": {
            "reactions": 0,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/agent-security",
            "qa/done",
            "short review",
            "internal"
          ],
          "author": "paulcacheux",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:5bf4e4a4916ffefd28b1",
        "signalId": "github:DataDog/datadog-agent:pull_request:46236",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:46236",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix(ci):comment ci-identities calls",
          "text": "### What does this PR do? #incident-49349 ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/46236",
          "createdAt": "2026-02-11T09:24:18Z",
          "updatedAt": "2026-08-13T03:02:20Z",
          "timestamp": "2026-08-13T03:02:20Z",
          "metrics": {
            "reactions": 0,
            "comments": 1
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "team/agent-delivery",
            "short review",
            "team/agent-devx",
            "team/windows-products",
            "internal"
          ],
          "author": "chouetz",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:d6083d05c26e9b424c02",
        "signalId": "github:DataDog/datadog-agent:pull_request:45535",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:45535",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "See if we can hack a way around project.extra_package_file",
          "text": "See if we can hack a way around the `project.extra_package_file` by writing tarballs directly to OMNIBUS_PACKAGE_ARTIFACT_DIR. This would be a temporary solution until the time when we can completely replace the package-artifact.rb. After migration, we'll just depend on these special targets in the srcs of the package target. One of the key motivations is to be able to build the product without stomping /etc. That is a key step in being able to build without being root.",
          "url": "https://github.com/DataDog/datadog-agent/pull/45535",
          "createdAt": "2026-01-27T04:39:09Z",
          "updatedAt": "2026-08-13T03:02:12Z",
          "timestamp": "2026-08-13T03:02:12Z",
          "metrics": {
            "reactions": 0,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/agent-build",
            "stale",
            "auto-closed",
            "internal"
          ],
          "author": "aiuto",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:71e72478f0f535591f76",
        "signalId": "github:DataDog/datadog-agent:pull_request:54169",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54169",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "WIF-57: retry (not drop) 403s on delegated-auth-pending domains",
          "text": "## Summary Split out of #54062 (which grew to touch too many teams' code in one PR — see [discussion](https://github.com/DataDog/datadog-agent/pull/54062#issuecomment-5104702094)). This is the core mechanism; two follow-on PRs stack on top of this one to extend it to other products. Adds durable-delivery handling for delegated-auth (WIF)-managed domains, matching the treatment `secrets.Component.Refresh()` already gets on a 403 response: - `delegatedauth.Component` gains `IsManaged(Target)`, a query method backed by the component's instance registry, so callers can ask \"is this specific key/domain currently WIF-managed\" independently of what the config value looks like right now. String-sniffing the current `api_key` config value for a `DELA(...)` prefix almost never worked, since delegated auth resolves the directive to a real key synchronously during config load, before most `Endpoint`/`domainResolver` objects are ever constructed. - `pkg/config/utils.MakeEndpoints` keeps a pending `DELA(...)` directive as a placeholder API key instead of dropping it entirely, and guesses `HasPendingDelegatedAuth` from that literal prefix. Without this, a domain whose only key source was a pending directive got zero API keys, and since transactions are created one per resolver API key, it got zero transactions — meaning it silently dropped all its traffic rather than queuing it, and never got a chance to hit the new retry path below. - `comp/forwarder/defaultforwarder`'s `markPendingDelegatedAuthDomains` overwrites that initial guess with `IsManaged`'s authoritative answer once the forwarder is constructed, so a directive that was rejected as malformed/unsupported (and never actually registered as an instance) doesn't retry forever — it drops like a genuinely bad key. The transaction/resolver layers then gate the 403 drop-vs-retry decision on the corrected per-key `HasPendingDelegatedAuth`, and nudge delegated auth to refresh sooner instead of waiting out its normal backoff interval. ## How durable delivery works Before this PR, a domain whose only key was a not-yet-resolved `DELA(...)` directive got zero API keys and therefore zero transactions — it silently dropped everything rather than queuing it: ```mermaid flowchart TD A[\"additional_endpoints entry:<br/>DELA(org_uuid, provider)\"] --> B{\"Directive resolved yet?\"} B -->|\"no (still pending)\"| C[\"MakeEndpoints drops the domain —<br/>zero API keys, zero transactions,<br/>zero chance to ever retry\"] B -->|yes, real key| D[\"Normal delivery\"] ``` This PR replaces that dead end with a queue-and-retry path, correcting the initial guess once against the source of truth, then using it on every 403: ```mermaid sequenceDiagram participant MK as MakeEndpoints participant NF as NewDefaultForwarder participant DA as delegatedauth.Component participant DR as domainResolver participant FW as Forwarder transaction participant DD as Datadog Intake MK->>MK: additional_endpoints entry = DELA(...)<br/>keep it as a placeholder API key,<br/>guess HasPendingDelegatedAuth=true from the literal prefix NF->>DA: IsManaged(Target{domain}) — authoritative check alt directive was registered as a real instance DA-->>NF: true NF->>DR: HasPendingDelegatedAuth stays true else directive was rejected (malformed/unsupported) DA-->>NF: false NF->>DR: HasPendingDelegatedAuth corrected to false<br/>(so it can drop like a normal bad key, not retry forever) end DR->>FW: transaction created, queued for delivery FW->>DD: send payload using placeholder key DD-->>FW: 403 Forbidden FW->>FW: secrets.Refresh() resolved a new key? alt yes FW->>DD: retry immediately with the new key else no FW->>DR: HasPendingDelegatedAuth(apiKeyIdx)? DR-->>FW: true — this key is still a DELA(...) placeholder FW->>FW: requeue transaction instead of dropping it FW->>DA: Refresh() — nudge sooner than the normal backoff DA->>DA: exchange cloud auth proof for a real API key DA->>DR: merge real key into additional_endpoints DR->>FW: retry with the resolved key FW->>DD: send payload DD-->>FW: 200 OK end ``` A static, non-WIF domain that gets a genuine 403 (bad API key) still drops as it does today — `HasPendingDelegatedAuth` only changes behavior for domains delegated auth is actually managing, per key, so a domain mixing a static key with a DELA-managed one treats each independently. ## Test plan - [x] `dda inv test --targets=./comp/core/delegatedauth/...,./comp/forwarder/defaultforwarder/...,./pkg/config/utils/...,./pkg/config/setup/...` — 696 tests passed - [x] `dda inv linter.go` on the same targets — clean - [x] Adversarial code review and security review run on the full diff, no blocking findings 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
          "url": "https://github.com/DataDog/datadog-agent/pull/54169",
          "createdAt": "2026-07-28T14:49:11Z",
          "updatedAt": "2026-08-13T02:01:52Z",
          "timestamp": "2026-08-13T02:01:52Z",
          "metrics": {
            "reactions": 0,
            "comments": 6
          },
          "labels": [
            "long review"
          ],
          "author": "wynbennett",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:94fdfaf6682d691b3327",
        "signalId": "github:DataDog/datadog-agent:pull_request:54437",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54437",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[AAD-23] Remove CUSUM detector",
          "text": "### What does this PR do? This PR removes the unused CUSUM detector and its configuration, tests, testbench UI, and evaluation wiring. ### Motivation CUSUM is disabled by default, is not used, and performs poorly in its current form. On the same 12 local eval scenarios, BOCPD + TimeCluster produced 6.08x higher mean F1 while CUSUM + TimeCluster produced 24.5x more baseline false positives and took 11.75x longer in detector execution. | Metric | CUSUM | BOCPD | |---|---:|---:| | Mean scenario F1 | 0.0212 | 0.1289 | | TimeCluster predictions | 2,923 | 287 | | Baseline false positives | 1,054 | 43 | | Raw detector anomalies | 571,833 | 1,315 | | Detector-phase time | 901.0s | 76.7s | ### Describe how you validated your changes - `dda inv test --targets=./comp/anomalydetection/observer/impl/` - `dda inv test --targets=./internal/qbranch/anomalydetection-testbench/` - `dda inv anomalydetection.build-testbench` - Python syntax validation for the anomaly-eval tasks - `git diff --check` - Repository pre-commit and pre-push hooks ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54437",
          "createdAt": "2026-08-04T19:08:27Z",
          "updatedAt": "2026-08-13T00:37:11Z",
          "timestamp": "2026-08-13T00:37:11Z",
          "metrics": {
            "reactions": 1,
            "comments": 8
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "long review",
            "team/agent-build",
            "internal",
            "team/fleet-automation"
          ],
          "author": "Eokye",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:601507400e5991ca8e9c",
        "signalId": "github:DataDog/datadog-agent:pull_request:54789",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54789",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(gpu): Add experimental Apple Silicon monitoring",
          "text": "### What does this PR do? Adds an experimental Apple Silicon backend to the standard `gpu` core check. The macOS implementation reads AGX device properties through unprivileged public IOKit APIs and emits only Apple-scoped metrics: - `gpu.apple.device.count` - `gpu.apple.core.count` - `gpu.apple.device.utilization` - `gpu.apple.system_memory.allocated` - `gpu.apple.system_memory.in_use` The system-memory metrics are explicitly defined as Apple driver-reported system memory associated with GPU clients; they do not claim discrete VRAM or total unified-memory semantics. The change keeps the Linux/NVML implementation unchanged, adds vendor-aware metric specifications and Apple-specific tag requirements, and keeps iOS on the unsupported stub. ### Motivation The Agent's GPU check was previously available only for Linux/NVIDIA systems. Apple Silicon hosts running Metal workloads—such as local inference, rendering, and macOS CI—need basic GPU inventory, activity, and GPU-client memory visibility. Apple does not provide an NVML-equivalent public system API. This implementation deliberately uses only IOKit registry properties available without root and treats missing or changed properties as optional. It avoids private frameworks, `powermetrics`, subprocess parsing, and mapping Apple values onto NVIDIA-shaped metric names. ### Describe how you validated your changes - `dda inv test --targets=./pkg/collector/corechecks/gpu` - `dda inv linter.go --targets=./pkg/collector/corechecks/gpu` - `bazel test //pkg/collector/corechecks/gpu:gpu_test_base //pkg/collector/corechecks/gpu/spec:spec_test_base --test_output=errors` - `bazel run //bazel/buildifier` - `dda inv schema.lint` - `dda inv agent.build --build-exclude=systemd` - Ran the built Agent's standard `gpu` check on an Apple M5 Pro and verified that exactly the five `gpu.apple.*` metrics were emitted. - Generated sustained Metal load using an already-local 35B Ollama model. Device utilization increased from a 39.4% mean at baseline to 88.9% under load, then returned to 36.8%. Driver-reported allocated/in-use system memory rose from about 5.1/0.8–1.1 GB to about 35.1/30.6–31.3 GB, then returned after model unload. ### Additional Notes The AGX registry property names are undocumented Apple driver data, so the feature is marked experimental and every property is optional. There is not yet an Apple Silicon fakeintake E2E environment; local QA covered the real packaged Agent registration, native reader, sender output, and hardware behavior.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54789",
          "createdAt": "2026-08-12T16:07:48Z",
          "updatedAt": "2026-08-12T23:03:06Z",
          "timestamp": "2026-08-12T23:03:06Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "team/ebpf-platform",
            "qa/done",
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "internal",
            "team/gpu-monitoring-agent",
            "team/fleet-automation"
          ],
          "author": "scottopell",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:75540862e8c9145449fb",
        "signalId": "github:DataDog/datadog-agent:pull_request:53415",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53415",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[DO NOT MERGE] One-off e2e run with ADP enabled by default",
          "text": "## Summary Temporarily flips \\`data_plane.enabled\\` from \\`false\\` to \\`true\\` in the agent's compiled-in config default so that every e2e test in the full suite runs against ADP without requiring per-test changes or test duplication. The change is throwaway — close without merging once the CI run completes. This is the same config knob used by the AMP ADP test helpers (DADP-72, see [Slack thread](https://dd.slack.com/archives/C070PQKLLP5/p1783453441368899)). ## How to kick off the full e2e suite Trigger a new pipeline on this branch and set the CI variable: \\`\\`\\` RUN_E2E_TESTS=on \\`\\`\\` That variable hits the \\`if_run_all_e2e_tests\\` rule in \\`.gitlab-ci.yml\\` and flips all e2e jobs from manual to \\`on_success\\`. ## CI findings (ADP 1.5.1, branch jszwedko/run-ci-adp-enabled) ### Fixed in this PR - **Windows MSI \\`status_command_infos\\`**: All MSI test variants fail because \\`agent_behaviour.go\\` asserts the status output contains \"DogStatsD\". When ADP handles DSD, the \\`DogStatsD\\` status section is absent (the \\`EnabledInternal()\\` guard prevents registering the status provider). Fixed by accepting either \"DogStatsD\" or \"Dogstatsd Metric Sample\" (always present in the Aggregator section). ### Known pre-existing failures (ADP limitations, tracked in Saluki) - **\\`TestReplayWithTagEnrichment\\`** — ADP doesn't enrich replayed DSD packets with current tagger state. Tracked in Saluki. ### New failures requiring Saluki fixes - **Container DSD tests (ECS \\`TestDogtstatsdUDP\\`, \\`TestDogtstatsdUDS\\`; Kind \\`dogstatsd-uds\\` pods)**: In container environments (ECS, K8s/Kind), fakeintake is configured as \\`DD_ADDITIONAL_ENDPOINTS\\` rather than \\`dd_url\\`. ADP doesn't appear to forward DogStatsD metrics to \\`additional_endpoints\\`, so no metrics arrive at fakeintake. In VM tests where fakeintake IS \\`dd_url\\` (primary endpoint), DSD forwarding works. This points to an \\`additional_endpoints\\` forwarding gap in ADP. - The Kind \\`dogstatsd-uds\\` pods fail to become Ready — the workload pods mount \\`/var/run/datadog/dsd.socket\\` as a HostPath volume (type \\`Socket\\`). With ADP enabled, the core agent's DSD server doesn't start (so no socket is created); ADP must create it but apparently doesn't complete socket setup in time or at the expected path. - Root cause: ADP \\`additional_endpoints\\` forwarding — active Saluki config migration work (issues #2312–#2316) may be the upstream cause. ### Other failures under investigation - **Anomaly detection tests** — under investigation, may be ADP-independent - **GPU tests** — under investigation ## Test plan - No new tests. The goal is to observe which existing e2e tests break when ADP is the default. - \\`new-e2e-amp-adp\\` (existing) runs the AMP suite filtered to \\`--run \"ADP\"\\` tests; this PR covers the rest. **DO NOT MERGE** — this default flip must not land on \\`main\\`.",
          "url": "https://github.com/DataDog/datadog-agent/pull/53415",
          "createdAt": "2026-07-08T21:31:58Z",
          "updatedAt": "2026-08-12T22:19:24Z",
          "timestamp": "2026-08-12T22:19:24Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "long review",
            "team/agent-configuration",
            "team/agent-metric-pipelines",
            "team/agent-devx",
            "team/windows-products",
            "internal",
            "team/fleet-remediation",
            "team/fleet-automation"
          ],
          "author": "jszwedko",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:53bbf2d51de0c80f99d7",
        "signalId": "github:DataDog/datadog-agent:pull_request:52945",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:52945",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(otel-logs): map instrumentation scope name to otel.scope.name",
          "text": "## Summary - Adds `otel.scope.name` to the OTLP → DD log translation in `opentelemetry-mapping-go/otlp/logs`, covering the **Datadog Agent OTLP receiver** and **DDOT** ingestion paths - Counterpart to [ddoghq/dd-source#3393](https://github.com/ddoghq/dd-source/pull/3393), which adds the same mapping for the direct `otlp.datad0g.com/v1/logs` intake path - The field is `otel.scope.name` in `AdditionalProperties`, consistent with the existing `otel.*` namespace for other log-record-level fields ## Test plan - [ ] `go test ./pkg/opentelemetry-mapping-go/otlp/logs/...` passes (new \"scope name\" test case added) - [ ] Verify `otel.scope.name` appears in Logs Explorer for logs ingested via Agent OTLP receiver 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
          "url": "https://github.com/DataDog/datadog-agent/pull/52945",
          "createdAt": "2026-06-29T20:28:58Z",
          "updatedAt": "2026-08-12T21:59:48Z",
          "timestamp": "2026-08-12T21:59:48Z",
          "metrics": {
            "reactions": 3,
            "comments": 4
          },
          "labels": [
            "qa/done",
            "medium review",
            "ask-review",
            "team/opentelemetry-agent",
            "internal"
          ],
          "author": "mabdinur",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:2043f91d636dbe44ee79",
        "signalId": "github:DataDog/datadog-agent:pull_request:54800",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54800",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "perf: move #54639's `proto.Client` clone from `seen` to `activeClients`",
          "text": "### What does this PR do? Move the `proto.Clone()` call that guards `pbgo.Client` aliasing from `clients.seen()` to `clients.activeClients()`. ### Motivation Follow-up to #54639, discussed with its author beforehand. `seen()` runs on every `ClientGetConfigs` poll from every client, up to twice per request via the bypass path, while `activeClients()` runs once per `refresh()` cycle regardless of client count. Cloning in `seen()` therefore pays one allocation per poll instead of one per client per refresh cycle, and the gap widens with client count. A micro-benchmark with 200 clients showed 29% fewer allocations at 2 polls per client per refresh cycle, and 50% fewer at 5 polls per client. The only regime where the opposite holds is `activeClients()` being called more often than clients poll, which only `ConfigGetState` does, and that is a debug endpoint, not a hot path. ### Describe how you validated your changes `TestClientsSeenActiveClientsRace` and the rest of the package's test suite pass unchanged under `-race`: the invariant it guards, that whatever escapes the lock is never mutated again, holds regardless of where the clone happens.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54800",
          "createdAt": "2026-08-12T20:41:52Z",
          "updatedAt": "2026-08-12T21:45:53Z",
          "timestamp": "2026-08-12T21:45:53Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "team/remote-config",
            "qa/done",
            "short review",
            "internal"
          ],
          "author": "rdesgroppes",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:59be96b23afa734e3562",
        "signalId": "github:DataDog/datadog-agent:pull_request:54601",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54601",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "dyninst/irgen: name the unsupported operation in condition errors",
          "text": "### What does this PR do? When a logpoint's condition uses an operation the Go debugger doesn't implement, the resulting error now names that operation. Also an unsupported operation can appear in two places, on its own or nested inside a comparison. Both now report the operation by name. ### Motivation A logpoint was created in staging against a Go service with a condition using `startsWith`, which Go does not implement. It never activated. The person debugging was told the target had passed validation but the service had not applied the logpoint. ### Describe how you validated your changes Added eight test probes covering every operation the shared expression language accepts but Go does not implement, in both positions an operation can occupy, and confirmed in the regenerated snapshots that each reports its own name. Ran the generator test suite and the eBPF integration test for the affected test program, to confirm the added failing probes don't disturb the probes that do attach.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54601",
          "createdAt": "2026-08-07T21:01:21Z",
          "updatedAt": "2026-08-12T21:44:25Z",
          "timestamp": "2026-08-12T21:44:25Z",
          "metrics": {
            "reactions": 2,
            "comments": 8
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "long review",
            "internal",
            "team/debugger"
          ],
          "author": "grantseltzer",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:b9cf436a14a1d49b2601",
        "signalId": "github:DataDog/datadog-agent:pull_request:54802",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54802",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Update dependency @sentry/dotagents to v3",
          "text": "This PR contains the following updates: | Package | Change | [Age](https://docs.renovatebot.com/merge-confidence/) | [Adoption](https://docs.renovatebot.com/merge-confidence/) | [Passing](https://docs.renovatebot.com/merge-confidence/) | [Confidence](https://docs.renovatebot.com/merge-confidence/) | |---|---|---|---|---|---| | @&#8203;sentry/dotagents | `1.19.0` → `3.0.1` | ![age](https://developer.mend.io/api/mc/badges/age/npm/@sentry%2fdotagents/3.0.1?slim=true) | ![adoption](https://developer.mend.io/api/mc/badges/adoption/npm/@sentry%2fdotagents/3.0.1?slim=true) | ![passing](https://developer.mend.io/api/mc/badges/compatibility/npm/@sentry%2fdotagents/1.19.0/3.0.1?slim=true) | ![confidence](https://developer.mend.io/api/mc/badges/confidence/npm/@sentry%2fdotagents/1.19.0/3.0.1?slim=true) | --- > [!WARNING] > Some dependencies could not be looked up. Check the [Dependency Dashboard](../issues/33469) for more information. --- ### Configuration 📅 **Schedule**: (in timezone Europe/Paris) - Branch creation - At 12:00 AM through 04:59 AM and 10:00 PM through 11:59 PM, Monday through Friday (`* 0-4,22-23 * * 1-5`) - Only on Sunday and Saturday (`* * * * 0,6`) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/DataDog/datadog-agent). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0NC4yNC4wIiwidXBkYXRlZEluVmVyIjoiNDQuMjQuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiY2hhbmdlbG9nL25vLWNoYW5nZWxvZyIsImRlcGVuZGVuY2llcyIsInFhL25vLWNvZGUtY2hhbmdlIl19-->",
          "url": "https://github.com/DataDog/datadog-agent/pull/54802",
          "createdAt": "2026-08-12T21:11:49Z",
          "updatedAt": "2026-08-12T21:44:24Z",
          "timestamp": "2026-08-12T21:44:24Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog",
            "dependencies",
            "qa/no-code-change",
            "short review",
            "team/agent-devx",
            "internal"
          ],
          "author": "renovate[bot]",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:d588c854e73ed8c14ca3",
        "signalId": "github:DataDog/datadog-agent:pull_request:54540",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54540",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add `datadog.ncm.check_failure` metric",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds a new metric on the agent, `datadog.ncm.check_failure`, which counts NCM config-check failures. ### Motivation [Inspiring Slack thread](https://dd.slack.com/archives/C08NTAS3A1E/p1785854202017089) The idea is that customers should be able to see if an NCM config sync failed or succeeded, even if there was no net change on the config. ### Changes - Add `datadog.ncm.check_failure` count, tagged with device tags and an `error:<reason>` tag - Add new errors (`ErrConfigRetrievalFailed`, `ErrPayloadSendFailed`) to cover additional errors related to config syncing - Adds device profile to `DeviceContext.GetTags` since tags now need to be built before a connection succeeds ### Describe how you validated your changes Updated unit tests in `networkdeviceconfig_test.go` Verification by running a local agent pointed at an unreachable (nonexistent) device <img width=\"832\" height=\"759\" alt=\"image\" src=\"https://github.com/user-attachments/assets/3000cd8e-fbc7-45bb-8d06-66d5d49f9494\" /> - Specifically verified the \"profile unreachable\" error ### Additional Notes Next steps are to set up an OOTB monitor on this metric.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54540",
          "createdAt": "2026-08-06T20:19:10Z",
          "updatedAt": "2026-08-12T21:27:19Z",
          "timestamp": "2026-08-12T21:27:19Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "medium review",
            "qa/rc-required",
            "team/ndm-integrations",
            "internal"
          ],
          "author": "juliewangdd",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:2c95b1eb9f1a0fc63b00",
        "signalId": "github:DataDog/datadog-agent:pull_request:54799",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54799",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "ci: default GitLab jobs to shallow clones, keep full history where needed",
          "text": "## Summary - Default GitLab jobs to `GIT_DEPTH: 1` so most checkouts are a shallow clone of HEAD only. - Set `GIT_DEPTH: 0` on jobs that actually need git history (merge-base, ancestor walks, `git describe`, `git log` ranges). - `GIT_STRATEGY: clone` is not a full clone; clone with depth 1 is still shallow. Full history requires `GIT_DEPTH: 0`. ## Test plan - [ ] Confirm a typical build/lint job clones with depth 1 and still has the working tree. - [ ] Confirm jobs that compute merge-base still succeed (`golang_deps_diff`, e2e `--impacted`, `static_quality_gates`, `files_inventory_check`, SMP merge-base check). - [ ] Confirm `setup_agent_version` can still run `git describe --tags`. - [ ] Confirm unit-test jobs with `FAST_TESTS=true` still detect impacted packages. Made with [Cursor](https://cursor.com)",
          "url": "https://github.com/DataDog/datadog-agent/pull/54799",
          "createdAt": "2026-08-12T20:14:02Z",
          "updatedAt": "2026-08-12T21:08:06Z",
          "timestamp": "2026-08-12T21:08:06Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [
            "community",
            "team/agent-apm",
            "team/ebpf-platform",
            "team/agent-delivery",
            "team/container-integrations",
            "team/agent-devx",
            "team/agent-build",
            "team/windows-products"
          ],
          "author": "mikesherovdd",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:bfc53eb95e6a2caf9f09",
        "signalId": "github:DataDog/datadog-agent:pull_request:54746",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54746",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ABLD-419]  Only install bazelisk with dda inv install-tools on macos",
          "text": "### What does this PR do? Cuts bazelisk out of tasks/install_tools. Except on mac, because for some reason it is not in the build image. ### Motivation We should not be installing bazelisk from tasks. That muddies the chain to source of trust because bazel is the root of the trusted tools. Bazelisk should come with the build image or be installed in some other trusted way. ### Describe how you validated your changes CI ### Additional notes Related: ABLD-306 This may break some individual users where bazelisk is not installed on the developer machine. That is desired. I want to find those cases and find ways to better manage their environment.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54746",
          "createdAt": "2026-08-11T19:55:59Z",
          "updatedAt": "2026-08-12T20:53:58Z",
          "timestamp": "2026-08-12T20:53:58Z",
          "metrics": {
            "reactions": 2,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "team/agent-devx",
            "internal"
          ],
          "author": "aiuto",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:203db11665c55539027e",
        "signalId": "github:DataDog/datadog-agent:pull_request:54115",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54115",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ABLD-395] MVP macos .pkg file rule.",
          "text": "### What does this PR do? Adds an MVP rule to create Mac PKG files. - bazel/rules/macos/pkg/pkg_mac_pkg.bzl - materialize srcs to diesk via a pkg_install-generated installer. sub-optimal but equivalent to what omnibus does today. Future work will improve that. - bazel/rules/macos/pkg/build_mac_pkg.sh — the pkgbuild wrapper - Adds packages/agent/macos/BUILD.bazel, to create a .pkg file for datadog-agent. This is obviously incomplete because //cmd/agent:agent is not ready yet. - packages/agent/product/BUILD.bazel — fixed a pre-existing bug where //cmd/loader:trace_loader (Linux-only target_compatible_with) was listed unconditionally, breaking any non-Linux consumer of :all_files. ### Motivation ### Describe how you validated your changes Claude's used lsbom to verify that the pkg format was valid. Hand compare the DMG built from the omnibus job to this output. ``` $ tree_size_compare --save pkg.json bazel-bin/packages/agent/macos/pkg.pkg $ tree_size_compare --save=dmg.json $HOME/Downloads/datadog-agent-7.83.0-devel.git.371.359005d.pipeline.126858256-1.arm64.dmg $ grep PKG@ dmg.json | sed -e 's/@PKG@/opt\\/datadog-agent/' >/tmp/dmg.files $ grep path pkg.json >/tmp/pkg.files $ grep system-prob /tmp/*.files /tmp/dmg.files: \"path\": \"opt/datadog-agent/bin/agent/dist/system-probe.yaml\", /tmp/dmg.files: \"path\": \"opt/datadog-agent/embedded/bin/system-probe\", /tmp/dmg.files: \"path\": \"opt/datadog-agent/etc/system-probe.yaml\", /tmp/dmg.files: \"path\": \"opt/datadog-agent/etc/system-probe.yaml.example\", /tmp/pkg.files: \"path\": \"opt/datadog-agent/etc/system-probe.yaml\", ``` The missing files are expected right now, because we have not done serious work at wiring up the dependencies. ### Next steps - tweak dependencies and config until we have fidelity with the omnibus packager. Brew the omnibus jobs to do this. - replace use of pkg_install to manifest the tree with a direct reader/writer. That is probably upstreamable to rules_pkg in a contrib section. I think I want a pkg_instantiate rule that will return a tree artifact. - Add signing (blocked on ABLD-386)",
          "url": "https://github.com/DataDog/datadog-agent/pull/54115",
          "createdAt": "2026-07-24T18:59:12Z",
          "updatedAt": "2026-08-12T20:45:48Z",
          "timestamp": "2026-08-12T20:45:48Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/agent-build",
            "internal"
          ],
          "author": "aiuto",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:0cb4ddeb02fb8ac4bbc0",
        "signalId": "github:DataDog/datadog-agent:issue:54801",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:issue:54801",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "issue",
          "title": "NDM Agent Workload Balancing: switch RC product from NDM_AGENT_WORKLOAD_BALANCING to HA_AGENT",
          "text": "## Context PRs #54652, #54656, #54659, and #54795 implemented NDM Agent Workload Balancing's agent-side component (`comp/workloadbalancing`), registering its own Remote Config product, `NDM_AGENT_WORKLOAD_BALANCING`. The design RFC ([NDM Agent Workload Balancing: Device Handoff](https://datadoghq.atlassian.net/wiki/spaces/II/pages/7029621750)) has since been updated to reuse HA Agent's existing `HA_AGENT` Remote Config product instead, extending its schema with a second, discriminated payload type rather than registering a new product. This follows the same polymorphic-payload pattern already used by ASM and Network Path's `NETWORK_PATH` product, and was settled after a Slack discussion establishing that extending an existing RC pipeline runs roughly 1-2 weeks versus roughly 1-2 months for a new one (new product registration, delivery predicates, the full RC checklist including security review). ## What needs to change - `comp/workloadbalancing`'s Remote Config listener: subscribe to `state.ProductHaAgent` (`HA_AGENT`) instead of a new `NDM_AGENT_WORKLOAD_BALANCING` product. - The listener needs to only act on documents carrying workload-balancing's discriminator field (e.g. `group_id`), ignoring ordinary HA Agent election documents (`config_id`/`active_agent`) on the same product, per `comp/haagent`'s existing per-document filtering pattern. - Apply-status handling: skip `applyStateCallback` for documents this listener doesn't own, mirroring the existing pattern in `comp/core/autodiscovery/providers/networkpath/provider.go` and `comp/networkpath/npcollector/impl/remote_config.go`, which already share one RC product between two independent listeners. - The RC product schema itself (config validator's schema library) needs to move from a new `NDM_AGENT_WORKLOAD_BALANCING` directory to an extension of `HA_AGENT`'s existing `root.json`. - Backend-side writer (`WorkloadBalancingService.UpsertGroupAssignment`) needs to target `HA_AGENT` RC documents instead of a separate product. - Test suite in `test/new-e2e/tests/workload-balancing/` currently calls `RCAddConfig(..., state.ProductNDMAgentWorkloadBalancing, ...)` — needs updating to `state.ProductHaAgent` with the new payload shape. ## Why this is a separate follow-up This is a documentation-first change: the RFC update landed ahead of the code so reviewers are working from the current design. The already-merged agent code should be brought in line with it once the RFC's schema/discriminator details are finalized. > **Note:** This issue was created by Claude.",
          "url": "https://github.com/DataDog/datadog-agent/issues/54801",
          "createdAt": "2026-08-12T20:42:56Z",
          "updatedAt": "2026-08-12T20:44:34Z",
          "timestamp": "2026-08-12T20:44:34Z",
          "metrics": {
            "reactions": 0,
            "comments": 0
          },
          "labels": [
            "pending",
            "oss/0",
            "team/network-device-monitoring-core"
          ],
          "author": "matthewleese",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:af63d61c9a9e8ccf32b3",
        "signalId": "github:DataDog/datadog-agent:pull_request:54546",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54546",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[WINA-2940] Break Group Policy passes into timed CSE invocations",
          "text": "### What does this PR do? Gives the existing `computer_group_policy` / `user_group_policy` milestones a drill-down: the client-side extensions (CSEs) that ran inside each boot Group Policy pass, and the Group Policy objects that fed each one. New `custom.group_policy_details` block, a sibling of the untouched `boot_timeline` and `durations`. This is the real block from the validation boot, verbatim apart from abbreviated GUIDs: ```json \"group_policy_details\": { \"computer\": [ { \"cse_id\": \"{35378EAC-…}\", \"cse_name\": \"Registry\", \"offset_ms\": 8058, \"duration_ms\": 127, \"result\": \"success\", \"gpos\": [{ \"id\": \"{11BBEC75-…}\", \"name\": \"ZZ Probe C & D\" }, { \"id\": \"{29227867-…}\", \"name\": \"ZZ Probe Beta\" }, { \"id\": \"{9905CA71-…}\", \"name\": \"ZZ Probe Alpha\" }, { \"id\": \"{31B2F340-…}\", \"name\": \"Default Domain Policy\" }] } ], \"user\": [ { \"cse_id\": \"{35378EAC-…}\", \"cse_name\": \"Registry\", \"offset_ms\": 6210, \"duration_ms\": 53, \"result\": \"success\", \"gpos\": [{ \"id\": \"{11BBEC75-…}\", \"name\": \"ZZ Probe C & D\" }, { \"id\": \"{29227867-…}\", \"name\": \"ZZ Probe Beta\" }] } ] } ``` Two more fields exist and are `omitempty`, so neither appears above: `async` (false throughout this boot) and `gpos_omitted` (nothing was dropped). The block is omitted entirely when no invocation was measured end to end. **Shape.** Flat `computer` / `user` arrays, so the JSON *is* the tree the UI renders. GPOs are inlined per invocation rather than pooled behind a GUID join, so a consumer needs no join — and the set is self-pruning, since a GPO reaches the wire only when a surviving boot-pass invocation references it. `offset_ms` comes from `bootOffsetFunc`, extracted out of `buildTimelineMilestones` so an invocation and its parent milestone sit on one axis: the login-screen gap collapse means a raw boot-relative offset would render a user-pass CSE *outside* its own pass. One duration field, the measured 4016→terminal interval, which is the same kind of wall-clock measurement as the 4000→8000 pass duration it is a slice of. **Attribution.** Events 4002–4007 (network-state change, `gpupdate`, periodic refresh) are not collected — their invocations are not part of the boot pass, and counting them there lets the child durations sum past the parent. Scope comes from a pass-activity table pinned by the **pass start events only**, 4000 and 4001. Taking the activity from the same event that sets the milestone timestamp is what makes a populated scope array imply its parent: this block cannot describe timed slices of a pass `boot_timeline` does not report. Three guards sit on the table: the zero GUID is refused, because events outside any pass genuinely carry it — 16 of them on the validation boot; one activity may not pin two scopes, or its bucket is emitted under both; and an activity ID matching no boot pass is dropped, never charged to the most recent pass. An earlier revision also seeded the table from 8000/8001, to recover a pass whose start event was missing. **The trace that motivated that does not have the shape it was read as having, and the claim is retracted.** Re-read with `Get-WinEvent -Path`, the trace lacking 4001 also lacks 8001: its second activity is a **4004/8004** pair, machine *manual* processing. So there is nothing to recover, and 8000/8001 carry no `PolicyActivityId` in any case. **Only measured invocations are emitted.** An unmatched terminal, an unmatched start, and an invocation still open when the trace ends have no interval to place on the timeline; a record without one is a collection diagnostic rather than latency data. A duplicate open start keeps the later one, and a terminal event that precedes its start is refused and leaves the start open. **Bounds.** Four constants cap what one payload may carry, fixed rather than configurable: 64 invocations per scope, 32 distinct GPO references per invocation, 128 bytes of CSE name, 512 bytes of GPO name. `TestSubmitEvent_WorstCasePayloadSize` couples all four through **one** byte budget — it builds the largest payload the caps permit and asserts it stays under 3 MB uncompressed, so raising any single cap fails that one test. Currently 2,373,734 bytes against the ceiling, 626 KB of margin. They are mandatory rather than prudent, because oversize fails silently and unrecoverably. The `event-management` pipeline uses `useStreamStrategy: true`, and `streamStrategy` has no size logic and never splits — `batch_max_content_size` and `logs_config.max_message_size_bytes` are both inert on this path. Oversize therefore surfaces only as an intake **HTTP 413**, which increments `tlmDropped` and returns a non-retryable `errClient`; `SendEventPlatformEventBlocking` has already returned `nil` by then, so the component can never learn its event was discarded. The payload size distribution is unmeasured, but an undetectable failure mode justifies a deterministic bound at any frequency. `retainMostRelevant` cuts an over-long invocation list: non-success outcomes first, then the longest durations, tie-broken on CSE ID. It has to run **before** the caller's chronological sort — sort-then-truncate would keep the head of the pass and drop whatever ran late in it, which is the opposite of useful. GPO overflow is reported per invocation as `gpos_omitted`, and the collector's `seen` set is what keeps that count exact: a GUID repeated past the cap is not a fresh loss. `truncateProviderText` cuts on a UTF-8 boundary, since a 512-byte cut through a multi-byte character would emit invalid UTF-8. **GPO lists.** `ApplicableGPOList`'s runtime format is now confirmed against a real boot: a **rootless `<GPO ID=\"{GUID}\"><Name>…</Name></GPO>` sequence carrying ID and Name only**. So IDs come from the `ID` attributes and display names come free from 4016, **and 5312 is not collected at all** — one walk yields both. This closes the open validation earlier revisions flagged: on the boot capture every name 5312 supplied for an emitted invocation was already on that invocation's own 4016, and on the earlier capture its `GPOInfoList` is empty on both events. Re-running `analyzeETL` over the boot ETL with the 5312 arm removed produces an unchanged block, all four display names included. `name` is `omitempty`, so the wire schema is unaffected. What survives is the shared GUID→name lookup, which is no longer a merged inventory but the thing that lets an invocation whose list ended early borrow a name from one that parsed cleanly. The braced-GUID scan is kept as a fallback for a fragment the token walk cannot finish and for a delimited or prose value. **It is only safe on `ApplicableGPOList`**: 5312's `GPOInfoList` carries a fuller entry that embeds `<Extensions>[{CSE GUID}{…}]</Extensions>`, so scanning that fragment would report an extension's own GUID as an applicable GPO. Not collecting 5312 makes that **structural rather than an ordering discipline** — the scan can only ever be handed `ApplicableGPOList`, which has no `<Extensions>` at all. **The fragments are not well-formed XML, and this cost real data.** Windows builds them by concatenation and does **not** escape display names, so a GPO named `R&D Baseline` arrives carrying a bare `&`. The validation boot had exactly that, first in every one of its four lists. Under Go's default strict decoder `DecodeElement` fails on that entry and the walk abandons everything behind it — the payload emitted all four GPO references with **no display name at all**. Two further failure modes sat one position away: when the offending name is not first, the partial tier-1 result satisfies the `len(ids) > 0` short-circuit and the scan fallback never runs, so the tail of the list is **dropped outright**; and on any fragment that does carry `<Extensions>`, the fallback reports the extension GUID as a GPO. `decoder.Strict = false` fixes the ampersand, but **only narrows the mid-list class rather than closing it**, which review caught. Non-strict decoding forgives malformed entities and missing end tags — it does not relax tag syntax. So a display name whose `<` does not open a well-formed tag, or a mismatched end tag like `</Nam>`, still ends the walk partway, and the short-circuit still returns the prefix. The walk now reports whether it reached end of input (`errors.Is(err, io.EOF)` — a clean end *is* `io.EOF`) and the fallback runs on **any** incomplete walk, appending the IDs it could not reach. Two table rows cover both malformations mid-list; reverting the guard fails exactly those two and nothing else. **Two supporting changes in `pkg/util/winutil/etw`:** - Expose `EVENT_HEADER.ActivityId`. Windows runs more than one instance of policy processing concurrently, so pairing on the extension GUID alone would cross unrelated passes. The boot capture makes this concrete: the **same** Registry CSE GUID `{35378EAC-…}` runs in both the computer and the user pass, and only the activity ID separates them. The header is also the *only* correlator available for a pass stop event: 4000/4001 do carry `PolicyActivityId` as property [0], equal to the header value, but **8000/8001 do not carry it at all** — their template is `PolicyElaspedTimeInSeconds, ErrorCode, PrincipalSamName, IsMachine, IsConnectivityFailure`. - `EventProperties` returns the properties decoded before a failure alongside the error instead of discarding all of them. A 4016 carries seven properties including three long strings, and one bad decode previously zeroed every field on the event. Parsing still stops at the first failure and never skips ahead — the property cursor is shared, so everything after a failure is garbage rather than merely missing. This is a **contract change to a shipped function** (\"nil map on error\" → \"possibly-populated map on error\") that the new block does not strictly require — without it the reader falls through to the per-property path, which still yields `\"\"`. Both callers repo-wide were checked: `GetEventPropertyString` tests `err` before touching the map, and `eventPropertyReader` is the intended consumer. Worth stating plainly that `pkg/util/winutil/etw` contains no test files, so this and the `ActivityId` population ship with no coverage in their own package. The recovery helps 4016 and does nothing for the stop events, because the templates disagree on property order: `CSEExtensionId` is property **[0]** on 4016 but **[3]** on 5016/6016/7016. A partial decode therefore *degrades* a start, losing the async flag and the GPO list, and *annihilates* a stop, losing the identity so its start is left open and dropped at finalize. `GetPropertyByName` is not a fallback for it — that path reads raw bytes as UTF-16, turning a 16-byte `win:GUID` into eight junk runes. `TestPartialDecodeDegradesAStartButDropsAStop` locks both directions. **One cleanup, not a fix:** `submitEvent` read `total_boot_duration_ms` back out of the payload map and formatted an `interface{}` with `%d`. That always worked — the boxed value is an `int64` — so it is fragility rather than a bug, and the new condition is provably identical: the old gate, `durations` present and carrying the key, is exactly `haveBoot && haveLogon`, which is `complete`. Note it leaves `impl_darwin.go` on the old pattern, so the two platforms now express this one line differently. ### Motivation Group Policy was reported as two aggregate milestones, each a single start/end pair. When Group Policy is the slow phase of a boot, that tells an operator *that* GP was slow and nothing about *what* in GP was slow. **No installer or autologger change is required**, and the validation boot proves it rather than arguing it: that ETL was captured by a **stock, released Agent 7.82.0 autologger** with no modification, and it contains every event this PR consumes. The GroupPolicy mask is `0x4000000000000000`, the channel-wide Operational keyword, and the session runs at `EnableLevel=4`; ETW treats level as a ceiling, so 4016/5016 (Informational), 6016 (Warning) and 7016 (Error) are all admitted. The only MSI edit here is comment-only. The file cap is 256 MB sequential and this capture came in at 6.2 MB, so truncation is not a factor either. ### Describe how you validated your changes Two real captures, on top of the unit suite. **1. A real autologger boot ETL from a domain-joined host** (6.2 MB, 43,250 events, `EventsLost 0`, three probe GPOs linked at the domain root all feeding the Registry CSE, plus HKCU settings so user-scope CSEs run). Decoded four independent ways — two `tracerpt` passes, `Get-WinEvent -Path`, and the analyzer itself — with agreeing event histograms. **`analyzeETL` ran clean end to end on real boot data for the first time.** No error, all 23 `BootTimeline` fields set, 11 milestones, 12 `durations` keys, and `group_policy_details` populated in **both** scopes — the payload quoted at the top of this description. An independent recomputation of `bootOffsetFunc` straight from raw ETW timestamps reproduced the analyzer's output exactly: `computer_group_policy` 7308 ms / 913 ms, `user_group_policy` 5956 ms / 318 ms, machine CSE 8058 ms / 127 ms, user CSE 6210 ms / 53 ms, `total_boot_duration_ms` 28394. Two independent derivations agreeing is what establishes the offset extraction is faithful. Confirmed by that boot: - **Nesting holds on real data.** Machine CSE [8058, 8185] sits inside `computer_group_policy` [7308, 8221]; user CSE [6210, 6263] inside `user_group_policy` [5956, 6274] — both after a 35215 ms gap collapse. This is the property `TestCSEOffsetsShareTheBootTimelineAxis` locks. - **Activity-ID scoping works as designed.** Three distinct activity IDs: the computer pass carrying 4000/5312/4016/5016/8000 on one thread, the user pass carrying 4001/5312/4016/5016/8001 on another, and **the zero GUID on 16 service-lifecycle events outside any pass** (including both occurrences of 4117). No CSE event carried an activity matching no pass. Refusing the zero GUID is confirmed necessary a second time. - **All four pass boundaries present**, each pass on its own activity ID and its own thread, which is what start-only pinning needs. - **A real non-boot refresh pass is observed being excluded** — on the earlier trace, not this one. It carries a **4004/8004 pair triggered over RPC by a third-party service**, with event 5321 recording the attribution verbatim: `Group Policy refresh via RPC. Target=Machine ParentProcess=\"…\\services.exe\" RpcClient=\"…\\lenovo\\UDC\\Service\\UDClientService.exe\" Account=\"NT AUTHORITY\\SYSTEM\"`. Re-running the analyzer over it, the refresh pass is absent from the payload. So the 4002–4007 exclusion has observational backing and not only a synthetic test. - The measured 4016→terminal interval tracks the provider's own `CSEElaspedTimeInMilliSeconds` within one timer tick: 127 vs 140 and 53 vs 46 here, 62.4 vs 63 and 46.7 vs 47 elsewhere. `TimerResolution` on this trace is 15.625 ms, which accounts for the spread. **2. A `logman` + `gpupdate /force` capture** at the identical provider GUID, keyword and level, to settle the `ApplicableGPOList` format without waiting for a boot. This is what produced the format finding and the unescaped-ampersand finding above. It also observed `IsExtensionAsyncProcessing=true` in the wild (the Security CSE), which the boot capture does not contain. **3. An earlier Agent-captured ETL** (1.4 MB, 10,017 events, 32 Group Policy events) read alongside the `Microsoft-Windows-GroupPolicy` manifest via `ProviderMetadata`. This is the trace whose mixed `IsMachine` renderings made scope-from-event-ID look justified — and the manifest now explains why they differ rather than leaving it a quirk: **4000/4001, 4002–4007 and 8000–8007 each ship a version 0 and a version 1 template, and `IsMachine` is `win:Boolean` in v0 but `win:UInt32` in v1.** On the validation boot all four boundary events are v1 and it reads a perfectly consistent `1/0/1/0`. Deriving scope from the event ID is still right, but because the field is version-dependent, not because it is unreliable. Two further claims previously made about this trace are **retracted**: it does not carry 8001 without 4001, per Attribution above, and its computer pass did not fail — `ErrorCode` is `0` on both 8000 and 8004, and no property anywhere in the trace equals 1355. It does carry two 5312 events, both with an empty `GPOInfoList`. `group_policy_details` is correctly absent, but because the trace contains no 4016 at all. None of the ETLs are committed as fixtures: they carry machine names, a domain, and user SAM names. **Unit tests.** `grouppolicy_test.go` drives synthetic events through the real `processEvent` dispatch, feeding the mock the exact strings TDH produces for each declared out-type. Six guard the attribution rules specifically: `TestPassStopAloneNeverPins` proves a pass stop event cannot pin a scope by itself, `TestZeroActivityIDNeverPins` guards the zero-GUID sweep, `TestPassActivityIsNotSharedBetweenScopes` stops one activity being emitted under both, `TestCSEWithNoBootPassIsOmitted` proves an unmatched activity is dropped rather than charged to the most recent pass, `TestGPUpdateInvocationsAreExcluded` proves a `gpupdate` CSE stays out of the boot pass, and `TestCSEOffsetsShareTheBootTimelineAxis` locks an invocation inside its parent milestone with a login-screen gap present. `TestGPONamesSurviveUnescapedAmpersand` and two new table rows in `TestGPORefsFromList` cover the escaping fix, in both the first and mid-list positions — reverting `decoder.Strict = false` fails all four with the three distinct symptoms described above. `TestInvocationBackstopKeepsTheLeastHealthyAndTheSlowest` locks the retention order against the chronological sort. `TestBuildTimelineMilestones` passes **unmodified**, which is what proves `bootOffsetFunc` is a faithful extraction. `dda inv test --targets=./comp/logonduration/impl` — 149 passing, none failing, none skipped. `dda inv linter.go` clean on both `./comp/logonduration/impl` and `./pkg/util/winutil/etw`. Writing the tests caught a real bug independently of the captures: dropping the XML tier in favour of a pure braced-GUID scan silently harvested the CSE GUID out of a 5312-shaped entry's `<Extensions>` element and reported it as an applicable GPO. ### Additional Notes **`error_code` is removed, and the field set is now deliberate rather than incidental.** Earlier revisions carried the provider's status on each invocation. It is gone. The block reports what ran inside a pass and for how long; *why* an extension failed is a Group Policy health question, and it is the only annotation here a consumer can recover elsewhere — the code is in the host's own Group Policy Operational log, whereas `result` and `async` exist nowhere but this payload and both govern how `duration_ms` must be read. Removing it also retires a wire contract that existed solely to carry it: a hex string rather than a JSON number, parsed base 0 because the property is declared `win:HexInt32`, so that a status above `0x7FFFFFFF` does not round-trip as a negative signed integer. A fleet-level view of *which* status a slow pass failed with is worth having, but it is a different feature from a CSE→GPO latency breakdown and belongs in its own PR with its own release note. The two fields that stay are load-bearing, not decoration. `result` is nearly free — 5016/6016/7016 have to be accepted regardless, because a CSE that ends in warning or error still consumed wall-clock time inside the pass, and without its terminal event its start is never closed and the invocation is dropped at `finalize`. Given the dispatch already switches on the ID, the outcome is a byproduct; dropping the field while keeping the events would render a 45 s invocation that timed out identically to a 45 s invocation that did work. `async` redefines the primary number: when `IsExtensionAsyncProcessing` is set the terminal event marks worker-thread dispatch, so `duration_ms` is the cost of the dispatch and not of the extension's work. The stop events still carry `ErrorCode` and the synthetic ones in the tests still populate it — now with a non-zero E_PENDING, so every test that asserts on an emitted invocation also proves the field does not leak back into it. `TestCSEPairingOutcomes` gains meaning from that: a 5016 carrying a non-zero status still reports `success`, because the event ID is what is read. The release note is unchanged, having always described the block as offset, duration, and outcome. Also incidental: a merge of `main` left this package's tests not compiling, because `newPayloadTestComponent` was still passing the `compression` argument #54480 removed. Fixed here. **Four pre-existing bugs the captures exposed**, each left for its own PR because each moves an already-shipped number and deserves its own release note: 1. Pass endpoints are first-write-wins per event ID with no ActivityID pairing, so a start from one processing instance can pair with an end from another. The activity table makes the *children* consistent; the parent duration is still unpaired. 2. Both Group Policy milestones key off the **start** event alone, so a trace carrying only 8000 or only 8001 discards the endpoint it does have and drops the milestone and its `durations` entry silently. Latent rather than observed — the 8001-without-4001 shape that first motivated this is the one retracted above, and neither capture actually contains it. It is still a real hole, and it is the same first-write-wins-with-no-pairing weakness as bug 1. 3. `offset_ms` is non-monotonic for a milestone inside the collapsed login-screen gap, and this now reproduces on two traces with different numbers. On the earlier one `computer_group_policy` is at 19859 ms while the later `logon_duration` is at 9984 ms; on the boot trace `computer_group_policy` at 7308 ms lands after both `user_group_policy` at 5956 ms and `logon_duration` at 5687 ms. The machine pass falls inside the gap but is `Before(SessionLogon)`, so it escapes the subtraction while everything after logon is pulled left. 4. **New:** the boot trace carries **two** Winlogon 103/104 pairs, and first-write-wins takes the 11 ms pair over the 112 ms pair that follows it 5 s later. That choice sets the gap to 35215 ms instead of 30259 ms and is what amplifies bug 3 on this trace — with the second pair the inversion disappears. It also changes `login_ui_start.duration_ms` from 11 to 112, so picking the right pair is a shipped-number change in its own right. Separately, `boot_timeline` is emitted in the source order of a hardcoded candidate list and never sorted by `offset_ms`, so `logon_duration` precedes `user_group_policy` in the array while trailing it in time. That one is structural rather than trace-dependent. 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
          "url": "https://github.com/DataDog/datadog-agent/pull/54546",
          "createdAt": "2026-08-07T01:10:23Z",
          "updatedAt": "2026-08-12T20:40:44Z",
          "timestamp": "2026-08-12T20:40:44Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "qa/done",
            "long review",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "briantu",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:ffc4ab3c40dd0ea52bc7",
        "signalId": "github:DataDog/datadog-agent:pull_request:54797",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54797",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Sign macos DMG only on nightly instead of main",
          "text": "### What does this PR do? Stops doing real signing and notarization of Macos DMG packages on main. Do it on nightly only so we maintain some testing of the process. ### Motivation We should not be creating notarized, installable packages off of main. That creates artifacts which could appear to be end-user consumable, but are not supported, nor necessarily validated. Ideally we should only do this on the release branches. We'll address that once we convert the build to bazel. ### Describe how you validated your changes CI ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54797",
          "createdAt": "2026-08-12T19:48:33Z",
          "updatedAt": "2026-08-12T20:38:28Z",
          "timestamp": "2026-08-12T20:38:28Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "team/agent-build",
            "internal"
          ],
          "author": "aiuto",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:b9d5c17c80d5d57c89a0",
        "signalId": "github:DataDog/datadog-agent:pull_request:54603",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54603",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add allowlist for valid conntrack_path values",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Validate `conntrack_path` configuration values are acceptable before initializing the network check to collect metrics from the tool. The allowed values are what we have seen configured for this feature. ### Motivation ### Describe how you validated your changes * unit tests ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54603",
          "createdAt": "2026-08-07T22:19:55Z",
          "updatedAt": "2026-08-12T20:37:02Z",
          "timestamp": "2026-08-12T20:37:02Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "long review",
            "team/agent-integrations",
            "team/agent-runtimes",
            "internal"
          ],
          "author": "jeremy-hanna",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:4ba798938b62bbdcdc2f",
        "signalId": "github:DataDog/datadog-agent:pull_request:54653",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54653",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[release] Update last stable to 7.82.1",
          "url": "https://github.com/DataDog/datadog-agent/pull/54653",
          "createdAt": "2026-08-10T15:43:20Z",
          "updatedAt": "2026-08-12T20:34:45Z",
          "timestamp": "2026-08-12T20:34:45Z",
          "metrics": {
            "reactions": 2,
            "comments": 6
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "team/agent-delivery",
            "short review",
            "team/agent-integrations",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "temporal-github-worker-1[bot]",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:f7a6b741a2272d1a3af7",
        "signalId": "github:DataDog/datadog-agent:pull_request:54549",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54549",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add BUILD files for some straggler test tools",
          "text": "### What does this PR do? Create build files for some non-product manual test tools. ### Motivation They are not on any critical path, but we're adding the BUILD files for completeness.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54549",
          "createdAt": "2026-08-07T04:50:57Z",
          "updatedAt": "2026-08-12T20:32:12Z",
          "timestamp": "2026-08-12T20:32:12Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "qa/no-code-change",
            "medium review",
            "team/agent-build",
            "internal"
          ],
          "author": "aiuto",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:eafd7a8cf81ca8ca7ffc",
        "signalId": "github:DataDog/datadog-agent:pull_request:54662",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54662",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "add BUILD file for pkg/network/usm/debugger/cmd",
          "text": "### What does this PR do? - Add BUILD file for pkg/network/usm/debugger/cmd - Remove the go tags ### Motivation Cleanup and doing the last .1% of the migration. ### Describe how you validated your changes ``` # bazel run //pkg/network/usm/debugger/cmd:usm_debugger ... INFO: Build completed successfully, 1 total action INFO: Running command line: /root/.cache/bazel/_bazel_root/81a15fa9a2846e82038a778136785275/execroot/_main/bazel-out/aarch64-fastbuild-ST-9207cf685fa6/bin/pkg/network/usm/debugger/cmd/usm_debugger_/usm_debugger 2026-08-10 17:08:14 UTC | usm-debugger | DEBUG | (pkg/network/usm/debugger/cmd/ebpf_bytecode.go:52 in setupBytecode) | writing ebpf bytecode to /tmp/co-re/usm-debug.o 2026-08-10 17:08:14 UTC | usm-debugger | DEBUG | (pkg/network/usm/debugger/cmd/ebpf_bytecode.go:52 in setupBytecode) | writing ebpf bytecode to /tmp/co-re/shared-libraries-debug.o ... ``` ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54662",
          "createdAt": "2026-08-10T17:13:52Z",
          "updatedAt": "2026-08-12T20:30:49Z",
          "timestamp": "2026-08-12T20:30:49Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "qa/no-code-change",
            "medium review",
            "ask-review",
            "team/agent-build",
            "internal"
          ],
          "author": "aiuto",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:61f42859d1b707c76c0a",
        "signalId": "github:DataDog/datadog-agent:pull_request:54478",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54478",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[release] Update last stable to 7.82.0",
          "url": "https://github.com/DataDog/datadog-agent/pull/54478",
          "createdAt": "2026-08-05T15:03:55Z",
          "updatedAt": "2026-08-12T20:30:33Z",
          "timestamp": "2026-08-12T20:30:33Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "team/agent-delivery",
            "short review",
            "team/agent-integrations",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "temporal-github-worker-1[bot]",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:c2dbc777ccea6da7c521",
        "signalId": "github:DataDog/datadog-agent:pull_request:54435",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54435",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[AAD-23] Remove unused correlators",
          "text": "### What does this PR do? This PR cleans up unused Observer correlators. - removes the disabled `cross_signal` correlator - moves `passthrough` out of the production catalog and keeps it as a testbench-only adapter for raw-anomaly evaluation ### Motivation Neither correlator is used in production. `cross_signal` only recognizes three fixed source combinations, while `passthrough` is only needed to expose raw anomalies during testbench evaluation. ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54435",
          "createdAt": "2026-08-04T18:13:08Z",
          "updatedAt": "2026-08-12T20:29:37Z",
          "timestamp": "2026-08-12T20:29:37Z",
          "metrics": {
            "reactions": 0,
            "comments": 6
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "long review",
            "team/agent-build",
            "internal",
            "team/fleet-automation"
          ],
          "author": "Eokye",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:5f83be8e8d01cd1c0517",
        "signalId": "github:DataDog/datadog-agent:pull_request:54168",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54168",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "refactor(fleet): make procmgr an independent Linux service manager",
          "text": "### What does this PR do? Makes `procmgr` (`dd-procmgrd`) a first-class Linux service manager in the fleet installer, peer to systemd / upstart / sysvinit, instead of a systemd sub-unit that the installer cannot reason about. - New `service.ProcmgrType`, selected when the init system is systemd, `dd-procmgrd` is installed, and the operator has not opted out. New `pkg/fleet/installer/packages/service/procmgr` package whose unit-level verbs delegate to `systemd`, so no `ProcmgrType` branch calls `systemd.*` directly. - `agentService` gains a flat `Procmgr*` field group mirroring the existing `Upstart*`/`Sysvinit*` pairs, and every service-manager `switch` gains a `case service.ProcmgrType:`. `SystemdUnits*` drops `datadog-agent-procmgr.service`, so `systemd` means plain systemd again. - **Two generated unit trees**: `tmpl/gen/{systemd,procmgr}/<flavor>/`, each with its own `Wants=`. This is what makes the managers independent at the artifact level, and it replaces the `ConditionPathExists=!.../processes.d/datadog-agent-ddot.yaml` gate that had a systemd unit inspecting procmgr's state directory. New `embedded.GetProcmgrUnit` / `GetProcmgrConfig`. - The DDOT extension hooks stop touching procmgr configs entirely, and `writeDDOTProcmgrConfig`/`removeDDOTProcmgrConfig` are deleted. Process definitions are shipped unconditionally from `ProcmgrProcesses*`, exactly like units: `condition_path_exists` decides whether the payload runs, the same way `ConditionPathExists=` does for `datadog-agent-security.service`. ### Motivation From the installer's point of view procmgr was invisible: `agentService.SystemdUnitsStable` listed both `datadog-agent-ddot.service` and `datadog-agent-procmgr.service`, `datadog-agent.service` wanted both supervision paths, and mutual exclusion lived in a unit-file condition. The DDOT `processes.d` config was written from `postInstallDatadogAgent` outside the abstraction — and *not* written by `postStartExperiment`/`postPromoteExperiment`, which relied on the extension hook firing indirectly. That combination made classic-systemd/procmgr interactions hard to reason about and left no way to opt out on Linux. ### Describe how you validated your changes New tests, aimed at the invariants this design rests on: - `SystemdUnits*` contains no `-procmgr` unit and `ProcmgrUnits*` no `-ddot` unit; every name in each array resolves in its own generated tree for all four flavors (both write paths hard-fail on a missing embed, so drift would otherwise surface only at install time). - The generated `datadog-agent.service` `Wants=` matches the tree's array — the guarantee that replaced the deleted `ConditionPathExists=!` gate. - `procmgrInstallRoot` matches `DD_PM_CONFIG_DIR` in the generated procmgr units, for every package type and lifecycle half. This spans a Go helper and a generated unit, and nothing enforced it before; verified by injecting drift and confirming the test fails. Manual review of the generated trees: procmgr tree only defines datadog-agent.service with the specific Wants= sub-service that includes procmgr.service and excludes ddot.service. The yaml processes configuration are generated outside the platform scope: does depend on the platform only the package.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54168",
          "createdAt": "2026-07-28T14:14:25Z",
          "updatedAt": "2026-08-12T20:29:15Z",
          "timestamp": "2026-08-12T20:29:15Z",
          "metrics": {
            "reactions": 0,
            "comments": 4
          },
          "labels": [
            "qa/done",
            "long review",
            "team/container-integrations",
            "team/agent-runtimes",
            "team/agent-devx",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "Stanislas167",
          "state": "open",
          "assignees": [
            "Stanislas167"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:0fd6eaec76188f5443c8",
        "signalId": "github:DataDog/datadog-agent:pull_request:54761",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54761",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[Backport 7.83.x]  feat(wls): add K8S target through Remote Config",
          "text": "Backport 34e4e15f4654a23d43208c68be99fb2dd67ad4e9 from #54476. ___ feat(autoinstrumentation): wire remote-config SSI policies Subscribe the Cluster Agent auto-instrumentation webhook to the APM_POLICIES remote-config product and layer the delivered SSI policies on top of the configuration baseline at runtime. - TargetMutator now holds a base policy set plus an atomically swappable active set, so remote policies can be hot-reloaded without locking. - Remote policies take precedence over configuration targets (first-match-wins) and support explicit injection denies. - rc_policies.go parses the dd-wls document via dd-policy-engine and applies or clears policies on each remote-config update. This also add a SubscribeWithInitialConfig in RC Client to avoid a potential datarace between registration, initial config and first update if done without a mutex.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54761",
          "createdAt": "2026-08-12T08:04:00Z",
          "updatedAt": "2026-08-12T20:26:13Z",
          "timestamp": "2026-08-12T20:26:13Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "team/remote-config",
            "qa/done",
            "backport",
            "bot",
            "team/container-platform",
            "long review",
            "team/injection-platform",
            "team/agent-build",
            "internal"
          ],
          "author": "dd-octo-sts[bot]",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:5f902bd90c9b2fc83bd7",
        "signalId": "github:DataDog/datadog-agent:pull_request:54796",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54796",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "test(network/usm): run the USM and classification suites on the fentry tracer",
          "text": "### What does this PR do? Runs the USM and protocol-classification test suites against the **fentry** connection tracer, which they previously never exercised. Fentry was absent from `usmtestutil.SupportedBuildModes`, and four separate gates short-circuited on it even when it was selected: | Gate | Old behavior on fentry | |---|---| | `httpSupported()` / `httpsSupported()` (`usm/tests`) | returned `false` → suites skipped | | `setupTracer` (`tracer_classification_test.go`) | force-disabled `ProtocolClassificationEnabled` | | `TestTLSClassification` | `t.Skip(\"protocol classification not supported for fentry tracer\")` | | `httpSupported()` (`pkg/network/tracer`) | returned `false` → `TestGetStats` waived its `usm` telemetry assertion | The hardcoded gates are replaced with real capability queries: `classificationSupported` now dispatches to the fentry or kprobe tracer as appropriate. To make that possible, `fentry.classificationSupported` is exported as `ClassificationSupported`, matching `kprobe.ClassificationSupported` (first commit; no behavior change). Fentry eligibility in `usmtestutil.SupportedBuildModes` is delegated to `ebpftest.SupportedBuildModes()` rather than re-derived, since that gate (kernel floor / RCU-deadlock symbol boundary / `TEST_FENTRY_OVERRIDE`) is subtle and has regressed before when copied. Note that \"Fentry\" here selects the fentry *connection tracer* while `usm.o` still loads as CO-RE — `usm.o` has no fentry variant and needs none. ### Motivation Part of the fentry tracer cleanup and validation effort. The fentry tracer supports protocol classification in production, but no USM test ever ran against it, so that support was entirely unverified — a silent coverage hole rather than a known gap. ### Describe how you validated your changes Run on ubuntu-24 / 6.8.0-86 with `TEST_FENTRY_OVERRIDE=true` (this kernel carries the AUTOSEL backport of the RCU-exit deadlock fix, so it runs fentry despite being below the `kv >= 6.9` test gate). - **`TestUSMSuite/fentry`** — all 7 suite methods pass, across 3 full-suite runs. - **`TestTracerSuite/fentry`** — 109 pass, 5 skip, 0 fail. - **`TestGetStats/fentry`** — now *asserts* the `usm` telemetry section on fentry instead of waiving it, and passes on both `ebpf_conntracker` variants. This is a strictness increase, and it confirms fentry genuinely populates usm telemetry. **Skip audit.** All 27 skips across both suites were checked against their source conditions and are build-mode independent — unconditional \"flaky\" skips on the TLS variants, `skipIfUsingNAT` on the DNAT group, kernel-version and host-performance gates. The single exception is `TestKprobeAttachWithKprobeEvents`, which skips on fentry; see Additional Notes. **One flaky failure, investigated and cleared.** An initial run failed `without_nat/kafka/fetch_v11`. Measured over 9 further runs: | Scope | Runs | Failures | |---|---|---| | `without_nat/kafka` isolated | 4 | 0 | | `TestProtocolClassification` in-group | 3 | 0 | | full `TestUSMSuite/fentry` | 3 | 1 | Load-dependent, disappears under a narrower `-run` filter, and the failing Kafka API version varies run to run (v9/v11/v14/v16 all observed) — matching this test's known pre-existing flakiness on this VM across build modes. Not attributable to this change. It is not currently in `flakes.yaml`. ### Additional Notes `TestKprobeAttachWithKprobeEvents` still skips on fentry, and this PR deliberately leaves it that way. The reason is a **pre-existing production gap**: `AttachKprobesWithKprobeEventsABI` is silently ignored on the fentry path, because `initFentryTracer` never sets `DefaultKprobeAttachMethod` on its manager options, so the manager falls back to `AttachKprobeWithPerfEventOpen`. Fentry does retain 3 kprobes (`tcp_enter_loss`, `tcp_enter_recovery`, `tcp_send_probe0`), so the setting is meaningful there. Fixing it is a production change tracked separately and out of scope for this test-enablement PR.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54796",
          "createdAt": "2026-08-12T19:22:36Z",
          "updatedAt": "2026-08-12T20:25:56Z",
          "timestamp": "2026-08-12T20:25:56Z",
          "metrics": {
            "reactions": 2,
            "comments": 6
          },
          "labels": [
            "component/system-probe",
            "medium review",
            "team/agent-build",
            "team/cloud-network-monitoring",
            "internal"
          ],
          "author": "jmw51798",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:7c1b63ab682e6eb68036",
        "signalId": "github:DataDog/datadog-agent:pull_request:54592",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54592",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] add par-control OPMS client",
          "text": "### What does this PR do? Adds the authenticated OPMS client used by `par-control`: - Signs requests with runner JWT authentication. - Dequeues workflow tasks. - Publishes terminal task outcomes. - Sends task heartbeats. - Performs runner health checks. - Matches the existing Go wire contracts, proxy behavior, TLS settings, and retry pacing. The implementation and its HTTP/TLS contract tests are kept together in this layer. ### Motivation Separate the remote OPMS protocol from local executor communication and from the orchestration policy that composes them. ### Validation - 46 portable Rust tests pass locally. - Three native-tls tests require Linux/Windows and do not run successfully with the macOS Security Framework backend. ### Stack PR 6 of 9. Based on #54591; followed by #54593.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54592",
          "createdAt": "2026-08-07T17:51:46Z",
          "updatedAt": "2026-08-12T20:25:17Z",
          "timestamp": "2026-08-12T20:25:17Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:817d5ffc692896f8cfcc",
        "signalId": "github:DataDog/datadog-agent:pull_request:54547",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54547",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "macos: notable-events collector health stats",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? [MacOS] Implement health stats for notable-events collector so operators can diagnose a stalled or saturated collector from a flare. ### Motivation This is follow-up of PR #54084. ### Describe how you validated your changes Inspect the heath stats with local tests and ensure CI pipeline passes. Commands used for validation: agent status agent status -j | jq '.systemProbeStats.notable_events' ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54547",
          "createdAt": "2026-08-07T01:26:07Z",
          "updatedAt": "2026-08-12T20:25:16Z",
          "timestamp": "2026-08-12T20:25:16Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/ebpf-platform",
            "qa/done",
            "long review",
            "ask-review",
            "team/agent-build",
            "team/windows-products",
            "internal",
            "team/fleet-remediation"
          ],
          "author": "guohdd",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:2725b5d12f7a4be425b3",
        "signalId": "github:DataDog/datadog-agent:pull_request:54590",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54590",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] add par-control effective configuration",
          "text": "### What does this PR do? Adds the effective configuration and identity bootstrap layer for `par-control`: - Adds a Go helper subcommand that exports the Agent's resolved configuration. - Loads split-runner configuration from Rust. - Resolves local and Fleet-managed settings consistently. - Loads and persists runner identity. - Supports self-enrollment bootstrap. - Adds the required schema and setup wiring. Configuration production and consumption stay together in this PR so their contract can be reviewed as one behavior. ### Motivation Give the control process the same effective configuration as the Agent without duplicating configuration precedence or persisting a second plaintext configuration snapshot. ### Validation - Focused Go tests pass locally. - Portable Rust tests pass locally. - Relevant Go and Rust builds pass locally. ### Review fixes - **Process-manager socket**: falls back to dd-procmgrd's own `DD_PM_SOCKET_PATH` when `private_action_runner.procmgr_socket_path` is unset, before the platform default. Previously, relocating the daemon's socket also required setting a second, PAR-specific value. Resolution goes through the injected env lookup so it is testable without mutating process state, and an empty setting is treated as unset like the executor socket. - Carries the RPC deadlines, the `wait_for_failure` semantics, and the fake-daemon tests into the injected-socket `ProcmgrLifecycle` introduced here. - Same program-data-root log path, so the Windows log location no longer depends on where `--config` points. `platform.rs` also takes over the fleet-policies-dir registry lookup that was inline here. ### Stack PR 4 of 9. Based on #54589; followed by #54591.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54590",
          "createdAt": "2026-08-07T17:47:32Z",
          "updatedAt": "2026-08-12T20:24:36Z",
          "timestamp": "2026-08-12T20:24:36Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "team/action-platform",
            "internal",
            "team/fleet-automation"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:3c681c295b6dbe760268",
        "signalId": "github:DataDog/datadog-agent:pull_request:54594",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54594",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] wire split runner ownership",
          "text": "### What does this PR do? Teaches the existing Go runner and Fx component to stand down when split mode is enabled on supported Linux and Windows host deployments, while retaining the executor subcommand used by `par-control`. Container deployments do not yet launch the replacement topology. Official Agent containers are detected through `configenv.IsContainerized()` (`DOCKER_DD_AGENT`), so a requested split deployment logs a warning and safely continues with the monolithic runner instead of black-holing PAR. Cluster Agent continues to use its existing in-process monolithic path. The resulting ownership invariant is explicit: exactly one process polls OPMS, and the monolith exits only when its replacement topology is available. ### Motivation Keep runner ownership and activation behavior separate from package and installer mechanics so reviewers can focus on preventing both duplicate polling and unsupported deployments standing down their only runner. ### Validation - `bazel test //comp/privateactionrunner/impl:impl_test` passes locally. - Focused coverage includes Linux and Windows hosts, Linux and Windows containers, and an unsupported host platform. - Private Action Runner build passes locally. ### Review fixes - Documented `idle_timeout_seconds`, which now drives two mechanisms: par-control stops an idle executor after this long, and the executor exits by itself after a longer multiple, which is what reclaims it when par-control is no longer running. - Documented that `procmgr_socket_path` falls back to the process manager's own `DD_PM_SOCKET_PATH` when unset. ### Stack PR 8 of 9. Based on #54593; followed by #54529.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54594",
          "createdAt": "2026-08-07T18:09:51Z",
          "updatedAt": "2026-08-12T20:24:35Z",
          "timestamp": "2026-08-12T20:24:35Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "medium review",
            "team/agent-build",
            "team/action-platform",
            "internal",
            "team/fleet-automation"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:0670aa116187f9d65be1",
        "signalId": "github:DataDog/datadog-agent:pull_request:54593",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54593",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] orchestrate par-control tasks",
          "text": "### What does this PR do? Composes the process manager, effective configuration, OPMS client, and executor channel into the production `par-control` loop: - Adds bounded task concurrency and retry policy. - Leaves the executor stopped while idle and starts it only after a task is dequeued. - Starts task heartbeats at dequeue and continues them through executor cold start, key synchronization, execution, and terminal publication. - Sends runner liveness reports independently of task flow. - Lazily synchronizes and caches signing keys for later executor starts. - Stops the executor after the configured idle period and drains in-flight work during shutdown. - Wires the final binary and updates its documentation. - Restores Windows compatibility for the Rust Bazel test by staging the Agent OpenSSL DLLs in runfiles and placing that directory on the test process's `PATH`. ### Motivation Keep orchestration policy separate from the independently tested lifecycle and network primitives it coordinates. In particular, the control process should preserve an OPMS lease while paying the executor's cold-start cost and should not keep the higher-RSS Go process alive when no work is available. ### Validation - `dda env dev run -- bazel test //pkg/privateactionrunner/par-control:par-control_test` - `dda env dev run -- env -u PKG_CONFIG_LIBDIR cargo clippy --manifest-path pkg/privateactionrunner/par-control/Cargo.toml --all-targets -- -D warnings` - Buildifier passes. - Windows-target Bazel analysis confirms both OpenSSL DLLs are inputs to the staging action. - Full Windows Rust execution is delegated to Windows CI. ### Review fixes - **No startup prewarming**: the executor remains stopped until a task is leased. Signing keys are synchronized during the first cold start and cached for later starts. - **Lease protection during cold start**: task heartbeats begin immediately after dequeue and stop only after terminal publication, covering process startup, readiness, and key synchronization. - **Start race**: dd-procmgrd rejects `Start` for every state covered by `ProcessState::is_alive()` (`Starting`, `Running`, and `Stopping`). Those states and a lost `Start` race are now adopted instead of failing the task spuriously. - **Windows graceful shutdown**: `par-control` listens for `CTRL_BREAK`, which is the event dd-procmgrd sends to Windows children, so shutdown drains work instead of waiting for the process-manager timeout and job-object kill. - **Bounded process-manager calls**: dispatch-path `Describe` and `Start` RPCs have deadlines, allowing a leased task to fail and publish an outcome instead of hanging without heartbeats. - **Windows logging and defaults**: restores the program-data-root log path, `ExitCode`, and the platform-correct `--config` default. - **Clean executor exits**: idle self-termination from #54670 remains non-fatal, so `restart: on-failure` does not immediately respawn the executor. - Tests cover stopped-at-start behavior, heartbeat timing through cold start and publication, adoption of `Starting`/`Running`/`Stopping`, tolerated start races, RPC deadlines, idle stop, drain behavior, and vanished process definitions. ### Stack PR 7 of 9. Based on #54592; followed by #54594.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54593",
          "createdAt": "2026-08-07T17:53:19Z",
          "updatedAt": "2026-08-12T20:24:17Z",
          "timestamp": "2026-08-12T20:24:17Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:c8570eb87e5aced5f241",
        "signalId": "github:DataDog/datadog-agent:pull_request:54589",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54589",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] add par-control process lifecycle",
          "text": "### What does this PR do? Adds the process-lifecycle layer for `par-control`: - Uses the shared `dd-procmgr-client` for local IPC on Linux and Windows. - Loads the minimal configuration needed to gate split mode. - Starts or adopts the executor, monitors its state, and exposes start/stop operations for later orchestration layers. - Handles process-manager failures, RPC deadlines, and platform-specific shutdown and logging. - Tests the lifecycle against an in-process fake `dd-procmgrd`. Clean executor exits are treated as normal idle shutdown. During its own shutdown, `par-control` does not call back into `dd-procmgrd`, which may already be waiting for it to exit. Effective configuration loading, OPMS polling, and action dispatch are added in later PRs. ### Validation - `dda env dev run -- bazel test //pkg/privateactionrunner/par-control:par-control_test` - `dda env dev run -- env -u PKG_CONFIG_LIBDIR cargo clippy --manifest-path pkg/privateactionrunner/par-control/Cargo.toml --all-targets -- -D warnings`",
          "url": "https://github.com/DataDog/datadog-agent/pull/54589",
          "createdAt": "2026-08-07T17:44:51Z",
          "updatedAt": "2026-08-12T20:22:31Z",
          "timestamp": "2026-08-12T20:22:31Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:edc35440a2c7a3db7a07",
        "signalId": "github:DataDog/datadog-agent:pull_request:54591",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54591",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] add par-control executor channel",
          "text": "### What does this PR do? Defines the local control-to-executor channel and implements both ends of it: - Adds the executor gRPC protocol and generated bindings. - Exposes executor health and readiness. - Synchronizes workflow signing keys. - Streams action dispatch outcomes. - Adds the Rust mTLS client and transport support. - Keeps the shared terminal `Outcome` model with the executor layer. This layer provides communication primitives only; polling and process-lifecycle policy remain in later layers. ### Motivation Create a narrow, authenticated local contract between `par-control` and the existing Go executor before introducing OPMS polling or orchestration. ### Validation - Focused Go tests pass locally. - Private Action Runner Go build passes locally. - Portable Rust tests pass locally; native-tls identity coverage requires Linux/Windows. ### Review fixes - **Transport**: 5s connect timeout on both the plain and the mTLS channel, and no panic path in the named-pipe retry loop. Also corrects module docs that claimed Windows named-pipe support was a follow-up while the named-pipe client sits in the same file. - Dropped the redundant `tokio-stream` dev-dependency, since this layer promotes it to a regular dependency. - README records the build caveats: the dev VM's empty `PKG_CONFIG_LIBDIR` breaks `openssl-sys` under cargo, proto-touching changes must be Bazel-verified (under `--cfg=bazel` the bindings come from a separate crate, so the orphan rule differs), and the TLS tests are Linux-only. ### Stack PR 5 of 9. Based on #54590; followed by #54592.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54591",
          "createdAt": "2026-08-07T17:50:14Z",
          "updatedAt": "2026-08-12T20:22:19Z",
          "timestamp": "2026-08-12T20:22:19Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:15f96f1e35bf0c7e13b8",
        "signalId": "github:DataDog/datadog-agent:pull_request:54529",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54529",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] package and activate par-control",
          "text": "### What does this PR do? Packages and activates `par-control` on Linux and Windows: - Adds Agent package and installer wiring. - Installs process-manager definitions for `par-control` and the executor. - Adds Windows executable resources and MSI integration. - Preserves a standard service `PATH` for Unix process-manager children. - Adds Linux and Windows split-runner lifecycle E2E suites and CI jobs. Runner ownership is handled by the preceding layer. Split activation is intentionally limited to supported host deployments; Docker and Kubernetes containers continue running monolithically until their three-process topology is implemented. This PR contains only host packaging, activation, and end-to-end coverage. ### Motivation Ship the split runner consistently across supported installation paths and verify its process lifecycle on both Linux and Windows. ### Validation - Installer package tests pass locally. - Buildifier passes for the affected Bazel definitions. - Linux and Windows split-runner E2E execution is delegated to CI. ### Stack PR 9 of 9. Based on #54594.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54529",
          "createdAt": "2026-08-06T16:54:57Z",
          "updatedAt": "2026-08-12T19:59:03Z",
          "timestamp": "2026-08-12T19:59:03Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/container-integrations",
            "team/agent-runtimes",
            "team/agent-devx",
            "team/agent-build",
            "team/windows-products",
            "team/action-platform",
            "internal",
            "team/fleet-automation"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:54889910abf271bde6dd",
        "signalId": "github:DataDog/datadog-agent:pull_request:54795",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54795",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "test(ndm): add e2e coverage for Agent Workload Balancing",
          "text": "> **Note:** This PR was created by Claude. ### What does this PR do? Adds the e2e test suite for Agent Workload Balancing that was called out as needed in #54652's original plan, and adds the one missing CLI surface found while auditing that plan for completeness. - `TestWorkloadBalancingRunningMetrics` / `TestWorkloadBalancingAddedToRCListeners` (`workloadbalancing_test.go`): mirrors `haagent_test.go`. Pushes an `NDM_AGENT_WORKLOAD_BALANCING` Remote Config payload via `RCAddConfig` against fakeintake, then asserts `datadog.agent.workload_balancing.running` (tagged `workload_balancing_group`/`workload_balancing_state`) and the `\"Add workload balancing RCListener\"` log line. - `TestWorkloadBalancingMetadata` (`workloadbalancing_metadata_test.go`): mirrors `haagent_metadata_test.go`. Pushes an RC assignment, then reads it back via `diagnose show-metadata workload-balancing`. - `cmd/agent/subcommands/diagnose/command.go`: adds the `show-metadata workload-balancing` subcommand. #54659 wired the metadata provider into inventory, flare, status, and the `/metadata/workload-balancing` HTTP endpoint, but left out the CLI subcommand that HA Agent has as `show-metadata ha-agent`. The metadata e2e test above needs it to read the payload the same way the HA Agent test does. - `.gitlab-ci.yml` / `.gitlab/test/e2e/e2e.yml`: adds a `new-e2e-workload-balancing` job and its change-triggering rule, following the `ha-agent` job pattern. - `.github/CODEOWNERS`: adds `/test/new-e2e/tests/workload-balancing`. ### Motivation This was the fourth piece of the originally planned agent-side work (component, metric, inventory metadata, e2e test), deferred because it was \"blocked on #53246 for Remote Config fakeintake support.\" That PR merged, so the blocker is gone. Not included here: a multi-host failover test analogous to `haagent_failover_test.go` (driving an actual handoff between two hosts). Left as a follow-up TODO in `workloadbalancing_test.go` rather than adding a large multi-VM test to this PR. ### Describe how you validated your changes - `go vet ./tests/workload-balancing/...` in `test/new-e2e` passes. - `gofmt` clean on all changed/added files. - Base branch merges (`mleese/ndm-device-handoff` + `mleese/ndm-workload-balancing-metric` + `mleese/ndm-workload-balancing-metadata`) were clean, no conflicts. - Not yet run against real infra (draft; depends on #54652, #54656, #54659 landing first). ### Additional Notes Stacked on top of `mleese/ndm-device-handoff` (#54652), and depends on `mleese/ndm-workload-balancing-metric` (#54656) and `mleese/ndm-workload-balancing-metadata` (#54659) both being merged into it — this branch already contains both of those changes merged in, since they're sibling branches rather than stacked on each other.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54795",
          "createdAt": "2026-08-12T19:04:08Z",
          "updatedAt": "2026-08-12T20:05:27Z",
          "timestamp": "2026-08-12T20:05:27Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [],
          "author": "matthewleese",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:097b7be1f9ad354a1b6a",
        "signalId": "github:DataDog/datadog-agent:pull_request:49282",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:49282",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACIX-1440]  Only sign and notarize packages on nightly",
          "text": "### What does this PR do? Stops code signing on main, and moves it only to nightly. ### Motivation Get back ~7 minutes of wait time on the post merge finalization of every commit. Discussion with delivery team indicates that doing this on nightly is sufficient to keep them alert for potential problems. ### Describe how you validated your changes If basic CI passes we merge this. If some time (a week? until next release candidate freeze?) goes by without anyone finding a problem, we don't roll back. We also take a look at time for macos dmg jobs over the week to verify a measureable decrease.",
          "url": "https://github.com/DataDog/datadog-agent/pull/49282",
          "createdAt": "2026-04-13T18:20:13Z",
          "updatedAt": "2026-08-12T19:45:47Z",
          "timestamp": "2026-08-12T19:45:47Z",
          "metrics": {
            "reactions": 0,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/agent-build",
            "stale",
            "auto-closed",
            "internal"
          ],
          "author": "aiuto",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:43bf167dde6de9cb31ca",
        "signalId": "github:DataDog/datadog-agent:pull_request:50457",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:50457",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ABLD-457] Rust version of tool to make md5sums file of a tar file.",
          "text": "### What does this PR do? For debian packaging, we need to include a file of md5 sums of all the files in the data payload as the file md5sums in the control payload. This makes that available as a rule. I'll plug it into a wrapper for pkg_deb in a follow-up. ### Describe how you validated your changes - Tests - reading the generated code. It's pretty simple. ### Additional Notes I used lzma-rs because it is a pure rust implementation and that avoids having to do with integrating with the C library right now. That is easy enough to fix in the future if we decide we want to deal with that.",
          "url": "https://github.com/DataDog/datadog-agent/pull/50457",
          "createdAt": "2026-05-07T04:12:51Z",
          "updatedAt": "2026-08-12T19:45:24Z",
          "timestamp": "2026-08-12T19:45:24Z",
          "metrics": {
            "reactions": 0,
            "comments": 12
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "stale",
            "auto-closed",
            "internal"
          ],
          "author": "aiuto",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:2c0261024b3a0847f346",
        "signalId": "github:DataDog/datadog-agent:pull_request:52200",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:52200",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Revert \"SBOM e2e: scan host and container images across runtimes\"",
          "text": "Reverts DataDog/datadog-agent#51486 It overloads quota on an external server. https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1767647074 If tests pass on this, and the sbom test continues to fail on main, I'll merge this revert",
          "url": "https://github.com/DataDog/datadog-agent/pull/52200",
          "createdAt": "2026-06-12T18:34:44Z",
          "updatedAt": "2026-08-12T19:45:11Z",
          "timestamp": "2026-08-12T19:45:11Z",
          "metrics": {
            "reactions": 0,
            "comments": 6
          },
          "labels": [
            "changelog/no-changelog",
            "team/agent-security",
            "long review",
            "team/container-integrations",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "aiuto",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:350cf4fc25e2debd2e4e",
        "signalId": "github:DataDog/datadog-agent:pull_request:54757",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54757",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[Backport 7.82.x] Bump google.golang.org/grpc to v1.82.1",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Bump google.golang.org/grpc to v1.82.1 ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54757",
          "createdAt": "2026-08-11T22:23:29Z",
          "updatedAt": "2026-08-12T19:42:33Z",
          "timestamp": "2026-08-12T19:42:33Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "long review",
            "internal"
          ],
          "author": "jeremy-hanna",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:93190eaa2df306d1412e",
        "signalId": "github:DataDog/datadog-agent:pull_request:54691",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54691",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix(cws): register connected sockets in the `flow_pid` map",
          "text": "### What does this PR do? Registers the flow of a connecting IPv6 socket once `connect` returns. ### Motivation `tcp_v6_connect` classifies the flow before the ephemeral source port and the source address are picked, so until Linux 7.0 the socket was classified on its first transmit, once both were known. Linux 7.0 only routes on a dst cache miss in `inet6_csk_xmit`, and a connecting socket always ends up holding a route, so that second classification never happens and those flows are left unattributed. ### Describe how you validated your changes Existing functional tests running on Ubuntu 26.04 that this PR fixes. ### Additional Notes IPv4 flows are unaffected as these are still registered as part of the `security_sk_classify_flow` hook.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54691",
          "createdAt": "2026-08-10T22:39:08Z",
          "updatedAt": "2026-08-12T19:32:30Z",
          "timestamp": "2026-08-12T19:32:30Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/agent-security",
            "category/bugfix",
            "qa/done",
            "medium review",
            "internal"
          ],
          "author": "YoannGh",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:d89fa7aa40aac8220e99",
        "signalId": "github:DataDog/datadog-agent:pull_request:54783",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54783",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Keep injected redacted_compat.h file out of the windows python's build inputs",
          "text": "### What does this PR do? It removes the `redacted_compat.h` file out of the sources for the Python build on Windows, such that it doesn't get used for cache computation. ### Motivation I didn't get remote cache hits on a local checkout with git core.autocrlf disabled (see also https://github.com/DataDog/datadog-agent/pull/54776) due to this specific file. Since the file is only intended for the `configure_make` rule that builds Python on Linux / macOS, we can simply remove the file from inputs to mitigate the problem (regardless of whether we go with https://github.com/DataDog/datadog-agent/pull/54776 or any other similar more general solution). ### Describe how you validated your changes CI. ### Additional Notes Due to the lack of windows sandboxing, the excluded sources for the rule are actually visible to the build action, so there's no guarantee that it doesn't get used by it. However, given that it's a file that we introduce ourselves and not looked at by Python's build system, it's fairly safe to assume that in practice this file doesn't cause any difference to the build outputs.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54783",
          "createdAt": "2026-08-12T14:27:15Z",
          "updatedAt": "2026-08-12T19:29:49Z",
          "timestamp": "2026-08-12T19:29:49Z",
          "metrics": {
            "reactions": 2,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "team/agent-build",
            "internal"
          ],
          "author": "alopezz",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:4d8f731c7cbf08022512",
        "signalId": "github:DataDog/datadog-agent:pull_request:54793",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54793",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Remove schemaBuilder and createschema command",
          "text": "### What does this PR do? Remove the `createschema` command and the schema builder config implementation. We no longer need to generate the schema. ### Motivation Cleanup now that schema is live and in use. ### Describe how you validated your changes CI ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54793",
          "createdAt": "2026-08-12T18:13:12Z",
          "updatedAt": "2026-08-12T19:29:30Z",
          "timestamp": "2026-08-12T19:29:30Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-build",
            "internal",
            "team/fleet-remediation",
            "team/fleet-automation"
          ],
          "author": "dustmop",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:ca43da185ef51d36308d",
        "signalId": "github:DataDog/datadog-agent:pull_request:54682",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54682",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[Backport 7.83.x]  pkg/dyninst: Fix procscan backoff",
          "text": "Backport 623b04cb6c31624398ed401ef0a17fdf6282910c from #54400. ___ ### What does this PR do? Changes how the live debugger finds processes to instrument. It used to look at each process exactly three times, when the process turned 3, 100 and 1000 seconds old. If the tracer inside that process had not announced itself by the third look, that process was never instrumented again for as long as it ran. Now every process is checked repeatedly, with a growing gap between checks, until it is either instrumented or gone. A slow start is a delay of seconds instead of a permanent miss. Two supporting changes come with it. Processes that are not Go programs are identified with a cheap check and set aside, so that looking at everything repeatedly stays affordable. And scans now run on a plain five second timer, where the old one stretched itself in proportion to how long the previous scan took, with no upper limit. Includes benchmarks for the cost of a scan. ### Motivation This came out of an investigation into a service that took roughly half an hour to upload its debugging symbols. Symbols are only uploaded once a service is being instrumented, so a discovery failure surfaces as an unexplained delay somewhere else entirely, which is what made it hard to track down. The tracer announces itself at the very end of its own startup, behind a network call that can hang for ten seconds. The first look happened a few seconds after the process started, so the tracer could not win that race, and the design gave it only two more chances ever. The same investigation turned up a second problem: because the timer grew with scan duration and had no ceiling, a single slow scan could push the next one out far enough to swallow two of the three chances a process ever got. ### Describe how you validated your changes Extended the existing table-driven scanner tests to cover the retry schedule, a tracer that only announces itself after many attempts, agent restart, process ID reuse, permission failures, processes that are not Go programs, and the fixed timer. Added benchmarks, since the new loop looks at every process every time. On a host with two thousand processes, an ordinary scan costs about 0.44% of one core, and the first scan after a restart costs about 2% of a core for that one scan. ### Additional Notes A process that starts as a shell script and later replaces itself with the real service keeps the same process ID, so if we happen to look at it while it is still the script, we write it off along with the service it becomes if it's not Go. Container enrypoints happen on proc start so this is not an issue except the case of a proc running as a script that does set up and does an exec. I don't think that really matters for support.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54682",
          "createdAt": "2026-08-10T21:28:31Z",
          "updatedAt": "2026-08-12T19:21:56Z",
          "timestamp": "2026-08-12T19:21:56Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/ebpf-platform",
            "qa/done",
            "backport",
            "bot",
            "long review",
            "team/agent-build",
            "internal",
            "team/debugger"
          ],
          "author": "dd-octo-sts[bot]",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:00ae0b3a6e1b9b1724ee",
        "signalId": "github:DataDog/datadog-agent:pull_request:54784",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54784",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(fleet): Report installer status through local API",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Replaces the Fleet Automation process/service check in core Agent status with the installer local API. The local API wire contract and client now live in the updater components instead of `pkg/fleet/daemon`. Core Agent consumers receive a status-only client with a two-second request deadline, a 1 MiB response limit, disabled keep-alives, and no dependency on the installer daemon package. The existing installer CLI methods and wire format remain compatible. Agent status keeps the existing Fleet booleans and adds a stable `installerStatus` object containing reachability and sorted package state. Text and HTML output include non-empty package/configuration versions and task details. Errors degrade to `reachable: false` without failing status generation, and the secrets public key is never exposed. The obsolete `daemonchecker` component is removed. Existing Linux and Windows E2E coverage now checks the default unreachable case and verifies that a running core Agent can read installer package state during Fleet upgrade setup. ### Motivation The previous check only established whether the installer process or service appeared to be running. It could not distinguish an inaccessible installer API or expose the package, configuration, and task state needed to troubleshoot Fleet Automation operations. Reusing the existing local API provides the actual communication boundary and avoids introducing a second inventory/status API. Listener permissions and ACLs are intentionally unchanged and were validated separately. ### Describe how you validated your changes - `bazel test //comp/fleetstatus/impl:impl_test //comp/updater/localapiclient/impl:impl_test //pkg/fleet/daemon:daemon_test` - `bazel build --platforms=@rules_go//go/toolchain:windows_amd64 //comp/updater/localapiclient/impl:impl` - `dda inv agent.build --build-exclude=systemd` - `dda inv agent.build --flavor=iot --build-exclude=systemd` - Targeted `dda inv linter.go` for the changed core packages - `dda inv components.lint-components` - Verified `somepath(//comp/updater/localapiclient/impl:impl, //pkg/fleet/daemon:daemon)` is empty The legacy `dda inv test` wrapper could not start tests locally because its bundled Go 1.26.4 is older than the Go 1.26.5 required by `go.work`; the equivalent hermetic Bazel suites above pass. Full E2E compilation also exhausted local disk while compiling Pulumi dependencies, so the added provisioned Linux/Windows coverage remains for CI. ### Additional Notes Automated pre-PR review identified and prompted fixes for two issues before push: status reads no longer wait behind long-running installer operations, and Windows pipe dialing retains the previous two-second bound for mutation requests without an existing deadline.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54784",
          "createdAt": "2026-08-12T14:34:35Z",
          "updatedAt": "2026-08-12T19:12:47Z",
          "timestamp": "2026-08-12T19:12:47Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-devx",
            "team/agent-build",
            "team/windows-products",
            "internal",
            "team/fleet-remediation"
          ],
          "author": "arbll",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:be74461a41d95d99181b",
        "signalId": "github:DataDog/datadog-agent:pull_request:54680",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54680",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "AGNTLOG-706 Increase logging for fingerprinting tailing",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? A file that matches a log config but gets no tailer because its fingerprint is unusable used to be dropped silently, with no log line at any level. The only clue was an unexplained shortfall in `N files tailed out of M files matching`. This reports the gap when it opens, while it lasts, and when it closes. #### What an operator sees Setup: `byte_checksum` fingerprinting with `count` left at its default of 1024 bytes, a source matching `/var/log/app/*.log`, and `app.log` just rotated away to a 412-byte replacement. Scans run every second. ``` t=1s WARN Unable to tail /var/log/app/app.log. 412 bytes is too short for fingerprinting (needs 1024 bytes). Logs are not collected until the file grows. t=2..29s (silent: the warning is latched, so a file that stays short cannot fill the log. Every scan still shows the arithmetic at debug level.) t=30s INFO Now tailing /var/log/app/app.log, 30s after it was first skipped for an unusable fingerprint (insufficient_data). ``` While the gap is open, `agent status` carries it under the source whose pattern matched the file: ``` - Type: file Path: /var/log/app/*.log Status: OK 2 files tailed out of 3 files matching Not tailing /var/log/app/app.log: too short to fingerprint (needs 1024 bytes). Lower logs_config.fingerprint_config.count if this persists ``` The `2 files tailed out of 3` line already existed and was the whole of what an operator had to go on. The `Not tailing` line is new: which file, why, and the setting that governs it. It names `this source's fingerprint_config.count` instead when the source carries its own `fingerprint_config`, and names no setting at all when the threshold came from an internal fallback, so the suggestion always points at something that would change the outcome. Recovery is a delay in collection rather than a hole in it: these tailers start at the beginning of the file, so the 412 bytes written while it waited are read and sent once tailing starts. What the file held is only lost if it is destroyed before a tailer ever reaches it. Three variations on the ending: - **The file goes away while still short** — deleted, or `count` set too high. The closing line is a WARN rather than an INFO, so the gap is bounded either way: `Stopped tracking /var/log/app/app.log, never tailed for 45s because of an unusable fingerprint (insufficient_data). Logs written during that gap were not collected.` - **The Agent stops with skips outstanding** — one line: `Stopping with 1 file(s) still not tailed because their fingerprint was unusable.` - **The fingerprint fails to compute** rather than coming up short, a permissions error say. The warning and the status message report that instead of blaming the file's size. A file alternating between the two reasons warns once per reason, keeping its original start time, so one gap is still reported as one gap. ### Motivation The usual cause is benign and self-healing — a rotation leaving the file below `logs_config.fingerprint_config.count` — but collection stalls while it lasts, and a `count` set too high makes that permanent. Customers cannot query the Agent's telemetry, so this has to reach them through the log and `agent status`. ### Describe how you validated your changes `dda inv test --targets=./pkg/logs/launchers/file/...` — 110 tests pass. New tests cover the warn-once latching (including a file alternating between reasons), both closing outcomes and their durations, the status message and its removal, the message following a source that gets replaced, and two ways a skip could be wrongly reported as given up on: a scan already in flight when the source was added, and one that hit `open_files_limit` and so may have left out files that are still matched. `dda inv test --targets=./pkg/logs/launchers/file/provider/...` — 45 tests pass. The new one asserts that a wildcard matching no files is reported in both selection modes, which is the parity the provider fix restores: revert those six lines and only the `by_modification_time` case fails. Also verified `gofmt` and `bazel test //bazel/buildifier:test`. No E2E test covers this. ### Additional Notes - Inert by default: `logs_config.fingerprint_config.fingerprint_strategy` defaults to `disabled`. - Drive-by fix in the file provider: under `file_wildcard_selection_mode: by_modification_time`, a wildcard source that resolves to no files now reports the error, as it already does under the default `by_name` mode. That mode resolves wildcards in a pass of its own, separate from the one every other source goes through, which is how it came to drop them. Not in the release note.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54680",
          "createdAt": "2026-08-10T21:13:57Z",
          "updatedAt": "2026-08-12T19:00:06Z",
          "timestamp": "2026-08-12T19:00:06Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "qa/done",
            "long review",
            "ask-review",
            "team/agent-log-pipelines",
            "team/agent-build",
            "internal"
          ],
          "author": "DDuongNguyen",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:e386bae11128eb61f172",
        "signalId": "github:DataDog/datadog-agent:pull_request:54710",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54710",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[Backport 7.83.x]  [autoscaling] Filter Preview DPAs from pod patcher",
          "text": "Backport bb50da7066b760291cd2c0dbcd51f8d7162025d4 from #54697. ___ ### What does this PR do? Updates findAutoscaler in pod_patcher.go to filter out DatadogPodAutoscaler resources whose ApplyPolicy.Mode is set to Preview. Only autoscalers in `Apply` mode (or with no ApplyPolicy set) are considered when patching pods. ### Motivation It is valid to have multiple DPAs targeting the same workload - for example, one in Preview mode for observing recommendations and one in Apply mode for actually applying them. Previously, the pod patcher would find both and error out with \"Multiple autoscaler found\", preventing any patching from occurring. This fix allows Preview DPAs to coexist with an Apply DPA on the same target. ### Describe how you validated your changes Tested locally with a kind cluster running two DPAs targeting the same deployment.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54710",
          "createdAt": "2026-08-11T10:37:31Z",
          "updatedAt": "2026-08-12T18:51:10Z",
          "timestamp": "2026-08-12T18:51:10Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "component/cluster-agent",
            "qa/done",
            "backport",
            "bot",
            "component/autoscaling",
            "short review",
            "team/container-autoscaling",
            "internal"
          ],
          "author": "dd-octo-sts[bot]",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:d1d9942b701f0e1b5168",
        "signalId": "github:DataDog/datadog-agent:pull_request:53732",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53732",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "APM: Enable convert-traces feature by default (take 2)",
          "text": "This is attempt 2 due to needing to revert last version ## Summary - Flips the trace-agent's `convert-traces` v1.0 payload-conversion path to be **enabled by default**. - Introduces a new opt-out feature flag, `disable-convert-traces`, for teams/customers who need to revert to the legacy code path. - Updates `pkg/trace/api/api_test.go` to reflect the new default (removes the test-only force-enable of `convert-traces`; the \"without conversion\" test now sets `disable-convert-traces` instead of clearing the whole `Features` map). - Update serverless use cases to also affect v1 paths (e.g. modify span, discard span) The long term plan here is to deprecate and remove the non-V1 paths. This code change adds some duplicated code for the serverless v1 span usage, but the plan is to remove the old path entirely after we have confidence with customers running the conversion logic and no issues found. ## Test plan - [x] `dda inv trace-agent.build` succeeds - [x] `dda inv test --targets=./pkg/trace/api/...` — all 584 tests pass - [x] We have been dogfooding this conversion logic in staging and production across ALL DCs - [x] APM System-tests pass with conversion logic enabled - [ ] **TODO** Manually trigger APM system-tests to validate on all tracers",
          "url": "https://github.com/DataDog/datadog-agent/pull/53732",
          "createdAt": "2026-07-16T12:59:13Z",
          "updatedAt": "2026-08-12T18:36:49Z",
          "timestamp": "2026-08-12T18:36:49Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "team/agent-apm",
            "long review",
            "team/injection-platform",
            "team/agent-build",
            "stale",
            "internal"
          ],
          "author": "ajgajg1134",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:7d4578623345c5fe7812",
        "signalId": "github:DataDog/datadog-agent:pull_request:53641",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53641",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add Windows `powershell` check",
          "text": "### What does this PR do? Adds a new Windows `powershell` check that runs admin-allowlisted, read-only PowerShell cmdlets and maps their output objects to metrics and tags. The data model mirrors the WMI check — `metrics`, `tag_by`, `tags`, `filters`, and `tag_queries` (joins) — so each cmdlet output object is a \"row\" and its properties are \"columns.\" Key pieces: - **Config** (`config.go`): per-instance YAML parsing with dual positional-tuple / mapping forms; supports a \"virtual\" metric (constant value, tags carry the signal) for all-string cmdlet output. - **Allowlist** (`allowlist.go`): admin-owned policy read from the fixed, ACL-protected path `C:\\ProgramData\\Datadog\\protected\\powershell_allowlist.yaml`, constraining cmdlets, parameters, and values. Fails closed if the file is missing, malformed, or not owned by an administrator. - **Command generation** (`command.go`): parameter values are bound to the cmdlet as data (splatting + single-quoted literals + a runtime `Get-*` verb re-check), never interpolated, so untrusted values cannot inject PowerShell. - **Execution** (`powershell.go`): runs the cmdlet under a per-invocation timeout with a restricted environment and a capped output buffer, then maps rows to metrics and tags. Behavior refinements included: - A non-virtual metric whose property is missing or non-numeric causes `Run()` to error out (logged at error level, surfaced in `agent status`) rather than silently emitting nothing. - A negative per-instance `timeout` logs a warning and falls back to the default 30s. ### Motivation Windows Server exposes a large amount of operational data through PowerShell cmdlets that have no dedicated Datadog integration. This check lets customers point the Agent at a read-only cmdlet and turn its output into metrics and tags declaratively, with no custom code — the cmdlet analog of the WMI check. ### Describe how you validated your changes `dda inv test --targets=./pkg/collector/corechecks/system/powershell` — 27/27 pass, covering config parsing (incl. timeout handling), allowlist enforcement, injection-safe command generation, and value/tag mapping. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/53641",
          "createdAt": "2026-07-14T14:38:46Z",
          "updatedAt": "2026-08-12T18:29:14Z",
          "timestamp": "2026-08-12T18:29:14Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "long review",
            "qa/rc-required",
            "team/agent-runtimes",
            "team/agent-devx",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "mrafi97",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:0a40f9a85da0e99dbbca",
        "signalId": "github:DataDog/datadog-agent:pull_request:54727",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54727",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CONTP-1773] Fix(workloadmeta): signal initialization when no collector is applicable",
          "text": "### What does this PR do? Fixes GH issue #49480 / CONTP-1773: the Agent logs a spurious ERROR on every startup in environments where no workloadmeta collector is applicable (e.g. a container sidecar with no Kubernetes, no container runtime socket, no ECS, no GPU). Root cause: when all collector candidates fail to start with non-retriable \"disabled\" errors, `startCandidatesWithRetry` never closes `firstCollectorReady`, so the pull goroutine waits the full `firstPullWaitTimeout` (30s) before marking the store initialized. Autodiscovery only waits 10s, so it logs the ERROR first. Fix: close `firstCollectorReady` once all candidates have been processed, even when none started, so the pull goroutine proceeds immediately and signals initialization. ### Motivation Spurious startup ERROR alarms users and trips log-based alerts on every pod restart. ### Describe how you validated your changes Unit tests (`dda inv test --targets=./comp/core/workloadmeta/impl/...` and `./comp/core/autodiscovery/impl/...`). ### Additional Notes Regression introduced by #47178 (AGENTCFG-650). This fix restores prompt initialization when no collector is applicable without reintroducing that PR's race.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54727",
          "createdAt": "2026-08-11T15:18:05Z",
          "updatedAt": "2026-08-12T18:18:21Z",
          "timestamp": "2026-08-12T18:18:21Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "qa/done",
            "team/container-platform",
            "medium review",
            "team/agent-build",
            "internal"
          ],
          "author": "zhuminyi",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:f08b7a7ce1b7431d11b5",
        "signalId": "github:DataDog/datadog-agent:pull_request:54744",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54744",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "remove unneeded python spec in legcay omnibus",
          "text": "### What does this PR do? Removes unused python version spec. It is just confusing. ### Motivation ### Describe how you validated your changes CI",
          "url": "https://github.com/DataDog/datadog-agent/pull/54744",
          "createdAt": "2026-08-11T18:56:37Z",
          "updatedAt": "2026-08-12T18:05:46Z",
          "timestamp": "2026-08-12T18:05:46Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/agent-integrations",
            "team/agent-build",
            "internal"
          ],
          "author": "aiuto",
          "state": "open",
          "assignees": [
            "Kyle-Neale"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:e5df29f222fedb529581",
        "signalId": "github:DataDog/datadog-agent:pull_request:54739",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54739",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ABLD-366] Fix build file for cmd/loader so it can also build for macos.",
          "text": "### What does this PR do? Fix build file for cmd/loader so it can also build for macos. - Remove unneeded target_compatible_with - Adjust packaging to include it for macos. - Fix dd_agent_go_binary so we can select() `exact_gotags` We are blocked on ABLD-294 for using the loader in the real package, so we just have it named \"loader\" for now. We can build and verify that it works. ### Describe how you validated your changes Make sure the loader builds and runs on mac. Running it is subtle. ``` $ bazel build //cmd/trace-agent:trace-agent Target //cmd/trace-agent:trace-agent up-to-date: bazel-bin/cmd/trace-agent/trace-agent_/trace-agent INFO: Build completed successfully, 1 total action $ cp bazel-bin/cmd/trace-agent/trace-agent_/trace-agent /tmp $ bazel build //cmd/loader:loader Target //cmd/loader:loader up-to-date: bazel-bin/cmd/loader/loader_/loader $ bazel-bin/cmd/loader/loader_/loader /opt/datadog-agent/etc/datadog.yaml /tmp/trace-agent ... 2026-08-11 14:45:52 EDT | TRACE-LOADER | INFO | (pkg/util/log/log.go:734 in func1) | Starting to load the configuration 2026-08-11 14:45:52 EDT | TRACE-LOADER | ERROR | (pkg/util/log/log.go:815 in func1) | warning reading config ... ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54739",
          "createdAt": "2026-08-11T17:28:25Z",
          "updatedAt": "2026-08-12T17:58:08Z",
          "timestamp": "2026-08-12T17:58:08Z",
          "metrics": {
            "reactions": 2,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "team/agent-build",
            "internal"
          ],
          "author": "aiuto",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:2adc92e3371b6ecabade",
        "signalId": "github:DataDog/datadog-agent:pull_request:53496",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53496",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add support for renamed settings",
          "text": "### What does this PR do? Add support for renamed settings This PR introduce a rename mechanism within the config. It also use the warning from the config to raise error about unknown keys.",
          "url": "https://github.com/DataDog/datadog-agent/pull/53496",
          "createdAt": "2026-07-10T10:19:18Z",
          "updatedAt": "2026-08-12T17:53:39Z",
          "timestamp": "2026-08-12T17:53:39Z",
          "metrics": {
            "reactions": 0,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog",
            "team/agent-apm",
            "team/ebpf-platform",
            "qa/done",
            "long review",
            "team/agent-configuration",
            "team/agent-build",
            "internal",
            "team/fleet-remediation",
            "team/fleet-automation"
          ],
          "author": "hush-hush",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:573b6187b749eeaabbc2",
        "signalId": "github:DataDog/datadog-agent:pull_request:54769",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54769",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Split network-devices section in it's own file and fix ID links",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Split netowrk-devices section in it's own file and fix ID links",
          "url": "https://github.com/DataDog/datadog-agent/pull/54769",
          "createdAt": "2026-08-12T10:03:17Z",
          "updatedAt": "2026-08-12T17:52:05Z",
          "timestamp": "2026-08-12T17:52:05Z",
          "metrics": {
            "reactions": 1,
            "comments": 1
          },
          "labels": [
            "changelog/no-changelog",
            "team/agent-apm",
            "team/agent-security",
            "team/remote-config",
            "team/ebpf-platform",
            "team/agent-cspm",
            "qa/done",
            "team/container-platform",
            "long review",
            "team/container-integrations",
            "team/agent-runtimes",
            "team/agent-configuration",
            "team/agent-log-pipelines",
            "team/container-experiences",
            "team/kubernetes-experiences",
            "team/action-platform",
            "internal",
            "team/network-device-monitoring-core",
            "team/gpu-monitoring-agent",
            "team/fleet-remediation",
            "team/fleet-automation"
          ],
          "author": "hush-hush",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:37de9cf260a985863be8",
        "signalId": "github:DataDog/datadog-agent:pull_request:54166",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54166",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[WP] Ignore unsupported socket types in flow_pid map during snapshot",
          "text": "### What does this PR do? This PR prevents keys unrelated to UDP or TCP sockets from being added to the `flow_pid` map when reading socket from procfs. ### Motivation The current mechanism is designed specifically for UDP and TCP. We should avoid adding other socket types until we support parsing them from procfs info",
          "url": "https://github.com/DataDog/datadog-agent/pull/54166",
          "createdAt": "2026-07-28T12:55:29Z",
          "updatedAt": "2026-08-12T17:51:46Z",
          "timestamp": "2026-08-12T17:51:46Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/agent-security",
            "qa/done",
            "short review",
            "internal"
          ],
          "author": "theop-dd",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:55347bb5439550d37eff",
        "signalId": "github:DataDog/datadog-agent:pull_request:54658",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54658",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add BUILD file for pkg/network/protocols/http/gotls/lookup/internal",
          "text": "### What does this PR do? Add BUILD file for pkg/network/protocols/http/gotls/lookup/internal. Remove the `go:build nobuild` tag preventing this from being seen by gazelle. ### Motivation Cleaning up. ### Describe how you validated your changes ``` bazel build //pkg/network/protocols/http/gotls/lookup/internal:generate_luts ```",
          "url": "https://github.com/DataDog/datadog-agent/pull/54658",
          "createdAt": "2026-08-10T16:31:57Z",
          "updatedAt": "2026-08-12T17:40:12Z",
          "timestamp": "2026-08-12T17:40:12Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "qa/no-code-change",
            "medium review",
            "ask-review",
            "team/agent-build",
            "internal"
          ],
          "author": "aiuto",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:051722483d80206492f0",
        "signalId": "github:DataDog/datadog-agent:pull_request:54791",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54791",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[MVP][CONTP-1967] feat(ddi): Support custom targer refs for DDI checks and logs",
          "text": "### What does this PR do? Adds configurable workload targets for DatadogInstrumentation checks and logs. The Cluster Agent now: - Builds a registry from built-in workloads and `instrumentation_crd_controller.custom_workload_targets`. - Resolves Pod controller ownership through configured `via` resources with the dynamic Kubernetes client. - Streams resolved target identity, including group, version, kind, namespace, name, and UID, to Node Agents through the Kubernetes metadata stream. - Uses `container.pod.resolved_targets` in CEL selectors for custom targets while preserving the existing `rootowner` path for built-in targets. - Starts the Pod workloadmeta store when custom workload targets are configured. For example, an OpenKruise `AdvancedCronJob` can be configured as a target reached through its intermediate `Job`: ```yaml instrumentation_crd_controller: custom_workload_targets: - target: apiVersion: apps.kruise.io/v1alpha1 kind: AdvancedCronJob resource: advancedcronjobs via: - apiVersion: batch/v1 kind: Job resource: jobs ``` Direct owners such as `CloneSet` use the same format without `via`. ### Motivation [CONTP-1967](https://datadoghq.atlassian.net/browse/CONTP-1967) DatadogInstrumentation currently relies on a hard-coded workload allowlist and root-owner metadata. That excludes arbitrary workload CRs, cannot distinguish identical kinds across API groups, and does not support ownership chains such as Pod to Job to AdvancedCronJob. This proof of concept makes workload support data-driven while keeping the existing behavior for built-in Kubernetes workloads. [CONTP-1967]: https://datadoghq.atlassian.net/browse/CONTP-1967?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54791",
          "createdAt": "2026-08-12T17:28:19Z",
          "updatedAt": "2026-08-12T17:36:59Z",
          "timestamp": "2026-08-12T17:36:59Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [
            "team/container-platform",
            "long review",
            "team/container-integrations",
            "team/agent-runtimes",
            "team/agent-build",
            "internal",
            "team/fleet-automation"
          ],
          "author": "Mathew-Estafanous",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:d9bab9197ca807ee6a5d",
        "signalId": "github:DataDog/datadog-agent:pull_request:52587",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:52587",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "add eviction configs",
          "text": "### What does this PR do? Pick up NCM eviction configurations from the datadog.yaml. Use these values in the eviction function. Call the eviction function after we write to the db to ensure that we do not exceed memory constraints. Evictions are tracked under a new Datadog internal metric: `datadog.ncm.store.configs_evicted` ### Motivation ### Describe how you validated your changes ### Additional Notes ### Local Validation That datadog.yaml is read correctly set `dev/dist/datadog.yaml`: ``` log_level: debug api_key: *** dd_url: 'https://dd.datad0g.com/' hostname: \"sophie-local\" process_config: process_collection: enabled: true network_devices: config_management: rollback: enabled: true store: min_configs_per_device: 2 max_configs_per_device: 24 max_raw_config_store_bytes: 2000000000 ``` run commands: ``` dda inv agent.build --build-exclude=systemd ./bin/agent/agent run -c ./bin/agent/dist/datadog.yaml ``` View debug logs: <img width=\"1439\" height=\"61\" alt=\"Screenshot 2026-06-23 at 11 59 38 AM\" src=\"https://github.com/user-attachments/assets/c2f526a1-76e4-407e-9569-be1adc573112\" /> ### CML eviction e2e test Confirmed eviction order with simulation on CML - set low number of bytes for store config - change configuration of network device, expecting removal of configurations in alignment with eviction policy - check evicted uuids in logs, confirm that inventory_reported_at does not continue to update for evicted configs in orgstore ### QA flow in CML 1) Configure datadog.yaml file inside of CML yaml file for test case, import lab to CML 2) Make needed configuration changes for test case 3) Validate Boltdb state with the following steps: ssh into vm running agent in cml, display device_config.db in cml as base 64: `sudo base64 /opt/datadog-agent/run/ncm_config.db` copy and paste the db output into a .txt file in local computer convert to a bin file: `base64 -d ~/Documents/cml_boltdb.txt > ~/Documents/cml_boltdb.bin` explore file using ncm show: ``` cd ~/go/src/github.com/DataDog/ndm-tools/ncmshow ./ncmshow ~Documents/cml_boltdb.bin ``` ### Manual test cases 1) Set configuration to: min_configs_per_device: 1, max_configs_per_device: 24, max_raw_config_store_bytes: 8 Get BoltDB state: <img width=\"849\" height=\"88\" alt=\"Screenshot 2026-08-05 at 9 51 16 AM\" src=\"https://github.com/user-attachments/assets/68b152bf-a4d2-4208-9651-84d014c6177d\" /> Change hostname Get BoltDB state: <img width=\"850\" height=\"92\" alt=\"Screenshot 2026-08-05 at 9 51 23 AM\" src=\"https://github.com/user-attachments/assets/bbffc9bb-ca2f-46b1-8c12-9996c39ae3ca\" /> (Should see 2 configs per device, even though min configs is set to 1 it should get overridden to 2. Min configs should override the config store requirement - will see that even after eviction not within this setting.) - note here, old running config was evicted so that the modified one could be stored <img width=\"969\" height=\"531\" alt=\"Screenshot 2026-08-05 at 10 12 01 AM\" src=\"https://github.com/user-attachments/assets/72e3942e-8cf5-43eb-9b65-21e1de3a3855\" /> 2) Set configuration to: min_configs_per_device: 1, max_configs_per_device: 3, max_raw_config_store_bytes: 1000000 Change hostname Change hostname <img width=\"561\" height=\"605\" alt=\"Screenshot 2026-08-05 at 12 32 52 PM\" src=\"https://github.com/user-attachments/assets/96d92227-ed84-4dcf-857b-8ad2d94adddb\" /> Get BoltDB state: <img width=\"853\" height=\"138\" alt=\"Screenshot 2026-08-05 at 12 32 43 PM\" src=\"https://github.com/user-attachments/assets/24adf9c7-a637-443c-80c3-ea50b14a23ad\" /> BoltDB only has 3 max configs for evictionCML2:10:10:1:2 even though there is enough space in the (db only 66000 bytes) because of the upper max_raw setting.",
          "url": "https://github.com/DataDog/datadog-agent/pull/52587",
          "createdAt": "2026-06-22T16:24:53Z",
          "updatedAt": "2026-08-12T17:32:18Z",
          "timestamp": "2026-08-12T17:32:18Z",
          "metrics": {
            "reactions": 0,
            "comments": 5
          },
          "labels": [
            "qa/done",
            "long review",
            "team/ndm-integrations",
            "team/agent-configuration",
            "team/agent-devx",
            "team/agent-build",
            "internal",
            "team/fleet-automation"
          ],
          "author": "Sophie-Ruetschi",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:bdb7dbe1890f8b067d43",
        "signalId": "github:DataDog/datadog-agent:pull_request:54384",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54384",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CNM-5556] Add diagnostics for TLS traffic reported as tls_encrypted:false",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds **observational-only** eBPF diagnostics to confirm a suspected root cause for encrypted traffic being reported as `tls_encrypted:false` in CNM. **No classification behaviour changes.** Five counters, one per link in the suspected chain, exposed as `datadog.system_probe.network_tracer.ebpf.*`: | Counter | Link | What a non-zero value proves | |---|---|---| | `tls_reject_record_exceeds_packet` | 1a | `is_tls()` rejected a valid record header solely because the record ran past the end of the packet | | `tls_reject_handshake_invalid` | 1b | The record fit, but `is_valid_tls_handshake()` rejected it (non-Hello type, coalesced, or fragmented) | | `applayer_match_on_tls_payload` | 2 | A db-layer classifier matched a buffer that *begins with a plausible TLS record header* | | `redis_match_on_nonstandard_port` | 2 | Redis matched on a port Redis never serves | | `tls_locked_out_by_applayer` | 3 | A TLS record header arrived on a connection whose app layer was already recorded, so `is_tls()` can never run again | Supporting pieces: - `is_tls_record_header_plausible()` in `tls.h` — validates `content_type` + `version` **without** the fits-in-packet bound. Needed because reusing `is_tls()` for diagnostics would be blind to precisely the case under investigation. Documented as diagnostic-only; deliberately not used for classification. - `tls_diag_events` — a bounded (1024-entry) hash map carrying per-connection detail, drained from the Prometheus `Collect()` path and logged at **info** level. Because the logging is userspace, a normal non-debug build at default log level is sufficient; eBPF cannot write agent logs at all. Rate limited to 5 lines per scrape, and every entry visited is deleted so the map cannot pin at capacity. - Everything is gated behind a `tls_diag_enabled` constant (kernel **6.0+**), so on older kernels the verifier prunes the branches entirely — see \"Additional Notes\". - Drive-by: corrects a stale comment claiming `connection_protocol` is an LRU map. It is a plain hash map, so it does not evict; leaked entries are reclaimed by the userspace map cleaner. ### Motivation Encrypted traffic is being reported as unencrypted across a broad slice of staging: **47 aggregate connections on one Kafka port, all classified `redis`**, spanning ~10 client services and ~10 kube clusters plus bare EC2, with Rust, Go and JVM clients all affected. Both endpoints' agents misclassify independently. The suspected mechanism, from reading the classifier: 1. On a connection whose TLS handshake was never observed, `is_tls()` rejects genuine TLS because `read_tls_record_header()` requires the whole record to fit in one packet. Records run to 16 KB; MSS is ~1460. 2. Classification falls through to the app-layer classifiers. `is_redis()` accepts on a **single byte** matching any of 14 RESP type markers, with no CRLF, length or structure check — so it matches arbitrary ciphertext ~5.5% of the time. 3. `mark_as_fully_classified()`, plus the `app_layer_proto == UNKNOWN || POSTGRES` gate on the `is_tls()` call, pin that wrong answer for the life of the map entry. Result: emitted protocol stack `[Redis]` → `tls_encrypted:false` on genuinely encrypted traffic. Note this does **not** mean the gate is wrong. Per the [Harden TLS socket filter classification RFC](https://datadoghq.atlassian.net/wiki/spaces/UT/pages/3954869126), which introduced it in #28198, the reasoning was *\"if the socket filter was able to classify the protocol, then it is not TLS\"* — sound, **provided classifiers do not false-positive**. This PR measures whether that proviso is being violated in practice. `redis_match_on_nonstandard_port` is the decisive signal: classification is purely content-based with no port heuristics anywhere, so Redis matched off 6379/6380/16379/26379 is a false positive by definition — no ground truth required. The other four are sampling-dependent (they need a packet to begin at a TLS record boundary), so treat their magnitudes as evidence of *mechanism*, not blast radius. **Falsification condition:** if all five stay zero while `tls_encrypted:false` persists on the affected port, the theory is wrong and the Redis verdict is arriving via some other path. ### Describe how you validated your changes - eBPF compiles for prebuilt, runtime and CO-RE; `cgo -godefs` regenerated via `bazel run //pkg/network/ebpf:kprobe_types_godefs{,_test_file}` (both generated files), 46/48 godefs tests pass (2 Windows-only skipped). - Verifier accepts `tracer.o` and `tracer-fentry.o` with no load failures. - Measured on 6.8/arm64 with the gate closed, confirming the branches are pruned rather than merely unreached: | program | diagnostics active | gated off | |---|---|---| | `socket__classifier_entry` | 5,245 processed | **2,946** (−44%) | | `socket__classifier_dbs` | 2,060 processed | **1,247** (−39%) | - Program sizes measured against the base commit: `_entry` 1,127 → 1,402, `_dbs` 703 → 922 instructions. `_grpc` and `_tls_handshake_client` are byte-identical to `main`. ### Additional Notes **This is an investigation aid, not the fix.** It changes no classification behaviour. The likely fix — tightening `is_redis` to require a well-formed RESP frame, using the validators that already exist unused in `redis/helpers.h` — is intentionally not in this PR so the diagnostics can be reviewed independently and so the fix lands with its own regression test. **Two earlier KMT failures shaped the design, both fixed here:** 1. `BPF_MAP_TYPE_LRU_HASH` was added in kernel **4.10**, but classification runs from 4.11 down through runtime compilation on older kernels, which builds against the *host's* headers — so debian_9 (4.9) and ubuntu_16.04 (4.4) failed to compile outright. No other map reachable from `tracer.c` used `BPF_LRU_MAP`. Now a plain hash map. 2. On ubuntu_18.04 / amazon_4.14 (**kernel 4.18**), the added branches stopped `socket__classifier_entry` loading in the *prebuilt* object while the runtime-compiled tracer passed on the same kernel and commit. Not program size — the diagnostics add 275 instructions to a 4,096 limit — but verifier **complexity**, where pre-5.2 kernels cap processed instructions at 131,072 and prune far less. The runtime object escapes because host-specific compilation drops the version-gated branches that make the prebuilt object more complex. Hence the kernel-6.0 gate. The threshold is 6.0 rather than the functional boundary of 5.2 (where `BPF_MAXINSNS` and the complexity limit both jump to 1M) because these diagnostics only ever run on 6.x staging hosts, so there is no reason to carry risk on older kernels. `TLSDiagnosticsSupported()` fails closed if the kernel version cannot be determined, and is ANDed with classification support. Known limitations: the gate reduces complexity but **not** program size (dead instructions still count toward `BPF_MAXINSNS`); `tls_diag_events` is still created on every kernel (~72 KB) because it is declared in the ELF; and KMT distros below 6.0 no longer exercise the diagnostic code, so a regression in it would not be caught there.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54384",
          "createdAt": "2026-08-03T17:50:45Z",
          "updatedAt": "2026-08-12T17:32:04Z",
          "timestamp": "2026-08-12T17:32:04Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "qa/done",
            "long review",
            "team/agent-build",
            "team/cloud-network-monitoring",
            "internal"
          ],
          "author": "jmw51798",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:4f12ab57dae9062a7e61",
        "signalId": "github:DataDog/datadog-agent:pull_request:54665",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54665",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add BUILD file for tools/retry_file_dump",
          "text": "### What does this PR do? Add BUILD file for tools/retry_file_dump ### Motivation Everything should be buildable with bazel. ### Describe how you validated your changes build and run ``` bazel run //tools/retry_file_dump:retry_file_dump ... INFO: Build completed successfully, 3 total actions INFO: Running command line: /root/.cache/bazel/_bazel_root/81a15fa9a2846e82038a778136785275/execroot/_main/bazel-out/aarch64-fastbuild/bin/tools/retry_file_dump/retry_file_dump_/retry_file_dump Invalid folder: Usage `./retry_file_dump --folder=/opt/datadog-agent/run/transactions_to_retry/c47da40ac935c8fd5ca1441a5ee3d068/` ```",
          "url": "https://github.com/DataDog/datadog-agent/pull/54665",
          "createdAt": "2026-08-10T18:15:00Z",
          "updatedAt": "2026-08-12T17:31:57Z",
          "timestamp": "2026-08-12T17:31:57Z",
          "metrics": {
            "reactions": 0,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "ask-review",
            "team/agent-metric-pipelines",
            "team/agent-build",
            "internal"
          ],
          "author": "aiuto",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:03ddae908154521873f4",
        "signalId": "github:DataDog/datadog-agent:pull_request:54702",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54702",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix(agent-integrations): bump AIX embedded Python version in patch upgrade task",
          "text": "### What does this PR do? Adds a new `_prepare_aix_update` step to `tasks/python_version.py` so the `python-version.update` task also bumps `PYTHON_VERSION` in `packaging/aix/lib/env.sh`. Also updates the `upgrade-python-patch-version` workflow's PR description to mention this file, and adds a unit test covering the new function. ### Motivation PR #54696 (the automated Python patch bump) only updated the Omnibus and Bazel Python references. As flagged in [review feedback](https://github.com/DataDog/datadog-agent/pull/54696#discussion_r3755248597), the AIX packaging path (`packaging/aix/lib/env.sh`, sourced by `packaging/aix/stages/02-python.sh`) has its own `PYTHON_VERSION` variable that was left out of sync, so AIX Agent builds continued embedding the old patch version. ### Describe how you validated your changes Ran the existing unit test suite plus the new `TestAixUpdate` test via `dda inv invoke-unit-tests.run --tests python_version` — all 17 tests pass.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54702",
          "createdAt": "2026-08-11T07:02:48Z",
          "updatedAt": "2026-08-12T17:01:24Z",
          "timestamp": "2026-08-12T17:01:24Z",
          "metrics": {
            "reactions": 2,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "team/agent-integrations",
            "team/agent-devx",
            "internal"
          ],
          "author": "chouetz",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:314e73082aedecb0ed18",
        "signalId": "github:DataDog/datadog-agent:pull_request:54713",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54713",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[SBOM] Derive image inUse from workloadmeta",
          "text": "### What does this PR do? The SBOM check computed inUse from imageUsers, a map of image identifier to running container IDs that it maintained from workloadmeta container events. The map was keyed by the Image.ID of the merged container entity, and that field changes shape over a container's lifetime. On Kubernetes the containerd collector reports the image config digest and the kubelet reports the repo digest, and workloadmeta merges its sources in alphabetical order, so the kubelet value wins as soon as it appears. A container starting on a containerd node is therefore registered first under the config digest, a moment later under the repo digest once the kubelet describes it too, and removed only from the second. The config digest entry stayed behind, and that is exactly the key the img.ID fallback looks up, so the image reported inUse=true until the Agent restarted. Nothing reconciled the map, so a dropped event bundle left the same residue. Ask workloadmeta which images have a running container instead. The store is already up to date when an event bundle is handed to the check, and the question is the one the container check behind Live Containers asks, so the two agree by construction and no cache can drift from either. What is left of the old map is the set of images reported in use by the previous bundle, used only to decide when to push an update, so a stale entry can now delay an emission but never produce a wrong inUse. This drops the event ordering and the stopped container cleanup added in #48586, which the store makes unnecessary. Matching a container against the image entity ID, from the same change, stays: it is how a container on containerd names its image. When an image and the container that just started it are described by the same event bundle, they no longer produce an SBOM each. The first of the two used to carry inUse=false, because the container had not been registered yet, and the second corrected it.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54713",
          "createdAt": "2026-08-11T12:21:46Z",
          "updatedAt": "2026-08-12T17:00:10Z",
          "timestamp": "2026-08-12T17:00:10Z",
          "metrics": {
            "reactions": 0,
            "comments": 7
          },
          "labels": [
            "team/agent-security",
            "qa/done",
            "medium review",
            "team/container-integrations",
            "internal"
          ],
          "author": "0intro",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:abca2f98368e04e8a275",
        "signalId": "github:DataDog/datadog-agent:pull_request:54675",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54675",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "add skeletal authored script action",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds skeletal implemenation for authored script actions. This is not available to users as the action is behind a feature flag. [This PR](https://github.com/ddoghq/dd-source/pull/48812) ### Motivation We will be supporting authored scripts where new scripts can be added without needing a new agent release. This is to add a skeletal handler to support it. Further details in [Datadog Authored Script](https://docs.google.com/document/d/1qB2R__ZUkL2xjCDLybJGoaKl5EhpJ-rpy907h0qlRm4/edit?tab=t.0#heading=h.qjl27megtr2p) and [Authored script download and storage RFC](https://datadoghq.atlassian.net/wiki/spaces/ACT/pages/7060063493/RFC+Authored+script+download+storage+and+isolation) ### Describe how you validated your changes TODO ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54675",
          "createdAt": "2026-08-10T19:53:19Z",
          "updatedAt": "2026-08-12T16:58:44Z",
          "timestamp": "2026-08-12T16:58:44Z",
          "metrics": {
            "reactions": 1,
            "comments": 7
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "Madhu-TV",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:9ecaaf34766469af38e9",
        "signalId": "github:DataDog/datadog-agent:pull_request:54788",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54788",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[NETPATH-1108] Remove flaky RC re-poll gate from Dynamic Path e2e test Setup",
          "text": "### What does this PR do? Removes the `SetupSuite` gate in `TestHostTrafficDynamicPathSuite` that waited for the agent's Remote Config poll counter to increase within 2 minutes of pushing the dynamic config. JIRA: [NETPATH-1108](https://datadoghq.atlassian.net/browse/NETPATH-1108) ### Motivation `TestHostTrafficDynamicPathSuite` has been intermittently failing on `main` (~105 failures / ~4,150 runs over 30 days, ~2.5%) since it was first introduced, always aborting in `SetupSuite` with: > `agent did not poll Remote Config after the dynamic config was added` The gate asserted the agent's RC poll counter strictly increment within a 2-minute window. But the agent's RC refresh cadence is `defaultRefreshInterval` (1m) plus exponential backoff on transient poll errors (`pkg/config/remote/service/service.go`), with a backoff ceiling of 2–5 minutes. A short run of transient errors legitimately pushes the next poll past the 2-minute deadline, failing the assertion and tearing down the entire suite before the real test runs. This is a fragile timing assumption in the test, not an agent regression. ### Describe how you validated your changes The gate is redundant: `TestHostTrafficDynamicNetworkPath` already waits (up to 5 minutes) for the RC-admitted network path to appear in fakeintake, which inherently proves the agent polled and applied the config — so removing the setup gate loses no coverage. The initial \"agent has polled at all\" check (`NotZero` polls) is kept, as it is not the flaky assertion. `go vet` passes on the package. E2E will exercise the change in CI.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54788",
          "createdAt": "2026-08-12T15:59:08Z",
          "updatedAt": "2026-08-12T16:52:48Z",
          "timestamp": "2026-08-12T16:52:48Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [
            "short review",
            "team/windows-products",
            "team/network-path",
            "internal"
          ],
          "author": "ken-schneider",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:fd726e461a33550ad311",
        "signalId": "github:DataDog/datadog-agent:pull_request:54148",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54148",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Bump dd-compile-policy to v0.1.13",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? `dd-compile-policy` binary is pinned within the Agent at v0.1.2, which predates https://github.com/DataDog/dd-policy-engine/pull/68 in `dd-policy-engine` that added Docker container evaluators (CONTAINER_IMAGE_TAG, CONTAINER_IMAGE_DIGEST, CONTAINER_NAME, CONTAINER_LABEL) to the schema. `dd-compile-policy` embeds its FlatBuffers schema at build time, so the currently pinned binary has no knowledge of these evaluators. When a policy JSON references one, the generic FlatBuffers parser silently resolves it to `STRING_EVAL_UNKNOWN` (enum value 0) instead of erroring, so any WLS rule using a Docker attribute silently compiles into a no-op. This bumps the pin to v0.1.13, the first release of `dd-policy-engine` that includes the Docker container evaluators. ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54148",
          "createdAt": "2026-07-27T19:58:29Z",
          "updatedAt": "2026-08-12T16:46:44Z",
          "timestamp": "2026-08-12T16:46:44Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "short review",
            "team/agent-build",
            "stale",
            "internal"
          ],
          "author": "annacai21",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:9569e21497572a0f9d20",
        "signalId": "github:DataDog/datadog-agent:pull_request:54775",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54775",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "CONTINT-5539 - use correct kind version and kubeadm version",
          "text": "### What does this PR do? In order to run kubernetes version > v1.37.0 we need to use kind v0.32.0 at least and use kubemad API version v1alpha4. generate the correct kubeadm config file depending on the requested version. ### Motivation fix flaky test ### Describe how you validated your changes run the latest job with kube v1.37.0-rc.0 ✅ run the latest job with kube v1.36.3 ✅ ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54775",
          "createdAt": "2026-08-12T12:05:58Z",
          "updatedAt": "2026-08-12T16:24:55Z",
          "timestamp": "2026-08-12T16:24:55Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "medium review",
            "team/agent-devx",
            "internal"
          ],
          "author": "lavigne958",
          "state": "open",
          "assignees": [
            "lavigne958"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:9b9c5f957111ff50941a",
        "signalId": "github:DataDog/datadog-agent:pull_request:53753",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53753",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(remote-config): expose remote config state over the agent IPC HTTP API",
          "text": "> **⚠️ Deferred (2026-07-28).** Paused pending alignment with the remote-config team on whether `getRemoteConfigState` should be backend-sourced instead of Agent-local. During review, Dario Meloni pointed out the backend already receives this data on every RC poll; investigation confirmed that's true but found no viable customer-scoped backend replacement today (the internal `remote-config-admin` tool is support-only and warehouse-lagged; Fleet Automation's customer-scoped API lacks apply-state data). See the addendum in the [RFC](https://datadoghq.atlassian.net/wiki/spaces/FRM/pages/6996001355) for the full discussion. The other three read actions plus flare generation (#53754, #53756) do not depend on this endpoint and are proceeding independently — see the updated stacked series below. ### What does this PR do? Adds a `GET /agent/remote-config/state` endpoint to the Agent's authenticated IPC HTTP (CMD) API that returns the Remote Config repositories state as JSON. It exposes the same data as the existing `AgentSecure.GetConfigState` gRPC method, registered through the standard `agent_endpoint` provider group from the `rcservice` component (so it inherits the IPC auth-token middleware). When remote config is disabled it responds `503` with a not-initialized error. ### Motivation Originally the first change in a stacked series that exposes a subset of `datadog-agent` CLI actions through the Datadog MCP server, using Action Platform + the co-located Private Action Runner (PAR) as the transport. This endpoint would unblock the `getRemoteConfigState` PAR action (#53755) — now deferred alongside it (see above). ### Describe how you validated your changes `bazel build //comp/remote-config/rcservice/impl:impl` passes; pre-push `go-linter` and `go-test` hooks pass. ### Additional Notes **Status: deferred**, not closed — kept open/draft as the design question is resolved with the remote-config team. `getStatus`/`getDiagnose`/`getConfig`/`generateFlare` no longer depend on this PR (their branches have been rebased to drop this dependency; see #53754/#53756). --- ### Full stacked series **Shipping now (no dependency on this PR):** **datadog-agent** (Go execution layer): 1. DataDog/datadog-agent#53754 — `com.datadoghq.agent` bundle, read-only actions (`getStatus`, `getDiagnose`, `getConfig`) 2. DataDog/datadog-agent#53756 — `generateFlare` action (mutating, confirm-gated) **dd-source** (catalog + MCP tools + authz): 3. ddoghq/dd-source#22260 — `com.datadoghq.agent` private bundle manifest (three read actions + flare) 4. ddoghq/dd-source#22261 — read-only MCP tools 5. ddoghq/dd-source#22262 — confirm-gated mutating MCP tool 6. ddoghq/dd-source#22263 — MCP OBO allow-list (optional hardening) Cross-repo: land datadog-agent #53754/#53756 and dd-source #22260, and ship an agent build containing them, before the dd-source MCP tools (#22261–#22262) work end-to-end. **Deferred (this PR + its dependent):** - DataDog/datadog-agent#53753 — this PR - DataDog/datadog-agent#53755 — `getRemoteConfigState` action Parked pending alignment with the remote-config team — see the RFC addendum linked above.",
          "url": "https://github.com/DataDog/datadog-agent/pull/53753",
          "createdAt": "2026-07-16T15:46:14Z",
          "updatedAt": "2026-08-12T16:22:54Z",
          "timestamp": "2026-08-12T16:22:54Z",
          "metrics": {
            "reactions": 2,
            "comments": 6
          },
          "labels": [
            "team/remote-config",
            "qa/done",
            "medium review",
            "team/agent-build",
            "stale",
            "internal"
          ],
          "author": "louis-cqrl",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:7522c672f3ebc793c9d2",
        "signalId": "github:DataDog/datadog-agent:pull_request:53864",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53864",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "e2e: add local Docker-based Kind provisioner as a cheaper alternative to AWS-VM",
          "text": "## Summary - Adds a local Docker-based Kind provisioner (`testing/provisioners/local/kubernetes`) as a cheaper alternative to the existing AWS-VM-backed Kind provisioner — no dedicated EC2 VM needed for most Kind-based E2E tests. - Brings the local provisioner to feature parity with the AWS one: fakeintake options (memory/retention/dddev-forwarding), dogstatsd-standalone/test-workload/argo-rollout deployment helpers, and a diagnose-on-failure cluster-state dump. - Adds a `kindprovisioner` switch package (`testing/provisioners/kindprovisioner`) that picks between the AWS-VM and local provisioners based on `E2E_PROVISIONER=kind-local` / `E2E_DEV_LOCAL=true`, so test suites don't have to duplicate the switch logic. - Migrates `test/new-e2e/tests/containers/kindvm_test.go` (`TestKindSuite`) onto the shared switch helper. - Adds a new `new-e2e-containers-kind-local` GitLab CI job that runs `TestKindSuite` against a Kind cluster created directly on a `docker-in-docker:amd64` runner, in parallel with (not replacing) the existing `new-e2e-containers-k8s-latest` AWS-VM job — both required to pass. ## Test plan - [x] `dda inv linter.go` on all touched Go packages (0 issues) - [x] `dda inv gitlab.compute-gitlab-ci-config` to confirm the new job resolves correctly (before_script, needs, rules, variables) - [x] `dda inv linter.full-gitlab-ci` / `linter.gitlab-ci-shellcheck` (PASS) - [ ] Verify `new-e2e-containers-kind-local` and `new-e2e-containers-k8s-latest` both pass in this PR's pipeline with equivalent test behavior 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
          "url": "https://github.com/DataDog/datadog-agent/pull/53864",
          "createdAt": "2026-07-20T16:08:15Z",
          "updatedAt": "2026-08-12T16:22:47Z",
          "timestamp": "2026-08-12T16:22:47Z",
          "metrics": {
            "reactions": 1,
            "comments": 8
          },
          "labels": [
            "team/container-platform",
            "long review",
            "team/container-integrations",
            "team/agent-devx",
            "team/agent-build",
            "stale",
            "internal"
          ],
          "author": "KevinFairise2",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:0e527d66e2d345edfa15",
        "signalId": "github:DataDog/datadog-agent:pull_request:53905",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53905",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[FA] Categorize installer OOM/resource-exhaustion errors",
          "text": "## Summary A week-long Error Tracking sweep of installer error categories surfaced this: when the fleet-automation daemon execs a fresh `datadog-installer` child process (for state refresh, install, or experiment operations) and that child crashes at Go-runtime bootstrap because the host is out of memory, threads, or paging capacity — e.g. `fatal error: pageAlloc: out of memory`, `out of memory allocating heap arena metadata`, `runtime: failed to create new OS thread ... errno=11`, `VirtualAlloc ... errno=1455`, `paging file is too small` — the raw multi-line Go panic stack trace gets wrapped verbatim into the returned error via `\"run failed: %w\\n%s\"`. This surfaces to users/Error Tracking as an opaque wall of Go-runtime internals with no actionable signal, indistinguishable from any other subprocess failure. ## Change `pkg/fleet/installer/exec/installer_exec.go`: - Added `isResourceExhaustionCrash(output []byte) bool`, which pattern-matches the known OOM/thread-exhaustion signatures listed above. - Added a sentinel `var ErrResourceExhausted = errors.New(\"installer subprocess crashed due to host resource exhaustion (memory/thread limit)\")`. - `(*installerCmd).Run()` now checks the subprocess's captured stderr against these signatures before falling back to the generic error path. On a match, it returns `fmt.Errorf(\"run failed: %w: %w\", ErrResourceExhausted, err)` — so `errors.Is(err, ErrResourceExhausted)` works for programmatic handling and Error Tracking — instead of echoing the full multi-KB stack trace into the primary error string. The full raw output is still preserved via `pkg/util/log.Debugf` for diagnostics. - Scoped strictly to error categorization/message quality: no retry logic, no pre-flight memory checks, no other call sites touched. `pkg/fleet/installer/exec/installer_exec_test.go` (new): - Table-driven unit tests for `isResourceExhaustionCrash` covering each known signature plus unrelated/empty output (expected `false`). - A test confirming `errors.Is` still unwraps correctly through the `%w: %w` double-wrap used in `Run()`. `pkg/fleet/installer/exec/BUILD.bazel`: - Added the `go_test` target for the new test file and the `pkg/util/log` dependency. ## Status Draft, pending review. This is split out of #53904, which combined this fix with an unrelated Windows-MSI-side fix; splitting per the reviewer's request since the two are independent (different languages, different files, no shared code paths). ## Test plan - [x] `go build ./pkg/fleet/installer/...` passes - [x] `go vet ./pkg/fleet/installer/exec/...` passes - [x] `go test ./pkg/fleet/installer/exec/...` passes, including the new tests - [x] Pre-commit hooks (`go-fmt`, `go-mod-tidy`, `copyright`) passed locally - [ ] Manual/synthetic verification that an installer subprocess OOM crash now returns an error satisfying `errors.Is(err, exec.ErrResourceExhausted)` in a real deployment",
          "url": "https://github.com/DataDog/datadog-agent/pull/53905",
          "createdAt": "2026-07-21T09:03:43Z",
          "updatedAt": "2026-08-12T16:22:44Z",
          "timestamp": "2026-08-12T16:22:44Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "medium review",
            "team/agent-build",
            "team/windows-products",
            "stale",
            "internal"
          ],
          "author": "coignetp",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:e7324287ad4f88c8fe40",
        "signalId": "github:DataDog/datadog-agent:pull_request:54032",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54032",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add experimental prepared startup for Agent rollouts",
          "text": "### What does this PR do? Adds a default-disabled prepared-startup primitive for the core Agent and direct trace Agent. Each process constructs its Fx graph, identifies its own Pod and DaemonSet through the local kubelet Pod list, and waits without starting Fx hooks when an older sibling Pod exists. It publishes `prepared` so native DaemonSet surge can consider the replacement Ready. After Kubernetes removes the old Pod, the replacement publishes `activating`, starts its hooks, then publishes `active`. A fresh install with no sibling activates immediately. Lifecycle state records the writer PID and Linux `/proc` start time so probes cannot accept a stale Prepared marker after a container restart. Kubelet errors, missing self data, and ambiguous Pod ordering fail closed. ### Motivation Agent DaemonSet updates currently delete the old Pod before the replacement image is pulled and its processes are constructed. Slow pulls and startup therefore become collection downtime. Prepared startup lets native `maxSurge` finish image pull, initialization, and Agent construction while the old Agent remains active. ### Describe how you validated your changes - Core lifecycle tests with and without kubelet support passed - Configuration tests passed - Focused Agent lint reported 0 issues - Core Agent and trace Agent builds passed - Commit and pre-push hooks passed, including Go tests and lint ### Additional Notes This is an experimental Linux-only primitive, disabled by default. The first pilot supports only the core Agent and direct trace Agent. Process Agent, system-probe, security Agent, logs, OTel, trace-loader socket activation, and other long-running node-Agent containers remain outside this PR. Coordinated branches: - Operator: https://github.com/DataDog/datadog-operator/pull/3298 - Experimental cluster configuration: https://github.com/DataDog/k8s-datadog-agent-ops/pull/9138",
          "url": "https://github.com/DataDog/datadog-agent/pull/54032",
          "createdAt": "2026-07-23T09:57:12Z",
          "updatedAt": "2026-08-12T16:22:36Z",
          "timestamp": "2026-08-12T16:22:36Z",
          "metrics": {
            "reactions": 1,
            "comments": 8
          },
          "labels": [
            "changelog/no-changelog",
            "team/agent-apm",
            "long review",
            "qa/rc-required",
            "team/agent-runtimes",
            "team/agent-configuration",
            "team/agent-build",
            "stale",
            "internal",
            "team/fleet-automation"
          ],
          "author": "AliDatadog",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:76438ad07926e2048256",
        "signalId": "github:DataDog/datadog-agent:pull_request:54134",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54134",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "When uploading artifacts to yumtesting, also download the datadog-fip…",
          "text": "…s-proxy and upload it too <!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54134",
          "createdAt": "2026-07-27T14:25:56Z",
          "updatedAt": "2026-08-12T16:22:31Z",
          "timestamp": "2026-08-12T16:22:31Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "short review",
            "team/agent-devx",
            "stale",
            "internal"
          ],
          "author": "jeremy-hanna",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:599b6bc873ff9ecb7e2e",
        "signalId": "github:DataDog/datadog-agent:pull_request:54138",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54138",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CWS] Persist profile when cgroup is deleted / agent shutdown",
          "text": "### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54138",
          "createdAt": "2026-07-27T16:44:18Z",
          "updatedAt": "2026-08-12T16:22:29Z",
          "timestamp": "2026-08-12T16:22:29Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "component/system-probe",
            "team/agent-security",
            "short review",
            "stale",
            "internal"
          ],
          "author": "kovagsm",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:b7c50565f45fb3b9faf9",
        "signalId": "github:DataDog/datadog-agent:pull_request:54145",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54145",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[cisco-sdwan] Add config detail to max_pages pagination error",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Enriches the error returned when the Cisco SD-WAN paginated API hits the`max_pages` limit. The error now reports how many pages were fetched, that more data remains, and the current `max_count` / `max_pages` values: Example: `reached max_pages limit after fetching 20 pages and more data remains; increase max_count and/or max_pages to collect all data. current_configs: max_count=500, max_pages=20` ### Motivation On large SD-WAN environments endpoints can return more pages than `max_pages` allows, so collection stops and those metrics go missing for the collection period. The previous error was missing how much data was being pulled. Displaying the page count and the current config values helps with being able to tune the collection. ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54145",
          "createdAt": "2026-07-27T19:28:03Z",
          "updatedAt": "2026-08-12T16:22:26Z",
          "timestamp": "2026-08-12T16:22:26Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "qa/no-code-change",
            "short review",
            "team/ndm-integrations",
            "stale",
            "internal"
          ],
          "author": "ddog-nasirthomas",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:3ab2d99bd71f31522738",
        "signalId": "github:DataDog/datadog-agent:pull_request:54147",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54147",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "experiment(observer): add configurable time-aware log count view",
          "text": "## What changed This adds a testbench-only, timestamp-aware detector view for log-derived occurrence counts. - Keep extractor output sparse in shared Observer storage. - Present completed fixed-window counts and causal forward zeros only when detectors read log `.count` series. - Never backfill zeros before a series is first observed. - Stop virtual zeros after a configurable idle TTL (300 seconds by default). - Leave ordinary metric-series missing-data semantics unchanged. - Expose `--time-aware-log-count-series`, `--log-count-window-seconds` (1, 5, or 10; default 5), and `--log-count-idle-ttl-seconds` through the testbench and Invoke eval tasks. - Record raw-storage versus logical-detector observation statistics in testbench output. - Add focused unit/integration coverage and save the detector-matrix results. ## Why Sparse log events are not evenly spaced metric samples, but the current detectors generally interpret adjacent points that way. Materializing zero-filled one-second series improved some detectors, but expanded storage and increased baseline false positives. This POC instead constructs an elapsed-time count view at the detector read boundary without writing synthetic points into shared storage. ## Results Across 12 log scenarios and Holt, ScanMW, ScanWelch, Tukey, and BOCPD: | Representation | Mean F1 | Baseline FPs | |---|---:|---:| | Sparse | 21.36% | 53 | | Materialized 1s | 29.81% | 143 | | Time-aware 1s | 20.65% | 138 | | **Time-aware 5s** | **39.15%** | **67** | | Time-aware 10s | 11.90% | 26 | The five-second configuration improves mean F1 by 17.79 percentage points over sparse input and 9.34 points over materialized one-second input, while keeping false positives much closer to the sparse control. The summarized results remain under `results/time-aware-count-view/`; raw scorer outputs are retained only on the local stacked experiment branch. These results were selected on the same scenario set and used the stacked fuzzy-tokenizer experiment, so they are evidence for continuing the design—not a held-out production accuracy estimate. ## Known limitations - This is intentionally testbench-only; it does not enable the representation in production wiring. - Detector warmups and windows are still point-count based. Changing bucket width therefore also changes their elapsed-time horizon. - The adapter currently reconstructs overlapping virtual ranges on reads. ScanMW/ScanWelch produced roughly 33 million logical observations in this evaluation, so caching/incremental maintenance is needed before production use. - Kafka regressed substantially and Cassandra regressed slightly at five seconds; those cases need dominant-series attribution before choosing a default. ## Validation - `dda inv test --targets=./comp/anomalydetection/observer/impl/` - `dda inv test --targets=./internal/qbranch/anomalydetection-testbench/...` - `dda inv anomalydetection.build-testbench` - CLI help and invalid-window validation smoke checks - modified-package Go linter: 0 issues - full repository pre-push hooks: passed",
          "url": "https://github.com/DataDog/datadog-agent/pull/54147",
          "createdAt": "2026-07-27T19:55:19Z",
          "updatedAt": "2026-08-12T16:22:24Z",
          "timestamp": "2026-08-12T16:22:24Z",
          "metrics": {
            "reactions": 1,
            "comments": 7
          },
          "labels": [
            "long review",
            "team/agent-build",
            "stale",
            "internal"
          ],
          "author": "Eokye",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:8c832da04732f43ecde3",
        "signalId": "github:DataDog/datadog-agent:pull_request:54159",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54159",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CWS] Fix glob bypass",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54159",
          "createdAt": "2026-07-28T10:07:51Z",
          "updatedAt": "2026-08-12T16:22:20Z",
          "timestamp": "2026-08-12T16:22:20Z",
          "metrics": {
            "reactions": 2,
            "comments": 7
          },
          "labels": [
            "component/system-probe",
            "team/agent-security",
            "short review",
            "stale",
            "internal"
          ],
          "author": "kovagsm",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:1a94847249e8e5ea6e3f",
        "signalId": "github:DataDog/datadog-agent:pull_request:54162",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54162",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "DO NOT MERGE: validate datadog-agent-buildimages toolchains_mass branch",
          "text": "## Summary Points at the `linux_test_only` image and crosstool-ng toolchains published by the `chouquette/toolchains_mass` branch in `datadog-agent-buildimages` (new toolchain build+publish CI stage), to confirm the agent still builds with them before that branch merges. - `.gitlab-ci.yml`: `CI_IMAGE_LINUX` → test-only image from that branch's pipeline - `bazel/patches/gcc-toolchain/0001-adapt-to-our-ctng-toolchain.patch`: x86_64/aarch64 toolchain URLs → artifacts published to the `branches/` channel in `dd-agent-build-artifacts` **Do not merge**: the toolchain URLs are pinned to the `branches/` channel, specific to that feature branch. Once it merges to `main`, these need to move to the `main/` channel (or this PR gets closed once validated). ## Test plan - [ ] CI is green on this branch (regular Linux build + Bazel build)",
          "url": "https://github.com/DataDog/datadog-agent/pull/54162",
          "createdAt": "2026-07-28T11:05:51Z",
          "updatedAt": "2026-08-12T16:22:19Z",
          "timestamp": "2026-08-12T16:22:19Z",
          "metrics": {
            "reactions": 1,
            "comments": 8
          },
          "labels": [
            "short review",
            "team/agent-devx",
            "team/agent-build",
            "stale",
            "internal"
          ],
          "author": "chouquette",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:1cf6cb9ce608dad00501",
        "signalId": "github:DataDog/datadog-agent:pull_request:54786",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54786",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Pedro.cordeiro/macos ec2 snapshot poc 2",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54786",
          "createdAt": "2026-08-12T15:08:50Z",
          "updatedAt": "2026-08-12T16:09:31Z",
          "timestamp": "2026-08-12T16:09:31Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [],
          "author": "PedroCordeiroDataDog",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:426a5e454412fb800b94",
        "signalId": "github:DataDog/datadog-agent:pull_request:52758",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:52758",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[otel-agent] Use zstd compression for all signals",
          "text": "### What does this PR do? Makes the DDOT collector (`otel-agent`) compress **every** signal with `zstd`, replacing the previous per-signal mix (zlib for metrics, gzip for traces, zstd for logs): - **Metrics**: use the config-driven metrics compressor (`metricscompression/fx`) instead of the hardcoded zlib module; defaults to **zstd level 3**, overridable via `serializer_zstd_compressor_level`. - **Logs**: pin zstd and default `logs_config.zstd_compression_level` to **3** (overridable). - **Traces**: use the existing `fx-zstd` module (zstd at `BestSpeed`); the trace level is intentionally fixed. - **Host metadata**: rides the same serializer compressor as metrics (no dedicated knob), so it becomes zstd automatically. Also adds tests that guard against future per-signal compression divergence. ### Motivation The DDOT exporter used a different compression algorithm per signal, which is inconsistent and harder to reason about. Standardizing on `zstd` gives a consistent algorithm across metrics/traces/logs and a better compression ratio, with the level configurable per signal. ### Describe how you validated your changes - `dda inv otel-agent.build` passes; `dda inv linter.go` → **0 issues** on changed packages; `gofmt` clean. - **Unit** (`cmd/otel-agent/config`): asserts metrics and logs resolve to the **same** algorithm (zstd) at level 3, that the level stays env-overridable, and that **host metadata** uses that same serializer compressor (so it is zstd too). - **Integration** (`comp/otelcol/otlp/integrationtest`): now decodes trace payloads as zstd — verifies traces ship valid zstd end-to-end. Passes locally (`dda inv otel-agent.integration-test`). - **E2E** (`TestOTelAgentComplete/TestOTLPCompression`): asserts metrics, traces, and logs reach fakeintake with `Content-Encoding: zstd` (requires the e2e infra to run). ### Additional Notes - **Scope is the standalone `otel-agent`.** The core Agent, trace-agent, host-profiler, and OSS exporter are unaffected — they use their own compression modules (`metricscompression/fx`, `fx-zstd`, `fx-gzip`, `fx-otel` respectively). - **The v2 metrics intake is preserved** (`use_v3_api.series.enabled` stays `false`); moving series to v3 is a separate effort. ⚠️ **Reviewers:** please confirm the v2 series intake (`/api/v2/series`) accepts `Content-Encoding: zstd` — the core Agent uses zstd→v3 for series by default, so this exact combination isn't exercised today. The new e2e test validates it against fakeintake. - **Exhaustive compression coverage** (all the DD exporter's submission clients): after this change, every active intake submission in the otel-agent is zstd — **metrics (series/sketches), host metadata, logs, traces** — *except* **APM stats**, which stays **gzip** (hardcoded in `pkg/trace/writer/stats.go`, shared with the trace-agent; out of scope here, separate conversation). The orchestrator/K8s-objects sub-exporter already uses zstd and is disabled by default. Internal exporter telemetry (`metricsclient`, COAT/gateway gauges) is scraped Prometheus/OTel-meter telemetry, not an intake submission. 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
          "url": "https://github.com/DataDog/datadog-agent/pull/52758",
          "createdAt": "2026-06-25T00:02:17Z",
          "updatedAt": "2026-08-12T16:07:00Z",
          "timestamp": "2026-08-12T16:07:00Z",
          "metrics": {
            "reactions": 1,
            "comments": 10
          },
          "labels": [
            "long review",
            "qa/rc-required",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "truthbk",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:5c6916aa5e7e3d123e3e",
        "signalId": "github:DataDog/datadog-agent:pull_request:54787",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54787",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Pedro.cordeiro/macos ec2 snapshot poc 3",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54787",
          "createdAt": "2026-08-12T15:09:00Z",
          "updatedAt": "2026-08-12T16:01:59Z",
          "timestamp": "2026-08-12T16:01:59Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [],
          "author": "PedroCordeiroDataDog",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:8bc4a981fd256561e06c",
        "signalId": "github:DataDog/datadog-agent:pull_request:53700",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53700",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[NTWK-799] Allow custom namespaces on Synthetics to enable NDM resolution",
          "text": "### What does this PR do? This PR modifies the Synthetics Collector to: - Send NDM namespace on Network Path tests by default (in line with the Network Path integration) - Allows the back end to send `namespace` as part of a test config and have that namespace propagate to the Network Path backend. UI changes would be required for this path to be used. ### Motivation NTWK-799, a customer reported that NDM devices aren't showing in their Network Paths, upon investigation these were Agent based Synthetic tests and the devices in question have a specific namespace that they're a part of. Today, the Synthetics runner never reads the `namespace` from anywhere. This change will put it in line with other Network Path tests and the customer should in the short-medium term just set this in the YAML until the changes can be implemented on the Synthetics UI. ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/53700",
          "createdAt": "2026-07-15T20:17:18Z",
          "updatedAt": "2026-08-12T15:53:59Z",
          "timestamp": "2026-08-12T15:53:59Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "medium review",
            "team/agent-build",
            "team/network-path",
            "internal"
          ],
          "author": "ken-schneider",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:1f40d53582caf2fa1e54",
        "signalId": "github:DataDog/datadog-agent:pull_request:54438",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54438",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Remove deprecated Install-Datadog.ps1 script",
          "text": "### What does this PR do? Removes the deprecated `Install-Datadog.ps1` script and its build/sign/deploy CI jobs, and migrates the Windows e2e install coverage that depended on it over to `datadog-installer.exe`. ### Motivation The script was already deprecated in favor of `datadog-installer.exe` (see the [deprecation note](https://github.com/DataDog/datadog-agent/blob/main/releasenotes/notes/deprecated-install-ps1-0cba33afa6fa2347.yaml)). ### Describe how you validated your changes Existing e2e coverage for the script was merged into the exe-based suite rather than dropped; these suites run in CI on this PR. ### Additional Notes Also removed `TestInstallIgnoreMajorMinor` — the behavior it asserted is no longer true now that Windows honors those variables.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54438",
          "createdAt": "2026-08-04T19:12:08Z",
          "updatedAt": "2026-08-12T15:48:31Z",
          "timestamp": "2026-08-12T15:48:31Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "team/agent-delivery",
            "long review",
            "team/container-integrations",
            "team/agent-devx",
            "team/windows-products",
            "internal"
          ],
          "author": "clarkb7",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:7491089c83012147f23b",
        "signalId": "github:DataDog/datadog-agent:pull_request:53411",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53411",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "sbom: remove the Trivy on-disk cache",
          "text": "SBOM scanning kept a BoltDB cache on disk under sbom.cache_directory to reuse per-layer analysis results across scans. In practice it earned little. Only the legacy tarball scan path used it. The overlayfs path has run without it by default since #48004, filesystem scans never used it, and image rescans are off by default. Remove the cache subsystem entirely instead of porting it to memory. Every scan now uses the in-memory cache that the overlayfs and filesystem paths already used. It is created per scan and freed when the scan returns, so Trivy still gets the cache object it needs within a scan without anything touching disk. The in-memory cache is guarded by a mutex so a fast scan that analyzes image layers in parallel can store results safely. This drops the BoltDB layer, the persistent LRU cache, the workloadmeta garbage collector, and the scanner janitor. It also removes a leaked telemetry goroutine and a latent bug where the sbomgen CLI could create a fanal directory in the working directory. The options sbom.cache_directory, sbom.clear_cache_on_exit, sbom.cache.max_disk_size, sbom.cache.clean_interval, and sbom.container_image.overlayfs_disable_cache are removed and now ignored. The telemetry metrics sbom.cache_disk_size, sbom.cache_hits_total, and sbom.cache_misses_total are removed.",
          "url": "https://github.com/DataDog/datadog-agent/pull/53411",
          "createdAt": "2026-07-08T19:59:01Z",
          "updatedAt": "2026-08-12T15:47:51Z",
          "timestamp": "2026-08-12T15:47:51Z",
          "metrics": {
            "reactions": 0,
            "comments": 5
          },
          "labels": [
            "team/agent-security",
            "qa/done",
            "long review",
            "team/container-integrations",
            "team/agent-configuration",
            "team/agent-build",
            "stale",
            "internal"
          ],
          "author": "0intro",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:96c5e2e5279a679f334b",
        "signalId": "github:DataDog/datadog-agent:pull_request:54631",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54631",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[Backport main]  Changelog update for 7.82.1 release",
          "text": "Backport 13cef24437a2a0c3c3b8c202426c26ea1458c282 from #54627. ___",
          "url": "https://github.com/DataDog/datadog-agent/pull/54631",
          "createdAt": "2026-08-10T12:23:37Z",
          "updatedAt": "2026-08-12T15:46:07Z",
          "timestamp": "2026-08-12T15:46:07Z",
          "metrics": {
            "reactions": 2,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "backport",
            "bot",
            "team/container-platform",
            "team/agent-delivery",
            "short review",
            "team/container-integrations",
            "internal"
          ],
          "author": "dd-octo-sts[bot]",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:a17176d4459428a43d8e",
        "signalId": "github:DataDog/datadog-agent:pull_request:54195",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54195",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Improve E2E test-writing skill",
          "text": "### What does this PR do? Rewrites the `write-e2e` skill from a table of pointers into a procedure that carries a change from scope to merged test, with the lookup material split into five reference files loaded only when their trigger fires. The skill now works out what needs covering from the current diff when no target is named, gates that scope through `e2e-audit` before reading any implementation, steers authors into an existing suite instead of a new one, and finishes with verification gates that share a single provisioned environment rather than provisioning three times. Other notable changes: - Several documents named provisioner options, client methods, or package paths that do not exist, so copying from any of them produced a compile error or a dead link. Each now names something that exists, and `dockeragentparams.WithEnvironmentVariables` gained the doc comment separating it from the option that reaches the Agent process. - Root `AGENTS.md` described context inheritance as importing the parent `CLAUDE.md`, which re-reads files the harness has already loaded. It now says parent context arrives on its own, and the two files that followed the old pattern no longer import their parent. - `docs/public/guidelines/contributing.md` documented two of the three QA labels the tooling enforces; `qa/rc-required` is now defined alongside them. ### Motivation E2E tests are expensive to write and expensive to get wrong: a test that never runs in CI gives false confidence, and a suite sharing a Pulumi stack name with a sibling destroys that sibling's infrastructure mid-run with no error message. The previous skill was a list of files to read, which left every one of those decisions to be rediscovered. Several of the documents it pointed at were actively wrong. Copying the provisioner options from either Go doc comment, the framework `AGENTS.md` table, the Cursor rule, or the public how-to produced code that does not compile, and the how-to's sample violated the reliability rules in `test/new-e2e/codereview_guideline.md` that the same page links to. Recording those forms as traps to avoid only helps whoever loads the file that records them, so they are fixed where they were written. ### Describe how you validated your changes Every claim now written down was checked against the repository rather than carried over: provisioner paths and constructors, environment struct fields, OS descriptors, fakeintake client methods, GitLab job and template names, rule template names, agentparams options, and the section anchors of every cross-reference. The dynamic test skipping section was traced end to end before being written, through the rule in `.gitlab-ci.yml`, the `--impacted` flag and breakglass conditions in `.gitlab/test/e2e/e2e.yml`, the executor call in `tasks/new_e2e_tests.py`, and the skip-list computation in `tasks/libs/dynamic_test/index.py`. It previously said the executor selects jobs from coverage data and that a `changes` rule is a floor; it selects tests within a job that the rule has already created, which is the opposite trade, and the earlier wording would have led someone to write a narrower rule than they wanted. The QA label wording was taken from `tasks/github_tasks.py`, which holds the enforced set and the text of the bot message, rather than from the Confluence page both it and the bot link to, because that page misspells one of the three labels. ### Additional Notes Two framework issues are documented here rather than fixed, both worth their own change. - The stack name is derived from the suite's struct type name with no collision detection, so the rule that each entry point needs its own type is enforced only by whoever read the docs, and the existing tree is unguarded; failing fast in `e2e.Run` on a duplicate would replace a silent teardown with a clear error. - AWS provisioners nest their options while Azure, GCP, and local ones are flat, which is the single most-repeated fact across these files; thin forwarding options on the AWS provisioners would remove the need to state it at all. On the Confluence side, the page describing how to add an e2e job is now superseded by `references/ci-wiring.md`: it names a config file path that does not exist, an artifact job that has been renamed, and a target directory that was renamed, and it never mentions job ownership. It should be replaced by a pointer rather than migrated. The QA best-practices page that `tasks/github_tasks.py` links to can point at `contributing.md` now. The troubleshooting content in \"Common E2E issues\" has no in-repo equivalent and is the strongest candidate for migration into `docs/public`, but several of its entries reference tooling that has moved, so it needs per-entry verification instead of a copy.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54195",
          "createdAt": "2026-07-29T08:32:11Z",
          "updatedAt": "2026-08-12T15:38:35Z",
          "timestamp": "2026-08-12T15:38:35Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "long review",
            "team/agent-devx",
            "internal"
          ],
          "author": "ofek",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:ca8245cec210e230b2d9",
        "signalId": "github:DataDog/datadog-agent:pull_request:54333",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54333",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Build with race detector",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Build with race detector. ### Motivation Make a custom build and give it a shot internally, to see if we can detect races. ### Describe how you validated your changes n/a ### Additional Notes [AGENTRUN-1159]: https://datadoghq.atlassian.net/browse/AGENTRUN-1159?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54333",
          "createdAt": "2026-08-03T05:47:18Z",
          "updatedAt": "2026-08-12T15:33:57Z",
          "timestamp": "2026-08-12T15:33:57Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "do-not-merge/hold",
            "changelog/no-changelog",
            "team/agent-apm",
            "component/system-probe",
            "team/agent-security",
            "team/ebpf-platform",
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-metric-pipelines",
            "team/agent-devx",
            "team/container-experiences",
            "team/windows-products",
            "team/action-platform",
            "team/profiling-full-host",
            "internal",
            "team/fleet-automation"
          ],
          "author": "pgimalac",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:724d7eaac2191acfd9b2",
        "signalId": "github:DataDog/datadog-agent:pull_request:53982",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53982",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Pedro.cordeiro/macos ec2 snapshot poc",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Introduces a shared pool of macOS EC2 Dedicated Hosts for the E2E test framework, so macOS test runs stop provisioning (and tearing down) a brand-new Dedicated Host + instance every time. - **Pool package** (`test/e2e-framework/resources/aws/ec2/pool`): discovers idle, tagged macOS EC2 instances and manages their lifecycle via lease records stored in S3, using conditional writes (ETag/If-Match) to arbitrate concurrent acquisition: - `Acquire` claims an idle instance from the pool (`AcquireIdleInstance`), or falls back to a per-developer local instance lookup/provisioning path (`LocalProvisionOptions`) outside CI. - Leases track `idle`/`in-use` status, owner, and `leased_at`, and are namespaced per owner to avoid collisions. - `RevertAndRelease` reverts an instance's root volume to the lease's baseline AMI and republishes it as `idle` on teardown; `RevertInPlace` re-reverts and re-publishes as `in-use` for local dev reuse. - `PublishInitialLease` registers a brand-new pool member's first lease out-of-band (used when auto-provisioning on a local cache miss). - **Provisioning wiring** (`test/e2e-framework/resources/aws/ec2/vm.go`): macOS VM creation now imports an existing pool member (pinning `HostID`/`SubnetID`/AMI via `pulumi.Import` + `IgnoreChanges`, and `RetainOnDelete` so Pulumi never destroys pooled instances) instead of always creating a fresh Dedicated Host. On a local cache miss, it provisions a new Dedicated Host/instance through ordinary Pulumi resources and registers it as a new pool member. - **Teardown wiring** (`test/e2e-framework/testing/e2e/suite.go`): `BaseSuite.releasePoolInstanceIfAny` reverts and releases the pool instance backing a suite's environment at teardown, replacing ad hoc destroy-based cleanup for macOS hosts. - **Bypass flag**: `E2E_MACOS_POOL_ENABLED` (default enabled) lets a run opt out of the pool entirely and fall back to the pre-existing per-run Dedicated Host provisioning; it's meant to be removed once the pool is validated and trusted as the default. - CI-run detection now checks the `CI` env var, so local runs consistently take the per-developer local-provisioning path. ### Motivation Every macOS E2E test run previously stood up a new AWS EC2 Dedicated Host that was used once and then torn down — but AWS bills Dedicated Host allocations in 24-hour minimum increments, so each single test run paid for a full day of macOS instance time. A shared pool of pre-baked, leasable hosts amortizes that 24h allocation across many runs via acquire/release against S3-backed lease state. See [WINA-2931](https://datadoghq.atlassian.net/browse/WINA-2931). ### Describe how you validated your changes - Ran `TestMacosInstallScript` locally in CI-mode (`E2E_PIPELINE_ID` forced) and in local-provisioning mode against a live pool, confirming warm-import acquisition and correct root-volume revert/release on teardown. - Ran four simultaneous `TestMacosInstallScript` invocations against a 2-member pool to exercise acquire-retry contention: the two extra runs correctly queued and waited on `pool.Acquire`'s retry loop until a member was released, then all four passed. - Validated the `E2E_MACOS_POOL_ENABLED=false` bypass path falls back to the pre-existing per-run Dedicated Host provisioning unchanged. ### Additional Notes [WINA-2931]: https://datadoghq.atlassian.net/browse/WINA-2931?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/53982",
          "createdAt": "2026-07-22T10:05:14Z",
          "updatedAt": "2026-08-12T15:31:09Z",
          "timestamp": "2026-08-12T15:31:09Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "PedroCordeiroDataDog",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:d4fc4c835af4547047fb",
        "signalId": "github:DataDog/datadog-agent:pull_request:54330",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54330",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "docs(ncm): document network_config_management conf.yaml.example",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Populates `cmd/agent/dist/conf.d/network_config_management.d/conf.yaml.example` with the `init_config` and instance-level options supported by the Network Config Management (NCM) check, sourced from `pkg/networkconfigmanagement/config/config.go` (namespace, collection intervals, SSH connection settings, device `ip_address`/`profile`, and `auth` credentials). ### Motivation The example config was left empty (copied from an empty test fixture) when the NCM default profiles were moved to internal directories in #43357. ### Describe how you validated your changes - Verified the example parses as valid YAML. - Verified documented fields/defaults match `pkg/networkconfigmanagement/config/config.go` (`InitConfig`, `DeviceInstance`, `AuthCredentials`, `SSHConfig`). ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54330",
          "createdAt": "2026-08-03T04:38:45Z",
          "updatedAt": "2026-08-12T15:29:56Z",
          "timestamp": "2026-08-12T15:29:56Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/ndm-integrations",
            "team/agent-integrations",
            "internal"
          ],
          "author": "ian28223",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:3ddc9207f37083c9408f",
        "signalId": "github:DataDog/datadog-agent:pull_request:54444",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54444",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Update dependency DataDog/dd-apm-library-python to v4.13.0",
          "text": "This PR contains the following updates: | Package | Update | Change | |---|---|---| | DataDog/dd-apm-library-python | minor | `4.12.0` → `4.13.0` | --- > [!WARNING] > Some dependencies could not be looked up. Check the [Dependency Dashboard](../issues/33469) for more information. --- ### Configuration 📅 **Schedule**: (in timezone Europe/Paris) - Branch creation - At 12:00 AM through 04:59 AM and 10:00 PM through 11:59 PM, Monday through Friday (`* 0-4,22-23 * * 1-5`) - Only on Sunday and Saturday (`* * * * 0,6`) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/DataDog/datadog-agent). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0NC4xMS40IiwidXBkYXRlZEluVmVyIjoiNDQuMjQuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiY2hhbmdlbG9nL25vLWNoYW5nZWxvZyIsImRlcGVuZGVuY2llcyIsInFhL25vLWNvZGUtY2hhbmdlIl19-->",
          "url": "https://github.com/DataDog/datadog-agent/pull/54444",
          "createdAt": "2026-08-05T00:07:19Z",
          "updatedAt": "2026-08-12T15:25:37Z",
          "timestamp": "2026-08-12T15:25:37Z",
          "metrics": {
            "reactions": 2,
            "comments": 17
          },
          "labels": [
            "changelog/no-changelog",
            "dependencies",
            "qa/no-code-change",
            "short review",
            "ask-review",
            "stop-updating",
            "team/windows-products",
            "internal"
          ],
          "author": "renovate[bot]",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:2233066a0a09039534db",
        "signalId": "github:DataDog/datadog-agent:pull_request:54055",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54055",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "rtloader: Test ignored event_object field",
          "text": "### What does this PR do? Adds an explicit rtloader A/B regression test proving that otherwise identical Python events produce identical callback output with and without the unsupported `event_object` dictionary key. ### Motivation This documents the Agent-side behavior relied on by DataDog/integrations-core#24611, which removes an MD5-derived vSphere `event_object` value. The existing general event test supplied the key but did not explicitly assert that it is ignored. ### Describe how you validated your changes - `GOPROXY=https://proxy.golang.org,direct dda inv rtloader.test` - Pre-commit `go-fmt` and repository checks passed. - Pre-push modified-package `go-test` and `go-linter` checks passed. - Manual Agent 7.81.2 system proof: `agent check --json` retained an `aggregation_key` sentinel and omitted `event_object`; the decoded raw zstd `/intake/` request captured by fake intake did the same. ### Additional Notes This is test-only and does not change Agent runtime behavior, so it does not need a Reno release note.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54055",
          "createdAt": "2026-07-23T16:46:13Z",
          "updatedAt": "2026-08-12T15:12:47Z",
          "timestamp": "2026-08-12T15:12:47Z",
          "metrics": {
            "reactions": 2,
            "comments": 6
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "team/agent-runtimes",
            "stale",
            "internal"
          ],
          "author": "nubtron",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:978f59a888e0bac2bad9",
        "signalId": "github:DataDog/datadog-agent:pull_request:54718",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54718",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Use hermetic MSVC and msbuild to build cpython on Windows",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Previous implementation relied on the local installation of MSVC and msbuild to build cpython. A custom repository rule would verify version of the installed MSVC that worked perfectly fine inside of build images. Unfortunately, Windows Updates do bump MSVC as well, so at some point the build started to fail on the Windows host (not inside of the container) due to msbuild version mismatch. One of the potential solutions was to relax version check but that would inevitably introduce caching issues when we can't efficiently share cache across machines unable to ensure that everyone is using the same MSVC. Thus, this PR targets to introduce a fully hermetic MSVC and msbuild distribution that is fully managed by Bazel. We use [toolchains_msvc](https://github.com/Dragnalith/toolchains_msvc) as basis applying a patch on top of that to, first, stop filtering out msbuild and, second, expose additional headers and dlls that are required to make this whole enterprise work. There is one more consumer for msbuild - `libdatadog-interop.dll`. This will be handled in a follow up PR.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54718",
          "createdAt": "2026-08-11T13:10:35Z",
          "updatedAt": "2026-08-12T15:07:54Z",
          "timestamp": "2026-08-12T15:07:54Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "JSGette",
          "state": "closed",
          "assignees": [
            "JSGette"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:bb492836c7aa9ab7c452",
        "signalId": "github:DataDog/datadog-agent:pull_request:54298",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54298",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Titouan.guesdon/clusteragent gomemlimit",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds support for `runtime.gomemlimit` in vertical scaling recommendations. When the backend recommendation includes a `Gomemlimit` value for a container, the cluster agent now: 1. Parses `RuntimeValues` (keyed by container name) from the autoscaling backend response 2. Includes `RuntimeValues` in the recommendation hash so changes are detected correctly 3. Injects/updates the `GOMEMLIMIT` environment variable on pods via the admission webhook (`pod_patcher`) 4. Forces a pod rollout (instead of in-place resize) when `RuntimeValues` are present, since env vars cannot be updated on running containers via `pods/resize` 5. Persists `RuntimeValues` to the DPA status annotation so HA follower replicas can reconstruct the full recommendation without hitting the backend ### Motivation Go applications expose a `GOMEMLIMIT` env var to cap the Go runtime's memory usage. Vertical scaling recommendations from the backend can now include this value alongside CPU/memory resource requests/limits, allowing the cluster agent to apply it end-to-end. ### Describe how you validated your changes Unit tests in `pod_patcher_test.go` cover: - Injection of `GOMEMLIMIT` when not present - Update of `GOMEMLIMIT` when the value changes - Clearing of `ValueFrom` when the env var was previously sourced from a ConfigMap/Secret (Kubernetes rejects env vars with both `Value` and `ValueFrom` set) ### Additional Notes - `RuntimeValues` are included in the `ResourcesHash` so any change to `GOMEMLIMIT` triggers a new recommendation cycle - Constraints filtering (`applyVerticalConstraints`) also prunes `RuntimeValues` for containers that are dropped, keeping hash consistency",
          "url": "https://github.com/DataDog/datadog-agent/pull/54298",
          "createdAt": "2026-07-31T12:37:49Z",
          "updatedAt": "2026-08-12T14:50:16Z",
          "timestamp": "2026-08-12T14:50:16Z",
          "metrics": {
            "reactions": 1,
            "comments": 7
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "medium review",
            "team/agent-build",
            "internal"
          ],
          "author": "TitouanGuesdon",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:5e24477717cd04fa576a",
        "signalId": "github:DataDog/datadog-agent:pull_request:54585",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54585",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "ebpf: validate runtime-compiler cache directory and open cached objects via verified fd",
          "text": "### What does this PR do? Tightens how system-probe's runtime-compiled eBPF object cache is created and consumed: - Adds `secureRuntimeDir`, which creates the runtime-compiler output directory root-only (`0700`) and verifies that it — and every ancestor up to the filesystem root — is a real directory owned by root and not writable by other users. The sticky bit is accepted for the default `/var/tmp` parent. If the tree is not under root's control, runtime compilation is skipped instead of using it. - Adds `VerifyAssetPermissionsAndOpen`, which opens the compiled object with `O_NOFOLLOW` and checks ownership/permissions on the returned file descriptor. The runtime compiler and `GetReader` now consume that descriptor directly instead of re-opening the file by path, so the bytes that are loaded are the same bytes that were verified. - Treats only a regular file as a valid cache entry (a non-regular entry is removed and recompiled). ### Motivation The runtime-compiler cache defaults to a location under the world-writable `/var/tmp`, and the compiled object was previously verified and then re-opened by path in two separate steps. Making the directory root-owned and reusing the verified descriptor keeps the whole compile → verify → kernel-load path under root's control and removes the second path resolution. Hardening / robustness improvement. ### Describe how you validated your changes - New unit tests for the rejection paths: `O_NOFOLLOW` symlink rejection and non-root-owned file rejection (`permissions_test.go`); non-root-owned and symlinked-component cache directory rejection (`asset_test.go`). - Ran `dda inv test --targets=./pkg/ebpf/bytecode/` and `--targets=./pkg/ebpf/bytecode/runtime/ --build-include=linux_bpf` — all pass. - Manually validated on an Ubuntu 24.04 (kernel 6.8, arm64) VM with `enable_runtime_compiler: true`, `enable_co_re: false`, `allow_precompiled_fallback: false`: - Correctly provisioned host: `tracer.c` / `conntrack.c` runtime-compiled and loaded into the kernel; cache tree created `root:root 0700`. No behavior change. - Directory pre-created by a non-root user: system-probe declines to use it (`refusing to use compiler output directory: … is not owned by root`) and the module falls back cleanly instead of loading from the untrusted location. ### Additional Notes No release note is included in this PR (a `changelog/no-changelog` label will be needed to satisfy the reno CI check).",
          "url": "https://github.com/DataDog/datadog-agent/pull/54585",
          "createdAt": "2026-08-07T15:49:30Z",
          "updatedAt": "2026-08-12T14:42:41Z",
          "timestamp": "2026-08-12T14:42:41Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/ebpf-platform",
            "qa/done",
            "long review",
            "team/agent-build",
            "internal"
          ],
          "author": "mbertrone",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:8fd589643eb9a75c53e1",
        "signalId": "github:DataDog/datadog-agent:pull_request:53246",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53246",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "HA(e2e): Move tests to RC fakeintake to fix flakiness",
          "text": "### What does this PR do? Update HA Agent failover test to rely on the fakeintake RC instead of the real backend, that is very flaky because of conflicts ### Motivation Fix test and test new RC feature in fakeitake ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/53246",
          "createdAt": "2026-07-06T08:59:06Z",
          "updatedAt": "2026-08-12T14:40:34Z",
          "timestamp": "2026-08-12T14:40:34Z",
          "metrics": {
            "reactions": 2,
            "comments": 13
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/container-integrations",
            "ask-review",
            "team/agent-devx",
            "team/agent-build",
            "internal",
            "team/network-device-monitoring-core"
          ],
          "author": "KevinFairise2",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:a4ec6bf932357e36f717",
        "signalId": "github:DataDog/datadog-agent:pull_request:53936",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53936",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(privateactionrunner): sync kubernetes admissionregistration, networking, and cluster CRD bundles",
          "text": "## Intent This PR syncs new Kubernetes action bundles from [dd-source PR #26413](https://github.com/ddoghq/dd-source/pull/26413) into the private action runner embedded in the Datadog Agent. Three sets of changes are synced: **`pkg/privateactionrunner/bundles/kubernetes/admissionregistration/`** — new bundle, full CRUD for the four `admissionregistration/v1` types: `MutatingWebhookConfiguration`, `ValidatingWebhookConfiguration`, `ValidatingAdmissionPolicy`, and `ValidatingAdmissionPolicyBinding`. All four are cluster-scoped, so none of the handlers take a namespace input. **`pkg/privateactionrunner/bundles/kubernetes/networking/`** — new bundle, full CRUD for all five `networking/v1` resources: `Ingress`, `IngressClass`, `IPAddress`, `NetworkPolicy`, and `ServiceCIDR`. `Ingress` and `NetworkPolicy` are namespaced; the remaining three are cluster-scoped. **`pkg/privateactionrunner/bundles/kubernetes/customresources/`** — extends the existing bundle with seven cluster-scoped custom object actions: `getClusterCustomObject`, `listClusterCustomObject`, `createClusterCustomObject`, `updateClusterCustomObject`, `patchClusterCustomObject`, `deleteClusterCustomObject`, `deleteMultipleClusterCustomObjects`. These use the dynamic client without `.Namespace()`, enabling CRUD on cluster-scoped CRDs. All files were synced from the corresponding `dd-source` generated handlers with `PAR_SYNC_EXCLUDE` blocks stripped and import paths rewritten (`dd-source/domains/actionplatform/apps/private-runner/src/` → `DataDog/datadog-agent/pkg/privateactionrunner/`). The two new bundles are registered in `bundles/registry.go`. ## Surface changes No surface changes. New action FQNs are registered in the existing private action runner bundle map and are callable via the same `com.datadoghq.kubernetes.*` namespace used by all other Kubernetes AP actions. ## Automated review results | Agent | Findings | Fixed | Remaining | |-------|----------|-------|-----------| | Go best practices | 4 | 1 (TrimSuffix style) | 3 (pre-existing patterns shared with namespaced handlers) | ## QA guidelines CI is green. To validate locally, deploy a private action runner connected to a cluster and execute one of the new read actions (e.g. `com.datadoghq.kubernetes.networking.listIngress` or `com.datadoghq.kubernetes.admissionregistration.getMutatingWebhookConfiguration`) via the workflow automation UI.",
          "url": "https://github.com/DataDog/datadog-agent/pull/53936",
          "createdAt": "2026-07-21T17:35:13Z",
          "updatedAt": "2026-08-12T14:37:59Z",
          "timestamp": "2026-08-12T14:37:59Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "team/container-platform",
            "long review",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "BaptisteFoy",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:303ea845aa45a5b76671",
        "signalId": "github:DataDog/datadog-agent:pull_request:54770",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54770",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Clean bazelignore from invalid folder path",
          "text": "### What does this PR do? This path was added by mistake in previous PR and correspond to a local git worktree.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54770",
          "createdAt": "2026-08-12T10:08:12Z",
          "updatedAt": "2026-08-12T14:33:13Z",
          "timestamp": "2026-08-12T14:33:13Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "short review",
            "team/agent-build",
            "internal"
          ],
          "author": "hush-hush",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:55280b8b688b5494f17a",
        "signalId": "github:DataDog/datadog-agent:pull_request:54723",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54723",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Upgrade embedded Python patch version to 3.13.15",
          "text": "### What does this PR do? Upgrades the Agent's embedded CPython interpreter from **3.13.14** to **3.13.15** (patch version update). - Updated `omnibus/config/software/python3.rb` with the new version - Updated `deps/cpython/cpython.MODULE.bazel` with the new version and SHA256 - Updated `test/new-e2e/tests/agent-platform/common/agent_behaviour.go` with the expected version - Created a release note documenting the upgrade SHA256 hash automatically fetched and verified against the official Python.org SBOM file. See the [official Python release page](https://www.python.org/downloads/release/python-31315/) for details. ### Motivation Keep the embedded Python up to date with bug fixes and security patches. 3.13.15 (released 2026-08-05) remediates several CVEs tracked in the agent-integrations VULN queue, including tarfile symlink/hardlink filter issues (CVE-2026-11940, CVE-2026-4360), a tarfile DoS (CVE-2026-11972), an html.parser quadratic DoS (CVE-2026-15308), a configparser CR write injection (CVE-2026-0864), and an xml.etree findall DoS (CVE-2026-6879). ### Describe how you validated your changes CI is considered enough to validate changes. The E2E `ExpectedPythonVersion3` constant is updated in lockstep so the agent-platform behaviour tests assert the new version. ### Additional Notes Generated with `dda inv python-version.update`, mirroring the previous automated bump (#52085).",
          "url": "https://github.com/DataDog/datadog-agent/pull/54723",
          "createdAt": "2026-08-11T14:32:24Z",
          "updatedAt": "2026-08-12T14:29:34Z",
          "timestamp": "2026-08-12T14:29:34Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "medium review",
            "qa/rc-required",
            "team/agent-integrations",
            "ask-review",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "Kyle-Neale",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:bc2268746e10e7500476",
        "signalId": "github:DataDog/datadog-agent:pull_request:54749",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54749",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Bump AIX embedded Python to 3.13.15",
          "text": "### What does this PR do? Bumps the AIX embedded Python pin from 3.13.14 to 3.13.15 in `packaging/aix/lib/env.sh`. ### Motivation The AIX packaging build pins the embedded Python version in `packaging/aix/lib/env.sh`, and `packaging/aix/stages/02-python.sh` downloads and builds CPython from that value. This file is **not** touched by `dda inv python-version.update`, so the 3.13.15 upgrade (#54723) left AIX on 3.13.14 — meaning the AIX artifact would ship the vulnerable patch version while the rest of the platforms move to 3.13.15. This was flagged by Codex review on #54723 and confirmed by @aiuto. `02-python.sh` downloads the source tarball from python.org over `curl` with no pinned checksum and applies AIX patches via `sed` with graceful fallback, so the version string is the only change required for a patch bump. ### Describe how you validated your changes - Verified `packaging/aix/stages/02-python.sh` derives the tarball name, URL, and source dir entirely from `$PYTHON_VERSION` and performs no checksum verification, so no hash needs updating. - Confirmed `packaging/` has no other hardcoded `3.13.14` reference after the change. ### Additional Notes Companion to the main 3.13.15 upgrade in #54723; the \"embedded Python upgraded from 3.13.14 to 3.13.15\" release note in that PR covers this change for the AIX platform, so no separate release note is added here.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54749",
          "createdAt": "2026-08-11T20:26:03Z",
          "updatedAt": "2026-08-12T14:29:10Z",
          "timestamp": "2026-08-12T14:29:10Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog",
            "short review",
            "qa/rc-required",
            "team/agent-build",
            "internal"
          ],
          "author": "Kyle-Neale",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:c1e42475cb88ecb78980",
        "signalId": "github:DataDog/datadog-agent:pull_request:54107",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54107",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ABLD-536] Bazelify `gotestsum` usage across the repo",
          "text": "### What does this PR do? Route `gotestsum` through Bazel wherever it was invoked via `go install`, `$GOBIN`, or `$GOPATH`, and drop it from `install-tools`' `TOOL_LIST`. Replace every direct `gotestsum` invocation with `bazel run *:gotestsum` whenever possible. Otherwise install it by leveraging: 1. `platform_transition_filegroup` to cross-compile it without incurring the overhead of a full platform transition (for which some Bazel rules are not suited[^1]), 2. `pkg_install` for copying it out of the sandbox. Together, both of the above provide a flawless[^2] alternative in runtime environments where Bazel is not (yet) available. ### Initial Motivation `gotestsum`'s version and toolchain provenance were at best tracked by a runtime version check, and `go install` left it exposed to the \"gotestsum not found\" and wrong-arch incident class, leading us to land urgent PRs (e.g., #53993): - [#incident-56214](https://app.datadoghq.com/incidents/56214), - [#incident-56215](https://app.datadoghq.com/incidents/56215), - [#incident-56553](https://app.datadoghq.com/incidents/56553), - etc. => Bazel's hermetic build and efficient caching remove the failure mode at the source instead of patching around it again. ### Additional Motivation It introduces `platform_transition_filegroup` as a first working case that cross-compiles without having to globally alter `bazel --platforms` flags that would invalidate the action cache[^1][^2]. By adding the necessary GitLab `extends` as well as tweaking adhoc scripts, this also prepare jobs for: - switching from `bazel run *:gotestsum` to `bazel test`, - moving more non-hermetic tool invocations to `bazel run`, towards [ABLD-536](https://datadoghq.atlassian.net/browse/ABLD-536). ### Describe how you validated your changes `dda inv test` ran end to end through the new `bazel run` path: 18 tests passed with correct output and exit code. `kmt.py` and `system_probe.py`'s install paths were exercised directly, producing correct-arch binaries, verified via `file(1)`, for host, `arm64`, and `x86_64` targets, including the KMT cross-compile case. Existing unit test suites, `bazel_tests.py`, `e2e_testing_tests.py`, `setup_env_tests.py`, and `go_tests.py`, pass unchanged. ### Additional Notes [^1]: a bare `--platforms=` flag on the whole `bazel run` invocation doesn't just cost more, it breaks `pkg_install`'s own launcher outright (hit this directly: a garbled venv/Python launcher, `Syntax error: ')' unexpected`, zero output). [^2]: a naive `bazel build` followed by a copy of the resulting binary by gardening into Bazel's output is flawed: not only is the operation not atomic, but output paths collide across `--platforms` invocations. Also, build artifacts would get thrashed over `--platforms` switches. [ABLD-536]: https://datadoghq.atlassian.net/browse/ABLD-536?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54107",
          "createdAt": "2026-07-24T16:50:19Z",
          "updatedAt": "2026-08-12T14:25:08Z",
          "timestamp": "2026-08-12T14:25:08Z",
          "metrics": {
            "reactions": 3,
            "comments": 7
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/agent-security",
            "team/database-monitoring",
            "team/ebpf-platform",
            "qa/no-code-change",
            "long review",
            "team/container-integrations",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "rdesgroppes",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:1a4efa7b6193db8846a7",
        "signalId": "github:DataDog/datadog-agent:pull_request:54667",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54667",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "tagger: refuse reserved tag names from workload-controlled metadata",
          "text": "### What does this PR do? Adds a `workload_tags_denylist` setting (default `[\"host\", \"pod_name\"]`) listing tag names the tagger refuses to build out of workload-controlled metadata. It is resolved once into a set held by the `TagList` for O(1) lookups, and honored by the new `AddLow/AddHigh/AddAutoFromWorkload` methods, which are used on the paths where the workload names the tag: - the `ad.datadoghq.com/tags` and `ad.datadoghq.com/<container>.tags` pod annotations (`parseJSONValue`) - the `com.datadoghq.ad.tags` container label - tracer process tags on process entities - pod labels/annotations and container labels/env vars mapped to a tag name via a `%%label%%`/`%%annotation%%`/`%%env%%` template (`AddWorkloadMetadataAsTags`) Matching is case-insensitive, ignores the `+` high-cardinality prefix, and cuts at the first `:` — otherwise `{\"host:attacker\": \"1\"}` would serialize to `host:attacker:1` and still be read as the `host` tag downstream. Deliberately **not** filtered, since the tag name there is not the workload's to choose: the tags the Agent computes itself, node/namespace/deployment metadata (`AddMetadataAsTags` is unchanged, so node labels as host tags keep working), and tag names an administrator hardcoded in a `*_labels_as_tags` mapping. ### Motivation VULN-92370 / CONTP-108: a tenant with `edit` on its own namespace could inject reserved infrastructure tags on its own workload and have the DCA ship them, poisoning cross-tenant tag attribution, monitor scoping and billing-by-tag. Confirmed as real — reproduced in a unit test that asserts the forged tags land on the entity when the denylist is empty. ### Describe how you validated your changes `go test -tags test ./comp/core/tagger/...` — all green. New coverage: - `taglist`: default denylist, custom/empty denylist, `+` prefix, casing, `:` in the tag name, `Copy` keeping the set, and that the Agent's own `AddLow`/`AddOrchestrator` are unaffected - `k8s_metadata`: template-named tag denied, admin-hardcoded name kept, admin-controlled `AddMetadataAsTags` unfiltered - `collectors`: end-to-end pod with a forged `ad.datadoghq.com/tags`, both with the default denylist (dropped) and with it disabled (the pre-fix behavior, i.e. the repro) Also ran the schema linter and `go vet` on the changed packages. ### Additional Notes - One behavior change to flag: `{\"pod_name\":\"%%kube_pod_name%%\"}` in `ad.datadoghq.com/tags` — the documented way to get `pod_name` at low cardinality — now drops that tag. Covered in the upgrade release note; admins can remove `pod_name` from the list. - The setting name is easy to change if you'd prefer something else. - Follow-up worth its own PR: in `labelsToTags`, `extractFromMapNormalizedWithFn(labels, containerLabelsAsTags, tags.AddAuto)` re-processes container labels a second time without resolving templates, emitting a literal `%%label%%:<value>` tag. Pre-existing and unrelated to this fix, so left alone. - Coordinate with CONTP-1959, which extends the same annotation path.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54667",
          "createdAt": "2026-08-10T18:25:59Z",
          "updatedAt": "2026-08-12T14:04:29Z",
          "timestamp": "2026-08-12T14:04:29Z",
          "metrics": {
            "reactions": 1,
            "comments": 10
          },
          "labels": [
            "team/container-platform",
            "medium review",
            "team/container-integrations",
            "team/agent-build",
            "internal",
            "team/fleet-automation"
          ],
          "author": "gabedos",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:9ac90db2baac95adfbf5",
        "signalId": "github:DataDog/datadog-agent:pull_request:54566",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54566",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Split macOS-only corechecks into MACOS_CORECHECKS",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds a new `MACOS_CORECHECKS` list to `tasks/core_checks.py` (and its byte-identical mirror `cmd/agent/dist/core_checks.bzl`), moves `battery` and `wlan` out of `AGENT_CORECHECKS` into it, and adds both to `WINDOWS_CORECHECKS`. Wires the new list up the same way `WINDOWS_CORECHECKS` already is: - `tasks/agent.py`: `refresh_assets` gets a `sys.platform == 'darwin'` copy loop that installs each `MACOS_CORECHECKS` check's `conf.d` directory, alongside the existing Windows-only loop. - `cmd/agent/dist/conf.d/BUILD.bazel`: adds a `macos_checks_files` `pkg_files` target (globbing over `MACOS_CORECHECKS`), merged into the existing `@platforms//os:macos` select branch next to `:macos_files`. ### Motivation `AGENT_CORECHECKS` is meant for checks available on every platform, but `battery` and `wlan` only collect on macOS and Windows — `pkg/collector/corechecks/system/battery/battery_nix.go` and `pkg/collector/corechecks/net/wlan/wlan_nix.go` are both built with `//go:build !darwin && !windows` and return an error (\"battery/wifi info only supported on macOS and Windows\") everywhere else. Both configs are Autodiscovery templates (`ad_identifiers: [_end_user_device]`), so on Linux and AIX they were dead files in the package on a default install, and under `infrastructure_mode: end_user_device` they scheduled a check that could never collect. Giving macOS-only checks their own list, mirroring the existing `WINDOWS_CORECHECKS` pattern, keeps `AGENT_CORECHECKS` accurate and makes the per-platform packaging explicit. ### Why `WINDOWS_CORECHECKS` also changes `AGENT_CORECHECKS` feeds the `base_checks_files` target, which is included on *every* platform via the `//conditions:default` branch of the `select` in `cmd/agent/dist/conf.d/BUILD.bazel`. Removing `battery`/`wlan` from it would therefore have dropped both configs from the **Windows** package too, which would break `TestEUDMWindowsSuite` (`test/new-e2e/tests/agent-runtimes/infra_eudm_win_test.go`) — it asserts the `wlan` check is scheduled and runs in `end_user_device` mode. Adding both names to `WINDOWS_CORECHECKS` keeps the Windows package byte-identical to before this PR. ### Describe how you validated your changes - Built the agent natively on macOS/arm64 with `dda inv agent.build` and confirmed `bin/agent/dist/conf.d/` contains `battery.d/` and `wlan.d/`, verifying the new darwin-only copy path in `tasks/agent.py`. - `bazel run //bazel/buildifier` and `bazel run //:gazelle` are clean. - `//cmd/agent/dist:core_checks_list_sync_test` passes (the `.py` and `.bzl` copies are identical). - Verified per-platform package contents: ``` bazel cquery --platforms=@platforms//os:linux 'deps(//cmd/agent/dist/conf.d:all_files)' | grep -E 'battery|wlan' # expect empty bazel cquery --platforms=@platforms//os:macos 'deps(//cmd/agent/dist/conf.d:all_files)' | grep -E 'battery|wlan' # expect present bazel cquery --platforms=@platforms//os:windows 'deps(//cmd/agent/dist/conf.d:all_files)' | grep -E 'battery|wlan' # expect present ``` - Manually installed the agent on macOS/arm64 from a real CI pipeline build artifact (via the pipeline's `install_mac_os.sh` install script, fetched over a short-lived presigned S3 URL) and confirmed `battery.d/` and `wlan.d/` are present under the installed agent's `conf.d/`, alongside the standard cross-platform checks (e.g. `cpu.d/`, `memory.d/`) — validating the new macOS packaging end-to-end on a real installed build, not just the local dev build. ### Additional Notes `battery` and `wlan` work on both macOS and Windows, so they are listed in `MACOS_CORECHECKS` *and* `WINDOWS_CORECHECKS`. A check belongs in every platform list that can actually collect it. Labelled `qa/rc-required`: this changes package contents, and per-platform package contents are not verified by PR-branch CI.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54566",
          "createdAt": "2026-08-07T12:52:23Z",
          "updatedAt": "2026-08-12T13:58:03Z",
          "timestamp": "2026-08-12T13:58:03Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "medium review",
            "qa/rc-required",
            "team/agent-runtimes",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "PedroCordeiroDataDog",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:9f9347fba0536e15e21e",
        "signalId": "github:DataDog/datadog-agent:pull_request:54056",
        "event": "changed",
        "observedAt": "2026-08-13T13:48:00.446149Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54056",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[WP] Fix isolation re-apply mechanism",
          "text": "### What does this PR do? This PR prevent isolations from behind removed for some time during a ruleset loaded. ### Motivation This was supposed to be fixed in a previous PR but a bug was found. ### Describe how you validated your changes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54056",
          "createdAt": "2026-07-23T16:55:34Z",
          "updatedAt": "2026-08-12T13:48:22Z",
          "timestamp": "2026-08-12T13:48:22Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/agent-security",
            "category/bugfix",
            "qa/done",
            "short review",
            "internal"
          ],
          "author": "theop-dd",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:cab1d073c018aeb58779",
        "signalId": "github:DataDog/datadog-agent:pull_request:54589",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "text",
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54589",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] add par-control process lifecycle",
          "text": "### What does this PR do? Adds the process-lifecycle layer for `par-control`: - Uses the shared `dd-procmgr-client` for local IPC on Linux and Windows. - Loads the minimal configuration needed to gate split mode. - Starts or adopts the executor, monitors its state, and exposes start/stop operations for later orchestration layers. - Handles process-manager failures, RPC deadlines, and platform-specific shutdown and logging. - Tests the lifecycle against an in-process fake `dd-procmgrd`. Clean executor exits are treated as normal idle shutdown. During its own shutdown, `par-control` does not call back into `dd-procmgrd`, which may already be waiting for it to exit. ### Validation - `dda env dev run -- bazel test //pkg/privateactionrunner/par-control:par-control_test` - `dda env dev run -- env -u PKG_CONFIG_LIBDIR cargo clippy --manifest-path pkg/privateactionrunner/par-control/Cargo.toml --all-targets -- -D warnings`",
          "url": "https://github.com/DataDog/datadog-agent/pull/54589",
          "createdAt": "2026-08-07T17:44:51Z",
          "updatedAt": "2026-08-13T16:19:16Z",
          "timestamp": "2026-08-13T16:19:16Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:d2e63917bf1ae2d48bd5",
        "signalId": "github:DataDog/datadog-agent:pull_request:54842",
        "event": "discovered",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54842",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CONTP-2006] feat(ddi): Add pod workload target resolution",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds a registry and owner-chain resolver for DatadogInstrumentation workload targets. - Models built-in and customer-configured workload profiles using a `target` resource and optional `via` resources. - Identifies every resource by `apiVersion`, kind, and plural resource name. - Walks controller owner references with the dynamic Kubernetes client, validates owner UIDs, caches resolved owners, and limits traversal depth. This PR only introduces the resolver package. It does not expose or activate custom workload target configuration. ### Motivation [CONTP-2006](https://datadoghq.atlassian.net/browse/CONTP-2006) Hard-coding every operator-managed workload does not scale and cannot represent indirect ownership such as Pod to Job to a custom workload. Explicit target and traversal profiles provide a general mechanism that distinguishes API groups and allows deployments to grant read access only to the intermediate resources required for resolution. ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54842",
          "createdAt": "2026-08-13T15:51:31Z",
          "updatedAt": "2026-08-13T16:18:34Z",
          "timestamp": "2026-08-13T16:18:34Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog"
          ],
          "author": "Mathew-Estafanous",
          "state": "open",
          "assignees": [
            "Mathew-Estafanous"
          ],
          "change": "new"
        }
      },
      {
        "id": "event:40b8558c5d27c255bea7",
        "signalId": "github:DataDog/datadog-agent:pull_request:54840",
        "event": "discovered",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54840",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CONTP-2006] feat(ddi): Add resolved target to workloadmeta",
          "text": "### What does this PR do? Adds group- and version-aware resolved workload targets to Kubernetes Pod workload metadata and the workload-filter CEL model. - Preserves `apiVersion` and `controller` from Kubernetes owner references in both Pod parsers. - Adds `KubernetesPod.ResolvedTargets` with group, version, kind, namespace, name, and UID identity. - Exposes resolved targets to CEL as `container.pod.resolved_targets`. This is an additive data-model change and does not alter current DatadogInstrumentation matching behavior. ### Motivation [CONTP-2006](https://datadoghq.atlassian.net/browse/CONTP-2006) DatadogInstrumentation currently matches workload Pods through `rootowner`, which only carries kind and name and relies on built-in ownership conventions. Supporting arbitrary workload CRs requires a structured, API-group-aware identity that can distinguish identical kinds from different API groups and carry targets resolved by the Cluster Agent to CEL evaluation. ### Describe how you validated your changes ### Additional Notes [CONTP-2006]: https://datadoghq.atlassian.net/browse/CONTP-2006?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54840",
          "createdAt": "2026-08-13T15:44:42Z",
          "updatedAt": "2026-08-13T16:18:33Z",
          "timestamp": "2026-08-13T16:18:33Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "team/container-platform",
            "medium review",
            "team/container-integrations",
            "team/agent-runtimes",
            "internal"
          ],
          "author": "Mathew-Estafanous",
          "state": "open",
          "assignees": [
            "Mathew-Estafanous"
          ],
          "change": "new"
        }
      },
      {
        "id": "event:39d62e64bc0ccffc58f1",
        "signalId": "github:DataDog/datadog-agent:pull_request:54115",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "labels"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54115",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ABLD-395] MVP macos .pkg file rule.",
          "text": "### What does this PR do? Adds an MVP rule to create Mac PKG files. - bazel/rules/macos/pkg/pkg_mac_pkg.bzl - materialize srcs to diesk via a pkg_install-generated installer. sub-optimal but equivalent to what omnibus does today. Future work will improve that. - bazel/rules/macos/pkg/build_mac_pkg.sh — the pkgbuild wrapper - Adds packages/agent/macos/BUILD.bazel, to create a .pkg file for datadog-agent. This is obviously incomplete because //cmd/agent:agent is not ready yet. - packages/agent/product/BUILD.bazel — fixed a pre-existing bug where //cmd/loader:trace_loader (Linux-only target_compatible_with) was listed unconditionally, breaking any non-Linux consumer of :all_files. ### Motivation ### Describe how you validated your changes Claude's used lsbom to verify that the pkg format was valid. Hand compare the DMG built from the omnibus job to this output. ``` $ tree_size_compare --save pkg.json bazel-bin/packages/agent/macos/pkg.pkg $ tree_size_compare --save=dmg.json $HOME/Downloads/datadog-agent-7.83.0-devel.git.371.359005d.pipeline.126858256-1.arm64.dmg $ grep PKG@ dmg.json | sed -e 's/@PKG@/opt\\/datadog-agent/' >/tmp/dmg.files $ grep path pkg.json >/tmp/pkg.files $ grep system-prob /tmp/*.files /tmp/dmg.files: \"path\": \"opt/datadog-agent/bin/agent/dist/system-probe.yaml\", /tmp/dmg.files: \"path\": \"opt/datadog-agent/embedded/bin/system-probe\", /tmp/dmg.files: \"path\": \"opt/datadog-agent/etc/system-probe.yaml\", /tmp/dmg.files: \"path\": \"opt/datadog-agent/etc/system-probe.yaml.example\", /tmp/pkg.files: \"path\": \"opt/datadog-agent/etc/system-probe.yaml\", ``` The missing files are expected right now, because we have not done serious work at wiring up the dependencies. ### Next steps - tweak dependencies and config until we have fidelity with the omnibus packager. Brew the omnibus jobs to do this. - replace use of pkg_install to manifest the tree with a direct reader/writer. That is probably upstreamable to rules_pkg in a contrib section. I think I want a pkg_instantiate rule that will return a tree artifact. - Add signing (blocked on ABLD-386)",
          "url": "https://github.com/DataDog/datadog-agent/pull/54115",
          "createdAt": "2026-07-24T18:59:12Z",
          "updatedAt": "2026-08-13T16:18:09Z",
          "timestamp": "2026-08-13T16:18:09Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "ask-review",
            "team/agent-build",
            "internal"
          ],
          "author": "aiuto",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:f90e151fbfdc81ff269a",
        "signalId": "github:DataDog/datadog-agent:pull_request:54837",
        "event": "discovered",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54837",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(autodiscovery): tag configuration-discovery instances to mitigate duplicate metrics risk (#54660)",
          "text": "Adds a `dd_config_discovery:true` tag to every check instance scheduled via the Autodiscovery configuration-discovery mechanism (i.e. any `auto_conf.yaml` template with `discovery: {}`, resolved through `comp/core/autodiscovery/impl/configmgr_discovery.go`'s `applyDiscoveredConfigsLocked`). The tag used is `dd_config_discovery:true`, a plain `dd_`-prefixed key, following the precedent of other agent-added, customer-visible marker/provenance tags already in the codebase: - `dd_remote_config_id` / `dd_remote_config_rev` (`comp/core/tagger/tags/tags.go`) - `dd_enable_check_intake` (`pkg/collector/worker/worker.go`) [DSCVR-651](https://datadoghq.atlassian.net/browse/DSCVR-651): there is a risk that an agent on host A is monitoring a service on host B with a manually-configured check (e.g. a generic `openmetrics` check), while the agent running locally on host B also autodiscovers and schedules a dedicated integration for the same service via configuration discovery. Neither agent's local anti-duplication logic can see the other's config, so both submit metrics for the same underlying data. This tag doesn't prevent the duplication, but lets users identify and, if needed, exclude the autodiscovered side of it (e.g. `metric{!dd_config_discovery:true}`), both for the cross-host case above and for any single-host case the automatic suppression doesn't catch. Unit and E2E tests. --- 🤖 This PR description and implementation were generated with assistance from [Claude Code](https://claude.com/claude-code). [DSCVR-651]: https://datadoghq.atlassian.net/browse/DSCVR-651?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ Co-authored-by: vincent.whitchurch <vincent.whitchurch@datadoghq.com> (cherry picked from commit 0b134fce442c8d3c923e7159b07d614e050f5df1) Conflicts: test/new-e2e/tests/discovery/BUILD.bazel",
          "url": "https://github.com/DataDog/datadog-agent/pull/54837",
          "createdAt": "2026-08-13T15:12:02Z",
          "updatedAt": "2026-08-13T16:16:20Z",
          "timestamp": "2026-08-13T16:16:20Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "qa/done",
            "team/container-platform",
            "medium review",
            "team/agent-discovery",
            "team/agent-build",
            "internal"
          ],
          "author": "vitkyrka",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:eb431a6861ad5468b9ff",
        "signalId": "github:DataDog/datadog-agent:pull_request:54731",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "metrics"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54731",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[procmgr] Windows spawn profiles foundation",
          "text": "### What does this PR do? Introduces **Windows spawn profiles** in dd-procmgr so managed children can run under different security contexts: - **Privileged**: spawn as LocalSystem (supervisor primary token) - **AgentUser**: spawn as the agent service account (`ddagentuser`) Adds the Windows spawn stack (token logon, user profile load, supervision job, suspended `CreateProcessAsUserW`), COAT catalog enforcement for allowed profiles, and gRPC pipe caller authentication. **Stack context:** PR 1/4 split from [#53249](https://github.com/DataDog/datadog-agent/pull/53249). Config gates, secret backend resolution, and process-agent dual-mode integration land in follow-up PRs (`jose/procmgr-config-gates`, `jose/procmgr-secret-backend-gates`, `jose/procmgr-windows-process-agent`). This PR includes a **stub** `config_gate` module (gates always open) so the crate compiles until PR 2. ### Motivation Process-agent on Windows must run as LocalSystem and other agent children should stay on the agent user. Spawn profiles make that explicit and enforceable at spawn time, and are a prerequisite for moving process-agent supervision off legacy SCM in later PRs. ### Describe how you validated your changes - Windows procmgr Rust build/tests in CI - COAT unit tests (`pkg/procmgr/coat/...`) - Windows E2E: privileged spawn catalog enforcement (`test/new-e2e/tests/agent-runtimes/procmgr/...`) ### Additional Notes - No agent startup, fleet installer, or process-agent dual-mode changes in this PR. - [#53568](https://github.com/DataDog/datadog-agent/pull/53568) (list/describe profile + user) should rebase onto this branch once merged. - Supersedes the spawn/COAT portion of [#53249](https://github.com/DataDog/datadog-agent/pull/53249); that PR will be closed after the stack is open.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54731",
          "createdAt": "2026-08-11T15:45:26Z",
          "updatedAt": "2026-08-13T16:16:09Z",
          "timestamp": "2026-08-13T16:16:09Z",
          "metrics": {
            "reactions": 1,
            "comments": 29
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "jose-manuel-almaza",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:40d4188af4428abbb533",
        "signalId": "github:DataDog/datadog-agent:pull_request:54841",
        "event": "discovered",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54841",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CONTP-2006] feat(ddi): Stream resolved targets from DCA to node agent",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Streams per-Pod resolved workload targets from the Cluster Agent to Node Agents through the Kubernetes metadata stream. - Adds a generic `PodTargetResolver` interface to keep the transport independent from the DDI resolver implementation. - Includes resolved targets in initial full-state responses and incremental `SET` and `UNSET` updates scoped to each node. - Enriches Node Agent Pod workload metadata when resolved targets change. No production resolver is wired in this PR, so the new transport remains dormant until a later change supplies resolved targets. ### Motivation [CONTP-2006](https://datadoghq.atlassian.net/browse/CONTP-2006) Custom owner-chain resolution belongs in the Cluster Agent, where Kubernetes API access is centralized, while Autodiscovery CEL matching runs on each Node Agent. A node-scoped transport is therefore required to deliver resolved target identity without granting every Node Agent access to arbitrary workload resources. ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54841",
          "createdAt": "2026-08-13T15:46:01Z",
          "updatedAt": "2026-08-13T16:15:30Z",
          "timestamp": "2026-08-13T16:15:30Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog"
          ],
          "author": "Mathew-Estafanous",
          "state": "open",
          "assignees": [
            "Mathew-Estafanous"
          ],
          "change": "new"
        }
      },
      {
        "id": "event:31dbceb30e86af423de4",
        "signalId": "github:DataDog/datadog-agent:pull_request:54735",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54735",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[procmgr] Supervise process-agent on Windows via dd-procmgr",
          "text": "### What does this PR do? Moves Windows **process-agent** supervision to **dd-procmgr** using the same dual-mode pattern as PAR: - Fleet installer writes `processes.d/datadog-agent-process.yaml` (Privileged spawn profile) - Legacy `datadog-process-agent` SCM service is suppressed when procmgr owns process-agent - Agent startup waits on `dd-procmgr-service` before starting gated legacy children; independent services (sysprobe, security-agent, installer) start without blocking on procmgr Also runs **dd-procmgr-service as LocalSystem** (MSI service custom action) so the supervisor can spawn Privileged children while agent-profile processes still spawn as `ddagentuser`. **Stack context:** PR 4/4 split from [#53249](https://github.com/DataDog/datadog-agent/pull/53249). Builds on [#54734](https://github.com/DataDog/datadog-agent/pull/54734) → [#54732](https://github.com/DataDog/datadog-agent/pull/54732) → [#54731](https://github.com/DataDog/datadog-agent/pull/54731). Spawn profiles, config gates, and secret backend resolution land in those PRs. ### Motivation We want subservices on dd-procmgr instead of SCM. Process-agent needs LocalSystem on Windows; other agent children should stay on the agent user. This PR wires the product integration once the procmgr foundation (PRs 1–3) is in place. ### Describe how you validated your changes - Go unit tests for dependent Windows service startup (`dependent_services_windows_test.go`) - Go unit tests for fleet installer templates and YAML path substitution (`processmanager/...`) - New Windows E2E: process-agent supervised by procmgr, runs as LocalSystem, legacy SCM stopped - E2E: dd-procmgr-service runs as LocalSystem; agent-profile children run as agent user - E2E: privileged spawn catalog enforcement when processes.d YAML is tampered with - PAR/procmgr Windows E2E regression ### Additional Notes - Linux process-agent stays on systemd for now. Legacy SCM service registration is not removed yet. - Process-agent `processes.d` config uses the shared `install_root` helper (same as PAR/ADP). MSI `RemoveFolderEx` handles uninstall/rollback cleanup; no per-file MSI rollback custom actions. - Includes release note `windows-process-procmgr-dual-mode-b7d2e4a1c8f03962.yaml`. - Closes/supersedes [#53249](https://github.com/DataDog/datadog-agent/pull/53249) once the full stack merges.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54735",
          "createdAt": "2026-08-11T16:07:07Z",
          "updatedAt": "2026-08-13T16:15:16Z",
          "timestamp": "2026-08-13T16:15:16Z",
          "metrics": {
            "reactions": 2,
            "comments": 1
          },
          "labels": [
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "jose-manuel-almaza",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:22a27c7a5e9e78bd1880",
        "signalId": "github:DataDog/datadog-agent:pull_request:54734",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54734",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[procmgr] Secret backend resolution for config gates",
          "text": "### What does this PR do? Resolves `ENC[...]` values during config gate evaluation so dd-procmgr matches Agent secret handling. Adds: - `config_gate/secrets.rs`: resolve handles via `secret_backend_command`, native `secret_backend_type`, and `multi_secret_backends` (same precedence as the core Agent) - Platform secret backend runners (Windows `CreateProcessAsUserW` under the Agent account; Unix setuid when procmgr runs as root for Privileged children) - `secret_backend_exec.rs`: shared spawn, timeout, stdout drain, and response parsing - Windows ACL validation on secret backend executables before spawn - Agent config precedence for backend settings: `DD_SECRET_BACKEND_*` env (including core Agent SCM `Environment` on Windows) over `datadog.yaml` - Manager reload: invalidate secret caches when config changes Fleet policy `ENC[...]` values stay unresolved here, matching Agent `MergeFleetPolicy` running after secret resolution. **Stack context:** PR 3/4 split from [#53249](https://github.com/DataDog/datadog-agent/pull/53249). Builds on [#54732](https://github.com/DataDog/datadog-agent/pull/54732) (`jose/procmgr-config-gates`), which in turn builds on [#54731](https://github.com/DataDog/datadog-agent/pull/54731). Process-agent dual-mode integration lands in PR 4 (`jose/procmgr-windows-process-agent`). ### Motivation PR 2 config gates read YAML, env, and fleet policy, but many customers gate features with secret-backed settings (`ENC[api_key]`, secret-backed booleans, etc.). Without secret resolution, gates would mis-evaluate and auto-start behavior would diverge from the Agent. ### Describe how you validated your changes - Rust unit tests in `pkg/procmgr/rust/src/config_gate/secrets.rs` and config gate integration tests (serialized env to avoid cross-test leakage) - Windows procmgr Rust build/tests in CI - Linux CI: secret-backend tests run under the agent service user where required ### Additional Notes - Secret backends always run as the core Agent service account, not as the procmgr supervisor (LocalSystem) or a Privileged managed child. - No agent startup, fleet installer, or legacy SCM suppression changes in this PR. - Invokes `secret-generic-connector` when no custom `secret_backend_command` is configured.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54734",
          "createdAt": "2026-08-11T15:56:49Z",
          "updatedAt": "2026-08-13T16:15:07Z",
          "timestamp": "2026-08-13T16:15:07Z",
          "metrics": {
            "reactions": 2,
            "comments": 1
          },
          "labels": [
            "changelog/no-changelog",
            "team/ebpf-platform",
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-devx",
            "team/container-experiences",
            "team/agent-build",
            "team/windows-products",
            "internal",
            "team/fleet-automation"
          ],
          "author": "jose-manuel-almaza",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:89a1de2e42885edf8351",
        "signalId": "github:DataDog/datadog-agent:pull_request:54732",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54732",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[procmgr] Config gates for processes.d auto-start",
          "text": "### What does this PR do? Adds **config gates** to dd-procmgr so `processes.d` definitions can use `condition_config_any` to auto-start only when Agent config says they should. Implementation mirrors the Windows legacy SCM startup checks in `dependent_services_windows.go` and Agent config resolution: - YAML lookup (case-insensitive keys, flattened dotted keys, permissive parse fallback, merge keys) - Environment bindings (`DD_*`) with Agent precedence (ignore empty values, no trim before `ParseBool`, legacy `process_config.enabled` transforms) - Fleet policy merge - Derived `system_probe_config.enabled` (USM/NPM/security knobs, sk-tracer and discovery adjustments) - Windows: read `DD_*` overrides from the core Agent SCM `Environment` registry when not set in the procmgr process env Wires gate evaluation into `ManagedProcess` start/reload paths in the manager. **Stack context:** PR 2/4 split from [#53249](https://github.com/DataDog/datadog-agent/pull/53249). Builds on [#54731](https://github.com/DataDog/datadog-agent/pull/54731) (`jose/procmgr-spawn-profiles`). `ENC[...]` secret backend resolution lands in PR 3 (`jose/procmgr-secret-backend-gates`). Process-agent dual-mode integration lands in PR 4 (`jose/procmgr-windows-process-agent`). ### Motivation Moving subservices (starting with process-agent) to dd-procmgr requires the supervisor to apply the same start/stop rules as the Agent today. Without config gates, a `processes.d` entry would always spawn when registered, which breaks parity with legacy SCM and fleet policy. ### Describe how you validated your changes - Rust unit tests in `pkg/procmgr/rust/src/config_gate/` (env bindings, YAML load, system-probe derivations, gate evaluation) - Go unit tests for Windows config helpers (`pkg/config/setup/config_windows_test.go`) - Windows procmgr Rust build/tests in CI ### Additional Notes - No `ENC[...]` / secret backend resolution in this PR (fleet policy `ENC[...]` values are not resolved here either). - No agent startup, fleet installer, or legacy SCM suppression changes in this PR. - Schema comment sync in `pkg/config/schema/yaml/process_config.yaml` for env binding documentation. - Small exports in `pkg/system-probe/config/` so procmgr gate derivations stay aligned with Go `adjust*` logic.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54732",
          "createdAt": "2026-08-11T15:51:46Z",
          "updatedAt": "2026-08-13T16:15:06Z",
          "timestamp": "2026-08-13T16:15:06Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "team/ebpf-platform",
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-devx",
            "team/container-experiences",
            "team/agent-build",
            "team/windows-products",
            "internal",
            "team/fleet-automation"
          ],
          "author": "jose-manuel-almaza",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:defe80457afd0dc17bca",
        "signalId": "github:DataDog/datadog-agent:issue:33469",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "text",
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:issue:33469",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "issue",
          "title": "Dependency Dashboard",
          "text": "This issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.<br>[View this repository on the Mend.io Web Portal](https://developer.mend.io/github/DataDog/datadog-agent). ## Deprecations / Replacements > [!WARNING] The following dependencies are either deprecated or have replacements available. | Datasource | Package | Replacement PR? | |------------|------|--------------| | nuget | [xunit](https://redirect.github.com/xunit/xunit) | ![Unavailable](https://img.shields.io/badge/unavailable-orange?style=flat-square) | ## Pending Approval The following branches are pending approval. To create them, click on a checkbox below. - [ ] <!-- approve-branch=renovate/github.com-alecthomas-participle-2.x -->Update module github.com/alecthomas/participle to v2 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-authorization-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/authorization/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-compute-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/compute/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-containerservice-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/containerservice/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-managedidentity-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/managedidentity/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-network-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/network/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-docker-sdk-v4-5.x -->Update module github.com/pulumi/pulumi-docker/sdk/v4 to v5 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-tls-sdk-v4-5.x -->Update module github.com/pulumi/pulumi-tls/sdk/v4 to v5 - [ ] <!-- approve-branch=renovate/github.com-sijms-go-ora-v2-3.x -->Update module github.com/sijms/go-ora/v2 to v3 - [ ] <!-- approve-branch=renovate/gitlab.com-gitlab-org-api-client-go-2.x -->Update module gitlab.com/gitlab-org/api/client-go to v2 - [ ] <!-- approve-branch=renovate/gopkg.in-datadog-dd-trace-go.v1-2.x -->Update module gopkg.in/DataDog/dd-trace-go.v1 to v2 - [ ] <!-- approve-all-pending-prs -->🔐 **Create all pending approval PRs at once** 🔐 ## Rate-Limited The following updates are currently rate-limited. To force their creation now, click on a checkbox below. - [ ] <!-- unlimit-branch=renovate/linux-images-130715735.x -->Update dependency linux-images to v130715735 - [ ] <!-- unlimit-branch=renovate/linux-images-devcontainer-130715735.x -->Update dependency linux-images-devcontainer to v130715735 - [ ] <!-- unlimit-branch=renovate/windows-images-130715735.x -->Update dependency windows-images to v130715735 - [ ] <!-- unlimit-branch=renovate/github-actions -->Update github-actions (`DataDog/dd-sts-action`, `actions/checkout`, `aws-actions/configure-aws-credentials`, `docker/login-action`, `tcort/github-action-markdown-link-check`) - [ ] <!-- unlimit-branch=renovate/github.com-jarcoal-httpmock-1.x -->Update module github.com/jarcoal/httpmock to v1.4.2 - [ ] <!-- unlimit-branch=renovate/github.com-klauspost-compress-1.x -->Update module github.com/klauspost/compress to v1.19.2 - [ ] <!-- unlimit-branch=renovate/github.com-mattn-go-sqlite3-1.x -->Update module github.com/mattn/go-sqlite3 to v1.14.49 - [ ] <!-- unlimit-branch=renovate/github.com-pierrec-lz4-v4-4.x -->Update module github.com/pierrec/lz4/v4 to v4.1.28 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-random-sdk-v4-4.x -->Update module github.com/pulumi/pulumi-random/sdk/v4 to v4.21.1 - [ ] <!-- unlimit-branch=renovate/github.com-santhosh-tekuri-jsonschema-v6-6.x -->Update module github.com/santhosh-tekuri/jsonschema/v6 to v6.0.3 - [ ] <!-- unlimit-branch=renovate/github.com-vektra-mockery-v3-3.x -->Update module github.com/vektra/mockery/v3 to v3.7.2 - [ ] <!-- unlimit-branch=renovate/go.etcd.io-etcd-client-v2-2.x -->Update module go.etcd.io/etcd/client/v2 to v2.305.33 - [ ] <!-- unlimit-branch=renovate/go.temporal.io-api-1.x -->Update module go.temporal.io/api to v1.63.5 - [ ] <!-- unlimit-branch=renovate/clap-4.x-lockfile -->Update Rust crate clap to v4.6.6 - [ ] <!-- unlimit-branch=renovate/packaging-26.x -->Update dependency packaging to v26.3 - [ ] <!-- unlimit-branch=renovate/cloud.google.com-go-compute-1.x -->Update module cloud.google.com/go/compute to v1.65.0 - [ ] <!-- unlimit-branch=renovate/code.cloudfoundry.org-lager-v3-3.x -->Update module code.cloudfoundry.org/lager/v3 to v3.81.0 - [ ] <!-- unlimit-branch=renovate/github.com-apache-arrow-go-v18-18.x -->Update module github.com/apache/arrow-go/v18 to v18.7.0 - [ ] <!-- unlimit-branch=renovate/github.com-aquasecurity-trivy-0.x -->Update module github.com/aquasecurity/trivy to v0.73.0 - [ ] <!-- unlimit-branch=renovate/github.com-containerd-containerd-v2-2.x -->Update module github.com/containerd/containerd/v2 to v2.3.3 - [ ] <!-- unlimit-branch=renovate/github.com-datadog-dd-trace-go-contrib-net-http-v2-2.x -->Update module github.com/DataDog/dd-trace-go/contrib/net/http/v2 to v2.9.1 - [ ] <!-- unlimit-branch=renovate/github.com-datadog-orchestrion-1.x -->Update module github.com/DataDog/orchestrion to v1.12.0 - [ ] <!-- unlimit-branch=renovate/github.com-docker-cli-29.x -->Update module github.com/docker/cli to v29.7.2+incompatible - [ ] <!-- unlimit-branch=renovate/github.com-envoyproxy-gateway-1.x -->Update module github.com/envoyproxy/gateway to v1.8.3 - [ ] <!-- unlimit-branch=renovate/github.com-google-cel-go-0.x -->Update module github.com/google/cel-go to v0.30.0 - [ ] <!-- unlimit-branch=renovate/github.com-open-policy-agent-opa-1.x -->Update module github.com/open-policy-agent/opa to v1.19.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-aws-sdk-v7-7.x -->Update module github.com/pulumi/pulumi-aws/sdk/v7 to v7.40.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-awsx-sdk-v3-3.x -->Update module github.com/pulumi/pulumi-awsx/sdk/v3 to v3.8.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-eks-sdk-v4-4.x -->Update module github.com/pulumi/pulumi-eks/sdk/v4 to v4.3.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-gcp-sdk-v9-9.x -->Update module github.com/pulumi/pulumi-gcp/sdk/v9 to v9.33.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-sdk-v3-3.x -->Update module github.com/pulumi/pulumi/sdk/v3 to v3.256.0 - [ ] <!-- unlimit-branch=renovate/github.com-rabbitmq-amqp091-go-1.x -->Update module github.com/rabbitmq/amqp091-go to v1.13.0 - [ ] <!-- unlimit-branch=renovate/github.com-redis-go-redis-v9-9.x -->Update module github.com/redis/go-redis/v9 to v9.22.0 - [ ] <!-- unlimit-branch=renovate/go.temporal.io-sdk-1.x -->Update module go.temporal.io/sdk to v1.47.0 - [ ] <!-- unlimit-branch=renovate/sigs.k8s.io-gateway-api-1.x -->Update module sigs.k8s.io/gateway-api to v1.6.1 - [ ] <!-- unlimit-branch=renovate/redis-7.x -->Update redis Docker tag to v7.4 - [ ] <!-- unlimit-branch=renovate/confluentinc-cp-kafka-8.x -->Update confluentinc/cp-kafka Docker tag to v8 - [ ] <!-- unlimit-branch=renovate/major-github-actions -->Update github-actions (major) (`actions/cache`, `actions/labeler`, `actions/setup-go`, `actions/setup-node`, `actions/setup-python`, `actions/stale`, `slackapi/slack-github-action`) - [ ] <!-- unlimit-branch=renovate/postgres-17.x -->Update postgres Docker tag to v17 - [ ] <!-- unlimit-branch=renovate/redis-8.x -->Update redis Docker tag to v8 - [ ] <!-- create-all-rate-limited-prs -->🔐 **Create all rate-limited PRs at once** 🔐 ## Pending Status Checks The following updates await pending status checks. To force their creation now, click on a checkbox below. - [ ] <!-- approvePr-branch=renovate/confluentinc-cp-kafka-7.x -->Update confluentinc/cp-kafka Docker tag to v7.9.9 - [ ] <!-- approvePr-branch=renovate/rules_rs-0.x -->Update dependency rules_rs to v0.0.102 - [ ] <!-- approvePr-branch=renovate/franz-go -->Update module github.com/twmb/franz-go to v1.21.6 - [ ] <!-- approvePr-branch=renovate/google.golang.org-protobuf-1.x -->Update module google.golang.org/protobuf to v1.36.12 - [ ] <!-- approvePr-branch=renovate/dd_sds-0.x -->Update Rust crate dd_sds to v0.1.0-20260813-972b5d8d1827 - [ ] <!-- approvePr-branch=renovate/http-body-util-0.x-lockfile -->Update Rust crate http-body-util to v0.1.5 - [ ] <!-- approvePr-branch=renovate/thiserror-2.x-lockfile -->Update Rust crate thiserror to v2.0.20 - [ ] <!-- approvePr-branch=renovate/hatchling-1.x -->Update dependency hatchling to v1.32.0 - [ ] <!-- approvePr-branch=renovate/azure-sdk-for-go-monorepo -->Update module github.com/Azure/azure-sdk-for-go/sdk/azcore to v1.23.0 - [ ] <!-- approvePr-branch=renovate/github.com-datadog-datadog-api-client-go-v2-2.x -->Update module github.com/DataDog/datadog-api-client-go/v2 to v2.64.0 - [ ] <!-- approvePr-branch=renovate/github.com-sirupsen-logrus-1.x -->Update module github.com/sirupsen/logrus to v1.10.0 - [ ] <!-- approvePr-branch=renovate/public.ecr.aws-docker-library-alpine-3.x -->Update public.ecr.aws/docker/library/alpine Docker tag to v3.24.1 - [ ] <!-- approvePr-branch=renovate/ureq-3.x-lockfile -->Update Rust crate ureq to v3.4.0 - [ ] <!-- approvePr-branch=renovate/npm-sentry-dotagents-3.x -->Update dependency npm:@sentry/dotagents to v3 --- > [!WARNING] > Renovate failed to look up the following dependencies: `Failed to look up go package github.com/evanphx/json-patch/v5: no-result`, `Failed to look up go package istio.io/api: no-result`, `Failed to look up go package k8s.io/klog/v2: no-result`, `Failed to look up go package gotest.tools/gotestsum: no-result`. > > Files affected: `go.mod`, `internal/tools/go.mod`, `pkg/fleet/installer/go.mod` --- ## Other Branches The following updates are pending. To force the creation of a PR, click on a checkbox below. - [ ] <!-- other-branch=renovate/integrations-core-digest -->Update integrations-core digest to 84ce638 - [ ] <!-- other-branch=renovate/aws-sdk-go-v2 -->Update aws-sdk-go-v2 (`github.com/aws/aws-sdk-go-v2`, `github.com/aws/aws-sdk-go-v2/config`, `github.com/aws/aws-sdk-go-v2/credentials`, `github.com/aws/aws-sdk-go-v2/service/ec2`, `github.com/aws/aws-sdk-go-v2/service/ecr`, `github.com/aws/aws-sdk-go-v2/service/ecs`, `github.com/aws/aws-sdk-go-v2/service/eks`, `github.com/aws/aws-sdk-go-v2/service/rds`, `github.com/aws/aws-sdk-go-v2/service/s3`, `github.com/aws/aws-sdk-go-v2/service/secretsmanager`, `github.com/aws/aws-sdk-go-v2/service/ssm`, `github.com/aws/aws-sdk-go-v2/service/sts`) - [ ] <!-- other-branch=renovate/github.com-go-delve-delve-1.x -->Update module github.com/go-delve/delve to v1.27.1 - [ ] <!-- other-branch=renovate/github.com-google-go-containerregistry-0.x -->Update module github.com/google/go-containerregistry to v0.21.9 ## Open The following updates have all been created. To force a retry/rebase of any, click on a checkbox below. - [ ] <!-- rebase-branch=renovate/go-github.com-datadog-dd-trace-go-v2-vulnerability -->[Update module github.com/DataDog/dd-trace-go/v2 to v2.8.1 [SECURITY]](../pull/53708) - [ ] <!-- rebase-branch=renovate/datadog-datadog-agent-dev-0.x -->[Update dependency DataDog/datadog-agent-dev to v0.38.0](../pull/52555) - [ ] <!-- rebase-branch=renovate/sentry-dotagents-3.x -->[Update dependency @sentry/dotagents to v3](../pull/54802) - [ ] <!-- rebase-branch=renovate/github.com-datadog-dd-trace-go-v2-2.x -->[Update module github.com/DataDog/dd-trace-go/v2 to v2.9.1](../pull/52521) - [ ] <!-- rebase-branch=renovate/gawk-5.x -->[Update dependency gawk to v5.4.0](../pull/52963) - [ ] <!-- rebase-branch=renovate/kubernetes-monorepo -->[Update kubernetes monorepo to v0.36.3](../pull/51833) (`k8s.io/api`, `k8s.io/apiextensions-apiserver`, `k8s.io/apimachinery`, `k8s.io/cli-runtime`, `k8s.io/client-go`, `k8s.io/component-base`, `k8s.io/cri-api`, `k8s.io/cri-client`, `k8s.io/kube-aggregator`, `k8s.io/kubectl`, `k8s.io/kubelet`, `k8s.io/metrics`) - [ ] <!-- rebase-branch=renovate/github.com-godror-godror-0.x -->[Update module github.com/godror/godror to v0.51.0](../pull/53235) - [ ] <!-- rebase-branch=renovate/k8s.io-autoscaler-vertical-pod-autoscaler-1.x -->[Update module k8s.io/autoscaler/vertical-pod-autoscaler to v1.7.1](../pull/51852) - [ ] <!-- rebase-branch=renovate/k8s.io-kube-state-metrics-v2-2.x -->[Update module k8s.io/kube-state-metrics/v2 to v2.19.1](../pull/52895) - [ ] <!-- rebase-branch=renovate/sigs.k8s.io-custom-metrics-apiserver-1.x -->[Update module sigs.k8s.io/custom-metrics-apiserver to v1.36.0](../pull/52282) - [ ] <!-- rebase-branch=renovate/docker.io-library-ubuntu-26.x -->[Update docker.io/library/ubuntu Docker tag to v26](../pull/52153) - [ ] <!-- rebase-branch=renovate/docker.io-ubuntu-26.x -->[Update docker.io/ubuntu Docker tag to v26](../pull/50840) - [ ] <!-- rebase-branch=renovate/github.com-cloudfoundry-community-go-cfclient-v2-3.x -->[Update module github.com/cloudfoundry-community/go-cfclient/v2 to v3](../pull/53622) - [ ] <!-- rebase-branch=renovate/github.com-netsampler-goflow2-2.x -->[Update module github.com/netsampler/goflow2 to v2](../pull/53239) - [ ] <!-- rebase-branch=renovate/major-franz-go -->[Update module github.com/twmb/franz-go/pkg/kmsg to v2](../pull/53824) - [ ] <!-- rebase-all-open-prs -->**Click on this checkbox to rebase all open PRs at once** ## PR Closed (Blocked) The following updates are blocked by an existing closed PR. To recreate the PR, click on a checkbox below. - [ ] <!-- recreate-branch=renovate/rules_go-0.x -->[Update dependency rules_go to v0.62.0](../pull/54068) - [ ] <!-- recreate-branch=renovate/code.cloudfoundry.org-bbs-1.x -->[Update module code.cloudfoundry.org/bbs to v1.11.0](../pull/53818) - [ ] <!-- recreate-branch=renovate/github.com-aws-karpenter-provider-aws-1.x -->[Update module github.com/aws/karpenter-provider-aws to v1.14.0](../pull/53819) - [ ] <!-- recreate-branch=renovate/github.com-bazelbuild-rules_go-0.x -->[Update module github.com/bazelbuild/rules_go to v0.62.0](../pull/54057) - [ ] <!-- recreate-branch=renovate/gopkg.in-datadog-dd-trace-go.v1-1.x -->[Update module gopkg.in/DataDog/dd-trace-go.v1 to v1.74.8](../pull/52894) - [ ] <!-- recreate-branch=renovate/sigs.k8s.io-karpenter-1.x -->[Update module sigs.k8s.io/karpenter to v1.14.0](../pull/53820) - [ ] <!-- recreate-branch=renovate/chef-sugar-5.x -->[Update dependency chef-sugar to v5](../pull/51540) - [ ] <!-- recreate-branch=renovate/invoke-3.x -->[Update dependency invoke to v3](../pull/50838) - [ ] <!-- recreate-branch=renovate/code.cloudfoundry.org-bbs-models-1.x -->[Update module code.cloudfoundry.org/bbs/models to v1](../pull/53823) - [ ] <!-- recreate-branch=renovate/github.com-santhosh-tekuri-jsonschema-v5-6.x -->[Update module github.com/santhosh-tekuri/jsonschema/v5 to v6](../pull/54069) - [ ] <!-- recreate-branch=renovate/go.etcd.io-etcd-client-v2-3.x -->[Update module go.etcd.io/etcd/client/v2 to v3](../pull/53825) - [ ] <!-- recreate-branch=renovate/go.yaml.in-yaml-v2-3.x -->[Update module go.yaml.in/yaml/v2 to v3](../pull/53527) ## Detected Dependencies > [!NOTE] > Detected dependencies section has been truncated <details><summary>bazel-module (2)</summary> <blockquote> <details><summary>deps/repos.MODULE.bazel</summary> </details> <details><summary>MODULE.bazel (20)</summary> - `bazel_lib 3.7.1` - `bazel_skylib 1.9.2` - `gawk 5.3.2.bcr.7` → [Updates: `5.4.0`] - `gazelle 0.52.2` - `libarchive 3.8.1.bcr.2` - `platforms 1.1.0` - `re.bzl 0.3.1` - `rules_cc 0.2.22` - `rules_flex 0.4.1` - `rules_go 0.61.1` → [Updates: `0.62.0`] - `rules_m4 0.3.bcr.1` - `rules_multitool 1.11.1` - `rules_python 2.2.0` - `rules_rs 0.0.27` → [Updates: `0.0.102`] - `rules_rust 0.73.0` - `rules_rust_prost 0.73.0` - `rules_shell 0.8.0` - `toml.bzl 0.4.1` - `rules_testing 0.9.0` - `apple_support 2.8.0` </details> </blockquote> </details> <details><summary>bazelisk (1)</summary> <blockquote> <details><summary>.bazelversion</summary> </details> </blockquote> </details> <details><summary>bitbucket-pipelines (1)</summary> <blockquote> <details><summary>.gitlab/.pre/cancel-prev-pipelines.yml</summary> </details> </blockquote> </details> <details><summary>bundler (1)</summary> <blockquote> <details><summary>omnibus/Gemfile (2)</summary> - `chef-sugar v3.6.0` → [Updates: `v5.1.12`] - `mixlib-cli '~> 2.1.0'` </details> </blockquote> </details> <details><summary>cargo (9)</summary> <blockquote> <details><summary>Cargo.toml (56)</summary> - `anyhow 1.0.98` - `cap-std 4.0` - `caps 0.5` - `chrono 0.4` - `clap 4.5` → [Updates: `4.5`] - `elf 0.8.0` - `glob-match 0.2` - `http-body-util 0.1` → [Updates: `0.1`] - `hostname 0.4` - `hyper 1` - `hyper-util 0.1` - `libc 0.2` - `log 0.4` - `prost 0.14` - `prost-build 0.14` - `prost-types 0.14` - `protoc-gen-prost 0.5` - `protoc-gen-tonic 0.5` - `lru 0.18.0` - `memchr 2.7.6` - `nom 8.0` - `normalize-path 0.2` - `phf 0.14` - `rawzip 0.5.0` - `xml-rs 1.0` - `rmp-serde 1.3` - `serde 1.0.219` - `serde_json 1.0` - `serde_yaml 0.9` - `time 0.3` - `thiserror 2.0.12` → [Updates: `2.0.12`] - `tokio 1` - `tokio-stream 0.1` - `tonic 0.14` - `tonic-build 0.14` - `tonic-prost 0.14` - `tonic-prost-build 0.14` - `tonic-reflection 0.14` - `ureq 3.0` → [Updates: `3.0`] - `uzers 0.12` - `walkdir 2` - `saphyr-parser 0.0.11` - `yaml-rust2 0.11` - `zip 8.0` - `flate2 1.1` - `tower 0.5` - `uuid 1` - `windows-registry 0.6` - `windows-sys 0.61` - `dircpy 0.3.19` - `regex 1` - `memmap2 0.9` - `nix 0.31` - `scopeguard 1.2` - `temp-env 0.3` - `tempfile 3.0` </details> <details><summary>cmd/ai_prompt_logger/Cargo.toml</summary> </details> <details><summary>comp/core/log/rust/Cargo.toml</summary> </details> <details><summary>pkg/collector/sharedlibrary/rustchecks/checks/datasecurity/Cargo.toml (2)</summary> - `dd_sds =0.1.0-20260803-1e4349aada52` → [Updates: `=0.1.0-20260813-972b5d8d1827`] - `postgres 0.19` </details> <details><summary>pkg/collector/sharedlibrary/rustchecks/checks/example/Cargo.toml</summary> </details> <details><summary>pkg/collector/sharedlibrary/rustchecks/core/Cargo.toml</summary> </details> <details><summary>pkg/discovery/module/rust/Cargo.toml</summary> </details> <details><summary>pkg/privateactionrunner/par-control/Cargo.toml</summary> </details> <details><summary>pkg/procmgr/rust/Cargo.toml</summary> </details> </blockquote> </details> <details><summary>docker-compose (36)</summary> <blockquote> <details><summary>cmd/host-profiler/docker-compose.yml (1)</summary> - `registry.datadoghq.com/agent 7` </details> <details><summary>pkg/collector/corechecks/oracle/compose/docker-compose.yml</summary> </details> <details><summary>pkg/discovery/module/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/amqp/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/http/testutil/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/kafka/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/mongo/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/mysql/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/postgres/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/redis/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/tls/gotls/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/tls/nodejs/testdata/docker-compose-ubuntu.yml</summary> </details> <details><summary>pkg/network/protocols/tls/nodejs/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/tracer/testdata/dnsworkload/docker-compose.yml</summary> </details> <details><summary>pkg/network/usm/testdata/bio_leak_test/docker-compose.yml</summary> </details> <details><summary>pkg/network/usm/testdata/musl/docker-compose.yml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/dogstatsd/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/jmxfetch/docker-compose-all-metrics.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/jmxfetch/docker-compose-slow-metrics.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/jmxfetch/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/logger/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/redis/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/integration/etcd/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/integration/kafka/docker-compose.yaml (3)</summary> - `confluentinc/cp-kafka 7.9.8` → [Updates: `7.9.9`, `8.3.0`] - `confluentinc/cp-kafka 7.9.8` → [Updates: `7.9.9`, `8.3.0`] - `confluentinc/cp-kafka 7.9.8` → [Updates: `7.9.9`, `8.3.0`] </details> <details><summary>test/e2e-framework/components/integration/postgres/docker-compose.yaml (2)</summary> - `postgres 16` → [Updates: `17`] - `postgres 16` → [Updates: `17`] </details> <details><summary>test/e2e-framework/components/integration/redisdb/docker-compose.yaml (2)</summary> - `redis 7.2` → [Updates: `7.4`, `8.2`] - `redis 7.2` → [Updates: `7.4`, `8.2`] </details> <details><summary>test/fakeintake/docker-compose.yaml</summary> </details> <details><summary>test/new-e2e/examples/testfixtures/docker-compose.fake-process.yaml</summary> </details> <details><summary>test/new-e2e/examples/testfixtures/docker-compose.lighttpd.yaml</summary> </details> <details><summary>test/new-e2e/tests/agent-health/fixtures/docker-compose.busybox.yaml</summary> </details> <details><summary>test/new-e2e/tests/discovery/testdata/compose/docker-compose.configfilesdiscovery-kafka.yaml</summary> </details> <details><summary>test/new-e2e/tests/discovery/testdata/compose/docker-compose.configfilesdiscovery-redis.yaml</summary> </details> <details><summary>test/new-e2e/tests/discovery/testdata/compose/docker-compose.fake-krakend.yaml</summary> </details> <details><summary>test/new-e2e/tests/fips-compliance/fixtures/docker-compose-cluster-agent.yaml</summary> </details> <details><summary>test/new-e2e/tests/fips-compliance/fixtures/docker-compose-fips-server.yaml</summary> </details> <details><summary>test/new-e2e/tests/fips-compliance/fixtures/docker-compose.yaml</summary> </details> </blockquote> </details> <details><summary>dockerfile (15)</summary> <blockquote> <details><summary>Dockerfiles/agent-ddot/Dockerfile</summary> </details> <details><summary>Dockerfiles/agent-ddot/Dockerfile.agent-otel (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/agent/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/agent/windows/amd64/Dockerfile (1)</summary> - `mcr.microsoft.com/dotnet/sdk 9.0-windowsservercore-ltsc2019` </details> <details><summary>Dockerfiles/base-image/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/cluster-agent/Dockerfile (2)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/ddot-ebpf/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/dogstatsd/alpine/Dockerfile (1)</summary> - `public.ecr.aws/docker/library/alpine 3.23.3` → [Updates: `3.24.1`] </details> <details><summary>Dockerfiles/otel-agent/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>test/e2e-framework/resources/local/podman/data/Dockerfile (1)</summary> - `docker.io/library/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>test/fakeintake/Dockerfile (2)</summary> - `docker.io/library/golang 1.26.5` - `docker.io/library/alpine 3.24.1` </details> <details><summary>tools/ebpf/Dockerfiles/Dockerfile-process-agent-dev</summary> </details> <details><summary>tools/ebpf/Dockerfiles/Dockerfile-security-agent-dev</summary> </details> <details><summary>tools/gdb/Dockerfile (1)</summary> - `registry.datadoghq.com/agent 7` </details> <details><summary>tools/host-profiler/Dockerfile</summary> </details> </blockquote> </details> <details><summary>github-actions (45)</summary> <blockquote> <details><summary>.github/actions/bazel-cache/action.yml (2)</summary> - `actions/cache v6.1.0@55cc8345863c7cc4c66a329aec7e433d2d1c52a9` - `actions/cache v6.1.0@55cc8345863c7cc4c66a329aec7e433d2d1c52a9` </details> <details><summary>.github/actions/deps-tidy-push/action.yml</summary> </details> <details><summary>.github/actions/deps-tidy-setup/action.yml (1)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` </details> <details><summary>.github/actions/install-dda/action.yml (3)</summary> - `actions/cache v6.1.0@55cc8345863c7cc4c66a329aec7e433d2d1c52a9` - `DataDog/datadog-agent-dev install@00e4a423088309efce1d5ba6b8c5366eef648710` - `DataDog/datadog-agent-dev install@00e4a423088309efce1d5ba6b8c5366eef648710` </details> <details><summary>.github/workflows/add-dependabot-pr-to-mq.yml (3)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/add-label-community-pr.yml (2)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/add-label-pr.yml (3)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/add-milestone.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/agenttelemetry-metric-reminder.yml (1)</summary> - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/ask-review.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/assess-permissions.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/assign-issue.yml (1)</summary> - `DataDog/issue-triage-action v1.0.1@b39f0bc12abc52fe8aa70dc9b9353bf307a13219` </details> <details><summary>.github/workflows/backport-pr.yml (4)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/buildimages-update.yml (5)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/chase-for-qa-cards.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/check-issue-status.yml (5)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/check-skip.yml</summary> </details> <details><summary>.github/workflows/cla.yml (2)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `contributor-assistant/github-action v2.6.1@ca4a40a7d1004f18d9960b404b97e5f30a505a08` </details> <details><summary>.github/workflows/code-review-complexity.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/code-review.yml (1)</summary> - `DataDog/code-review-action v1.1.0@56d6862711348b11ec2603edfb29c52c09f4b84c` </details> <details><summary>.github/workflows/codex-review-draft.yml (1)</summary> - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/codex-review-ready-for-review.yml</summary> </details> <details><summary>.github/workflows/collector-generate-and-update.yml (5)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `slackapi/slack-github-action v3.0.5@0d95c9a7becc1e6e297d76df9bc735c44f4cbcbc` → [Updates: `v4.0.0`] </details> <details><summary>.github/workflows/create-rc-pr.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/cws-btfhub-sync.yml (11)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `actions/upload-artifact v7.0.1@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `actions/download-artifact v8.0.1@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c` - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `ubuntu 24.04` - `ubuntu 24.04` </details> <details><summary>.github/workflows/deps-tidy.yml (7)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `dtolnay/rust-toolchain v1@e97e2d8cc328f1b50210efc529dca0028893a2d9` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `rust stable` </details> <details><summary>.github/workflows/do-not-merge.yml</summary> </details> <details><summary>.github/workflows/docs-dev.yml (8)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/upload-artifact v7.0.1@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a` - `actions/download-artifact v8.0.1@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c` - `peaceiris/actions-gh-pages v4.1.0@84c30a85c19949d7eee79c4ff27748b70285e453` </details> <details><summary>.github/workflows/go-update-commenter.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/gohai.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] </details> <details><summary>.github/workflows/label-analysis.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/labeler.yml (1)</summary> - `actions/labeler v6.2.0@b8dd2d9be0f68b860e7dae5dae7d772984eacd6d` → [Updates: `v7.0.0`] </details> <details><summary>.github/workflows/markdown-lint-check.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `tcort/github-action-markdown-link-check v1.1.2@e7c7a18363c842693fadde5d41a3bd3573a7a225` → [Updates: `v1.1.3`] </details> <details><summary>.github/workflows/push-bazel-cache.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/report-merged-pr.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `DataDog/dd-sts-action v1.0.0@2e8187910199bd93129520183c093e19aa585c75` → [Updates: `v1.0.5`] </details> <details><summary>.github/workflows/slapr_backport.yml (1)</summary> - `DataDog/slapr 1.1.0@95312d6b8528460243ba27c7f8167bfe20a68bec` </details> <details><summary>.github/workflows/slapr.yml (3)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `DataDog/slapr 1.1.0@95312d6b8528460243ba27c7f8167bfe20a68bec` </details> <details><summary>.github/workflows/stale.yml (2)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/stale v10.4.0@1e223db275d687790206a7acac4d1a11bd6fe629` → [Updates: `v11.0.0`] </details> <details><summary>.github/workflows/test-devcontainer.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-node v6.5.0@249970729cb0ef3589644e2896645e5dc5ba9c38` → [Updates: `v7.0.0`] </details> <details><summary>.github/workflows/update-dependencies.yml (4)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/update-ebpf-profiler-branch.yml (4)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/update-kubernetes-versions.yml (8)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-python v6.3.0@ece7cb06caefa5fff74198d8649806c4678c61a1` → [Updates: `v7.0.0`] - `helm/kind-action v1.14.0@ef37e7f390d99f746eb8b610417061a60e82a6cc` - `aws-actions/configure-aws-credentials v6.2.2@517a711dbcd0e402f90c77e7e2f81e849156e31d` → [Updates: `v6.2.3`] - `docker/login-action v4.4.0@af1e73f918a031802d376d3c8bbc3fe56130a9b0` → [Updates: `v4.6.0`] - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `python 3.14` </details> <details><summary>.github/workflows/upgrade-python-patch-version.yml (5)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-python v6.3.0@ece7cb06caefa5fff74198d8649806c4678c61a1` → [Updates: `v7.0.0`] - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `python 3.14` </details> <details><summary>.github/workflows/validate-renovate-deps.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/warn-failed-dependabot-pr.yml</summary> </details> </blockquote> </details> <details><summary>gomod (80)</summary> <blockquote> <details><summary>comp/anomalydetection/observer/def/go.mod</summary> </details> <details><summary>comp/anomalydetection/recorder/def/go.mod</summary> </details> <details><summary>comp/anomalydetection/severityevents/def/go.mod</summary> </details> <details><summary>comp/api/api/def/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/agenttelemetry/def/go.mod</summary> </details> <details><summary>comp/core/agenttelemetry/fx/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/agenttelemetry/impl/go.mod (7)</summary> - `github.com/DataDog/zstd v1.5.8-0.20260421145859-31a7e515a571@31a7e515a571` → [Updates: `v1.5.8-0.20260421145859-31a7e515a571`] - `github.com/prometheus/client_model v0.6.2` - `github.com/robfig/cron/v3 v3.0.1` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/core/config/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/configstreamconsumer/def/go.mod</summary> </details> <details><summary>comp/core/configsync/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/delegatedauth/api/cloudauth/aws/go.mod (2)</summary> - `github.com/aws/aws-sdk-go-v2 v1.43.3` → [Updates: `v1.43.4`] - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/delegatedauth/go.mod (2)</summary> - `github.com/cenkalti/backoff/v7 v7.0.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/flare/builder/go.mod</summary> </details> <details><summary>comp/core/flare/types/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/hostname/hostnameinterface/def/go.mod</summary> </details> <details><summary>comp/core/hostname/hostnameinterface/go.mod</summary> </details> <details><summary>comp/core/hostname/hostnameinterface/mock/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/ipc/def/go.mod</summary> </details> <details><summary>comp/core/ipc/httphelpers/go.mod (2)</summary> - `github.com/mdlayher/vsock v1.3.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/ipc/impl/go.mod (2)</summary> - `github.com/gofrs/flock v0.13.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/ipc/mock/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/def/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/fx/go.mod</summary> </details> <details><summary>comp/core/log/impl-trace/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/impl/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/mock/go.mod</summary> </details> <details><summary>comp/core/secrets/def/go.mod</summary> </details> <details><summary>comp/core/secrets/fx/go.mod</summary> </details> <details><summary>comp/core/secrets/impl/go.mod (4)</summary> - `github.com/benbjohnson/clock v1.3.5` - `github.com/json-iterator/go v1.1.12` - `github.com/stretchr/testify v1.11.1` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/secrets/mock/go.mod (1)</summary> - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/secrets/noop-impl/go.mod</summary> </details> <details><summary>comp/core/secrets/utils/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/status/go.mod (4)</summary> - `github.com/dustin/go-humanize v1.0.1` - `github.com/fatih/color v1.19.0` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/status/statusimpl/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/tagger/def/go.mod</summary> </details> <details><summary>comp/core/tagger/fx-remote/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/tagger/generic_store/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/impl-remote/go.mod (5)</summary> - `github.com/cenkalti/backoff/v7 v7.0.0` - `github.com/google/uuid v1.6.0` - `github.com/mdlayher/vsock v1.3.0` - `github.com/stretchr/testify v1.11.1` - `google.golang.org/grpc v1.83.0` </details> <details><summary>comp/core/tagger/origindetection/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/subscriber/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/tags/go.mod</summary> </details> <details><summary>comp/core/tagger/telemetry/go.mod</summary> </details> <details><summary>comp/core/tagger/types/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/utils/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/telemetry/go.mod (6)</summary> - `github.com/prometheus/client_golang v1.24.1` - `github.com/prometheus/client_model v0.6.2` - `github.com/prometheus/common v0.70.1` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/def/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/forwarder/defaultforwarder/go.mod (6)</summary> - `github.com/benbjohnson/clock v1.3.5` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.uber.org/fx v1.24.0` - `go.uber.org/multierr v1.11.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/forwarder/orchestrator/orchestratorinterface/go.mod</summary> </details> <details><summary>comp/host-profiler/symboluploader/testdata/go.mod</summary> </details> <details><summary>comp/logs-library/go.mod (4)</summary> - `github.com/DataDog/agent-payload/v5 v5.0.209` - `github.com/benbjohnson/clock v1.3.5` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` </details> <details><summary>comp/logs/agent/config/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.yaml.in/yaml/v3 v3.0.5` </details> <details><summary>comp/netflow/payload/go.mod</summary> </details> <details><summary>comp/otelcol/collector-contrib/def/go.mod</summary> </details> <details><summary>comp/otelcol/collector-contrib/impl/go.mod</summary> </details> <details><summary>comp/otelcol/converter/def/go.mod</summary> </details> <details><summary>comp/otelcol/converter/impl/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/ddflareextension/def/go.mod</summary> </details> <details><summary>comp/otelcol/ddflareextension/impl/go.mod (6)</summary> - `github.com/google/go-cmp v0.7.0` - `github.com/google/uuid v1.6.0` - `github.com/mohae/deepcopy v0.0.0-20170929034955-c48cc78d4826@c48cc78d4826` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/otelcol/ddflareextension/types/go.mod</summary> </details> <details><summary>comp/otelcol/ddprofilingextension/def/go.mod</summary> </details> <details><summary>comp/otelcol/ddprofilingextension/impl/go.mod (3)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/DataDog/dd-trace-go/v2 v2.9.0` → [Updates: `v2.9.1`] - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/otelcol/logsagentpipeline/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/logsagentpipeline/logsagentpipelineimpl/go.mod</summary> </details> <details><summary>comp/otelcol/otlp/components/connector/datadogconnector/go.mod (5)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/google/go-cmp v0.7.0` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/otelcol/otlp/components/datadogconfig/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/otlp/components/exporter/datadogexporter/go.mod (4)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/otelcol/otlp/components/exporter/logsagentexporter/go.mod (4)</summary> - `github.com/DataDog/agent-payload/v5 v5.0.209` - `github.com/patrickmn/go-cache v2.1.0+incompatible` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/otlp/components/exporter/serializerexporter/go.mod (8)</summary> - `github.com/google/go-cmp v0.7.0` - `github.com/stretchr/testify v1.11.1` - `github.com/tinylib/msgp v1.6.4` - `go.uber.org/fx v1.24.0` - `go.uber.org/multierr v1.11.0` - `go.uber.org/zap v1.28.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] - `go.uber.org/atomic v1.11.0` </details> <details><summary>comp/otelcol/otlp/components/metricsclient/go.mod (2)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/otelcol/otlp/components/processor/infraattributesprocessor/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/otlp/testutil/go.mod (3)</summary> - `github.com/DataDog/sketches-go v1.4.8` - `github.com/stretchr/testify v1.11.1` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/otelcol/status/def/go.mod</summary> </details> <details><summary>comp/otelcol/status/impl/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.yaml.in/yaml/v3 v3.0.5` </details> <details><summary>comp/serializer/logscompression/go.mod</summary> </details> <details><summary>comp/serializer/metricscompression/go.mod</summary> </details> <details><summary>comp/trace/agent/def/go.mod</summary> </details> <details><summary>comp/trace/compression/def/go.mod</summary> </details> <details><summary>comp/trace/compression/impl-gzip/go.mod</summary> </details> <details><summary>comp/trace/compression/impl-zstd/go.mod (1)</summary> - `github.com/DataDog/zstd v1.5.8-0.20260421145859-31a7e515a571@31a7e515a571` → [Updates: `v1.5.8-0.20260421145859-31a7e515a571`] </details> <details><summary>go.mod (115)</summary> - `code.cloudfoundry.org/bbs v1.3.0` → [Updates: `v1.11.0`] - `code.cloudfoundry.org/bbs/models v0.0.0-20260618205254-dc4b9f8d5bc9@dc4b9f8d5bc9` → [Updates: `v1.8.0`] - `code.cloudfoundry.org/garden v0.0.0-20260617020226-a9e754564bb5@a9e754564bb5` → [Updates: `v0.0.0-20260811183727-158508cf0d71`] - `code.cloudfoundry.org/lager/v3 v3.78.0` → [Updates: `v3.81.0`] - `dario.cat/mergo v1.0.2` - `github.com/Azure/azure-sdk-for-go/sdk/azcore v1.22.0` → [Updates: `v1.23.0`] - `github.com/Azure/azure-sdk-for-go/sdk/azidentity v1.14.0` - `github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/azsecrets v1.5.0` - `github.com/CycloneDX/cyclonedx-go v0.11.0` - `github.com/DATA-DOG/go-sqlmock v1.5.2` - `github.com/DataDog/agent-payload/v5 v5.0.209` - `github.com/DataDog/datadog-api-client-go/v2 v2.62.0` → [Updates: `v2.64.0`] - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/DataDog/datadog-operator/api v0.0.0-20260807013103-1518bb55e423@1518bb55e423` → [Updates: `v0.0.0-20260812212652-5f8a87676244`] - `github.com/DataDog/datadog-traceroute v1.0.19` - `github.com/DataDog/dd-policy-engine/go v0.0.0-20260730181922-c5e419a4ec7d@c5e419a4ec7d` → [Updates: `v0.0.0-20260803230307-dd41045a4bb2`] - `github.com/DataDog/dd-trace-go/v2 v2.9.0` → [Updates: `v2.9.1`] - `github.com/DataDog/ddtrivy v0.0.0-20260519164847-bf6bcaf2f9b7@bf6bcaf2f9b7` → [Updates: `v0.0.0-20260519164847-bf6bcaf2f9b7`] - `github.com/DataDog/ebpf-manager v0.8.1` - `github.com/DataDog/go-acl v1.0.1` - `github.com/DataDog/go-sqllexer v0.2.4` - `github.com/DataDog/jsonapi v0.13.0` - `github.com/DataDog/rshell v0.0.24` - `github.com/DataDog/sketches-go v1.4.8` - `github.com/DataDog/watermarkpodautoscaler/apis v0.0.0-20250108152814-82e58d0231d1@82e58d0231d1` → [Updates: `v0.0.0-20260803084540-a82e1114b53b`] - `github.com/DataDog/zstd v1.5.8-0.20260421145859-31a7e515a571@31a7e515a571` → [Updates: `v1.5.8-0.20260421145859-31a7e515a571`] - `github.com/Masterminds/semver/v3 v3.5.0` - `github.com/Masterminds/sprig/v3 v3.3.0` - `github.com/Microsoft/go-winio v0.6.2` - `github.com/Microsoft/hcsshim v0.14.1` - `github.com/NVIDIA/go-nvml v0.13.1-0` - `github.com/ProtonMail/go-crypto v1.4.1` - `github.com/acobaugh/osrelease v0.1.0` - `github.com/alecthomas/units v0.0.0-20240927000941-0f3dac36c52b@0f3dac36c52b` - `github.com/aptly-dev/aptly v1.6.3` - `github.com/aquasecurity/trivy v0.72.0` → [Updates: `v0.73.0`] - `github.com/aquasecurity/trivy-db v0.0.0-20251222105351-a833f47f8f0d@a833f47f8f0d` → [Updates: `v0.0.0-20260813095258-0e0340a01b57`] - `github.com/aws/aws-sdk-go-v2 v1.43.3` → [Updates: `v1.43.4`] - `github.com/aws/aws-sdk-go-v2/config v1.32.34` → [Updates: `v1.32.35`] - `github.com/aws/aws-sdk-go-v2/credentials v1.19.33` → [Updates: `v1.19.34`] - `github.com/aws/aws-sdk-go-v2/service/ec2 v1.318.1` → [Updates: `v1.319.1`] - `github.com/aws/aws-sdk-go-v2/service/rds v1.120.1` → [Updates: `v1.124.1`] - `github.com/aws/aws-sdk-go-v2/service/secretsmanager v1.44.0` → [Updates: `v1.44.4`] - `github.com/aws/aws-sdk-go-v2/service/ssm v1.73.0` → [Updates: `v1.73.4`] - `github.com/aws/aws-sdk-go-v2/service/sts v1.45.3` → [Updates: `v1.45.4`] - `github.com/aws/karpenter-provider-aws v1.9.0` → [Updates: `v1.14.0`] - `github.com/aymerick/raymond v2.0.2+incompatible` - `github.com/bazelbuild/rules_go v0.61.1` → [Updates: `v0.62.0`] - `github.com/beevik/ntp v1.5.0` - `github.com/benbjohnson/clock v1.3.5` - `github.com/bhmj/jsonslice v1.1.3` - `github.com/blabber/go-freebsd-sysctl v0.0.0-20201130114544-503969f39d8f@503969f39d8f` - `github.com/bmatcuk/doublestar/v4 v4.10.0` - `github.com/cenkalti/backoff/v7 v7.0.0` - `github.com/cespare/xxhash/v2 v2.3.0` - `github.com/cilium/ebpf v0.22.0` - `github.com/clbanning/mxj/v2 v2.7.0` - `github.com/cloudflare/cbpfc v0.0.0-20260219140841-0661ad29132c@0661ad29132c` → [Updates: `v0.0.0-20260805072904-7ac485fd93e1`] - `github.com/cloudfoundry-community/go-cfclient/v2 v2.0.1-0.20230503155151-3d15366c5820@3d15366c5820` → [Updates: `v3.0.0-beta.1`] - `github.com/containerd/cgroups/v3 v3.1.3` - `github.com/containerd/containerd/api v1.11.1` - `github.com/containerd/containerd/v2 v2.2.5` → [Updates: `v2.3.3`] - `github.com/containerd/errdefs v1.0.0` - `github.com/containerd/typeurl/v2 v2.3.0` - `github.com/containernetworking/cni v1.3.0` - `github.com/coreos/go-semver v0.3.1` - `github.com/coreos/go-systemd/v22 v22.7.0` - `github.com/creack/pty v1.1.24` - `github.com/cri-o/ocicni v0.5.0` - `github.com/cyphar/filepath-securejoin v0.7.0` - `github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc@d8f796af33cc` - `github.com/distribution/reference v0.6.0` - `github.com/dustin/go-humanize v1.0.1` - `github.com/elastic/go-freelru v0.16.0` - `github.com/elastic/go-libaudit/v2 v2.6.2` - `github.com/elastic/go-seccomp-bpf v1.6.0` - `github.com/envoyproxy/gateway v1.7.4` → [Updates: `v1.8.3`] - `github.com/evanphx/json-patch/v5 v5.9.11` - `github.com/fatih/color v1.19.0` - `github.com/fatih/structtag v1.2.0` - `github.com/freddierice/go-losetup v0.0.0-20220711213114-2a14873012db@2a14873012db` - `github.com/ghodss/yaml v1.0.1-0.20220118164431-d8423dcdf344@d8423dcdf344` - `github.com/glaslos/ssdeep v1.0.0` - `github.com/go-delve/delve v1.27.0` → [Updates: `v1.27.1`] - `github.com/go-jose/go-jose/v4 v4.1.4` - `github.com/go-json-experiment/json v0.0.0-20250517221953-25912455fbc8@25912455fbc8` → [Updates: `v0.0.0-20260623181947-01eb4420fa68`] - `github.com/go-ole/go-ole v1.3.0` - `github.com/go-sql-driver/mysql v1.10.0` - `github.com/go-viper/mapstructure/v2 v2.5.0` - `github.com/go-zookeeper/zk v1.0.4` - `github.com/gobwas/glob v0.2.3` - `github.com/goccy/go-yaml v1.19.2` - `github.com/gocomply/scap v0.1.3` - `github.com/godbus/dbus/v5 v5.2.2` - `github.com/godror/godror v0.50.0` → [Updates: `v0.51.0`] - `github.com/gogo/protobuf v1.3.2` - `github.com/golang-jwt/jwt/v5 v5.3.1` - `github.com/golang/groupcache v0.0.0-20241129210726-2c02b8208cf8@2c02b8208cf8` - `github.com/golang/mock v1.7.0-rc.1` - `github.com/google/btree v1.1.3` - `github.com/google/cel-go v0.29.2` → [Updates: `v0.30.0`] - `github.com/google/go-cmp v0.7.0` - `github.com/google/go-containerregistry v0.21.7` → [Updates: `v0.21.9`] - `github.com/google/gofuzz v1.2.0` - `github.com/google/gopacket v1.1.19` - `github.com/google/uuid v1.6.0` - `github.com/gorilla/websocket v1.5.4-0.20250319132907-e064f32e3674@e064f32e3674` - `github.com/gosnmp/gosnmp v1.44.0` - `github.com/grpc-ecosystem/go-grpc-middleware/v2 v2.3.3` - `github.com/h2non/filetype v1.1.3` - `github.com/hashicorp/consul/api/v2 v2.0.0` - `github.com/hashicorp/go-multierror v1.1.1` - `github.com/hashicorp/go-retryablehttp v0.7.8` - `github.com/hashicorp/go-version v1.9.0` - `github.com/hashicorp/golang-lru/v2 v2.0.7` </details> </blockquote> </details> --- - [ ] <!-- manual job -->Check this box to trigger a request for Renovate to run again on this repository",
          "url": "https://github.com/DataDog/datadog-agent/issues/33469",
          "createdAt": "2025-01-28T12:05:52Z",
          "updatedAt": "2026-08-13T16:14:48Z",
          "timestamp": "2026-08-13T16:14:48Z",
          "metrics": {
            "reactions": 0,
            "comments": 0
          },
          "labels": [
            "team/agent-devx",
            "pending",
            "oss/0"
          ],
          "author": "renovate[bot]",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:908af68f382bf790a0a4",
        "signalId": "github:DataDog/datadog-agent:pull_request:54804",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "text",
          "updatedAt",
          "metrics",
          "labels"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54804",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix(installer): embed -nocap systemd unit templates",
          "text": "## What does this PR do? Adds `//go:embed` directives for `tmpl/gen/oci-nocap/*.service` and `tmpl/gen/debrpm-nocap/*.service`, and the matching Bazel `embedsrcs` entries, so the `-nocap` systemd unit templates ship inside the installer binary. Adds `embed_test.go`, which enumerates units through the `embed.FS` and asserts `GetSystemdUnit` resolves every unit in both the ambient-capability and `-nocap` variants. ## Motivation This is to address this escalation: https://datadoghq.atlassian.net/browse/AGENT-16750 `GetSystemdUnit` selects the `-nocap` templates on hosts whose kernel does not support ambient capabilities (older than 4.3), but no `//go:embed` directive covered those directories. Unit generation failed at runtime with: ``` failed to write stable units: open tmpl/gen/debrpm-nocap/datadog-agent.service: file does not exist ``` The package manager scriptlet ignores that failure, so the install reported success while the host was left with no Datadog units and `systemctl start datadog-agent` returned `Unit not found`. Both the classic DEB/RPM path and Fleet Automation remote upgrades and config experiments (`oci-nocap`) were affected. The existing tests missed this because they read the template tree from disk instead of from the `embed.FS`, so the templates were always present regardless of the embed directives. ## Verification - `dda inv test --targets=./pkg/fleet/installer/packages/embedded` - 83 tests passed - `bazel test //pkg/fleet/installer/packages/embedded:all` - `embedded_test` and `tmpl_test` passed - The new `TestGetSystemdUnitEmbedsAllVariants` fails on `main` (`file does not exist` for every `-nocap` unit) and passes with this change - `TestGetSystemdUnitSelectsNocapVariant` confirms the `-nocap` unit actually has `AmbientCapabilities=` stripped, not just that it loads ### Known gap, not addressed here `tmpl/datadog-agent-data-plane.service.tmpl` emits `AmbientCapabilities` unconditionally, without the `{{ if .AmbiantCapabilitiesSupported }}` guard its siblings use, so its two variants are byte-identical. That is a pre-existing template defect, out of scope for this fix, and is documented in a comment on the test. 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
          "url": "https://github.com/DataDog/datadog-agent/pull/54804",
          "createdAt": "2026-08-13T03:52:11Z",
          "updatedAt": "2026-08-13T16:13:25Z",
          "timestamp": "2026-08-13T16:13:25Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "qa/done",
            "medium review",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "mwdd146980",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:38158b246951d5a6e6d1",
        "signalId": "github:DataDog/datadog-agent:pull_request:54664",
        "event": "discovered",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54664",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[Backport 7.82.x]  feat(eudm): auto-enable logon_duration in end_user_device mode",
          "text": "Backport 1dbeb46efe19c82cc0f1f1064ea146467ea92be9 from #54434. ___ ### What does this PR do? Automatically enables the `logon_duration` feature when the Agent is in end-user-device mode (`infrastructure_mode: end_user_device`), so operators no longer have to set `logon_duration.enabled: true` separately. Two changes: 1. **`pkg/config/setup/config.go`** — `applyInfrastructureModeOverrides` now force-enables `logon_duration.enabled` (with `SourceInfraMode`) in the `end_user_device` branch, alongside the existing `process_collection`, `software_inventory`, and `notable_events` overrides. Because `SourceInfraMode` sits below explicit user config, a user who sets `logon_duration.enabled: false` still wins. 2. **`pkg/system-probe/config/config.go`** — the macOS `logon_duration` system-probe module gate now reads the flag from the **core** config (`datadog.yaml`) instead of the **system-probe** config (`system-probe.yaml`). Without this, the EUD override (which is applied to the core config) would enable the agent-side component but never start the system-probe module that actually collects the data on macOS. This mirrors how `software_inventory` is gated. ### Motivation WINA-3004 — reduce configuration friction for end-user-device deployments; `logon_duration` should be on by default in that mode. ### Describe how you validated your changes - Unit tests added in `pkg/config/setup/config_test.go`: EUD auto-enables `logon_duration.enabled`; non-EUD modes leave it at the default (`false`); an explicit user `false` overrides the EUD default. - `dda inv test --targets=./pkg/config/setup` and `--targets=./pkg/system-probe/config` both pass. ### Additional Notes - **Behavior change on macOS:** setting `logon_duration.enabled` only in `system-probe.yaml` no longer starts the module — the value must come from `datadog.yaml` (or `DD_LOGON_DURATION_ENABLED`). This matches `software_inventory`.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54664",
          "createdAt": "2026-08-10T17:48:21Z",
          "updatedAt": "2026-08-13T16:12:15Z",
          "timestamp": "2026-08-13T16:12:15Z",
          "metrics": {
            "reactions": 0,
            "comments": 3
          },
          "labels": [
            "team/ebpf-platform",
            "qa/done",
            "backport",
            "bot",
            "medium review",
            "team/agent-configuration",
            "internal",
            "team/fleet-automation"
          ],
          "author": "dd-octo-sts[bot]",
          "state": "closed",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:f8944c7e94658ac826fa",
        "signalId": "github:DataDog/datadog-agent:pull_request:54838",
        "event": "discovered",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54838",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] test CONNECTION_TOKENS_V2 Agent secret resolution",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54838",
          "createdAt": "2026-08-13T15:20:01Z",
          "updatedAt": "2026-08-13T16:11:56Z",
          "timestamp": "2026-08-13T16:11:56Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [],
          "author": "dd-gplassard",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:b93c1a9cae46d32788dc",
        "signalId": "github:DataDog/datadog-agent:pull_request:54758",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "title",
          "text",
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54758",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(softinv): report OS updates and kernel-mode drivers",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Extends the software inventory beyond installed applications with three collectors, under two new software types, `os_update` and `driver`: | Platform | Type | Source | |---|---|---| | Windows | `driver` | `Win32_SystemDriver` — every registered kernel-mode driver | | Windows | `os_update` | CBS servicing store, packages with `CurrentState == 112` | | macOS | `os_update` | `SystemVersion.plist`, plus `InstallHistory.plist` receipts | **Drivers.** `Win32_SystemDriver` projects the kernel driver services under `HKLM\\SYSTEM\\CurrentControlSet\\Services`, so it covers software-only drivers — EDR minifilters, network and DLP filters — that have no PnP device node and no driver-store INF and so are invisible to `Win32_PnPSignedDriver`. Microsoft inbox drivers are included: inbox driver CVEs and version skew are real signal. The class carries no version or vendor, so both come from the version resource of the image path. Only the numeric `VS_FIXEDFILEINFO` file version is accepted — the `FileVersion` string is routinely decorated or comma-separated, and a driver without a numeric version is dropped rather than guessed at. Image paths are normalized first (`\\??\\`, `\\SystemRoot\\`, `%SystemRoot%`, relative), and display names stored as MUI references (`@<dll>,-<id>`) are resolved with `SHLoadIndirectString`. Identity is the service name, which Windows guarantees unique. The version stays out of it so a bump reads as an update rather than remove + install, and two services sharing one binary (`tcpip`/`tcpip6`) stay distinct entries. Known limitations: UMDF user-mode drivers register no kernel service, and a driver whose service entry is created, loaded, then deleted is invisible — this is an inventory of registered drivers, not of code in the kernel. **Updates.** Identified by KB number where the servicing store records one, by package family otherwise; matching only `Package_for_KB…` would drop monthly cumulative updates (`Package_for_RollupFix~…`) entirely. macOS uses a constant `com.apple.macos` product code for the running system. **Deadline.** Each collector is bounded at 90s in the shared snapshot runner. A timeout is fatal, because a timed-out enumeration is an unknown state and a missing row reads downstream as a removal; zero rows is still a valid result. A hung native call cannot be cancelled — the WMI library takes no context — so a collector that misses its deadline is not started again until it returns. ### Motivation The inventory only covered installed applications, leaving OS patch level and kernel drivers invisible — two of the most useful signals for fleet visibility and compliance. The deadline is a prerequisite rather than a nicety: these sources can block, and a single slow `Collect()` previously stalled the whole snapshot with no upper bound. ### Describe how you validated your changes - Unit tests pass (66 on macOS, including the macOS integration test against a real host with `-test.short=false`); `bazel test //pkg/inventory/software:software_test` passes. - `dda inv linter.go` clean, and clean again under `GOOS=windows`, which type-checks the Windows-tagged files and their tests. - Coverage: deadline and in-flight behaviour, driver path normalization and display-name resolution, the numeric-version requirement, CBS parsing including `RollupFix` and servicing-stack packages, FILETIME conversion, macOS receipt filtering, and entry-ID uniqueness once the new families merge with application entries. - Real-host integration tests, gated on `testing.Short()`: Windows checks collected drivers against the `Services` registry key and logs every driver dropped with its reason; macOS asserts the running-system version matches `sw_vers -productVersion`. - A driver payload from a real Windows host was inspected end to end. It caught two drivers reporting an unresolved MUI reference as their name, fixed in 2741b66. **The Windows-tagged tests are type-checked but have not been executed.** They need a Windows host or CI. The macOS path has been exercised end to end. ### Additional Notes - A fatal error from any single collector still drops the whole snapshot (existing behaviour). Relevant to the new fatal paths: if the CBS key cannot be opened — for instance when system-probe is not elevated — application entries are lost too. - Reporting all kernel drivers adds roughly 250–450 entries per Windows host. Worth a look at payload size before this ships. - Enable with `software_inventory.enabled: true`, which drives both the system-probe module and the core agent component. No status or flare changes were needed, since `populateStatus` already groups by `Source`. - Worst-case snapshot duration is bounded per collector, not globally, so it scales with collector count. A snapshot-wide ceiling would be a separate change.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54758",
          "createdAt": "2026-08-11T23:51:09Z",
          "updatedAt": "2026-08-13T16:11:43Z",
          "timestamp": "2026-08-13T16:11:43Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "long review",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "sar-shah",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:9be15ede0856231146fa",
        "signalId": "github:DataDog/datadog-agent:pull_request:54633",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54633",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[AAD-39] Format logs in scorer events",
          "text": "### What does this PR do? > [!NOTE] > Context: https://github.com/DataDog/datadog-agent/pull/54572 For scorer events, we handled only metrics. This PR formats the metrics derived by logs such that we obtain log patterns instead of metric names. Example: ``` Top contributions: 1. 75% — log: ERROR: connection refused to db.prod:5432 — {service:api} 2. 25% — log: GET /checkout <*> returned 500 — {env:prod} ``` ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54633",
          "createdAt": "2026-08-10T12:28:52Z",
          "updatedAt": "2026-08-13T16:10:29Z",
          "timestamp": "2026-08-13T16:10:29Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "medium review",
            "internal"
          ],
          "author": "CelianR",
          "state": "open",
          "assignees": [
            "CelianR"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:ca79318a1bcd21f6da5e",
        "signalId": "github:DataDog/datadog-agent:pull_request:54634",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "metrics",
          "labels"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54634",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "optimize the complexity of the trace_contention_begin",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? This [commit](https://github.com/torvalds/linux/commit/e67ddd9b1cff7872d43ead73a1403c4e532003d9) landed in kernel v6.9 negatively effects the complexity of the `trace_contention_begin` bpf program. The verifier cannot effectively prune the state space of the binary search algorithm. In order to fix the load failures this PR moves the loop variables of the binary search into a percpu array map. Since the verifier cannot track the bounds of registers spilled to a map value, it can prune the state space more effectively. In order to make it reliable to use this scratch space the bpf program must now account for nested execution from different contexts. In order to handle this the PR introduce code to detect the execution context of the bpf program in the kernel and use that to select a slot to hold the loop variables. ### Motivation ### Describe how you validated your changes New tests cover the changes ### Additional Notes This PR is currently incomplete due to the lack of support for handling environments where kernel addresses from `/proc/kallsyms` are not readable such as when `kptr_restrict` is set and when `CAP_SYSLOG` is not available, in the cilium/ebpf loader. The loader automatically reads and caches addresses from /proc/kallsyms when `__ksyms` is used to mark global variables. I am working on upstreaming support for handling restricted environment to the cilium/ebpf loader.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54634",
          "createdAt": "2026-08-10T12:57:41Z",
          "updatedAt": "2026-08-13T16:07:46Z",
          "timestamp": "2026-08-13T16:07:46Z",
          "metrics": {
            "reactions": 1,
            "comments": 7
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/ebpf-platform",
            "qa/done",
            "long review",
            "ask-review",
            "team/agent-build",
            "internal"
          ],
          "author": "usamasaqib",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:74f0a36be69a7fa8f702",
        "signalId": "github:DataDog/datadog-agent:pull_request:54843",
        "event": "discovered",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54843",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CONTP-2006] feat(ddi): Connect custom workload targets to DDI controller and streaming",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Connects configurable workload target resolution to DatadogInstrumentation checks and logs. - Adds `instrumentation_crd_controller.custom_workload_targets` configuration. - Starts the Pod workloadmeta store and resolver when at least one custom target is configured. - Accepts registered target GVKs and generates CEL selectors against `container.pod.resolved_targets`. - Includes `apiVersion` when detecting duplicate target references. - Preserves `rootowner` matching for built-in workloads and EndpointSlice delivery for core `v1` Services. For example, a workload reached through an intermediate Kubernetes Job can be configured as: ```yaml instrumentation_crd_controller: custom_workload_targets: - target: apiVersion: example.com/v1 kind: ScheduledWorkload resource: scheduledworkloads via: - apiVersion: batch/v1 kind: Job resource: jobs ``` ### Motivation [CONTP-2006](https://datadoghq.atlassian.net/browse/CONTP-2006) DatadogInstrumentation supports core Kubernetes workload kinds and Argo Rollouts out of the box, but customers also run workloads through controllers such as Ray, Kueue, OpenKruise, and Strimzi. Customers need an opt-in way to declare the workload resources they use and the ownership path from Pods, without relying on a generic fallback or requiring every custom kind to be added to the Agent. ### Describe how you validated your changes ### Additional Notes [CONTP-2006]: https://datadoghq.atlassian.net/browse/CONTP-2006?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54843",
          "createdAt": "2026-08-13T15:53:26Z",
          "updatedAt": "2026-08-13T16:06:43Z",
          "timestamp": "2026-08-13T16:06:43Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [],
          "author": "Mathew-Estafanous",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:6fbe0d8b48624255035c",
        "signalId": "github:DataDog/datadog-agent:pull_request:54793",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54793",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Remove schemaBuilder and createschema command",
          "text": "### What does this PR do? Remove the `createschema` command and the schema builder config implementation. We no longer need to generate the schema. ### Motivation Cleanup now that schema is live and in use. ### Describe how you validated your changes CI ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54793",
          "createdAt": "2026-08-12T18:13:12Z",
          "updatedAt": "2026-08-13T16:06:22Z",
          "timestamp": "2026-08-13T16:06:22Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-build",
            "internal",
            "team/fleet-remediation",
            "team/fleet-automation"
          ],
          "author": "dustmop",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:df2fe2108e947d03a921",
        "signalId": "github:DataDog/datadog-agent:pull_request:54835",
        "event": "discovered",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54835",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] PAR secret resolution v2",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54835",
          "createdAt": "2026-08-13T14:21:30Z",
          "updatedAt": "2026-08-13T16:05:19Z",
          "timestamp": "2026-08-13T16:05:19Z",
          "metrics": {
            "reactions": 2,
            "comments": 6
          },
          "labels": [
            "team/container-platform",
            "long review",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "dd-gplassard",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:a78d6955183605528b15",
        "signalId": "github:DataDog/datadog-agent:pull_request:54834",
        "event": "discovered",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54834",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "ci: default GitLab jobs to shallow clones, keep full history where needed",
          "text": "## Summary - Default GitLab jobs to `GIT_DEPTH: 1` so most checkouts are a shallow clone of HEAD only. - Set `GIT_DEPTH: 0` on jobs that actually need git history (merge-base, ancestor walks, `git describe`, `git log` ranges, three-dot diffs, or checkout of another branch). - Jobs that inherit a full-history template but never use merge-base stay at depth 1 (`new-e2e-unit-tests`, upgrade/RPM install-package jobs). - `GIT_STRATEGY: clone` is not a full clone; clone with depth 1 is still shallow. Full history requires `GIT_DEPTH: 0`. Supersedes https://github.com/DataDog/datadog-agent/pull/54799 (opened from a fork). ## Test plan - [ ] Confirm a typical build/lint job clones with depth 1 and still has the working tree. - [ ] Confirm jobs that compute merge-base still succeed (`golang_deps_diff`, e2e `--impacted`, `static_quality_gates`, `files_inventory_check`, SMP merge-base check). - [ ] Confirm `setup_agent_version` can still run `git describe --tags`. - [ ] Confirm unit-test jobs with `FAST_TESTS=true` still detect impacted packages. - [ ] Confirm `benchmark` can check out `BASE_BRANCH` and `prebuild-workspace-image-check` can three-dot diff against `COMPARE_TO_BRANCH`. Made with [Cursor](https://cursor.com)",
          "url": "https://github.com/DataDog/datadog-agent/pull/54834",
          "createdAt": "2026-08-13T14:03:09Z",
          "updatedAt": "2026-08-13T16:05:03Z",
          "timestamp": "2026-08-13T16:05:03Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "team/agent-apm",
            "team/agent-security",
            "team/ebpf-platform",
            "qa/no-code-change",
            "team/container-platform",
            "team/agent-delivery",
            "long review",
            "team/agent-integrations",
            "team/container-integrations",
            "team/agent-devx",
            "team/agent-build",
            "team/windows-products",
            "team/profiling-full-host",
            "internal"
          ],
          "author": "mikesherovdd",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:af4cb09799e5f93dac86",
        "signalId": "github:DataDog/datadog-agent:pull_request:54670",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54670",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] [PAR split deployment] shut down idle private action executor",
          "text": "### What does this PR do? Makes the new on-demand PAR executor terminate after an idle period. This should be triggered by `par-control` via `dd-procmgrd` so this is really a fallback for the daemon not working properly. Idle period is configured via `private_action_runner.idle_timeout_seconds` with a 60-second default. We use 3x that value as a backstop behind the control plane's normal explicit stop. This behavior is currently dormant in supported deployments: executor mode exists, but no deployment launches `privateactionrunner run-executor` until the later process-manager and packaging layers activate it. ### Motivation `par-control` and the PAR executor are siblings managed by `dd-procmgrd`. The control plane normally stops an idle executor, but if it crashes, exhausts its restart limit, or is stopped independently, nothing else reclaims the executor. The executor must therefore own a self-termination backstop. ### Describe how you validated your changes On the Linux development VM: - `bazel test //pkg/privateactionrunner/executor:executor_test` - `bazel test //comp/privateactionrunner/impl:impl_test` - `bazel test //cmd/privateactionrunner/subcommands/runexecutor:runexecutor_test` The executor test target also passed 10 consecutive runs after the idle tests were converted to use a mock clock. ### Additional Notes The watchdog is configured only by executor mode, so the existing monolithic runner is unchanged. A user could invoke `run-executor` manually, but no supported host, Docker, or Kubernetes deployment currently does so.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54670",
          "createdAt": "2026-08-10T18:41:18Z",
          "updatedAt": "2026-08-13T16:02:34Z",
          "timestamp": "2026-08-13T16:02:34Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/agent-build",
            "team/action-platform",
            "internal",
            "team/fleet-automation"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:31830ac665657996a6a9",
        "signalId": "github:DataDog/datadog-agent:pull_request:54767",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "metrics",
          "labels"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54767",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "aix: populate datadog.yaml from env vars in the config script",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Seeds `datadog.yaml` from `DD_API_KEY`/`DD_SITE`/`DD_HOSTNAME`/`DD_TAGS`/`DD_ENV`/`DD_INFRASTRUCTURE_MODE`/proxy env vars on first install, mirroring the Linux install script. ### Motivation installp has no mechanism to pass parameters at install time, so this is the only way to configure the agent unattended on AIX. ### Describe how you validated your changes Ran all creation/skip/`DD_INSTALL_ONLY` scenarios in a sandbox on a real AIX 7.3 host and confirmed the resulting YAML and file permissions. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54767",
          "createdAt": "2026-08-12T09:07:16Z",
          "updatedAt": "2026-08-13T16:02:24Z",
          "timestamp": "2026-08-13T16:02:24Z",
          "metrics": {
            "reactions": 1,
            "comments": 1
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "medium review",
            "team/agent-runtimes",
            "team/agent-build",
            "internal"
          ],
          "author": "pgimalac",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:b9f578229e2d383b7eb9",
        "signalId": "github:DataDog/datadog-agent:pull_request:54845",
        "event": "discovered",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54845",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[release] Update release.json for 7.83.0-rc.3",
          "url": "https://github.com/DataDog/datadog-agent/pull/54845",
          "createdAt": "2026-08-13T16:01:16Z",
          "updatedAt": "2026-08-13T16:02:05Z",
          "timestamp": "2026-08-13T16:02:05Z",
          "metrics": {
            "reactions": 2,
            "comments": 1
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "qa/no-code-change",
            "team/agent-delivery",
            "long review",
            "team/agent-runtimes",
            "internal"
          ],
          "author": "temporal-github-worker-1[bot]",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:f6dff3264f3e9f5bb548",
        "signalId": "github:DataDog/datadog-agent:pull_request:54769",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "labels"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54769",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Split network-devices section in it's own file and fix ID links",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Split netowrk-devices section in it's own file and fix ID links",
          "url": "https://github.com/DataDog/datadog-agent/pull/54769",
          "createdAt": "2026-08-12T10:03:17Z",
          "updatedAt": "2026-08-13T16:00:45Z",
          "timestamp": "2026-08-13T16:00:45Z",
          "metrics": {
            "reactions": 1,
            "comments": 1
          },
          "labels": [
            "changelog/no-changelog",
            "team/agent-apm",
            "team/agent-security",
            "team/remote-config",
            "team/ebpf-platform",
            "team/agent-cspm",
            "qa/done",
            "team/container-platform",
            "long review",
            "team/container-integrations",
            "team/agent-runtimes",
            "team/agent-configuration",
            "team/agent-log-pipelines",
            "team/container-experiences",
            "team/agent-build",
            "team/kubernetes-experiences",
            "team/action-platform",
            "internal",
            "team/network-device-monitoring-core",
            "team/gpu-monitoring-agent",
            "team/fleet-remediation",
            "team/fleet-automation"
          ],
          "author": "hush-hush",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:5bc36e4d271664f6db67",
        "signalId": "github:DataDog/datadog-agent:pull_request:54676",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54676",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[procmgr] Extract shared Rust client",
          "text": "### What does this PR do? Extracts a `dd-procmgr-client` Rust crate from client code in `dd-procmgrd`: - process-manager protobuf/gRPC bindings; - default endpoint and `DD_PM_SOCKET_PATH` handling; - Unix socket and Windows named-pipe connections; - Windows busy-pipe retry behavior. The `dd-procmgr` CLI now uses this crate. The daemon reuses its bindings and endpoint resolution, but keeps all server transport, process supervision, and lifecycle code. This is a code move and dependency cleanup. It does not change the protocol, endpoint defaults, retry policy, or process-manager behavior. ### Why? A later PR in the Private Action Runner split-mode stack (#54589) adds a second Rust client of `dd-procmgrd`. Without this crate, that client would either depend on the full daemon implementation or copy its platform-specific connection code. ### Validation ```text dda env dev run -- bazel test //pkg/procmgr/rust/... dda env dev run -- cargo clippy --manifest-path pkg/procmgr/rust/client/Cargo.toml --all-targets -- -D warnings dda env dev run -- cargo clippy --manifest-path pkg/procmgr/rust/Cargo.toml --all-targets --features test-helpers -- -D warnings ``` The Bazel suite covers the client, daemon, CLI, and CLI/daemon E2E tests.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54676",
          "createdAt": "2026-08-10T20:37:41Z",
          "updatedAt": "2026-08-13T15:58:22Z",
          "timestamp": "2026-08-13T15:58:22Z",
          "metrics": {
            "reactions": 2,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "long review",
            "team/agent-runtimes",
            "team/agent-devx",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:3f8a169c8c52e9f7feb1",
        "signalId": "github:DataDog/datadog-agent:pull_request:53496",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "metrics",
          "labels"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53496",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add support for renamed settings",
          "text": "### What does this PR do? Add support for renamed settings This PR introduce a rename mechanism within the config. It also use the warning from the config to raise error about unknown keys.",
          "url": "https://github.com/DataDog/datadog-agent/pull/53496",
          "createdAt": "2026-07-10T10:19:18Z",
          "updatedAt": "2026-08-13T15:54:41Z",
          "timestamp": "2026-08-13T15:54:41Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog",
            "team/agent-apm",
            "team/ebpf-platform",
            "qa/done",
            "long review",
            "team/agent-configuration",
            "team/agent-devx",
            "team/agent-build",
            "internal",
            "team/fleet-remediation",
            "team/fleet-automation"
          ],
          "author": "hush-hush",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:745087aeaa0d602e10db",
        "signalId": "github:DataDog/datadog-agent:pull_request:54836",
        "event": "discovered",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54836",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Commit the configuration examples to the repo",
          "text": "### What does this PR do? Those example will be updated each time we release a new Agent",
          "url": "https://github.com/DataDog/datadog-agent/pull/54836",
          "createdAt": "2026-08-13T14:54:10Z",
          "updatedAt": "2026-08-13T15:54:15Z",
          "timestamp": "2026-08-13T15:54:15Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-configuration",
            "team/agent-devx",
            "team/agent-build",
            "team/windows-products",
            "internal",
            "team/fleet-automation"
          ],
          "author": "hush-hush",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:19276211c86c602f2f6d",
        "signalId": "github:DataDog/datadog-agent:pull_request:54748",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54748",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Read embedded Python version from Bazel in the python-version task",
          "text": "### What does this PR do? Migrates the `python-version` invoke task (`tasks/python_version.py`) to treat the Bazel module file `deps/cpython/cpython.MODULE.bazel` as the single source of truth for the embedded Python version: - `_get_current_python_version()` now reads `PYTHON_VERSION` from the Bazel file instead of `default_version` in `omnibus/config/software/python3.rb`. - Drops `_prepare_omnibus_update()` (and its call in `update()`), so the task no longer rewrites `default_version` on a bump. The Bazel file already carries both the version and the source-tarball `sha256`, and already drives the build. - Updates `tasks/unit_tests/python_version_tests.py` accordingly (Bazel-based fixtures for the read path; removes the now-obsolete omnibus-write test). ### Motivation PR #54744 removes the unused `default_version`/`relative_path` fields from `omnibus/config/software/python3.rb` (Bazel drives the CPython build now). As Codex flagged there, removing `default_version` would break the documented Python bump workflow, because `_get_current_python_version()` / `_prepare_omnibus_update()` still scan `python3.rb` for that marker and raise if it is absent. This change decouples the task from the omnibus marker so the bump workflow keeps working regardless of the order in which this PR and #54744 merge. It also aligns with the `tasks/AGENTS.md` \"single source of truth\" idiom. ### Describe how you validated your changes - `dda inv invoke-unit-tests.run` fixtures updated; ran `tasks/unit_tests/python_version_tests.py` (15 tests) — all pass. - Live check: `_get_current_python_version()` returns `3.13.14` on `main`, read from the Bazel file. - `ruff check` and `ruff format --check` clean on both changed files. ### Additional Notes Follows up on the discussion in #54744. No release note: this is developer tooling (invoke task) and is not shipped with the Agent.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54748",
          "createdAt": "2026-08-11T20:19:47Z",
          "updatedAt": "2026-08-13T15:54:05Z",
          "timestamp": "2026-08-13T15:54:05Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/agent-integrations",
            "team/agent-devx",
            "internal"
          ],
          "author": "Kyle-Neale",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:6bf571445bb9ec375015",
        "signalId": "github:DataDog/datadog-agent:pull_request:54593",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54593",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] orchestrate par-control tasks",
          "text": "### What does this PR do? Composes the process manager, effective configuration, OPMS client, and executor channel into the production `par-control` loop: - Adds bounded task concurrency and retry policy. - Leaves the executor stopped while idle and starts it only after a task is dequeued. - Starts task heartbeats at dequeue and continues them through executor cold start, key synchronization, execution, and terminal publication. - Sends runner liveness reports independently of task flow. - Lazily synchronizes and caches signing keys for later executor starts. - Stops the executor after the configured idle period and drains in-flight work during shutdown. - Wires the final binary and updates its documentation. - Restores Windows compatibility for the Rust Bazel test by staging the Agent OpenSSL DLLs in runfiles and placing that directory on the test process's `PATH`. ### Motivation Keep orchestration policy separate from the independently tested lifecycle and network primitives it coordinates. In particular, the control process should preserve an OPMS lease while paying the executor's cold-start cost and should not keep the higher-RSS Go process alive when no work is available. ### Validation - `dda env dev run -- bazel test //pkg/privateactionrunner/par-control:par-control_test` - `dda env dev run -- env -u PKG_CONFIG_LIBDIR cargo clippy --manifest-path pkg/privateactionrunner/par-control/Cargo.toml --all-targets -- -D warnings` - Buildifier passes. - Windows-target Bazel analysis confirms both OpenSSL DLLs are inputs to the staging action. - Full Windows Rust execution is delegated to Windows CI. ### Review fixes - **No startup prewarming**: the executor remains stopped until a task is leased. Signing keys are synchronized during the first cold start and cached for later starts. - **Lease protection during cold start**: task heartbeats begin immediately after dequeue and stop only after terminal publication, covering process startup, readiness, and key synchronization. - **Start race**: dd-procmgrd rejects `Start` for every state covered by `ProcessState::is_alive()` (`Starting`, `Running`, and `Stopping`). Those states and a lost `Start` race are now adopted instead of failing the task spuriously. - **Windows graceful shutdown**: `par-control` listens for `CTRL_BREAK`, which is the event dd-procmgrd sends to Windows children, so shutdown drains work instead of waiting for the process-manager timeout and job-object kill. - **Bounded process-manager calls**: dispatch-path `Describe` and `Start` RPCs have deadlines, allowing a leased task to fail and publish an outcome instead of hanging without heartbeats. - **Windows logging and defaults**: restores the program-data-root log path, `ExitCode`, and the platform-correct `--config` default. - **Clean executor exits**: idle self-termination from #54670 remains non-fatal, so `restart: on-failure` does not immediately respawn the executor. - Tests cover stopped-at-start behavior, heartbeat timing through cold start and publication, adoption of `Starting`/`Running`/`Stopping`, tolerated start races, RPC deadlines, idle stop, drain behavior, and vanished process definitions. ### Stack PR 7 of 9. Based on #54592; followed by #54594.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54593",
          "createdAt": "2026-08-07T17:53:19Z",
          "updatedAt": "2026-08-13T15:50:56Z",
          "timestamp": "2026-08-13T15:50:56Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:ba3b9efd9d547bb7cd3d",
        "signalId": "github:DataDog/datadog-agent:pull_request:54157",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54157",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[WP] ICMPv4 packet flow classification",
          "text": "### What does this PR do? This PR adds proper IPv4 ICMP flow tracking so CWS can attribute outbound ICMP packets to the correct process in the TC classifier at snapshot, enabling cgroup-scoped network_filter actions (e.g. dropping ping traffic). Problem: The flow_pid map keys flows by (netns, source address, L4 identifier, protocol). For TCP/UDP, the L4 identifier is the source port. ICMP has no ports — only an echo identifier in the header — and security_sk_classify_flow runs too early for ICMP sockets: the flowi metadata is incomplete and the existing port-matching logic does not apply. Solution: Hook ip_finish_output, once the IPv4 packet (IP + ICMP headers) is built, and parse the sk_buff to extract: the source address (iph.saddr) the echo identifier (icmph.un.echo.id), stored in the existing port field of pid_route_t ICMP flow registration is skipped in security_sk_classify_flow and handled exclusively from this hook. On the TC egress path, resolve_pid_from_flow_pid is updated to look up ICMP flows using icmp.id instead of tcp_udp.sport. Refactor: Flow registration logic is extracted into register_flow_pid_classify_entry, shared by both hooks. Test: TestNetworkFilterICMPPingIsolation starts a long-running ping in a container, loads a cgroup-scoped network_filter rule (icmp and dst host 1.1.1.1), and verifies packet loss once the agent attaches the filter. ### Motivation Cgroup network isolation relies on resolving the emitting process (and its cgroup) from packets observed on the TC egress path. Without a correct flow_pid entry for ICMP, the classifier cannot attribute ping packets to the container process if the agent miss the create of the socket. This caused pings not to be dropped when the ping process started before the agent, even if an isolation was applied on this process / cgroup. TCP/UDP flows were already registered from security_sk_classify_flow, but that hook fires before the kernel has assembled the final ICMP with the address (chosen at runtime for ICMP) packet and does not expose a usable port for the port-matching checks. By moving registration to ip_finish_output and keying on the ICMP echo identifier, we align ICMP with the same flow_pid → PID → cgroup resolution path used for TCP/UDP.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54157",
          "createdAt": "2026-07-28T09:37:01Z",
          "updatedAt": "2026-08-13T15:50:25Z",
          "timestamp": "2026-08-13T15:50:25Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/agent-security",
            "qa/done",
            "medium review",
            "internal"
          ],
          "author": "theop-dd",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:173405d1a11d9f1125dd",
        "signalId": "github:DataDog/datadog-agent:pull_request:51861",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "metrics",
          "state"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:51861",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "packaging/aix: use rmssys only in unconfig, drop odmdelete",
          "text": "### What does this PR do? Remove the `odmdelete` calls from the AIX `unconfig` lifecycle script, keeping only `rmssys`. ### Motivation `rmssys` atomically removes a subsystem from both the ODM file and the live srcmstr daemon. Calling `odmdelete` before actually makes `rmssys` fail silently, and leave a stale entry in `srcmstr`. The `postinst` script already documents this: \"Always use rmssys, never odmdelete.\" ### Describe how you validated your changes Verified on the AIX 7.3 VM. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/51861",
          "createdAt": "2026-06-05T13:06:45Z",
          "updatedAt": "2026-08-13T15:48:46Z",
          "timestamp": "2026-08-13T15:48:46Z",
          "metrics": {
            "reactions": 2,
            "comments": 6
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "short review",
            "team/agent-runtimes",
            "team/agent-build",
            "internal"
          ],
          "author": "pgimalac",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:b90aa2dc3e7f00ec261b",
        "signalId": "github:DataDog/datadog-agent:pull_request:54592",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54592",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] add par-control OPMS client",
          "text": "### What does this PR do? Adds the authenticated OPMS client used by `par-control`: - Signs requests with runner JWT authentication. - Dequeues workflow tasks. - Publishes terminal task outcomes. - Sends task heartbeats. - Performs runner health checks. - Matches the existing Go wire contracts, proxy behavior, TLS settings, and retry pacing. The implementation and its HTTP/TLS contract tests are kept together in this layer. ### Motivation Separate the remote OPMS protocol from local executor communication and from the orchestration policy that composes them. ### Validation - 46 portable Rust tests pass locally. - Three native-tls tests require Linux/Windows and do not run successfully with the macOS Security Framework backend. ### Stack PR 6 of 9. Based on #54591; followed by #54593.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54592",
          "createdAt": "2026-08-07T17:51:46Z",
          "updatedAt": "2026-08-13T15:44:38Z",
          "timestamp": "2026-08-13T15:44:38Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:0884e8ea9ebe615e31e4",
        "signalId": "github:DataDog/datadog-agent:pull_request:54546",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "metrics"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54546",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[WINA-2940] Break Group Policy passes into timed CSE invocations",
          "text": "### What does this PR do? Gives the existing `computer_group_policy` / `user_group_policy` milestones a drill-down: the client-side extensions (CSEs) that ran inside each boot Group Policy pass, and the Group Policy objects that fed each one. New `custom.group_policy_details` block, a sibling of the untouched `boot_timeline` and `durations`. This is the real block from the validation boot, verbatim apart from abbreviated GUIDs: ```json \"group_policy_details\": { \"computer\": [ { \"cse_id\": \"{35378EAC-…}\", \"cse_name\": \"Registry\", \"offset_ms\": 8058, \"duration_ms\": 127, \"result\": \"success\", \"gpos\": [{ \"id\": \"{11BBEC75-…}\", \"name\": \"ZZ Probe C & D\" }, { \"id\": \"{29227867-…}\", \"name\": \"ZZ Probe Beta\" }, { \"id\": \"{9905CA71-…}\", \"name\": \"ZZ Probe Alpha\" }, { \"id\": \"{31B2F340-…}\", \"name\": \"Default Domain Policy\" }] } ], \"user\": [ { \"cse_id\": \"{35378EAC-…}\", \"cse_name\": \"Registry\", \"offset_ms\": 6210, \"duration_ms\": 53, \"result\": \"success\", \"gpos\": [{ \"id\": \"{11BBEC75-…}\", \"name\": \"ZZ Probe C & D\" }, { \"id\": \"{29227867-…}\", \"name\": \"ZZ Probe Beta\" }] } ] } ``` Two more fields exist and are `omitempty`, so neither appears above: `async` (false throughout this boot) and `gpos_omitted` (nothing was dropped). The block is omitted entirely when no invocation was measured end to end. **Shape.** Flat `computer` / `user` arrays, so the JSON *is* the tree the UI renders. GPOs are inlined per invocation rather than pooled behind a GUID join, so a consumer needs no join — and the set is self-pruning, since a GPO reaches the wire only when a surviving boot-pass invocation references it. `offset_ms` comes from `bootOffsetFunc`, extracted out of `buildTimelineMilestones` so an invocation and its parent milestone sit on one axis: the login-screen gap collapse means a raw boot-relative offset would render a user-pass CSE *outside* its own pass. One duration field, the measured 4016→terminal interval, which is the same kind of wall-clock measurement as the 4000→8000 pass duration it is a slice of. **Attribution.** Events 4002–4007 (network-state change, `gpupdate`, periodic refresh) are not collected — their invocations are not part of the boot pass, and counting them there lets the child durations sum past the parent. Scope comes from a pass-activity table pinned by the **pass start events only**, 4000 and 4001. Taking the activity from the same event that sets the milestone timestamp is what makes a populated scope array imply its parent: this block cannot describe timed slices of a pass `boot_timeline` does not report. Three guards sit on the table: the zero GUID is refused, because events outside any pass genuinely carry it — 16 of them on the validation boot; one activity may not pin two scopes, or its bucket is emitted under both; and an activity ID matching no boot pass is dropped, never charged to the most recent pass. An earlier revision also seeded the table from 8000/8001, to recover a pass whose start event was missing. **The trace that motivated that does not have the shape it was read as having, and the claim is retracted.** Re-read with `Get-WinEvent -Path`, the trace lacking 4001 also lacks 8001: its second activity is a **4004/8004** pair, machine *manual* processing. So there is nothing to recover, and 8000/8001 carry no `PolicyActivityId` in any case. **Only measured invocations are emitted.** An unmatched terminal, an unmatched start, and an invocation still open when the trace ends have no interval to place on the timeline; a record without one is a collection diagnostic rather than latency data. A duplicate open start keeps the later one, and a terminal event that precedes its start is refused and leaves the start open. **Bounds.** Four constants cap what one payload may carry, fixed rather than configurable: 64 invocations per scope, 32 distinct GPO references per invocation, 128 bytes of CSE name, 512 bytes of GPO name. `TestSubmitEvent_WorstCasePayloadSize` couples all four through **one** byte budget — it builds the largest payload the caps permit and asserts it stays under 3 MB uncompressed, so raising any single cap fails that one test. Currently 2,373,734 bytes against the ceiling, 626 KB of margin. They are mandatory rather than prudent, because oversize fails silently and unrecoverably. The `event-management` pipeline uses `useStreamStrategy: true`, and `streamStrategy` has no size logic and never splits — `batch_max_content_size` and `logs_config.max_message_size_bytes` are both inert on this path. Oversize therefore surfaces only as an intake **HTTP 413**, which increments `tlmDropped` and returns a non-retryable `errClient`; `SendEventPlatformEventBlocking` has already returned `nil` by then, so the component can never learn its event was discarded. The payload size distribution is unmeasured, but an undetectable failure mode justifies a deterministic bound at any frequency. `retainMostRelevant` cuts an over-long invocation list: non-success outcomes first, then the longest durations, tie-broken on CSE ID. It has to run **before** the caller's chronological sort — sort-then-truncate would keep the head of the pass and drop whatever ran late in it, which is the opposite of useful. GPO overflow is reported per invocation as `gpos_omitted`, and the collector's `seen` set is what keeps that count exact: a GUID repeated past the cap is not a fresh loss. `truncateProviderText` cuts on a UTF-8 boundary, since a 512-byte cut through a multi-byte character would emit invalid UTF-8. **GPO lists.** `ApplicableGPOList`'s runtime format is now confirmed against a real boot: a **rootless `<GPO ID=\"{GUID}\"><Name>…</Name></GPO>` sequence carrying ID and Name only**. So IDs come from the `ID` attributes and display names come free from 4016, **and 5312 is not collected at all** — one walk yields both. This closes the open validation earlier revisions flagged: on the boot capture every name 5312 supplied for an emitted invocation was already on that invocation's own 4016, and on the earlier capture its `GPOInfoList` is empty on both events. Re-running `analyzeETL` over the boot ETL with the 5312 arm removed produces an unchanged block, all four display names included. `name` is `omitempty`, so the wire schema is unaffected. What survives is the shared GUID→name lookup, which is no longer a merged inventory but the thing that lets an invocation whose list ended early borrow a name from one that parsed cleanly. The braced-GUID scan is kept as a fallback for a fragment the token walk cannot finish and for a delimited or prose value. **It is only safe on `ApplicableGPOList`**: 5312's `GPOInfoList` carries a fuller entry that embeds `<Extensions>[{CSE GUID}{…}]</Extensions>`, so scanning that fragment would report an extension's own GUID as an applicable GPO. Not collecting 5312 makes that **structural rather than an ordering discipline** — the scan can only ever be handed `ApplicableGPOList`, which has no `<Extensions>` at all. **The fragments are not well-formed XML, and this cost real data.** Windows builds them by concatenation and does **not** escape display names, so a GPO named `R&D Baseline` arrives carrying a bare `&`. The validation boot had exactly that, first in every one of its four lists. Under Go's default strict decoder `DecodeElement` fails on that entry and the walk abandons everything behind it — the payload emitted all four GPO references with **no display name at all**. Two further failure modes sat one position away: when the offending name is not first, the partial tier-1 result satisfies the `len(ids) > 0` short-circuit and the scan fallback never runs, so the tail of the list is **dropped outright**; and on any fragment that does carry `<Extensions>`, the fallback reports the extension GUID as a GPO. `decoder.Strict = false` fixes the ampersand, but **only narrows the mid-list class rather than closing it**, which review caught. Non-strict decoding forgives malformed entities and missing end tags — it does not relax tag syntax. So a display name whose `<` does not open a well-formed tag, or a mismatched end tag like `</Nam>`, still ends the walk partway, and the short-circuit still returns the prefix. The walk now reports whether it reached end of input (`errors.Is(err, io.EOF)` — a clean end *is* `io.EOF`) and the fallback runs on **any** incomplete walk, appending the IDs it could not reach. Two table rows cover both malformations mid-list; reverting the guard fails exactly those two and nothing else. **Two supporting changes in `pkg/util/winutil/etw`:** - Expose `EVENT_HEADER.ActivityId`. Windows runs more than one instance of policy processing concurrently, so pairing on the extension GUID alone would cross unrelated passes. The boot capture makes this concrete: the **same** Registry CSE GUID `{35378EAC-…}` runs in both the computer and the user pass, and only the activity ID separates them. The header is also the *only* correlator available for a pass stop event: 4000/4001 do carry `PolicyActivityId` as property [0], equal to the header value, but **8000/8001 do not carry it at all** — their template is `PolicyElaspedTimeInSeconds, ErrorCode, PrincipalSamName, IsMachine, IsConnectivityFailure`. - `EventProperties` returns the properties decoded before a failure alongside the error instead of discarding all of them. A 4016 carries seven properties including three long strings, and one bad decode previously zeroed every field on the event. Parsing still stops at the first failure and never skips ahead — the property cursor is shared, so everything after a failure is garbage rather than merely missing. This is a **contract change to a shipped function** (\"nil map on error\" → \"possibly-populated map on error\") that the new block does not strictly require — without it the reader falls through to the per-property path, which still yields `\"\"`. Both callers repo-wide were checked: `GetEventPropertyString` tests `err` before touching the map, and `eventPropertyReader` is the intended consumer. Worth stating plainly that `pkg/util/winutil/etw` contains no test files, so this and the `ActivityId` population ship with no coverage in their own package. The recovery helps 4016 and does nothing for the stop events, because the templates disagree on property order: `CSEExtensionId` is property **[0]** on 4016 but **[3]** on 5016/6016/7016. A partial decode therefore *degrades* a start, losing the async flag and the GPO list, and *annihilates* a stop, losing the identity so its start is left open and dropped at finalize. `GetPropertyByName` is not a fallback for it — that path reads raw bytes as UTF-16, turning a 16-byte `win:GUID` into eight junk runes. `TestPartialDecodeDegradesAStartButDropsAStop` locks both directions. **One cleanup, not a fix:** `submitEvent` read `total_boot_duration_ms` back out of the payload map and formatted an `interface{}` with `%d`. That always worked — the boxed value is an `int64` — so it is fragility rather than a bug, and the new condition is provably identical: the old gate, `durations` present and carrying the key, is exactly `haveBoot && haveLogon`, which is `complete`. Note it leaves `impl_darwin.go` on the old pattern, so the two platforms now express this one line differently. ### Motivation Group Policy was reported as two aggregate milestones, each a single start/end pair. When Group Policy is the slow phase of a boot, that tells an operator *that* GP was slow and nothing about *what* in GP was slow. **No installer or autologger change is required**, and the validation boot proves it rather than arguing it: that ETL was captured by a **stock, released Agent 7.82.0 autologger** with no modification, and it contains every event this PR consumes. The GroupPolicy mask is `0x4000000000000000`, the channel-wide Operational keyword, and the session runs at `EnableLevel=4`; ETW treats level as a ceiling, so 4016/5016 (Informational), 6016 (Warning) and 7016 (Error) are all admitted. The only MSI edit here is comment-only. The file cap is 256 MB sequential and this capture came in at 6.2 MB, so truncation is not a factor either. ### Describe how you validated your changes Two real captures, on top of the unit suite. **1. A real autologger boot ETL from a domain-joined host** (6.2 MB, 43,250 events, `EventsLost 0`, three probe GPOs linked at the domain root all feeding the Registry CSE, plus HKCU settings so user-scope CSEs run). Decoded four independent ways — two `tracerpt` passes, `Get-WinEvent -Path`, and the analyzer itself — with agreeing event histograms. **`analyzeETL` ran clean end to end on real boot data for the first time.** No error, all 23 `BootTimeline` fields set, 11 milestones, 12 `durations` keys, and `group_policy_details` populated in **both** scopes — the payload quoted at the top of this description. An independent recomputation of `bootOffsetFunc` straight from raw ETW timestamps reproduced the analyzer's output exactly: `computer_group_policy` 7308 ms / 913 ms, `user_group_policy` 5956 ms / 318 ms, machine CSE 8058 ms / 127 ms, user CSE 6210 ms / 53 ms, `total_boot_duration_ms` 28394. Two independent derivations agreeing is what establishes the offset extraction is faithful. Confirmed by that boot: - **Nesting holds on real data.** Machine CSE [8058, 8185] sits inside `computer_group_policy` [7308, 8221]; user CSE [6210, 6263] inside `user_group_policy` [5956, 6274] — both after a 35215 ms gap collapse. This is the property `TestCSEOffsetsShareTheBootTimelineAxis` locks. - **Activity-ID scoping works as designed.** Three distinct activity IDs: the computer pass carrying 4000/5312/4016/5016/8000 on one thread, the user pass carrying 4001/5312/4016/5016/8001 on another, and **the zero GUID on 16 service-lifecycle events outside any pass** (including both occurrences of 4117). No CSE event carried an activity matching no pass. Refusing the zero GUID is confirmed necessary a second time. - **All four pass boundaries present**, each pass on its own activity ID and its own thread, which is what start-only pinning needs. - **A real non-boot refresh pass is observed being excluded** — on the earlier trace, not this one. It carries a **4004/8004 pair triggered over RPC by a third-party service**, with event 5321 recording the attribution verbatim: `Group Policy refresh via RPC. Target=Machine ParentProcess=\"…\\services.exe\" RpcClient=\"…\\lenovo\\UDC\\Service\\UDClientService.exe\" Account=\"NT AUTHORITY\\SYSTEM\"`. Re-running the analyzer over it, the refresh pass is absent from the payload. So the 4002–4007 exclusion has observational backing and not only a synthetic test. - The measured 4016→terminal interval tracks the provider's own `CSEElaspedTimeInMilliSeconds` within one timer tick: 127 vs 140 and 53 vs 46 here, 62.4 vs 63 and 46.7 vs 47 elsewhere. `TimerResolution` on this trace is 15.625 ms, which accounts for the spread. **2. A `logman` + `gpupdate /force` capture** at the identical provider GUID, keyword and level, to settle the `ApplicableGPOList` format without waiting for a boot. This is what produced the format finding and the unescaped-ampersand finding above. It also observed `IsExtensionAsyncProcessing=true` in the wild (the Security CSE), which the boot capture does not contain. **3. An earlier Agent-captured ETL** (1.4 MB, 10,017 events, 32 Group Policy events) read alongside the `Microsoft-Windows-GroupPolicy` manifest via `ProviderMetadata`. This is the trace whose mixed `IsMachine` renderings made scope-from-event-ID look justified — and the manifest now explains why they differ rather than leaving it a quirk: **4000/4001, 4002–4007 and 8000–8007 each ship a version 0 and a version 1 template, and `IsMachine` is `win:Boolean` in v0 but `win:UInt32` in v1.** On the validation boot all four boundary events are v1 and it reads a perfectly consistent `1/0/1/0`. Deriving scope from the event ID is still right, but because the field is version-dependent, not because it is unreliable. Two further claims previously made about this trace are **retracted**: it does not carry 8001 without 4001, per Attribution above, and its computer pass did not fail — `ErrorCode` is `0` on both 8000 and 8004, and no property anywhere in the trace equals 1355. It does carry two 5312 events, both with an empty `GPOInfoList`. `group_policy_details` is correctly absent, but because the trace contains no 4016 at all. None of the ETLs are committed as fixtures: they carry machine names, a domain, and user SAM names. **Unit tests.** `grouppolicy_test.go` drives synthetic events through the real `processEvent` dispatch, feeding the mock the exact strings TDH produces for each declared out-type. Six guard the attribution rules specifically: `TestPassStopAloneNeverPins` proves a pass stop event cannot pin a scope by itself, `TestZeroActivityIDNeverPins` guards the zero-GUID sweep, `TestPassActivityIsNotSharedBetweenScopes` stops one activity being emitted under both, `TestCSEWithNoBootPassIsOmitted` proves an unmatched activity is dropped rather than charged to the most recent pass, `TestGPUpdateInvocationsAreExcluded` proves a `gpupdate` CSE stays out of the boot pass, and `TestCSEOffsetsShareTheBootTimelineAxis` locks an invocation inside its parent milestone with a login-screen gap present. `TestGPONamesSurviveUnescapedAmpersand` and two new table rows in `TestGPORefsFromList` cover the escaping fix, in both the first and mid-list positions — reverting `decoder.Strict = false` fails all four with the three distinct symptoms described above. `TestInvocationBackstopKeepsTheLeastHealthyAndTheSlowest` locks the retention order against the chronological sort. `TestBuildTimelineMilestones` passes **unmodified**, which is what proves `bootOffsetFunc` is a faithful extraction. `dda inv test --targets=./comp/logonduration/impl` — 149 passing, none failing, none skipped. `dda inv linter.go` clean on both `./comp/logonduration/impl` and `./pkg/util/winutil/etw`. Writing the tests caught a real bug independently of the captures: dropping the XML tier in favour of a pure braced-GUID scan silently harvested the CSE GUID out of a 5312-shaped entry's `<Extensions>` element and reported it as an applicable GPO. ### Additional Notes **`error_code` is removed, and the field set is now deliberate rather than incidental.** Earlier revisions carried the provider's status on each invocation. It is gone. The block reports what ran inside a pass and for how long; *why* an extension failed is a Group Policy health question, and it is the only annotation here a consumer can recover elsewhere — the code is in the host's own Group Policy Operational log, whereas `result` and `async` exist nowhere but this payload and both govern how `duration_ms` must be read. Removing it also retires a wire contract that existed solely to carry it: a hex string rather than a JSON number, parsed base 0 because the property is declared `win:HexInt32`, so that a status above `0x7FFFFFFF` does not round-trip as a negative signed integer. A fleet-level view of *which* status a slow pass failed with is worth having, but it is a different feature from a CSE→GPO latency breakdown and belongs in its own PR with its own release note. The two fields that stay are load-bearing, not decoration. `result` is nearly free — 5016/6016/7016 have to be accepted regardless, because a CSE that ends in warning or error still consumed wall-clock time inside the pass, and without its terminal event its start is never closed and the invocation is dropped at `finalize`. Given the dispatch already switches on the ID, the outcome is a byproduct; dropping the field while keeping the events would render a 45 s invocation that timed out identically to a 45 s invocation that did work. `async` redefines the primary number: when `IsExtensionAsyncProcessing` is set the terminal event marks worker-thread dispatch, so `duration_ms` is the cost of the dispatch and not of the extension's work. The stop events still carry `ErrorCode` and the synthetic ones in the tests still populate it — now with a non-zero E_PENDING, so every test that asserts on an emitted invocation also proves the field does not leak back into it. `TestCSEPairingOutcomes` gains meaning from that: a 5016 carrying a non-zero status still reports `success`, because the event ID is what is read. The release note is unchanged, having always described the block as offset, duration, and outcome. Also incidental: a merge of `main` left this package's tests not compiling, because `newPayloadTestComponent` was still passing the `compression` argument #54480 removed. Fixed here. **Four pre-existing bugs the captures exposed**, each left for its own PR because each moves an already-shipped number and deserves its own release note: 1. Pass endpoints are first-write-wins per event ID with no ActivityID pairing, so a start from one processing instance can pair with an end from another. The activity table makes the *children* consistent; the parent duration is still unpaired. 2. Both Group Policy milestones key off the **start** event alone, so a trace carrying only 8000 or only 8001 discards the endpoint it does have and drops the milestone and its `durations` entry silently. Latent rather than observed — the 8001-without-4001 shape that first motivated this is the one retracted above, and neither capture actually contains it. It is still a real hole, and it is the same first-write-wins-with-no-pairing weakness as bug 1. 3. `offset_ms` is non-monotonic for a milestone inside the collapsed login-screen gap, and this now reproduces on two traces with different numbers. On the earlier one `computer_group_policy` is at 19859 ms while the later `logon_duration` is at 9984 ms; on the boot trace `computer_group_policy` at 7308 ms lands after both `user_group_policy` at 5956 ms and `logon_duration` at 5687 ms. The machine pass falls inside the gap but is `Before(SessionLogon)`, so it escapes the subtraction while everything after logon is pulled left. 4. **New:** the boot trace carries **two** Winlogon 103/104 pairs, and first-write-wins takes the 11 ms pair over the 112 ms pair that follows it 5 s later. That choice sets the gap to 35215 ms instead of 30259 ms and is what amplifies bug 3 on this trace — with the second pair the inversion disappears. It also changes `login_ui_start.duration_ms` from 11 to 112, so picking the right pair is a shipped-number change in its own right. Separately, `boot_timeline` is emitted in the source order of a hardcoded candidate list and never sorted by `offset_ms`, so `logon_duration` precedes `user_group_policy` in the array while trailing it in time. That one is structural rather than trace-dependent. 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
          "url": "https://github.com/DataDog/datadog-agent/pull/54546",
          "createdAt": "2026-08-07T01:10:23Z",
          "updatedAt": "2026-08-13T15:40:27Z",
          "timestamp": "2026-08-13T15:40:27Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "qa/done",
            "long review",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "briantu",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:d5727ea4ed0e3accb7d3",
        "signalId": "github:DataDog/datadog-agent:pull_request:54805",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "metrics",
          "state"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54805",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[Backport 7.82.x]  [EBPF] Gate NVML workloadmeta collector on GPU monitoring",
          "text": "Backport d1520bca29c837ff691f91102b60a32a37c0112c from #54563. ___ ### What does this PR do? Gates the NVML workloadmeta collector on `gpu.enabled`. ### Motivation Avoid NVML collection when GPU monitoring is disabled. ### Describe how you validated your changes Added unit coverage for disabled startup. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54805",
          "createdAt": "2026-08-13T07:47:49Z",
          "updatedAt": "2026-08-13T15:39:30Z",
          "timestamp": "2026-08-13T15:39:30Z",
          "metrics": {
            "reactions": 2,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "team/ebpf-platform",
            "qa/done",
            "backport",
            "bot",
            "medium review",
            "team/agent-build",
            "internal",
            "team/gpu-monitoring-agent"
          ],
          "author": "dd-octo-sts[bot]",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:975de076702cca0db6ff",
        "signalId": "github:DataDog/datadog-agent:pull_request:54590",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54590",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] add par-control effective configuration",
          "text": "### What does this PR do? Adds the effective configuration and identity bootstrap layer for `par-control`: - Adds a Go helper subcommand that exports the Agent's resolved configuration. - Loads split-runner configuration from Rust. - Resolves local and Fleet-managed settings consistently. - Loads and persists runner identity. - Supports self-enrollment bootstrap. - Adds the required schema and setup wiring. Configuration production and consumption stay together in this PR so their contract can be reviewed as one behavior. ### Motivation Give the control process the same effective configuration as the Agent without duplicating configuration precedence or persisting a second plaintext configuration snapshot. ### Validation - Focused Go tests pass locally. - Portable Rust tests pass locally. - Relevant Go and Rust builds pass locally. ### Review fixes - **Process-manager socket**: falls back to dd-procmgrd's own `DD_PM_SOCKET_PATH` when `private_action_runner.procmgr_socket_path` is unset, before the platform default. Previously, relocating the daemon's socket also required setting a second, PAR-specific value. Resolution goes through the injected env lookup so it is testable without mutating process state, and an empty setting is treated as unset like the executor socket. - Carries the RPC deadlines, the `wait_for_failure` semantics, and the fake-daemon tests into the injected-socket `ProcmgrLifecycle` introduced here. - Same program-data-root log path, so the Windows log location no longer depends on where `--config` points. `platform.rs` also takes over the fleet-policies-dir registry lookup that was inline here. ### Stack PR 4 of 9. Based on #54589; followed by #54591.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54590",
          "createdAt": "2026-08-07T17:47:32Z",
          "updatedAt": "2026-08-13T15:38:55Z",
          "timestamp": "2026-08-13T15:38:55Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "team/action-platform",
            "internal",
            "team/fleet-automation"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:0d750453c1844a416f54",
        "signalId": "github:DataDog/datadog-agent:pull_request:54377",
        "event": "discovered",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54377",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[MVP] feat(instrumentation): Report runtime check failures in DDI status",
          "text": "### What does this PR do? This draft MVP surfaces runtime integration-check failures in the originating `DatadogInstrumentation` status instead of maintaining integration-specific validation schemas in admission. - Carries the originating DDI namespace, name, UID, generation, and check index through workload-targeted check configurations. - Reports check configuration and run-state transitions from the node Agent to the Cluster Agent. - Routes reports to the leader Cluster Agent and only allows the leader to write CR status. - Updates the `ChecksReady` condition with `AwaitingCheckStatus`, `CheckConfigurationFailed`, `CheckRunFailed`, or `Running`. - Sends node Agent status POSTs only when the observed state or error changes and skips identical CR status writes. - Scrubs and truncates reported errors before transmission. ### Motivation `DatadogInstrumentation` users can currently submit integration instance fields that pass structural admission validation but fail only after the check reaches the node Agent. Maintaining integration schemas in the Agent duplicates `integrations-core` models and would still miss custom and runtime validation. This MVP uses the regular check loading and execution lifecycle as the source of truth, then makes its failure visible on the CR that produced the configuration. MVP boundaries: - Workload-targeted DDI checks only; Service-targeted and Cluster Checks remain follow-up work. - Status is aggregated into the existing `ChecksReady` condition rather than new per-instance status fields. - Cluster Agent aggregation is currently in memory. - This does not test connectivity or resolve Autodiscovery templates at admission time. ### Describe how you validated your changes - `dda inv cluster-agent.build --skip-assets --no-force-policies-clone` - `dda inv agent.build --build-exclude=systemd,python --skip-assets --exclude-rtloader` - Repository pre-push hooks, including Go tests and linting. - Manual Injector Dev QA using the local Datadog Operator chart: - An invalid Redis `port: \"not-a-port\"` was admitted and transitioned to `ChecksReady=False` with reason `CheckConfigurationFailed`. - Replacing it with the valid `%%port%%` template transitioned the CR to `ChecksReady=True` with reason `Running`. ### Demo <!-- Add the demo video or recording link here. --> _TODO: Add demo video._ ### Additional Notes This is intentionally a draft MVP. Service-targeted checks, durable aggregation across Cluster Agent failover, finer-grained CRD status fields, tests, and a release note can be completed before marking it ready for review.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54377",
          "createdAt": "2026-08-03T15:57:42Z",
          "updatedAt": "2026-08-13T15:37:17Z",
          "timestamp": "2026-08-13T15:37:17Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [
            "qa/done",
            "team/container-platform",
            "long review",
            "team/container-integrations",
            "team/agent-runtimes",
            "team/agent-build",
            "team/kubernetes-experiences",
            "internal"
          ],
          "author": "Mathew-Estafanous",
          "state": "closed",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:5a84184a59527f16c87d",
        "signalId": "github:DataDog/datadog-agent:pull_request:54594",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54594",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] wire split runner ownership",
          "text": "### What does this PR do? Teaches the existing Go runner and Fx component to stand down when split mode is enabled on supported Linux and Windows host deployments, while retaining the executor subcommand used by `par-control`. Container deployments do not yet launch the replacement topology. Official Agent containers are detected through `configenv.IsContainerized()` (`DOCKER_DD_AGENT`), so a requested split deployment logs a warning and safely continues with the monolithic runner instead of black-holing PAR. Cluster Agent continues to use its existing in-process monolithic path. The resulting ownership invariant is explicit: exactly one process polls OPMS, and the monolith exits only when its replacement topology is available. ### Motivation Keep runner ownership and activation behavior separate from package and installer mechanics so reviewers can focus on preventing both duplicate polling and unsupported deployments standing down their only runner. ### Validation - `bazel test //comp/privateactionrunner/impl:impl_test` passes locally. - Focused coverage includes Linux and Windows hosts, Linux and Windows containers, and an unsupported host platform. - Private Action Runner build passes locally. ### Review fixes - Documented `idle_timeout_seconds`, which now drives two mechanisms: par-control stops an idle executor after this long, and the executor exits by itself after a longer multiple, which is what reclaims it when par-control is no longer running. - Documented that `procmgr_socket_path` falls back to the process manager's own `DD_PM_SOCKET_PATH` when unset. ### Stack PR 8 of 9. Based on #54593; followed by #54529.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54594",
          "createdAt": "2026-08-07T18:09:51Z",
          "updatedAt": "2026-08-13T15:36:41Z",
          "timestamp": "2026-08-13T15:36:41Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "medium review",
            "team/agent-build",
            "team/action-platform",
            "internal",
            "team/fleet-automation"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:b29c6e13a6dd2769d686",
        "signalId": "github:DataDog/datadog-agent:pull_request:54818",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54818",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Fail bazel build on Windows if vault isn't found",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Builds are notoriously slow on Windows so it was requested by @DataDog/windows-products to fail the agent build in case we can't utilize the cache. One of the main reasons for that is absence of `vault` tool that is used to acquire an access token for our `buildbarn` cluster that serves as a remote cache backend. With this change we: - immediately fail the build if `vault` hasn't been found. Users can still opt-out and build without cache. - print a hint explaining how to properly install `vault`",
          "url": "https://github.com/DataDog/datadog-agent/pull/54818",
          "createdAt": "2026-08-13T10:26:41Z",
          "updatedAt": "2026-08-13T15:35:06Z",
          "timestamp": "2026-08-13T15:35:06Z",
          "metrics": {
            "reactions": 2,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "team/agent-build",
            "internal"
          ],
          "author": "JSGette",
          "state": "open",
          "assignees": [
            "JSGette"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:7ff8ffcc94f088f580bc",
        "signalId": "github:DataDog/datadog-agent:pull_request:54645",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54645",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix: avoid data race in grpclog.SetLogger on otelcol collector start",
          "text": "### What does this PR do? Sets `SkipSettingGRPCLogger: true` on the `otelcol.CollectorSettings` for the otel-agent and host-profiler collectors, so `otelcol.(*Collector).Run` no longer calls the non-mutex-protected `grpclog.SetLogger` while other gRPC clients (e.g. remote-config/remote-tagger) are active in the same process. ### Motivation Fix a race, found via a race-detector-enabled build in staging. ### Describe how you validated your changes Ran `./comp/otelcol/...` and `./comp/host-profiler/collector/...` tests (including with `--race`) and built `otel-agent`/`host-profiler`, all passing; a real regression test isn't feasible since the race needs real concurrent gRPC/otelcol startup. ### Additional Notes No log routing is lost: `comp/core/tagger/impl-remote` (pulled in by both otel-agent and host-profiler) already sets a Datadog-logger-backed `grpclog` logger in its package `init()`, which runs once before `main()` and is therefore race-free. Skipping otelcol's later, racy `SetLogger` call just stops it from unsafely clobbering that existing assignment — grpc's internal logs keep flowing to our structured logger exactly as before. Similar to https://github.com/DataDog/datadog-agent/pull/15321 for the OTLP endpoint.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54645",
          "createdAt": "2026-08-10T13:59:56Z",
          "updatedAt": "2026-08-13T15:30:17Z",
          "timestamp": "2026-08-13T15:30:17Z",
          "metrics": {
            "reactions": 1,
            "comments": 8
          },
          "labels": [
            "changelog/no-changelog",
            "team/opentelemetry",
            "qa/done",
            "medium review",
            "team/profiling-full-host",
            "internal"
          ],
          "author": "pgimalac",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:8adbe8349109cc0f7c64",
        "signalId": "github:DataDog/datadog-agent:pull_request:54815",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54815",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[DSEC] Move dd-sds dependency to shared workspace",
          "text": "### What does this PR do? Moves the `dd-sds` (`dd-sensitive-data-scanner`) dependency from the `datasecurity` check crate into the shared `[workspace.dependencies]` in the root `Cargo.toml`. The crate now references it via `dd_sds.workspace = true`. ### Motivation Centralize the pinned version and feature set so future check crates share a single source of truth instead of duplicating the spec. ### Tests Use docker image registry.ddbuild.io/ci/datadog-agent/agent:v130685756-40c89d95-7-amd64 generated in the CI and confirmed that data security check is correctly running. ```bash dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/aggregator/aggregator.go:182 in LogMsg) | datasecurity: sub task succeeded (1 match(es)) dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/aggregator/aggregator.go:182 in LogMsg) | datasecurity: running sub task (sub_task_id=455ECD24-5C11-45AA-801B-5C2C43C8533C, platform=postgres) dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (comp/core/agenttelemetry/impl/agenttelemetry.go:665 in run) | Starting agent telemetry run dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/aggregator/aggregator.go:182 in LogMsg) | datasecurity: sub task succeeded (1 match(es)) dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/aggregator/aggregator.go:182 in LogMsg) | datasecurity: check completed dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/worker/check_logger.go:59 in CheckFinished) | check:datasecurity | Done running check dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/worker/check_logger.go:65 in CheckFinished) | check:datasecurity | Check's one time execution has finished ```",
          "url": "https://github.com/DataDog/datadog-agent/pull/54815",
          "createdAt": "2026-08-13T10:12:22Z",
          "updatedAt": "2026-08-13T15:29:29Z",
          "timestamp": "2026-08-13T15:29:29Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "short review",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "aimenebelfodil",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:18f5a1e1a62a001d2919",
        "signalId": "github:DataDog/datadog-agent:pull_request:54823",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54823",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix(aix): discover Python checks via integrations-core AIX manifest tag",
          "text": "### What does this PR do? Replaces the hardcoded AIX Python check list with dynamic discovery of every integrations-core check tagged `Supported OS::AIX`. ### Motivation Keep AIX in sync with integrations-core instead of drifting from a hand-maintained list. ### Describe how you validated your changes Ran the updated stage on an AIX 7.3 build host: it installed all currently AIX-tagged checks with no errors. ### Additional Notes `ibm_spectrum_lsf` is dropped — it was hardcoded before but never actually tagged for AIX upstream.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54823",
          "createdAt": "2026-08-13T11:32:13Z",
          "updatedAt": "2026-08-13T15:28:49Z",
          "timestamp": "2026-08-13T15:28:49Z",
          "metrics": {
            "reactions": 2,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "short review",
            "team/agent-build",
            "internal"
          ],
          "author": "pgimalac",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:fa5c7ae00ae11c6b73aa",
        "signalId": "github:DataDog/datadog-agent:pull_request:54839",
        "event": "discovered",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54839",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Remove buildschema legacy command",
          "text": "### What does this PR do? Now that the schema is the source of truth we no longer need that command",
          "url": "https://github.com/DataDog/datadog-agent/pull/54839",
          "createdAt": "2026-08-13T15:20:20Z",
          "updatedAt": "2026-08-13T15:28:41Z",
          "timestamp": "2026-08-13T15:28:41Z",
          "metrics": {
            "reactions": 2,
            "comments": 0
          },
          "labels": [
            "component/system-probe",
            "long review",
            "team/agent-runtimes",
            "team/agent-build",
            "internal",
            "team/fleet-remediation",
            "team/fleet-automation"
          ],
          "author": "hush-hush",
          "state": "closed",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:644ecc10268597c275c2",
        "signalId": "github:DataDog/datadog-agent:pull_request:54830",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "metrics"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54830",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Deflake `TestKeepTryingLockingIfPermissionDenied` with `synctest`",
          "text": "### What does this PR do? Wrap `TestKeepTryingLockingIfPermissionDenied`, `TestContextCancellation` and `TestHandleMultipleConcurrentWrites` in `synctest` \"bubbles\" by extracting their body into `sync<same name>` functions while dropping `t.Parallel()` (disallowed inside a bubble). Drop remaining `t.Parallel()` from the file's other 2 tests too (Bazel schedules this whole test binary as one action regardless of it). Also switch every `context.Background()` in the file to `t.Context()` for good measure (test-bound, canceled right before running Cleanup functions). ### Motivation `TestKeepTryingLockingIfPermissionDenied` races a 500ms retry loop against its own 2s context timeout using real time, so a scheduling stall near either boundary can flip a would-be success into a failure. It failed exactly that way in a local `bazel test` run on Linux: ``` --- FAIL: TestKeepTryingLockingIfPermissionDenied (3.00s) concurrent_write_test.go:212: Error Trace: pkg/util/filesystem/concurrent_write_test.go:212 Error: Received unexpected error: unable to read the artifact or acquire the lock in the given time open /tmp/TestKeepTryingLockingIfPermissionDenied252193597/001/test_artifact.lock: permission denied Test: TestKeepTryingLockingIfPermissionDenied concurrent_write_test.go:216: Error Trace: pkg/util/filesystem/concurrent_write_test.go:216 Error: Expected error with \"file does not exist\" in chain but got nil. Test: TestKeepTryingLockingIfPermissionDenied Messages: lock file should not exist after successful creation and concurrent reads ``` The flakiness may manifest itself in a slightly different way, like for instance in [a CI job](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1928209794#L476) on Windows where 2 `t.Parallel()` siblings in the same batch also ran multiple real seconds longer than their own logic requires, showing the whole binary stalled right when the retry loop needed to recheck the lock: ``` === NAME TestKeepTryingLockingIfPermissionDenied concurrent_write_test.go:212: Error Trace: pkg/util/filesystem/concurrent_write_test.go:212 Error: Received unexpected error: unable to read the artifact or acquire the lock in the given time Test: TestKeepTryingLockingIfPermissionDenied concurrent_write_test.go:216: Error Trace: pkg/util/filesystem/concurrent_write_test.go:216 Error: Expected error with \"file does not exist\" in chain but got nil. Test: TestKeepTryingLockingIfPermissionDenied Messages: lock file should not exist after successful creation and concurrent reads --- FAIL: TestKeepTryingLockingIfPermissionDenied (2.11s) ``` `TestContextCancellation` and `TestHandleMultipleConcurrentWrites` don't share that specific failure mode, but they do pay their timers' full real duration on every run regardless of load. ### Describe how you validated your changes Isolated timing before/after: - `TestKeepTryingLockingIfPermissionDenied`: 1.05s to 0.02s, - `TestContextCancellation`: 0.10s to 0.00s, - `TestHandleMultipleConcurrentWrites`: 0.50s to 0.05s. All tests pass 30/30 under `--config=gorace`, and the package passes 60/60 repeated runs under heavy artificial CPU oversubscription. ### Additional Notes Dropping `t.Parallel()` doesn't cost anything net: - ~1.65s before this change, - ~0.07s after. This is because virtualizing sleeps removes far more real time than serializing 5 tests loses.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54830",
          "createdAt": "2026-08-13T12:00:51Z",
          "updatedAt": "2026-08-13T15:28:26Z",
          "timestamp": "2026-08-13T15:28:26Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "team/agent-runtimes",
            "internal"
          ],
          "author": "rdesgroppes",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:e608469620be6dab78dd",
        "signalId": "github:DataDog/datadog-agent:pull_request:54828",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54828",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[EBPF] gpu: add NVLink capability tag",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds `gpu_nvlink_capable` and `gpu_nvlink_version` tags to GPU metrics. ### Motivation Knowing whether a GPU is NVlink-capable and the version of the NVlink system or not is useful to ensure the presence of certain metrics and to compare GPU performance. Another PR will also use part of this code to allow segmenting telemetry based on NVLink capability. ### Describe how you validated your changes Unit tests, manually validated in nvlink-enabled instance. ### Additional Notes Both tags might be slightly redundant but having two doesn't cost extra cardinality (gpu_uuid is already there, with one value per GPU) and it allows separating \"nvlink GPUs/non nvlink GPUs\" and between specific versions.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54828",
          "createdAt": "2026-08-13T11:52:04Z",
          "updatedAt": "2026-08-13T15:25:15Z",
          "timestamp": "2026-08-13T15:25:15Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "team/ebpf-platform",
            "qa/done",
            "team/container-platform",
            "long review",
            "team/container-integrations",
            "internal",
            "team/gpu-monitoring-agent"
          ],
          "author": "gjulianm",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:1809d9fe9b1a70f6512f",
        "signalId": "github:DataDog/datadog-agent:pull_request:54833",
        "event": "discovered",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54833",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "SMP experiment selection and codeowners v2",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Classifies SMP experiments into three modes: always: as the name implies, they always run, these are the quality gates codeowners: these experiments x, owned by team y, are automatically triggered if the the PR touches a file owned by y optional: fully manual, label triggered set of experiments used for specific features ### Motivation ### Describe how you validated your changes ### Additional Notes No need for review yet, this is a POC that will be split",
          "url": "https://github.com/DataDog/datadog-agent/pull/54833",
          "createdAt": "2026-08-13T13:59:48Z",
          "updatedAt": "2026-08-13T15:21:58Z",
          "timestamp": "2026-08-13T15:21:58Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "team/agent-security",
            "long review",
            "team/agent-log-pipelines",
            "team/agent-devx",
            "team/action-platform",
            "internal",
            "smp/logs/syslog"
          ],
          "author": "cmetz100",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:39604ff27c817928343c",
        "signalId": "github:DataDog/datadog-agent:pull_request:54816",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "state"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54816",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[Backport 7.83.x]  [EBPF] gpu: Skip unsupported vGPU max-clock queries",
          "text": "Backport e5a19fa15faff217145de62c45995fd1f2451ee1 from #54729. ___ <!-- dd-meta {\"pullId\":\"00000000-0000-0000-0000-000000000000\",\"source\":\"chat\",\"resourceId\":\"b6950850-80dc-4801-bc2f-895d5b466cca\",\"workflowId\":\"c63cfe10-11dd-4bbc-800e-23188cad9c50\",\"codeChangeId\":\"c63cfe10-11dd-4bbc-800e-23188cad9c50\",\"sourceType\":\"bits_ai_sre\"} --> ### What does this PR do? Bits AI SRE Investigation • [View in Bits AI SRE Investigation](https://app.datadoghq.com/bits-ai/investigations/54d64295-b38b-44f1-85fa-fb1948786cba) - Detect vGPU devices in the NVIDIA stateless max-clock handlers. - Cache each device's NVML virtualization mode in `safenvml.DeviceInfo` during device initialization, so max-clock collection does not query NVML repeatedly. - Return the repository's typed unsupported-API error so all four max-clock handlers are filtered during collector initialization. - Log an error when the virtualization-mode lookup fails during device initialization. - Add regression coverage that makes vGPU max-clock calls return `ERROR_UNKNOWN`, verifies the cached mode, and confirms max-clock calls are never invoked or reported as collection errors. ### Motivation NVIDIA vGPU devices such as the A10-24Q configuration in the zekrom cluster do not support NVML `GetMaxClockInfo`. The API returns `Unknown Error` rather than `ERROR_NOT_SUPPORTED`, so the stateless collector previously retried the calls on every collection cycle and generated recurring collection-error noise. This fix suppresses those unsupported calls while preserving max-clock metrics for physical GPUs, caches the virtualization capability query used to make that decision, and reports failures to determine the mode. ### Describe how you validated your changes - Formatted the modified Go file with `gofmt` and ran `git diff --check`. - Verified the vGPU regression test observes one virtualization-mode query during device initialization and zero max-clock queries. - The targeted Bazel test was previously attempted but could not start because the workspace could not download the required Bazel version. - The prescribed `dda` executable was unavailable in the workspace. ### Additional Notes The change is limited to the NVIDIA stateless collector, safenvml device metadata and logging, and regression coverage. --- PR by Bits - [View session in Datadog](https://app.datadoghq.com/code/b6950850-80dc-4801-bc2f-895d5b466cca) Comment @datadog to request changes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54816",
          "createdAt": "2026-08-13T10:18:43Z",
          "updatedAt": "2026-08-13T15:20:14Z",
          "timestamp": "2026-08-13T15:20:14Z",
          "metrics": {
            "reactions": 2,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "team/ebpf-platform",
            "qa/done",
            "backport",
            "bot",
            "short review",
            "Bits AI",
            "internal",
            "team/gpu-monitoring-agent"
          ],
          "author": "dd-octo-sts[bot]",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:ec3e6ef92c8720f96975",
        "signalId": "github:DataDog/datadog-agent:pull_request:54806",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "state"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54806",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[Backport 7.83.x]  [EBPF] Gate NVML workloadmeta collector on GPU monitoring",
          "text": "Backport d1520bca29c837ff691f91102b60a32a37c0112c from #54563. ___ ### What does this PR do? Gates the NVML workloadmeta collector on `gpu.enabled`. ### Motivation Avoid NVML collection when GPU monitoring is disabled. ### Describe how you validated your changes Added unit coverage for disabled startup. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54806",
          "createdAt": "2026-08-13T07:47:59Z",
          "updatedAt": "2026-08-13T15:20:09Z",
          "timestamp": "2026-08-13T15:20:09Z",
          "metrics": {
            "reactions": 2,
            "comments": 0
          },
          "labels": [
            "changelog/no-changelog",
            "team/ebpf-platform",
            "qa/done",
            "backport",
            "bot",
            "medium review",
            "team/agent-build",
            "internal",
            "team/gpu-monitoring-agent"
          ],
          "author": "dd-octo-sts[bot]",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:de7878608374e3c33afb",
        "signalId": "github:DataDog/datadog-agent:pull_request:54761",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "state"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54761",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[Backport 7.83.x]  feat(wls): add K8S target through Remote Config",
          "text": "Backport 34e4e15f4654a23d43208c68be99fb2dd67ad4e9 from #54476. ___ feat(autoinstrumentation): wire remote-config SSI policies Subscribe the Cluster Agent auto-instrumentation webhook to the APM_POLICIES remote-config product and layer the delivered SSI policies on top of the configuration baseline at runtime. - TargetMutator now holds a base policy set plus an atomically swappable active set, so remote policies can be hot-reloaded without locking. - Remote policies take precedence over configuration targets (first-match-wins) and support explicit injection denies. - rc_policies.go parses the dd-wls document via dd-policy-engine and applies or clears policies on each remote-config update. This also add a SubscribeWithInitialConfig in RC Client to avoid a potential datarace between registration, initial config and first update if done without a mutex.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54761",
          "createdAt": "2026-08-12T08:04:00Z",
          "updatedAt": "2026-08-13T15:17:03Z",
          "timestamp": "2026-08-13T15:17:03Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "team/remote-config",
            "qa/done",
            "backport",
            "bot",
            "team/container-platform",
            "long review",
            "team/injection-platform",
            "team/agent-build",
            "internal"
          ],
          "author": "dd-octo-sts[bot]",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:2c6cbcf997bcbacb28ee",
        "signalId": "github:DataDog/datadog-agent:pull_request:54529",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54529",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] package and activate par-control",
          "text": "### What does this PR do? Packages and activates `par-control` on Linux and Windows: - Adds Agent package and installer wiring. - Installs process-manager definitions for `par-control` and the executor. - Adds Windows executable resources and MSI integration. - Preserves a standard service `PATH` for Unix process-manager children. - Adds Linux and Windows split-runner lifecycle E2E suites and CI jobs. Runner ownership is handled by the preceding layer. Split activation is intentionally limited to supported host deployments; Docker and Kubernetes containers continue running monolithically until their three-process topology is implemented. This PR contains only host packaging, activation, and end-to-end coverage. ### Motivation Ship the split runner consistently across supported installation paths and verify its process lifecycle on both Linux and Windows. ### Validation - Installer package tests pass locally. - Buildifier passes for the affected Bazel definitions. - Linux and Windows split-runner E2E execution is delegated to CI. ### Stack PR 9 of 9. Based on #54594.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54529",
          "createdAt": "2026-08-06T16:54:57Z",
          "updatedAt": "2026-08-13T15:15:47Z",
          "timestamp": "2026-08-13T15:15:47Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/container-integrations",
            "team/agent-runtimes",
            "team/agent-devx",
            "team/agent-build",
            "team/windows-products",
            "team/action-platform",
            "internal",
            "team/fleet-automation"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:026fc3167b78efefce4a",
        "signalId": "github:DataDog/datadog-agent:pull_request:54831",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "metrics",
          "labels"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54831",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "test(e2e): add IBM MQ integration lab",
          "text": "### What does this PR do? Adds a deploy=true E2E-framework lab for the `ibm_mq` integration under `test/e2e-framework/scenarios/aws/integrations/ibm_mq`. The scenario self-provisions **IBM MQ Advanced for Developers 9.3** with a configurable number of queue managers and queues on a single amd64 RHEL 8 EC2 host, co-located with the Datadog Agent. A systemd-driven put/get load generator keeps queue depth and enqueue/dequeue metric families non-zero so the `ibm_mq` check has realistic work to do. It exposes knobs for: - queue-manager count and queues per manager - collection interval - queue selection strategy (auto-discovery / regex / explicit) - `collect_reset_queue_metrics` - metric exclusion patterns - integration and internal profiling Wiring: registered in the integrations `registry.go` + `BUILD.bazel`, and in the invoke task collection, giving the usual task surface: ``` dda inv aws.integrations.ibm-mq.{create,status,check,exec,ssh,destroy,reload-check} ``` ### Motivation Provide a reproducible, self-contained environment to investigate `ibm_mq` check CPU cost as queue-manager and queue counts scale — the check can become expensive with large queue counts and auto-discovery, and this lab makes that behavior easy to reproduce and profile in isolation. ### Describe how you validated your changes - `gofmt` clean on `registry.go` and all `ibm_mq/*.go`. - `go build ./scenarios/aws/integrations/...` in the `test/e2e-framework` module succeeds. - `dda inv aws.integrations -l` lists all `ibm-mq.*` tasks. - pre-commit hooks (shellcheck, go-fmt, copyright, python-linter, …) pass. ### Additional Notes Follows the existing integration-lab pattern (kafka, lustre, etc.). The scenario provisions billable EC2; remember to `dda inv aws.integrations.ibm-mq.destroy` when finished.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54831",
          "createdAt": "2026-08-13T13:26:11Z",
          "updatedAt": "2026-08-13T15:14:58Z",
          "timestamp": "2026-08-13T15:14:58Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "long review",
            "team/agent-integrations",
            "team/agent-build",
            "internal"
          ],
          "author": "dkirov-dd",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:ed992e5d51c833b0e5b8",
        "signalId": "github:DataDog/datadog-agent:pull_request:52587",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:52587",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "add eviction configs",
          "text": "### What does this PR do? Pick up NCM eviction configurations from the datadog.yaml. Use these values in the eviction function. Call the eviction function after we write to the db to ensure that we do not exceed memory constraints. Evictions are tracked under a new Datadog internal metric: `datadog.ncm.store.configs_evicted` ### Motivation ### Describe how you validated your changes ### Additional Notes ### Local Validation That datadog.yaml is read correctly set `dev/dist/datadog.yaml`: ``` log_level: debug api_key: *** dd_url: 'https://dd.datad0g.com/' hostname: \"sophie-local\" process_config: process_collection: enabled: true network_devices: config_management: rollback: enabled: true store: min_configs_per_device: 2 max_configs_per_device: 24 max_raw_config_store_bytes: 2000000000 ``` run commands: ``` dda inv agent.build --build-exclude=systemd ./bin/agent/agent run -c ./bin/agent/dist/datadog.yaml ``` View debug logs: <img width=\"1439\" height=\"61\" alt=\"Screenshot 2026-06-23 at 11 59 38 AM\" src=\"https://github.com/user-attachments/assets/c2f526a1-76e4-407e-9569-be1adc573112\" /> ### CML eviction e2e test Confirmed eviction order with simulation on CML - set low number of bytes for store config - change configuration of network device, expecting removal of configurations in alignment with eviction policy - check evicted uuids in logs, confirm that inventory_reported_at does not continue to update for evicted configs in orgstore ### QA flow in CML 1) Configure datadog.yaml file inside of CML yaml file for test case, import lab to CML 2) Make needed configuration changes for test case 3) Validate Boltdb state with the following steps: ssh into vm running agent in cml, display device_config.db in cml as base 64: `sudo base64 /opt/datadog-agent/run/ncm_config.db` copy and paste the db output into a .txt file in local computer convert to a bin file: `base64 -d ~/Documents/cml_boltdb.txt > ~/Documents/cml_boltdb.bin` explore file using ncm show: ``` cd ~/go/src/github.com/DataDog/ndm-tools/ncmshow ./ncmshow ~Documents/cml_boltdb.bin ``` ### Manual test cases 1) Set configuration to: min_configs_per_device: 1, max_configs_per_device: 24, max_raw_config_store_bytes: 8 Get BoltDB state: <img width=\"849\" height=\"88\" alt=\"Screenshot 2026-08-05 at 9 51 16 AM\" src=\"https://github.com/user-attachments/assets/68b152bf-a4d2-4208-9651-84d014c6177d\" /> Change hostname Get BoltDB state: <img width=\"850\" height=\"92\" alt=\"Screenshot 2026-08-05 at 9 51 23 AM\" src=\"https://github.com/user-attachments/assets/bbffc9bb-ca2f-46b1-8c12-9996c39ae3ca\" /> (Should see 2 configs per device, even though min configs is set to 1 it should get overridden to 2. Min configs should override the config store requirement - will see that even after eviction not within this setting.) - note here, old running config was evicted so that the modified one could be stored <img width=\"969\" height=\"531\" alt=\"Screenshot 2026-08-05 at 10 12 01 AM\" src=\"https://github.com/user-attachments/assets/72e3942e-8cf5-43eb-9b65-21e1de3a3855\" /> 2) Set configuration to: min_configs_per_device: 1, max_configs_per_device: 3, max_raw_config_store_bytes: 1000000 Change hostname Change hostname <img width=\"561\" height=\"605\" alt=\"Screenshot 2026-08-05 at 12 32 52 PM\" src=\"https://github.com/user-attachments/assets/96d92227-ed84-4dcf-857b-8ad2d94adddb\" /> Get BoltDB state: <img width=\"853\" height=\"138\" alt=\"Screenshot 2026-08-05 at 12 32 43 PM\" src=\"https://github.com/user-attachments/assets/24adf9c7-a637-443c-80c3-ea50b14a23ad\" /> BoltDB only has 3 max configs for evictionCML2:10:10:1:2 even though there is enough space in the (db only 66000 bytes) because of the upper max_raw setting.",
          "url": "https://github.com/DataDog/datadog-agent/pull/52587",
          "createdAt": "2026-06-22T16:24:53Z",
          "updatedAt": "2026-08-13T15:11:56Z",
          "timestamp": "2026-08-13T15:11:56Z",
          "metrics": {
            "reactions": 0,
            "comments": 5
          },
          "labels": [
            "qa/done",
            "long review",
            "team/ndm-integrations",
            "team/agent-configuration",
            "team/agent-devx",
            "team/agent-build",
            "internal",
            "team/fleet-automation"
          ],
          "author": "Sophie-Ruetschi",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:b5b6fcd12662c6c2d1e4",
        "signalId": "github:DataDog/datadog-agent:pull_request:54781",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54781",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP][e2e][incident-59050] restore fake runner keys injection for PAR e2e test",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? \"revert\" of https://github.com/DataDog/datadog-agent/pull/54709 Try to reintroduce the fake intake usage for RC keys instead of `DD_INTERNAL_PAR_SKIP_TASK_VERIFICATION` The extra latency (which is a separate problem to solve with RC's help) seems to only appear if the PAR starts AFTER the core agent. By restarting the core agent we ### Motivation Trying to get rid of DD_INTERNAL_PAR_SKIP_TASK_VERIFICATION ### Describe how you validated your changes CI Ran, need to see if it does not become [flaky again](https://app.datadoghq.com/ci/ci-cd/explorer?query=ci_level%3Ajob%20%40ci.pipeline.name%3ADataDog%2Fdatadog-agent%20%40git.branch%3Amain%20%40ci.job.name%3A%22new-e2e-privateactionrunner%22%20%40ci.status%3Aerror&agg_m=%40ci.job.name&agg_m_source=base&agg_t=cardinality&analyticsOptions=%5B%22line%22%2C%22dog_classic%22%2Cnull%2Cnull%2C%22value%22%5D&ci_cd_explorer_tab=pipelines&cipipeline_explorer_sort=time%2Cdesc&colorByAttr=meta%5B%27ci.stage.name%27%5D&cols=%40git.branch%2C%40ci.status%2Ctimestamp%2C%40ci.pipeline.name%2C%40ci.stage.name%2C%40ci.job.name%2C%40duration%2C%40ci.pipeline.id%2C%40git.repository.name&currentTab=trace&fromUser=false&graphType=flamegraph&index=cipipeline&mode=sliding&refresh_mode=sliding&sort=time&spanViewType=metadata&step=86400000&tab=overview&viz=stream&start=1781426607918&end=1786610607918&paused=false) ### Additional Notes See #incident-59050",
          "url": "https://github.com/DataDog/datadog-agent/pull/54781",
          "createdAt": "2026-08-12T14:15:10Z",
          "updatedAt": "2026-08-13T15:03:38Z",
          "timestamp": "2026-08-13T15:03:38Z",
          "metrics": {
            "reactions": 2,
            "comments": 1
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "team/action-platform",
            "internal"
          ],
          "author": "dd-gplassard",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:27040c2cf073f566192e",
        "signalId": "github:DataDog/datadog-agent:pull_request:54832",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "text",
          "updatedAt",
          "metrics",
          "labels"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54832",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add a lightweight gate for prepared Agent rollouts",
          "text": "### What does this PR do? Adds an experimental Linux `agent-rollout-gate` binary to the Agent images used by the node Agent. The Operator can place this binary in front of each Agent container. The gate acquires a component-specific host lock before it starts the real process, so a replacement Pod can be pulled, created, and kept sleeping beside the serving Pod without initializing a second Agent. Each component hands off independently; a slow `system-probe` shutdown does not block the core or trace Agent. While sleeping, the gate's startup probe remains failed indefinitely. Readiness and liveness probes are unchanged and do not run until startup succeeds. After lock acquisition, the gate starts the Agent and preserves the original startup failure budget and termination behavior. ### Motivation Today a DaemonSet update deletes the old Agent before the replacement image is pulled and initialized. Slow or failed pulls therefore create node-level telemetry gaps. This gate supplies the Agent-side primitive for the paired-DaemonSet Operator PoC: prepare the replacement first, then hand over each node-local listener and UDS owner. This does **not** claim zero-gap telemetry. Agent caches, Cluster Agent assignments, metadata, and process state still start cold after handoff. ### Describe how you validated your changes - `dda inv test --targets=./cmd/agent-rollout-gate` — 6 tests passed on Darwin - `dda inv agent-rollout-gate.build` — passed - `dda inv linter.go --targets=./cmd/agent-rollout-gate` — 0 issues - mandatory pre-commit and pre-push hooks — passed The lock, signal, and startup-probe tests are Linux-only and must pass in CI. Experimental-cluster validation is intentionally deferred until both PoCs have been reviewed. The `qa/done` label is intentionally not set until that cluster validation is complete, so the repository's QA-label check is expected to remain red during review. ### Additional Notes - Experimental and Linux-only. - Must be deployed conventionally before opting a `DatadogAgent` into the Operator PoC. - Companion Operator PoC: https://github.com/DataDog/datadog-operator/pull/3355 - Capacity fallback may deliberately use delete-first replacement and reintroduce baseline downtime.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54832",
          "createdAt": "2026-08-13T13:47:40Z",
          "updatedAt": "2026-08-13T15:01:44Z",
          "timestamp": "2026-08-13T15:01:44Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "team/container-platform",
            "long review",
            "team/agent-runtimes",
            "team/agent-devx",
            "team/agent-build",
            "team/profiling-full-host",
            "internal",
            "team/fleet-remediation"
          ],
          "author": "AliDatadog",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:f3c48998dd69aaf1b35b",
        "signalId": "github:DataDog/datadog-agent:pull_request:54803",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54803",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "WIF-48: wire delegated auth into endpoint subsystems",
          "text": "## Summary Stacked on #53517, this PR integrates delegated-auth-managed `DELA(...)` additional endpoints into Agent subsystems: - discovers delegated-auth directives in every supported map- and list-shaped additional-endpoints setting - preserves pending directives during startup and excludes them from outbound keys until resolution - updates forwarder, logs, process, and orchestrator endpoint handling - rebuilds trace proxy transports after delegated-auth resolution and reload; trace writers still require restart to add a previously unresolved endpoint The customer-facing release note is in the foundation PR, #53517. This stacked integration PR is labeled `changelog/no-changelog` to avoid duplicating it. ## Validation Focused tests passed: - forwarder resolver and logs endpoint behavior - trace reload callback and pending-directive transport behavior - config setup parsing, fallback resolution, redaction, map/list registration, and multi-org cases - orchestrator configuration Full trace-config and trace-API Bazel targets are blocked locally by sandbox limitations unrelated to this change: the trace-config external-hostname test cannot find `go` in the Bazel sandbox, and trace-API UDS tests cannot bind a temporary Unix socket in the macOS sandbox. The process-runner target is platform-skipped. ## Dependency Depends on #53517.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54803",
          "createdAt": "2026-08-13T02:02:43Z",
          "updatedAt": "2026-08-13T14:57:39Z",
          "timestamp": "2026-08-13T14:57:39Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "long review"
          ],
          "author": "wynbennett",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:75251383936fe22ce061",
        "signalId": "github:DataDog/datadog-agent:pull_request:54508",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54508",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix(cluster-agent): gate pprof/expvar debug endpoints to loopback",
          "text": "### What does this PR do? The Cluster Agent's metrics server (`0.0.0.0:metrics_port`, default `5000`) served the entire `http.DefaultServeMux`, exposing the `pprof` and `expvar` debug endpoints (registered via blank imports in `cmd/cluster-agent/main.go`) unauthenticated to anything that can reach the pod. This routes only `/metrics` on the public mux and gates everything under `/debug/` to loopback callers, returning `404` to non-loopback requests. ### Motivation Solves #CONTP-1771 and #VULN-87907. `/metrics` must stay reachable off-pod so the node Agent can scrape Cluster Agent telemetry, so a blanket localhost bind (like the core Agent's expvar server) isn't viable — hence a per-path loopback gate. This removes an unauthenticated, network-reachable debug/DoS surface while preserving telemetry scraping and local flare tooling. ### Describe how you validated your changes - Unit tests (`TestLoopbackOnly`, `TestMetricsMuxRouting`) covering loopback vs off-host for `/metrics` and `/debug/*` — 16/16 pass. - `dda inv cluster-agent.build` links clean; `dda inv linter.go` clean; release-note lint clean. - Generated a flare. - Deployed the built cluster-agent image to a local minikube cluster and curled the live DCA pod: - **In-pod** (loopback `127.0.0.1:5000`): `/metrics`, `/debug/vars`, `/debug/pprof/*` all `200` — flare/profiler unaffected. - **Off-pod** (from a separate pod → DCA pod IP): `/debug/*` = `404`, `/metrics` = `200`. - Verified nothing else is registered on the DCA's `DefaultServeMux` (only `pprof`/`expvar`), so no routes are dropped. ### Additional Notes Brings the DCA in line with the core Agent, which already binds its equivalent `pprof`/`expvar` server to `127.0.0.1`, while keeping `/metrics` public.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54508",
          "createdAt": "2026-08-06T12:20:07Z",
          "updatedAt": "2026-08-13T14:54:42Z",
          "timestamp": "2026-08-13T14:54:42Z",
          "metrics": {
            "reactions": 1,
            "comments": 8
          },
          "labels": [
            "qa/done",
            "team/container-platform",
            "medium review",
            "qa/skip-qa",
            "team/agent-build",
            "internal"
          ],
          "author": "wdhif",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:7b25388d1d2c09cf7be2",
        "signalId": "github:DataDog/datadog-agent:pull_request:54821",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54821",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[EBPF] gpu: serialize NVML field value queries",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Ensures that calls to `GetFieldValues` are serialized as that is not a thread safe API. ### Motivation #incident-59170 - `nvlink_fields` collector might mark some ports as unsupported. This is an extra safety on top of #54817, in case parallel collection is enabled. ### Describe how you validated your changes Tested in an A100 instance. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54821",
          "createdAt": "2026-08-13T10:55:17Z",
          "updatedAt": "2026-08-13T14:53:13Z",
          "timestamp": "2026-08-13T14:53:13Z",
          "metrics": {
            "reactions": 2,
            "comments": 6
          },
          "labels": [
            "team/ebpf-platform",
            "qa/done",
            "short review",
            "internal",
            "team/gpu-monitoring-agent",
            "backport/7.82.x",
            "backport/7.83.x"
          ],
          "author": "gjulianm",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:c58bbe5b9e29b3a9c457",
        "signalId": "github:DataDog/datadog-agent:pull_request:54822",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54822",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[AAD-37] Optimize total series count",
          "text": "### What does this PR do? `TotalSeriesCount` was taking a lot of CPU time (and mostly for telemetry), removed overhead by O(1) CPU / memory. This removes 36.8% of CPU on the staging cluster I tested, quick win! ### Motivation ### Describe how you validated your changes [Profile](https://ddstaging.datadoghq.com/profiling/comparison?query=service%3Adatadog-agent%20kube_cluster_name%3Astingchameleon&compare_end_A=1786621749000&compare_end_B=1786626605000&compare_start_A=1786620495000&compare_start_B=1786625998000&compareValuesMode=absolute&my_code=enabled&profiling-flame-graph__filter=focus_on%28package%3Agithub.com%2FDataDog%2Fdatadog-agent%2Fcomp%2Fanomalydetection%29&viz=flame_graph&from_ts=1786623005144&to_ts=1786626605144&live=false) <img width=\"2375\" height=\"497\" alt=\"Screenshot 2026-08-13 at 15 21 37\" src=\"https://github.com/user-attachments/assets/126c3a5c-543e-4e92-8f02-4682e20e45e4\" /> ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54822",
          "createdAt": "2026-08-13T11:16:18Z",
          "updatedAt": "2026-08-13T14:51:48Z",
          "timestamp": "2026-08-13T14:51:48Z",
          "metrics": {
            "reactions": 2,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "medium review",
            "internal"
          ],
          "author": "CelianR",
          "state": "open",
          "assignees": [
            "CelianR"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:98adc5b7c3318b99230d",
        "signalId": "github:DataDog/datadog-agent:pull_request:53517",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53517",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "WIF-48: add delegated-auth dual-shipping foundation",
          "text": "## Summary This PR contains the reusable delegated-auth foundation for WIF dual shipping: - extends the delegated-auth component so an instance can update an additional-endpoint key in either map- or list-shaped configuration - adds shared helpers for normalizing list-shaped endpoints and reading case-insensitive fields - recognizes pending `DELA(...)` directives so consumers can avoid sending them as literal API keys - exchanges proofs against the configured target site rather than always using `dd_url` - covers token-domain parsing, component updates, and directive handling with unit tests The Agent subsystem integration is intentionally split into a stacked follow-up PR. It wires this foundation into config setup, forwarder, logs, process, orchestrator, and trace-agent reload/proxy behavior. ## Validation - `bazel test //comp/core/delegatedauth/... //pkg/config/utils/... --build_tests_only` ## Review note The local subagent reviewer service failed before startup, so its adversarial and security passes could not run. No review findings were produced.",
          "url": "https://github.com/DataDog/datadog-agent/pull/53517",
          "createdAt": "2026-07-10T17:39:01Z",
          "updatedAt": "2026-08-13T14:48:10Z",
          "timestamp": "2026-08-13T14:48:10Z",
          "metrics": {
            "reactions": 1,
            "comments": 7
          },
          "labels": [
            "team/agent-apm",
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-configuration",
            "team/agent-log-pipelines",
            "team/agent-metric-pipelines",
            "team/container-experiences",
            "team/agent-build",
            "team/kubernetes-experiences",
            "internal",
            "team/fleet-automation"
          ],
          "author": "wynbennett",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:1b472b0e66a5b90ba9a1",
        "signalId": "github:DataDog/datadog-agent:pull_request:54375",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54375",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "configfilesdiscovery: collect redis env vars",
          "text": "### What does this PR do? Collects selected, non-secret Redis environment variables alongside Redis config files in `configfilesdiscovery`. It uses regex-based allow and deny rules plus the shared secret-name filter. Config-file selection follows `redis-server` argv, then `REDIS_CONF_FILE`, then known default paths. The shared reader accepts the optional fallback while Kafka retains its existing behavior by passing none. ### Motivation DSCVR-619 ### Describe how you validated your changes Unit tests. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54375",
          "createdAt": "2026-08-03T15:53:00Z",
          "updatedAt": "2026-08-13T14:44:56Z",
          "timestamp": "2026-08-13T14:44:56Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "medium review",
            "team/agent-discovery",
            "internal"
          ],
          "author": "Yumasi",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:9b490b9f28bd5004e4a3",
        "signalId": "github:DataDog/datadog-agent:pull_request:51295",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:51295",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add source to distributions via checks.",
          "text": "### What does this PR do? This adds the source to distributions that have been submitted by a Go check. ### Motivation Source was added to other metrics in #20690. This completes the source for distributions. ### Describe how you validated your changes Tested manually by creating a dummy go check, which was not added to this PR. ### Additional Notes [RFC outlining](https://datadoghq.atlassian.net/wiki/spaces/AM/pages/6773538856/RFC+-+Add+origin+to+check+distribution+metrics) the impact of this change. (TLDR there is no known negative impact)",
          "url": "https://github.com/DataDog/datadog-agent/pull/51295",
          "createdAt": "2026-05-26T11:16:34Z",
          "updatedAt": "2026-08-13T14:43:10Z",
          "timestamp": "2026-08-13T14:43:10Z",
          "metrics": {
            "reactions": 2,
            "comments": 8
          },
          "labels": [
            "qa/done",
            "short review",
            "team/agent-metric-pipelines",
            "internal"
          ],
          "author": "StephenWakely",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:61c1fe1b4cd11485bb21",
        "signalId": "github:DataDog/datadog-agent:pull_request:54790",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "metrics",
          "labels"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54790",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "ci: default to GIT_DEPTH=1, full clone for jobs needing git history",
          "text": "### What does this PR do? Sets a repo-wide `GIT_DEPTH: 1` default in `.gitlab-ci.yml` to speed up job checkouts, and adds `GIT_DEPTH: 0` overrides on the jobs whose scripts (or the invoke tasks they call) run history-dependent git operations: - `.gitlab/build/source_test/golang_deps_diff.yml` (`golang_deps_diff` — `git merge-base` via `go-deps.diff`) - `.gitlab/test/e2e/e2e.yml` (`.new_e2e_template` — `git merge-base` for `--impacted` test selection) - `.gitlab/.pre/ci_configuration.yml` (`test_gitlab_compare_to`, `compute_gitlab_ci_config`, `lint_github_actions_shellcheck` — all use `git merge-base`) - `.gitlab/build/binary_build/fakeintake.yml` (`fakeintake_check_version_bump` — `git merge-base` + reading a file at the merge-base commit) - `.gitlab/deploy/internal_kubernetes_deploy/internal_kubernetes_deploy.yml` (`notify-slack` — `git log` over a commit range for the changelog) - `.gitlab/build/lint/technical_linters.yml` (`lint_releasenotes_rst` — `git merge-base`) - `.gitlab/.pre/setup/setup.yml` (`setup_agent_version` — `git describe --tags`, needs full history to find the nearest tag) Jobs that already had an explicit `GIT_DEPTH`/`GIT_STRATEGY` override (`regression_detector.yml`, `static_quality_gate.yml`, `files_inventory_check.yml`, the Windows bazel runner) were left untouched. The Windows `GIT_STRATEGY: \"clone\"` templates in `deploy/conditions.yml` / `agent7.yml` are unrelated to git history (they work around CIEXE-1152 for cancelled jobs) and don't need `GIT_DEPTH: 0`. ### Motivation Shallow clones reduce checkout time/bandwidth across the pipeline, which runs on every commit/PR. ### Describe how you validated your changes - Validated YAML syntax of all changed files. - Manually traced every git operation (`git merge-base`, `git log` ranges, `git describe --tags`) reachable from CI jobs, including through the invoke tasks they call (`tasks/libs/common/git.py`, `tasks/gotest.py`, `tasks/libs/releasing/version.py`, etc.) to confirm which jobs need full history. - Ran the `gitlab-configuration` pre-push linter (`dda inv linter.full-gitlab-ci -t main --pre-push-linters --fail-fast`) locally — passed with pre-existing warnings unrelated to this change. ### Additional Notes **Known risk, intentionally not addressed here:** the Linux/macOS/Windows unit-test jobs use `--only-impacted-packages` on essentially every dev-branch pipeline (via `FAST_TESTS=true`), which calls `git merge-base` through `tasks/gotest.py:get_impacted_packages` with **no error handling**. Under `GIT_DEPTH=1`, if the merge-base predates the 1-commit shallow window, this would hard-fail the test job rather than gracefully falling back to running all tests. This wasn't addressed in this PR to avoid setting `GIT_DEPTH: 0` on the largest and most CI-time-costly category of jobs, which would defeat much of the purpose of this change. Options going forward: harden the fallback in `get_impacted_packages` (deepen fetch or fall back to \"run all tests\" on merge-base failure), or scope `GIT_DEPTH: 0` to those jobs if the risk materializes.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54790",
          "createdAt": "2026-08-12T17:04:33Z",
          "updatedAt": "2026-08-13T14:41:40Z",
          "timestamp": "2026-08-13T14:41:40Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "team/agent-delivery",
            "medium review",
            "team/container-integrations",
            "team/agent-devx",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "KevinFairise2",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:86060d0a73bb222e9088",
        "signalId": "github:DataDog/datadog-agent:pull_request:54819",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54819",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Copy python files to avoid junction issues",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54819",
          "createdAt": "2026-08-13T10:45:46Z",
          "updatedAt": "2026-08-13T14:39:12Z",
          "timestamp": "2026-08-13T14:39:12Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/agent-build",
            "internal"
          ],
          "author": "JSGette",
          "state": "open",
          "assignees": [
            "JSGette"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:ec3be84883481212ac17",
        "signalId": "github:DataDog/datadog-agent:pull_request:54792",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54792",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Increase Quality Gate memory thresholds for ADP pre-flight mode",
          "text": "ADP pre-flight mode (#54175) adds 23 MiB to peak PSS on every workload that exercises a default Agent configuration. Pre-flight is enabled by default and runs ADP for 90 seconds at startup in anticipation of turning it on by default. This PR re-baselines all Quality Gate memory thresholds. | Gate | Old (MiB) | Observed (MiB) | New (MiB) | |---|---|---|---| | `quality_gate_idle` | 154 | 174.89 | 178 | | `quality_gate_logs` | 195 | 216.59 | 229 | | `quality_gate_metrics_logs` | 430 | 417.52 | 439 | | `quality_gate_idle_all_features` | 512 | 524.74 | 538 | | `quality_gate_security_idle` | 330 | 330.55 | 335 | | `quality_gate_security_no_fs_load` | 320 | 319.31 | 343 | | `quality_gate_security_mean_fs_load` | 310 | 309.05 | 314 | | `quality_gate_private_action_runner` | 75 | 74.04 | 76 | Observed values come from `total_pss_bytes` on the comparison variant of last night's Quality Gate run. Bounds are sized to 1% over observed + 1 MiB, with the exception of `logs`, `metrics_logs`, and `security_no_fs_load`. Those three are sized against their three-week peak to account for variability that is not currently captured every night.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54792",
          "createdAt": "2026-08-12T17:54:22Z",
          "updatedAt": "2026-08-13T14:36:54Z",
          "timestamp": "2026-08-13T14:36:54Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "team/agent-security",
            "team/single-machine-performance",
            "qa/no-code-change",
            "medium review",
            "team/action-platform",
            "internal",
            "team/agent-data-plane"
          ],
          "author": "GeorgeHahn",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:391f6250236468860a77",
        "signalId": "github:DataDog/datadog-agent:pull_request:54810",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "state"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54810",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Remove bazel strptime_cgo_testlib override",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Remove bazel strptime_cgo_testlib override. ### Motivation Fixed by https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/49516. ### Describe how you validated your changes CI ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54810",
          "createdAt": "2026-08-13T08:49:37Z",
          "updatedAt": "2026-08-13T14:34:51Z",
          "timestamp": "2026-08-13T14:34:51Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "internal"
          ],
          "author": "pgimalac",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:95deb5bed55bfa2d7ed3",
        "signalId": "github:DataDog/datadog-agent:pull_request:54471",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54471",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CWS-6177] Use dynamic sampling",
          "text": "### What does this PR do? Makes CWS event sampling react to event stream backpressure instead of applying a fixed rate limit. All rate-limit decisions for the sampled event types (`open`, `connect`, `bind`, `dns`) now route through a new eBPF helper, `sampling_admission_check()` in `pkg/security/ebpf/c/include/helpers/approvers.h`. It reads the current events ring buffer occupancy with `bpf_ringbuf_query()`, converts it to a pressure percentage against the configured ring buffer size, and picks one of three behaviors: | Ring buffer pressure | Behavior | |---|---| | `< threshold` (per event type) | Bypass the rate limiter, always sample | | `threshold` to 90% | Fall back to the existing token-bucket limiter | | `> 90%` (`SAMPLING_PRESSURE_CRITICAL`) | Drop the sample outright | Thresholds are per event type and configurable, defaulting to `open: 80`, `dns: 60`, `bind: 60`, `connect: 40`. A higher threshold means the limiter is bypassed for longer, so that event type is throttled later. The whole path is gated behind a new `event_sampling.dynamic.enabled` setting and behind `USE_RING_BUFFER` plus a runtime `use_ring_buffer` check. When either is off, behavior is identical to today. Also adds a `datadog.runtime_security.event_sample.pressure_level` gauge reporting the peak pressure observed per stats window. ### Config ``` # BEFORE — fixed rate, 500 events/sec per type regardless of load runtime_security_config: event_sampling: open: enabled: true rate: 500 connect: enabled: true rate: 500 bind: enabled: true rate: 500 dns: enabled: true rate: 500 ``` ``` # AFTER — same config still valid; opt in to pressure-aware sampling runtime_security_config: event_sampling: dynamic: enabled: true # new: turns on pressure-aware admission open: enabled: true rate: 500 # now the throttled-band rate, not a hard cap threshold: 80 # new: bypass the limiter below 80% buffer pressure connect: enabled: true rate: 500 threshold: 40 bind: enabled: true rate: 500 threshold: 60 dns: enabled: true rate: 500 threshold: 60 ```",
          "url": "https://github.com/DataDog/datadog-agent/pull/54471",
          "createdAt": "2026-08-05T13:37:32Z",
          "updatedAt": "2026-08-13T14:31:44Z",
          "timestamp": "2026-08-13T14:31:44Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/agent-security",
            "team/ebpf-platform",
            "qa/done",
            "medium review",
            "internal",
            "team/fleet-automation"
          ],
          "author": "mftoure",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:d74d477fabb9aca208ce",
        "signalId": "github:DataDog/datadog-agent:pull_request:54591",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54591",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] add par-control executor channel",
          "text": "### What does this PR do? Defines the local control-to-executor channel and implements both ends of it: - Adds the executor gRPC protocol and generated bindings. - Exposes executor health and readiness. - Synchronizes workflow signing keys. - Streams action dispatch outcomes. - Adds the Rust mTLS client and transport support. - Keeps the shared terminal `Outcome` model with the executor layer. This layer provides communication primitives only; polling and process-lifecycle policy remain in later layers. ### Motivation Create a narrow, authenticated local contract between `par-control` and the existing Go executor before introducing OPMS polling or orchestration. ### Validation - Focused Go tests pass locally. - Private Action Runner Go build passes locally. - Portable Rust tests pass locally; native-tls identity coverage requires Linux/Windows. ### Review fixes - **Transport**: 5s connect timeout on both the plain and the mTLS channel, and no panic path in the named-pipe retry loop. Also corrects module docs that claimed Windows named-pipe support was a follow-up while the named-pipe client sits in the same file. - Dropped the redundant `tokio-stream` dev-dependency, since this layer promotes it to a regular dependency. - README records the build caveats: the dev VM's empty `PKG_CONFIG_LIBDIR` breaks `openssl-sys` under cargo, proto-touching changes must be Bazel-verified (under `--cfg=bazel` the bindings come from a separate crate, so the orphan rule differs), and the TLS tests are Linux-only. ### Stack PR 5 of 9. Based on #54590; followed by #54592.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54591",
          "createdAt": "2026-08-07T17:50:14Z",
          "updatedAt": "2026-08-13T14:31:39Z",
          "timestamp": "2026-08-13T14:31:39Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:7d4f2f55b8eb90a7ac9b",
        "signalId": "github:DataDog/datadog-agent:pull_request:54829",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "metrics"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54829",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[EBPF] gpu: improve collector run telemetry",
          "text": "### What does this PR do? Improves the collector telemetry for the GPU check by adding a new counter for the number of runs per collector, and also adds device-related tags: device name, architecture, NVlink capabilities, MIG/vGPU state. ### Motivation Facilitate debugging and monitoring, with these tags we will be able to understand whether collectors are failing for specific GPU types for example. ### Describe how you validated your changes Ran the agent and validated that the telemetry has the necessary tags. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54829",
          "createdAt": "2026-08-13T11:57:55Z",
          "updatedAt": "2026-08-13T14:25:28Z",
          "timestamp": "2026-08-13T14:25:28Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [],
          "author": "gjulianm",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:73e061ff337bf2ac9823",
        "signalId": "github:DataDog/datadog-agent:pull_request:54660",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54660",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(autodiscovery): tag configuration-discovery instances to mitigate duplicate metrics risk",
          "text": "### What does this PR do? Adds a `dd_config_discovery:true` tag to every check instance scheduled via the Autodiscovery configuration-discovery mechanism (i.e. any `auto_conf.yaml` template with `discovery: {}`, resolved through `comp/core/autodiscovery/impl/configmgr_discovery.go`'s `applyDiscoveredConfigsLocked`). The tag used is `dd_config_discovery:true`, a plain `dd_`-prefixed key, following the precedent of other agent-added, customer-visible marker/provenance tags already in the codebase: - `dd_remote_config_id` / `dd_remote_config_rev` (`comp/core/tagger/tags/tags.go`) - `dd_enable_check_intake` (`pkg/collector/worker/worker.go`) ### Motivation [DSCVR-651](https://datadoghq.atlassian.net/browse/DSCVR-651): there is a risk that an agent on host A is monitoring a service on host B with a manually-configured check (e.g. a generic `openmetrics` check), while the agent running locally on host B also autodiscovers and schedules a dedicated integration for the same service via configuration discovery. Neither agent's local anti-duplication logic can see the other's config, so both submit metrics for the same underlying data. This tag doesn't prevent the duplication, but lets users identify and, if needed, exclude the autodiscovered side of it (e.g. `metric{!dd_config_discovery:true}`), both for the cross-host case above and for any single-host case the automatic suppression doesn't catch. ### Describe how you validated your changes Unit and E2E tests. --- 🤖 This PR description and implementation were generated with assistance from [Claude Code](https://claude.com/claude-code). [DSCVR-651]: https://datadoghq.atlassian.net/browse/DSCVR-651?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54660",
          "createdAt": "2026-08-10T16:56:47Z",
          "updatedAt": "2026-08-13T14:24:27Z",
          "timestamp": "2026-08-13T14:24:27Z",
          "metrics": {
            "reactions": 3,
            "comments": 8
          },
          "labels": [
            "qa/done",
            "team/container-platform",
            "medium review",
            "team/agent-discovery",
            "team/agent-build",
            "internal",
            "backport/7.83.x"
          ],
          "author": "vitkyrka",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:9bd738efdc97de1b53a7",
        "signalId": "github:DataDog/datadog-agent:pull_request:54774",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54774",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CWS] Fix: handle activity dump endpoint host that already embeds a port",
          "text": "### What does this PR do? Fixes CWS activity dump uploads to dual-shipped `additional_endpoints` whose `host` already includes a port (e.g. `cws-intake.datadoghq.com.:443`). `GetEndpointURL` was appending the port a second time, producing a malformed `[host:port]:port` authority that failed URL parsing — so every upload to that endpoint failed with an `invalid port` error. The host is now split before joining, so an embedded port is honored instead of duplicated. An explicitly configured port still wins, and bare IPv6 literals are untouched. ### Motivation In prod, CWS activity dumps were failing to reach the secondary (dual-ship) endpoint.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54774",
          "createdAt": "2026-08-12T11:37:04Z",
          "updatedAt": "2026-08-13T14:23:51Z",
          "timestamp": "2026-08-13T14:23:51Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/agent-security",
            "qa/done",
            "short review",
            "team/agent-build",
            "internal"
          ],
          "author": "kovagsm",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:149e3392d6b848b4eb26",
        "signalId": "github:DataDog/datadog-agent:pull_request:54362",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54362",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CONTINT-5415] Tag CronJob-owned Job events with kube_cronjob",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? This PR adds the `kube_cronjob` tag to Kubernetes Job events when they are spawned by a cronjob. It does this by parsing through the job name, the same as what is done in the [tagger](https://github.com/DataDog/datadog-agent/blob/9f1c7785f27a5a040377c1f0db4e4faf50cefe3d/comp/core/tagger/collectors/workloadmeta_extract.go#L1206) and [KSM](https://github.com/DataDog/datadog-agent/blob/9f1c7785f27a5a040377c1f0db4e4faf50cefe3d/pkg/collector/corechecks/cluster/ksm/kubernetes_state.go#L1479) check. ### Motivation Closes issue https://github.com/DataDog/datadog-agent/issues/52611 https://datadoghq.atlassian.net/browse/CONTINT-5415 ### Describe how you validated your changes On a kind cluster, built and deployed the agent with event bundling enabled, added a cronjob that spawns a new job with schedule `* * * * *`. Saw that events are emitted with the proper `kube_cronjob` tag: <img width=\"835\" height=\"387\" alt=\"image\" src=\"https://github.com/user-attachments/assets/e3991a91-a636-4a4a-96c7-84e61df2127f\" /> ### Additional Notes This change is _complete_ in that any job events spawned by a cronjob while have this tag, it's not _sound_ in that there could be jobs (not spawned by a cronjob) that could parse as a if its spawned by a cronjob, and the `kube_cronjob` tag will be emitted. Since other parts of the agent have accepted this risk, it's probably acceptable here too but I think worth noting.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54362",
          "createdAt": "2026-08-03T14:42:35Z",
          "updatedAt": "2026-08-13T14:16:32Z",
          "timestamp": "2026-08-13T14:16:32Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "qa/done",
            "medium review",
            "team/container-integrations",
            "team/agent-build",
            "internal"
          ],
          "author": "triviajon",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:e1d69f1b28aa26424da6",
        "signalId": "github:DataDog/datadog-agent:pull_request:54539",
        "event": "discovered",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54539",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Update ownership/notifications for delegatedauth component+code",
          "text": "### What does this PR do? Update ownership configs for delegatedauth component & related code. Goals: - Make it clear that _either_ credential-management OR delegated-auth-login may approve PRs - Notify #workload-identity-federation channel instead of #aaa-auth-identity-help. I didn't realize it would be sending a message about every new PR to review. This will get PRs more directly to the right reviewers.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54539",
          "createdAt": "2026-08-06T19:27:53Z",
          "updatedAt": "2026-08-13T14:07:51Z",
          "timestamp": "2026-08-13T14:07:51Z",
          "metrics": {
            "reactions": 3,
            "comments": 4
          },
          "labels": [],
          "author": "srosenthal-dd",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:0bef702d3945be848a0a",
        "signalId": "github:DataDog/datadog-agent:issue:54801",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "metrics",
          "labels",
          "state"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:issue:54801",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "issue",
          "title": "NDM Agent Workload Balancing: switch RC product from NDM_AGENT_WORKLOAD_BALANCING to HA_AGENT",
          "text": "## Context PRs #54652, #54656, #54659, and #54795 implemented NDM Agent Workload Balancing's agent-side component (`comp/workloadbalancing`), registering its own Remote Config product, `NDM_AGENT_WORKLOAD_BALANCING`. The design RFC ([NDM Agent Workload Balancing: Device Handoff](https://datadoghq.atlassian.net/wiki/spaces/II/pages/7029621750)) has since been updated to reuse HA Agent's existing `HA_AGENT` Remote Config product instead, extending its schema with a second, discriminated payload type rather than registering a new product. This follows the same polymorphic-payload pattern already used by ASM and Network Path's `NETWORK_PATH` product, and was settled after a Slack discussion establishing that extending an existing RC pipeline runs roughly 1-2 weeks versus roughly 1-2 months for a new one (new product registration, delivery predicates, the full RC checklist including security review). ## What needs to change - `comp/workloadbalancing`'s Remote Config listener: subscribe to `state.ProductHaAgent` (`HA_AGENT`) instead of a new `NDM_AGENT_WORKLOAD_BALANCING` product. - The listener needs to only act on documents carrying workload-balancing's discriminator field (e.g. `group_id`), ignoring ordinary HA Agent election documents (`config_id`/`active_agent`) on the same product, per `comp/haagent`'s existing per-document filtering pattern. - Apply-status handling: skip `applyStateCallback` for documents this listener doesn't own, mirroring the existing pattern in `comp/core/autodiscovery/providers/networkpath/provider.go` and `comp/networkpath/npcollector/impl/remote_config.go`, which already share one RC product between two independent listeners. - The RC product schema itself (config validator's schema library) needs to move from a new `NDM_AGENT_WORKLOAD_BALANCING` directory to an extension of `HA_AGENT`'s existing `root.json`. - Backend-side writer (`WorkloadBalancingService.UpsertGroupAssignment`) needs to target `HA_AGENT` RC documents instead of a separate product. - Test suite in `test/new-e2e/tests/workload-balancing/` currently calls `RCAddConfig(..., state.ProductNDMAgentWorkloadBalancing, ...)` — needs updating to `state.ProductHaAgent` with the new payload shape. ## Why this is a separate follow-up This is a documentation-first change: the RFC update landed ahead of the code so reviewers are working from the current design. The already-merged agent code should be brought in line with it once the RFC's schema/discriminator details are finalized. > **Note:** This issue was created by Claude.",
          "url": "https://github.com/DataDog/datadog-agent/issues/54801",
          "createdAt": "2026-08-12T20:42:56Z",
          "updatedAt": "2026-08-13T14:07:16Z",
          "timestamp": "2026-08-13T14:07:16Z",
          "metrics": {
            "reactions": 0,
            "comments": 1
          },
          "labels": [
            "oss/0",
            "team/network-device-monitoring-core"
          ],
          "author": "matthewleese",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:d7b4bd796f703bf536ed",
        "signalId": "github:DataDog/datadog-agent:pull_request:54795",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "metrics",
          "state"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54795",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "test(ndm): add e2e coverage for Agent Workload Balancing",
          "text": "> **Note:** This PR was created by Claude. ### What does this PR do? Adds the e2e test suite for Agent Workload Balancing that was called out as needed in #54652's original plan, and adds the one missing CLI surface found while auditing that plan for completeness. - `TestWorkloadBalancingRunningMetrics` / `TestWorkloadBalancingAddedToRCListeners` (`workloadbalancing_test.go`): mirrors `haagent_test.go`. Pushes an `NDM_AGENT_WORKLOAD_BALANCING` Remote Config payload via `RCAddConfig` against fakeintake, then asserts `datadog.agent.workload_balancing.running` (tagged `workload_balancing_group`/`workload_balancing_state`) and the `\"Add workload balancing RCListener\"` log line. - `TestWorkloadBalancingMetadata` (`workloadbalancing_metadata_test.go`): mirrors `haagent_metadata_test.go`. Pushes an RC assignment, then reads it back via `diagnose show-metadata workload-balancing`. - `cmd/agent/subcommands/diagnose/command.go`: adds the `show-metadata workload-balancing` subcommand. #54659 wired the metadata provider into inventory, flare, status, and the `/metadata/workload-balancing` HTTP endpoint, but left out the CLI subcommand that HA Agent has as `show-metadata ha-agent`. The metadata e2e test above needs it to read the payload the same way the HA Agent test does. - `.gitlab-ci.yml` / `.gitlab/test/e2e/e2e.yml`: adds a `new-e2e-workload-balancing` job and its change-triggering rule, following the `ha-agent` job pattern. - `.github/CODEOWNERS`: adds `/test/new-e2e/tests/workload-balancing`. ### Motivation This was the fourth piece of the originally planned agent-side work (component, metric, inventory metadata, e2e test), deferred because it was \"blocked on #53246 for Remote Config fakeintake support.\" That PR merged, so the blocker is gone. Not included here: a multi-host failover test analogous to `haagent_failover_test.go` (driving an actual handoff between two hosts). Left as a follow-up TODO in `workloadbalancing_test.go` rather than adding a large multi-VM test to this PR. ### Describe how you validated your changes - `go vet ./tests/workload-balancing/...` in `test/new-e2e` passes. - `gofmt` clean on all changed/added files. - Base branch merges (`mleese/ndm-device-handoff` + `mleese/ndm-workload-balancing-metric` + `mleese/ndm-workload-balancing-metadata`) were clean, no conflicts. - Not yet run against real infra (draft; depends on #54652, #54656, #54659 landing first). ### Additional Notes Stacked on top of `mleese/ndm-device-handoff` (#54652), and depends on `mleese/ndm-workload-balancing-metric` (#54656) and `mleese/ndm-workload-balancing-metadata` (#54659) both being merged into it — this branch already contains both of those changes merged in, since they're sibling branches rather than stacked on each other.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54795",
          "createdAt": "2026-08-12T19:04:08Z",
          "updatedAt": "2026-08-13T14:02:29Z",
          "timestamp": "2026-08-13T14:02:29Z",
          "metrics": {
            "reactions": 1,
            "comments": 7
          },
          "labels": [],
          "author": "matthewleese",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:87fd6b7b345eefa101b2",
        "signalId": "github:DataDog/datadog-agent:pull_request:54659",
        "event": "discovered",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54659",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(ndm): report workload balancing group state as inventory metadata",
          "text": "> **Note:** This PR was created by Claude. Stacked on #54652 — review that one first. ### What does this PR do? Adds a `comp/metadata/workloadbalancing` component, mirroring the existing `comp/metadata/haagent`. When Agent workload balancing is enabled it reports a `workload_balancing_metadata` inventory payload: ```json { \"hostname\": \"...\", \"workload_balancing_metadata\": { \"enabled\": true, \"groups\": {\"group-a\": \"active\", \"group-b\": \"standby\"} }, \"timestamp\": 1716985696922603000 } ``` It surfaces in three places: the inventory product, `agent status` (text and HTML), and the `/metadata/workload-balancing` endpoint. The flare picks it up as `workload-balancing.json`. Nothing is reported when workload balancing is disabled, which is the default. Unlike HA Agent, which has a single Agent-wide state, this Agent can hold a different state per group, so the payload carries a map rather than one string. ### Motivation `datadog.agent.workload_balancing.running` says a group is being run somewhere. It does not say which Agent holds it, or what the Agent itself thinks it holds. When a handoff does not land, the first question is which Agent believes it is active, and the inventory and status page are where that gets answered without shelling into a pod. ### Describe how you validated your changes - `go test -tags test ./comp/metadata/... ./cmd/agent/subcommands/run/... ./cmd/agent/subcommands/flare/...` — pass, including new tests for the payload, the copy semantics of the group map, the disabled case, and the status text/HTML renderers - `go build ./...` and `go vet -tags test ./comp/metadata/... ./cmd/agent/...` — clean - `dda inv linter.go --targets=./comp/metadata/workloadbalancing` — 0 issues - `dda inv components.lint-components --fix` and `bazel run //:gazelle` for the generated files No manual validation: the Remote Config product that populates the group states still needs backend registration.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54659",
          "createdAt": "2026-08-10T16:47:55Z",
          "updatedAt": "2026-08-13T14:02:28Z",
          "timestamp": "2026-08-13T14:02:28Z",
          "metrics": {
            "reactions": 0,
            "comments": 6
          },
          "labels": [
            "qa/done",
            "team/agent-runtimes",
            "team/fleet-remediation",
            "team/fleet-automation"
          ],
          "author": "matthewleese",
          "state": "closed",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:7ee54f5fe6c6d66c3872",
        "signalId": "github:DataDog/datadog-agent:pull_request:54656",
        "event": "discovered",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54656",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(ndm): emit a metric per workload balancing group",
          "text": "> **Note:** This PR was created by Claude. Stacked on #54652 — review that one first. ### What does this PR do? Emits `datadog.agent.workload_balancing.running` once per NDM workload balancing group the Agent knows about, tagged with: - `workload_balancing_group:<id>` - `workload_balancing_state:active|standby|unmanaged` It follows the shape of the existing `datadog.agent.ha_agent.running` metric and is emitted from the same place, `BufferedAggregator.appendDefaultSeries`. Nothing is emitted when workload balancing is disabled, which is the default. The `workloadbalancing` component is threaded into the aggregator through the demultiplexer, which is most of the diff. ### Motivation The interesting signal is the gap, not the value. Each group should be reported as `active` by exactly one Agent. If the assigned Agent goes away and the reassignment does not land, the group stops being reported as active anywhere, and that absence is visible in a way that a silently unpolled device is not. ### Describe how you validated your changes - `go test -tags test ./pkg/aggregator/... ./comp/aggregator/...` — pass, including two new tests covering the tags and states emitted per group and that a disabled component emits nothing - `go vet -tags test ./...` — clean across the module - `dda inv linter.go --targets=./pkg/aggregator,./comp/aggregator/demultiplexer/impl` — 0 issues - `bazel run //:gazelle` for the BUILD.bazel files No manual validation: the Remote Config product that populates the group states still needs backend registration.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54656",
          "createdAt": "2026-08-10T16:25:18Z",
          "updatedAt": "2026-08-13T14:02:26Z",
          "timestamp": "2026-08-13T14:02:26Z",
          "metrics": {
            "reactions": 0,
            "comments": 9
          },
          "labels": [
            "qa/done",
            "long review",
            "team/agent-integrations",
            "team/agent-metric-pipelines",
            "internal",
            "team/network-device-monitoring-core",
            "team/fleet-automation"
          ],
          "author": "matthewleese",
          "state": "closed",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:8a499fb473828afe5fa6",
        "signalId": "github:DataDog/datadog-agent:pull_request:54652",
        "event": "discovered",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54652",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(ndm): add Agent workload balancing",
          "text": "> **Note:** This PR was created by Claude. ### What does this PR do? Adds NDM Agent workload balancing: a device can be handed from one Agent to another without restarting either one. **The component** (`comp/workloadbalancing`) - `def/` — the `Component` interface and the `Active` / `Standby` / `Unmanaged` states - `impl/` — an `RWMutex`-guarded map of group ID to state, the `agent_workload_balancing.enabled` config read, and the Remote Config update callback - `fx/`, `mock/`, `helpers/` — the usual component scaffolding - `pkg/config/schema/yaml/core_schema.yaml` — the new `agent_workload_balancing.enabled` setting, default `false` **Remote Config** New `NDM_AGENT_WORKLOAD_BALANCING` product in `pkg/remoteconfig/state/products.go`. Each config names a group and the Agent that should actively poll it. The listener is registered only when the setting is enabled. **Where the group comes from** The SNMP instance setting `agent_workload_balancing_group` flows through `InstanceConfig` into `CheckConfig` and out via `Check#WorkloadBalancingGroupID()`, a new method on the `Check` interface that returns the empty string for everything else. It is deliberately left out of `DeviceDigest`, so moving a device between groups does not change its identity. **The gate** `pkg/collector/worker` skips a check only when workload balancing is enabled, the check names a group, and that group is not active on this Agent. **Wiring** `workloadbalancingfx.Module()` at 12 binary sites; the component is threaded into the collector and the check runner. ### Motivation First slice of the NDM Agent load balancing RFC. Today moving a device between Agents means editing config on both and restarting them, which leaves a monitoring gap. The design follows `comp/haagent` closely, with two deliberate differences: - **State is per group, not per Agent.** One Agent can be active for some groups and standby for others, so the component holds a map rather than a single value. - **It fails open.** HA treats an unknown state as a reason to suppress. Here a group we hold no assignment for is `Unmanaged` and runs, and only an explicit standby suppresses. Duplicate monitoring during a handoff is recoverable; a silent device is not. For the same reason an empty Remote Config update clears every group rather than suppressing everything, and a group that drops out of the set returns to unmanaged. ### Describe how you validated your changes - `go test -tags test ./comp/workloadbalancing/... ./pkg/collector/... ./comp/collector/...` — pass - `go build ./...` — clean - `dda inv linter.go` over the touched packages — clean apart from a pre-existing cgo typecheck failure in `pkg/collector/python`, which this PR does not touch - `bazel run //:gazelle` for the BUILD.bazel files - fx graph validation via `go test -tags test ./cmd/agent/subcommands/... ./cmd/dogstatsd/subcommands/... ./pkg/cli/subcommands/...` Unit tests cover: enabled/disabled config; the unmanaged-runs default; standby suppression; `RemoveGroup`; group independence; `GetGroupStates` returning a copy; Remote Config apply/error states for valid, malformed, and partially valid update sets; and the worker gate across active, standby, unmanaged, and disabled. No manual validation yet — the Remote Config product still needs backend registration before an end-to-end handoff can be exercised. ### Additional Notes Still draft. Remaining work, in its own PRs: the `datadog.agent.workload_balancing.running` metric, inventory metadata, and an e2e test (blocked on #53246 for Remote Config fakeintake support).",
          "url": "https://github.com/DataDog/datadog-agent/pull/54652",
          "createdAt": "2026-08-10T15:32:03Z",
          "updatedAt": "2026-08-13T14:02:24Z",
          "timestamp": "2026-08-13T14:02:24Z",
          "metrics": {
            "reactions": 0,
            "comments": 8
          },
          "labels": [
            "team/agent-apm",
            "team/remote-config",
            "qa/done",
            "team/container-platform",
            "long review",
            "team/agent-integrations",
            "team/agent-runtimes",
            "team/container-experiences",
            "team/agent-build",
            "internal",
            "team/network-device-monitoring-core",
            "team/fleet-automation"
          ],
          "author": "matthewleese",
          "state": "closed",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:cef6b122c588eb343515",
        "signalId": "github:DataDog/datadog-agent:pull_request:54814",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54814",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[AGENTRUN-1446] Skip nss failover e2e test it if the fakeintakes are still in use",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Due to a framework issue, the fakeintakes might still be in use (ie. an agent is still sending payloads to them) when the test starts, which makes the test flaky. We added a detection logic to fail early in this case (to avoid confusion when debugging). Update the logic to skip the test rather than fail it in this case. ### Motivation Avoid receiving notifications for failed test for a framework issue. ### Describe how you validated your changes CI ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54814",
          "createdAt": "2026-08-13T09:46:46Z",
          "updatedAt": "2026-08-13T14:02:07Z",
          "timestamp": "2026-08-13T14:02:07Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "team/agent-runtimes",
            "team/agent-build",
            "internal"
          ],
          "author": "pgimalac",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:7bca1814340d349cee7e",
        "signalId": "github:DataDog/datadog-agent:pull_request:54799",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt",
          "metrics",
          "labels",
          "state"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54799",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "ci: default GitLab jobs to shallow clones, keep full history where needed",
          "text": "## Summary - Default GitLab jobs to `GIT_DEPTH: 1` so most checkouts are a shallow clone of HEAD only. - Set `GIT_DEPTH: 0` on jobs that actually need git history (merge-base, ancestor walks, `git describe`, `git log` ranges). - `GIT_STRATEGY: clone` is not a full clone; clone with depth 1 is still shallow. Full history requires `GIT_DEPTH: 0`. ## Test plan - [ ] Confirm a typical build/lint job clones with depth 1 and still has the working tree. - [ ] Confirm jobs that compute merge-base still succeed (`golang_deps_diff`, e2e `--impacted`, `static_quality_gates`, `files_inventory_check`, SMP merge-base check). - [ ] Confirm `setup_agent_version` can still run `git describe --tags`. - [ ] Confirm unit-test jobs with `FAST_TESTS=true` still detect impacted packages. Made with [Cursor](https://cursor.com)",
          "url": "https://github.com/DataDog/datadog-agent/pull/54799",
          "createdAt": "2026-08-12T20:14:02Z",
          "updatedAt": "2026-08-13T14:01:36Z",
          "timestamp": "2026-08-13T14:01:36Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "community",
            "changelog/no-changelog",
            "team/agent-apm",
            "team/ebpf-platform",
            "qa/no-code-change",
            "team/agent-delivery",
            "team/container-integrations",
            "team/agent-devx",
            "team/agent-build",
            "team/windows-products"
          ],
          "author": "mikesherovdd",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:7c5cf88dd8f6e06a7662",
        "signalId": "github:DataDog/datadog-agent:pull_request:52993",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:52993",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Unify converter features behavior",
          "text": "### What does this PR do? Make all extension-related converter features behave like `datadog` and `dogtel`: in the case where the relevant extension is defiled by the user but not added to `service.pipeline`, add this instance instead of defining a `/dd-autoconfigured` one ### Motivation Unify the user experience [OTAGENT-1127](https://datadoghq.atlassian.net/browse/OTAGENT-1127?atlOrigin=eyJpIjoiZjBlOGI1ODVhYzlhNGZjNWExMzczYTM4MjY0NTE5MWYiLCJwIjoiaiJ9) ### Describe how you validated your changes Tests ### Additional Notes [OTAGENT-1127]: https://datadoghq.atlassian.net/browse/OTAGENT-1127?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/52993",
          "createdAt": "2026-06-30T17:01:11Z",
          "updatedAt": "2026-08-13T14:01:09Z",
          "timestamp": "2026-08-13T14:01:09Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "qa/done",
            "medium review",
            "team/opentelemetry-agent",
            "stale",
            "internal"
          ],
          "author": "agagniere",
          "state": "open",
          "assignees": [
            "agagniere"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:117fb3c1287a4002cafc",
        "signalId": "github:DataDog/datadog-agent:pull_request:54826",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54826",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[EBPF] Download gpu-burner for GPU tests",
          "text": "### What does this PR do? Downloads gpu-burner before GPU integration tests run. ### Motivation Allow the tests to use the gpu-burner mASS artifact. ### Describe how you validated your changes Confirmed the CI rules trigger `tests_gpu` for this file change. ### Additional Notes The referenced branch artifact expires after seven days.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54826",
          "createdAt": "2026-08-13T11:49:04Z",
          "updatedAt": "2026-08-13T13:58:45Z",
          "timestamp": "2026-08-13T13:58:45Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "team/ebpf-platform",
            "short review",
            "team/agent-devx",
            "team/agent-build",
            "internal",
            "team/gpu-monitoring-agent"
          ],
          "author": "gjulianm",
          "state": "open",
          "assignees": [
            "gjulianm"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:3d67536c433b78947729",
        "signalId": "github:DataDog/datadog-agent:pull_request:54809",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54809",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(cancel): Force cancellation of running jobs",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Improve cleanup to also cancel running jobs. Move call to stack-cleaner to after_script, which is executed after a \"graceful\" (not forced) job cancel. Prevent cleanup of whitelisted jobs. ### Motivation Reduce pressure on infrastructure. ### Describe how you validated your changes Local tests and attempt to push a new commit on this precise branch ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54809",
          "createdAt": "2026-08-13T08:42:37Z",
          "updatedAt": "2026-08-13T13:50:05Z",
          "timestamp": "2026-08-13T13:50:05Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/container-integrations",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "chouetz",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:3b845917b4727a24cffb",
        "signalId": "github:DataDog/datadog-agent:pull_request:54812",
        "event": "changed",
        "observedAt": "2026-08-13T16:19:22.035158Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54812",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Move tools/tar_checksums to bazel/tools",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Moves tar_checksums code to under `bazel/tools`, such that it falls under the agent-build team ownership. ### Motivation I made a PR that touched these files and no review from agent-build was requested, even though this is under our scope. This is also consistent with the contents of both folders (`bazel/tools` vs `tools`) as things stand today. ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54812",
          "createdAt": "2026-08-13T09:32:34Z",
          "updatedAt": "2026-08-13T13:48:08Z",
          "timestamp": "2026-08-13T13:48:08Z",
          "metrics": {
            "reactions": 2,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/agent-build",
            "internal"
          ],
          "author": "alopezz",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:64ba9869d27f270aac31",
        "signalId": "github:DataDog/datadog-agent:pull_request:54841",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "text",
          "updatedAt",
          "metrics",
          "labels"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54841",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CONTP-2006] feat(ddi): Stream resolved targets from DCA to node agent",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Streams per-Pod resolved workload targets from the Cluster Agent to Node Agents through the Kubernetes metadata stream. - Adds a generic `PodTargetResolver` interface to keep the transport independent from the DDI resolver implementation. - Includes resolved targets in initial full-state responses and incremental `SET` and `UNSET` updates scoped to each node. - Enriches Node Agent Pod workload metadata when resolved targets change. No production resolver is wired in this PR, so the new transport remains dormant until a later change supplies resolved targets. ### Motivation [CONTP-2006](https://datadoghq.atlassian.net/browse/CONTP-2006) Custom owner-chain resolution belongs in the Cluster Agent, where Kubernetes API access is centralized, while Autodiscovery CEL matching runs on each Node Agent. A node-scoped transport is therefore required to deliver resolved target identity without granting every Node Agent access to arbitrary workload resources. ### Describe how you validated your changes ### Additional Notes [CONTP-2006]: https://datadoghq.atlassian.net/browse/CONTP-2006?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54841",
          "createdAt": "2026-08-13T15:46:01Z",
          "updatedAt": "2026-08-13T17:43:18Z",
          "timestamp": "2026-08-13T17:43:18Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "team/container-platform",
            "medium review",
            "team/container-integrations",
            "team/agent-build",
            "internal"
          ],
          "author": "Mathew-Estafanous",
          "state": "open",
          "assignees": [
            "Mathew-Estafanous"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:7700bbdc58a88cb93aef",
        "signalId": "github:DataDog/datadog-agent:pull_request:54840",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt",
          "metrics",
          "labels"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54840",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CONTP-2006] feat(ddi): Add resolved target to workloadmeta",
          "text": "### What does this PR do? Adds group- and version-aware resolved workload targets to Kubernetes Pod workload metadata and the workload-filter CEL model. - Preserves `apiVersion` and `controller` from Kubernetes owner references in both Pod parsers. - Adds `KubernetesPod.ResolvedTargets` with group, version, kind, namespace, name, and UID identity. - Exposes resolved targets to CEL as `container.pod.resolved_targets`. This is an additive data-model change and does not alter current DatadogInstrumentation matching behavior. ### Motivation [CONTP-2006](https://datadoghq.atlassian.net/browse/CONTP-2006) DatadogInstrumentation currently matches workload Pods through `rootowner`, which only carries kind and name and relies on built-in ownership conventions. Supporting arbitrary workload CRs requires a structured, API-group-aware identity that can distinguish identical kinds from different API groups and carry targets resolved by the Cluster Agent to CEL evaluation. ### Describe how you validated your changes ### Additional Notes [CONTP-2006]: https://datadoghq.atlassian.net/browse/CONTP-2006?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54840",
          "createdAt": "2026-08-13T15:44:42Z",
          "updatedAt": "2026-08-13T17:43:01Z",
          "timestamp": "2026-08-13T17:43:01Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "team/container-platform",
            "medium review",
            "team/container-integrations",
            "team/agent-runtimes",
            "team/agent-build",
            "internal"
          ],
          "author": "Mathew-Estafanous",
          "state": "open",
          "assignees": [
            "Mathew-Estafanous"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:921a287e35ed305986b5",
        "signalId": "github:DataDog/datadog-agent:pull_request:54843",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt",
          "metrics"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54843",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CONTP-2006] feat(ddi): Connect custom workload targets to DDI controller and streaming",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Connects configurable workload target resolution to DatadogInstrumentation checks and logs. - Adds `instrumentation_crd_controller.custom_workload_targets` configuration. - Starts the Pod workloadmeta store and resolver when at least one custom target is configured. - Accepts registered target GVKs and generates CEL selectors against `container.pod.resolved_targets`. - Includes `apiVersion` when detecting duplicate target references. - Preserves `rootowner` matching for built-in workloads and EndpointSlice delivery for core `v1` Services. For example, a workload reached through an intermediate Kubernetes Job can be configured as: ```yaml instrumentation_crd_controller: custom_workload_targets: - target: apiVersion: example.com/v1 kind: ScheduledWorkload resource: scheduledworkloads via: - apiVersion: batch/v1 kind: Job resource: jobs ``` ### Motivation [CONTP-2006](https://datadoghq.atlassian.net/browse/CONTP-2006) DatadogInstrumentation supports core Kubernetes workload kinds and Argo Rollouts out of the box, but customers also run workloads through controllers such as Ray, Kueue, OpenKruise, and Strimzi. Customers need an opt-in way to declare the workload resources they use and the ownership path from Pods, without relying on a generic fallback or requiring every custom kind to be added to the Agent. ### Describe how you validated your changes ### Additional Notes [CONTP-2006]: https://datadoghq.atlassian.net/browse/CONTP-2006?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54843",
          "createdAt": "2026-08-13T15:53:26Z",
          "updatedAt": "2026-08-13T17:42:53Z",
          "timestamp": "2026-08-13T17:42:53Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [],
          "author": "Mathew-Estafanous",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:007deb0e370f1b207abb",
        "signalId": "github:DataDog/datadog-agent:pull_request:54804",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54804",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix(installer): embed -nocap systemd unit templates",
          "text": "## What does this PR do? Adds `//go:embed` directives for `tmpl/gen/oci-nocap/*.service` and `tmpl/gen/debrpm-nocap/*.service`, and the matching Bazel `embedsrcs` entries, so the `-nocap` systemd unit templates ship inside the installer binary. Adds `embed_test.go`, which enumerates units through the `embed.FS` and asserts `GetSystemdUnit` resolves every unit in both the ambient-capability and `-nocap` variants. ## Motivation This is to address this escalation: https://datadoghq.atlassian.net/browse/AGENT-16750 `GetSystemdUnit` selects the `-nocap` templates on hosts whose kernel does not support ambient capabilities (older than 4.3), but no `//go:embed` directive covered those directories. Unit generation failed at runtime with: ``` failed to write stable units: open tmpl/gen/debrpm-nocap/datadog-agent.service: file does not exist ``` The package manager scriptlet ignores that failure, so the install reported success while the host was left with no Datadog units and `systemctl start datadog-agent` returned `Unit not found`. Both the classic DEB/RPM path and Fleet Automation remote upgrades and config experiments (`oci-nocap`) were affected. The existing tests missed this because they read the template tree from disk instead of from the `embed.FS`, so the templates were always present regardless of the embed directives. ## Verification - `dda inv test --targets=./pkg/fleet/installer/packages/embedded` - 83 tests passed - `bazel test //pkg/fleet/installer/packages/embedded:all` - `embedded_test` and `tmpl_test` passed - The new `TestGetSystemdUnitEmbedsAllVariants` fails on `main` (`file does not exist` for every `-nocap` unit) and passes with this change - `TestGetSystemdUnitSelectsNocapVariant` confirms the `-nocap` unit actually has `AmbientCapabilities=` stripped, not just that it loads ### Known gap, not addressed here `tmpl/datadog-agent-data-plane.service.tmpl` emits `AmbientCapabilities` unconditionally, without the `{{ if .AmbiantCapabilitiesSupported }}` guard its siblings use, so its two variants are byte-identical. That is a pre-existing template defect, out of scope for this fix, and is documented in a comment on the test. 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
          "url": "https://github.com/DataDog/datadog-agent/pull/54804",
          "createdAt": "2026-08-13T03:52:11Z",
          "updatedAt": "2026-08-13T17:42:48Z",
          "timestamp": "2026-08-13T17:42:48Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "qa/done",
            "medium review",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "mwdd146980",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:3d8600930c340da93300",
        "signalId": "github:DataDog/datadog-agent:issue:33469",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "text",
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:issue:33469",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "issue",
          "title": "Dependency Dashboard",
          "text": "This issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.<br>[View this repository on the Mend.io Web Portal](https://developer.mend.io/github/DataDog/datadog-agent). ## Deprecations / Replacements > [!WARNING] The following dependencies are either deprecated or have replacements available. | Datasource | Package | Replacement PR? | |------------|------|--------------| | nuget | [xunit](https://redirect.github.com/xunit/xunit) | ![Unavailable](https://img.shields.io/badge/unavailable-orange?style=flat-square) | ## Pending Approval The following branches are pending approval. To create them, click on a checkbox below. - [ ] <!-- approve-branch=renovate/github.com-alecthomas-participle-2.x -->Update module github.com/alecthomas/participle to v2 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-authorization-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/authorization/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-compute-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/compute/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-containerservice-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/containerservice/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-managedidentity-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/managedidentity/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-network-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/network/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-docker-sdk-v4-5.x -->Update module github.com/pulumi/pulumi-docker/sdk/v4 to v5 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-tls-sdk-v4-5.x -->Update module github.com/pulumi/pulumi-tls/sdk/v4 to v5 - [ ] <!-- approve-branch=renovate/github.com-sijms-go-ora-v2-3.x -->Update module github.com/sijms/go-ora/v2 to v3 - [ ] <!-- approve-branch=renovate/gitlab.com-gitlab-org-api-client-go-2.x -->Update module gitlab.com/gitlab-org/api/client-go to v2 - [ ] <!-- approve-branch=renovate/gopkg.in-datadog-dd-trace-go.v1-2.x -->Update module gopkg.in/DataDog/dd-trace-go.v1 to v2 - [ ] <!-- approve-all-pending-prs -->🔐 **Create all pending approval PRs at once** 🔐 ## Rate-Limited The following updates are currently rate-limited. To force their creation now, click on a checkbox below. - [ ] <!-- unlimit-branch=renovate/datadog-dd-apm-library-python-4.x -->Update dependency DataDog/dd-apm-library-python to v4.13.1 - [ ] <!-- unlimit-branch=renovate/linux-images-130715735.x -->Update dependency linux-images to v130715735 - [ ] <!-- unlimit-branch=renovate/linux-images-devcontainer-130715735.x -->Update dependency linux-images-devcontainer to v130715735 - [ ] <!-- unlimit-branch=renovate/windows-images-130715735.x -->Update dependency windows-images to v130715735 - [ ] <!-- unlimit-branch=renovate/github-actions -->Update github-actions (`DataDog/dd-sts-action`, `actions/checkout`, `aws-actions/configure-aws-credentials`, `docker/login-action`, `tcort/github-action-markdown-link-check`) - [ ] <!-- unlimit-branch=renovate/github.com-jarcoal-httpmock-1.x -->Update module github.com/jarcoal/httpmock to v1.4.2 - [ ] <!-- unlimit-branch=renovate/github.com-klauspost-compress-1.x -->Update module github.com/klauspost/compress to v1.19.2 - [ ] <!-- unlimit-branch=renovate/github.com-mattn-go-sqlite3-1.x -->Update module github.com/mattn/go-sqlite3 to v1.14.49 - [ ] <!-- unlimit-branch=renovate/github.com-pierrec-lz4-v4-4.x -->Update module github.com/pierrec/lz4/v4 to v4.1.28 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-random-sdk-v4-4.x -->Update module github.com/pulumi/pulumi-random/sdk/v4 to v4.21.1 - [ ] <!-- unlimit-branch=renovate/github.com-santhosh-tekuri-jsonschema-v6-6.x -->Update module github.com/santhosh-tekuri/jsonschema/v6 to v6.0.3 - [ ] <!-- unlimit-branch=renovate/github.com-vektra-mockery-v3-3.x -->Update module github.com/vektra/mockery/v3 to v3.7.2 - [ ] <!-- unlimit-branch=renovate/go.etcd.io-etcd-client-v2-2.x -->Update module go.etcd.io/etcd/client/v2 to v2.305.33 - [ ] <!-- unlimit-branch=renovate/go.temporal.io-api-1.x -->Update module go.temporal.io/api to v1.63.5 - [ ] <!-- unlimit-branch=renovate/clap-4.x-lockfile -->Update Rust crate clap to v4.6.6 - [ ] <!-- unlimit-branch=renovate/packaging-26.x -->Update dependency packaging to v26.3 - [ ] <!-- unlimit-branch=renovate/cloud.google.com-go-compute-1.x -->Update module cloud.google.com/go/compute to v1.65.0 - [ ] <!-- unlimit-branch=renovate/code.cloudfoundry.org-lager-v3-3.x -->Update module code.cloudfoundry.org/lager/v3 to v3.81.0 - [ ] <!-- unlimit-branch=renovate/github.com-apache-arrow-go-v18-18.x -->Update module github.com/apache/arrow-go/v18 to v18.7.0 - [ ] <!-- unlimit-branch=renovate/github.com-aquasecurity-trivy-0.x -->Update module github.com/aquasecurity/trivy to v0.73.0 - [ ] <!-- unlimit-branch=renovate/github.com-containerd-containerd-v2-2.x -->Update module github.com/containerd/containerd/v2 to v2.3.3 - [ ] <!-- unlimit-branch=renovate/github.com-datadog-dd-trace-go-contrib-net-http-v2-2.x -->Update module github.com/DataDog/dd-trace-go/contrib/net/http/v2 to v2.9.1 - [ ] <!-- unlimit-branch=renovate/github.com-datadog-orchestrion-1.x -->Update module github.com/DataDog/orchestrion to v1.12.0 - [ ] <!-- unlimit-branch=renovate/github.com-docker-cli-29.x -->Update module github.com/docker/cli to v29.7.2+incompatible - [ ] <!-- unlimit-branch=renovate/github.com-envoyproxy-gateway-1.x -->Update module github.com/envoyproxy/gateway to v1.8.3 - [ ] <!-- unlimit-branch=renovate/github.com-google-cel-go-0.x -->Update module github.com/google/cel-go to v0.30.0 - [ ] <!-- unlimit-branch=renovate/github.com-open-policy-agent-opa-1.x -->Update module github.com/open-policy-agent/opa to v1.19.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-aws-sdk-v7-7.x -->Update module github.com/pulumi/pulumi-aws/sdk/v7 to v7.40.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-awsx-sdk-v3-3.x -->Update module github.com/pulumi/pulumi-awsx/sdk/v3 to v3.8.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-eks-sdk-v4-4.x -->Update module github.com/pulumi/pulumi-eks/sdk/v4 to v4.3.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-gcp-sdk-v9-9.x -->Update module github.com/pulumi/pulumi-gcp/sdk/v9 to v9.33.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-sdk-v3-3.x -->Update module github.com/pulumi/pulumi/sdk/v3 to v3.256.0 - [ ] <!-- unlimit-branch=renovate/github.com-rabbitmq-amqp091-go-1.x -->Update module github.com/rabbitmq/amqp091-go to v1.13.0 - [ ] <!-- unlimit-branch=renovate/github.com-redis-go-redis-v9-9.x -->Update module github.com/redis/go-redis/v9 to v9.22.0 - [ ] <!-- unlimit-branch=renovate/go.temporal.io-sdk-1.x -->Update module go.temporal.io/sdk to v1.47.0 - [ ] <!-- unlimit-branch=renovate/sigs.k8s.io-gateway-api-1.x -->Update module sigs.k8s.io/gateway-api to v1.6.1 - [ ] <!-- unlimit-branch=renovate/redis-7.x -->Update redis Docker tag to v7.4 - [ ] <!-- unlimit-branch=renovate/confluentinc-cp-kafka-8.x -->Update confluentinc/cp-kafka Docker tag to v8 - [ ] <!-- unlimit-branch=renovate/major-github-actions -->Update github-actions (major) (`actions/cache`, `actions/labeler`, `actions/setup-go`, `actions/setup-node`, `actions/setup-python`, `actions/stale`, `slackapi/slack-github-action`) - [ ] <!-- unlimit-branch=renovate/postgres-17.x -->Update postgres Docker tag to v17 - [ ] <!-- unlimit-branch=renovate/redis-8.x -->Update redis Docker tag to v8 - [ ] <!-- create-all-rate-limited-prs -->🔐 **Create all rate-limited PRs at once** 🔐 ## Pending Status Checks The following updates await pending status checks. To force their creation now, click on a checkbox below. - [ ] <!-- approvePr-branch=renovate/confluentinc-cp-kafka-7.x -->Update confluentinc/cp-kafka Docker tag to v7.9.9 - [ ] <!-- approvePr-branch=renovate/rules_rs-0.x -->Update dependency rules_rs to v0.0.102 - [ ] <!-- approvePr-branch=renovate/franz-go -->Update module github.com/twmb/franz-go to v1.21.6 - [ ] <!-- approvePr-branch=renovate/google.golang.org-protobuf-1.x -->Update module google.golang.org/protobuf to v1.36.12 - [ ] <!-- approvePr-branch=renovate/dd_sds-0.x -->Update Rust crate dd_sds to v0.1.0-20260813-972b5d8d1827 - [ ] <!-- approvePr-branch=renovate/http-body-util-0.x-lockfile -->Update Rust crate http-body-util to v0.1.5 - [ ] <!-- approvePr-branch=renovate/thiserror-2.x-lockfile -->Update Rust crate thiserror to v2.0.20 - [ ] <!-- approvePr-branch=renovate/hatchling-1.x -->Update dependency hatchling to v1.32.0 - [ ] <!-- approvePr-branch=renovate/azure-sdk-for-go-monorepo -->Update module github.com/Azure/azure-sdk-for-go/sdk/azcore to v1.23.0 - [ ] <!-- approvePr-branch=renovate/github.com-datadog-datadog-api-client-go-v2-2.x -->Update module github.com/DataDog/datadog-api-client-go/v2 to v2.64.0 - [ ] <!-- approvePr-branch=renovate/github.com-sirupsen-logrus-1.x -->Update module github.com/sirupsen/logrus to v1.10.0 - [ ] <!-- approvePr-branch=renovate/public.ecr.aws-docker-library-alpine-3.x -->Update public.ecr.aws/docker/library/alpine Docker tag to v3.24.1 - [ ] <!-- approvePr-branch=renovate/ureq-3.x-lockfile -->Update Rust crate ureq to v3.4.0 - [ ] <!-- approvePr-branch=renovate/npm-sentry-dotagents-3.x -->Update dependency npm:@sentry/dotagents to v3 --- > [!WARNING] > Renovate failed to look up the following dependencies: `Failed to look up go package github.com/prometheus/client_model: no-result`, `Failed to look up go package github.com/mohae/deepcopy: no-result`, `Failed to look up go package github.com/evanphx/json-patch/v5: no-result`, `Failed to look up nuget package WixToolset.Dtf.WindowsInstaller: no-result`, `Failed to look up nuget package YamlDotNet: no-result`, `Failed to look up nuget package xunit.analyzers: no-result`, `Failed to look up nuget package xunit: no-result`, `Failed to look up nuget package WixSharp_wix4: no-result`, `Failed to look up nuget package System.Runtime.CompilerServices.Unsafe: no-result`, `Failed to look up nuget package more.xunit.runner.visualstudio: no-result`, `Failed to look up nuget package Newtonsoft.Json: no-result`, `Failed to look up nuget package System.Threading.Tasks.Extensions: no-result`. > > Files affected: `comp/core/agenttelemetry/impl/go.mod`, `comp/core/telemetry/go.mod`, `comp/otelcol/ddflareextension/impl/go.mod`, `go.mod`, `pkg/config/nodetreemodel/go.mod`, `pkg/fleet/installer/go.mod`, `tools/windows/DatadogAgentInstaller/AgentCustomActions/AgentCustomActions.csproj`, `tools/windows/DatadogAgentInstaller/CustomActions.Tests/CustomActions.Tests.csproj`, `tools/windows/DatadogAgentInstaller/CustomActions/CustomActions.csproj`, `tools/windows/DatadogAgentInstaller/InstallerCustomActions/InstallerCustomActions.csproj`, `tools/windows/DatadogAgentInstaller/WixSetup.Tests/WixSetup.Tests.csproj`, `tools/windows/DatadogAgentInstaller/WixSetup/WixSetup.csproj` --- ## Other Branches The following updates are pending. To force the creation of a PR, click on a checkbox below. - [ ] <!-- other-branch=renovate/integrations-core-digest -->Update integrations-core digest to 84ce638 - [ ] <!-- other-branch=renovate/aws-sdk-go-v2 -->Update aws-sdk-go-v2 (`github.com/aws/aws-sdk-go-v2`, `github.com/aws/aws-sdk-go-v2/config`, `github.com/aws/aws-sdk-go-v2/credentials`, `github.com/aws/aws-sdk-go-v2/service/ec2`, `github.com/aws/aws-sdk-go-v2/service/ecr`, `github.com/aws/aws-sdk-go-v2/service/ecs`, `github.com/aws/aws-sdk-go-v2/service/eks`, `github.com/aws/aws-sdk-go-v2/service/rds`, `github.com/aws/aws-sdk-go-v2/service/s3`, `github.com/aws/aws-sdk-go-v2/service/secretsmanager`, `github.com/aws/aws-sdk-go-v2/service/ssm`, `github.com/aws/aws-sdk-go-v2/service/sts`) - [ ] <!-- other-branch=renovate/github.com-go-delve-delve-1.x -->Update module github.com/go-delve/delve to v1.27.1 - [ ] <!-- other-branch=renovate/github.com-google-go-containerregistry-0.x -->Update module github.com/google/go-containerregistry to v0.21.9 ## Open The following updates have all been created. To force a retry/rebase of any, click on a checkbox below. - [ ] <!-- rebase-branch=renovate/go-github.com-datadog-dd-trace-go-v2-vulnerability -->[Update module github.com/DataDog/dd-trace-go/v2 to v2.8.1 [SECURITY]](../pull/53708) - [ ] <!-- rebase-branch=renovate/datadog-datadog-agent-dev-0.x -->[Update dependency DataDog/datadog-agent-dev to v0.38.0](../pull/52555) - [ ] <!-- rebase-branch=renovate/sentry-dotagents-3.x -->[Update dependency @sentry/dotagents to v3](../pull/54802) - [ ] <!-- rebase-branch=renovate/github.com-datadog-dd-trace-go-v2-2.x -->[Update module github.com/DataDog/dd-trace-go/v2 to v2.9.1](../pull/52521) - [ ] <!-- rebase-branch=renovate/gawk-5.x -->[Update dependency gawk to v5.4.0](../pull/52963) - [ ] <!-- rebase-branch=renovate/kubernetes-monorepo -->[Update kubernetes monorepo to v0.36.3](../pull/51833) (`k8s.io/api`, `k8s.io/apiextensions-apiserver`, `k8s.io/apimachinery`, `k8s.io/cli-runtime`, `k8s.io/client-go`, `k8s.io/component-base`, `k8s.io/cri-api`, `k8s.io/cri-client`, `k8s.io/kube-aggregator`, `k8s.io/kubectl`, `k8s.io/kubelet`, `k8s.io/metrics`) - [ ] <!-- rebase-branch=renovate/github.com-godror-godror-0.x -->[Update module github.com/godror/godror to v0.51.0](../pull/53235) - [ ] <!-- rebase-branch=renovate/k8s.io-autoscaler-vertical-pod-autoscaler-1.x -->[Update module k8s.io/autoscaler/vertical-pod-autoscaler to v1.7.1](../pull/51852) - [ ] <!-- rebase-branch=renovate/k8s.io-kube-state-metrics-v2-2.x -->[Update module k8s.io/kube-state-metrics/v2 to v2.19.1](../pull/52895) - [ ] <!-- rebase-branch=renovate/sigs.k8s.io-custom-metrics-apiserver-1.x -->[Update module sigs.k8s.io/custom-metrics-apiserver to v1.36.0](../pull/52282) - [ ] <!-- rebase-branch=renovate/docker.io-library-ubuntu-26.x -->[Update docker.io/library/ubuntu Docker tag to v26](../pull/52153) - [ ] <!-- rebase-branch=renovate/docker.io-ubuntu-26.x -->[Update docker.io/ubuntu Docker tag to v26](../pull/50840) - [ ] <!-- rebase-branch=renovate/github.com-cloudfoundry-community-go-cfclient-v2-3.x -->[Update module github.com/cloudfoundry-community/go-cfclient/v2 to v3](../pull/53622) - [ ] <!-- rebase-branch=renovate/github.com-netsampler-goflow2-2.x -->[Update module github.com/netsampler/goflow2 to v2](../pull/53239) - [ ] <!-- rebase-branch=renovate/major-franz-go -->[Update module github.com/twmb/franz-go/pkg/kmsg to v2](../pull/53824) - [ ] <!-- rebase-all-open-prs -->**Click on this checkbox to rebase all open PRs at once** ## PR Closed (Blocked) The following updates are blocked by an existing closed PR. To recreate the PR, click on a checkbox below. - [ ] <!-- recreate-branch=renovate/rules_go-0.x -->[Update dependency rules_go to v0.62.0](../pull/54068) - [ ] <!-- recreate-branch=renovate/code.cloudfoundry.org-bbs-1.x -->[Update module code.cloudfoundry.org/bbs to v1.11.0](../pull/53818) - [ ] <!-- recreate-branch=renovate/github.com-aws-karpenter-provider-aws-1.x -->[Update module github.com/aws/karpenter-provider-aws to v1.14.0](../pull/53819) - [ ] <!-- recreate-branch=renovate/github.com-bazelbuild-rules_go-0.x -->[Update module github.com/bazelbuild/rules_go to v0.62.0](../pull/54057) - [ ] <!-- recreate-branch=renovate/gopkg.in-datadog-dd-trace-go.v1-1.x -->[Update module gopkg.in/DataDog/dd-trace-go.v1 to v1.74.8](../pull/52894) - [ ] <!-- recreate-branch=renovate/sigs.k8s.io-karpenter-1.x -->[Update module sigs.k8s.io/karpenter to v1.14.0](../pull/53820) - [ ] <!-- recreate-branch=renovate/chef-sugar-5.x -->[Update dependency chef-sugar to v5](../pull/51540) - [ ] <!-- recreate-branch=renovate/invoke-3.x -->[Update dependency invoke to v3](../pull/50838) - [ ] <!-- recreate-branch=renovate/code.cloudfoundry.org-bbs-models-1.x -->[Update module code.cloudfoundry.org/bbs/models to v1](../pull/53823) - [ ] <!-- recreate-branch=renovate/github.com-santhosh-tekuri-jsonschema-v5-6.x -->[Update module github.com/santhosh-tekuri/jsonschema/v5 to v6](../pull/54069) - [ ] <!-- recreate-branch=renovate/go.etcd.io-etcd-client-v2-3.x -->[Update module go.etcd.io/etcd/client/v2 to v3](../pull/53825) - [ ] <!-- recreate-branch=renovate/go.yaml.in-yaml-v2-3.x -->[Update module go.yaml.in/yaml/v2 to v3](../pull/53527) ## Detected Dependencies > [!NOTE] > Detected dependencies section has been truncated <details><summary>bazel-module (2)</summary> <blockquote> <details><summary>deps/repos.MODULE.bazel</summary> </details> <details><summary>MODULE.bazel (20)</summary> - `bazel_lib 3.7.1` - `bazel_skylib 1.9.2` - `gawk 5.3.2.bcr.7` → [Updates: `5.4.0`] - `gazelle 0.52.2` - `libarchive 3.8.1.bcr.2` - `platforms 1.1.0` - `re.bzl 0.3.1` - `rules_cc 0.2.22` - `rules_flex 0.4.1` - `rules_go 0.61.1` → [Updates: `0.62.0`] - `rules_m4 0.3.bcr.1` - `rules_multitool 1.11.1` - `rules_python 2.2.0` - `rules_rs 0.0.27` → [Updates: `0.0.102`] - `rules_rust 0.73.0` - `rules_rust_prost 0.73.0` - `rules_shell 0.8.0` - `toml.bzl 0.4.1` - `rules_testing 0.9.0` - `apple_support 2.8.0` </details> </blockquote> </details> <details><summary>bazelisk (1)</summary> <blockquote> <details><summary>.bazelversion</summary> </details> </blockquote> </details> <details><summary>bitbucket-pipelines (1)</summary> <blockquote> <details><summary>.gitlab/.pre/cancel-prev-pipelines.yml</summary> </details> </blockquote> </details> <details><summary>bundler (1)</summary> <blockquote> <details><summary>omnibus/Gemfile (2)</summary> - `chef-sugar v3.6.0` → [Updates: `v5.1.12`] - `mixlib-cli '~> 2.1.0'` </details> </blockquote> </details> <details><summary>cargo (9)</summary> <blockquote> <details><summary>Cargo.toml (57)</summary> - `anyhow 1.0.98` - `cap-std 4.0` - `dd_sds =0.1.0-20260803-1e4349aada52` → [Updates: `=0.1.0-20260813-972b5d8d1827`] - `caps 0.5` - `chrono 0.4` - `clap 4.5` → [Updates: `4.5`] - `elf 0.8.0` - `glob-match 0.2` - `http-body-util 0.1` → [Updates: `0.1`] - `hostname 0.4` - `hyper 1` - `hyper-util 0.1` - `libc 0.2` - `log 0.4` - `prost 0.14` - `prost-build 0.14` - `prost-types 0.14` - `protoc-gen-prost 0.5` - `protoc-gen-tonic 0.5` - `lru 0.18.0` - `memchr 2.7.6` - `nom 8.0` - `normalize-path 0.2` - `phf 0.14` - `rawzip 0.5.0` - `xml-rs 1.0` - `rmp-serde 1.3` - `serde 1.0.219` - `serde_json 1.0` - `serde_yaml 0.9` - `time 0.3` - `thiserror 2.0.12` → [Updates: `2.0.12`] - `tokio 1` - `tokio-stream 0.1` - `tonic 0.14` - `tonic-build 0.14` - `tonic-prost 0.14` - `tonic-prost-build 0.14` - `tonic-reflection 0.14` - `ureq 3.0` → [Updates: `3.0`] - `uzers 0.12` - `walkdir 2` - `saphyr-parser 0.0.11` - `yaml-rust2 0.11` - `zip 8.0` - `flate2 1.1` - `tower 0.5` - `uuid 1` - `windows-registry 0.6` - `windows-sys 0.61` - `dircpy 0.3.19` - `regex 1` - `memmap2 0.9` - `nix 0.31` - `scopeguard 1.2` - `temp-env 0.3` - `tempfile 3.0` </details> <details><summary>cmd/ai_prompt_logger/Cargo.toml</summary> </details> <details><summary>comp/core/log/rust/Cargo.toml</summary> </details> <details><summary>pkg/collector/sharedlibrary/rustchecks/checks/datasecurity/Cargo.toml (1)</summary> - `postgres 0.19` </details> <details><summary>pkg/collector/sharedlibrary/rustchecks/checks/example/Cargo.toml</summary> </details> <details><summary>pkg/collector/sharedlibrary/rustchecks/core/Cargo.toml</summary> </details> <details><summary>pkg/discovery/module/rust/Cargo.toml</summary> </details> <details><summary>pkg/privateactionrunner/par-control/Cargo.toml</summary> </details> <details><summary>pkg/procmgr/rust/Cargo.toml</summary> </details> </blockquote> </details> <details><summary>docker-compose (36)</summary> <blockquote> <details><summary>cmd/host-profiler/docker-compose.yml (1)</summary> - `registry.datadoghq.com/agent 7` </details> <details><summary>pkg/collector/corechecks/oracle/compose/docker-compose.yml</summary> </details> <details><summary>pkg/discovery/module/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/amqp/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/http/testutil/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/kafka/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/mongo/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/mysql/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/postgres/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/redis/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/tls/gotls/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/tls/nodejs/testdata/docker-compose-ubuntu.yml</summary> </details> <details><summary>pkg/network/protocols/tls/nodejs/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/tracer/testdata/dnsworkload/docker-compose.yml</summary> </details> <details><summary>pkg/network/usm/testdata/bio_leak_test/docker-compose.yml</summary> </details> <details><summary>pkg/network/usm/testdata/musl/docker-compose.yml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/dogstatsd/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/jmxfetch/docker-compose-all-metrics.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/jmxfetch/docker-compose-slow-metrics.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/jmxfetch/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/logger/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/redis/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/integration/etcd/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/integration/kafka/docker-compose.yaml (3)</summary> - `confluentinc/cp-kafka 7.9.8` → [Updates: `7.9.9`, `8.3.0`] - `confluentinc/cp-kafka 7.9.8` → [Updates: `7.9.9`, `8.3.0`] - `confluentinc/cp-kafka 7.9.8` → [Updates: `7.9.9`, `8.3.0`] </details> <details><summary>test/e2e-framework/components/integration/postgres/docker-compose.yaml (2)</summary> - `postgres 16` → [Updates: `17`] - `postgres 16` → [Updates: `17`] </details> <details><summary>test/e2e-framework/components/integration/redisdb/docker-compose.yaml (2)</summary> - `redis 7.2` → [Updates: `7.4`, `8.2`] - `redis 7.2` → [Updates: `7.4`, `8.2`] </details> <details><summary>test/fakeintake/docker-compose.yaml</summary> </details> <details><summary>test/new-e2e/examples/testfixtures/docker-compose.fake-process.yaml</summary> </details> <details><summary>test/new-e2e/examples/testfixtures/docker-compose.lighttpd.yaml</summary> </details> <details><summary>test/new-e2e/tests/agent-health/fixtures/docker-compose.busybox.yaml</summary> </details> <details><summary>test/new-e2e/tests/discovery/testdata/compose/docker-compose.configfilesdiscovery-kafka.yaml</summary> </details> <details><summary>test/new-e2e/tests/discovery/testdata/compose/docker-compose.configfilesdiscovery-redis.yaml</summary> </details> <details><summary>test/new-e2e/tests/discovery/testdata/compose/docker-compose.fake-krakend.yaml</summary> </details> <details><summary>test/new-e2e/tests/fips-compliance/fixtures/docker-compose-cluster-agent.yaml</summary> </details> <details><summary>test/new-e2e/tests/fips-compliance/fixtures/docker-compose-fips-server.yaml</summary> </details> <details><summary>test/new-e2e/tests/fips-compliance/fixtures/docker-compose.yaml</summary> </details> </blockquote> </details> <details><summary>dockerfile (15)</summary> <blockquote> <details><summary>Dockerfiles/agent-ddot/Dockerfile</summary> </details> <details><summary>Dockerfiles/agent-ddot/Dockerfile.agent-otel (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/agent/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/agent/windows/amd64/Dockerfile (1)</summary> - `mcr.microsoft.com/dotnet/sdk 9.0-windowsservercore-ltsc2019` </details> <details><summary>Dockerfiles/base-image/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/cluster-agent/Dockerfile (2)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/ddot-ebpf/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/dogstatsd/alpine/Dockerfile (1)</summary> - `public.ecr.aws/docker/library/alpine 3.23.3` → [Updates: `3.24.1`] </details> <details><summary>Dockerfiles/otel-agent/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>test/e2e-framework/resources/local/podman/data/Dockerfile (1)</summary> - `docker.io/library/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>test/fakeintake/Dockerfile (2)</summary> - `docker.io/library/golang 1.26.5` - `docker.io/library/alpine 3.24.1` </details> <details><summary>tools/ebpf/Dockerfiles/Dockerfile-process-agent-dev</summary> </details> <details><summary>tools/ebpf/Dockerfiles/Dockerfile-security-agent-dev</summary> </details> <details><summary>tools/gdb/Dockerfile (1)</summary> - `registry.datadoghq.com/agent 7` </details> <details><summary>tools/host-profiler/Dockerfile</summary> </details> </blockquote> </details> <details><summary>github-actions (45)</summary> <blockquote> <details><summary>.github/actions/bazel-cache/action.yml (2)</summary> - `actions/cache v6.1.0@55cc8345863c7cc4c66a329aec7e433d2d1c52a9` - `actions/cache v6.1.0@55cc8345863c7cc4c66a329aec7e433d2d1c52a9` </details> <details><summary>.github/actions/deps-tidy-push/action.yml</summary> </details> <details><summary>.github/actions/deps-tidy-setup/action.yml (1)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` </details> <details><summary>.github/actions/install-dda/action.yml (3)</summary> - `actions/cache v6.1.0@55cc8345863c7cc4c66a329aec7e433d2d1c52a9` - `DataDog/datadog-agent-dev install@00e4a423088309efce1d5ba6b8c5366eef648710` - `DataDog/datadog-agent-dev install@00e4a423088309efce1d5ba6b8c5366eef648710` </details> <details><summary>.github/workflows/add-dependabot-pr-to-mq.yml (3)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/add-label-community-pr.yml (2)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/add-label-pr.yml (3)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/add-milestone.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/agenttelemetry-metric-reminder.yml (1)</summary> - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/ask-review.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/assess-permissions.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/assign-issue.yml (1)</summary> - `DataDog/issue-triage-action v1.0.1@b39f0bc12abc52fe8aa70dc9b9353bf307a13219` </details> <details><summary>.github/workflows/backport-pr.yml (4)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/buildimages-update.yml (5)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/chase-for-qa-cards.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/check-issue-status.yml (5)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/check-skip.yml</summary> </details> <details><summary>.github/workflows/cla.yml (2)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `contributor-assistant/github-action v2.6.1@ca4a40a7d1004f18d9960b404b97e5f30a505a08` </details> <details><summary>.github/workflows/code-review-complexity.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/code-review.yml (1)</summary> - `DataDog/code-review-action v1.1.0@56d6862711348b11ec2603edfb29c52c09f4b84c` </details> <details><summary>.github/workflows/codex-review-draft.yml (1)</summary> - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/codex-review-ready-for-review.yml</summary> </details> <details><summary>.github/workflows/collector-generate-and-update.yml (5)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `slackapi/slack-github-action v3.0.5@0d95c9a7becc1e6e297d76df9bc735c44f4cbcbc` → [Updates: `v4.0.0`] </details> <details><summary>.github/workflows/create-rc-pr.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/cws-btfhub-sync.yml (11)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `actions/upload-artifact v7.0.1@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `actions/download-artifact v8.0.1@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c` - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `ubuntu 24.04` - `ubuntu 24.04` </details> <details><summary>.github/workflows/deps-tidy.yml (7)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `dtolnay/rust-toolchain v1@e97e2d8cc328f1b50210efc529dca0028893a2d9` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `rust stable` </details> <details><summary>.github/workflows/do-not-merge.yml</summary> </details> <details><summary>.github/workflows/docs-dev.yml (8)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/upload-artifact v7.0.1@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a` - `actions/download-artifact v8.0.1@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c` - `peaceiris/actions-gh-pages v4.1.0@84c30a85c19949d7eee79c4ff27748b70285e453` </details> <details><summary>.github/workflows/go-update-commenter.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/gohai.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] </details> <details><summary>.github/workflows/label-analysis.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/labeler.yml (1)</summary> - `actions/labeler v6.2.0@b8dd2d9be0f68b860e7dae5dae7d772984eacd6d` → [Updates: `v7.0.0`] </details> <details><summary>.github/workflows/markdown-lint-check.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `tcort/github-action-markdown-link-check v1.1.2@e7c7a18363c842693fadde5d41a3bd3573a7a225` → [Updates: `v1.1.3`] </details> <details><summary>.github/workflows/push-bazel-cache.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/report-merged-pr.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `DataDog/dd-sts-action v1.0.0@2e8187910199bd93129520183c093e19aa585c75` → [Updates: `v1.0.5`] </details> <details><summary>.github/workflows/slapr_backport.yml (1)</summary> - `DataDog/slapr 1.1.0@95312d6b8528460243ba27c7f8167bfe20a68bec` </details> <details><summary>.github/workflows/slapr.yml (3)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `DataDog/slapr 1.1.0@95312d6b8528460243ba27c7f8167bfe20a68bec` </details> <details><summary>.github/workflows/stale.yml (2)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/stale v10.4.0@1e223db275d687790206a7acac4d1a11bd6fe629` → [Updates: `v11.0.0`] </details> <details><summary>.github/workflows/test-devcontainer.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-node v6.5.0@249970729cb0ef3589644e2896645e5dc5ba9c38` → [Updates: `v7.0.0`] </details> <details><summary>.github/workflows/update-dependencies.yml (4)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/update-ebpf-profiler-branch.yml (4)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/update-kubernetes-versions.yml (8)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-python v6.3.0@ece7cb06caefa5fff74198d8649806c4678c61a1` → [Updates: `v7.0.0`] - `helm/kind-action v1.14.0@ef37e7f390d99f746eb8b610417061a60e82a6cc` - `aws-actions/configure-aws-credentials v6.2.2@517a711dbcd0e402f90c77e7e2f81e849156e31d` → [Updates: `v6.2.3`] - `docker/login-action v4.4.0@af1e73f918a031802d376d3c8bbc3fe56130a9b0` → [Updates: `v4.6.0`] - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `python 3.14` </details> <details><summary>.github/workflows/upgrade-python-patch-version.yml (5)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-python v6.3.0@ece7cb06caefa5fff74198d8649806c4678c61a1` → [Updates: `v7.0.0`] - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `python 3.14` </details> <details><summary>.github/workflows/validate-renovate-deps.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/warn-failed-dependabot-pr.yml</summary> </details> </blockquote> </details> <details><summary>gomod (80)</summary> <blockquote> <details><summary>comp/anomalydetection/observer/def/go.mod</summary> </details> <details><summary>comp/anomalydetection/recorder/def/go.mod</summary> </details> <details><summary>comp/anomalydetection/severityevents/def/go.mod</summary> </details> <details><summary>comp/api/api/def/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/agenttelemetry/def/go.mod</summary> </details> <details><summary>comp/core/agenttelemetry/fx/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/agenttelemetry/impl/go.mod (7)</summary> - `github.com/DataDog/zstd v1.5.8-0.20260421145859-31a7e515a571@31a7e515a571` → [Updates: `v1.5.8-0.20260421145859-31a7e515a571`] - `github.com/prometheus/client_model v0.6.2` - `github.com/robfig/cron/v3 v3.0.1` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/core/config/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/configstreamconsumer/def/go.mod</summary> </details> <details><summary>comp/core/configsync/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/delegatedauth/api/cloudauth/aws/go.mod (2)</summary> - `github.com/aws/aws-sdk-go-v2 v1.43.3` → [Updates: `v1.43.4`] - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/delegatedauth/go.mod (2)</summary> - `github.com/cenkalti/backoff/v7 v7.0.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/flare/builder/go.mod</summary> </details> <details><summary>comp/core/flare/types/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/hostname/hostnameinterface/def/go.mod</summary> </details> <details><summary>comp/core/hostname/hostnameinterface/go.mod</summary> </details> <details><summary>comp/core/hostname/hostnameinterface/mock/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/ipc/def/go.mod</summary> </details> <details><summary>comp/core/ipc/httphelpers/go.mod (2)</summary> - `github.com/mdlayher/vsock v1.3.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/ipc/impl/go.mod (2)</summary> - `github.com/gofrs/flock v0.13.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/ipc/mock/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/def/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/fx/go.mod</summary> </details> <details><summary>comp/core/log/impl-trace/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/impl/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/mock/go.mod</summary> </details> <details><summary>comp/core/secrets/def/go.mod</summary> </details> <details><summary>comp/core/secrets/fx/go.mod</summary> </details> <details><summary>comp/core/secrets/impl/go.mod (4)</summary> - `github.com/benbjohnson/clock v1.3.5` - `github.com/json-iterator/go v1.1.12` - `github.com/stretchr/testify v1.11.1` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/secrets/mock/go.mod (1)</summary> - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/secrets/noop-impl/go.mod</summary> </details> <details><summary>comp/core/secrets/utils/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/status/go.mod (4)</summary> - `github.com/dustin/go-humanize v1.0.1` - `github.com/fatih/color v1.19.0` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/status/statusimpl/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/tagger/def/go.mod</summary> </details> <details><summary>comp/core/tagger/fx-remote/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/tagger/generic_store/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/impl-remote/go.mod (5)</summary> - `github.com/cenkalti/backoff/v7 v7.0.0` - `github.com/google/uuid v1.6.0` - `github.com/mdlayher/vsock v1.3.0` - `github.com/stretchr/testify v1.11.1` - `google.golang.org/grpc v1.83.0` </details> <details><summary>comp/core/tagger/origindetection/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/subscriber/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/tags/go.mod</summary> </details> <details><summary>comp/core/tagger/telemetry/go.mod</summary> </details> <details><summary>comp/core/tagger/types/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/utils/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/telemetry/go.mod (6)</summary> - `github.com/prometheus/client_golang v1.24.1` - `github.com/prometheus/client_model v0.6.2` - `github.com/prometheus/common v0.70.1` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/def/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/forwarder/defaultforwarder/go.mod (6)</summary> - `github.com/benbjohnson/clock v1.3.5` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.uber.org/fx v1.24.0` - `go.uber.org/multierr v1.11.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/forwarder/orchestrator/orchestratorinterface/go.mod</summary> </details> <details><summary>comp/host-profiler/symboluploader/testdata/go.mod</summary> </details> <details><summary>comp/logs-library/go.mod (4)</summary> - `github.com/DataDog/agent-payload/v5 v5.0.209` - `github.com/benbjohnson/clock v1.3.5` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` </details> <details><summary>comp/logs/agent/config/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.yaml.in/yaml/v3 v3.0.5` </details> <details><summary>comp/netflow/payload/go.mod</summary> </details> <details><summary>comp/otelcol/collector-contrib/def/go.mod</summary> </details> <details><summary>comp/otelcol/collector-contrib/impl/go.mod</summary> </details> <details><summary>comp/otelcol/converter/def/go.mod</summary> </details> <details><summary>comp/otelcol/converter/impl/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/ddflareextension/def/go.mod</summary> </details> <details><summary>comp/otelcol/ddflareextension/impl/go.mod (6)</summary> - `github.com/google/go-cmp v0.7.0` - `github.com/google/uuid v1.6.0` - `github.com/mohae/deepcopy v0.0.0-20170929034955-c48cc78d4826@c48cc78d4826` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/otelcol/ddflareextension/types/go.mod</summary> </details> <details><summary>comp/otelcol/ddprofilingextension/def/go.mod</summary> </details> <details><summary>comp/otelcol/ddprofilingextension/impl/go.mod (3)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/DataDog/dd-trace-go/v2 v2.9.0` → [Updates: `v2.9.1`] - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/otelcol/logsagentpipeline/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/logsagentpipeline/logsagentpipelineimpl/go.mod</summary> </details> <details><summary>comp/otelcol/otlp/components/connector/datadogconnector/go.mod (5)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/google/go-cmp v0.7.0` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/otelcol/otlp/components/datadogconfig/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/otlp/components/exporter/datadogexporter/go.mod (4)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/otelcol/otlp/components/exporter/logsagentexporter/go.mod (4)</summary> - `github.com/DataDog/agent-payload/v5 v5.0.209` - `github.com/patrickmn/go-cache v2.1.0+incompatible` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/otlp/components/exporter/serializerexporter/go.mod (8)</summary> - `github.com/google/go-cmp v0.7.0` - `github.com/stretchr/testify v1.11.1` - `github.com/tinylib/msgp v1.6.4` - `go.uber.org/fx v1.24.0` - `go.uber.org/multierr v1.11.0` - `go.uber.org/zap v1.28.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] - `go.uber.org/atomic v1.11.0` </details> <details><summary>comp/otelcol/otlp/components/metricsclient/go.mod (2)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/otelcol/otlp/components/processor/infraattributesprocessor/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/otlp/testutil/go.mod (3)</summary> - `github.com/DataDog/sketches-go v1.4.8` - `github.com/stretchr/testify v1.11.1` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/otelcol/status/def/go.mod</summary> </details> <details><summary>comp/otelcol/status/impl/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.yaml.in/yaml/v3 v3.0.5` </details> <details><summary>comp/serializer/logscompression/go.mod</summary> </details> <details><summary>comp/serializer/metricscompression/go.mod</summary> </details> <details><summary>comp/trace/agent/def/go.mod</summary> </details> <details><summary>comp/trace/compression/def/go.mod</summary> </details> <details><summary>comp/trace/compression/impl-gzip/go.mod</summary> </details> <details><summary>comp/trace/compression/impl-zstd/go.mod (1)</summary> - `github.com/DataDog/zstd v1.5.8-0.20260421145859-31a7e515a571@31a7e515a571` → [Updates: `v1.5.8-0.20260421145859-31a7e515a571`] </details> <details><summary>go.mod (87)</summary> - `code.cloudfoundry.org/bbs v1.3.0` → [Updates: `v1.11.0`] - `code.cloudfoundry.org/bbs/models v0.0.0-20260618205254-dc4b9f8d5bc9@dc4b9f8d5bc9` → [Updates: `v1.8.0`] - `code.cloudfoundry.org/garden v0.0.0-20260617020226-a9e754564bb5@a9e754564bb5` → [Updates: `v0.0.0-20260811183727-158508cf0d71`] - `code.cloudfoundry.org/lager/v3 v3.78.0` → [Updates: `v3.81.0`] - `dario.cat/mergo v1.0.2` - `github.com/Azure/azure-sdk-for-go/sdk/azcore v1.22.0` → [Updates: `v1.23.0`] - `github.com/Azure/azure-sdk-for-go/sdk/azidentity v1.14.0` - `github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/azsecrets v1.5.0` - `github.com/CycloneDX/cyclonedx-go v0.11.0` - `github.com/DATA-DOG/go-sqlmock v1.5.2` - `github.com/DataDog/agent-payload/v5 v5.0.209` - `github.com/DataDog/datadog-api-client-go/v2 v2.62.0` → [Updates: `v2.64.0`] - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/DataDog/datadog-operator/api v0.0.0-20260807013103-1518bb55e423@1518bb55e423` → [Updates: `v0.0.0-20260812212652-5f8a87676244`] - `github.com/DataDog/datadog-traceroute v1.0.19` - `github.com/DataDog/dd-policy-engine/go v0.0.0-20260730181922-c5e419a4ec7d@c5e419a4ec7d` → [Updates: `v0.0.0-20260803230307-dd41045a4bb2`] - `github.com/DataDog/dd-trace-go/v2 v2.9.0` → [Updates: `v2.9.1`] - `github.com/DataDog/ddtrivy v0.0.0-20260519164847-bf6bcaf2f9b7@bf6bcaf2f9b7` → [Updates: `v0.0.0-20260519164847-bf6bcaf2f9b7`] - `github.com/DataDog/ebpf-manager v0.8.1` - `github.com/DataDog/go-acl v1.0.1` - `github.com/DataDog/go-sqllexer v0.2.4` - `github.com/DataDog/jsonapi v0.13.0` - `github.com/DataDog/rshell v0.0.24` - `github.com/DataDog/sketches-go v1.4.8` - `github.com/DataDog/watermarkpodautoscaler/apis v0.0.0-20250108152814-82e58d0231d1@82e58d0231d1` → [Updates: `v0.0.0-20260803084540-a82e1114b53b`] - `github.com/DataDog/zstd v1.5.8-0.20260421145859-31a7e515a571@31a7e515a571` → [Updates: `v1.5.8-0.20260421145859-31a7e515a571`] - `github.com/Masterminds/semver/v3 v3.5.0` - `github.com/Masterminds/sprig/v3 v3.3.0` - `github.com/Microsoft/go-winio v0.6.2` - `github.com/Microsoft/hcsshim v0.14.1` - `github.com/NVIDIA/go-nvml v0.13.1-0` - `github.com/ProtonMail/go-crypto v1.4.1` - `github.com/acobaugh/osrelease v0.1.0` - `github.com/alecthomas/units v0.0.0-20240927000941-0f3dac36c52b@0f3dac36c52b` - `github.com/aptly-dev/aptly v1.6.3` - `github.com/aquasecurity/trivy v0.72.0` → [Updates: `v0.73.0`] - `github.com/aquasecurity/trivy-db v0.0.0-20251222105351-a833f47f8f0d@a833f47f8f0d` → [Updates: `v0.0.0-20260813095258-0e0340a01b57`] - `github.com/aws/aws-sdk-go-v2 v1.43.3` → [Updates: `v1.43.4`] - `github.com/aws/aws-sdk-go-v2/config v1.32.34` → [Updates: `v1.32.35`] - `github.com/aws/aws-sdk-go-v2/credentials v1.19.33` → [Updates: `v1.19.34`] - `github.com/aws/aws-sdk-go-v2/service/ec2 v1.318.1` → [Updates: `v1.319.1`] - `github.com/aws/aws-sdk-go-v2/service/rds v1.120.1` → [Updates: `v1.124.1`] - `github.com/aws/aws-sdk-go-v2/service/secretsmanager v1.44.0` → [Updates: `v1.44.4`] - `github.com/aws/aws-sdk-go-v2/service/ssm v1.73.0` → [Updates: `v1.73.4`] - `github.com/aws/aws-sdk-go-v2/service/sts v1.45.3` → [Updates: `v1.45.4`] - `github.com/aws/karpenter-provider-aws v1.9.0` → [Updates: `v1.14.0`] - `github.com/aymerick/raymond v2.0.2+incompatible` - `github.com/bazelbuild/rules_go v0.61.1` → [Updates: `v0.62.0`] - `github.com/beevik/ntp v1.5.0` - `github.com/benbjohnson/clock v1.3.5` - `github.com/bhmj/jsonslice v1.1.3` - `github.com/blabber/go-freebsd-sysctl v0.0.0-20201130114544-503969f39d8f@503969f39d8f` - `github.com/bmatcuk/doublestar/v4 v4.10.0` - `github.com/cenkalti/backoff/v7 v7.0.0` - `github.com/cespare/xxhash/v2 v2.3.0` - `github.com/cilium/ebpf v0.22.0` - `github.com/clbanning/mxj/v2 v2.7.0` - `github.com/cloudflare/cbpfc v0.0.0-20260219140841-0661ad29132c@0661ad29132c` → [Updates: `v0.0.0-20260805072904-7ac485fd93e1`] - `github.com/cloudfoundry-community/go-cfclient/v2 v2.0.1-0.20230503155151-3d15366c5820@3d15366c5820` → [Updates: `v3.0.0-beta.1`] - `github.com/containerd/cgroups/v3 v3.1.3` - `github.com/containerd/containerd/api v1.11.1` - `github.com/containerd/containerd/v2 v2.2.5` → [Updates: `v2.3.3`] - `github.com/containerd/errdefs v1.0.0` - `github.com/containerd/typeurl/v2 v2.3.0` - `github.com/containernetworking/cni v1.3.0` - `github.com/coreos/go-semver v0.3.1` - `github.com/coreos/go-systemd/v22 v22.7.0` - `github.com/creack/pty v1.1.24` - `github.com/cri-o/ocicni v0.5.0` - `github.com/cyphar/filepath-securejoin v0.7.0` - `github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc@d8f796af33cc` - `github.com/distribution/reference v0.6.0` - `github.com/dustin/go-humanize v1.0.1` - `github.com/elastic/go-freelru v0.16.0` - `github.com/elastic/go-libaudit/v2 v2.6.2` - `github.com/elastic/go-seccomp-bpf v1.6.0` - `github.com/envoyproxy/gateway v1.7.4` → [Updates: `v1.8.3`] - `github.com/evanphx/json-patch/v5 v5.9.11` - `github.com/fatih/color v1.19.0` - `github.com/fatih/structtag v1.2.0` - `github.com/freddierice/go-losetup v0.0.0-20220711213114-2a14873012db@2a14873012db` - `github.com/ghodss/yaml v1.0.1-0.20220118164431-d8423dcdf344@d8423dcdf344` - `github.com/glaslos/ssdeep v1.0.0` - `github.com/go-delve/delve v1.27.0` → [Updates: `v1.27.1`] - `github.com/go-jose/go-jose/v4 v4.1.4` - `github.com/go-json-experiment/json v0.0.0-20250517221953-25912455fbc8@25912455fbc8` → [Updates: `v0.0.0-20260623181947-01eb4420fa68`] - `github.com/go-ole/go-ole v1.3.0` </details> </blockquote> </details> --- - [ ] <!-- manual job -->Check this box to trigger a request for Renovate to run again on this repository",
          "url": "https://github.com/DataDog/datadog-agent/issues/33469",
          "createdAt": "2025-01-28T12:05:52Z",
          "updatedAt": "2026-08-13T17:42:43Z",
          "timestamp": "2026-08-13T17:42:43Z",
          "metrics": {
            "reactions": 0,
            "comments": 0
          },
          "labels": [
            "team/agent-devx",
            "pending",
            "oss/0"
          ],
          "author": "renovate[bot]",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:191b3dba57220b6d3d99",
        "signalId": "github:DataDog/datadog-agent:pull_request:54842",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "text",
          "updatedAt",
          "metrics",
          "labels"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54842",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CONTP-2006] feat(ddi): Add pod workload target resolution",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds a registry and owner-chain resolver for DatadogInstrumentation workload targets. - Models built-in and customer-configured workload profiles using a `target` resource and optional `via` resources. - Identifies every resource by `apiVersion`, kind, and plural resource name. - Walks controller owner references with the dynamic Kubernetes client, validates owner UIDs, caches resolved owners, and limits traversal depth. This PR only introduces the resolver package. It does not expose or activate custom workload target configuration. ### Motivation [CONTP-2006](https://datadoghq.atlassian.net/browse/CONTP-2006) Hard-coding every operator-managed workload does not scale and cannot represent indirect ownership such as Pod to Job to a custom workload. Explicit target and traversal profiles provide a general mechanism that distinguishes API groups and allows deployments to grant read access only to the intermediate resources required for resolution. ### Describe how you validated your changes ### Additional Notes [CONTP-2006]: https://datadoghq.atlassian.net/browse/CONTP-2006?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54842",
          "createdAt": "2026-08-13T15:51:31Z",
          "updatedAt": "2026-08-13T17:43:18Z",
          "timestamp": "2026-08-13T17:43:18Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "team/container-platform",
            "medium review",
            "team/agent-build",
            "internal"
          ],
          "author": "Mathew-Estafanous",
          "state": "open",
          "assignees": [
            "Mathew-Estafanous"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:7d2f3789cbe5f5b5bd37",
        "signalId": "github:DataDog/datadog-agent:pull_request:54828",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54828",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[EBPF] gpu: add NVLink capability tag",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds `gpu_nvlink_capable` and `gpu_nvlink_version` tags to GPU metrics. ### Motivation Knowing whether a GPU is NVlink-capable and the version of the NVlink system or not is useful to ensure the presence of certain metrics and to compare GPU performance. Another PR will also use part of this code to allow segmenting telemetry based on NVLink capability. ### Describe how you validated your changes Unit tests, manually validated in nvlink-enabled instance. ### Additional Notes Both tags might be slightly redundant but having two doesn't cost extra cardinality (gpu_uuid is already there, with one value per GPU) and it allows separating \"nvlink GPUs/non nvlink GPUs\" and between specific versions.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54828",
          "createdAt": "2026-08-13T11:52:04Z",
          "updatedAt": "2026-08-13T17:42:38Z",
          "timestamp": "2026-08-13T17:42:38Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "team/ebpf-platform",
            "qa/done",
            "team/container-platform",
            "long review",
            "team/container-integrations",
            "internal",
            "team/gpu-monitoring-agent"
          ],
          "author": "gjulianm",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:269fe1583f9e56fb2baf",
        "signalId": "github:DataDog/datadog-agent:pull_request:54847",
        "event": "discovered",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54847",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[Backport 7.83.x]  [EBPF] gpu: Support ARM64 NVML library discovery",
          "text": "Backport 5dcbd3081dd283e30cf25879eb5be7b55577e50a from #54720. ___ <!-- dd-meta {\"pullId\":\"df13230b-a434-451b-972e-ac9007c02168\",\"source\":\"chat\",\"resourceId\":\"86800824-17f2-4a85-9551-be5b7bf8a830\",\"workflowId\":\"2ce581a4-a03e-4c0a-a1a1-dda5b27f5a0c\",\"codeChangeId\":\"2ce581a4-a03e-4c0a-a1a1-dda5b27f5a0c\",\"sourceType\":\"bits_ai_sre\"} --> ### What does this PR do? Bits AI SRE Investigation • [View in Bits AI SRE Investigation](https://ddstaging.datadoghq.com/bits-ai/investigations/8418dc69-efd2-44d3-ad70-91e14223f69d) Add standard ARM64 (`aarch64-linux-gnu`) NVML library paths for host and NVIDIA GPU Operator installations. ### Motivation GPU checks on ARM64 GPU nodes fail because NVML discovery searches only x86_64 library directories. This causes all GPU metrics to fail on affected ARM64 nodes and can trigger incorrect health responses. ### Describe how you validated your changes Unit tests added ### Additional Notes --- PR by Bits - [View session in Datadog](https://ddstaging.datadoghq.com/code/86800824-17f2-4a85-9551-be5b7bf8a830) Comment @datadog to request changes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54847",
          "createdAt": "2026-08-13T16:30:11Z",
          "updatedAt": "2026-08-13T17:42:07Z",
          "timestamp": "2026-08-13T17:42:07Z",
          "metrics": {
            "reactions": 2,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "team/ebpf-platform",
            "qa/done",
            "backport",
            "bot",
            "team/container-platform",
            "medium review",
            "team/container-integrations",
            "Bits AI",
            "internal",
            "team/gpu-monitoring-agent",
            "team/fleet-automation"
          ],
          "author": "dd-octo-sts[bot]",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:69a9ac89eae69a11a627",
        "signalId": "github:DataDog/datadog-agent:pull_request:53030",
        "event": "discovered",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53030",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(serverless-init): add shared infrastructure for AWS MicroVM cloud service",
          "text": "### What does this PR do? Adds the shared Go infrastructure that AWS MicroVM cloud-service support depends on. This is the first in a stack of PRs that together deliver full MicroVM observability. ### Motivation The Datadog Agent's serverless-init supports multiple cloud platforms (Cloud Run, Container Apps, etc.) via a `CloudService` abstraction. AWS Lambda MicroVMs are a new deployment target where the Agent runs as an init process inside a Firecracker microVM. Each new platform requires small additions in a few central places before the platform-specific code can be wired in cleanly. This PR makes those additions in isolation so the platform-specific MicroVM PR is a clean diff: - **`pkg/metrics/metricsource.go`** — adds `MetricSourceAWSMicroVMEnhanced`, the metric source tag used on all MicroVM enhanced metrics. - **`pkg/serverless/env/env.go`** — adds `MicroVMImageARNEnvVar` (`AWS_LAMBDA_MICROVM_IMAGE_ARN`), the env var the platform injects with the image ARN. - **`pkg/serializer/internal/metrics/origin_mapping.go`** — maps the new MetricSource to its origin string so metrics are routed correctly in the serializer. - **`comp/dogstatsd/server/impl/default_serverless.go` + `enrich.go`** — threads MicroVM origin/tag enrichment through DogStatsD's serverless path. - **`comp/logs-library/processor/json_serverless_init.go`** — adds a JSON log encoder for structured serverless-init logs, needed for MicroVM's log pipeline. ### Describe how you validated your changes - New unit tests cover the origin mapping and DogStatsD enrichment paths. - All changes are additive; no existing behaviour is altered. Run the unit tests for the packages touched by this PR: ``` dda inv test --targets=./comp/dogstatsd/server/impl,./comp/logs-library/processor,./pkg/metrics,./pkg/serializer/internal/metrics,./pkg/serverless/env ``` ### Additional Notes **PR stack** (each PR bases on the one above): 1. **This PR** — shared infrastructure 2. `microvm-02-cloudservice-run` — `Run()` method on `CloudService` interface 3. `microvm-03-lifecycle-config-childhandle` — lifecycle package primitives 4. `microvm-04-lifecycle-forwarder` — HTTP pass-through proxy 5. `microvm-05-lifecycle-heartbeat` — periodic heartbeat metric 6. `microvm-06-lifecycle-server-wire` — lifecycle HTTP server 7. `microvm-07-microvm-service-wiring` — MicroVM `CloudService` + main wiring 8. `microvm-08-sigusr2-on-run` — SIGUSR2 on `/run` for PRNG reseeding",
          "url": "https://github.com/DataDog/datadog-agent/pull/53030",
          "createdAt": "2026-06-30T21:34:33Z",
          "updatedAt": "2026-08-13T17:41:59Z",
          "timestamp": "2026-08-13T17:41:59Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "long review",
            "qa/rc-required",
            "team/agent-integrations",
            "team/agent-log-pipelines",
            "team/agent-metric-pipelines",
            "team/agent-devx",
            "team/agent-build",
            "internal",
            "aws-microvm"
          ],
          "author": "litianningdatadog",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:2823ad6dd6b191d0ddfe",
        "signalId": "github:DataDog/datadog-agent:pull_request:54834",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54834",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "ci: default GitLab jobs to shallow clones, keep full history where needed",
          "text": "## Summary - Default GitLab jobs to `GIT_DEPTH: 1` so most checkouts are a shallow clone of HEAD only. - Set `GIT_DEPTH: 0` on jobs that actually need git history (merge-base, ancestor walks, `git describe`, `git log` ranges, three-dot diffs, or checkout of another branch). - Jobs that inherit a full-history template but never use merge-base stay at depth 1 (`new-e2e-unit-tests`, upgrade/RPM install-package jobs). - `GIT_STRATEGY: clone` is not a full clone; clone with depth 1 is still shallow. Full history requires `GIT_DEPTH: 0`. Supersedes https://github.com/DataDog/datadog-agent/pull/54799 (opened from a fork). ## Test plan - [ ] Confirm a typical build/lint job clones with depth 1 and still has the working tree. - [ ] Confirm jobs that compute merge-base still succeed (`golang_deps_diff`, e2e `--impacted`, `static_quality_gates`, `files_inventory_check`, SMP merge-base check). - [ ] Confirm `setup_agent_version` can still run `git describe --tags`. - [ ] Confirm unit-test jobs with `FAST_TESTS=true` still detect impacted packages. - [ ] Confirm `benchmark` can check out `BASE_BRANCH` and `prebuild-workspace-image-check` can three-dot diff against `COMPARE_TO_BRANCH`. Made with [Cursor](https://cursor.com)",
          "url": "https://github.com/DataDog/datadog-agent/pull/54834",
          "createdAt": "2026-08-13T14:03:09Z",
          "updatedAt": "2026-08-13T17:41:34Z",
          "timestamp": "2026-08-13T17:41:34Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "team/agent-apm",
            "team/agent-security",
            "team/ebpf-platform",
            "qa/no-code-change",
            "team/container-platform",
            "team/agent-delivery",
            "long review",
            "team/agent-integrations",
            "team/container-integrations",
            "team/agent-devx",
            "team/agent-build",
            "team/windows-products",
            "team/profiling-full-host",
            "internal"
          ],
          "author": "mikesherovdd",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:61c18a99c34b390ce31c",
        "signalId": "github:DataDog/datadog-agent:pull_request:53033",
        "event": "discovered",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53033",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(serverless-init): add MicroVM lifecycle HTTP forwarder",
          "text": "### What does this PR do? Adds `lifecycle/forwarder.go`: an HTTP proxy that passes MicroVM lifecycle hooks (`/ready`, `/validate`, `/run`, `/resume`, `/suspend`, `/terminate`) from the platform through to the user application, when `DD_AWS_MICROVM_USER_APP_PORT` is set. Key behaviours: - Mirrors status code, response body (up to 1 MiB), and `Content-Type` back to the platform so the platform sees the user app's response, not the agent's. - Does not follow redirects returned by the user app — a 3xx is mirrored back as-is instead of being silently followed, which would otherwise replay a POST as a GET (dropping the body) and report the redirect target's response instead of the hook's own. - `/ready` and `/validate` perform a TCP dial-wait before forwarding: the forwarder retries until the user app's port is reachable or the timeout expires. This absorbs the race between the platform's first `/ready` and the user app's TCP listener coming up. - `/run`, `/resume`, `/suspend`, `/terminate` forward with a short deadline (`DD_AWS_MICROVM_FORWARD_TIMEOUT_MS`, default 1 s), which is appropriate since these are informational hooks with tight platform deadlines. Also lowers `DefaultHeartbeatInterval` from 5 minutes to 10 seconds, per review feedback: relying on a steady multi-minute submission for billing is risky since a missed or double-submitted point has outsized impact. Emitting more frequently and deduping downstream is safer. ### Motivation By default the agent handles all lifecycle hooks autonomously — it answers `/ready` based on child-process liveness, emits metrics, flushes telemetry, and so on. But some user applications also need to react to lifecycle events (e.g. warm their own caches on `/run`, checkpoint state on `/suspend`). The forwarder enables this opt-in pass-through mode: the agent does its own work _and_ lets the user app participate in each hook. The TCP dial-wait on `/ready` and `/validate` is especially important: the platform sends `/ready` as soon as the VM boots, which is often before the user app has had time to bind its port. ### Describe how you validated your changes - `forwarder_test.go` covers: mirror of status/body/headers, TCP wait-for-port logic, dial-error → 503, deadline → 504, body truncation, the sidecar-mode guard, and that redirects from the user app are mirrored rather than followed. Run the relevant unit tests locally: ``` dda inv test --targets=./cmd/serverless-init/lifecycle ``` ### Additional Notes **PR stack** — this is PR 4/8: 1. `microvm-01-foundation` — shared infrastructure ✓ 2. `microvm-02-cloudservice-run` — `Run()` on `CloudService` ✓ 3. `microvm-03-lifecycle-config-childhandle` — lifecycle config + child-handle ✓ 4. **This PR** — HTTP pass-through forwarder 5. `microvm-05-lifecycle-heartbeat` — periodic heartbeat metric 6. `microvm-06-lifecycle-server-wire` — lifecycle HTTP server 7. `microvm-07-microvm-service-wiring` — MicroVM `CloudService` + main wiring 8. `microvm-08-sigusr2-on-run` — SIGUSR2 on `/run`",
          "url": "https://github.com/DataDog/datadog-agent/pull/53033",
          "createdAt": "2026-06-30T21:36:15Z",
          "updatedAt": "2026-08-13T17:41:06Z",
          "timestamp": "2026-08-13T17:41:06Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "long review",
            "aws-microvm"
          ],
          "author": "litianningdatadog",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:6b662e367b007323a76d",
        "signalId": "github:DataDog/datadog-agent:pull_request:54815",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt",
          "state"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54815",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[DSEC] Move dd-sds dependency to shared workspace",
          "text": "### What does this PR do? Moves the `dd-sds` (`dd-sensitive-data-scanner`) dependency from the `datasecurity` check crate into the shared `[workspace.dependencies]` in the root `Cargo.toml`. The crate now references it via `dd_sds.workspace = true`. ### Motivation Centralize the pinned version and feature set so future check crates share a single source of truth instead of duplicating the spec. ### Tests Use docker image registry.ddbuild.io/ci/datadog-agent/agent:v130685756-40c89d95-7-amd64 generated in the CI and confirmed that data security check is correctly running. ```bash dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/aggregator/aggregator.go:182 in LogMsg) | datasecurity: sub task succeeded (1 match(es)) dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/aggregator/aggregator.go:182 in LogMsg) | datasecurity: running sub task (sub_task_id=455ECD24-5C11-45AA-801B-5C2C43C8533C, platform=postgres) dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (comp/core/agenttelemetry/impl/agenttelemetry.go:665 in run) | Starting agent telemetry run dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/aggregator/aggregator.go:182 in LogMsg) | datasecurity: sub task succeeded (1 match(es)) dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/aggregator/aggregator.go:182 in LogMsg) | datasecurity: check completed dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/worker/check_logger.go:59 in CheckFinished) | check:datasecurity | Done running check dsec-perf-agent-dsec | 2026-08-13 12:20:42 UTC | CORE | INFO | (pkg/collector/worker/check_logger.go:65 in CheckFinished) | check:datasecurity | Check's one time execution has finished ```",
          "url": "https://github.com/DataDog/datadog-agent/pull/54815",
          "createdAt": "2026-08-13T10:12:22Z",
          "updatedAt": "2026-08-13T17:40:40Z",
          "timestamp": "2026-08-13T17:40:40Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "short review",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "aimenebelfodil",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:6337d50d3bb8f847558c",
        "signalId": "github:DataDog/datadog-agent:pull_request:54793",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54793",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Remove schemaBuilder and createschema command",
          "text": "### What does this PR do? Remove the `createschema` command and the schema builder config implementation. We no longer need to generate the schema. ### Motivation Cleanup now that schema is live and in use. ### Describe how you validated your changes CI ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54793",
          "createdAt": "2026-08-12T18:13:12Z",
          "updatedAt": "2026-08-13T17:38:20Z",
          "timestamp": "2026-08-13T17:38:20Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-build",
            "internal",
            "team/fleet-remediation",
            "team/fleet-automation"
          ],
          "author": "dustmop",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:bfa77fdde7c5bca4e5d1",
        "signalId": "github:DataDog/datadog-agent:pull_request:54592",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54592",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] add par-control OPMS client",
          "text": "### What does this PR do? Adds the authenticated OPMS client used by `par-control`: - Signs requests with runner JWT authentication. - Dequeues workflow tasks. - Publishes terminal task outcomes. - Sends task heartbeats. - Performs runner health checks. - Matches the existing Go wire contracts, proxy behavior, TLS settings, and retry pacing. The implementation and its HTTP/TLS contract tests are kept together in this layer. ### Motivation Separate the remote OPMS protocol from local executor communication and from the orchestration policy that composes them. ### Validation - 46 portable Rust tests pass locally. - Three native-tls tests require Linux/Windows and do not run successfully with the macOS Security Framework backend. ### Stack PR 6 of 9. Based on #54591; followed by #54593.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54592",
          "createdAt": "2026-08-07T17:51:46Z",
          "updatedAt": "2026-08-13T17:38:20Z",
          "timestamp": "2026-08-13T17:38:20Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:9c1aa729f935b0fb10a5",
        "signalId": "github:DataDog/datadog-agent:pull_request:54593",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54593",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] orchestrate par-control tasks",
          "text": "### What does this PR do? Composes the process manager, effective configuration, OPMS client, and executor channel into the production `par-control` loop: - Adds bounded task concurrency and retry policy. - Leaves the executor stopped while idle and starts it only after a task is dequeued. - Starts task heartbeats at dequeue and continues them through executor cold start, key synchronization, execution, and terminal publication. - Sends runner liveness reports independently of task flow. - Lazily synchronizes and caches signing keys for later executor starts. - Stops the executor after the configured idle period and drains in-flight work during shutdown. - Wires the final binary and updates its documentation. - Restores Windows compatibility for the Rust Bazel test by staging the Agent OpenSSL DLLs in runfiles and placing that directory on the test process's `PATH`. ### Motivation Keep orchestration policy separate from the independently tested lifecycle and network primitives it coordinates. In particular, the control process should preserve an OPMS lease while paying the executor's cold-start cost and should not keep the higher-RSS Go process alive when no work is available. ### Validation - `dda env dev run -- bazel test //pkg/privateactionrunner/par-control:par-control_test` - `dda env dev run -- env -u PKG_CONFIG_LIBDIR cargo clippy --manifest-path pkg/privateactionrunner/par-control/Cargo.toml --all-targets -- -D warnings` - Buildifier passes. - Windows-target Bazel analysis confirms both OpenSSL DLLs are inputs to the staging action. - Full Windows Rust execution is delegated to Windows CI. ### Review fixes - **No startup prewarming**: the executor remains stopped until a task is leased. Signing keys are synchronized during the first cold start and cached for later starts. - **Lease protection during cold start**: task heartbeats begin immediately after dequeue and stop only after terminal publication, covering process startup, readiness, and key synchronization. - **Start race**: dd-procmgrd rejects `Start` for every state covered by `ProcessState::is_alive()` (`Starting`, `Running`, and `Stopping`). Those states and a lost `Start` race are now adopted instead of failing the task spuriously. - **Windows graceful shutdown**: `par-control` listens for `CTRL_BREAK`, which is the event dd-procmgrd sends to Windows children, so shutdown drains work instead of waiting for the process-manager timeout and job-object kill. - **Bounded process-manager calls**: dispatch-path `Describe` and `Start` RPCs have deadlines, allowing a leased task to fail and publish an outcome instead of hanging without heartbeats. - **Windows logging and defaults**: restores the program-data-root log path, `ExitCode`, and the platform-correct `--config` default. - **Clean executor exits**: idle self-termination from #54670 remains non-fatal, so `restart: on-failure` does not immediately respawn the executor. - Tests cover stopped-at-start behavior, heartbeat timing through cold start and publication, adoption of `Starting`/`Running`/`Stopping`, tolerated start races, RPC deadlines, idle stop, drain behavior, and vanished process definitions. ### Stack PR 7 of 9. Based on #54592; followed by #54594.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54593",
          "createdAt": "2026-08-07T17:53:19Z",
          "updatedAt": "2026-08-13T17:37:50Z",
          "timestamp": "2026-08-13T17:37:50Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:c6ca6319218f0645dcea",
        "signalId": "github:DataDog/datadog-agent:pull_request:54589",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "text",
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54589",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] add par-control process lifecycle",
          "text": "### What does this PR do? Adds the process-lifecycle boundary for `par-control`: - Uses the shared `dd-procmgr-client` connector for local IPC on Linux and Windows. - Loads the minimal configuration needed to gate split mode. - Exposes one-shot executor lifecycle operations to start or adopt the executor, inspect liveness and terminal state, and stop it. - Intentionally leaves the executor stopped during control-plane startup; the later orchestration layer invokes the lifecycle only after leasing a task rather than prewarming or continuously polling the executor. - Bounds process-manager RPCs and handles platform-specific shutdown, logging, and Windows `ConfigRoot` paths. - Tests the real generated gRPC client against an in-process fake `dd-procmgrd`. `par-control` and the executor are siblings owned by `dd-procmgrd`. A `Start` race that returns `FAILED_PRECONDITION` therefore adopts the already-alive executor. During its own shutdown, `par-control` does not call back into `dd-procmgrd`, which may already be waiting for it to exit. ### Validation - `dda env dev run -- bazel test //pkg/privateactionrunner/par-control:par-control_test` - `dda env dev run -- bazel build //pkg/privateactionrunner/par-control:par-control` - `dda env dev run -- env -u PKG_CONFIG_LIBDIR cargo clippy --manifest-path pkg/privateactionrunner/par-control/Cargo.toml --all-targets -- -D warnings`",
          "url": "https://github.com/DataDog/datadog-agent/pull/54589",
          "createdAt": "2026-08-07T17:44:51Z",
          "updatedAt": "2026-08-13T17:37:42Z",
          "timestamp": "2026-08-13T17:37:42Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:5957651b76c5091d1466",
        "signalId": "github:DataDog/datadog-agent:pull_request:54852",
        "event": "discovered",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54852",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[NTWK-812] Filter dynamic tests across all reverse-DNS names",
          "text": "What does this PR do? Fixes Network Path dynamic tests scheduling traceroutes against Datadog's own intake backends (e.g. l4-metrics-agent-*.elb.us-east-1.amazonaws.com) despite the default *.datadoghq.com connection-filter exclude. - Adds ConnFilter.EvaluateDomains(domains, ip), which evaluates every DNS name a destination IP reverse-resolves to (via the existing last-match-wins chain) instead of only the first. A connection is excluded if any of its names is excluded, and the returned hostname is the preferred name for the path test (an include-matched name, else the first included name). - Plumbs the full name list end-to-end: adds Domains []string to NetworkPathConnection, a getDNSNamesForIP helper in both connection builders (pkg/network/sender, pkg/process/checks), and wires npcollector to filter on it and use the selected hostname. - Adds l4-metrics-agent-*.elb.*.amazonaws.com to the default excludes as hardening for the case where only the ELB name is cached. Customer include filters still override the defaults, so Datadog domains can be re-enabled if desired. Motivation [NTWK-812 / ZD 2972181](https://datadoghq.atlassian.net/browse/NTWK-812). A destination IP for a Datadog intake endpoint reverse-resolves to more than one name: the queried *.datadoghq.com name and the AWS ELB hostname it's CNAME'd to (short A-record TTLs cause resolvers to re-query the ELB target directly). getDNSNameForIP collapsed that list to dnsEntry[0], so when the ELB name was selected first the *.datadoghq.com exclude never fired — nondeterministically, depending on cache ordering. For the reporting org this was ~37% of dynamic test runs (>3,000/day), which also drives unnecessary billing. Describe how you validated your changes - New unit tests in connfilter_test.go: - TestEvaluateDomains — the CNAME gap with both name orderings, ELB-name-only, unrelated names, the customer-include override case, and empty input. - TestEvaluateDomainsPrefersIncludeMatchedName — an RC-include-matched name is chosen as the path test hostname even when it isn't first. - Extended TestNewConnFilter with the intake-ELB default exclude (and a customer-ELB negative case). - dda inv test --targets=./comp/networkpath/npcollector/... ./pkg/process/checks/ — all networkpath + connection tests pass. (TestProcessDiscoveryCheck fails identically on main on this platform; unrelated and pre-existing.) Additional Notes - Behavior change worth a reviewer's eye: \"any excluded name → exclude the connection\" means if a customer excludes name A and the IP also resolves to a fine name B, the connection is now dropped. Intended (they asked to exclude that destination), but flagging it. - The l4-metrics-agent-* default only covers one intake family; with the multi-name fix it's a secondary safety net rather than the primary fix. If we want the other intake ELB prefixes as defaults, we'd need the authorie/networking team. - sender_linux.go / sender/dns.go are Linux-only and couldn't bemacOS (cgo cross-compile); their changes are a one-field additionplus a mirror of the existing getDNSNameForIP — relying on CI fold. Ran 1 shell command Commit a63bb24aa84 is ready on branch netpath-812-exclude-intake/-22). Push to origin/netpath-812-exclude-intake-elb-cnames? Once you confirm, I'll run git push origin netpath-812-exclude-intake-elb-cnames. Reminder before you decide: the two Linux-only files (sender_linux.go, sender/dns.go) couldn't be compiled locally (cgo cross-compile), so first CI on this branch is where they get a real build — worth watching that pipeline after the push. ✻ Brewed for 1m 2s ❯ confirmed Pushed to netpath-812-exclude-intake-elb-cnames Pushed successfully — branch netpath-812-exclude-intake-elb-cnames is now on origin (new branch, tracking set up earlier). Next steps you may want: - Open the PR: https://github.com/DataDog/datadog-agent/pull/new/netpath-812-exclude-intake-elb-cnames — I can do this via the create-pr skill (I'll flag the Linux-build/CI caveat and the \"any-excluded-name excludes ththe description). - Watch CI: this is where the two Linux-only files get their first real compile. I can follow the pipeline with the follow-pr skill once a PR exists. - Update NTWK-812: post a triage-format update linking the branch/PR. Want me to open the PR? ✻ Baked for 26s ❯ Can you create a PR description for me that I can copy/paste? Let me pull the repo's PR template so the description matches wh Read 1 file Here's a copy/paste-ready PR description following the repo template: --- ### What does this PR do? Fixes Network Path dynamic tests scheduling traceroutes against Datadog's own intake backends (e.g. l4-metrics-agent-*.elb.us-east-1.amazonaws.com) despite the default *.datadoghq.com connection-filter exclude. - Adds ConnFilter.EvaluateDomains(domains, ip), which evaluates every DNS name a destination IP reverse-resolves to (via the existing last-match-wins chain) instead of only the first. A connection is excluded if any of its names is excluded, and the returned hostname is the preferred name for the path test (an include-matched name, else the first included name). - Plumbs the full name list end-to-end: adds Domains []string togetDNSNamesForIP helper in both connection builders(pkg/network/sender, pkg/process/checks), and wires npcollector to filter on it and use the selected hostname. - Adds l4-metrics-agent-*.elb.*.amazonaws.com to the default excludes as hardening for the case where only the ELB name is cached. Customer include filters still override the defaults, so Datadog if desired. ### Motivation NTWK-812 / ZD 2972181. A destination IP for a Datadog intake endmore than one name: the queried *.datadoghq.com name and the AWSELB hostname it's CNAME'd to (short A-record TTLs cause resolvers to re-query the ELB target directly). getDNSNameForIP collapsed that list to dnsEntry[0], so when the ELB name was selected first the *.datadoghq.com exclude never fired — nondeterministically, depending on cache ordering. For the reporting org this was ~37% of dynamic test runs (>3,000/day), which also drives unnecessary billing. Describe how you validated your changes - New unit tests in connfilter_test.go: - TestEvaluateDomains — the CNAME gap with both name orderings, ELB-name-only, unrelated names, the customer-include override case, and empty input. - TestEvaluateDomainsPrefersIncludeMatchedName — an RC-include-matched name is chosen as the path test hostname even when it isn't first. - Extended TestNewConnFilter with the intake-ELB default excluative case). - dda inv test --targets=./comp/networkpath/npcollector/... ./pkg/process/checks/ — all networkpath + connection tests pass. (TestProcessDiscoveryCheck fails identically on main on this platform; unrelated and pre-ex ### Additional Notes - Behavior change worth a reviewer's eye: \"any excluded name → ens if a customer excludes name A and the IP also resolves to afine name B, the connection is now dropped. Intended (they asked to exclude that destination), but flagging it. - The l4-metrics-agent-* default only covers one intake family; 's a secondary safety net rather than the primary fix. If we wantthe other intake ELB prefixes as defaults, we'd need the authoritative list from the intake/networking team. - sender_linux.go / sender/dns.go are Linux-only and couldn't bemacOS (cgo cross-compile); their changes are a one-field additionplus a mirror of the existing getDNSNameForIP — relying on CI for the first real Linux build.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54852",
          "createdAt": "2026-08-13T17:33:46Z",
          "updatedAt": "2026-08-13T17:37:25Z",
          "timestamp": "2026-08-13T17:37:25Z",
          "metrics": {
            "reactions": 1,
            "comments": 1
          },
          "labels": [
            "component/system-probe",
            "medium review",
            "team/cloud-network-monitoring",
            "team/network-path",
            "internal"
          ],
          "author": "ken-schneider",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:2eb5a02208bfe2ee2356",
        "signalId": "github:DataDog/datadog-agent:pull_request:54731",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt",
          "metrics"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54731",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[procmgr] Windows spawn profiles foundation",
          "text": "### What does this PR do? Introduces **Windows spawn profiles** in dd-procmgr so managed children can run under different security contexts: - **Privileged**: spawn as LocalSystem (supervisor primary token) - **AgentUser**: spawn as the agent service account (`ddagentuser`) Adds the Windows spawn stack (token logon, user profile load, supervision job, suspended `CreateProcessAsUserW`), COAT catalog enforcement for allowed profiles, and gRPC pipe caller authentication. **Stack context:** PR 1/4 split from [#53249](https://github.com/DataDog/datadog-agent/pull/53249). Config gates, secret backend resolution, and process-agent dual-mode integration land in follow-up PRs (`jose/procmgr-config-gates`, `jose/procmgr-secret-backend-gates`, `jose/procmgr-windows-process-agent`). This PR includes a **stub** `config_gate` module (gates always open) so the crate compiles until PR 2. ### Motivation Process-agent on Windows must run as LocalSystem and other agent children should stay on the agent user. Spawn profiles make that explicit and enforceable at spawn time, and are a prerequisite for moving process-agent supervision off legacy SCM in later PRs. ### Describe how you validated your changes - Windows procmgr Rust build/tests in CI - COAT unit tests (`pkg/procmgr/coat/...`) - Windows E2E: privileged spawn catalog enforcement (`test/new-e2e/tests/agent-runtimes/procmgr/...`) ### Additional Notes - No agent startup, fleet installer, or process-agent dual-mode changes in this PR. - [#53568](https://github.com/DataDog/datadog-agent/pull/53568) (list/describe profile + user) should rebase onto this branch once merged. - Supersedes the spawn/COAT portion of [#53249](https://github.com/DataDog/datadog-agent/pull/53249); that PR will be closed after the stack is open.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54731",
          "createdAt": "2026-08-11T15:45:26Z",
          "updatedAt": "2026-08-13T17:37:03Z",
          "timestamp": "2026-08-13T17:37:03Z",
          "metrics": {
            "reactions": 1,
            "comments": 30
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "jose-manuel-almaza",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:1236c902a787181c95a8",
        "signalId": "github:DataDog/datadog-agent:pull_request:54590",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54590",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] add par-control effective configuration",
          "text": "### What does this PR do? Adds the effective configuration and identity bootstrap layer for `par-control`: - Adds a Go helper subcommand that exports the Agent's resolved configuration. - Loads split-runner configuration from Rust. - Resolves local and Fleet-managed settings consistently. - Loads and persists runner identity. - Supports self-enrollment bootstrap. - Adds the required schema and setup wiring. Configuration production and consumption stay together in this PR so their contract can be reviewed as one behavior. ### Motivation Give the control process the same effective configuration as the Agent without duplicating configuration precedence or persisting a second plaintext configuration snapshot. ### Validation - Focused Go tests pass locally. - Portable Rust tests pass locally. - Relevant Go and Rust builds pass locally. ### Review fixes - **Process-manager socket**: falls back to dd-procmgrd's own `DD_PM_SOCKET_PATH` when `private_action_runner.procmgr_socket_path` is unset, before the platform default. Previously, relocating the daemon's socket also required setting a second, PAR-specific value. Resolution goes through the injected env lookup so it is testable without mutating process state, and an empty setting is treated as unset like the executor socket. - Carries the RPC deadlines, the `wait_for_failure` semantics, and the fake-daemon tests into the injected-socket `ProcmgrLifecycle` introduced here. - Same program-data-root log path, so the Windows log location no longer depends on where `--config` points. `platform.rs` also takes over the fleet-policies-dir registry lookup that was inline here. ### Stack PR 4 of 9. Based on #54589; followed by #54591.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54590",
          "createdAt": "2026-08-07T17:47:32Z",
          "updatedAt": "2026-08-13T17:36:53Z",
          "timestamp": "2026-08-13T17:36:53Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "team/action-platform",
            "internal",
            "team/fleet-automation"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:0c9e5b7a94566c6acf3b",
        "signalId": "github:DataDog/datadog-agent:pull_request:54594",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54594",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] wire split runner ownership",
          "text": "### What does this PR do? Teaches the existing Go runner and Fx component to stand down when split mode is enabled on supported Linux and Windows host deployments, while retaining the executor subcommand used by `par-control`. Container deployments do not yet launch the replacement topology. Official Agent containers are detected through `configenv.IsContainerized()` (`DOCKER_DD_AGENT`), so a requested split deployment logs a warning and safely continues with the monolithic runner instead of black-holing PAR. Cluster Agent continues to use its existing in-process monolithic path. The resulting ownership invariant is explicit: exactly one process polls OPMS, and the monolith exits only when its replacement topology is available. ### Motivation Keep runner ownership and activation behavior separate from package and installer mechanics so reviewers can focus on preventing both duplicate polling and unsupported deployments standing down their only runner. ### Validation - `bazel test //comp/privateactionrunner/impl:impl_test` passes locally. - Focused coverage includes Linux and Windows hosts, Linux and Windows containers, and an unsupported host platform. - Private Action Runner build passes locally. ### Review fixes - Documented `idle_timeout_seconds`, which now drives two mechanisms: par-control stops an idle executor after this long, and the executor exits by itself after a longer multiple, which is what reclaims it when par-control is no longer running. - Documented that `procmgr_socket_path` falls back to the process manager's own `DD_PM_SOCKET_PATH` when unset. ### Stack PR 8 of 9. Based on #54593; followed by #54529.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54594",
          "createdAt": "2026-08-07T18:09:51Z",
          "updatedAt": "2026-08-13T17:36:52Z",
          "timestamp": "2026-08-13T17:36:52Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "medium review",
            "team/agent-build",
            "team/action-platform",
            "internal",
            "team/fleet-automation"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:258ac25e7bad0f1d8714",
        "signalId": "github:DataDog/datadog-agent:pull_request:54437",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt",
          "metrics"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54437",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[AAD-23] Remove CUSUM detector",
          "text": "### What does this PR do? This PR removes the unused CUSUM detector and its configuration, tests, testbench UI, and evaluation wiring. ### Motivation CUSUM is disabled by default, is not used, and performs poorly in its current form. On the same 12 local eval scenarios, BOCPD + TimeCluster produced 6.08x higher mean F1 while CUSUM + TimeCluster produced 24.5x more baseline false positives and took 11.75x longer in detector execution. | Metric | CUSUM | BOCPD | |---|---:|---:| | Mean scenario F1 | 0.0212 | 0.1289 | | TimeCluster predictions | 2,923 | 287 | | Baseline false positives | 1,054 | 43 | | Raw detector anomalies | 571,833 | 1,315 | | Detector-phase time | 901.0s | 76.7s | ### Describe how you validated your changes - `dda inv test --targets=./comp/anomalydetection/observer/impl/` - `dda inv test --targets=./internal/qbranch/anomalydetection-testbench/` - `dda inv anomalydetection.build-testbench` - Python syntax validation for the anomaly-eval tasks - `git diff --check` - Repository pre-commit and pre-push hooks ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54437",
          "createdAt": "2026-08-04T19:08:27Z",
          "updatedAt": "2026-08-13T17:35:30Z",
          "timestamp": "2026-08-13T17:35:30Z",
          "metrics": {
            "reactions": 2,
            "comments": 10
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "long review",
            "team/agent-build",
            "internal",
            "team/fleet-automation"
          ],
          "author": "Eokye",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:a5f8e01738fcdecf89a5",
        "signalId": "github:DataDog/datadog-agent:pull_request:54591",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54591",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] add par-control executor channel",
          "text": "### What does this PR do? Defines the local control-to-executor channel and implements both ends of it: - Adds the executor gRPC protocol and generated bindings. - Exposes executor health and readiness. - Synchronizes workflow signing keys. - Streams action dispatch outcomes. - Adds the Rust mTLS client and transport support. - Keeps the shared terminal `Outcome` model with the executor layer. This layer provides communication primitives only; polling and process-lifecycle policy remain in later layers. ### Motivation Create a narrow, authenticated local contract between `par-control` and the existing Go executor before introducing OPMS polling or orchestration. ### Validation - Focused Go tests pass locally. - Private Action Runner Go build passes locally. - Portable Rust tests pass locally; native-tls identity coverage requires Linux/Windows. ### Review fixes - **Transport**: 5s connect timeout on both the plain and the mTLS channel, and no panic path in the named-pipe retry loop. Also corrects module docs that claimed Windows named-pipe support was a follow-up while the named-pipe client sits in the same file. - Dropped the redundant `tokio-stream` dev-dependency, since this layer promotes it to a regular dependency. - README records the build caveats: the dev VM's empty `PKG_CONFIG_LIBDIR` breaks `openssl-sys` under cargo, proto-touching changes must be Bazel-verified (under `--cfg=bazel` the bindings come from a separate crate, so the orphan rule differs), and the TLS tests are Linux-only. ### Stack PR 5 of 9. Based on #54590; followed by #54592.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54591",
          "createdAt": "2026-08-07T17:50:14Z",
          "updatedAt": "2026-08-13T17:35:14Z",
          "timestamp": "2026-08-13T17:35:14Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:0b52bc4139eff35911e4",
        "signalId": "github:DataDog/datadog-agent:pull_request:51295",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:51295",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add source to distributions via checks.",
          "text": "### What does this PR do? This adds the source to distributions that have been submitted by a Go check. ### Motivation Source was added to other metrics in #20690. This completes the source for distributions. ### Describe how you validated your changes Tested manually by creating a dummy go check, which was not added to this PR. ### Additional Notes [RFC outlining](https://datadoghq.atlassian.net/wiki/spaces/AM/pages/6773538856/RFC+-+Add+origin+to+check+distribution+metrics) the impact of this change. (TLDR there is no known negative impact)",
          "url": "https://github.com/DataDog/datadog-agent/pull/51295",
          "createdAt": "2026-05-26T11:16:34Z",
          "updatedAt": "2026-08-13T17:33:52Z",
          "timestamp": "2026-08-13T17:33:52Z",
          "metrics": {
            "reactions": 2,
            "comments": 8
          },
          "labels": [
            "qa/done",
            "short review",
            "team/agent-metric-pipelines",
            "internal"
          ],
          "author": "StephenWakely",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:2516ee8a5eaae60732a7",
        "signalId": "github:DataDog/datadog-agent:pull_request:54821",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54821",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[EBPF] gpu: serialize NVML field value queries",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Ensures that calls to `GetFieldValues` are serialized as that is not a thread safe API. ### Motivation #incident-59170 - `nvlink_fields` collector might mark some ports as unsupported. This is an extra safety on top of #54817, in case parallel collection is enabled. ### Describe how you validated your changes Tested in an A100 instance. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54821",
          "createdAt": "2026-08-13T10:55:17Z",
          "updatedAt": "2026-08-13T17:32:57Z",
          "timestamp": "2026-08-13T17:32:57Z",
          "metrics": {
            "reactions": 2,
            "comments": 6
          },
          "labels": [
            "team/ebpf-platform",
            "qa/done",
            "short review",
            "internal",
            "team/gpu-monitoring-agent",
            "backport/7.82.x",
            "backport/7.83.x"
          ],
          "author": "gjulianm",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:63d7d08cc44e8b6d34cf",
        "signalId": "github:DataDog/datadog-agent:pull_request:54851",
        "event": "discovered",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54851",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Bump internal agent image to tmpl-v26 (check_intake_queue 1.5.0)",
          "text": "### What does this PR do? Points the uncompressed `-jmx` and `-fips` internal `datadog-agent` image builds at `datadog-agent/tmpl-v26` (was `tmpl-v25`) in the images repo: ```diff publish_internal_container_image-jmx / -fips: - COMPRESSION: \"\" - IMAGE_VERSION: tmpl-v25 + IMAGE_VERSION: tmpl-v26 ``` ### Motivation `tmpl-v26` bumps `check_intake_queue` `1.3.2 -> 1.5.0` (cell-tagged zero for an empty intake queue; DataDog/integrations-internal#283). The template was added in DataDog/images#11094 rather than editing `tmpl-v25` in place — the in-place bump (images#11084) is being reverted in images#11093. Only the uncompressed variant is bumped; `-nydus`/`-zstd` stay on `tmpl-v24` per request.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54851",
          "createdAt": "2026-08-13T17:30:18Z",
          "updatedAt": "2026-08-13T17:31:53Z",
          "timestamp": "2026-08-13T17:31:53Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [
            "community",
            "team/agent-delivery"
          ],
          "author": "alyssamui2",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:4daebb6bba37b1ce4340",
        "signalId": "github:DataDog/datadog-agent:pull_request:54776",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt",
          "state"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54776",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Force LF line endings for text files by default on gitattributes",
          "text": "### What does this PR do? This PR sets a catch-all .gitattributes line that forces all files that git identifies as \"text\" (based on `text=auto`) to be checked out with LF endings by default (i.e. anything not matched by any other line in .gitattributes), regardless of platform and `core.autocrlf` setting. The PR also adjusts the .gitattributes file such that: - Existing individual settings of `text=auto eol=lf` are removed as they're covered by the new catch-all line. - It adds entries that allow us to make the change to .gitattributes without having to change any file as part of the same change. This means adding exceptions matching files that were identified as being stored with CRLF endings in git, as well as a golden file for a test which would fail under this new normalization. ### Motivation The original reason for this is that I was getting cache misses on Windows when trying to build python (`bazel build @cpython//:python_win`), which with help of execution logs I identified as coming from differences in the file https://github.com/DataDog/datadog-agent/blob/main/deps/cpython/redacted_compat.h. CI converts this file to add CRLF endings, whereas my local machine had at some point disabled `autocrlf` which meant my local file was using LF endings. Enabling [core.autocrlf](https://git-scm.com/docs/git-config#Documentation/git-config.txt-coreautocrlf) causes git to automatically decide, for files not matching any pattern in our .gitattributes file, whether to \"translate\" a file to using CRLF depending on the platform (on Windows, basically). The core rationale for this change is that it's extremely undesirable to have git config, which can differ from machine to machine, influence the bytes that you get on a checkout. This is even more so in a Bazel-enabled repo, where hashes of files are used everywhere for identity (caching, lockfiles, etc.). This change targets that behavior directly by ensuring we get no discrepancies in the future. I think this is justified even if the current default on windows git installs seems to enable autocrlf, because it implies our setup relying on something that is out of our control. ### Describe how you validated your changes Passing tests, confirmed `git add --renormalize .` doesn't touch anything, and `git ls-files --eol` reports the expected results. ### Additional Notes Existing checkouts won't automatically get the line endings matching the .gitattributes changes. For that, on a clean tree, something like this might be needed: ``` git rm --cached -r . git reset --hard HEAD ``` I'll be removing the individual exceptions in chunks, to limit the scope of the changes and make them easier to revert.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54776",
          "createdAt": "2026-08-12T12:21:26Z",
          "updatedAt": "2026-08-13T17:31:26Z",
          "timestamp": "2026-08-13T17:31:26Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "alopezz",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:0dbffece9854832b5da8",
        "signalId": "github:DataDog/datadog-agent:pull_request:54850",
        "event": "discovered",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54850",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Bump internal agent image to tmpl-v26 (check_intake_queue 1.5.0)",
          "text": "### What Points the uncompressed `-jmx` and `-fips` internal `datadog-agent` image builds at `datadog-agent/tmpl-v26` (was `tmpl-v25`) in the images repo. ```diff publish_internal_container_image-jmx / -fips: - COMPRESSION: \"\" - IMAGE_VERSION: tmpl-v25 + IMAGE_VERSION: tmpl-v26 ``` ### Why `tmpl-v26` bumps `check_intake_queue` `1.3.2 -> 1.5.0` (cell-tagged zero for empty intake queue; DataDog/integrations-internal#283). The new template was added in DataDog/images#11094 instead of modifying `tmpl-v25` in place — the in-place bump (images#11084) is being reverted in images#11093.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54850",
          "createdAt": "2026-08-13T17:13:48Z",
          "updatedAt": "2026-08-13T17:30:34Z",
          "timestamp": "2026-08-13T17:30:34Z",
          "metrics": {
            "reactions": 2,
            "comments": 3
          },
          "labels": [
            "community",
            "team/agent-delivery"
          ],
          "author": "alyssamui2",
          "state": "closed",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:1d021f7ee785a6e33f7f",
        "signalId": "github:DataDog/datadog-agent:pull_request:54529",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54529",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] package and activate par-control",
          "text": "### What does this PR do? Packages and activates `par-control` on Linux and Windows: - Adds Agent package and installer wiring. - Installs process-manager definitions for `par-control` and the executor. - Adds Windows executable resources and MSI integration. - Preserves a standard service `PATH` for Unix process-manager children. - Adds Linux and Windows split-runner lifecycle E2E suites and CI jobs. Runner ownership is handled by the preceding layer. Split activation is intentionally limited to supported host deployments; Docker and Kubernetes containers continue running monolithically until their three-process topology is implemented. This PR contains only host packaging, activation, and end-to-end coverage. ### Motivation Ship the split runner consistently across supported installation paths and verify its process lifecycle on both Linux and Windows. ### Validation - Installer package tests pass locally. - Buildifier passes for the affected Bazel definitions. - Linux and Windows split-runner E2E execution is delegated to CI. ### Stack PR 9 of 9. Based on #54594.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54529",
          "createdAt": "2026-08-06T16:54:57Z",
          "updatedAt": "2026-08-13T17:30:15Z",
          "timestamp": "2026-08-13T17:30:15Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/container-integrations",
            "team/agent-runtimes",
            "team/agent-devx",
            "team/agent-build",
            "team/windows-products",
            "team/action-platform",
            "internal",
            "team/fleet-automation"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:9a230c519414c500f1e4",
        "signalId": "github:DataDog/datadog-agent:pull_request:54814",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt",
          "state"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54814",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[AGENTRUN-1446] Skip nss failover e2e test it if the fakeintakes are still in use",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Due to a framework issue, the fakeintakes might still be in use (ie. an agent is still sending payloads to them) when the test starts, which makes the test flaky. We added a detection logic to fail early in this case (to avoid confusion when debugging). Update the logic to skip the test rather than fail it in this case. ### Motivation Avoid receiving notifications for failed test for a framework issue. ### Describe how you validated your changes CI ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54814",
          "createdAt": "2026-08-13T09:46:46Z",
          "updatedAt": "2026-08-13T17:28:50Z",
          "timestamp": "2026-08-13T17:28:50Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "team/agent-runtimes",
            "team/agent-build",
            "internal"
          ],
          "author": "pgimalac",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:8f968ba5d43d6ea7491a",
        "signalId": "github:DataDog/datadog-agent:pull_request:54362",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt",
          "state"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54362",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CONTINT-5415] Tag CronJob-owned Job events with kube_cronjob",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? This PR adds the `kube_cronjob` tag to Kubernetes Job events when they are spawned by a cronjob. It does this by parsing through the job name, the same as what is done in the [tagger](https://github.com/DataDog/datadog-agent/blob/9f1c7785f27a5a040377c1f0db4e4faf50cefe3d/comp/core/tagger/collectors/workloadmeta_extract.go#L1206) and [KSM](https://github.com/DataDog/datadog-agent/blob/9f1c7785f27a5a040377c1f0db4e4faf50cefe3d/pkg/collector/corechecks/cluster/ksm/kubernetes_state.go#L1479) check. ### Motivation Closes issue https://github.com/DataDog/datadog-agent/issues/52611 https://datadoghq.atlassian.net/browse/CONTINT-5415 ### Describe how you validated your changes On a kind cluster, built and deployed the agent with event bundling enabled, added a cronjob that spawns a new job with schedule `* * * * *`. Saw that events are emitted with the proper `kube_cronjob` tag: <img width=\"835\" height=\"387\" alt=\"image\" src=\"https://github.com/user-attachments/assets/e3991a91-a636-4a4a-96c7-84e61df2127f\" /> ### Additional Notes This change is _complete_ in that any job events spawned by a cronjob while have this tag, it's not _sound_ in that there could be jobs (not spawned by a cronjob) that could parse as a if its spawned by a cronjob, and the `kube_cronjob` tag will be emitted. Since other parts of the agent have accepted this risk, it's probably acceptable here too but I think worth noting.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54362",
          "createdAt": "2026-08-03T14:42:35Z",
          "updatedAt": "2026-08-13T17:25:54Z",
          "timestamp": "2026-08-13T17:25:54Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "qa/done",
            "medium review",
            "team/container-integrations",
            "team/agent-build",
            "internal"
          ],
          "author": "triviajon",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:cb48dcd819a2b11c826e",
        "signalId": "github:DataDog/datadog-agent:pull_request:54845",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt",
          "metrics"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54845",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[release] Update release.json for 7.83.0-rc.3",
          "url": "https://github.com/DataDog/datadog-agent/pull/54845",
          "createdAt": "2026-08-13T16:01:16Z",
          "updatedAt": "2026-08-13T17:15:57Z",
          "timestamp": "2026-08-13T17:15:57Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "qa/no-code-change",
            "team/agent-delivery",
            "long review",
            "team/agent-runtimes",
            "internal"
          ],
          "author": "temporal-github-worker-1[bot]",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:fea816d0363f2677a17f",
        "signalId": "github:DataDog/datadog-agent:pull_request:54838",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt",
          "metrics"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54838",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] test CONNECTION_TOKENS_V2 Agent secret resolution",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54838",
          "createdAt": "2026-08-13T15:20:01Z",
          "updatedAt": "2026-08-13T17:12:48Z",
          "timestamp": "2026-08-13T17:12:48Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [],
          "author": "dd-gplassard",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:f090a8b827e99f081331",
        "signalId": "github:DataDog/datadog-agent:pull_request:54735",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54735",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[procmgr] Supervise process-agent on Windows via dd-procmgr",
          "text": "### What does this PR do? Moves Windows **process-agent** supervision to **dd-procmgr** using the same dual-mode pattern as PAR: - Fleet installer writes `processes.d/datadog-agent-process.yaml` (Privileged spawn profile) - Legacy `datadog-process-agent` SCM service is suppressed when procmgr owns process-agent - Agent startup waits on `dd-procmgr-service` before starting gated legacy children; independent services (sysprobe, security-agent, installer) start without blocking on procmgr Also runs **dd-procmgr-service as LocalSystem** (MSI service custom action) so the supervisor can spawn Privileged children while agent-profile processes still spawn as `ddagentuser`. **Stack context:** PR 4/4 split from [#53249](https://github.com/DataDog/datadog-agent/pull/53249). Builds on [#54734](https://github.com/DataDog/datadog-agent/pull/54734) → [#54732](https://github.com/DataDog/datadog-agent/pull/54732) → [#54731](https://github.com/DataDog/datadog-agent/pull/54731). Spawn profiles, config gates, and secret backend resolution land in those PRs. ### Motivation We want subservices on dd-procmgr instead of SCM. Process-agent needs LocalSystem on Windows; other agent children should stay on the agent user. This PR wires the product integration once the procmgr foundation (PRs 1–3) is in place. ### Describe how you validated your changes - Go unit tests for dependent Windows service startup (`dependent_services_windows_test.go`) - Go unit tests for fleet installer templates and YAML path substitution (`processmanager/...`) - New Windows E2E: process-agent supervised by procmgr, runs as LocalSystem, legacy SCM stopped - E2E: dd-procmgr-service runs as LocalSystem; agent-profile children run as agent user - E2E: privileged spawn catalog enforcement when processes.d YAML is tampered with - PAR/procmgr Windows E2E regression ### Additional Notes - Linux process-agent stays on systemd for now. Legacy SCM service registration is not removed yet. - Process-agent `processes.d` config uses the shared `install_root` helper (same as PAR/ADP). MSI `RemoveFolderEx` handles uninstall/rollback cleanup; no per-file MSI rollback custom actions. - Includes release note `windows-process-procmgr-dual-mode-b7d2e4a1c8f03962.yaml`. - Closes/supersedes [#53249](https://github.com/DataDog/datadog-agent/pull/53249) once the full stack merges.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54735",
          "createdAt": "2026-08-11T16:07:07Z",
          "updatedAt": "2026-08-13T17:09:07Z",
          "timestamp": "2026-08-13T17:09:07Z",
          "metrics": {
            "reactions": 2,
            "comments": 1
          },
          "labels": [
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-build",
            "team/windows-products",
            "internal"
          ],
          "author": "jose-manuel-almaza",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:64ba84520ba24a74d27e",
        "signalId": "github:DataDog/datadog-agent:pull_request:54734",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54734",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[procmgr] Secret backend resolution for config gates",
          "text": "### What does this PR do? Resolves `ENC[...]` values during config gate evaluation so dd-procmgr matches Agent secret handling. Adds: - `config_gate/secrets.rs`: resolve handles via `secret_backend_command`, native `secret_backend_type`, and `multi_secret_backends` (same precedence as the core Agent) - Platform secret backend runners (Windows `CreateProcessAsUserW` under the Agent account; Unix setuid when procmgr runs as root for Privileged children) - `secret_backend_exec.rs`: shared spawn, timeout, stdout drain, and response parsing - Windows ACL validation on secret backend executables before spawn - Agent config precedence for backend settings: `DD_SECRET_BACKEND_*` env (including core Agent SCM `Environment` on Windows) over `datadog.yaml` - Manager reload: invalidate secret caches when config changes Fleet policy `ENC[...]` values stay unresolved here, matching Agent `MergeFleetPolicy` running after secret resolution. **Stack context:** PR 3/4 split from [#53249](https://github.com/DataDog/datadog-agent/pull/53249). Builds on [#54732](https://github.com/DataDog/datadog-agent/pull/54732) (`jose/procmgr-config-gates`), which in turn builds on [#54731](https://github.com/DataDog/datadog-agent/pull/54731). Process-agent dual-mode integration lands in PR 4 (`jose/procmgr-windows-process-agent`). ### Motivation PR 2 config gates read YAML, env, and fleet policy, but many customers gate features with secret-backed settings (`ENC[api_key]`, secret-backed booleans, etc.). Without secret resolution, gates would mis-evaluate and auto-start behavior would diverge from the Agent. ### Describe how you validated your changes - Rust unit tests in `pkg/procmgr/rust/src/config_gate/secrets.rs` and config gate integration tests (serialized env to avoid cross-test leakage) - Windows procmgr Rust build/tests in CI - Linux CI: secret-backend tests run under the agent service user where required ### Additional Notes - Secret backends always run as the core Agent service account, not as the procmgr supervisor (LocalSystem) or a Privileged managed child. - No agent startup, fleet installer, or legacy SCM suppression changes in this PR. - Invokes `secret-generic-connector` when no custom `secret_backend_command` is configured.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54734",
          "createdAt": "2026-08-11T15:56:49Z",
          "updatedAt": "2026-08-13T17:08:58Z",
          "timestamp": "2026-08-13T17:08:58Z",
          "metrics": {
            "reactions": 2,
            "comments": 1
          },
          "labels": [
            "changelog/no-changelog",
            "team/ebpf-platform",
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-devx",
            "team/container-experiences",
            "team/agent-build",
            "team/windows-products",
            "internal",
            "team/fleet-automation"
          ],
          "author": "jose-manuel-almaza",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:5aabaa01ae869db2f99e",
        "signalId": "github:DataDog/datadog-agent:pull_request:54849",
        "event": "discovered",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54849",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Draft: SMP - locally-rendered CI report",
          "text": "### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54849",
          "createdAt": "2026-08-13T16:48:49Z",
          "updatedAt": "2026-08-13T17:01:59Z",
          "timestamp": "2026-08-13T17:01:59Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "medium review",
            "internal"
          ],
          "author": "Arpafaucon",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:bd2224cccf7cd0817ea2",
        "signalId": "github:DataDog/datadog-agent:pull_request:54157",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt",
          "metrics"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54157",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[WP] ICMPv4 packet flow classification",
          "text": "### What does this PR do? This PR adds proper IPv4 ICMP flow tracking so CWS can attribute outbound ICMP packets to the correct process in the TC classifier at snapshot, enabling cgroup-scoped network_filter actions (e.g. dropping ping traffic). Problem: The flow_pid map keys flows by (netns, source address, L4 identifier, protocol). For TCP/UDP, the L4 identifier is the source port. ICMP has no ports — only an echo identifier in the header — and security_sk_classify_flow runs too early for ICMP sockets: the flowi metadata is incomplete and the existing port-matching logic does not apply. Solution: Hook ip_finish_output, once the IPv4 packet (IP + ICMP headers) is built, and parse the sk_buff to extract: the source address (iph.saddr) the echo identifier (icmph.un.echo.id), stored in the existing port field of pid_route_t ICMP flow registration is skipped in security_sk_classify_flow and handled exclusively from this hook. On the TC egress path, resolve_pid_from_flow_pid is updated to look up ICMP flows using icmp.id instead of tcp_udp.sport. Refactor: Flow registration logic is extracted into register_flow_pid_classify_entry, shared by both hooks. Test: TestNetworkFilterICMPPingIsolation starts a long-running ping in a container, loads a cgroup-scoped network_filter rule (icmp and dst host 1.1.1.1), and verifies packet loss once the agent attaches the filter. ### Motivation Cgroup network isolation relies on resolving the emitting process (and its cgroup) from packets observed on the TC egress path. Without a correct flow_pid entry for ICMP, the classifier cannot attribute ping packets to the container process if the agent miss the create of the socket. This caused pings not to be dropped when the ping process started before the agent, even if an isolation was applied on this process / cgroup. TCP/UDP flows were already registered from security_sk_classify_flow, but that hook fires before the kernel has assembled the final ICMP with the address (chosen at runtime for ICMP) packet and does not expose a usable port for the port-matching checks. By moving registration to ip_finish_output and keying on the ICMP echo identifier, we align ICMP with the same flow_pid → PID → cgroup resolution path used for TCP/UDP.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54157",
          "createdAt": "2026-07-28T09:37:01Z",
          "updatedAt": "2026-08-13T16:52:46Z",
          "timestamp": "2026-08-13T16:52:46Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/agent-security",
            "qa/done",
            "medium review",
            "internal"
          ],
          "author": "theop-dd",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:beff4442d994187cf47d",
        "signalId": "github:DataDog/datadog-agent:pull_request:54675",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "text",
          "updatedAt",
          "metrics"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54675",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "add skeletal authored script action",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds skeletal implemenation for authored script actions. This is not available to users as the action is behind a feature flag. [This PR](https://github.com/ddoghq/dd-source/pull/48812) ### Motivation We will be supporting authored scripts where new scripts can be added without needing a new agent release. This is to add a skeletal handler to support it. Further details in [Datadog Authored Script](https://docs.google.com/document/d/1qB2R__ZUkL2xjCDLybJGoaKl5EhpJ-rpy907h0qlRm4/edit?tab=t.0#heading=h.qjl27megtr2p) and [Authored script download and storage RFC](https://datadoghq.atlassian.net/wiki/spaces/ACT/pages/7060063493/RFC+Authored+script+download+storage+and+isolation) ### Describe how you validated your changes Ran an authorized script action from a local agent. Screenshot attached <img width=\"1353\" height=\"771\" alt=\"Screenshot 2026-08-13 at 12 46 44 PM\" src=\"https://github.com/user-attachments/assets/5d729838-3aa4-4f8e-a7d0-ac6057dba557\" /> ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54675",
          "createdAt": "2026-08-10T19:53:19Z",
          "updatedAt": "2026-08-13T16:50:30Z",
          "timestamp": "2026-08-13T16:50:30Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "medium review",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "Madhu-TV",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:9018f0ece4742a5715bf",
        "signalId": "github:DataDog/datadog-agent:pull_request:54767",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54767",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "aix: populate datadog.yaml from env vars in the config script",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Seeds `datadog.yaml` from `DD_API_KEY`/`DD_SITE`/`DD_HOSTNAME`/`DD_TAGS`/`DD_ENV`/`DD_INFRASTRUCTURE_MODE`/proxy env vars on first install, mirroring the Linux install script. ### Motivation installp has no mechanism to pass parameters at install time, so this is the only way to configure the agent unattended on AIX. ### Describe how you validated your changes Ran all creation/skip/`DD_INSTALL_ONLY` scenarios in a sandbox on a real AIX 7.3 host and confirmed the resulting YAML and file permissions. ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54767",
          "createdAt": "2026-08-12T09:07:16Z",
          "updatedAt": "2026-08-13T16:48:53Z",
          "timestamp": "2026-08-13T16:48:53Z",
          "metrics": {
            "reactions": 1,
            "comments": 1
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "medium review",
            "team/agent-runtimes",
            "team/agent-build",
            "internal"
          ],
          "author": "pgimalac",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:b506a44508968e47c3fc",
        "signalId": "github:DataDog/datadog-agent:pull_request:54732",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54732",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[procmgr] Config gates for processes.d auto-start",
          "text": "### What does this PR do? Adds **config gates** to dd-procmgr so `processes.d` definitions can use `condition_config_any` to auto-start only when Agent config says they should. Implementation mirrors the Windows legacy SCM startup checks in `dependent_services_windows.go` and Agent config resolution: - YAML lookup (case-insensitive keys, flattened dotted keys, permissive parse fallback, merge keys) - Environment bindings (`DD_*`) with Agent precedence (ignore empty values, no trim before `ParseBool`, legacy `process_config.enabled` transforms) - Fleet policy merge - Derived `system_probe_config.enabled` (USM/NPM/security knobs, sk-tracer and discovery adjustments) - Windows: read `DD_*` overrides from the core Agent SCM `Environment` registry when not set in the procmgr process env Wires gate evaluation into `ManagedProcess` start/reload paths in the manager. **Stack context:** PR 2/4 split from [#53249](https://github.com/DataDog/datadog-agent/pull/53249). Builds on [#54731](https://github.com/DataDog/datadog-agent/pull/54731) (`jose/procmgr-spawn-profiles`). `ENC[...]` secret backend resolution lands in PR 3 (`jose/procmgr-secret-backend-gates`). Process-agent dual-mode integration lands in PR 4 (`jose/procmgr-windows-process-agent`). ### Motivation Moving subservices (starting with process-agent) to dd-procmgr requires the supervisor to apply the same start/stop rules as the Agent today. Without config gates, a `processes.d` entry would always spawn when registered, which breaks parity with legacy SCM and fleet policy. ### Describe how you validated your changes - Rust unit tests in `pkg/procmgr/rust/src/config_gate/` (env bindings, YAML load, system-probe derivations, gate evaluation) - Go unit tests for Windows config helpers (`pkg/config/setup/config_windows_test.go`) - Windows procmgr Rust build/tests in CI ### Additional Notes - No `ENC[...]` / secret backend resolution in this PR (fleet policy `ENC[...]` values are not resolved here either). - No agent startup, fleet installer, or legacy SCM suppression changes in this PR. - Schema comment sync in `pkg/config/schema/yaml/process_config.yaml` for env binding documentation. - Small exports in `pkg/system-probe/config/` so procmgr gate derivations stay aligned with Go `adjust*` logic.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54732",
          "createdAt": "2026-08-11T15:51:46Z",
          "updatedAt": "2026-08-13T16:47:33Z",
          "timestamp": "2026-08-13T16:47:33Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "team/ebpf-platform",
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-devx",
            "team/container-experiences",
            "team/agent-build",
            "team/windows-products",
            "internal",
            "team/fleet-automation"
          ],
          "author": "jose-manuel-almaza",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:8277822add0694b8afd5",
        "signalId": "github:DataDog/datadog-agent:pull_request:54846",
        "event": "discovered",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54846",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Add provisioner-independent agent installers",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54846",
          "createdAt": "2026-08-13T16:25:15Z",
          "updatedAt": "2026-08-13T16:45:43Z",
          "timestamp": "2026-08-13T16:45:43Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "internal"
          ],
          "author": "KevinFairise2",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:6eb8d3a28a4587e34d77",
        "signalId": "github:DataDog/datadog-agent:pull_request:54831",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54831",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "test(e2e): add IBM MQ integration lab",
          "text": "### What does this PR do? Adds a deploy=true E2E-framework lab for the `ibm_mq` integration under `test/e2e-framework/scenarios/aws/integrations/ibm_mq`. The scenario self-provisions **IBM MQ Advanced for Developers 9.3** with a configurable number of queue managers and queues on a single amd64 RHEL 8 EC2 host, co-located with the Datadog Agent. A systemd-driven put/get load generator keeps queue depth and enqueue/dequeue metric families non-zero so the `ibm_mq` check has realistic work to do. It exposes knobs for: - queue-manager count and queues per manager - collection interval - queue selection strategy (auto-discovery / regex / explicit) - `collect_reset_queue_metrics` - metric exclusion patterns - integration and internal profiling Wiring: registered in the integrations `registry.go` + `BUILD.bazel`, and in the invoke task collection, giving the usual task surface: ``` dda inv aws.integrations.ibm-mq.{create,status,check,exec,ssh,destroy,reload-check} ``` ### Motivation Provide a reproducible, self-contained environment to investigate `ibm_mq` check CPU cost as queue-manager and queue counts scale — the check can become expensive with large queue counts and auto-discovery, and this lab makes that behavior easy to reproduce and profile in isolation. ### Describe how you validated your changes - `gofmt` clean on `registry.go` and all `ibm_mq/*.go`. - `go build ./scenarios/aws/integrations/...` in the `test/e2e-framework` module succeeds. - `dda inv aws.integrations -l` lists all `ibm-mq.*` tasks. - pre-commit hooks (shellcheck, go-fmt, copyright, python-linter, …) pass. ### Additional Notes Follows the existing integration-lab pattern (kafka, lustre, etc.). The scenario provisions billable EC2; remember to `dda inv aws.integrations.ibm-mq.destroy` when finished.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54831",
          "createdAt": "2026-08-13T13:26:11Z",
          "updatedAt": "2026-08-13T16:42:05Z",
          "timestamp": "2026-08-13T16:42:05Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "long review",
            "team/agent-integrations",
            "team/agent-build",
            "internal"
          ],
          "author": "dkirov-dd",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:a89456f81c4b5b3278dd",
        "signalId": "github:DataDog/datadog-agent:pull_request:54848",
        "event": "discovered",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54848",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix(cloudfoundry): avoid nil panic on failed DCA connection",
          "text": "## TL;DR Fixes a nil pointer dereference in the `cloudfoundry-vm` workloadmeta collector that crashes the node Agent on Cloud Foundry when the connection to the Cluster Agent fails. Regressed in 7.81. ## Motivation Agents on Cloud Foundry running 7.81+ panic repeatedly with: ``` panic: runtime error: invalid memory address or nil pointer dereference clusteragent.(*DCAClient).buildURL(...) clusteragent.go:271 clusteragent.(*DCAClient).GetCFAppsMetadataForNode(0x0, ...) cloudfoundry/vm.(*collector).Pull(...) cf_vm.go:111 ``` Root cause: `getDCAClient()` assigns `clusteragent.GetClusterAgentClient()` (return type `(*DCAClient, error)`) directly into the `c.dcaClient` interface field *before* checking the error. On a failed connection the returned nil `*DCAClient` is boxed into the interface, producing a non-nil \"typed nil\". The next `Pull` passes the `c.dcaClient != nil` cache check and calls `GetCFAppsMetadataForNode` on the nil receiver, panicking. This became reachable in 7.81 when #50814 changed `GetClusterAgentClient`'s return type from `DCAClientInterface` to `*DCAClient`. Before that, the error path returned a true nil interface, so the field was never poisoned. 7.80.4 is unaffected. ## What this does - `getDCAClient`: assign the result to a local `*DCAClient` and only store it into `c.dcaClient` on success. - `Pull`: call the local `dcaClient` returned by `getDCAClient()` instead of the field `c.dcaClient`. ## Validation / Testing - Added `TestPullDCAConnectionFailureDoesNotPanic`: two `Pull`s with `dcaEnabled=true` and no reachable Cluster Agent; asserts the second does not panic. - Verified the test is a real regression guard: reverting the fix makes it panic at `cf_vm.go:111` (the exact crash line); with the fix all package tests pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
          "url": "https://github.com/DataDog/datadog-agent/pull/54848",
          "createdAt": "2026-08-13T16:38:07Z",
          "updatedAt": "2026-08-13T16:41:11Z",
          "timestamp": "2026-08-13T16:41:11Z",
          "metrics": {
            "reactions": 2,
            "comments": 2
          },
          "labels": [
            "short review",
            "team/agent-integrations",
            "internal"
          ],
          "author": "NouemanKHAL",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:876013c0bd09da734a3c",
        "signalId": "github:DataDog/datadog-agent:pull_request:54769",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt",
          "metrics"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54769",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Split network-devices section in it's own file and fix ID links",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Split netowrk-devices section in it's own file and fix ID links",
          "url": "https://github.com/DataDog/datadog-agent/pull/54769",
          "createdAt": "2026-08-12T10:03:17Z",
          "updatedAt": "2026-08-13T16:50:54Z",
          "timestamp": "2026-08-13T16:50:54Z",
          "metrics": {
            "reactions": 1,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "team/agent-apm",
            "team/agent-security",
            "team/remote-config",
            "team/ebpf-platform",
            "team/agent-cspm",
            "qa/done",
            "team/container-platform",
            "long review",
            "team/container-integrations",
            "team/agent-runtimes",
            "team/agent-configuration",
            "team/agent-log-pipelines",
            "team/container-experiences",
            "team/agent-build",
            "team/kubernetes-experiences",
            "team/action-platform",
            "internal",
            "team/network-device-monitoring-core",
            "team/gpu-monitoring-agent",
            "team/fleet-remediation",
            "team/fleet-automation"
          ],
          "author": "hush-hush",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:3803fa8b971a2f589ace",
        "signalId": "github:DataDog/datadog-agent:pull_request:54634",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54634",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "optimize the complexity of the trace_contention_begin",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? This [commit](https://github.com/torvalds/linux/commit/e67ddd9b1cff7872d43ead73a1403c4e532003d9) landed in kernel v6.9 negatively effects the complexity of the `trace_contention_begin` bpf program. The verifier cannot effectively prune the state space of the binary search algorithm. In order to fix the load failures this PR moves the loop variables of the binary search into a percpu array map. Since the verifier cannot track the bounds of registers spilled to a map value, it can prune the state space more effectively. In order to make it reliable to use this scratch space the bpf program must now account for nested execution from different contexts. In order to handle this the PR introduce code to detect the execution context of the bpf program in the kernel and use that to select a slot to hold the loop variables. ### Motivation ### Describe how you validated your changes New tests cover the changes ### Additional Notes This PR is currently incomplete due to the lack of support for handling environments where kernel addresses from `/proc/kallsyms` are not readable such as when `kptr_restrict` is set and when `CAP_SYSLOG` is not available, in the cilium/ebpf loader. The loader automatically reads and caches addresses from /proc/kallsyms when `__ksyms` is used to mark global variables. I am working on upstreaming support for handling restricted environment to the cilium/ebpf loader.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54634",
          "createdAt": "2026-08-10T12:57:41Z",
          "updatedAt": "2026-08-13T16:34:01Z",
          "timestamp": "2026-08-13T16:34:01Z",
          "metrics": {
            "reactions": 1,
            "comments": 7
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "team/ebpf-platform",
            "qa/done",
            "long review",
            "ask-review",
            "team/agent-build",
            "internal"
          ],
          "author": "usamasaqib",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:6c9cccefcd2207531de0",
        "signalId": "github:DataDog/datadog-agent:pull_request:54797",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "text",
          "updatedAt",
          "metrics"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54797",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Sign macos DMG only on nightly instead of main",
          "text": "### What does this PR do? Stops doing real signing and notarization of Macos DMG packages on main. Do it on nightly only so we maintain some testing of the process. ### Motivation We should not be creating notarized, installable packages off of main. That creates artifacts which could appear to be end-user consumable, but are not supported, nor necessarily validated. Notarization also slightly DOSes Apple. Ideally we should only do notarization on the release branches for candidate builds. We'll address that once we convert the build to bazel. ### Describe how you validated your changes CI ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54797",
          "createdAt": "2026-08-12T19:48:33Z",
          "updatedAt": "2026-08-13T16:33:42Z",
          "timestamp": "2026-08-13T16:33:42Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "short review",
            "team/agent-build",
            "internal"
          ],
          "author": "aiuto",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:a8903350a6fa4ff6d033",
        "signalId": "github:DataDog/datadog-agent:pull_request:54645",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt",
          "state"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54645",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix: avoid data race in grpclog.SetLogger on otelcol collector start",
          "text": "### What does this PR do? Sets `SkipSettingGRPCLogger: true` on the `otelcol.CollectorSettings` for the otel-agent and host-profiler collectors, so `otelcol.(*Collector).Run` no longer calls the non-mutex-protected `grpclog.SetLogger` while other gRPC clients (e.g. remote-config/remote-tagger) are active in the same process. ### Motivation Fix a race, found via a race-detector-enabled build in staging. ### Describe how you validated your changes Ran `./comp/otelcol/...` and `./comp/host-profiler/collector/...` tests (including with `--race`) and built `otel-agent`/`host-profiler`, all passing; a real regression test isn't feasible since the race needs real concurrent gRPC/otelcol startup. ### Additional Notes No log routing is lost: `comp/core/tagger/impl-remote` (pulled in by both otel-agent and host-profiler) already sets a Datadog-logger-backed `grpclog` logger in its package `init()`, which runs once before `main()` and is therefore race-free. Skipping otelcol's later, racy `SetLogger` call just stops it from unsafely clobbering that existing assignment — grpc's internal logs keep flowing to our structured logger exactly as before. Similar to https://github.com/DataDog/datadog-agent/pull/15321 for the OTLP endpoint.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54645",
          "createdAt": "2026-08-10T13:59:56Z",
          "updatedAt": "2026-08-13T16:28:43Z",
          "timestamp": "2026-08-13T16:28:43Z",
          "metrics": {
            "reactions": 1,
            "comments": 8
          },
          "labels": [
            "changelog/no-changelog",
            "team/opentelemetry",
            "qa/done",
            "medium review",
            "team/profiling-full-host",
            "internal"
          ],
          "author": "pgimalac",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:9e9e2fdfc6234627bd8e",
        "signalId": "github:DataDog/datadog-agent:pull_request:54720",
        "event": "discovered",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54720",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[EBPF] gpu: Support ARM64 NVML library discovery",
          "text": "<!-- dd-meta {\"pullId\":\"df13230b-a434-451b-972e-ac9007c02168\",\"source\":\"chat\",\"resourceId\":\"86800824-17f2-4a85-9551-be5b7bf8a830\",\"workflowId\":\"2ce581a4-a03e-4c0a-a1a1-dda5b27f5a0c\",\"codeChangeId\":\"2ce581a4-a03e-4c0a-a1a1-dda5b27f5a0c\",\"sourceType\":\"bits_ai_sre\"} --> ### What does this PR do? Bits AI SRE Investigation • [View in Bits AI SRE Investigation](https://ddstaging.datadoghq.com/bits-ai/investigations/8418dc69-efd2-44d3-ad70-91e14223f69d) Add standard ARM64 (`aarch64-linux-gnu`) NVML library paths for host and NVIDIA GPU Operator installations. ### Motivation GPU checks on ARM64 GPU nodes fail because NVML discovery searches only x86_64 library directories. This causes all GPU metrics to fail on affected ARM64 nodes and can trigger incorrect health responses. ### Describe how you validated your changes Unit tests added ### Additional Notes --- PR by Bits - [View session in Datadog](https://ddstaging.datadoghq.com/code/86800824-17f2-4a85-9551-be5b7bf8a830) Comment @datadog to request changes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54720",
          "createdAt": "2026-08-11T13:28:10Z",
          "updatedAt": "2026-08-13T16:28:12Z",
          "timestamp": "2026-08-13T16:28:12Z",
          "metrics": {
            "reactions": 2,
            "comments": 9
          },
          "labels": [
            "changelog/no-changelog",
            "team/ebpf-platform",
            "qa/done",
            "team/container-platform",
            "medium review",
            "team/container-integrations",
            "Bits AI",
            "internal",
            "team/gpu-monitoring-agent",
            "team/fleet-automation",
            "backport/7.83.x"
          ],
          "author": "gjulianm",
          "state": "closed",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:d3e8612cc3d98c09e4b0",
        "signalId": "github:DataDog/datadog-agent:pull_request:54823",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt",
          "metrics",
          "state"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54823",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix(aix): discover Python checks via integrations-core AIX manifest tag",
          "text": "### What does this PR do? Replaces the hardcoded AIX Python check list with dynamic discovery of every integrations-core check tagged `Supported OS::AIX`. ### Motivation Keep AIX in sync with integrations-core instead of drifting from a hand-maintained list. ### Describe how you validated your changes Ran the updated stage on an AIX 7.3 build host: it installed all currently AIX-tagged checks with no errors. ### Additional Notes `ibm_spectrum_lsf` is dropped — it was hardcoded before but never actually tagged for AIX upstream.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54823",
          "createdAt": "2026-08-13T11:32:13Z",
          "updatedAt": "2026-08-13T17:39:37Z",
          "timestamp": "2026-08-13T17:39:37Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "short review",
            "team/agent-build",
            "internal"
          ],
          "author": "pgimalac",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:df5fe6623d0e1087fbf9",
        "signalId": "github:DataDog/datadog-agent:pull_request:54496",
        "event": "changed",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [
          "updatedAt",
          "metrics"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54496",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "apm: use url.template for OTLP HTTP client resource names",
          "text": "## What does this PR do? Uses the OpenTelemetry `url.template` attribute when generating resource names for HTTP client spans. Client spans now use `METHOD url.template` when available and retain the method-only fallback otherwise. Server spans continue to use `METHOD http.route`. Both the current and legacy OTLP resource-name paths are covered to keep behavior consistent when operation/resource name V2 is disabled. Fixes #31570. ## Motivation HTTP client resource names currently collapse to the HTTP method even when OpenTelemetry instrumentation provides a low-cardinality URL template. Using the template produces more useful resource grouping without falling back to high-cardinality raw URLs. ## Testing Added focused unit coverage for client URL templates, method-only fallback, and client/server attribute precedence. Local `dda inv test --targets=./pkg/trace/api,./pkg/trace/otel/traceutil` could not run because Windows Defender quarantined the standalone `dda.exe` after its PyPI bootstrap failed with a TLS handshake error. CI is expected to run the required test targets. ## Additional Notes The current commit is unsigned because no local signing key is configured; it will need to be replaced with a signed commit before merge.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54496",
          "createdAt": "2026-08-05T21:37:23Z",
          "updatedAt": "2026-08-13T16:24:31Z",
          "timestamp": "2026-08-13T16:24:31Z",
          "metrics": {
            "reactions": 2,
            "comments": 8
          },
          "labels": [
            "community",
            "team/agent-apm",
            "team/agent-security",
            "team/ebpf-platform",
            "team/opentelemetry",
            "team/container-platform",
            "team/agent-delivery",
            "team/agent-integrations",
            "team/container-integrations",
            "team/agent-discovery",
            "team/agent-runtimes",
            "team/agent-log-pipelines",
            "team/agent-metric-pipelines",
            "team/agent-devx",
            "team/container-experiences",
            "team/agent-build",
            "team/action-platform",
            "team/gpu-monitoring-agent",
            "team/fleet-automation",
            "team/agent-data-plane"
          ],
          "author": "niharikag09",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:bd871c1195a6b89b96d3",
        "signalId": "github:DataDog/datadog-agent:pull_request:54190",
        "event": "discovered",
        "observedAt": "2026-08-13T17:43:20.785491Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54190",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "split org-wide and targeted policies into separate RC output files",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? ### Motivation ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54190",
          "createdAt": "2026-07-29T05:37:25Z",
          "updatedAt": "2026-08-13T16:21:44Z",
          "timestamp": "2026-08-13T16:21:44Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "medium review",
            "team/injection-platform",
            "stale",
            "internal"
          ],
          "author": "annacai21",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:789883deb1dc6a4a1023",
        "signalId": "github:DataDog/datadog-agent:pull_request:54556",
        "event": "discovered",
        "observedAt": "2026-08-13T17:47:07.884300Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54556",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[DOIO-171] Add MySQL query action dispatch",
          "text": "Data Observability query actions now dispatch remote configuration payloads to MySQL checks as well as Postgres and SAP HANA. The component uses one supported-integration allowlist for startup detection and instance matching, so unrelated integrations cannot activate the subscription or receive query configs. Closes https://linear.app/datadog/issue/DOIO-171",
          "url": "https://github.com/DataDog/datadog-agent/pull/54556",
          "createdAt": "2026-08-07T08:28:45Z",
          "updatedAt": "2026-08-13T17:47:03Z",
          "timestamp": "2026-08-13T17:47:03Z",
          "metrics": {
            "reactions": 2,
            "comments": 7
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "medium review",
            "team/data-jobs-monitoring",
            "internal"
          ],
          "author": "mobuchowski",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:925b75ae243cda923f6d",
        "signalId": "github:DataDog/datadog-agent:pull_request:54591",
        "event": "changed",
        "observedAt": "2026-08-13T17:47:07.884300Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54591",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] add par-control executor channel",
          "text": "### What does this PR do? Defines the local control-to-executor channel and implements both ends of it: - Adds the executor gRPC protocol and generated bindings. - Exposes executor health and readiness. - Synchronizes workflow signing keys. - Streams action dispatch outcomes. - Adds the Rust mTLS client and transport support. - Keeps the shared terminal `Outcome` model with the executor layer. This layer provides communication primitives only; polling and process-lifecycle policy remain in later layers. ### Motivation Create a narrow, authenticated local contract between `par-control` and the existing Go executor before introducing OPMS polling or orchestration. ### Validation - Focused Go tests pass locally. - Private Action Runner Go build passes locally. - Portable Rust tests pass locally; native-tls identity coverage requires Linux/Windows. ### Review fixes - **Transport**: 5s connect timeout on both the plain and the mTLS channel, and no panic path in the named-pipe retry loop. Also corrects module docs that claimed Windows named-pipe support was a follow-up while the named-pipe client sits in the same file. - Dropped the redundant `tokio-stream` dev-dependency, since this layer promotes it to a regular dependency. - README records the build caveats: the dev VM's empty `PKG_CONFIG_LIBDIR` breaks `openssl-sys` under cargo, proto-touching changes must be Bazel-verified (under `--cfg=bazel` the bindings come from a separate crate, so the orphan rule differs), and the TLS tests are Linux-only. ### Stack PR 5 of 9. Based on #54590; followed by #54592.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54591",
          "createdAt": "2026-08-07T17:50:14Z",
          "updatedAt": "2026-08-13T17:46:56Z",
          "timestamp": "2026-08-13T17:46:56Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:e7dbcb04022837d4a719",
        "signalId": "github:DataDog/datadog-agent:pull_request:54592",
        "event": "changed",
        "observedAt": "2026-08-13T17:47:07.884300Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54592",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] add par-control OPMS client",
          "text": "### What does this PR do? Adds the authenticated OPMS client used by `par-control`: - Signs requests with runner JWT authentication. - Dequeues workflow tasks. - Publishes terminal task outcomes. - Sends task heartbeats. - Performs runner health checks. - Matches the existing Go wire contracts, proxy behavior, TLS settings, and retry pacing. The implementation and its HTTP/TLS contract tests are kept together in this layer. ### Motivation Separate the remote OPMS protocol from local executor communication and from the orchestration policy that composes them. ### Validation - 46 portable Rust tests pass locally. - Three native-tls tests require Linux/Windows and do not run successfully with the macOS Security Framework backend. ### Stack PR 6 of 9. Based on #54591; followed by #54593.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54592",
          "createdAt": "2026-08-07T17:51:46Z",
          "updatedAt": "2026-08-13T17:46:54Z",
          "timestamp": "2026-08-13T17:46:54Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:238968d75c4291a1f98a",
        "signalId": "github:DataDog/datadog-agent:pull_request:54847",
        "event": "changed",
        "observedAt": "2026-08-13T17:47:07.884300Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54847",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[Backport 7.83.x]  [EBPF] gpu: Support ARM64 NVML library discovery",
          "text": "Backport 5dcbd3081dd283e30cf25879eb5be7b55577e50a from #54720. ___ <!-- dd-meta {\"pullId\":\"df13230b-a434-451b-972e-ac9007c02168\",\"source\":\"chat\",\"resourceId\":\"86800824-17f2-4a85-9551-be5b7bf8a830\",\"workflowId\":\"2ce581a4-a03e-4c0a-a1a1-dda5b27f5a0c\",\"codeChangeId\":\"2ce581a4-a03e-4c0a-a1a1-dda5b27f5a0c\",\"sourceType\":\"bits_ai_sre\"} --> ### What does this PR do? Bits AI SRE Investigation • [View in Bits AI SRE Investigation](https://ddstaging.datadoghq.com/bits-ai/investigations/8418dc69-efd2-44d3-ad70-91e14223f69d) Add standard ARM64 (`aarch64-linux-gnu`) NVML library paths for host and NVIDIA GPU Operator installations. ### Motivation GPU checks on ARM64 GPU nodes fail because NVML discovery searches only x86_64 library directories. This causes all GPU metrics to fail on affected ARM64 nodes and can trigger incorrect health responses. ### Describe how you validated your changes Unit tests added ### Additional Notes --- PR by Bits - [View session in Datadog](https://ddstaging.datadoghq.com/code/86800824-17f2-4a85-9551-be5b7bf8a830) Comment @datadog to request changes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54847",
          "createdAt": "2026-08-13T16:30:11Z",
          "updatedAt": "2026-08-13T17:44:41Z",
          "timestamp": "2026-08-13T17:44:41Z",
          "metrics": {
            "reactions": 2,
            "comments": 3
          },
          "labels": [
            "changelog/no-changelog",
            "team/ebpf-platform",
            "qa/done",
            "backport",
            "bot",
            "team/container-platform",
            "medium review",
            "team/container-integrations",
            "Bits AI",
            "internal",
            "team/gpu-monitoring-agent",
            "team/fleet-automation"
          ],
          "author": "dd-octo-sts[bot]",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:fc8f01aac1a6f61ec7a7",
        "signalId": "github:DataDog/datadog-agent:pull_request:54645",
        "event": "changed",
        "observedAt": "2026-08-13T17:47:07.884300Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54645",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "fix: avoid data race in grpclog.SetLogger on otelcol collector start",
          "text": "### What does this PR do? Sets `SkipSettingGRPCLogger: true` on the `otelcol.CollectorSettings` for the otel-agent and host-profiler collectors, so `otelcol.(*Collector).Run` no longer calls the non-mutex-protected `grpclog.SetLogger` while other gRPC clients (e.g. remote-config/remote-tagger) are active in the same process. ### Motivation Fix a race, found via a race-detector-enabled build in staging. ### Describe how you validated your changes Ran `./comp/otelcol/...` and `./comp/host-profiler/collector/...` tests (including with `--race`) and built `otel-agent`/`host-profiler`, all passing; a real regression test isn't feasible since the race needs real concurrent gRPC/otelcol startup. ### Additional Notes No log routing is lost: `comp/core/tagger/impl-remote` (pulled in by both otel-agent and host-profiler) already sets a Datadog-logger-backed `grpclog` logger in its package `init()`, which runs once before `main()` and is therefore race-free. Skipping otelcol's later, racy `SetLogger` call just stops it from unsafely clobbering that existing assignment — grpc's internal logs keep flowing to our structured logger exactly as before. Similar to https://github.com/DataDog/datadog-agent/pull/15321 for the OTLP endpoint.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54645",
          "createdAt": "2026-08-10T13:59:56Z",
          "updatedAt": "2026-08-13T17:44:38Z",
          "timestamp": "2026-08-13T17:44:38Z",
          "metrics": {
            "reactions": 1,
            "comments": 8
          },
          "labels": [
            "changelog/no-changelog",
            "team/opentelemetry",
            "qa/done",
            "medium review",
            "team/profiling-full-host",
            "internal"
          ],
          "author": "pgimalac",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:10552518c1209cbe7308",
        "signalId": "github:DataDog/datadog-agent:pull_request:54843",
        "event": "changed",
        "observedAt": "2026-08-13T17:47:07.884300Z",
        "changedFields": [
          "updatedAt",
          "labels"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54843",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CONTP-2006] feat(ddi): Connect custom workload targets to DDI controller and streaming",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Connects configurable workload target resolution to DatadogInstrumentation checks and logs. - Adds `instrumentation_crd_controller.custom_workload_targets` configuration. - Starts the Pod workloadmeta store and resolver when at least one custom target is configured. - Accepts registered target GVKs and generates CEL selectors against `container.pod.resolved_targets`. - Includes `apiVersion` when detecting duplicate target references. - Preserves `rootowner` matching for built-in workloads and EndpointSlice delivery for core `v1` Services. For example, a workload reached through an intermediate Kubernetes Job can be configured as: ```yaml instrumentation_crd_controller: custom_workload_targets: - target: apiVersion: example.com/v1 kind: ScheduledWorkload resource: scheduledworkloads via: - apiVersion: batch/v1 kind: Job resource: jobs ``` ### Motivation [CONTP-2006](https://datadoghq.atlassian.net/browse/CONTP-2006) DatadogInstrumentation supports core Kubernetes workload kinds and Argo Rollouts out of the box, but customers also run workloads through controllers such as Ray, Kueue, OpenKruise, and Strimzi. Customers need an opt-in way to declare the workload resources they use and the ownership path from Pods, without relying on a generic fallback or requiring every custom kind to be added to the Agent. ### Describe how you validated your changes ### Additional Notes [CONTP-2006]: https://datadoghq.atlassian.net/browse/CONTP-2006?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54843",
          "createdAt": "2026-08-13T15:53:26Z",
          "updatedAt": "2026-08-13T17:43:45Z",
          "timestamp": "2026-08-13T17:43:45Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "team/container-platform",
            "long review",
            "team/container-integrations",
            "team/agent-build",
            "internal",
            "team/fleet-automation"
          ],
          "author": "Mathew-Estafanous",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:c2a3e2994d6c5ea86ea4",
        "signalId": "github:DataDog/datadog-agent:pull_request:54842",
        "event": "changed",
        "observedAt": "2026-08-13T17:47:07.884300Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54842",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CONTP-2006] feat(ddi): Add pod workload target resolution",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds a registry and owner-chain resolver for DatadogInstrumentation workload targets. - Models built-in and customer-configured workload profiles using a `target` resource and optional `via` resources. - Identifies every resource by `apiVersion`, kind, and plural resource name. - Walks controller owner references with the dynamic Kubernetes client, validates owner UIDs, caches resolved owners, and limits traversal depth. This PR only introduces the resolver package. It does not expose or activate custom workload target configuration. ### Motivation [CONTP-2006](https://datadoghq.atlassian.net/browse/CONTP-2006) Hard-coding every operator-managed workload does not scale and cannot represent indirect ownership such as Pod to Job to a custom workload. Explicit target and traversal profiles provide a general mechanism that distinguishes API groups and allows deployments to grant read access only to the intermediate resources required for resolution. ### Describe how you validated your changes ### Additional Notes [CONTP-2006]: https://datadoghq.atlassian.net/browse/CONTP-2006?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54842",
          "createdAt": "2026-08-13T15:51:31Z",
          "updatedAt": "2026-08-13T17:43:26Z",
          "timestamp": "2026-08-13T17:43:26Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "team/container-platform",
            "medium review",
            "team/agent-build",
            "internal"
          ],
          "author": "Mathew-Estafanous",
          "state": "open",
          "assignees": [
            "Mathew-Estafanous"
          ],
          "change": "updated"
        }
      },
      {
        "id": "event:b8a8fffb66e8fb6b5be8",
        "signalId": "github:DataDog/datadog-agent:issue:33469",
        "event": "changed",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [
          "text",
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:issue:33469",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "issue",
          "title": "Dependency Dashboard",
          "text": "This issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.<br>[View this repository on the Mend.io Web Portal](https://developer.mend.io/github/DataDog/datadog-agent). ## Deprecations / Replacements > [!WARNING] The following dependencies are either deprecated or have replacements available. | Datasource | Package | Replacement PR? | |------------|------|--------------| | nuget | [xunit](https://redirect.github.com/xunit/xunit) | ![Unavailable](https://img.shields.io/badge/unavailable-orange?style=flat-square) | ## Pending Approval The following branches are pending approval. To create them, click on a checkbox below. - [ ] <!-- approve-branch=renovate/github.com-alecthomas-participle-2.x -->Update module github.com/alecthomas/participle to v2 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-authorization-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/authorization/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-compute-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/compute/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-containerservice-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/containerservice/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-managedidentity-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/managedidentity/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-network-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/network/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-docker-sdk-v4-5.x -->Update module github.com/pulumi/pulumi-docker/sdk/v4 to v5 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-tls-sdk-v4-5.x -->Update module github.com/pulumi/pulumi-tls/sdk/v4 to v5 - [ ] <!-- approve-branch=renovate/github.com-sijms-go-ora-v2-3.x -->Update module github.com/sijms/go-ora/v2 to v3 - [ ] <!-- approve-branch=renovate/gitlab.com-gitlab-org-api-client-go-2.x -->Update module gitlab.com/gitlab-org/api/client-go to v2 - [ ] <!-- approve-branch=renovate/gopkg.in-datadog-dd-trace-go.v1-2.x -->Update module gopkg.in/DataDog/dd-trace-go.v1 to v2 - [ ] <!-- approve-all-pending-prs -->🔐 **Create all pending approval PRs at once** 🔐 ## Rate-Limited The following updates are currently rate-limited. To force their creation now, click on a checkbox below. - [ ] <!-- unlimit-branch=renovate/datadog-dd-apm-library-python-4.x -->Update dependency DataDog/dd-apm-library-python to v4.13.1 - [ ] <!-- unlimit-branch=renovate/linux-images-130715735.x -->Update dependency linux-images to v130715735 - [ ] <!-- unlimit-branch=renovate/linux-images-devcontainer-130715735.x -->Update dependency linux-images-devcontainer to v130715735 - [ ] <!-- unlimit-branch=renovate/windows-images-130715735.x -->Update dependency windows-images to v130715735 - [ ] <!-- unlimit-branch=renovate/github-actions -->Update github-actions (`DataDog/dd-sts-action`, `actions/checkout`, `aws-actions/configure-aws-credentials`, `docker/login-action`, `tcort/github-action-markdown-link-check`) - [ ] <!-- unlimit-branch=renovate/github.com-jarcoal-httpmock-1.x -->Update module github.com/jarcoal/httpmock to v1.4.2 - [ ] <!-- unlimit-branch=renovate/github.com-klauspost-compress-1.x -->Update module github.com/klauspost/compress to v1.19.2 - [ ] <!-- unlimit-branch=renovate/github.com-mattn-go-sqlite3-1.x -->Update module github.com/mattn/go-sqlite3 to v1.14.49 - [ ] <!-- unlimit-branch=renovate/github.com-pierrec-lz4-v4-4.x -->Update module github.com/pierrec/lz4/v4 to v4.1.28 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-random-sdk-v4-4.x -->Update module github.com/pulumi/pulumi-random/sdk/v4 to v4.21.1 - [ ] <!-- unlimit-branch=renovate/github.com-santhosh-tekuri-jsonschema-v6-6.x -->Update module github.com/santhosh-tekuri/jsonschema/v6 to v6.0.3 - [ ] <!-- unlimit-branch=renovate/github.com-vektra-mockery-v3-3.x -->Update module github.com/vektra/mockery/v3 to v3.7.2 - [ ] <!-- unlimit-branch=renovate/go.etcd.io-etcd-client-v2-2.x -->Update module go.etcd.io/etcd/client/v2 to v2.305.33 - [ ] <!-- unlimit-branch=renovate/go.temporal.io-api-1.x -->Update module go.temporal.io/api to v1.63.5 - [ ] <!-- unlimit-branch=renovate/clap-4.x-lockfile -->Update Rust crate clap to v4.6.6 - [ ] <!-- unlimit-branch=renovate/packaging-26.x -->Update dependency packaging to v26.3 - [ ] <!-- unlimit-branch=renovate/cloud.google.com-go-compute-1.x -->Update module cloud.google.com/go/compute to v1.65.0 - [ ] <!-- unlimit-branch=renovate/code.cloudfoundry.org-lager-v3-3.x -->Update module code.cloudfoundry.org/lager/v3 to v3.81.0 - [ ] <!-- unlimit-branch=renovate/github.com-apache-arrow-go-v18-18.x -->Update module github.com/apache/arrow-go/v18 to v18.7.0 - [ ] <!-- unlimit-branch=renovate/github.com-aquasecurity-trivy-0.x -->Update module github.com/aquasecurity/trivy to v0.73.0 - [ ] <!-- unlimit-branch=renovate/github.com-containerd-containerd-v2-2.x -->Update module github.com/containerd/containerd/v2 to v2.3.3 - [ ] <!-- unlimit-branch=renovate/github.com-datadog-dd-trace-go-contrib-net-http-v2-2.x -->Update module github.com/DataDog/dd-trace-go/contrib/net/http/v2 to v2.9.1 - [ ] <!-- unlimit-branch=renovate/github.com-datadog-orchestrion-1.x -->Update module github.com/DataDog/orchestrion to v1.12.0 - [ ] <!-- unlimit-branch=renovate/github.com-docker-cli-29.x -->Update module github.com/docker/cli to v29.7.2+incompatible - [ ] <!-- unlimit-branch=renovate/github.com-envoyproxy-gateway-1.x -->Update module github.com/envoyproxy/gateway to v1.8.3 - [ ] <!-- unlimit-branch=renovate/github.com-google-cel-go-0.x -->Update module github.com/google/cel-go to v0.30.0 - [ ] <!-- unlimit-branch=renovate/github.com-open-policy-agent-opa-1.x -->Update module github.com/open-policy-agent/opa to v1.19.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-aws-sdk-v7-7.x -->Update module github.com/pulumi/pulumi-aws/sdk/v7 to v7.40.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-awsx-sdk-v3-3.x -->Update module github.com/pulumi/pulumi-awsx/sdk/v3 to v3.8.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-eks-sdk-v4-4.x -->Update module github.com/pulumi/pulumi-eks/sdk/v4 to v4.3.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-gcp-sdk-v9-9.x -->Update module github.com/pulumi/pulumi-gcp/sdk/v9 to v9.33.0 - [ ] <!-- unlimit-branch=renovate/github.com-pulumi-pulumi-sdk-v3-3.x -->Update module github.com/pulumi/pulumi/sdk/v3 to v3.256.0 - [ ] <!-- unlimit-branch=renovate/github.com-rabbitmq-amqp091-go-1.x -->Update module github.com/rabbitmq/amqp091-go to v1.13.0 - [ ] <!-- unlimit-branch=renovate/github.com-redis-go-redis-v9-9.x -->Update module github.com/redis/go-redis/v9 to v9.22.0 - [ ] <!-- unlimit-branch=renovate/go.temporal.io-sdk-1.x -->Update module go.temporal.io/sdk to v1.47.0 - [ ] <!-- unlimit-branch=renovate/sigs.k8s.io-gateway-api-1.x -->Update module sigs.k8s.io/gateway-api to v1.6.1 - [ ] <!-- unlimit-branch=renovate/redis-7.x -->Update redis Docker tag to v7.4 - [ ] <!-- unlimit-branch=renovate/confluentinc-cp-kafka-8.x -->Update confluentinc/cp-kafka Docker tag to v8 - [ ] <!-- unlimit-branch=renovate/major-github-actions -->Update github-actions (major) (`actions/cache`, `actions/labeler`, `actions/setup-go`, `actions/setup-node`, `actions/setup-python`, `actions/stale`, `slackapi/slack-github-action`) - [ ] <!-- unlimit-branch=renovate/postgres-17.x -->Update postgres Docker tag to v17 - [ ] <!-- unlimit-branch=renovate/redis-8.x -->Update redis Docker tag to v8 - [ ] <!-- create-all-rate-limited-prs -->🔐 **Create all rate-limited PRs at once** 🔐 ## Pending Status Checks The following updates await pending status checks. To force their creation now, click on a checkbox below. - [ ] <!-- approvePr-branch=renovate/confluentinc-cp-kafka-7.x -->Update confluentinc/cp-kafka Docker tag to v7.9.9 - [ ] <!-- approvePr-branch=renovate/rules_rs-0.x -->Update dependency rules_rs to v0.0.102 - [ ] <!-- approvePr-branch=renovate/franz-go -->Update module github.com/twmb/franz-go to v1.21.6 - [ ] <!-- approvePr-branch=renovate/google.golang.org-protobuf-1.x -->Update module google.golang.org/protobuf to v1.36.12 - [ ] <!-- approvePr-branch=renovate/dd_sds-0.x -->Update Rust crate dd_sds to v0.1.0-20260813-972b5d8d1827 - [ ] <!-- approvePr-branch=renovate/http-body-util-0.x-lockfile -->Update Rust crate http-body-util to v0.1.5 - [ ] <!-- approvePr-branch=renovate/thiserror-2.x-lockfile -->Update Rust crate thiserror to v2.0.20 - [ ] <!-- approvePr-branch=renovate/hatchling-1.x -->Update dependency hatchling to v1.32.0 - [ ] <!-- approvePr-branch=renovate/azure-sdk-for-go-monorepo -->Update module github.com/Azure/azure-sdk-for-go/sdk/azcore to v1.23.0 - [ ] <!-- approvePr-branch=renovate/github.com-datadog-datadog-api-client-go-v2-2.x -->Update module github.com/DataDog/datadog-api-client-go/v2 to v2.64.0 - [ ] <!-- approvePr-branch=renovate/github.com-sirupsen-logrus-1.x -->Update module github.com/sirupsen/logrus to v1.10.0 - [ ] <!-- approvePr-branch=renovate/public.ecr.aws-docker-library-alpine-3.x -->Update public.ecr.aws/docker/library/alpine Docker tag to v3.24.1 - [ ] <!-- approvePr-branch=renovate/ureq-3.x-lockfile -->Update Rust crate ureq to v3.4.0 - [ ] <!-- approvePr-branch=renovate/npm-sentry-dotagents-3.x -->Update dependency npm:@sentry/dotagents to v3 --- > [!WARNING] > Renovate failed to look up the following dependencies: `Failed to look up go package github.com/vishvananda/netlink: no-result`, `Failed to look up go package github.com/itchyny/gojq: no-result`. > > Files affected: `go.mod`, `pkg/fleet/installer/go.mod`, `pkg/util/jsonquery/go.mod` --- ## Other Branches The following updates are pending. To force the creation of a PR, click on a checkbox below. - [ ] <!-- other-branch=renovate/integrations-core-digest -->Update integrations-core digest to 84ce638 - [ ] <!-- other-branch=renovate/aws-sdk-go-v2 -->Update aws-sdk-go-v2 (`github.com/aws/aws-sdk-go-v2`, `github.com/aws/aws-sdk-go-v2/config`, `github.com/aws/aws-sdk-go-v2/credentials`, `github.com/aws/aws-sdk-go-v2/service/ec2`, `github.com/aws/aws-sdk-go-v2/service/ecr`, `github.com/aws/aws-sdk-go-v2/service/ecs`, `github.com/aws/aws-sdk-go-v2/service/eks`, `github.com/aws/aws-sdk-go-v2/service/rds`, `github.com/aws/aws-sdk-go-v2/service/s3`, `github.com/aws/aws-sdk-go-v2/service/secretsmanager`, `github.com/aws/aws-sdk-go-v2/service/ssm`, `github.com/aws/aws-sdk-go-v2/service/sts`) - [ ] <!-- other-branch=renovate/github.com-go-delve-delve-1.x -->Update module github.com/go-delve/delve to v1.27.1 - [ ] <!-- other-branch=renovate/github.com-google-go-containerregistry-0.x -->Update module github.com/google/go-containerregistry to v0.21.9 ## Open The following updates have all been created. To force a retry/rebase of any, click on a checkbox below. - [ ] <!-- rebase-branch=renovate/go-github.com-datadog-dd-trace-go-v2-vulnerability -->[Update module github.com/DataDog/dd-trace-go/v2 to v2.8.1 [SECURITY]](../pull/53708) - [ ] <!-- rebase-branch=renovate/datadog-datadog-agent-dev-0.x -->[Update dependency DataDog/datadog-agent-dev to v0.38.0](../pull/52555) - [ ] <!-- rebase-branch=renovate/sentry-dotagents-3.x -->[Update dependency @sentry/dotagents to v3](../pull/54802) - [ ] <!-- rebase-branch=renovate/github.com-datadog-dd-trace-go-v2-2.x -->[Update module github.com/DataDog/dd-trace-go/v2 to v2.9.1](../pull/52521) - [ ] <!-- rebase-branch=renovate/gawk-5.x -->[Update dependency gawk to v5.4.0](../pull/52963) - [ ] <!-- rebase-branch=renovate/kubernetes-monorepo -->[Update kubernetes monorepo to v0.36.3](../pull/51833) (`k8s.io/api`, `k8s.io/apiextensions-apiserver`, `k8s.io/apimachinery`, `k8s.io/cli-runtime`, `k8s.io/client-go`, `k8s.io/component-base`, `k8s.io/cri-api`, `k8s.io/cri-client`, `k8s.io/kube-aggregator`, `k8s.io/kubectl`, `k8s.io/kubelet`, `k8s.io/metrics`) - [ ] <!-- rebase-branch=renovate/github.com-godror-godror-0.x -->[Update module github.com/godror/godror to v0.51.0](../pull/53235) - [ ] <!-- rebase-branch=renovate/k8s.io-autoscaler-vertical-pod-autoscaler-1.x -->[Update module k8s.io/autoscaler/vertical-pod-autoscaler to v1.7.1](../pull/51852) - [ ] <!-- rebase-branch=renovate/k8s.io-kube-state-metrics-v2-2.x -->[Update module k8s.io/kube-state-metrics/v2 to v2.19.1](../pull/52895) - [ ] <!-- rebase-branch=renovate/sigs.k8s.io-custom-metrics-apiserver-1.x -->[Update module sigs.k8s.io/custom-metrics-apiserver to v1.36.0](../pull/52282) - [ ] <!-- rebase-branch=renovate/docker.io-library-ubuntu-26.x -->[Update docker.io/library/ubuntu Docker tag to v26](../pull/52153) - [ ] <!-- rebase-branch=renovate/docker.io-ubuntu-26.x -->[Update docker.io/ubuntu Docker tag to v26](../pull/50840) - [ ] <!-- rebase-branch=renovate/github.com-cloudfoundry-community-go-cfclient-v2-3.x -->[Update module github.com/cloudfoundry-community/go-cfclient/v2 to v3](../pull/53622) - [ ] <!-- rebase-branch=renovate/github.com-netsampler-goflow2-2.x -->[Update module github.com/netsampler/goflow2 to v2](../pull/53239) - [ ] <!-- rebase-branch=renovate/major-franz-go -->[Update module github.com/twmb/franz-go/pkg/kmsg to v2](../pull/53824) - [ ] <!-- rebase-all-open-prs -->**Click on this checkbox to rebase all open PRs at once** ## PR Closed (Blocked) The following updates are blocked by an existing closed PR. To recreate the PR, click on a checkbox below. - [ ] <!-- recreate-branch=renovate/rules_go-0.x -->[Update dependency rules_go to v0.62.0](../pull/54068) - [ ] <!-- recreate-branch=renovate/code.cloudfoundry.org-bbs-1.x -->[Update module code.cloudfoundry.org/bbs to v1.11.0](../pull/53818) - [ ] <!-- recreate-branch=renovate/github.com-aws-karpenter-provider-aws-1.x -->[Update module github.com/aws/karpenter-provider-aws to v1.14.0](../pull/53819) - [ ] <!-- recreate-branch=renovate/github.com-bazelbuild-rules_go-0.x -->[Update module github.com/bazelbuild/rules_go to v0.62.0](../pull/54057) - [ ] <!-- recreate-branch=renovate/gopkg.in-datadog-dd-trace-go.v1-1.x -->[Update module gopkg.in/DataDog/dd-trace-go.v1 to v1.74.8](../pull/52894) - [ ] <!-- recreate-branch=renovate/sigs.k8s.io-karpenter-1.x -->[Update module sigs.k8s.io/karpenter to v1.14.0](../pull/53820) - [ ] <!-- recreate-branch=renovate/chef-sugar-5.x -->[Update dependency chef-sugar to v5](../pull/51540) - [ ] <!-- recreate-branch=renovate/invoke-3.x -->[Update dependency invoke to v3](../pull/50838) - [ ] <!-- recreate-branch=renovate/code.cloudfoundry.org-bbs-models-1.x -->[Update module code.cloudfoundry.org/bbs/models to v1](../pull/53823) - [ ] <!-- recreate-branch=renovate/github.com-santhosh-tekuri-jsonschema-v5-6.x -->[Update module github.com/santhosh-tekuri/jsonschema/v5 to v6](../pull/54069) - [ ] <!-- recreate-branch=renovate/go.etcd.io-etcd-client-v2-3.x -->[Update module go.etcd.io/etcd/client/v2 to v3](../pull/53825) - [ ] <!-- recreate-branch=renovate/go.yaml.in-yaml-v2-3.x -->[Update module go.yaml.in/yaml/v2 to v3](../pull/53527) ## Detected Dependencies > [!NOTE] > Detected dependencies section has been truncated <details><summary>bazel-module (2)</summary> <blockquote> <details><summary>deps/repos.MODULE.bazel</summary> </details> <details><summary>MODULE.bazel (20)</summary> - `bazel_lib 3.7.1` - `bazel_skylib 1.9.2` - `gawk 5.3.2.bcr.7` → [Updates: `5.4.0`] - `gazelle 0.52.2` - `libarchive 3.8.1.bcr.2` - `platforms 1.1.0` - `re.bzl 0.3.1` - `rules_cc 0.2.22` - `rules_flex 0.4.1` - `rules_go 0.61.1` → [Updates: `0.62.0`] - `rules_m4 0.3.bcr.1` - `rules_multitool 1.11.1` - `rules_python 2.2.0` - `rules_rs 0.0.27` → [Updates: `0.0.102`] - `rules_rust 0.73.0` - `rules_rust_prost 0.73.0` - `rules_shell 0.8.0` - `toml.bzl 0.4.1` - `rules_testing 0.9.0` - `apple_support 2.8.0` </details> </blockquote> </details> <details><summary>bazelisk (1)</summary> <blockquote> <details><summary>.bazelversion</summary> </details> </blockquote> </details> <details><summary>bitbucket-pipelines (1)</summary> <blockquote> <details><summary>.gitlab/.pre/cancel-prev-pipelines.yml</summary> </details> </blockquote> </details> <details><summary>bundler (1)</summary> <blockquote> <details><summary>omnibus/Gemfile (2)</summary> - `chef-sugar v3.6.0` → [Updates: `v5.1.12`] - `mixlib-cli '~> 2.1.0'` </details> </blockquote> </details> <details><summary>cargo (9)</summary> <blockquote> <details><summary>Cargo.toml (57)</summary> - `anyhow 1.0.98` - `cap-std 4.0` - `dd_sds =0.1.0-20260803-1e4349aada52` → [Updates: `=0.1.0-20260813-972b5d8d1827`] - `caps 0.5` - `chrono 0.4` - `clap 4.5` → [Updates: `4.5`] - `elf 0.8.0` - `glob-match 0.2` - `http-body-util 0.1` → [Updates: `0.1`] - `hostname 0.4` - `hyper 1` - `hyper-util 0.1` - `libc 0.2` - `log 0.4` - `prost 0.14` - `prost-build 0.14` - `prost-types 0.14` - `protoc-gen-prost 0.5` - `protoc-gen-tonic 0.5` - `lru 0.18.0` - `memchr 2.7.6` - `nom 8.0` - `normalize-path 0.2` - `phf 0.14` - `rawzip 0.5.0` - `xml-rs 1.0` - `rmp-serde 1.3` - `serde 1.0.219` - `serde_json 1.0` - `serde_yaml 0.9` - `time 0.3` - `thiserror 2.0.12` → [Updates: `2.0.12`] - `tokio 1` - `tokio-stream 0.1` - `tonic 0.14` - `tonic-build 0.14` - `tonic-prost 0.14` - `tonic-prost-build 0.14` - `tonic-reflection 0.14` - `ureq 3.0` → [Updates: `3.0`] - `uzers 0.12` - `walkdir 2` - `saphyr-parser 0.0.11` - `yaml-rust2 0.11` - `zip 8.0` - `flate2 1.1` - `tower 0.5` - `uuid 1` - `windows-registry 0.6` - `windows-sys 0.61` - `dircpy 0.3.19` - `regex 1` - `memmap2 0.9` - `nix 0.31` - `scopeguard 1.2` - `temp-env 0.3` - `tempfile 3.0` </details> <details><summary>cmd/ai_prompt_logger/Cargo.toml</summary> </details> <details><summary>comp/core/log/rust/Cargo.toml</summary> </details> <details><summary>pkg/collector/sharedlibrary/rustchecks/checks/datasecurity/Cargo.toml (1)</summary> - `postgres 0.19` </details> <details><summary>pkg/collector/sharedlibrary/rustchecks/checks/example/Cargo.toml</summary> </details> <details><summary>pkg/collector/sharedlibrary/rustchecks/core/Cargo.toml</summary> </details> <details><summary>pkg/discovery/module/rust/Cargo.toml</summary> </details> <details><summary>pkg/privateactionrunner/par-control/Cargo.toml</summary> </details> <details><summary>pkg/procmgr/rust/Cargo.toml</summary> </details> </blockquote> </details> <details><summary>docker-compose (36)</summary> <blockquote> <details><summary>cmd/host-profiler/docker-compose.yml (1)</summary> - `registry.datadoghq.com/agent 7` </details> <details><summary>pkg/collector/corechecks/oracle/compose/docker-compose.yml</summary> </details> <details><summary>pkg/discovery/module/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/amqp/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/http/testutil/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/kafka/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/mongo/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/mysql/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/postgres/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/redis/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/tls/gotls/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/protocols/tls/nodejs/testdata/docker-compose-ubuntu.yml</summary> </details> <details><summary>pkg/network/protocols/tls/nodejs/testdata/docker-compose.yml</summary> </details> <details><summary>pkg/network/tracer/testdata/dnsworkload/docker-compose.yml</summary> </details> <details><summary>pkg/network/usm/testdata/bio_leak_test/docker-compose.yml</summary> </details> <details><summary>pkg/network/usm/testdata/musl/docker-compose.yml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/dogstatsd/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/jmxfetch/docker-compose-all-metrics.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/jmxfetch/docker-compose-slow-metrics.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/jmxfetch/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/logger/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/datadog/apps/redis/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/integration/etcd/docker-compose.yaml</summary> </details> <details><summary>test/e2e-framework/components/integration/kafka/docker-compose.yaml (3)</summary> - `confluentinc/cp-kafka 7.9.8` → [Updates: `7.9.9`, `8.3.0`] - `confluentinc/cp-kafka 7.9.8` → [Updates: `7.9.9`, `8.3.0`] - `confluentinc/cp-kafka 7.9.8` → [Updates: `7.9.9`, `8.3.0`] </details> <details><summary>test/e2e-framework/components/integration/postgres/docker-compose.yaml (2)</summary> - `postgres 16` → [Updates: `17`] - `postgres 16` → [Updates: `17`] </details> <details><summary>test/e2e-framework/components/integration/redisdb/docker-compose.yaml (2)</summary> - `redis 7.2` → [Updates: `7.4`, `8.2`] - `redis 7.2` → [Updates: `7.4`, `8.2`] </details> <details><summary>test/fakeintake/docker-compose.yaml</summary> </details> <details><summary>test/new-e2e/examples/testfixtures/docker-compose.fake-process.yaml</summary> </details> <details><summary>test/new-e2e/examples/testfixtures/docker-compose.lighttpd.yaml</summary> </details> <details><summary>test/new-e2e/tests/agent-health/fixtures/docker-compose.busybox.yaml</summary> </details> <details><summary>test/new-e2e/tests/discovery/testdata/compose/docker-compose.configfilesdiscovery-kafka.yaml</summary> </details> <details><summary>test/new-e2e/tests/discovery/testdata/compose/docker-compose.configfilesdiscovery-redis.yaml</summary> </details> <details><summary>test/new-e2e/tests/discovery/testdata/compose/docker-compose.fake-krakend.yaml</summary> </details> <details><summary>test/new-e2e/tests/fips-compliance/fixtures/docker-compose-cluster-agent.yaml</summary> </details> <details><summary>test/new-e2e/tests/fips-compliance/fixtures/docker-compose-fips-server.yaml</summary> </details> <details><summary>test/new-e2e/tests/fips-compliance/fixtures/docker-compose.yaml</summary> </details> </blockquote> </details> <details><summary>dockerfile (15)</summary> <blockquote> <details><summary>Dockerfiles/agent-ddot/Dockerfile</summary> </details> <details><summary>Dockerfiles/agent-ddot/Dockerfile.agent-otel (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/agent/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/agent/windows/amd64/Dockerfile (1)</summary> - `mcr.microsoft.com/dotnet/sdk 9.0-windowsservercore-ltsc2019` </details> <details><summary>Dockerfiles/base-image/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/cluster-agent/Dockerfile (2)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/ddot-ebpf/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>Dockerfiles/dogstatsd/alpine/Dockerfile (1)</summary> - `public.ecr.aws/docker/library/alpine 3.23.3` → [Updates: `3.24.1`] </details> <details><summary>Dockerfiles/otel-agent/Dockerfile (1)</summary> - `docker.io/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>test/e2e-framework/resources/local/podman/data/Dockerfile (1)</summary> - `docker.io/library/ubuntu 24.04` → [Updates: `26.04`] </details> <details><summary>test/fakeintake/Dockerfile (2)</summary> - `docker.io/library/golang 1.26.5` - `docker.io/library/alpine 3.24.1` </details> <details><summary>tools/ebpf/Dockerfiles/Dockerfile-process-agent-dev</summary> </details> <details><summary>tools/ebpf/Dockerfiles/Dockerfile-security-agent-dev</summary> </details> <details><summary>tools/gdb/Dockerfile (1)</summary> - `registry.datadoghq.com/agent 7` </details> <details><summary>tools/host-profiler/Dockerfile</summary> </details> </blockquote> </details> <details><summary>github-actions (45)</summary> <blockquote> <details><summary>.github/actions/bazel-cache/action.yml (2)</summary> - `actions/cache v6.1.0@55cc8345863c7cc4c66a329aec7e433d2d1c52a9` - `actions/cache v6.1.0@55cc8345863c7cc4c66a329aec7e433d2d1c52a9` </details> <details><summary>.github/actions/deps-tidy-push/action.yml</summary> </details> <details><summary>.github/actions/deps-tidy-setup/action.yml (1)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` </details> <details><summary>.github/actions/install-dda/action.yml (3)</summary> - `actions/cache v6.1.0@55cc8345863c7cc4c66a329aec7e433d2d1c52a9` - `DataDog/datadog-agent-dev install@00e4a423088309efce1d5ba6b8c5366eef648710` - `DataDog/datadog-agent-dev install@00e4a423088309efce1d5ba6b8c5366eef648710` </details> <details><summary>.github/workflows/add-dependabot-pr-to-mq.yml (3)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/add-label-community-pr.yml (2)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/add-label-pr.yml (3)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/add-milestone.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/agenttelemetry-metric-reminder.yml (1)</summary> - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/ask-review.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/assess-permissions.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/assign-issue.yml (1)</summary> - `DataDog/issue-triage-action v1.0.1@b39f0bc12abc52fe8aa70dc9b9353bf307a13219` </details> <details><summary>.github/workflows/backport-pr.yml (4)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/buildimages-update.yml (5)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/chase-for-qa-cards.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/check-issue-status.yml (5)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/check-skip.yml</summary> </details> <details><summary>.github/workflows/cla.yml (2)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `contributor-assistant/github-action v2.6.1@ca4a40a7d1004f18d9960b404b97e5f30a505a08` </details> <details><summary>.github/workflows/code-review-complexity.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/code-review.yml (1)</summary> - `DataDog/code-review-action v1.1.0@56d6862711348b11ec2603edfb29c52c09f4b84c` </details> <details><summary>.github/workflows/codex-review-draft.yml (1)</summary> - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/codex-review-ready-for-review.yml</summary> </details> <details><summary>.github/workflows/collector-generate-and-update.yml (5)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `slackapi/slack-github-action v3.0.5@0d95c9a7becc1e6e297d76df9bc735c44f4cbcbc` → [Updates: `v4.0.0`] </details> <details><summary>.github/workflows/create-rc-pr.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/cws-btfhub-sync.yml (11)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `actions/upload-artifact v7.0.1@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `actions/download-artifact v8.0.1@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c` - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `ubuntu 24.04` - `ubuntu 24.04` </details> <details><summary>.github/workflows/deps-tidy.yml (7)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `dtolnay/rust-toolchain v1@e97e2d8cc328f1b50210efc529dca0028893a2d9` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `rust stable` </details> <details><summary>.github/workflows/do-not-merge.yml</summary> </details> <details><summary>.github/workflows/docs-dev.yml (8)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/cache v4.3.0@0057852bfaa89a56745cba8c7296529d2fc39830` → [Updates: `v6.1.0`] - `actions/upload-artifact v7.0.1@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a` - `actions/download-artifact v8.0.1@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c` - `peaceiris/actions-gh-pages v4.1.0@84c30a85c19949d7eee79c4ff27748b70285e453` </details> <details><summary>.github/workflows/go-update-commenter.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/github-script v9.0.0@3a2844b7e9c422d3c10d287c895573f7108da1b3` </details> <details><summary>.github/workflows/gohai.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] </details> <details><summary>.github/workflows/label-analysis.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/labeler.yml (1)</summary> - `actions/labeler v6.2.0@b8dd2d9be0f68b860e7dae5dae7d772984eacd6d` → [Updates: `v7.0.0`] </details> <details><summary>.github/workflows/markdown-lint-check.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `tcort/github-action-markdown-link-check v1.1.2@e7c7a18363c842693fadde5d41a3bd3573a7a225` → [Updates: `v1.1.3`] </details> <details><summary>.github/workflows/push-bazel-cache.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/report-merged-pr.yml (2)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `DataDog/dd-sts-action v1.0.0@2e8187910199bd93129520183c093e19aa585c75` → [Updates: `v1.0.5`] </details> <details><summary>.github/workflows/slapr_backport.yml (1)</summary> - `DataDog/slapr 1.1.0@95312d6b8528460243ba27c7f8167bfe20a68bec` </details> <details><summary>.github/workflows/slapr.yml (3)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `DataDog/slapr 1.1.0@95312d6b8528460243ba27c7f8167bfe20a68bec` </details> <details><summary>.github/workflows/stale.yml (2)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/stale v10.4.0@1e223db275d687790206a7acac4d1a11bd6fe629` → [Updates: `v11.0.0`] </details> <details><summary>.github/workflows/test-devcontainer.yml (3)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-node v6.5.0@249970729cb0ef3589644e2896645e5dc5ba9c38` → [Updates: `v7.0.0`] </details> <details><summary>.github/workflows/update-dependencies.yml (4)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/update-ebpf-profiler-branch.yml (4)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-go v6.5.0@924ae3a1cded613372ab5595356fb5720e22ba16` → [Updates: `v7.0.0`] - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` </details> <details><summary>.github/workflows/update-kubernetes-versions.yml (8)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-python v6.3.0@ece7cb06caefa5fff74198d8649806c4678c61a1` → [Updates: `v7.0.0`] - `helm/kind-action v1.14.0@ef37e7f390d99f746eb8b610417061a60e82a6cc` - `aws-actions/configure-aws-credentials v6.2.2@517a711dbcd0e402f90c77e7e2f81e849156e31d` → [Updates: `v6.2.3`] - `docker/login-action v4.4.0@af1e73f918a031802d376d3c8bbc3fe56130a9b0` → [Updates: `v4.6.0`] - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `python 3.14` </details> <details><summary>.github/workflows/upgrade-python-patch-version.yml (5)</summary> - `DataDog/dd-octo-sts-action v1.0.4@96a25462dbcb10ebf0bfd6e2ccc917d2ab235b9a` - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] - `actions/setup-python v6.3.0@ece7cb06caefa5fff74198d8649806c4678c61a1` → [Updates: `v7.0.0`] - `peter-evans/create-pull-request v8.1.1@5f6978faf089d4d20b00c7766989d076bb2fc7f1` - `python 3.14` </details> <details><summary>.github/workflows/validate-renovate-deps.yml (1)</summary> - `actions/checkout v7.0.0@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0` → [Updates: `v7.0.1`] </details> <details><summary>.github/workflows/warn-failed-dependabot-pr.yml</summary> </details> </blockquote> </details> <details><summary>gomod (80)</summary> <blockquote> <details><summary>comp/anomalydetection/observer/def/go.mod</summary> </details> <details><summary>comp/anomalydetection/recorder/def/go.mod</summary> </details> <details><summary>comp/anomalydetection/severityevents/def/go.mod</summary> </details> <details><summary>comp/api/api/def/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/agenttelemetry/def/go.mod</summary> </details> <details><summary>comp/core/agenttelemetry/fx/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/agenttelemetry/impl/go.mod (7)</summary> - `github.com/DataDog/zstd v1.5.8-0.20260421145859-31a7e515a571@31a7e515a571` → [Updates: `v1.5.8-0.20260421145859-31a7e515a571`] - `github.com/prometheus/client_model v0.6.2` - `github.com/robfig/cron/v3 v3.0.1` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/core/config/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/configstreamconsumer/def/go.mod</summary> </details> <details><summary>comp/core/configsync/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/delegatedauth/api/cloudauth/aws/go.mod (2)</summary> - `github.com/aws/aws-sdk-go-v2 v1.43.3` → [Updates: `v1.43.4`] - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/delegatedauth/go.mod (2)</summary> - `github.com/cenkalti/backoff/v7 v7.0.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/flare/builder/go.mod</summary> </details> <details><summary>comp/core/flare/types/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/hostname/hostnameinterface/def/go.mod</summary> </details> <details><summary>comp/core/hostname/hostnameinterface/go.mod</summary> </details> <details><summary>comp/core/hostname/hostnameinterface/mock/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/ipc/def/go.mod</summary> </details> <details><summary>comp/core/ipc/httphelpers/go.mod (2)</summary> - `github.com/mdlayher/vsock v1.3.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/ipc/impl/go.mod (2)</summary> - `github.com/gofrs/flock v0.13.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/ipc/mock/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/def/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/fx/go.mod</summary> </details> <details><summary>comp/core/log/impl-trace/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/impl/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/log/mock/go.mod</summary> </details> <details><summary>comp/core/secrets/def/go.mod</summary> </details> <details><summary>comp/core/secrets/fx/go.mod</summary> </details> <details><summary>comp/core/secrets/impl/go.mod (4)</summary> - `github.com/benbjohnson/clock v1.3.5` - `github.com/json-iterator/go v1.1.12` - `github.com/stretchr/testify v1.11.1` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/secrets/mock/go.mod (1)</summary> - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/secrets/noop-impl/go.mod</summary> </details> <details><summary>comp/core/secrets/utils/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/core/status/go.mod (4)</summary> - `github.com/dustin/go-humanize v1.0.1` - `github.com/fatih/color v1.19.0` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/status/statusimpl/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/tagger/def/go.mod</summary> </details> <details><summary>comp/core/tagger/fx-remote/go.mod (1)</summary> - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/core/tagger/generic_store/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/impl-remote/go.mod (5)</summary> - `github.com/cenkalti/backoff/v7 v7.0.0` - `github.com/google/uuid v1.6.0` - `github.com/mdlayher/vsock v1.3.0` - `github.com/stretchr/testify v1.11.1` - `google.golang.org/grpc v1.83.0` </details> <details><summary>comp/core/tagger/origindetection/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/subscriber/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/tags/go.mod</summary> </details> <details><summary>comp/core/tagger/telemetry/go.mod</summary> </details> <details><summary>comp/core/tagger/types/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/tagger/utils/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/core/telemetry/go.mod (6)</summary> - `github.com/prometheus/client_golang v1.24.1` - `github.com/prometheus/client_model v0.6.2` - `github.com/prometheus/common v0.70.1` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.uber.org/fx v1.24.0` </details> <details><summary>comp/def/go.mod (1)</summary> - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/forwarder/defaultforwarder/go.mod (6)</summary> - `github.com/benbjohnson/clock v1.3.5` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.uber.org/fx v1.24.0` - `go.uber.org/multierr v1.11.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/forwarder/orchestrator/orchestratorinterface/go.mod</summary> </details> <details><summary>comp/host-profiler/symboluploader/testdata/go.mod</summary> </details> <details><summary>comp/logs-library/go.mod (4)</summary> - `github.com/DataDog/agent-payload/v5 v5.0.209` - `github.com/benbjohnson/clock v1.3.5` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` </details> <details><summary>comp/logs/agent/config/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/atomic v1.11.0` - `go.yaml.in/yaml/v3 v3.0.5` </details> <details><summary>comp/netflow/payload/go.mod</summary> </details> <details><summary>comp/otelcol/collector-contrib/def/go.mod</summary> </details> <details><summary>comp/otelcol/collector-contrib/impl/go.mod</summary> </details> <details><summary>comp/otelcol/converter/def/go.mod</summary> </details> <details><summary>comp/otelcol/converter/impl/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/ddflareextension/def/go.mod</summary> </details> <details><summary>comp/otelcol/ddflareextension/impl/go.mod (6)</summary> - `github.com/google/go-cmp v0.7.0` - `github.com/google/uuid v1.6.0` - `github.com/mohae/deepcopy v0.0.0-20170929034955-c48cc78d4826@c48cc78d4826` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` - `go.yaml.in/yaml/v2 v2.4.4` → [Updates: `v3.0.5`] </details> <details><summary>comp/otelcol/ddflareextension/types/go.mod</summary> </details> <details><summary>comp/otelcol/ddprofilingextension/def/go.mod</summary> </details> <details><summary>comp/otelcol/ddprofilingextension/impl/go.mod (3)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/DataDog/dd-trace-go/v2 v2.9.0` → [Updates: `v2.9.1`] - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/otelcol/logsagentpipeline/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/logsagentpipeline/logsagentpipelineimpl/go.mod</summary> </details> <details><summary>comp/otelcol/otlp/components/connector/datadogconnector/go.mod (5)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/google/go-cmp v0.7.0` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/otelcol/otlp/components/datadogconfig/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/otlp/components/exporter/datadogexporter/go.mod (4)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/otelcol/otlp/components/exporter/logsagentexporter/go.mod (4)</summary> - `github.com/DataDog/agent-payload/v5 v5.0.209` - `github.com/patrickmn/go-cache v2.1.0+incompatible` - `github.com/stretchr/testify v1.11.1` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/otlp/components/exporter/serializerexporter/go.mod (8)</summary> - `github.com/google/go-cmp v0.7.0` - `github.com/stretchr/testify v1.11.1` - `github.com/tinylib/msgp v1.6.4` - `go.uber.org/fx v1.24.0` - `go.uber.org/multierr v1.11.0` - `go.uber.org/zap v1.28.0` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] - `go.uber.org/atomic v1.11.0` </details> <details><summary>comp/otelcol/otlp/components/metricsclient/go.mod (2)</summary> - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/stretchr/testify v1.11.1` </details> <details><summary>comp/otelcol/otlp/components/processor/infraattributesprocessor/go.mod (3)</summary> - `github.com/stretchr/testify v1.11.1` - `go.uber.org/fx v1.24.0` - `go.uber.org/zap v1.28.0` </details> <details><summary>comp/otelcol/otlp/testutil/go.mod (3)</summary> - `github.com/DataDog/sketches-go v1.4.8` - `github.com/stretchr/testify v1.11.1` - `google.golang.org/protobuf v1.36.12-0.20260116114154-8c4c4ae446ca@8c4c4ae446ca` → [Updates: `v1.36.12`] </details> <details><summary>comp/otelcol/status/def/go.mod</summary> </details> <details><summary>comp/otelcol/status/impl/go.mod (2)</summary> - `github.com/stretchr/testify v1.11.1` - `go.yaml.in/yaml/v3 v3.0.5` </details> <details><summary>comp/serializer/logscompression/go.mod</summary> </details> <details><summary>comp/serializer/metricscompression/go.mod</summary> </details> <details><summary>comp/trace/agent/def/go.mod</summary> </details> <details><summary>comp/trace/compression/def/go.mod</summary> </details> <details><summary>comp/trace/compression/impl-gzip/go.mod</summary> </details> <details><summary>comp/trace/compression/impl-zstd/go.mod (1)</summary> - `github.com/DataDog/zstd v1.5.8-0.20260421145859-31a7e515a571@31a7e515a571` → [Updates: `v1.5.8-0.20260421145859-31a7e515a571`] </details> <details><summary>go.mod (115)</summary> - `code.cloudfoundry.org/bbs v1.3.0` → [Updates: `v1.11.0`] - `code.cloudfoundry.org/bbs/models v0.0.0-20260618205254-dc4b9f8d5bc9@dc4b9f8d5bc9` → [Updates: `v1.8.0`] - `code.cloudfoundry.org/garden v0.0.0-20260617020226-a9e754564bb5@a9e754564bb5` → [Updates: `v0.0.0-20260811183727-158508cf0d71`] - `code.cloudfoundry.org/lager/v3 v3.78.0` → [Updates: `v3.81.0`] - `dario.cat/mergo v1.0.2` - `github.com/Azure/azure-sdk-for-go/sdk/azcore v1.22.0` → [Updates: `v1.23.0`] - `github.com/Azure/azure-sdk-for-go/sdk/azidentity v1.14.0` - `github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/azsecrets v1.5.0` - `github.com/CycloneDX/cyclonedx-go v0.11.0` - `github.com/DATA-DOG/go-sqlmock v1.5.2` - `github.com/DataDog/agent-payload/v5 v5.0.209` - `github.com/DataDog/datadog-api-client-go/v2 v2.62.0` → [Updates: `v2.64.0`] - `github.com/DataDog/datadog-go/v5 v5.9.0` - `github.com/DataDog/datadog-operator/api v0.0.0-20260807013103-1518bb55e423@1518bb55e423` → [Updates: `v0.0.0-20260812212652-5f8a87676244`] - `github.com/DataDog/datadog-traceroute v1.0.19` - `github.com/DataDog/dd-policy-engine/go v0.0.0-20260730181922-c5e419a4ec7d@c5e419a4ec7d` → [Updates: `v0.0.0-20260803230307-dd41045a4bb2`] - `github.com/DataDog/dd-trace-go/v2 v2.9.0` → [Updates: `v2.9.1`] - `github.com/DataDog/ddtrivy v0.0.0-20260519164847-bf6bcaf2f9b7@bf6bcaf2f9b7` → [Updates: `v0.0.0-20260519164847-bf6bcaf2f9b7`] - `github.com/DataDog/ebpf-manager v0.8.1` - `github.com/DataDog/go-acl v1.0.1` - `github.com/DataDog/go-sqllexer v0.2.4` - `github.com/DataDog/jsonapi v0.13.0` - `github.com/DataDog/rshell v0.0.24` - `github.com/DataDog/sketches-go v1.4.8` - `github.com/DataDog/watermarkpodautoscaler/apis v0.0.0-20250108152814-82e58d0231d1@82e58d0231d1` → [Updates: `v0.0.0-20260803084540-a82e1114b53b`] - `github.com/DataDog/zstd v1.5.8-0.20260421145859-31a7e515a571@31a7e515a571` → [Updates: `v1.5.8-0.20260421145859-31a7e515a571`] - `github.com/Masterminds/semver/v3 v3.5.0` - `github.com/Masterminds/sprig/v3 v3.3.0` - `github.com/Microsoft/go-winio v0.6.2` - `github.com/Microsoft/hcsshim v0.14.1` - `github.com/NVIDIA/go-nvml v0.13.1-0` - `github.com/ProtonMail/go-crypto v1.4.1` - `github.com/acobaugh/osrelease v0.1.0` - `github.com/alecthomas/units v0.0.0-20240927000941-0f3dac36c52b@0f3dac36c52b` - `github.com/aptly-dev/aptly v1.6.3` - `github.com/aquasecurity/trivy v0.72.0` → [Updates: `v0.73.0`] - `github.com/aquasecurity/trivy-db v0.0.0-20251222105351-a833f47f8f0d@a833f47f8f0d` → [Updates: `v0.0.0-20260813095258-0e0340a01b57`] - `github.com/aws/aws-sdk-go-v2 v1.43.3` → [Updates: `v1.43.4`] - `github.com/aws/aws-sdk-go-v2/config v1.32.34` → [Updates: `v1.32.35`] - `github.com/aws/aws-sdk-go-v2/credentials v1.19.33` → [Updates: `v1.19.34`] - `github.com/aws/aws-sdk-go-v2/service/ec2 v1.318.1` → [Updates: `v1.319.1`] - `github.com/aws/aws-sdk-go-v2/service/rds v1.120.1` → [Updates: `v1.124.1`] - `github.com/aws/aws-sdk-go-v2/service/secretsmanager v1.44.0` → [Updates: `v1.44.4`] - `github.com/aws/aws-sdk-go-v2/service/ssm v1.73.0` → [Updates: `v1.73.4`] - `github.com/aws/aws-sdk-go-v2/service/sts v1.45.3` → [Updates: `v1.45.4`] - `github.com/aws/karpenter-provider-aws v1.9.0` → [Updates: `v1.14.0`] - `github.com/aymerick/raymond v2.0.2+incompatible` - `github.com/bazelbuild/rules_go v0.61.1` → [Updates: `v0.62.0`] - `github.com/beevik/ntp v1.5.0` - `github.com/benbjohnson/clock v1.3.5` - `github.com/bhmj/jsonslice v1.1.3` - `github.com/blabber/go-freebsd-sysctl v0.0.0-20201130114544-503969f39d8f@503969f39d8f` - `github.com/bmatcuk/doublestar/v4 v4.10.0` - `github.com/cenkalti/backoff/v7 v7.0.0` - `github.com/cespare/xxhash/v2 v2.3.0` - `github.com/cilium/ebpf v0.22.0` - `github.com/clbanning/mxj/v2 v2.7.0` - `github.com/cloudflare/cbpfc v0.0.0-20260219140841-0661ad29132c@0661ad29132c` → [Updates: `v0.0.0-20260805072904-7ac485fd93e1`] - `github.com/cloudfoundry-community/go-cfclient/v2 v2.0.1-0.20230503155151-3d15366c5820@3d15366c5820` → [Updates: `v3.0.0-beta.1`] - `github.com/containerd/cgroups/v3 v3.1.3` - `github.com/containerd/containerd/api v1.11.1` - `github.com/containerd/containerd/v2 v2.2.5` → [Updates: `v2.3.3`] - `github.com/containerd/errdefs v1.0.0` - `github.com/containerd/typeurl/v2 v2.3.0` - `github.com/containernetworking/cni v1.3.0` - `github.com/coreos/go-semver v0.3.1` - `github.com/coreos/go-systemd/v22 v22.7.0` - `github.com/creack/pty v1.1.24` - `github.com/cri-o/ocicni v0.5.0` - `github.com/cyphar/filepath-securejoin v0.7.0` - `github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc@d8f796af33cc` - `github.com/distribution/reference v0.6.0` - `github.com/dustin/go-humanize v1.0.1` - `github.com/elastic/go-freelru v0.16.0` - `github.com/elastic/go-libaudit/v2 v2.6.2` - `github.com/elastic/go-seccomp-bpf v1.6.0` - `github.com/envoyproxy/gateway v1.7.4` → [Updates: `v1.8.3`] - `github.com/evanphx/json-patch/v5 v5.9.11` - `github.com/fatih/color v1.19.0` - `github.com/fatih/structtag v1.2.0` - `github.com/freddierice/go-losetup v0.0.0-20220711213114-2a14873012db@2a14873012db` - `github.com/ghodss/yaml v1.0.1-0.20220118164431-d8423dcdf344@d8423dcdf344` - `github.com/glaslos/ssdeep v1.0.0` - `github.com/go-delve/delve v1.27.0` → [Updates: `v1.27.1`] - `github.com/go-jose/go-jose/v4 v4.1.4` - `github.com/go-json-experiment/json v0.0.0-20250517221953-25912455fbc8@25912455fbc8` → [Updates: `v0.0.0-20260623181947-01eb4420fa68`] - `github.com/go-ole/go-ole v1.3.0` - `github.com/go-sql-driver/mysql v1.10.0` - `github.com/go-viper/mapstructure/v2 v2.5.0` - `github.com/go-zookeeper/zk v1.0.4` - `github.com/gobwas/glob v0.2.3` - `github.com/goccy/go-yaml v1.19.2` - `github.com/gocomply/scap v0.1.3` - `github.com/godbus/dbus/v5 v5.2.2` - `github.com/godror/godror v0.50.0` → [Updates: `v0.51.0`] - `github.com/gogo/protobuf v1.3.2` - `github.com/golang-jwt/jwt/v5 v5.3.1` - `github.com/golang/groupcache v0.0.0-20241129210726-2c02b8208cf8@2c02b8208cf8` - `github.com/golang/mock v1.7.0-rc.1` - `github.com/google/btree v1.1.3` - `github.com/google/cel-go v0.29.2` → [Updates: `v0.30.0`] - `github.com/google/go-cmp v0.7.0` - `github.com/google/go-containerregistry v0.21.7` → [Updates: `v0.21.9`] - `github.com/google/gofuzz v1.2.0` - `github.com/google/gopacket v1.1.19` - `github.com/google/uuid v1.6.0` - `github.com/gorilla/websocket v1.5.4-0.20250319132907-e064f32e3674@e064f32e3674` - `github.com/gosnmp/gosnmp v1.44.0` - `github.com/grpc-ecosystem/go-grpc-middleware/v2 v2.3.3` - `github.com/h2non/filetype v1.1.3` - `github.com/hashicorp/consul/api/v2 v2.0.0` - `github.com/hashicorp/go-multierror v1.1.1` - `github.com/hashicorp/go-retryablehttp v0.7.8` - `github.com/hashicorp/go-version v1.9.0` - `github.com/hashicorp/golang-lru/v2 v2.0.7` </details> </blockquote> </details> --- - [ ] <!-- manual job -->Check this box to trigger a request for Renovate to run again on this repository",
          "url": "https://github.com/DataDog/datadog-agent/issues/33469",
          "createdAt": "2025-01-28T12:05:52Z",
          "updatedAt": "2026-08-13T18:01:09Z",
          "timestamp": "2026-08-13T18:01:09Z",
          "metrics": {
            "reactions": 0,
            "comments": 0
          },
          "labels": [
            "team/agent-devx",
            "pending",
            "oss/0"
          ],
          "author": "renovate[bot]",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:7c36e483bd002a8453be",
        "signalId": "github:DataDog/datadog-agent:pull_request:54659",
        "event": "changed",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54659",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(ndm): report workload balancing group state as inventory metadata",
          "text": "> **Note:** This PR was created by Claude. Stacked on #54652 — review that one first. ### What does this PR do? Adds a `comp/metadata/workloadbalancing` component, mirroring the existing `comp/metadata/haagent`. When Agent workload balancing is enabled it reports a `workload_balancing_metadata` inventory payload: ```json { \"hostname\": \"...\", \"workload_balancing_metadata\": { \"enabled\": true, \"groups\": {\"group-a\": \"active\", \"group-b\": \"standby\"} }, \"timestamp\": 1716985696922603000 } ``` It surfaces in three places: the inventory product, `agent status` (text and HTML), and the `/metadata/workload-balancing` endpoint. The flare picks it up as `workload-balancing.json`. Nothing is reported when workload balancing is disabled, which is the default. Unlike HA Agent, which has a single Agent-wide state, this Agent can hold a different state per group, so the payload carries a map rather than one string. ### Motivation `datadog.agent.workload_balancing.running` says a group is being run somewhere. It does not say which Agent holds it, or what the Agent itself thinks it holds. When a handoff does not land, the first question is which Agent believes it is active, and the inventory and status page are where that gets answered without shelling into a pod. ### Describe how you validated your changes - `go test -tags test ./comp/metadata/... ./cmd/agent/subcommands/run/... ./cmd/agent/subcommands/flare/...` — pass, including new tests for the payload, the copy semantics of the group map, the disabled case, and the status text/HTML renderers - `go build ./...` and `go vet -tags test ./comp/metadata/... ./cmd/agent/...` — clean - `dda inv linter.go --targets=./comp/metadata/workloadbalancing` — 0 issues - `dda inv components.lint-components --fix` and `bazel run //:gazelle` for the generated files No manual validation: the Remote Config product that populates the group states still needs backend registration.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54659",
          "createdAt": "2026-08-10T16:47:55Z",
          "updatedAt": "2026-08-13T18:00:57Z",
          "timestamp": "2026-08-13T18:00:57Z",
          "metrics": {
            "reactions": 0,
            "comments": 6
          },
          "labels": [
            "qa/done",
            "team/agent-runtimes",
            "team/fleet-remediation",
            "team/fleet-automation"
          ],
          "author": "matthewleese",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:5a8a952b8429cd5c7ba1",
        "signalId": "github:DataDog/datadog-agent:pull_request:54656",
        "event": "changed",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54656",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(ndm): emit a metric per workload balancing group",
          "text": "> **Note:** This PR was created by Claude. Stacked on #54652 — review that one first. ### What does this PR do? Emits `datadog.agent.workload_balancing.running` once per NDM workload balancing group the Agent knows about, tagged with: - `workload_balancing_group:<id>` - `workload_balancing_state:active|standby|unmanaged` It follows the shape of the existing `datadog.agent.ha_agent.running` metric and is emitted from the same place, `BufferedAggregator.appendDefaultSeries`. Nothing is emitted when workload balancing is disabled, which is the default. The `workloadbalancing` component is threaded into the aggregator through the demultiplexer, which is most of the diff. ### Motivation The interesting signal is the gap, not the value. Each group should be reported as `active` by exactly one Agent. If the assigned Agent goes away and the reassignment does not land, the group stops being reported as active anywhere, and that absence is visible in a way that a silently unpolled device is not. ### Describe how you validated your changes - `go test -tags test ./pkg/aggregator/... ./comp/aggregator/...` — pass, including two new tests covering the tags and states emitted per group and that a disabled component emits nothing - `go vet -tags test ./...` — clean across the module - `dda inv linter.go --targets=./pkg/aggregator,./comp/aggregator/demultiplexer/impl` — 0 issues - `bazel run //:gazelle` for the BUILD.bazel files No manual validation: the Remote Config product that populates the group states still needs backend registration.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54656",
          "createdAt": "2026-08-10T16:25:18Z",
          "updatedAt": "2026-08-13T18:00:57Z",
          "timestamp": "2026-08-13T18:00:57Z",
          "metrics": {
            "reactions": 0,
            "comments": 9
          },
          "labels": [
            "qa/done",
            "long review",
            "team/agent-integrations",
            "team/agent-metric-pipelines",
            "internal",
            "team/network-device-monitoring-core",
            "team/fleet-automation"
          ],
          "author": "matthewleese",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:851e42b237f8cf3e3a6b",
        "signalId": "github:DataDog/datadog-agent:pull_request:54795",
        "event": "changed",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54795",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "test(ndm): add e2e coverage for Agent Workload Balancing",
          "text": "> **Note:** This PR was created by Claude. ### What does this PR do? Adds the e2e test suite for Agent Workload Balancing that was called out as needed in #54652's original plan, and adds the one missing CLI surface found while auditing that plan for completeness. - `TestWorkloadBalancingRunningMetrics` / `TestWorkloadBalancingAddedToRCListeners` (`workloadbalancing_test.go`): mirrors `haagent_test.go`. Pushes an `NDM_AGENT_WORKLOAD_BALANCING` Remote Config payload via `RCAddConfig` against fakeintake, then asserts `datadog.agent.workload_balancing.running` (tagged `workload_balancing_group`/`workload_balancing_state`) and the `\"Add workload balancing RCListener\"` log line. - `TestWorkloadBalancingMetadata` (`workloadbalancing_metadata_test.go`): mirrors `haagent_metadata_test.go`. Pushes an RC assignment, then reads it back via `diagnose show-metadata workload-balancing`. - `cmd/agent/subcommands/diagnose/command.go`: adds the `show-metadata workload-balancing` subcommand. #54659 wired the metadata provider into inventory, flare, status, and the `/metadata/workload-balancing` HTTP endpoint, but left out the CLI subcommand that HA Agent has as `show-metadata ha-agent`. The metadata e2e test above needs it to read the payload the same way the HA Agent test does. - `.gitlab-ci.yml` / `.gitlab/test/e2e/e2e.yml`: adds a `new-e2e-workload-balancing` job and its change-triggering rule, following the `ha-agent` job pattern. - `.github/CODEOWNERS`: adds `/test/new-e2e/tests/workload-balancing`. ### Motivation This was the fourth piece of the originally planned agent-side work (component, metric, inventory metadata, e2e test), deferred because it was \"blocked on #53246 for Remote Config fakeintake support.\" That PR merged, so the blocker is gone. Not included here: a multi-host failover test analogous to `haagent_failover_test.go` (driving an actual handoff between two hosts). Left as a follow-up TODO in `workloadbalancing_test.go` rather than adding a large multi-VM test to this PR. ### Describe how you validated your changes - `go vet ./tests/workload-balancing/...` in `test/new-e2e` passes. - `gofmt` clean on all changed/added files. - Base branch merges (`mleese/ndm-device-handoff` + `mleese/ndm-workload-balancing-metric` + `mleese/ndm-workload-balancing-metadata`) were clean, no conflicts. - Not yet run against real infra (draft; depends on #54652, #54656, #54659 landing first). ### Additional Notes Stacked on top of `mleese/ndm-device-handoff` (#54652), and depends on `mleese/ndm-workload-balancing-metric` (#54656) and `mleese/ndm-workload-balancing-metadata` (#54659) both being merged into it — this branch already contains both of those changes merged in, since they're sibling branches rather than stacked on each other.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54795",
          "createdAt": "2026-08-12T19:04:08Z",
          "updatedAt": "2026-08-13T18:00:56Z",
          "timestamp": "2026-08-13T18:00:56Z",
          "metrics": {
            "reactions": 1,
            "comments": 7
          },
          "labels": [],
          "author": "matthewleese",
          "state": "closed",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:725f13a7eed3070b6287",
        "signalId": "github:DataDog/datadog-agent:pull_request:54594",
        "event": "changed",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54594",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] wire split runner ownership",
          "text": "### What does this PR do? Teaches the existing Go runner and Fx component to stand down when split mode is enabled on supported Linux and Windows host deployments, while retaining the executor subcommand used by `par-control`. Container deployments do not yet launch the replacement topology. Official Agent containers are detected through `configenv.IsContainerized()` (`DOCKER_DD_AGENT`), so a requested split deployment logs a warning and safely continues with the monolithic runner instead of black-holing PAR. Cluster Agent continues to use its existing in-process monolithic path. The resulting ownership invariant is explicit: exactly one process polls OPMS, and the monolith exits only when its replacement topology is available. ### Motivation Keep runner ownership and activation behavior separate from package and installer mechanics so reviewers can focus on preventing both duplicate polling and unsupported deployments standing down their only runner. ### Validation - `bazel test //comp/privateactionrunner/impl:impl_test` passes locally. - Focused coverage includes Linux and Windows hosts, Linux and Windows containers, and an unsupported host platform. - Private Action Runner build passes locally. ### Review fixes - Documented `idle_timeout_seconds`, which now drives two mechanisms: par-control stops an idle executor after this long, and the executor exits by itself after a longer multiple, which is what reclaims it when par-control is no longer running. - Documented that `procmgr_socket_path` falls back to the process manager's own `DD_PM_SOCKET_PATH` when unset. ### Stack PR 8 of 9. Based on #54593; followed by #54529.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54594",
          "createdAt": "2026-08-07T18:09:51Z",
          "updatedAt": "2026-08-13T18:00:51Z",
          "timestamp": "2026-08-13T18:00:51Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "medium review",
            "team/agent-build",
            "team/action-platform",
            "internal",
            "team/fleet-automation"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:f60df7a6b30b3aea1c7c",
        "signalId": "github:DataDog/datadog-agent:pull_request:54833",
        "event": "changed",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54833",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "SMP experiment selection and codeowners v2",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Classifies SMP experiments into three modes: always: as the name implies, they always run, these are the quality gates codeowners: these experiments x, owned by team y, are automatically triggered if the the PR touches a file owned by y optional: fully manual, label triggered set of experiments used for specific features ### Motivation ### Describe how you validated your changes ### Additional Notes No need for review yet, this is a POC that will be split",
          "url": "https://github.com/DataDog/datadog-agent/pull/54833",
          "createdAt": "2026-08-13T13:59:48Z",
          "updatedAt": "2026-08-13T18:00:44Z",
          "timestamp": "2026-08-13T18:00:44Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "team/agent-security",
            "long review",
            "team/agent-log-pipelines",
            "team/agent-devx",
            "team/action-platform",
            "internal",
            "smp/logs/syslog"
          ],
          "author": "cmetz100",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:f6f87268c3b62ebb55b0",
        "signalId": "github:DataDog/datadog-agent:pull_request:54591",
        "event": "changed",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54591",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] add par-control executor channel",
          "text": "### What does this PR do? Defines the local control-to-executor channel and implements both ends of it: - Adds the executor gRPC protocol and generated bindings. - Exposes executor health and readiness. - Synchronizes workflow signing keys. - Streams action dispatch outcomes. - Adds the Rust mTLS client and transport support. - Keeps the shared terminal `Outcome` model with the executor layer. This layer provides communication primitives only; polling and process-lifecycle policy remain in later layers. ### Motivation Create a narrow, authenticated local contract between `par-control` and the existing Go executor before introducing OPMS polling or orchestration. ### Validation - Focused Go tests pass locally. - Private Action Runner Go build passes locally. - Portable Rust tests pass locally; native-tls identity coverage requires Linux/Windows. ### Review fixes - **Transport**: 5s connect timeout on both the plain and the mTLS channel, and no panic path in the named-pipe retry loop. Also corrects module docs that claimed Windows named-pipe support was a follow-up while the named-pipe client sits in the same file. - Dropped the redundant `tokio-stream` dev-dependency, since this layer promotes it to a regular dependency. - README records the build caveats: the dev VM's empty `PKG_CONFIG_LIBDIR` breaks `openssl-sys` under cargo, proto-touching changes must be Bazel-verified (under `--cfg=bazel` the bindings come from a separate crate, so the orphan rule differs), and the TLS tests are Linux-only. ### Stack PR 5 of 9. Based on #54590; followed by #54592.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54591",
          "createdAt": "2026-08-07T17:50:14Z",
          "updatedAt": "2026-08-13T18:00:24Z",
          "timestamp": "2026-08-13T18:00:24Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:ce3d91a5f76fa4d89da8",
        "signalId": "github:DataDog/datadog-agent:pull_request:54793",
        "event": "changed",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54793",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Remove schemaBuilder and createschema command",
          "text": "### What does this PR do? Remove the `createschema` command and the schema builder config implementation. We no longer need to generate the schema. ### Motivation Cleanup now that schema is live and in use. ### Describe how you validated your changes CI ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54793",
          "createdAt": "2026-08-12T18:13:12Z",
          "updatedAt": "2026-08-13T17:59:52Z",
          "timestamp": "2026-08-13T17:59:52Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "component/system-probe",
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-build",
            "internal",
            "team/fleet-remediation",
            "team/fleet-automation"
          ],
          "author": "dustmop",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:9b8bdf0a5f6c44e39519",
        "signalId": "github:DataDog/datadog-agent:pull_request:54333",
        "event": "changed",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54333",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "Build with race detector",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Build with race detector. ### Motivation Make a custom build and give it a shot internally, to see if we can detect races. ### Describe how you validated your changes n/a ### Additional Notes [AGENTRUN-1159]: https://datadoghq.atlassian.net/browse/AGENTRUN-1159?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54333",
          "createdAt": "2026-08-03T05:47:18Z",
          "updatedAt": "2026-08-13T17:58:50Z",
          "timestamp": "2026-08-13T17:58:50Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "do-not-merge/hold",
            "changelog/no-changelog",
            "team/agent-apm",
            "component/system-probe",
            "team/agent-security",
            "team/ebpf-platform",
            "qa/done",
            "long review",
            "team/agent-runtimes",
            "team/agent-metric-pipelines",
            "team/agent-devx",
            "team/container-experiences",
            "team/windows-products",
            "team/action-platform",
            "team/profiling-full-host",
            "internal",
            "team/fleet-automation"
          ],
          "author": "pgimalac",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:af44707b5565f106aca2",
        "signalId": "github:DataDog/datadog-agent:pull_request:54834",
        "event": "changed",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [
          "updatedAt",
          "metrics"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54834",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "ci: default GitLab jobs to shallow clones, keep full history where needed",
          "text": "## Summary - Default GitLab jobs to `GIT_DEPTH: 1` so most checkouts are a shallow clone of HEAD only. - Set `GIT_DEPTH: 0` on jobs that actually need git history (merge-base, ancestor walks, `git describe`, `git log` ranges, three-dot diffs, or checkout of another branch). - Jobs that inherit a full-history template but never use merge-base stay at depth 1 (`new-e2e-unit-tests`, upgrade/RPM install-package jobs). - `GIT_STRATEGY: clone` is not a full clone; clone with depth 1 is still shallow. Full history requires `GIT_DEPTH: 0`. Supersedes https://github.com/DataDog/datadog-agent/pull/54799 (opened from a fork). ## Test plan - [ ] Confirm a typical build/lint job clones with depth 1 and still has the working tree. - [ ] Confirm jobs that compute merge-base still succeed (`golang_deps_diff`, e2e `--impacted`, `static_quality_gates`, `files_inventory_check`, SMP merge-base check). - [ ] Confirm `setup_agent_version` can still run `git describe --tags`. - [ ] Confirm unit-test jobs with `FAST_TESTS=true` still detect impacted packages. - [ ] Confirm `benchmark` can check out `BASE_BRANCH` and `prebuild-workspace-image-check` can three-dot diff against `COMPARE_TO_BRANCH`. Made with [Cursor](https://cursor.com)",
          "url": "https://github.com/DataDog/datadog-agent/pull/54834",
          "createdAt": "2026-08-13T14:03:09Z",
          "updatedAt": "2026-08-13T17:58:00Z",
          "timestamp": "2026-08-13T17:58:00Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "changelog/no-changelog",
            "team/agent-apm",
            "team/agent-security",
            "team/ebpf-platform",
            "qa/no-code-change",
            "team/container-platform",
            "team/agent-delivery",
            "long review",
            "team/agent-integrations",
            "team/container-integrations",
            "team/agent-devx",
            "team/agent-build",
            "team/windows-products",
            "team/profiling-full-host",
            "internal"
          ],
          "author": "mikesherovdd",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:5d8cd357d5ba27ece829",
        "signalId": "github:DataDog/datadog-agent:pull_request:54852",
        "event": "changed",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [
          "updatedAt",
          "metrics"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54852",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[NTWK-812] Filter dynamic tests across all reverse-DNS names",
          "text": "What does this PR do? Fixes Network Path dynamic tests scheduling traceroutes against Datadog's own intake backends (e.g. l4-metrics-agent-*.elb.us-east-1.amazonaws.com) despite the default *.datadoghq.com connection-filter exclude. - Adds ConnFilter.EvaluateDomains(domains, ip), which evaluates every DNS name a destination IP reverse-resolves to (via the existing last-match-wins chain) instead of only the first. A connection is excluded if any of its names is excluded, and the returned hostname is the preferred name for the path test (an include-matched name, else the first included name). - Plumbs the full name list end-to-end: adds Domains []string to NetworkPathConnection, a getDNSNamesForIP helper in both connection builders (pkg/network/sender, pkg/process/checks), and wires npcollector to filter on it and use the selected hostname. - Adds l4-metrics-agent-*.elb.*.amazonaws.com to the default excludes as hardening for the case where only the ELB name is cached. Customer include filters still override the defaults, so Datadog domains can be re-enabled if desired. Motivation [NTWK-812 / ZD 2972181](https://datadoghq.atlassian.net/browse/NTWK-812). A destination IP for a Datadog intake endpoint reverse-resolves to more than one name: the queried *.datadoghq.com name and the AWS ELB hostname it's CNAME'd to (short A-record TTLs cause resolvers to re-query the ELB target directly). getDNSNameForIP collapsed that list to dnsEntry[0], so when the ELB name was selected first the *.datadoghq.com exclude never fired — nondeterministically, depending on cache ordering. For the reporting org this was ~37% of dynamic test runs (>3,000/day), which also drives unnecessary billing. Describe how you validated your changes - New unit tests in connfilter_test.go: - TestEvaluateDomains — the CNAME gap with both name orderings, ELB-name-only, unrelated names, the customer-include override case, and empty input. - TestEvaluateDomainsPrefersIncludeMatchedName — an RC-include-matched name is chosen as the path test hostname even when it isn't first. - Extended TestNewConnFilter with the intake-ELB default exclude (and a customer-ELB negative case). - dda inv test --targets=./comp/networkpath/npcollector/... ./pkg/process/checks/ — all networkpath + connection tests pass. (TestProcessDiscoveryCheck fails identically on main on this platform; unrelated and pre-existing.) Additional Notes - Behavior change worth a reviewer's eye: \"any excluded name → exclude the connection\" means if a customer excludes name A and the IP also resolves to a fine name B, the connection is now dropped. Intended (they asked to exclude that destination), but flagging it. - The l4-metrics-agent-* default only covers one intake family; with the multi-name fix it's a secondary safety net rather than the primary fix. If we want the other intake ELB prefixes as defaults, we'd need the authorie/networking team. - sender_linux.go / sender/dns.go are Linux-only and couldn't bemacOS (cgo cross-compile); their changes are a one-field additionplus a mirror of the existing getDNSNameForIP — relying on CI fold. Ran 1 shell command Commit a63bb24aa84 is ready on branch netpath-812-exclude-intake/-22). Push to origin/netpath-812-exclude-intake-elb-cnames? Once you confirm, I'll run git push origin netpath-812-exclude-intake-elb-cnames. Reminder before you decide: the two Linux-only files (sender_linux.go, sender/dns.go) couldn't be compiled locally (cgo cross-compile), so first CI on this branch is where they get a real build — worth watching that pipeline after the push. ✻ Brewed for 1m 2s ❯ confirmed Pushed to netpath-812-exclude-intake-elb-cnames Pushed successfully — branch netpath-812-exclude-intake-elb-cnames is now on origin (new branch, tracking set up earlier). Next steps you may want: - Open the PR: https://github.com/DataDog/datadog-agent/pull/new/netpath-812-exclude-intake-elb-cnames — I can do this via the create-pr skill (I'll flag the Linux-build/CI caveat and the \"any-excluded-name excludes ththe description). - Watch CI: this is where the two Linux-only files get their first real compile. I can follow the pipeline with the follow-pr skill once a PR exists. - Update NTWK-812: post a triage-format update linking the branch/PR. Want me to open the PR? ✻ Baked for 26s ❯ Can you create a PR description for me that I can copy/paste? Let me pull the repo's PR template so the description matches wh Read 1 file Here's a copy/paste-ready PR description following the repo template: --- ### What does this PR do? Fixes Network Path dynamic tests scheduling traceroutes against Datadog's own intake backends (e.g. l4-metrics-agent-*.elb.us-east-1.amazonaws.com) despite the default *.datadoghq.com connection-filter exclude. - Adds ConnFilter.EvaluateDomains(domains, ip), which evaluates every DNS name a destination IP reverse-resolves to (via the existing last-match-wins chain) instead of only the first. A connection is excluded if any of its names is excluded, and the returned hostname is the preferred name for the path test (an include-matched name, else the first included name). - Plumbs the full name list end-to-end: adds Domains []string togetDNSNamesForIP helper in both connection builders(pkg/network/sender, pkg/process/checks), and wires npcollector to filter on it and use the selected hostname. - Adds l4-metrics-agent-*.elb.*.amazonaws.com to the default excludes as hardening for the case where only the ELB name is cached. Customer include filters still override the defaults, so Datadog if desired. ### Motivation NTWK-812 / ZD 2972181. A destination IP for a Datadog intake endmore than one name: the queried *.datadoghq.com name and the AWSELB hostname it's CNAME'd to (short A-record TTLs cause resolvers to re-query the ELB target directly). getDNSNameForIP collapsed that list to dnsEntry[0], so when the ELB name was selected first the *.datadoghq.com exclude never fired — nondeterministically, depending on cache ordering. For the reporting org this was ~37% of dynamic test runs (>3,000/day), which also drives unnecessary billing. Describe how you validated your changes - New unit tests in connfilter_test.go: - TestEvaluateDomains — the CNAME gap with both name orderings, ELB-name-only, unrelated names, the customer-include override case, and empty input. - TestEvaluateDomainsPrefersIncludeMatchedName — an RC-include-matched name is chosen as the path test hostname even when it isn't first. - Extended TestNewConnFilter with the intake-ELB default excluative case). - dda inv test --targets=./comp/networkpath/npcollector/... ./pkg/process/checks/ — all networkpath + connection tests pass. (TestProcessDiscoveryCheck fails identically on main on this platform; unrelated and pre-ex ### Additional Notes - Behavior change worth a reviewer's eye: \"any excluded name → ens if a customer excludes name A and the IP also resolves to afine name B, the connection is now dropped. Intended (they asked to exclude that destination), but flagging it. - The l4-metrics-agent-* default only covers one intake family; 's a secondary safety net rather than the primary fix. If we wantthe other intake ELB prefixes as defaults, we'd need the authoritative list from the intake/networking team. - sender_linux.go / sender/dns.go are Linux-only and couldn't bemacOS (cgo cross-compile); their changes are a one-field additionplus a mirror of the existing getDNSNameForIP — relying on CI for the first real Linux build.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54852",
          "createdAt": "2026-08-13T17:33:46Z",
          "updatedAt": "2026-08-13T17:57:36Z",
          "timestamp": "2026-08-13T17:57:36Z",
          "metrics": {
            "reactions": 1,
            "comments": 2
          },
          "labels": [
            "component/system-probe",
            "medium review",
            "team/cloud-network-monitoring",
            "team/network-path",
            "internal"
          ],
          "author": "ken-schneider",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:5686b1525b18642c3341",
        "signalId": "github:DataDog/datadog-agent:pull_request:53092",
        "event": "discovered",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53092",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(serverless-init): add ProcessHooks for subprocess liveness tracking",
          "text": "### What does this PR do? Adds a `*ProcessHooks` parameter (`OnAlive`/`OnDead`) to `mode.RunInit` and its internal `execute()`, so a caller can be notified when the spawned user process starts and exits. `mode.Conf.Runner` is dropped for init-container mode — its field type (`func(*serverlessLog.Config) error`) can no longer match `RunInit`'s new two-argument signature, so `main.go` switches from calling `modeConf.Runner(logConfig)` to `cloudService.Run(modeConf, logConfig)`, which already exists on the `CloudService` interface and produces identical behavior for every existing cloud service (sidecar → `RunSidecar`, init-container → `RunInit` with `nil` hooks). Also adds `cloudservice.MicroVM`, a `CloudService` implementation for AWS Lambda MicroVMs, and a `LifecycleContext` type carried on `TracingContext.LifecycleCtx`: - `GetTags` parses `DD_AWS_MICROVM_IMAGE_ARN` for `region`/`account_id`/`image_name` (falling back to `\"unknown\"` for any field it can't parse). - `GetEnhancedMetricTags` derives base/usage tag sets from those tags. - `Init` reads a `LifecycleContext` (metric/log flushers, trace-tag/log-tag setters, flush timeout, sidecar flag) and constructs + starts the lifecycle hook server. - `Run` spawns the user process via `mode.RunInit`, binding `ProcessHooks.OnAlive`/`OnDead` to the lifecycle server's child so its `/ready` check reflects real liveness. Sidecar mode is fatal for MicroVM — there's no child process to track, so `/ready` would silently return 503 forever instead of surfacing the misconfiguration. - `Shutdown` stops the lifecycle server within a bounded timeout so in-flight `/suspend`/`/terminate` requests can complete before the metric/trace agents tear down. - MicroVM supports both amd64 and arm64 (every other cloud service here is amd64-only). `MicroVM` is **not yet reachable**: `GetCloudServiceType` still doesn't know about it, so nothing in the running agent changes yet. Also fixes review feedback from Copilot on this PR: - `mode/initcontainer_mode.go`: `hooks.OnDead`'s defer was registered only inside the `hooks.OnAlive != nil` branch, and after `OnAlive()` ran. An `OnDead`-only hook never fired, and `OnDead` wouldn't fire if `OnAlive` panicked. Now deferred unconditionally right after `cmd.Start()` succeeds. - `main.go`: fixed a non-gofmt-compliant import grouping. - `cloudservice/microvm_test.go`: reworded stale `/launch` references (test names, a path variable, assertion messages) to `/run`, matching the route actually under test. ### Motivation The upcoming MicroVM `CloudService` needs to know whether the customer's process is currently alive so its lifecycle server can answer `/ready` correctly — there's no other signal available once `cmd.Start`/`cmd.Wait` are called deep inside `mode.execute()`. `ProcessHooks` is the minimal hook point for that. `MicroVM` is the core piece of the MicroVM integration: everything needed to answer the lifecycle server's HTTP hooks and track the user process's liveness, in one type that satisfies `CloudService` end-to-end. This is the split of #53036 (`tianning.li/microvm-07-microvm-service-wiring`). Originally planned as 5 independently-reviewable PRs; PR 2 (MicroVM CloudService implementation) has since been merged into this branch, so **this PR now covers PRs 1 and 2 combined**: 1. ~~ProcessHooks plumbing in `mode` package~~ (this PR) 2. ~~MicroVM CloudService implementation (`cloudservice/microvm.go`)~~ (this PR) 3. MicroVM tags/metrics/arch tests 4. MicroVM lifecycle-server tests 5. main.go wiring + CloudService registration (tip == original #53036) ### Describe how you validated your changes ``` dda inv test --targets=./cmd/serverless-init/... ``` 299 tests pass (4 platform-skips). New coverage: - `initcontainer_mode_test.go` pins `OnAlive`/`OnDead` ordering (start → alive → wait → dead), the nil-hooks no-op path, `Conf.Runner` nil-for-init/non-nil-for-sidecar, and two regression tests for the OnDead/OnAlive fix above (`TestExecute_OnDeadOnly_OnAliveNil_StillFires`, `TestExecute_OnAlivePanics_OnDeadStillFires` — both fail against the pre-fix code). - `mode_windows_test.go` covers the updated stub signature. - `cloudservice/microvm_test.go` and `cloudservice/service_test.go` cover `MicroVM`'s tag parsing, enhanced-metric tags, init/run/shutdown, and selection priority over Cloud Run. ### Additional Notes No `BUILD.bazel` changes needed — `cloudservice/`, `mode/`, and `cmd/serverless-init/*.go` are Gazelle-excluded (see root `BUILD.bazel` lines 97-100).",
          "url": "https://github.com/DataDog/datadog-agent/pull/53092",
          "createdAt": "2026-07-01T18:53:25Z",
          "updatedAt": "2026-08-13T17:57:27Z",
          "timestamp": "2026-08-13T17:57:27Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "aws-microvm"
          ],
          "author": "litianningdatadog",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:25467b09b6bd5d40bdce",
        "signalId": "github:DataDog/datadog-agent:pull_request:53085",
        "event": "discovered",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53085",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(serverless-init): add standalone MicroVM lifecycle HTTP server",
          "text": "## Summary This adds the MicroVM lifecycle HTTP server itself: an `http.Server` listening on the configured port, handling the six lifecycle hooks the AWS MicroVM platform sends — `/ready`, `/validate`, `/run`, `/resume`, `/suspend`, and `/terminate` — in **standalone** mode, i.e. the agent answers each hook itself rather than forwarding it to a user application (that pass-through mode is added later in this stack). The motivation is to give the agent visibility into a MicroVM's full lifecycle without requiring any cooperation from the user's own application: `/ready` reports child-process liveness so the platform knows when it's safe to snapshot; `/run`/`/resume`/`/suspend`/`/terminate` each emit an enhanced lifecycle metric (tagged with the MicroVM instance ID once known), and `/suspend`/`/terminate` additionally flush all pending telemetry (metrics, traces, logs) before responding, since those are the two points where telemetry could otherwise be lost — either frozen into a snapshot or torn down with the VM. `/run`'s request body (the `runHookPayload` a caller passes to `RunMicrovm`) is capped at **1 MiB** via `http.MaxBytesReader` before being buffered; a body exceeding the cap, or any other read error, aborts the handler with a 500 rather than silently forwarding a truncated body. This cap is a self-imposed defensive bound, not a value taken from an AWS-published limit — the AWS Lambda MicroVM reference docs describe `runHookPayload` only qualitatively (tenant IDs, signed URLs, secret references) and state no numeric size limit. ## Stack This is **PR 2 of 4** in a split of https://github.com/DataDog/datadog-agent/pull/53035 (\"feat(serverless-init): add MicroVM lifecycle HTTP server and env-var wiring\"), which was too large to review as a single PR. The full stack, in merge order: 1. wire MicroVM lifecycle server config from env vars 2. **(this PR)** add standalone MicroVM lifecycle HTTP server 3. propagate MicroVM ID to logs and trace tags 4. add MicroVM lifecycle user-app forwarder pass-through The tip of PR 4 is byte-for-byte identical to the original `tianning.li/microvm-06-lifecycle-server-wire` branch. Note: this PR is somewhat larger than the ~300-line target used elsewhere in the stack — the server skeleton (types, `NewServer`, all six handlers, the shared flush path) is a single cohesive, self-contained unit and its test suite cannot be meaningfully subdivided without breaking that self-containment. ## Test plan ``` bazel test //cmd/serverless-init/lifecycle:lifecycle_test ``` - [x] `bazel build //cmd/serverless-init/lifecycle:lifecycle` - [x] `bazel test //cmd/serverless-init/lifecycle:lifecycle_test` - [x] `dda inv linter.go --targets=./cmd/serverless-init/lifecycle` 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
          "url": "https://github.com/DataDog/datadog-agent/pull/53085",
          "createdAt": "2026-07-01T16:12:21Z",
          "updatedAt": "2026-08-13T17:57:27Z",
          "timestamp": "2026-08-13T17:57:27Z",
          "metrics": {
            "reactions": 2,
            "comments": 5
          },
          "labels": [
            "long review",
            "aws-microvm"
          ],
          "author": "litianningdatadog",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:3dc26cad7eb742a5da21",
        "signalId": "github:DataDog/datadog-agent:pull_request:54828",
        "event": "changed",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54828",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[EBPF] gpu: add NVLink capability tag",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds `gpu_nvlink_capable` and `gpu_nvlink_version` tags to GPU metrics. ### Motivation Knowing whether a GPU is NVlink-capable and the version of the NVlink system or not is useful to ensure the presence of certain metrics and to compare GPU performance. Another PR will also use part of this code to allow segmenting telemetry based on NVLink capability. ### Describe how you validated your changes Unit tests, manually validated in nvlink-enabled instance. ### Additional Notes Both tags might be slightly redundant but having two doesn't cost extra cardinality (gpu_uuid is already there, with one value per GPU) and it allows separating \"nvlink GPUs/non nvlink GPUs\" and between specific versions.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54828",
          "createdAt": "2026-08-13T11:52:04Z",
          "updatedAt": "2026-08-13T17:57:26Z",
          "timestamp": "2026-08-13T17:57:26Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "team/ebpf-platform",
            "qa/done",
            "team/container-platform",
            "long review",
            "team/container-integrations",
            "internal",
            "team/gpu-monitoring-agent"
          ],
          "author": "gjulianm",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:9c8c2a6132e216c34377",
        "signalId": "github:DataDog/datadog-agent:pull_request:54597",
        "event": "discovered",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54597",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[NDINT-652] [Agent] Accept CLI commands from payload sent via PAR",
          "text": "### What does this PR do? This PR adds a RunCommand action which, if enabled, allows a user to submit commands via PAR to be executed on a remote device. ### Motivation https://datadoghq.atlassian.net/browse/NDINT-652 ### Describe how you validated your changes ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54597",
          "createdAt": "2026-08-07T18:39:04Z",
          "updatedAt": "2026-08-13T17:57:15Z",
          "timestamp": "2026-08-13T17:57:15Z",
          "metrics": {
            "reactions": 0,
            "comments": 4
          },
          "labels": [
            "long review",
            "team/ndm-integrations",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "dplepage-dd",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:5c78cec45a7f556904c1",
        "signalId": "github:DataDog/datadog-agent:pull_request:54843",
        "event": "changed",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54843",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[CONTP-2006] feat(ddi): Connect custom workload targets to DDI controller and streaming",
          "text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Connects configurable workload target resolution to DatadogInstrumentation checks and logs. - Adds `instrumentation_crd_controller.custom_workload_targets` configuration. - Starts the Pod workloadmeta store and resolver when at least one custom target is configured. - Accepts registered target GVKs and generates CEL selectors against `container.pod.resolved_targets`. - Includes `apiVersion` when detecting duplicate target references. - Preserves `rootowner` matching for built-in workloads and EndpointSlice delivery for core `v1` Services. For example, a workload reached through an intermediate Kubernetes Job can be configured as: ```yaml instrumentation_crd_controller: custom_workload_targets: - target: apiVersion: example.com/v1 kind: ScheduledWorkload resource: scheduledworkloads via: - apiVersion: batch/v1 kind: Job resource: jobs ``` ### Motivation [CONTP-2006](https://datadoghq.atlassian.net/browse/CONTP-2006) DatadogInstrumentation supports core Kubernetes workload kinds and Argo Rollouts out of the box, but customers also run workloads through controllers such as Ray, Kueue, OpenKruise, and Strimzi. Customers need an opt-in way to declare the workload resources they use and the ownership path from Pods, without relying on a generic fallback or requiring every custom kind to be added to the Agent. ### Describe how you validated your changes ### Additional Notes [CONTP-2006]: https://datadoghq.atlassian.net/browse/CONTP-2006?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
          "url": "https://github.com/DataDog/datadog-agent/pull/54843",
          "createdAt": "2026-08-13T15:53:26Z",
          "updatedAt": "2026-08-13T17:54:16Z",
          "timestamp": "2026-08-13T17:54:16Z",
          "metrics": {
            "reactions": 1,
            "comments": 6
          },
          "labels": [
            "team/container-platform",
            "long review",
            "team/container-integrations",
            "team/agent-build",
            "internal",
            "team/fleet-automation"
          ],
          "author": "Mathew-Estafanous",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:bd1a4dab31df8fd17a85",
        "signalId": "github:DataDog/datadog-agent:pull_request:53084",
        "event": "discovered",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53084",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(serverless-init): wire MicroVM lifecycle server config from env vars",
          "text": "## Summary This adds the environment-variable-driven wiring code for the MicroVM lifecycle HTTP server: reading `DD_AWS_MICROVM_LIFECYCLE_PORT` and the other lifecycle-related env vars, and assembling the config needed to construct the server. No HTTP server or handlers are introduced yet — those land in the next PR in this stack. The motivation is to let the AWS MicroVM platform's serverless-init sidecar/init-container learn, purely from its environment, which port to listen on and how to configure the lifecycle server, without hardcoding values or requiring code changes per deployment. ## Stack This is **PR 1 of 4** in a split of https://github.com/DataDog/datadog-agent/pull/53035 (\"feat(serverless-init): add MicroVM lifecycle HTTP server and env-var wiring\"), which was too large to review as a single PR. The full stack, in merge order: 1. **(this PR)** wire MicroVM lifecycle server config from env vars 2. add standalone MicroVM lifecycle HTTP server 3. propagate MicroVM ID to logs and trace tags 4. add MicroVM lifecycle user-app forwarder pass-through The tip of PR 4 is byte-for-byte identical to the original `tianning.li/microvm-06-lifecycle-server-wire` branch. ## Test plan ``` bazel test //cmd/serverless-init/lifecycle:lifecycle_test ``` - [x] `bazel build //cmd/serverless-init/lifecycle:lifecycle` - [x] `bazel test //cmd/serverless-init/lifecycle:lifecycle_test` - [x] `dda inv linter.go --targets=./cmd/serverless-init/lifecycle` 🤖 Generated with [Claude Code](https://claude.com/claude-code)",
          "url": "https://github.com/DataDog/datadog-agent/pull/53084",
          "createdAt": "2026-07-01T16:12:07Z",
          "updatedAt": "2026-08-13T17:53:08Z",
          "timestamp": "2026-08-13T17:53:08Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "long review",
            "aws-microvm"
          ],
          "author": "litianningdatadog",
          "state": "open",
          "assignees": [],
          "change": "new"
        }
      },
      {
        "id": "event:11a242ccf8a9023808ce",
        "signalId": "github:DataDog/datadog-agent:pull_request:53033",
        "event": "changed",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:53033",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "feat(serverless-init): add MicroVM lifecycle HTTP forwarder",
          "text": "### What does this PR do? Adds `lifecycle/forwarder.go`: an HTTP proxy that passes MicroVM lifecycle hooks (`/ready`, `/validate`, `/run`, `/resume`, `/suspend`, `/terminate`) from the platform through to the user application, when `DD_AWS_MICROVM_USER_APP_PORT` is set. Key behaviours: - Mirrors status code, response body (up to 1 MiB), and `Content-Type` back to the platform so the platform sees the user app's response, not the agent's. - Does not follow redirects returned by the user app — a 3xx is mirrored back as-is instead of being silently followed, which would otherwise replay a POST as a GET (dropping the body) and report the redirect target's response instead of the hook's own. - `/ready` and `/validate` perform a TCP dial-wait before forwarding: the forwarder retries until the user app's port is reachable or the timeout expires. This absorbs the race between the platform's first `/ready` and the user app's TCP listener coming up. - `/run`, `/resume`, `/suspend`, `/terminate` forward with a short deadline (`DD_AWS_MICROVM_FORWARD_TIMEOUT_MS`, default 1 s), which is appropriate since these are informational hooks with tight platform deadlines. Also lowers `DefaultHeartbeatInterval` from 5 minutes to 10 seconds, per review feedback: relying on a steady multi-minute submission for billing is risky since a missed or double-submitted point has outsized impact. Emitting more frequently and deduping downstream is safer. ### Motivation By default the agent handles all lifecycle hooks autonomously — it answers `/ready` based on child-process liveness, emits metrics, flushes telemetry, and so on. But some user applications also need to react to lifecycle events (e.g. warm their own caches on `/run`, checkpoint state on `/suspend`). The forwarder enables this opt-in pass-through mode: the agent does its own work _and_ lets the user app participate in each hook. The TCP dial-wait on `/ready` and `/validate` is especially important: the platform sends `/ready` as soon as the VM boots, which is often before the user app has had time to bind its port. ### Describe how you validated your changes - `forwarder_test.go` covers: mirror of status/body/headers, TCP wait-for-port logic, dial-error → 503, deadline → 504, body truncation, the sidecar-mode guard, and that redirects from the user app are mirrored rather than followed. Run the relevant unit tests locally: ``` dda inv test --targets=./cmd/serverless-init/lifecycle ``` ### Additional Notes **PR stack** — this is PR 4/8: 1. `microvm-01-foundation` — shared infrastructure ✓ 2. `microvm-02-cloudservice-run` — `Run()` on `CloudService` ✓ 3. `microvm-03-lifecycle-config-childhandle` — lifecycle config + child-handle ✓ 4. **This PR** — HTTP pass-through forwarder 5. `microvm-05-lifecycle-heartbeat` — periodic heartbeat metric 6. `microvm-06-lifecycle-server-wire` — lifecycle HTTP server 7. `microvm-07-microvm-service-wiring` — MicroVM `CloudService` + main wiring 8. `microvm-08-sigusr2-on-run` — SIGUSR2 on `/run`",
          "url": "https://github.com/DataDog/datadog-agent/pull/53033",
          "createdAt": "2026-06-30T21:36:15Z",
          "updatedAt": "2026-08-13T17:49:32Z",
          "timestamp": "2026-08-13T17:49:32Z",
          "metrics": {
            "reactions": 2,
            "comments": 4
          },
          "labels": [
            "long review",
            "aws-microvm"
          ],
          "author": "litianningdatadog",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:0de32c1477d688b6132a",
        "signalId": "github:DataDog/datadog-agent:pull_request:54590",
        "event": "changed",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54590",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] add par-control effective configuration",
          "text": "### What does this PR do? Adds the effective configuration and identity bootstrap layer for `par-control`: - Adds a Go helper subcommand that exports the Agent's resolved configuration. - Loads split-runner configuration from Rust. - Resolves local and Fleet-managed settings consistently. - Loads and persists runner identity. - Supports self-enrollment bootstrap. - Adds the required schema and setup wiring. Configuration production and consumption stay together in this PR so their contract can be reviewed as one behavior. ### Motivation Give the control process the same effective configuration as the Agent without duplicating configuration precedence or persisting a second plaintext configuration snapshot. ### Validation - Focused Go tests pass locally. - Portable Rust tests pass locally. - Relevant Go and Rust builds pass locally. ### Review fixes - **Process-manager socket**: falls back to dd-procmgrd's own `DD_PM_SOCKET_PATH` when `private_action_runner.procmgr_socket_path` is unset, before the platform default. Previously, relocating the daemon's socket also required setting a second, PAR-specific value. Resolution goes through the injected env lookup so it is testable without mutating process state, and an empty setting is treated as unset like the executor socket. - Carries the RPC deadlines, the `wait_for_failure` semantics, and the fake-daemon tests into the injected-socket `ProcmgrLifecycle` introduced here. - Same program-data-root log path, so the Windows log location no longer depends on where `--config` points. `platform.rs` also takes over the fleet-policies-dir registry lookup that was inline here. ### Stack PR 4 of 9. Based on #54589; followed by #54591.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54590",
          "createdAt": "2026-08-07T17:47:32Z",
          "updatedAt": "2026-08-13T17:49:14Z",
          "timestamp": "2026-08-13T17:49:14Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "team/action-platform",
            "internal",
            "team/fleet-automation"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:b785d7c3992fae72c080",
        "signalId": "github:DataDog/datadog-agent:pull_request:54593",
        "event": "changed",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54593",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] orchestrate par-control tasks",
          "text": "### What does this PR do? Composes the process manager, effective configuration, OPMS client, and executor channel into the production `par-control` loop: - Adds bounded task concurrency and retry policy. - Leaves the executor stopped while idle and starts it only after a task is dequeued. - Starts task heartbeats at dequeue and continues them through executor cold start, key synchronization, execution, and terminal publication. - Sends runner liveness reports independently of task flow. - Lazily synchronizes and caches signing keys for later executor starts. - Stops the executor after the configured idle period and drains in-flight work during shutdown. - Wires the final binary and updates its documentation. - Restores Windows compatibility for the Rust Bazel test by staging the Agent OpenSSL DLLs in runfiles and placing that directory on the test process's `PATH`. ### Motivation Keep orchestration policy separate from the independently tested lifecycle and network primitives it coordinates. In particular, the control process should preserve an OPMS lease while paying the executor's cold-start cost and should not keep the higher-RSS Go process alive when no work is available. ### Validation - `dda env dev run -- bazel test //pkg/privateactionrunner/par-control:par-control_test` - `dda env dev run -- env -u PKG_CONFIG_LIBDIR cargo clippy --manifest-path pkg/privateactionrunner/par-control/Cargo.toml --all-targets -- -D warnings` - Buildifier passes. - Windows-target Bazel analysis confirms both OpenSSL DLLs are inputs to the staging action. - Full Windows Rust execution is delegated to Windows CI. ### Review fixes - **No startup prewarming**: the executor remains stopped until a task is leased. Signing keys are synchronized during the first cold start and cached for later starts. - **Lease protection during cold start**: task heartbeats begin immediately after dequeue and stop only after terminal publication, covering process startup, readiness, and key synchronization. - **Start race**: dd-procmgrd rejects `Start` for every state covered by `ProcessState::is_alive()` (`Starting`, `Running`, and `Stopping`). Those states and a lost `Start` race are now adopted instead of failing the task spuriously. - **Windows graceful shutdown**: `par-control` listens for `CTRL_BREAK`, which is the event dd-procmgrd sends to Windows children, so shutdown drains work instead of waiting for the process-manager timeout and job-object kill. - **Bounded process-manager calls**: dispatch-path `Describe` and `Start` RPCs have deadlines, allowing a leased task to fail and publish an outcome instead of hanging without heartbeats. - **Windows logging and defaults**: restores the program-data-root log path, `ExitCode`, and the platform-correct `--config` default. - **Clean executor exits**: idle self-termination from #54670 remains non-fatal, so `restart: on-failure` does not immediately respawn the executor. - Tests cover stopped-at-start behavior, heartbeat timing through cold start and publication, adoption of `Starting`/`Running`/`Stopping`, tolerated start races, RPC deadlines, idle stop, drain behavior, and vanished process definitions. ### Stack PR 7 of 9. Based on #54592; followed by #54594.",
          "url": "https://github.com/DataDog/datadog-agent/pull/54593",
          "createdAt": "2026-08-07T17:53:19Z",
          "updatedAt": "2026-08-13T17:49:05Z",
          "timestamp": "2026-08-13T17:49:05Z",
          "metrics": {
            "reactions": 1,
            "comments": 5
          },
          "labels": [
            "long review",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:bb689bdf568bdee9b4cf",
        "signalId": "github:DataDog/datadog-agent:pull_request:54589",
        "event": "changed",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54589",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[ACTP] add par-control process lifecycle",
          "text": "### What does this PR do? Adds the process-lifecycle boundary for `par-control`: - Uses the shared `dd-procmgr-client` connector for local IPC on Linux and Windows. - Loads the minimal configuration needed to gate split mode. - Exposes one-shot executor lifecycle operations to start or adopt the executor, inspect liveness and terminal state, and stop it. - Intentionally leaves the executor stopped during control-plane startup; the later orchestration layer invokes the lifecycle only after leasing a task rather than prewarming or continuously polling the executor. - Bounds process-manager RPCs and handles platform-specific shutdown, logging, and Windows `ConfigRoot` paths. - Tests the real generated gRPC client against an in-process fake `dd-procmgrd`. `par-control` and the executor are siblings owned by `dd-procmgrd`. A `Start` race that returns `FAILED_PRECONDITION` therefore adopts the already-alive executor. During its own shutdown, `par-control` does not call back into `dd-procmgrd`, which may already be waiting for it to exit. ### Validation - `dda env dev run -- bazel test //pkg/privateactionrunner/par-control:par-control_test` - `dda env dev run -- bazel build //pkg/privateactionrunner/par-control:par-control` - `dda env dev run -- env -u PKG_CONFIG_LIBDIR cargo clippy --manifest-path pkg/privateactionrunner/par-control/Cargo.toml --all-targets -- -D warnings`",
          "url": "https://github.com/DataDog/datadog-agent/pull/54589",
          "createdAt": "2026-08-07T17:44:51Z",
          "updatedAt": "2026-08-13T17:47:56Z",
          "timestamp": "2026-08-13T17:47:56Z",
          "metrics": {
            "reactions": 1,
            "comments": 4
          },
          "labels": [
            "changelog/no-changelog",
            "qa/no-code-change",
            "long review",
            "team/agent-devx",
            "team/agent-build",
            "team/action-platform",
            "internal"
          ],
          "author": "embeaken",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      },
      {
        "id": "event:d4b8259eab7b4d5cbf83",
        "signalId": "github:DataDog/datadog-agent:pull_request:54437",
        "event": "changed",
        "observedAt": "2026-08-13T18:01:55.420671Z",
        "changedFields": [
          "updatedAt"
        ],
        "signal": {
          "id": "github:DataDog/datadog-agent:pull_request:54437",
          "source": "github",
          "group": "observability",
          "project": "DataDog/datadog-agent",
          "kind": "pull_request",
          "title": "[AAD-23] Remove CUSUM detector",
          "text": "### What does this PR do? This PR removes the unused CUSUM detector and its configuration, tests, testbench UI, and evaluation wiring. ### Motivation CUSUM is disabled by default, is not used, and performs poorly in its current form. On the same 12 local eval scenarios, BOCPD + TimeCluster produced 6.08x higher mean F1 while CUSUM + TimeCluster produced 24.5x more baseline false positives and took 11.75x longer in detector execution. | Metric | CUSUM | BOCPD | |---|---:|---:| | Mean scenario F1 | 0.0212 | 0.1289 | | TimeCluster predictions | 2,923 | 287 | | Baseline false positives | 1,054 | 43 | | Raw detector anomalies | 571,833 | 1,315 | | Detector-phase time | 901.0s | 76.7s | ### Describe how you validated your changes - `dda inv test --targets=./comp/anomalydetection/observer/impl/` - `dda inv test --targets=./internal/qbranch/anomalydetection-testbench/` - `dda inv anomalydetection.build-testbench` - Python syntax validation for the anomaly-eval tasks - `git diff --check` - Repository pre-commit and pre-push hooks ### Additional Notes",
          "url": "https://github.com/DataDog/datadog-agent/pull/54437",
          "createdAt": "2026-08-04T19:08:27Z",
          "updatedAt": "2026-08-13T17:47:15Z",
          "timestamp": "2026-08-13T17:47:15Z",
          "metrics": {
            "reactions": 2,
            "comments": 10
          },
          "labels": [
            "changelog/no-changelog",
            "qa/done",
            "long review",
            "team/agent-build",
            "internal",
            "team/fleet-automation"
          ],
          "author": "Eokye",
          "state": "open",
          "assignees": [],
          "change": "updated"
        }
      }
    ]
  }
}
