Add logic to the target_info metric generation in the OTLP endpoint, so that any samples with the same timestamp for the same (target_info) series are de-duplicated. It comes out of a user's bug report about duplicated target_info samples in Grafana Mimir (which uses the Prometheus target_info generation logic).
If I'm not mistaken, duplicate target_info samples should stem from multiple resources in the same OTLP request being translated to the same target_info label set. It shouldn't be caused by a Prometheus bug.
* Correctly generate rulesLintConfig when --lint=none is set (#17399)
If I run promtool check config --lint=none I get:
```
Checking rules.yml
FAILED:
rules.yml: unset nameValidationScheme
```
This is because passing --lint=none stops newConfigLintConfig from generating rulesLintConfig which is needed for validation.
It means that defaults are used then, one of which is unset value for metric name validation, causing this error.
Fix this by handling --lint=none case correctly and still generating rulesLintConfig.
---------
Signed-off-by: Lukasz Mierzwa <l.mierzwa@gmail.com>
Signed-off-by: Arve Knudsen <arve.knudsen@gmail.com>
Co-authored-by: Łukasz Mierzwa <l.mierzwa@gmail.com>
Reduce tsdb.TestHeadSeriesChunkRace number of iterations from 1000 to
100, to stop this test from timing out under CI.
Signed-off-by: Arve Knudsen <arve.knudsen@gmail.com>
If I run promtool check config --lint=none I get:
```
Checking rules.yml
FAILED:
rules.yml: unset nameValidationScheme
```
This is becuase passing --lint=none stops newConfigLintConfig from generating rulesLintConfig which is needed for validation.
It means that defaults are used then, one of which is unset value for metric name validation, causing this error.
Fix this by handling --lint=none case correctly and still generating rulesLintConfig.
Fixes#17398.
Signed-off-by: Lukasz Mierzwa <l.mierzwa@gmail.com>
* Add WriteProto method and tests for promtool metrics
This commit adds:
1. WriteProto method to storage/remote/client.go that handles
marshaling and compression of protobuf messages
2. Updated parseAndPushMetrics in cmd/promtool/metrics.go to use
the new WriteProto method
3. Comprehensive tests for PushMetrics functionality
The WriteProto method provides a cleaner API for sending protobuf
messages without manually handling marshaling and compression.
Signed-off-by: pipiland2612 <nguyen.t.dang.minh@gmail.com>
* use Write method from exp/api/remote
Signed-off-by: pipiland2612 <nguyen.t.dang.minh@gmail.com>
* fix
Signed-off-by: pipiland2612 <nguyen.t.dang.minh@gmail.com>
* fix lint
Signed-off-by: pipiland2612 <nguyen.t.dang.minh@gmail.com>
* fix test
Signed-off-by: pipiland2612 <nguyen.t.dang.minh@gmail.com>
* fix
Signed-off-by: pipiland2612 <nguyen.t.dang.minh@gmail.com>
* nit fixed
Signed-off-by: pipiland2612 <nguyen.t.dang.minh@gmail.com>
* fix lint
Signed-off-by: pipiland2612 <nguyen.t.dang.minh@gmail.com>
---------
Signed-off-by: pipiland2612 <nguyen.t.dang.minh@gmail.com>
Fixes: #16572
Mark as stable means that breaking changes are only allowed together with
major version release of Prometheus.
Co-authored-by: Björn Rabenstein <beorn@grafana.com>
Signed-off-by: George Krajcsovits <krajorama@users.noreply.github.com>
Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
TestScrapeLoop_HistogramBucketLimit tests the bucket limiter but it also sets sample_limit to the same value, which seems incorrect.
Signed-off-by: Lukasz Mierzwa <l.mierzwa@gmail.com>
Currently histograms bypass sample_limit logic as the limitAppender only implements the Append() method, while histograms are appended using AppendHistogram.
This means that they are effectively ignored during sample_limit checks and a scrape with sample_limit=100 and 500 histograms will accept all samples.
Add AppendHistogram method to the limitAppender so histograms are also counted towards sample_limit.
Signed-off-by: Lukasz Mierzwa <l.mierzwa@gmail.com>
This reverts commit 93887a9b82a71613067ff0706248c18fe131c5b0.
See discussion at https://github.com/prometheus/prometheus/pull/17240 - I had
thought this was a simple and clear bugfix, but multiple people were depending
on the previous behavior already, and we want to err on the side of stability.
Signed-off-by: Julius Volz <julius.volz@gmail.com>
The modifiers were already printed as part of the VectorSelector, so for:
`foo[5m] anchored`
...the output was:
`foo anchored[5m] anchored`
Similar to how it was already done for `@` and `offset`, I now removed these
modifiers in the copy of the vector selector that is used to print the matrix
selector. I also removed some unused code that restored the copy of the vector
selector after overwriting its fields. AFAICS there was no use in doing that,
since it was a copy already that would just be thrown away after printing, and
the original selector wasn't affected. I also removed an erroneous comment in
`atOffset()` where no actual copying took place and no fields were overwritten.
Signed-off-by: Julius Volz <julius.volz@gmail.com>
