prometheus

Commit Graph

Author	SHA1	Message	Date
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
zenador	191bf9055b	Handle more arithmetic operators for native histograms (#12262 ) Handle more arithmetic operators and aggregators for native histograms This includes operators for multiplication (formerly known as scaling), division, and subtraction. Plus aggregations for average and the avg_over_time function. Stdvar and stddev will (for now) ignore histograms properly (rather than counting them but adding a 0 for them). Signed-off-by: Jeanette Tan <jeanette.tan@grafana.com>	2 years ago
Bryan Boreham	a073e04a9b	Merge pull request #12366 from prometheus/release-2.44 Merge release 2.44 back to main	2 years ago
beorn7	9e500345f3	textparse/scrape: Add option to scrape both classic and native histograms So far, if a target exposes a histogram with both classic and native buckets, a native-histogram enabled Prometheus would ignore the classic buckets. With the new scrape config option `scrape_classic_histograms` set, both buckets will be ingested, creating all the series of a classic histogram in parallel to the native histogram series. For example, a histogram `foo` would create a native histogram series `foo` and classic series called `foo_sum`, `foo_count`, and `foo_bucket`. This feature can be used in a migration strategy from classic to native histograms, where it is desired to have a transition period during which both native and classic histograms are present. Note that two bugs in classic histogram parsing were found and fixed as a byproduct of testing the new feature: 1. Series created from classic _gauge_ histograms didn't get the _sum/_count/_bucket prefix set. 2. Values of classic _float_ histograms weren't parsed properly. Signed-off-by: beorn7 <beorn@grafana.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
cui fliter	276ca6a883	fix some comments Signed-off-by: cui fliter <imcusg@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
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
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
Matthieu MOREL	fb3eb21230	enable gocritic, unconvert and unused linters Signed-off-by: Matthieu MOREL <matthieu.morel35@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
Björn Rabenstein	847093479b	Merge pull request #11978 from trevorwhitney/set-counter-hint Set `CounterResetHint` and use in recording rules	2 years ago
Trevor Whitney	e3513d1dd2	Change nested ifs to a switch Signed-off-by: Trevor Whitney <trevorjwhitney@gmail.com>	2 years ago
Trevor Whitney	b4e324f637	Handle valid cases of mismatched hints when adding Signed-off-by: Trevor Whitney <trevorjwhitney@gmail.com>	2 years ago
Trevor Whitney	dd94ebb87b	promql: set CounterResetHint after rate and sum Signed-off-by: Trevor Whitney <trevorjwhitney@gmail.com>	2 years ago
Julien Pivotto	5583c77b3a	Merge pull request #12095 from damnever/unnecessary-sort Remove unnecessary sort	2 years ago
Xiaochao Dong (@damnever)	36fc1158b5	Remove unnecessary sort Signed-off-by: Xiaochao Dong (@damnever) <the.xcdong@gmail.com>	2 years ago
Bryan Boreham	11d019ed5a	relabel: keep intermediate results in labels.Builder Save work converting between Builder and Labels. Also expose ProcessBuilder, so callers can supply a Builder. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago
Bryan Boreham	d740abf0c6	model/labels: add Get and Range to Builder This lets relabelling work on a `Builder` rather than converting to and from `Labels` on every rule. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago
Bryan Boreham	ff993b279a	Merge pull request #12073 from bboreham/slices-sort2 labels: use slices.Sort for better performance	2 years ago
Bryan Boreham	38c6d3da9f	labels: use slices.Sort for better performance The difference is modest, but we've used `slices.Sort` in lots of other places so why not here. name old time/op new time/op delta Builder 1.04µs ± 3% 0.95µs ± 3% -8.27% (p=0.008 n=5+5) name old alloc/op new alloc/op delta Builder 312B ± 0% 288B ± 0% -7.69% (p=0.008 n=5+5) name old allocs/op new allocs/op delta Builder 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.008 n=5+5) Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago
Bryan Boreham	a07a0be024	Add benchmark for labels.Builder Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago
Bryan Boreham	30297f0d9b	stringlabels: size buffer for added labels This makes the buffer the correct size for the common case that labels have only been added. It will be too large for the case that labels are changed, but the current buffer resize logic in `appendLabelTo` doubles the buffer, so a small over-estimate is better. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago
Jonatan Ivanov	9225d118dc	Add Exemplars support for all time series This change removes restrictions to allow adding exemplars to all time series. It also contains some improvements in test values so that it is easier to track what is tested. The advantage of doing this is having a little less error-prone tests: "yy" is not really descriptive but "counter-test" can give people a better idea about what is tested so it is harder to make mistakes. Closes gh-11982 Signed-off-by: Jonatan Ivanov <jonatan.ivanov@gmail.com>	2 years ago
Renning Bruns	5ec1b4baaf	make hashmod a lot easier to read and a little faster (#11551 ) Previous code was effectively doing BigEndian.Uint64, so call that and save time. An md5.Sum result is always 16 bytes. The first 8 are not used in the result, just as before. Signed-off-by: Renning Bruns <ren@renmail.net>	2 years ago
Bryan Boreham	35026fb26d	Merge pull request #11746 from prometheus/remove-microbenchmarks These benchmarks were testing things related to what Prometheus does, but not testing actual Prometheus code. Moved the label-copying benchmark into the labels package.	2 years ago
Levi Harrison	64ff6bece6	Merge pull request #11682 from dgrisonnet/parsing-errors Improve the Prometheus parser error outputs to be more comprehensive	2 years ago
Bryan Boreham	f03b8d0968	Add benchmark copying labels Taken from previous tsdb/test/BenchmarkLabelsClone. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago
Damien Grisonnet	0fee615719	model/textparse: improve openmetrics error outputs Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>	2 years ago
Bryan Boreham	6136ae67e0	labels: shrink by making internals a single string This commit adds an alternate implementation for `labels.Labels`, behind a build tag `stringlabels`. Instead of storing label names and values as individual strings, they are all concatenated into one string in this format: [len][name0][len][value0][len][name1][len][value1]... The lengths are varint encoded so usually a single byte. The previous `[]string` had 24 bytes of overhead for the slice and 16 for each label name and value; this one has 16 bytes overhead plus 1 for each name and value. In `ScratchBuilder.Overwrite` and `Labels.Hash` we use an unsafe conversion from string to byte slice. `Overwrite` is explicitly unsafe, but for `Hash` this is a pure performance hack. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	2 years ago
Damien Grisonnet	e3b5416d05	model/textparse: improve error outputs Parsing errors in the Prometheus HTTP format parser are very hard to investigate since they only approximately indicate what is going wrong in the parser and don't provide any information about the incorrect input. As such it is very hard to tell what is wrong in the format exposed by the application. Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>	2 years ago
Julien Pivotto	8e500dbd39	Add rulefmt tests Signed-off-by: Julien Pivotto <roidelapluie@o11y.eu>	2 years ago
Julien Pivotto	ce55e5074d	Add 'keep_firing_for' field to alerting rules This commit adds a new 'keep_firing_for' field to Prometheus alerting rules. The 'resolve_delay' field specifies the minimum amount of time that an alert should remain firing, even if the expression does not return any results. This feature was discussed at a previous dev summit, and it was determined that a feature like this would be useful in order to allow the expression time to stabilize and prevent confusing resolved messages from being propagated through Alertmanager. This approach is simpler than having two PromQL queries, as was sometimes discussed, and it should be easy to implement. This commit does not include tests for the 'resolve_delay' field. This is intentional, as the purpose of this commit is to gather comments on the proposed design of the 'resolve_delay' field before implementing tests. Once the design of the 'resolve_delay' field has been finalized, a follow-up commit will be submitted with tests." See https://github.com/prometheus/prometheus/issues/11570 Signed-off-by: Julien Pivotto <roidelapluie@o11y.eu>	2 years ago
beorn7	3e5ad99c33	textparse: Minor doc comment improvement Signed-off-by: beorn7 <beorn@grafana.com>	2 years ago
beorn7	3f977e89ab	textparse: Add tests for float and gauge histograms Signed-off-by: beorn7 <beorn@grafana.com>	2 years ago
beorn7	c26891043f	textparse: Set CounterResetHint If a (float or integer) histogram is a gauge histogram, set the CounterResetHint accordingly. (The default value is fine for the normal counter histograms.) Signed-off-by: beorn7 <beorn@grafana.com>	2 years ago
Björn Rabenstein	f07adbd45f	Merge pull request #11814 from prometheus/beorn7/protobuf textparse: Add gauge histogram support	2 years ago
Ganesh Vernekar	57bcbf1888	Merge pull request #11783 from codesome/gauge-histogram tsdb: Add gauge histogram support	2 years ago
Ganesh Vernekar	a87e7e9e33	tsdb: Add counter reset hint to histograms and support in WAL Signed-off-by: Ganesh Vernekar <ganeshvern@gmail.com>	2 years ago
Ganesh Vernekar	c94a41c4b2	Merge pull request #11785 from Fish-pro/erroris Use errors.Is to check for a specific error	2 years ago
beorn7	b5d4a94e9d	textparse: Add gauge histogram support to protobuf parsing With this commit, the parser stops to see a gauge histogram (whether native or conventional) as an unexpected metric type. It ingests it normally, it even sets the `GaugeHistogram` type in the metadata (as it has already done for a conventional gauge histogram scraped using OpenMetrics), but it otherwise treats it as a normal counter-like histogram. Once #11783 is merged, though, it should be very easy to utilize the type information. Signed-off-by: beorn7 <beorn@grafana.com>	2 years ago
beorn7	e9d9bb1b08	textparse: Handle unknown metric types in protobuf gracefully So far, the parser hasn't validated that the type is valid in the `Next()` call. Later, in the `Series()` call, however, it assumes that we will only see valid types and therefore panics with `encountered unexpected metric type, this is a bug`. This commit fixes said bug by adding validation to the `Next()` call. Signed-off-by: beorn7 <beorn@grafana.com>	2 years ago
Damien Grisonnet	96b9d8cebb	model/textparse: associate correct token to errors In some cases, the Prometheus HTTP format parser was not returning the right token in the error output which made debugging impossible. Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>	2 years ago

1 2 3 4 5

203 Commits (344c8ff97ce261dbaaf2720f1e5164a8fee19184)