prometheus

Commit Graph

Author	SHA1	Message	Date
Bryan Boreham	3d26faade4	Create 2.44.0-rc.1 (#12323 ) Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	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
Bryan Boreham	d70688038e	Merge pull request #12289 from bboreham/release-2.44-rc0 Create new Release Candidate 2.44.0-rc0	2 years ago
Bryan Boreham	6b25e9a923	build: turn on stringlabels by default This setting uses less memory, and was optional in previous release 2.43. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago
Bryan Boreham	8bfd162198	Review feedback - mostly capitalization Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago
Bryan Boreham	aeccf9e770	Bump version to 2.44.0-rc0 Including CHANGELOG. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago
Bryan Boreham	cf1bea344a	Merge pull request #12191 from narqo/web-gomemlimit Display GOMEMLIMIT in runtime info	2 years ago
Vladimir Varankin	d281ebb178	web: display GOMEMLIMIT in runtime info Signed-off-by: Vladimir Varankin <vladimir@varank.in>	2 years ago
Julien Pivotto	7cd9f8a340	Merge pull request #12285 from bboreham/update-older-go Update test_golang_oldest to 1.19	2 years ago
Bryan Boreham	13938d0ccc	Update test_golang_oldest to 1.19 Since test_go is on 1.20, and it should use the previous version. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago
Björn Rabenstein	d52a976ee1	Merge pull request #12272 from zenador/check-histogram-type-on-convert Perform integer/float histogram type checking on conversions	2 years ago
Jeanette Tan	1102ffd188	Fix according to code review Signed-off-by: Jeanette Tan <jeanette.tan@grafana.com>	2 years ago
Jeanette Tan	e9a1e26ab7	Perform integer/float histogram type checking on conversions, and use a consistent method for determining integer vs float histogram Signed-off-by: Jeanette Tan <jeanette.tan@grafana.com>	2 years ago
Julien Pivotto	8f1dc4a70f	Merge pull request #12248 from yeya24/consistent-response Use same error for instant and range query when 400	2 years ago
Julien Pivotto	0b212fd123	Merge pull request #12279 from mmorel-35/linters golangci-lint: remove skip-cache and restore singleCaseSwitch rule	2 years ago
Julien Pivotto	388eb03923	Merge pull request #12277 from roidelapluie/restore-main Revert type casting removal	2 years ago
Matthieu MOREL	7e9acc2e46	golangci-lint: remove skip-cache and restore singleCaseSwitch rule Signed-off-by: Matthieu MOREL <matthieu.morel35@gmail.com>	2 years ago
Björn Rabenstein	78cd9ae2c3	Merge pull request #12264 from rabenhorst/sample-ring-iterator-mixed-histograms-fix Fix for `sampleRingIterator` with mixed histograms	2 years ago
Julien Pivotto	637235f0a6	Revert type casting removal This reverts the removal of type casting due to an error in the dragonfly integration. The change in the type casting introduced by the commit causes a type mismatch, resulting in the following errors: util/runtime/limits_default.go:42:57: cannot use rlimit.Cur (variable of type int64) as type uint64 in argument to limitToString util/runtime/limits_default.go:42:90: cannot use rlimit.Max (variable of type int64) as type uint64 in argument to limitToString Reverting this commit to resolve the type mismatch error and maintain compatibility with the dragonfly integration. Signed-off-by: Julien Pivotto <roidelapluie@o11y.eu>	2 years ago
Julien Pivotto	f7c6130ff2	Merge pull request #12251 from prymitive/query_samples_total Add query_samples_total metric	2 years ago
Julien Pivotto	e2512078e5	Merge pull request #12241 from mmorel-35/linter/nilerr enable gocritic, unconvert and unused linters	2 years ago
Bryan Boreham	59176e5a97	Merge pull request #12271 from bboreham/update-go-deps Update many Go dependencies	2 years ago
gotjosh	2f22c8b7f8	Merge pull request #12270 from prometheus/gotjosh/allow-filtering-of-rules-by-name-api Rules API: Allow filtering by rule name	2 years ago
gotjosh	e78be38cc0	don't show empty groups Signed-off-by: gotjosh <josue.abreu@gmail.com>	2 years ago
gotjosh	74e6668e87	update docs Signed-off-by: gotjosh <josue.abreu@gmail.com>	2 years ago
Bryan Boreham	1f04415494	Update many Go dependencies Ran `make update-go-deps` then hand-edited to remove any downgrades. Then backed out changes to: * Azure: still waiting someone to test this. * Kubernetes: needs update elsewhere to klog. * kube-openapi: it doesn't compile with previous Go version. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago
Matthieu MOREL	bae9a21200	Merge branch 'main' into linter/nilerr Signed-off-by: Matthieu MOREL <matthieu.morel35@gmail.com>	2 years ago
Björn Rabenstein	69155c6ba1	Merge pull request #12252 from prometheus/beorn7/lint Lint clean-up	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
beorn7	c3c7d44d84	lint: Adjust to the lint warnings raised by current versions of golint-ci We haven't updated golint-ci in our CI yet, but this commit prepares for that. There are a lot of new warnings, and it is mostly because the "revive" linter got updated. I agree with most of the new warnings, mostly around not naming unused function parameters (although it is justified in some cases for documentation purposes – while things like mocks are a good example where not naming the parameter is clearer). I'm pretty upset about the "empty block" warning to include `for` loops. It's such a common pattern to do something in the head of the `for` loop and then have an empty block. There is still an open issue about this: https://github.com/mgechev/revive/issues/810 I have disabled "revive" altogether in files where empty blocks are used excessively, and I have made the effort to add individual `// nolint:revive` where empty blocks are used just once or twice. It's borderline noisy, though, but let's go with it for now. I should mention that none of the "empty block" warnings for `for` loop bodies were legitimate. Signed-off-by: beorn7 <beorn@grafana.com>	2 years ago
gotjosh	cf230bcd18	more wordsmithing Signed-off-by: gotjosh <josue.abreu@gmail.com>	2 years ago
gotjosh	28909a4636	more worthsmithing Signed-off-by: gotjosh <josue.abreu@gmail.com>	2 years ago
gotjosh	e2a2790b2c	add more docs Signed-off-by: gotjosh <josue.abreu@gmail.com>	2 years ago
gotjosh	96b6463f25	review comments Signed-off-by: gotjosh <josue.abreu@gmail.com>	2 years ago
Đurica Yuri Nikolić	b028112331	Making the number of CPU cores used for sorting postings lists editable (#12247 ) Signed-off-by: Yuri Nikolic <durica.nikolic@grafana.com>	2 years ago
Julien Pivotto	bb217dded8	Merge pull request #12269 from yeya24/add-ctx-engine-interface Add ctx to QueryEngine interface	2 years ago
gotjosh	f3394bf7a1	Rules API: Allow filtering by rule name Introduces support for a new query parameter in the `/rules` API endpoint that allows filtering by rule names. If all the rules of a group are filtered, we skip the group entirely. Signed-off-by: gotjosh <josue.abreu@gmail.com>	2 years ago
Bryan Boreham	cdf42df698	Merge pull request #12267 from bboreham/faster-decodesize labels: small optimization to stringlabels	2 years ago
Ben Ye	fd3630b9a3	add ctx to QueryEngine interface Signed-off-by: Ben Ye <benye@amazon.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
Sebastian Rabenhorst	5d4ec08a1f	Fixed sampleRingIterator for mixed histograms Signed-off-by: Sebastian Rabenhorst <sebastian.rabenhorst@shopify.com> Fixed sampleRingIterator for mixed histograms Signed-off-by: Sebastian Rabenhorst <sebastian.rabenhorst@shopify.com> Fixed lint	2 years ago
Ganesh Vernekar	7309ac2721	Merge pull request #12257 from alexqyle/block-populator-rename Rename PopulateBlockFunc to BlockPopulator	2 years ago
Matthieu MOREL	fb3eb21230	enable gocritic, unconvert and unused linters Signed-off-by: Matthieu MOREL <matthieu.morel35@gmail.com>	2 years ago
Björn Rabenstein	6b8573a846	Merge pull request #11687 from prometheus/beorn7/histogram histograms: Optimize query performance	2 years ago
beorn7	717a3f8e25	storage: Manually expand `genericAdd` for specific types This commit is doing what I would have expected that Go generics do for me. However, the PromQL benchmarks show a significant runtime and allocation increase with `genericAdd`, so this replaces it with hand-coded non-generic versions of it. Signed-off-by: beorn7 <beorn@grafana.com>	2 years ago
beorn7	551de0346f	promql: Do not return nil slices to the pool Signed-off-by: beorn7 <beorn@grafana.com>	2 years ago
beorn7	817a2396cb	Name float values as "floats", not as "values" In the past, every sample value was a float, so it was fine to call a variable holding such a float "value" or "sample". With native histograms, a sample might have a histogram value. And a histogram value is still a value. Calling a float value just "value" or "sample" or "V" is therefore misleading. Over the last few commits, I already renamed many variables, but this cleans up a few more places where the changes are more invasive. Note that we do not to attempt naming in the JSON APIs or in the protobufs. That would be quite a disruption. However, internally, we can call variables as we want, and we should go with the option of avoiding misunderstandings. Signed-off-by: beorn7 <beorn@grafana.com>	2 years ago
beorn7	462240bc78	storage: add specialized buffers to sampleRing This utilizes the fact that most sampleRings will only contain samples of one type. In this case, the generic interface is circumvented, and a bespoke buffer for the one actually occurring sample type is used. Should a sampleRing receive a sample of a different kind later, it will transparently switch to the generic behavior. Signed-off-by: beorn7 <beorn@grafana.com>	2 years ago
beorn7	630bcb494b	storage: Use separate sample types for histogram vs. float Previously, we had one “polymorphous” `sample` type in the `storage` package. This commit breaks it up into `fSample`, `hSample`, and `fhSample`, each still implementing the `tsdbutil.Sample` interface. This reduces allocations in `sampleRing.Add` but inflicts the penalty of the interface wrapper, which makes things worse in total. This commit therefore just demonstrates the step taken. The next commit will tackle the interface overhead problem. Signed-off-by: beorn7 <beorn@grafana.com>	2 years ago
beorn7	c0879d64cf	promql: Separate `Point` into `FPoint` and `HPoint` In other words: Instead of having a “polymorphous” `Point` that can either contain a float value or a histogram value, use an `FPoint` for floats and an `HPoint` for histograms. This seemingly small change has a _lot_ of repercussions throughout the codebase. The idea here is to avoid the increase in size of `Point` arrays that happened after native histograms had been added. The higher-level data structures (`Sample`, `Series`, etc.) are still “polymorphous”. The same idea could be applied to them, but at each step the trade-offs needed to be evaluated. The idea with this change is to do the minimum necessary to get back to pre-histogram performance for functions that do not touch histograms. Here are comparisons for the `changes` function. The test data doesn't include histograms yet. Ideally, there would be no change in the benchmark result at all. First runtime v2.39 compared to directly prior to this commit: ``` name old time/op new time/op delta RangeQuery/expr=changes(a_one[1d]),steps=1-16 391µs ± 2% 542µs ± 1% +38.58% (p=0.000 n=9+8) RangeQuery/expr=changes(a_one[1d]),steps=10-16 452µs ± 2% 617µs ± 2% +36.48% (p=0.000 n=10+10) RangeQuery/expr=changes(a_one[1d]),steps=100-16 1.12ms ± 1% 1.36ms ± 2% +21.58% (p=0.000 n=8+10) RangeQuery/expr=changes(a_one[1d]),steps=1000-16 7.83ms ± 1% 8.94ms ± 1% +14.21% (p=0.000 n=10+10) RangeQuery/expr=changes(a_ten[1d]),steps=1-16 2.98ms ± 0% 3.30ms ± 1% +10.67% (p=0.000 n=9+10) RangeQuery/expr=changes(a_ten[1d]),steps=10-16 3.66ms ± 1% 4.10ms ± 1% +11.82% (p=0.000 n=10+10) RangeQuery/expr=changes(a_ten[1d]),steps=100-16 10.5ms ± 0% 11.8ms ± 1% +12.50% (p=0.000 n=8+10) RangeQuery/expr=changes(a_ten[1d]),steps=1000-16 77.6ms ± 1% 87.4ms ± 1% +12.63% (p=0.000 n=9+9) RangeQuery/expr=changes(a_hundred[1d]),steps=1-16 30.4ms ± 2% 32.8ms ± 1% +8.01% (p=0.000 n=10+10) RangeQuery/expr=changes(a_hundred[1d]),steps=10-16 37.1ms ± 2% 40.6ms ± 2% +9.64% (p=0.000 n=10+10) RangeQuery/expr=changes(a_hundred[1d]),steps=100-16 105ms ± 1% 117ms ± 1% +11.69% (p=0.000 n=10+10) RangeQuery/expr=changes(a_hundred[1d]),steps=1000-16 783ms ± 3% 876ms ± 1% +11.83% (p=0.000 n=9+10) ``` And then runtime v2.39 compared to after this commit: ``` name old time/op new time/op delta RangeQuery/expr=changes(a_one[1d]),steps=1-16 391µs ± 2% 547µs ± 1% +39.84% (p=0.000 n=9+8) RangeQuery/expr=changes(a_one[1d]),steps=10-16 452µs ± 2% 616µs ± 2% +36.15% (p=0.000 n=10+10) RangeQuery/expr=changes(a_one[1d]),steps=100-16 1.12ms ± 1% 1.26ms ± 1% +12.20% (p=0.000 n=8+10) RangeQuery/expr=changes(a_one[1d]),steps=1000-16 7.83ms ± 1% 7.95ms ± 1% +1.59% (p=0.000 n=10+8) RangeQuery/expr=changes(a_ten[1d]),steps=1-16 2.98ms ± 0% 3.38ms ± 2% +13.49% (p=0.000 n=9+10) RangeQuery/expr=changes(a_ten[1d]),steps=10-16 3.66ms ± 1% 4.02ms ± 1% +9.80% (p=0.000 n=10+9) RangeQuery/expr=changes(a_ten[1d]),steps=100-16 10.5ms ± 0% 10.8ms ± 1% +3.08% (p=0.000 n=8+10) RangeQuery/expr=changes(a_ten[1d]),steps=1000-16 77.6ms ± 1% 78.1ms ± 1% +0.58% (p=0.035 n=9+10) RangeQuery/expr=changes(a_hundred[1d]),steps=1-16 30.4ms ± 2% 33.5ms ± 4% +10.18% (p=0.000 n=10+10) RangeQuery/expr=changes(a_hundred[1d]),steps=10-16 37.1ms ± 2% 40.0ms ± 1% +7.98% (p=0.000 n=10+10) RangeQuery/expr=changes(a_hundred[1d]),steps=100-16 105ms ± 1% 107ms ± 1% +1.92% (p=0.000 n=10+10) RangeQuery/expr=changes(a_hundred[1d]),steps=1000-16 783ms ± 3% 775ms ± 1% -1.02% (p=0.019 n=9+9) ``` In summary, the runtime doesn't really improve with this change for queries with just a few steps. For queries with many steps, this commit essentially reinstates the old performance. This is good because the many-step queries are the one that matter most (longest absolute runtime). In terms of allocations, though, this commit doesn't make a dent at all (numbers not shown). The reason is that most of the allocations happen in the sampleRingIterator (in the storage package), which has to be addressed in a separate commit. Signed-off-by: beorn7 <beorn@grafana.com>	2 years ago

1 2 3 4 5 ...

11132 Commits (3d26faade4069b70b5a5cc3a53b56c7654c38a49) All Branches Search

11132 Commits (3d26faade4069b70b5a5cc3a53b56c7654c38a49)

All Branches