prometheus

Commit Graph

Author	SHA1	Message	Date
sujal shah	4408a6bcaf	api: Create `/status/tsdb/blocks` endpoint. this endpoint serves blocks data to the client. Signed-off-by: sujal shah <sujalshah28092004@gmail.com>	6 months ago
Charles Korn	d19a9ab673	Remove other instances of "obvious" Signed-off-by: Charles Korn <charles.korn@grafana.com>	6 months ago
Charles Korn	1977452331	Address PR feedback: adjust docs to match current behaviour Signed-off-by: Charles Korn <charles.korn@grafana.com>	6 months ago
Charles Korn	665eb3d6cb	Address PR feedback: remove use of "obvious" Signed-off-by: Charles Korn <charles.korn@grafana.com>	6 months ago
Charles Korn	70df21a680	Address PR feedback: format Inf and NaN as monospace Signed-off-by: Charles Korn <charles.korn@grafana.com>	6 months ago
Charles Korn	9c6916f4f9	Address PR feedback: add blank lines before lists Signed-off-by: Charles Korn <charles.korn@grafana.com>	6 months ago
George Krajcsovits	5b7ff92d95	fix(promql): histogram_quantile and histogram_fraction NaN observed in native histogram (#16724 ) * fix(promql): histogram_quantile NaN observed in native histogram Fixes: #16578 See the issue for detailed explanation. When a histogram had only NaN observations and no normal observations, we returned 0 from the quantile, which is completely wrong. If there were normal observations but we went over them, we returned the upper bound of the existing buckets, however that contradicts expectations on histogram_fraction. Now we return NaN if the quantile is calculated to be over all normal observations, falling into NaNs (in a virtual +Inf bucket). We also return info level annotations if we see any NaN observations. The annotation calls out if we returned NaN or even if we took the virtual +Inf bucket into account. Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com> * fix(promql): histogram_fraction NaN observed in native histogram Fixes: #16580 According to the specification we should not take NaN observations into account when calculating the fraction. This commit fixes that and adds an info level annotation to let the user know about this. Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>	6 months ago
Michael Hoffmann	a5fa9431d8	promql: add ts_of_(max,min,last)_over_time functions This commit adds the ts_of_(max,min,last)_over_time functions behind the experimental feature flag. Signed-off-by: Michael Hoffmann <mhoffmann@cloudflare.com>	7 months ago
Charles Korn	5926159f2a	Clarify expected behaviour of `on(__name__)` See https://github.com/prometheus/prometheus/issues/16631 Signed-off-by: Charles Korn <charles.korn@grafana.com>	7 months ago
Charles Korn	0c6ef1b23c	Clarify behaviour of `bool` modifier Signed-off-by: Charles Korn <charles.korn@grafana.com>	7 months ago
Charles Korn	40bed6281e	Clarify behaviour of metric names with `bool` modifier Based on discussion in https://github.com/prometheus/prometheus/issues/15471 Signed-off-by: Charles Korn <charles.korn@grafana.com>	7 months ago
Charles Korn	1e794f7ef9	Break large paragraphs into smaller pieces Signed-off-by: Charles Korn <charles.korn@grafana.com>	7 months ago
Julius Volz	13564c03ef	Standardize doc page title handling See https://groups.google.com/g/prometheus-developers/c/cwL3cM66Em8 Signed-off-by: Julius Volz <julius.volz@gmail.com>	7 months ago
marcoderama	778d49bbfb	docs: fix typo in operators.md Signed-off-by: marcoderama <marcoderamagit@gmail.com>	8 months ago
Julius Volz	1b818b03d5	Clean up codeboxes and headings in docs The new docs site will have syntax highlighting, so this adds language tags to code boxes that are currently missing them. I didn't add `promql` as a language yet since the highlighter doesn't support it yet, plus a lot of the PromQL codeboxes in our docs aren't strictly valid PromQL, they are more like multiple expressions listed in the same code box on multiple lines. So I'm leaving that for sometime later. In the HTTP API page, I moved the curl examples from the JSON codeboxes to their own ones above the JSON output. I considered putting an "Output:" text between the curl + JSON output, but I think the way it currently looks without it is probably fine. I also fixed a number of headings which were at the wrong level relative to their nesting in the document. I also removed `go` as a language from the Go template language examples, because the Go template language isn't Go at all. I also adjusted the indent on one codebox to be more reasonable (2 spaces instead of 8). And then finally, my editor made a bunch of whitespace changes automatically, like removing trailing spaces. Signed-off-by: Julius Volz <julius.volz@gmail.com> Signed-off-by: Julius Volz <julius.volz@gmail.com>	8 months ago
Aman	26bddcf068	promql: histogram_stddev and histogram_stdvar should use arithmetic mean for custom buckets Signed-off-by: amanycodes <amanycodes@gmail.com>	9 months ago
Michael Hoffmann	d6d9f97bac	promql: histogram_fraction for bucket histograms (#16095 ) * promql: histogram_fraction for bucket histograms This PR extends the histogram_fraction function to also work with classic bucket histograms. This is beneficial because it allows expressions like sum(increase(my_bucket{le="0.5"}[10m]))/sum(increase(my_total[10m])) to be written without knowing the actual values of the "le" label, easing the transition to native histograms later on. It also feels natural since histogram_quantile also can deal with classic histograms. Signed-off-by: Michael Hoffmann <mhoffmann@cloudflare.com> * promql: histogram_fraction for bucket histograms * Add documentation and reduce code duplication * Fix a bug in linear interpolation between bucket boundaries * Add more PromQL tests Signed-off-by: Michael Hoffmann <mhoffmann@cloudflare.com> * Update docs/querying/functions.md Co-authored-by: Björn Rabenstein <github@rabenste.in> Signed-off-by: Michael Hoffmann <mhoffm@posteo.de> --------- Signed-off-by: Michael Hoffmann <mhoffmann@cloudflare.com> Signed-off-by: Michael Hoffmann <mhoffm@posteo.de> Co-authored-by: Björn Rabenstein <github@rabenste.in>	9 months ago
co63oc	0e4e5a71bd	Fix typos (#16076 ) Signed-off-by: co63oc <co63oc@users.noreply.github.com>	10 months ago
Julius Volz	4be2243f06	Include scrape pool name for dropped targets in /api/v1/targets This is needed so we can display dropped targets in the right scrape pool in the web interface even if they have a non-default job name. See also https://github.com/prometheus/prometheus/pull/16078 Fixes https://github.com/prometheus/prometheus/issues/16065 Signed-off-by: Julius Volz <julius.volz@gmail.com>	10 months ago
Charles Korn	2cfd402b3a	Clarify sorting behaviour of `topk` and `bottomk`. Signed-off-by: Charles Korn <charles.korn@grafana.com>	11 months ago
Charles Korn	acd74b02fb	Fix typo Signed-off-by: Charles Korn <charles.korn@grafana.com>	11 months ago
beorn7	993d4e71c9	docs: Update PromQL documentation to match the native histogram spec This is also meant to document the actual implementation, but see #13934 for the current state. This also improves and streamlines some parts of the documentation that are not strictly native histogram related, but are colocated with them. In particular, the section about aggregation operators got restructured quite a bit, including the removal of a quite verbose example for `limit_ratio` (which was just too long an this location and also a bit questionabl in its usefulness). Signed-off-by: beorn7 <beorn@grafana.com>	11 months ago
asymmetric	96f31e370b	doc: clarify `rate` values are averaged (#14045 ) * doc: clarify `rate` values are averaged Signed-off-by: asymmetric <101816+asymmetric@users.noreply.github.com> Co-authored-by: Björn Rabenstein <github@rabenste.in>	11 months ago
sh0rez	5303e515af	remote/otlp: convert delta to cumulative (#15165 ) What Adds support for OTLP delta temporality to the OTLP endpoint. This is done by calling the deltatocumulative processor from the OpenTelemetry collector during OTLP conversion. Why Delta conversion is a naturally stateful process, which requires careful request routing when operated inside a collector. Prometheus is already stateful and doing the conversion in-server reduces the operational burden on the ingest architecture by only having one stateful component. How deltatocumulative is a OTel collector component that works as follows: * pmetric.Metrics come from a receiver or in this case from the HTTP client * It operates as an in-place update loop: * for each sample, if not delta, leave unmodified * if delta, do: * state += sample, where state is the in-memory sum of all previous samples * sample = state, sample value is now cumulative * this is supported for sums (counters), gauges, histograms (old histograms) and exponential histograms (native histograms) If a series receives no new samples for 5m, its state is removed from memory Performance Delta performance is a stateful operation and the OTel code is not highly optimized yet, e.g. it locks the entire processor for each request. Nonetheless, care has been taken to mitigate those effects: delta conversion is behind a feature flag. If disabled, no conversion code is ever invoked if enabled, conversion is not invoked if request not actually contains delta samples. This leads to no measureable performance difference between default-cumulative to convert-cumulative (only cumulative, feature on/off) Signed-off-by: sh0rez <me@shorez.de>	12 months ago
Vandit Singh	6339989e25	web/api: Add a limit parameter to /query and /query_range (#15552 ) add limit param to query and rangeQuery --------- Signed-off-by: Vandit Singh <vanditsinghkv@gmail.com> Signed-off-by: Vandit Singh <107131545+Vandit1604@users.noreply.github.com> Co-authored-by: Björn Rabenstein <github@rabenste.in>	1 year ago
sujal shah	73a3438c1b	api: Add two new fields Node and ServerTime. This commit introduced two field in `/status` endpoint: - The node currently serving the request. - The current server time for debugging time drift issues. fixes #15394. Signed-off-by: sujal shah <sujalshah28092004@gmail.com>	1 year ago
Owen Williams	12577e3851	Add support for values unescaping on `/v1/label/:name/values` endpoint Signed-off-by: Owen Williams <owen.williams@grafana.com>	1 year ago
Kateryna Pavlova	d6e43b89f4	docs: add regex section in querying basics Signed-off-by: Kateryna Pavlova <kathrinett@gmail.com>	1 year ago
Kateryna Pavlova	bc008f1b0e	docs: fix range queries link Signed-off-by: Kateryna Pavlova <kathrinett@gmail.com>	1 year ago
Jonathan Ballet	7ca90e5729	doc: fix formatting Signed-off-by: Jonathan Ballet <jon@multani.info>	1 year ago
Yijie Qin	d2802c6fac	api: Add rule group pagination to list rules api (#14017 ) * Add paginated feature to list rules api Signed-off-by: Yijie Qin <qinyijie@amazon.com> * Refactor to simplify code: * Reduce number of variables * Reduce type convesion Signed-off-by: Raphael Silva <rapphil@gmail.com> * Simplify paginated implementation * Remove maxAlerts parameter. * Reuse existing API responses by using omitempty in some fields Signed-off-by: Raphael Silva <rapphil@gmail.com> * Simplify pagination implementation * Eliminate the need to sort the rule groups. Signed-off-by: Raphael Silva <rapphil@gmail.com> * Fix linting error Signed-off-by: Raphael Silva <rapphil@gmail.com> * Add more unit tests Signed-off-by: Raphael Silva <rapphil@gmail.com> * Update pagination parameters to be consistent with existing parameters Signed-off-by: Raphael Silva <rapphil@gmail.com> * Rename max_rule_groups to max_groups Signed-off-by: Raphael Silva <rapphil@gmail.com> * Refactor to simplify code Signed-off-by: Raphael Silva <rapphil@gmail.com> * Refactor to simplify the calculation of next token Signed-off-by: Raphael Silva <rapphil@gmail.com> * Handle corner case in pagination request Signed-off-by: Raphael Silva <rapphil@gmail.com> * Handle corner cases for pagination of list rules Signed-off-by: Raphael Silva <rapphil@gmail.com> * Update documentation for list rules parameters Signed-off-by: Raphael Silva <rapphil@gmail.com> * Refactor comments Signed-off-by: Raphael Silva <rapphil@gmail.com> * Simplify pagination implementation * Eliminate need for extra structs to store pagination parameters Signed-off-by: Raphael Silva <rapphil@gmail.com> * Update docs/querying/api.md Co-authored-by: Julius Volz <julius.volz@gmail.com> Signed-off-by: Raphael Philipe Mendes da Silva <rapphil@gmail.com> * Update web/api/v1/api.go Co-authored-by: Bartlomiej Plotka <bwplotka@gmail.com> Signed-off-by: Raphael Philipe Mendes da Silva <rapphil@gmail.com> * Update comment describing the need for next token Signed-off-by: Raphael Silva <rapphil@gmail.com> --------- Signed-off-by: Yijie Qin <qinyijie@amazon.com> Signed-off-by: Raphael Silva <rapphil@gmail.com> Signed-off-by: Raphael Philipe Mendes da Silva <rapphil@gmail.com> Co-authored-by: Raphael Silva <rapphil@gmail.com> Co-authored-by: Julius Volz <julius.volz@gmail.com> Co-authored-by: Bartlomiej Plotka <bwplotka@gmail.com>	1 year ago
Arve Knudsen	de16f5e387	[FEATURE] PromQL: Add experimental info function MVP (#14495 ) The `info` function is an experiment to improve UX around including labels from info metrics. `info` has to be enabled via the feature flag `--enable-feature=promql-experimental-functions`. This MVP of info simplifies the implementation by assuming: * Only support for the target_info metric * That target_info's identifying labels are job and instance Also: * Encode info samples' original timestamp as sample value * Deduce info series select hints from top-most VectorSelector --------- Signed-off-by: Arve Knudsen <arve.knudsen@gmail.com> Co-authored-by: Ying WANG <ying.wang@grafana.com> Co-authored-by: Augustin Husson <augustin.husson@amadeus.com> Co-authored-by: Bartlomiej Plotka <bwplotka@gmail.com> Co-authored-by: Björn Rabenstein <github@rabenste.in> Co-authored-by: Bryan Boreham <bjboreham@gmail.com>	1 year ago
Viet Hung Nguyen	f0a9f62ce8	[DOCS] Querying basics: what can be graphed Put a scalar to query, it can be graphed. So the doc says "an expression that returns an instant vector is the only type which can be graphed." is not correct? And also, a query_range, which used for graph, always return a range vector <https://promlabs.com/blog/2020/06/18/the-anatomy-of-a-promql-query/#range-queries> , so it's confusing to read the above statement. Signed-off-by: Viet Hung Nguyen <hvn@familug.org>	1 year ago
beorn7	08d4b034da	docs: Declare "float literals are time durations" as stable This unifies the documentation of float literals and time durations and updates all references to the old definitions. Signed-off-by: beorn7 <beorn@grafana.com>	1 year ago
Julien	db730fcade	Document the notifications API Signed-off-by: Julien <roidelapluie@o11y.eu>	1 year ago
Jan Fajerski	563bfdd384	storage: require selectors to always return matching results Signed-off-by: Jan Fajerski <jfajersk@redhat.com>	1 year ago
Jesus Vazquez	77d3b3aff3	OTLP: Remove experimental word form OTLP receiver (#14894 ) The OTLP receiver can now considered stable. We've had it for longer than a year in main and has received constant improvements. Signed-off-by: Jesus Vazquez <jesusvzpg@gmail.com>	1 year ago
Craig Ringer	15b68e989c	Refer to staleness in instant vector documentation The instant vector documentation does not explain which metric samples are selected - in particular, it makes no reference to staleness. It's confusing when reading the docs to understand how exactly Prometheus selects the metrics to report: the most recent sample older than the search timestamp specified in the API request, so long as that metric is not "stale". Signed-off-by: Craig Ringer <craig.ringer@enterprisedb.com>	1 year ago
Jan Fajerski	96e5a94d29	promql: rename holt_winters to double_exponential_smoothing Signed-off-by: Jan Fajerski <jfajersk@redhat.com>	1 year ago
beorn7	6fcd225aee	promql(native histograms): Introduce exponential interpolation The linear interpolation (assuming that observations are uniformly distributed within a bucket) is a solid and simple assumption in lack of any other information. However, the exponential bucketing used by standard schemas of native histograms has been chosen to cover the whole range of observations in a way that bucket populations are spread out over buckets in a reasonably way for typical distributions encountered in real-world scenarios. This is the origin of the idea implemented here: If we divide a given bucket into two (or more) smaller exponential buckets, we "most naturally" expect that the samples in the original buckets will split among those smaller buckets in a more or less uniform fashion. With this assumption, we end up with an "exponential interpolation", which therefore appears to be a better match for histograms with exponential bucketing. This commit leaves the linear interpolation in place for NHCB, but changes the interpolation for exponential native histograms to exponential. This affects `histogram_quantile` and `histogram_fraction` (because the latter is more or less the inverse of the former). The zero bucket has to be treated specially because the assumption above would lead to an "interpolation to zero" (the bucket density approaches infinity around zero, and with the postulated uniform usage of buckets, we would end up with an estimate of zero for all quantiles ending up in the zero bucket). We simply fall back to linear interpolation within the zero bucket. At the same time, this commit makes the call to stick with the assumption that the zero bucket only contains positive observations for native histograms without negative buckets (and vice versa). (This is an assumption relevant for interpolation. It is a mostly academic point, as the zero bucket is supposed to be very small anyway. However, in cases where it _is_ relevantly broad, the assumption helps a lot in practice.) This commit also updates and completes the documentation to match both details about interpolation. As a more high level note: The approach here attempts to strike a balance between a more simplistic approach without any assumption, and a more involved approach with more sophisticated assumptions. I will shortly describe both for reference: The "zero assumption" approach would be to not interpolate at all, but _always_ return the harmonic mean of the bucket boundaries of the bucket the quantile ends up in. This has the advantage of minimizing the maximum possible relative error of the quantile estimation. (Depending on the exact definition of the relative error of an estimation, there is also an argument to return the arithmetic mean of the bucket boundaries.) While limiting the maximum possible relative error is a good property, this approach would throw away the information if a quantile is closer to the upper or lower end of the population within a bucket. This can be valuable trending information in a dashboard. With any kind of interpolation, the maximum possible error of a quantile estimation increases to the full width of a bucket (i.e. it more than doubles for the harmonic mean approach, and precisely doubles for the arithmetic mean approach). However, in return the _expectation value_ of the error decreases. The increase of the theoretical maximum only has practical relevance for pathologic distributions. For example, if there are thousand observations within a bucket, they could _all_ be at the upper bound of the bucket. If the quantile calculation picks the 1st observation in the bucket as the relevant one, an interpolation will yield a value close to the lower bucket boundary, while the true quantile value is close to the upper boundary. The "fancy interpolation" approach would be one that analyses the _actual_ distribution of samples in the histogram. A lot of statistics could be applied based on the information we have available in the histogram. This would include the population of neighboring (or even all) buckets in the histogram. In general, the resolution of a native histogram should be quite high, and therefore, those "fancy" approaches would increase the computational cost quite a bit with very little practical benefits (i.e. just tiny corrections of the estimated quantile value). The results are also much harder to reason with. Signed-off-by: beorn7 <beorn@grafana.com>	1 year ago
Jan Fajerski	15cea39136	promql: put holt_winters behind experimental feature flag Signed-off-by: Jan Fajerski <jfajersk@redhat.com>	1 year ago
Julius Volz	f1e0939f2f	Document /api/v1/parse_expr endpoint Signed-off-by: Julius Volz <julius.volz@gmail.com>	1 year ago
Kevin Rawal	b0677263c3	Update basics.md fix broken URL for feature flags native histograms in querying prometheus documentation Signed-off-by: Kevin Rawal <84058124+kevinrawal@users.noreply.github.com>	1 year ago
suntala	ce4eac859a	Link to specific feature flag entry Signed-off-by: suntala <arati.rana@grafana.com>	1 year ago
suntala	532904a1d6	Document changes to sort by label Co-authored-by: Aleks Fazlieva <britishrum@users.noreply.github.com> Signed-off-by: suntala <arati.rana@grafana.com>	1 year ago
suntala	77d111e501	Fix links to feature flags page Signed-off-by: suntala <arati.rana@grafana.com>	1 year ago
Bryan Boreham	cc7dcf5afe	[DOCS] Querying basics: explain range and instant queries I often see people ask questions that indicate they don't understand this point, and launching into "instant vector" and "range vector" is likely to point them in the wrong direction. Remove the admonishment that the reader mustn't confuse these things. Remove mention of "inferred sample timestamps" that is never explained. Signed-off-by: Bryan Boreham <bjboreham@gmail.com>	1 year ago
咸鱼暄	bab098a4c1	change all lists to bullets Signed-off-by: 咸鱼暄 <30610597+smd1121@users.noreply.github.com>	2 years ago
咸鱼暄	ad03ede602	fix markdown list Signed-off-by: 咸鱼暄 <30610597+smd1121@users.noreply.github.com>	2 years ago
beorn7	706e19912b	adjust version number in documentation Signed-off-by: beorn7 <beorn@grafana.com>	2 years ago

1 2 3 4 5 ...

267 Commits (4408a6bcafe4e70b29341e69fce473c8e2d03b67)