[main][Automation] Update elastic/beats to 1dc4d7a6380e

[github-actions]

What

Update elastic/beats to the latest version on branch main.

Changeset

• elastic/beats@afc53c0...1dc4d7a

---

Bump beats

Update to elastic/beats@1dc4d7a6380e

ran shell command ".ci/scripts/update-beats.sh 1dc4d7a6380e"

GitHub Action workflow link

---

Created automatically by Updatecli Options: Most of Updatecli configuration is done via its manifest(s). If you close this pull request, Updatecli will automatically reopen it, the next time it runs. If you close this pull request and delete the base branch, Updatecli will automatically recreate it, erasing all previous commits made. Feel free to report any issues at github.com/updatecli/updatecli. If you find this tool useful, do not hesitate to star our GitHub repository as a sign of appreciation, and/or to tell us directly on our chat!

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[mergify]

This pull request does not have a backport label. Could you fix it @github-actions[bot]? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-./d./d is the label that automatically backports to the 8./d branch. /d is the digit
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.

[ebeahan]

I didn't investigate each failure exhaustingly, but in quick review the test I see fail are related to liveness probing/monitoring:

=== FAIL: testing/integration/ess TestMonitoringPreserveTextConfig/TestMonitoringLiveness (2.14s)
...
=== FAIL: testing/integration/ess TestMonitoringPreserveTextConfig (57.85s)
...
=== FAIL: testing/integration/ess TestMonitoringLivenessReloadable/TestMonitoringLiveness (2.12s)
...
=== FAIL: testing/integration/ess TestMonitoringLivenessReloadable (53.82s)

@nkvoll could these failures relate to the recent liveness changes made in #9673?

[nkvoll]

@nkvoll could these failures relate to the recent liveness changes made in #9673?

Initially I don't think so, as I /think/ these tests basically exec and do elastic-agent status --output json, where the linked PR only changes the HTTP liveness endpoint.

[cmacknz]

These failures are related to the /processes endpoint as well which is separate from the /liveness endpoint.

=== RUN   TestMonitoringLivenessReloadable/TestMonitoringLiveness
    monitoring_probe_reload_test.go:177: component state: Healthy: communicating with pid '65589'
    monitoring_probe_reload_test.go:177: component state: Healthy: communicating with pid '65583'
    monitoring_probe_reload_test.go:177: component state: Healthy: communicating with pid '65564'
    monitoring_probe_reload_test.go:177: component state: Healthy: communicating with pid '65589'
    monitoring_probe_reload_test.go:177: component state: Healthy: communicating with pid '65583'
    monitoring_probe_reload_test.go:177: component state: Healthy: communicating with pid '65564'
    monitoring_probe_reload_test.go:160: 
        	Error Trace:	/opt/buildkite-agent/builds/bk-agent-prod-gcp-1758025637851735731/elastic/elastic-agent/testing/integration/ess/monitoring_probe_reload_test.go:160
        	            				/opt/buildkite-agent/builds/bk-agent-prod-gcp-1758025637851735731/elastic/elastic-agent/testing/integration/ess/monitoring_probe_reload_test.go:143
        	            				/opt/buildkite-agent/.asdf/installs/golang/1.24.7/go/src/runtime/asm_amd64.s:1700
        	Error:      	Received unexpected error:
        	            	Get "http://localhost:6792/liveness": dial tcp 127.0.0.1:6792: connect: connection refused
        	Test:       	TestMonitoringLivenessReloadable/TestMonitoringLiveness
    --- FAIL: TestMonitoringLivenessReloadable/TestMonitoringLiveness (2.14s)

Looking at the JSON test logs, the test fails at 2025-09-16T12:59:32.168290271Z

{"Time":"2025-09-16T12:59:32.168290271Z","Action":"output","Package":"github.com/elastic/elastic-agent/testing/integration/ess","Test":"TestMonitoringLivenessReloadable/TestMonitoringLiveness","Output":"        \t            \tGet \"http://localhost:6792/liveness\": dial tcp 127.0.0.1:6792: connect: connection refused\n"}

Looking at the agent diagnostics the monitoring server changes 3 times with the change to 127.0.0.1:6792 happening last at 2025-09-16T12:59:33.669Z which is ~1s after 16T12:59:32.168290271Z.

{"log.level":"info","@timestamp":"2025-09-16T12:59:09.248Z","log.logger":"api","log.origin":{"function":"github.com/elastic/elastic-agent-libs/api.(*Server).Start.func1","file.name":"api/server.go","file.line":87},"message":"Metrics endpoint listening on: 127.0.0.1:6791 (configured: http://localhost:6791)","log":{"source":"elastic-agent"},"ecs.version":"1.6.0"}

{"log.level":"info","@timestamp":"2025-09-16T12:59:31.394Z","log.logger":"api","log.origin":{"function":"github.com/elastic/elastic-agent-libs/api.(*Server).Start.func1","file.name":"api/server.go","file.line":87},"message":"Metrics endpoint listening on: 127.0.0.1:6791 (configured: http://localhost:6791)","log":{"source":"elastic-agent"},"ecs.version":"1.6.0"}

{"log.level":"info","@timestamp":"2025-09-16T12:59:33.669Z","log.logger":"api","log.origin":{"function":"github.com/elastic/elastic-agent-libs/api.(*Server).Start.func1","file.name":"api/server.go","file.line":87},"message":"Metrics endpoint listening on: 127.0.0.1:6792 (configured: http://localhost:6792)","log":{"source":"elastic-agent"},"ecs.version":"1.6.0"}

The way the test is written seems inherently racy, it makes a policy change via the override API, then checks for components to be healthy (which is not an indicator the policy change happened), then makes a single HTTP request an expects it to succeed.

elastic-agent/testing/integration/ess/monitoring_probe_preserve_text_cfg_test.go

Lines 171 to 181 in 3e1fc2b

	overrideEndpoint := fmt.Sprintf("/api/fleet/agent_policies/%s", runner.policyID)
	statusCode, overrideResp, err := runner.info.KibanaClient.Request("PUT", overrideEndpoint, nil, nil, reader)
	require.NoError(runner.T(), err)
	require.Equal(runner.T(), http.StatusOK, statusCode, "non-200 status code; got response: %s", string(overrideResp))
	runner.AllComponentsHealthy(ctx)
	updatedEndpoint := "http://localhost:6792/processes"
	// second stage: ensure the HTTP config has updated
	req, err = http.NewRequestWithContext(ctx, "GET", updatedEndpoint, nil)
	require.NoError(runner.T(), err)

The simplest fix is probably just to add some retries, a slightly better fix would be to poll for the policy revision to change or even the log line indicating the metrics server port change happened.

[cmacknz]

I linked to the /processes test above, the /liveness test does the same thing.

elastic-agent/testing/integration/ess/monitoring_probe_reload_test.go

Lines 131 to 140 in 3e1fc2b

	overrideEndpoint := fmt.Sprintf("/api/fleet/agent_policies/%s", runner.policyID)
	statusCode, overrideResp, err := runner.info.KibanaClient.Request("PUT", overrideEndpoint, nil, nil, reader)
	require.NoError(runner.T(), err)
	require.Equal(runner.T(), http.StatusOK, statusCode, "non-200 status code; got response: %s", string(overrideResp))
	runner.AllComponentsHealthy(ctx)
	// check to make sure that we now have a liveness probe response
	req, err = http.NewRequestWithContext(ctx, "GET", endpoint, nil)
	require.NoError(runner.T(), err)

[ycombinator]

I've narrowed down the cause of the TestClientWithCertificate FIPS unit test failing. It has something to do with the github.com/stretchr/testify dependency being bumped from v1.10.0 to v1.11.1. In fact, the test fails if the dependency is bumped from v1.10.0 to v1.11.0 (which is the next release after v1.10.0) as well. Looking into what specifically changed between these versions that would cause the test to start failing.

[UPDATE 1] The change I made in 8525a53 should get this test to pass again.

[UPDATE 2] I didn't take a closer look but I suspect something in stretchr/testify#1427, which was included in v1.11.0, might've caused the breakage 🤷.

[cmacknz]

Closing in favor of #10019, there were several conflicts in this branch with the fixes on main and my attempt to force rebase the fixes out failed.

[elastic-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube

[elasticmachine]

💔 Build Failed

• Buildkite Build
• Commit: 9030428

Failed CI Steps

• Unit tests - Windows 2022
• Win2022:sudo:install-uninstall
• v1.27.16:amd64:basic,slim,complete,service,elastic-otel-collector
• v1.27.16:amd64:basic,slim,complete,service,elastic-otel-collector
• v1.28.15:amd64:basic,slim,complete,service,elastic-otel-collector
• v1.28.15:amd64:basic,slim,complete,service,elastic-otel-collector
• v1.29.14:amd64:basic,slim,complete,service,elastic-otel-collector
• v1.29.14:amd64:basic,slim,complete,service,elastic-otel-collector
• v1.30.0:amd64:basic,slim,complete,service,elastic-otel-collector
• v1.30.0:amd64:basic,slim,complete,service,elastic-otel-collector
• v1.31.0:amd64:basic,slim,complete,service,elastic-otel-collector
• v1.31.0:amd64:basic,slim,complete,service,elastic-otel-collector
• v1.32.0:amd64:basic,slim,complete,service,elastic-otel-collector
• v1.32.0:amd64:basic,slim,complete,service,elastic-otel-collector
• v1.33.0:amd64:basic,slim,complete,service,elastic-otel-collector
• v1.33.0:amd64:basic,slim,complete,service,elastic-otel-collector
• v1.27.16:amd64:wolfi,slim-wolfi,complete-wolfi,elastic-otel-collector-wolfi
• v1.27.16:amd64:wolfi,slim-wolfi,complete-wolfi,elastic-otel-collector-wolfi
• v1.28.15:amd64:wolfi,slim-wolfi,complete-wolfi,elastic-otel-collector-wolfi
• v1.28.15:amd64:wolfi,slim-wolfi,complete-wolfi,elastic-otel-collector-wolfi
• v1.29.14:amd64:wolfi,slim-wolfi,complete-wolfi,elastic-otel-collector-wolfi
• v1.29.14:amd64:wolfi,slim-wolfi,complete-wolfi,elastic-otel-collector-wolfi
• v1.30.0:amd64:wolfi,slim-wolfi,complete-wolfi,elastic-otel-collector-wolfi
• v1.30.0:amd64:wolfi,slim-wolfi,complete-wolfi,elastic-otel-collector-wolfi
• v1.31.0:amd64:wolfi,slim-wolfi,complete-wolfi,elastic-otel-collector-wolfi
• v1.31.0:amd64:wolfi,slim-wolfi,complete-wolfi,elastic-otel-collector-wolfi
• v1.32.0:amd64:wolfi,slim-wolfi,complete-wolfi,elastic-otel-collector-wolfi
• v1.32.0:amd64:wolfi,slim-wolfi,complete-wolfi,elastic-otel-collector-wolfi
• v1.33.0:amd64:wolfi,slim-wolfi,complete-wolfi,elastic-otel-collector-wolfi
• v1.33.0:amd64:wolfi,slim-wolfi,complete-wolfi,elastic-otel-collector-wolfi

History

• 💔 Build #27002 failed b33442b
• 💔 Build #26972 failed 698cf5c
• 💔 Build #26955 failed 7d2dd09
• 💔 Build #26908 failed 0cd3684

cc @swiatekm