[chore] Update prometheus to match OTel v0.120.0

[andrzej-stencel]

Proposed commit message

Update github.com/prometheus/prometheus dependency to v0.300.1
by running go get github.com/prometheus/prometheus@v0.300.1.
This version matches the version used in OTel v0.120.0,
and this update is needed to include OTel v0.120.0 in Elastic Agent.
See https://github.com/elastic/elastic-agent/pull/6912/files#diff-33ef32bf6c23acb95f5902d7097b7a1d5128ca061167ec0716715b0b9eeaa5f6R496.

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
• [ ] I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @andrzej-stencel? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-8./d is the label to automatically backport 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.

[elasticmachine]

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

[andrzej-stencel]

cc @blakerouse for 👀 as you created a similar PR before.

[andrzej-stencel]

I've pushed a commit to fix the compilation error by adding missing parameters to the textparse.New call.

See textparse.New@v0.54.1 (before this change) and textparse.New@v0.300.1 (after this change).

I've set fallbackType argument to empty string "" and skipOMCTSeries to false.
OMCT series are OpenMetrics CreatedTimestamp timeseries,
and I believe the default for this is false.

[elasticmachine]

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

[cmacknz]

Pinging @elastic/obs-infraobs-integrations as they own the prometheus integration that depends on this and are most likely to know how to test any impact this might have. https://github.com/elastic/integrations/blob/119156a21359b7a56756e91743b18d6970b9c643/packages/prometheus/manifest.yml#L35

[MichaelKatsoulis]

In https://github.com/elastic/beats/blob/26fecc126fe80b648471e401a7b175cf2165ab1b/metricbeat/mb/testing/testdata.go#L119C6-L119C23 the default content type is application/json which in new textParse

https://github.com/prometheus/prometheus/blob/1f56e8492c31a558ccea833027db4bd7f8b6d0e9/model/textparse/interface.go#L128

func New(b []byte, contentType, fallbackType string, parseClassicHistograms, skipOMCTSeries bool, st *labels.SymbolTable) (Parser, error) {
	mediaType, err := extractMediaType(contentType, fallbackType)
	// err may be nil or something we want to warn about.

	switch mediaType {
	case "application/openmetrics-text":
		return NewOpenMetricsParser(b, st, func(o *openMetricsParserOptions) {
			o.SkipCTSeries = skipOMCTSeries
		}), err
	case "application/vnd.google.protobuf":
		return NewProtobufParser(b, parseClassicHistograms, st), err
	case "text/plain":
		return NewPromParser(b, st), err
	default:
		return nil, err
	}
}

is not supported as mediaType. For the same behaviour as in previous versions we could use text/plain instead.

[MichaelKatsoulis]

@pkoutsovasilis before we merge this, I have a concern regarding one test that is Flaky.
It is related to the leaderlection process.
Here is the test:
https://github.com/elastic/beats/blame/e26baff8300e552174c1027db79a3cc0fc067ea9/libbeat/autodiscover/providers/kubernetes/kubernetes_test.go#L102

The test timeouts and it is something that is never happening in the main branch. The test uses the k8s.io library that was also updated as dependency in this PR.
They have changed some stuff in the LeaderElection process between the old version 0.29.5 and 0.31.1.
Maybe it is just that something that the test was taking for granted in old version is not happening in the new.

The test breaks when one node loses the leader lock but stopLeading is not executed.
Because of that when a second nodes becomes the leader, and test enters in lines , then checkLoosingLeaders is called that waits in these lines for the previous node to signal that it stopped leading. That never happens and it timeouts.

That is weird and I tested multiple times and this signal is never received.

[pkoutsovasilis]

Thanks for the heads up @MichaelKatsoulis! I saw the CI green and the code changes made sense to me thus I didn't assume that there isn't any Flaky tests in it 🙂 Please hold your horses people on merging this one. @MichaelKatsoulis please let us know when you are confident about this one

[belimawr]

Not a big deal because it's a test, but why was the content type changed?

[cmacknz]

#42748 (comment) looks like it explains this

[swiatekm]

@MichaelKatsoulis have you been able to reproduce this test failure locally? I tried on main after bumping the k8s libraries, and it didn't fail once in 100 runs.

[MichaelKatsoulis]

@MichaelKatsoulis have you been able to reproduce this test failure locally? I tried on main after bumping the k8s libraries, and it didn't fail once in 100 runs.

@swiatekm
Yes it is failing many times locally. Did you clean the go test cache before running the tests?
I was using:

go clean -testcache && /usr/local/go/bin/go test -timeout 30s -run ^TestNewLeaderElectionManager$ github.com/elastic/beats/v7/libbeat/autodiscover/providers/kubernetes -v

Also the PR ci was failing almost every time. Check one buildkite output that shows exactly that.

I updated the test logic because I think it was faulty in the part that it was forcing the lease renewals.
I believe now it is better.
Also I tested in a real cluster and there was no problem with the new library. So there was no bug.

[MichaelKatsoulis]

For me the PR is good to be merged!