[9.3](backport #51591) remove global paths from metricbeat

[mergify]

Proposed commit message

This change removes the use of global/singleton path state from Metricbeat and replaces it with per-instance paths, fixing a bug where multiple Metricbeat receivers could share the same data store.

Problem

Metricbeat was using global paths.Paths (a package-level singleton) when resolving file paths like the SQL cursor data store. In receiver mode, multiple Metricbeat instances share the same process, so they would all resolve to the same data path, causing them to share state incorrectly.

Changes

• metricbeat/mb/mb.go: Added a Paths *paths.Path field to BaseModule so each module carries its own path instance.
• metricbeat/mb/builders.go: Threaded the *paths.Path parameter through newBaseModuleFromConfig so it is assigned to the BaseModule at construction time.
• metricbeat/mb/lightmetricset.go: Updated LightMetricSet.baseModule() to pass the metric set's path to newBaseModuleFromConfig.
• x-pack/libbeat/cmd/instance/beat.go: Simplified NewBeatForReceiver by removing the filebeat-specific branch for path initialization — both filebeat and metricbeat now use the same path initialization path, constructing a fresh paths.Path instance per beat.
• x-pack/metricbeat/module/sql/module.go: Replaced paths.Resolve(paths.Data, "sql-cursor") (global) with m.Paths.Resolve(paths.Data, "sql-cursor") (per-instance), so each SQL module instance resolves its own data directory.

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.

Disruptive User Impact

None. Stand alone Metricbeat will function as before, only metricbeat receiver will have multiple beat instances in the same process. This change will allow the sql module to have unique data path per beat instance.

How to test this PR locally

cd x-pack/metricbeat/module/sql
go test .

Related issues

• Closes Metricbeat receivers share the same store and "corrupt" data elastic-agent#15154

Use cases

Screenshots

Logs

---

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

[mergify]

Cherry-pick of 37f3d26 has failed:

On branch mergify/bp/9.3/pr-51591
Your branch is up to date with 'origin/9.3'.

You are currently cherry-picking commit 37f3d269d.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	new file:   changelog/fragments/1782499306-remove-global-paths-from-metricbeat.yaml
	modified:   metricbeat/mb/lightmetricset.go
	modified:   metricbeat/mb/lightmetricset_test.go
	modified:   metricbeat/mb/mb.go
	modified:   metricbeat/mb/mb_test.go

Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)
	both modified:   metricbeat/mb/builders.go
	both modified:   x-pack/libbeat/cmd/instance/beat.go
	deleted by us:   x-pack/metricbeat/module/sql/module.go
	deleted by us:   x-pack/metricbeat/module/sql/module_test.go
	deleted by us:   x-pack/metricbeat/module/sql/query/cursor/store_test.go
	deleted by us:   x-pack/metricbeat/module/sql/query/cursor_integration_test.go
	both modified:   x-pack/metricbeat/module/sql/query/query_integration_test.go
	deleted by us:   x-pack/metricbeat/module/sql/query/query_test.go

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[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

Buildkite is failing because the backport commit b265923669c53b14bf051c76eadbdc1f669de791 still contains unresolved cherry-pick conflict markers. The failing pre-commit jobs all stop at check-merge-conflict, and x-pack/libbeat also fails because goimports cannot parse the conflicted cmd/instance/beat.go.

Remediation

• Manually resolve the remaining cherry-pick conflicts in metricbeat/mb/builders.go, x-pack/libbeat/cmd/instance/beat.go, and x-pack/metricbeat/module/sql/query/query_integration_test.go, then remove all <<<<<<<, =======, and >>>>>>> lines.
• For the 9.3 backport specifically, adapt the upstream path changes to the 9.3 APIs: in metricbeat/mb/builders.go, keep the 9.3 NewModule(..., p *paths.Path, logger *logp.Logger) signature and call newBaseModuleFromConfig(config, logger, p); in x-pack/libbeat/cmd/instance/beat.go, use a fresh paths.New()/InitPaths result for receiver beats instead of leaving the old filebeat-only/global paths branch; in the Oracle integration test, merge the 9.3 Oracle client skip/imports with the upstream readiness/connection changes.
• Re-run pre-commit run --all-files; for the libbeat failure, also re-run make -C x-pack/libbeat check update && make check-no-changes.

Investigation details

Root Cause

This is a backport conflict-resolution issue, not a transient infrastructure failure. The PR is labeled conflicts, and the only PR commit message records unresolved conflict paths including metricbeat/mb/builders.go, x-pack/libbeat/cmd/instance/beat.go, and x-pack/metricbeat/module/sql/query/query_integration_test.go. The PR diff itself still includes conflict markers in metricbeat/mb/builders.go and x-pack/libbeat/cmd/instance/beat.go.

Evidence

• Build: https://buildkite.com/elastic/beats/builds/49010
• Failed steps: x-pack/dockerlogbeat: Run pre-commit, x-pack/osquerybeat: Run pre-commit, x-pack/winlogbeat: Run pre-commit, x-pack/libbeat: Run pre-commit, x-pack/heartbeat: Run pre-commit, x-pack/packetbeat: Run pre-commit, and x-pack/libbeat: Run check/update.
• Repeated pre-commit excerpt:

metricbeat/mb/builders.go:61: Merge conflict string '<<<<<<<' found
metricbeat/mb/builders.go:63: Merge conflict string '=======' found
metricbeat/mb/builders.go:65: Merge conflict string '>>>>>>>' found
x-pack/metricbeat/module/sql/query/query_integration_test.go:230: Merge conflict string '<<<<<<<' found
x-pack/metricbeat/module/sql/query/query_integration_test.go:231: Merge conflict string '=======' found
x-pack/metricbeat/module/sql/query/query_integration_test.go:245: Merge conflict string '>>>>>>>' found
x-pack/libbeat/cmd/instance/beat.go:109: Merge conflict string '<<<<<<<' found
x-pack/libbeat/cmd/instance/beat.go:123: Merge conflict string '=======' found
x-pack/libbeat/cmd/instance/beat.go:126: Merge conflict string '>>>>>>>' found

• x-pack/libbeat: Run check/update fails on the same root cause while formatting/parsing Go:

cmd/instance/beat.go:109:1: expected statement, found '<<'
cmd/instance/beat.go:118:4: expected ';', found 'else'
cmd/instance/beat.go:126:57: illegal character U+0023 '#'

Verification

I did not re-run the failing Buildkite commands locally because this checkout is at the original source commit 37f3d269d087d16b20e2450a2ed3ac602596aaa7, while the failing Buildkite run is on the generated 9.3 backport commit b265923669c53b14bf051c76eadbdc1f669de791. The log evidence and PR diff are sufficient to identify the blocking issue.

---

What is this? | From workflow: PR Buildkite Detective

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

[github-actions]

TL;DR

golangci-lint is failing on the 9.3 backport because x-pack/metricbeat/module/sql/query/query_integration_test.go now calls containsOracleClientError, but that helper is not present in the PR head. Restore the helper or remove that Oracle-client skip block from this backport.

Remediation

• Add containsOracleClientError to x-pack/metricbeat/module/sql/query/query_integration_test.go, or restore the file that defines it if the associated cursor integration tests are meant to be backported to 9.3.
• Re-run the GitHub Actions golangci-lint workflow; a narrower local check is golangci-lint run --new-from-merge-base upstream/9.3 --whole-files after checking out the PR branch.

Investigation details

Root Cause

This is a backport cleanup issue. PR #51779 added the Oracle Instant Client preflight block in x-pack/metricbeat/module/sql/query/query_integration_test.go, including this call:

if err != nil && containsOracleClientError(err.Error()) {

The current PR file list does not include x-pack/metricbeat/module/sql/query/cursor_integration_test.go or x-pack/metricbeat/module/sql/query/cursor/, and reading those paths at head commit e5a40af3032be0ccbd368aa81ebd616427188ae4 returns “file does not exist”. The helper exists on newer code in cursor_integration_test.go, but it was not brought into this backport branch.

This is a follow-on from the previous PR Actions Detective report: the earlier run failed in check-default on missing cursor package files, while this run reaches golangci-lint and fails on the remaining dangling helper reference.

Evidence

• Workflow: https://github.com/elastic/beats/actions/runs/28964029700
• Job/step: lint (ubuntu-latest) / golangci-lint
• Key log excerpt:

2026-07-08T18:02:26.1157771Z x-pack/metricbeat/module/sql/query/doc.go:1: : # github.com/elastic/beats/v7/x-pack/metricbeat/module/sql/query [github.com/elastic/beats/v7/x-pack/metricbeat/module/sql/query.test]
2026-07-08T18:02:26.1254730Z ##[error]x-pack/metricbeat/module/sql/query/query_integration_test.go:236:19: undefined: containsOracleClientError (typecheck)
2026-07-08T18:02:26.1273372Z * typecheck: 1

• PR changed files include x-pack/metricbeat/module/sql/query/query_integration_test.go, but no file defining containsOracleClientError at the PR head.

Validation

• Not run locally; this workflow is read-only and the GitHub Actions log directly identifies the typecheck failure.

Follow-up

• After fixing this helper reference, watch for any additional SQL module backport issues because this PR has already had multiple failures from omitted or partially restored SQL query files.

---

What is this? | From workflow: PR Actions Detective

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

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request