prometheus

Commit Graph

Author	SHA1	Message	Date
Oleg Zaytsev	2524a91591	Fix FastRegexMatcher matching multibyte runes with . (#14059 ) When `zeroOrOneCharacterStringMatcher` wach checking the input string, it assumed that if there are more than one bytes, then there are more than one runes, but that's not necessarily true. Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>	7 months ago
Matthieu MOREL	d496687c8e	golangci-lint: enable usestdlibvars linter Signed-off-by: Matthieu MOREL <matthieu.morel35@gmail.com>	8 months ago
Bryan Boreham	7c28521451	[TESTS] Truncate some long test names, for readability The strings produced by these tests can run to thousands of characters, which makes test logs difficult to read. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	8 months ago
carehabit	a672662073	all: fix some typos (#13863 ) Signed-off-by: carehabit <shenyuting@outlook.com>	8 months ago
Domantas	435f330d0b	[BUGFIX] labels: don't modify original labels in DropMetricName (#13845 ) Restrict the capacity of first argument to `append()` to force an allocation. This is for the slice implementation only. Signed-off-by: Domantas Jadenkus <djadenkus@gmail.com>	8 months ago
Bryan Boreham	48786ad4e8	Use slices insteda of exp/slices Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	8 months ago
Bryan Boreham	080d440bf8	Merge remote-tracking branch 'origin/main' into pr/13461	8 months ago
Oleg Zaytsev	d12e785075	Improve readability As suggested by @bboreham Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>	8 months ago
Oleg Zaytsev	9699598952	Improve Labels.Compare performance w/stringlabels I was bored on a train and I spent some amount of time trying to scratch some nanoseconds off the Labels.Compare when running with stringlabels. I would be ashamed to admit the real amount of time I spent on it. The worst thing is, I can't really explain why this is performing so much better, and someone should re-run the benchmarks on their machine to confirm that it's not something related to general relativity because the train is moving. I also added some extra real-life benchmark cases with longer labelsets (these aren't the longest we have in production, but kubernetes labelsets are fairly common in Prometheus so I thought it would be nice to have them). My benchmarks show this diff: goos: darwin goarch: arm64 pkg: github.com/prometheus/prometheus/model/labels │ old │ new │ │ sec/op │ sec/op vs base │ Labels_Compare/equal 5.898n ± 0% 5.875n ± 1% -0.40% (p=0.037 n=10) Labels_Compare/not_equal 11.78n ± 2% 11.01n ± 1% -6.54% (p=0.000 n=10) Labels_Compare/different_sizes 4.959n ± 1% 4.906n ± 2% -1.05% (p=0.050 n=10) Labels_Compare/lots 21.32n ± 0% 17.54n ± 5% -17.75% (p=0.000 n=10) Labels_Compare/real_long_equal 15.06n ± 1% 14.92n ± 0% -0.93% (p=0.000 n=10) Labels_Compare/real_long_different_end 25.20n ± 0% 24.43n ± 0% -3.04% (p=0.000 n=10) geomean 11.86n 11.25n -5.16% Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>	8 months ago
Bryan Boreham	0bb5588386	labels: optimize String method (#13673 ) Use a stack buffer to reduce memory allocations. `Write(AppendQuote(AvailableBuffer` does not allocate or copy when the buffer has sufficient space. Also add a benchmark, with some refactoring. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	9 months ago
machine424	f477e0539a	Move from golang.org/x/exp/slices into slices now that we only support Go >= 1.21 Prevent adding back golang.org/x/exp/slices. Signed-off-by: machine424 <ayoubmrini424@gmail.com>	9 months ago
Bryan Boreham	e1a741a0d7	labels: update copyright dates Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	9 months ago
Bryan Boreham	55e7de04f8	model/labels (stringlabels): use strings.Clone Suggestion from @colega. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	9 months ago
Bryan Boreham	d16ce3c9bd	model/labels (dedupelabels): small clarifications Suggestion from @colega. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	9 months ago
Bryan Boreham	b39286fd1f	Add dedupelabels tag to not build regular labels Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	9 months ago
Bryan Boreham	d51a5344cd	labels: new version de-duplicating strings in SymbolTables The individual strings for label names and values are held in a table, and each Labels value is a run of varint-encoded indexes into that table. When creating new labels, a sync.Mutex is locked around reads and writes. When reading labels, there is no locking because the table of strings used by those labels is immutable. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	9 months ago
Bryan Boreham	28191109a8	Labels: add fake versions of SymbolTable apis So we can use them where necessary for internlabels implementation. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	9 months ago
Bryan Boreham	d1af84f6ee	Labels: move Builder and Reset out of common New internstrings implementation is different. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	9 months ago
Bryan Boreham	5aa4473894	labels tests: extend TestBuilder Start with empty base labels, also check new and re-used symbol tables Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	9 months ago
Bryan Boreham	bb82a57e64	Labels: Call NewScratchBuilder in test_utils Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	9 months ago
Bryan Boreham	cc5dc6a61b	labels: use Equal instead of DeepEqual This will work better with a different data structure. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	9 months ago
beorn7	553d92affd	model/labels: Fix new lint warning in test Signed-off-by: beorn7 <beorn@grafana.com>	10 months ago
Bryan Boreham	14b4fbc2ff	labels: make InternStrings a no-op for stringlabels version The current implementation of `InternStrings` will only save memory when the whole set of labels is identical to one already seen, and this cannot happen in the one place it is called from in Prometheus, remote-write, which already detects identical series. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	10 months ago
Marco Pracucci	501bc6419e	Add ShardedPostings() support to TSDB (#10421 ) This PR is a reference implementation of the proposal described in #10420. In addition to what described in #10420, in this PR I've introduced labels.StableHash(). The idea is to offer an hashing function which doesn't change over time, and that's used by query sharding in order to get a stable behaviour over time. The implementation of labels.StableHash() is the hashing function used by Prometheus before stringlabels, and what's used by Grafana Mimir for query sharding (because built before stringlabels was a thing). Follow up work As mentioned in #10420, if this PR is accepted I'm also open to upload another foundamental piece used by Grafana Mimir query sharding to accelerate the query execution: an optional, configurable and fast in-memory cache for the series hashes. Signed-off-by: Marco Pracucci <marco@pracucci.com>	10 months ago
Bryan Boreham	74b73d1e2c	Labels: Add DropMetricName function, used in PromQL (#13446 ) This function is called very frequently when executing PromQL functions, and we can do it much more efficiently inside Labels. In the common case that `__name__` comes first in the labels, we simply re-point to start at the next label, which is nearly free. `DropMetricName` is now so cheap I removed the cache - benchmarks show everything still goes faster. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	10 months ago
Marco Pracucci	bfec57bd2e	Further optimise FastRegexMatcher Signed-off-by: Marco Pracucci <marco@pracucci.com>	10 months ago
Bryan Boreham	a3e02f35d6	labels: extract common code between slice and stringlabels This reduces bulk and should avoid issues if a fix is made in one file and not the other. A few methods now call `Range()` instead of `range`, but nothing performance-sensitive. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	1 year ago
Bryan Boreham	1bfb3ed062	Labels: reduce allocations when creating from TSDB WAL (#13044 ) * Labels: reduce allocations when creating from TSDB When reading the WAL, by passing references into the buffer we can avoid copying strings under `-tags stringlabels`. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	1 year ago
Oleksandr Redko	fa90ca46e5	ci(lint): enable godot; append dot at the end of comments Signed-off-by: Oleksandr Redko <Oleksandr_Redko@epam.com>	1 year ago
Goutham Veeramachaneni	86729d4d7b	Update exp package (#12650 )	1 year ago
Bryan Boreham	d6e1b1acdb	Merge pull request #12681 from prometheus/labels-unused-code labels: remove some unused code	1 year ago
Bryan Boreham	ce260b1fe1	labels: remove some unused code Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	1 year ago
Bryan Boreham	b5c6807fea	Labels.Has quick check on first character Exit early if we've gone past - labels are sorted in order. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	1 year ago
Bryan Boreham	33aab1b2cc	labels: extend benchmark for Has() Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	1 year ago
Bryan Boreham	e1115ae58d	labels: improve Get method for stringlabels build (#12485 ) Inline one call to `decodeString`, and skip decoding the value string until we find a match for the name. Do a quick check on the first character in each string, and exit early if we've gone past - labels are sorted in order. Also improve tests and benchmark: * labels: test Get with varying lengths - it's not typical for Prometheus labels to all be the same length. * extend benchmark with label not found --------- Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	1 year ago
Bryan Boreham	87d08abe11	labels: faster Compare function when using -tags stringlabels (#12451 ) Instead of unpacking every individual string, we skip to the point where there is a difference, going 8 bytes at a time where possible. Add benchmark for Compare; extend tests too. --------- Signed-off-by: Bryan Boreham <bjboreham@gmail.com> Co-authored-by: Oleg Zaytsev <mail@olegzaytsev.com>	1 year ago
Oleg Zaytsev	6a18962cfa	mv labels_string.go labels_stringlabels.go (#12328 ) This is a minor cosmetical change, but my IDE (and I guess many of them) nests `labels_string.go` under `labels.go` because it assumes it's the file generated by the `stringer` tool, which follows that naming pattern. Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>	1 year ago
Michael Hoffmann	344c8ff97c	feat: dont compile regex matcher if we know its a literal (#12434 ) labels: dont compile regex matcher if we know its a literal Signed-off-by: Michael Hoffmann <mhoffm@posteo.de> Co-authored-by: Sharad <sharadgaur@gmail.com>	1 year ago
Bryan Boreham	a073e04a9b	Merge pull request #12366 from prometheus/release-2.44 Merge release 2.44 back to main	2 years ago
Bryan Boreham	7a48a266b6	labels: respect Set after Del in Builder (#12322 ) * labels: respect Set after Del in Builder The implementations are not symmetric between `Set()` and `Del()`, so we must be careful. Add tests for this, both in labels and in relabel where the issue was reported. Also make the slice implementation consistent re `slices.Contains`. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago
cui fliter	276ca6a883	fix some comments Signed-off-by: cui fliter <imcusg@gmail.com>	2 years ago
beorn7	5b53aa1108	style: Replace `else if` cascades with `switch` Wiser coders than myself have come to the conclusion that a `switch` statement is almost always superior to a statement that includes any `else if`. The exceptions that I have found in our codebase are just these two: * The `if else` is followed by an additional statement before the next condition (separated by a `;`). * The whole thing is within a `for` loop and `break` statements are used. In this case, using `switch` would require tagging the `for` loop, which probably tips the balance. Why are `switch` statements more readable? For one, fewer curly braces. But more importantly, the conditions all have the same alignment, so the whole thing follows the natural flow of going down a list of conditions. With `else if`, in contrast, all conditions but the first are "hidden" behind `} else if `, harder to spot and (for no good reason) presented differently from the first condition. I'm sure the aforemention wise coders can list even more reasons. In any case, I like it so much that I have found myself recommending it in code reviews. I would like to make it a habit in our code base, without making it a hard requirement that we would test on the CI. But for that, there has to be a role model, so this commit eliminates all `if else` occurrences, unless it is autogenerated code or fits one of the exceptions above. Signed-off-by: beorn7 <beorn@grafana.com>	2 years ago
Bryan Boreham	1801cd4196	labels: small optimization to stringlabels Add a fast path for the common case that a string is less than 127 bytes long, to skip a shift and the loop. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago
Bryan Boreham	10cc60af01	labels: add ScratchBuilder.Overwrite for slice implementation This is a method used by some downstream projects; it was created to optimize the implementation in `labels_string.go` but we should have one for both implementations so the same code works with either. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago
Ganesh Vernekar	5588cab8b2	Merge pull request #12173 from bboreham/builder-no-empty-labels labels: simplify call to get Labels from Builder	2 years ago
Bryan Boreham	e917202766	labels: make sure estimated size is not negative Deleted labels are remembered, even if they were not in `base` or were removed from `add`, so `base+add-del` could go negative. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago
Bryan Boreham	ee1157c14a	labels: shrink stack arrays in Builder.Range Go spends some time initializing all the elements of these arrays to zero, so reduce the size from 1024 to 128. This is still much bigger than we ever expect for a set of labels. (If someone does have more than 128 labels it will still work, but via heap allocation.) Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago
Bryan Boreham	b987afa7ef	labels: simplify call to get Labels from Builder It took a `Labels` where the memory could be re-used, but in practice this hardly ever benefitted. Especially after converting `relabel.Process` to `relabel.ProcessBuilder`. Comparing the parameter to `nil` was a bug; `EmptyLabels` is not `nil` so the slice was reallocated multiple times by `append`. Lastly `Builder.Labels()` now estimates that the final size will depend on labels added and deleted. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago
Bryan Boreham	3743d87c56	labels: cope with mutating Builder during Range call Although we had a different slice, the underlying memory was the same so any changes meant we could skip some values. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago
Bryan Boreham	3c4ab7a069	labels: add test for Builder.Range Including mutating the Builder being Ranged over. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago

1 2

87 Commits (0ba747187da2313f8673088ae2673ca7a178a2f7)