[9.5](backport #51940) Set shutdown timeout for beat receivers to 5s by default

[mergify]

Proposed commit message

Set shutdown timeout for beat receivers to 5s by default.

Beat receivers need a longer timeout than the default 1s, as it needs to exceed the batcher flush timeout. The current code gives the impression of this already happening, but in reality, if the beater handles pipeline shutdown on its own, the default timeout wins.

The PR adds the default in NewBeatForReceiver and adds a test for filebeat receiver which asserts that the timeout is at least 5 seconds.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation
• [ ] I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works. Where relevant, I have used the stresstest.sh script to run them under stress conditions and race detector to verify their stability.
• [ ] I have added an entry in ./changelog/fragments using the changelog tool.

Related issues

• Relates [Flaky Test] Fix TestMonitoringNoDuplicates flakiness elastic-agent#15514

---

This is an automatic backport of pull request #51940 done by [Mergify](https://mergify.com).

[github-actions]

🤖 GitHub comments

Just comment with:

• run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)
• /test : Run the Buildkite pipeline.

[infra-vault-gh-plugin-prod]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[github-actions]

TL;DR

The Packetbeat Go integration job failed with one test failure, but the supplied Buildkite log does not include the failing assertion or error. It only shows the failure-only OTel configuration for TestPacketbeatOTelMultipleReceiversE2E, so the root cause cannot be determined reliably from the available artifacts.

Remediation

• Re-run the Buildkite job or attach the generated TEST-go-integration.out.json/JUnit output so the failing assertion and test name are available.
• If the failure reproduces, inspect the event-ingestion assertion in x-pack/packetbeat/tests/integration/otel_test.go:284-294, then validate whether the expected events arrive in Elasticsearch.

Investigation details

Root Cause

Inconclusive. The PR adds a default shutdown_timeout only when constructing a receiver in x-pack/libbeat/cmd/instance/beat.go:100-110; the available log does not show that this change caused the failure.

Evidence

• Build: https://buildkite.com/elastic/beats/builds/49441
• Job/step: x-pack/packetbeat: Ubuntu x86_64 Go Integration Tests (mage goIntegTest)
• Key log excerpt: /tmp/gh-aw/buildkite-logs/beats-xpack-packetbeat-ubuntu-x-packpacketbeat-ubuntu-x86_64-go-integration-tests.txt:121 reports DONE 5 tests, 2 skipped, 1 failure in 279.190s. Lines 1-120 contain only the failure-only OTel configuration; no assertion, panic, timeout, or Elasticsearch error is present.
• The logged configuration corresponds to TestPacketbeatOTelMultipleReceiversE2E, whose event-count assertion is at x-pack/packetbeat/tests/integration/otel_test.go:289-294.

Verification

Not run locally; this integration test requires the configured Elasticsearch integration environment, and the provided failure output lacks the assertion needed to reproduce the exact failure.

Follow-up

Please provide the test collector artifact or rerun output before making a code change; otherwise a retry is the appropriate first action if the failure does not reproduce.

---

What is this? | From workflow: PR Buildkite Detective

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.