api: Improve doc comments for v1.MinTime and v1.MaxTime
While investigated something mostly unrelated, I got nerd-sniped by
the calculation of v1.MinTime and v1.MaxTime. The seemingly magic
number in there (62135596801) needed an explanation. While looking for
it, I found out that the offsets used here are actually needlessly
conservative. Since the timestamps are so far in the past or future,
respectively, that there is no practical impact, except that the
calculation is needlessly obfuscated. However, we won't change the
values now to not cause any confusion for users of this code. Still, I
think the doc comment should explain the circumstances so nobody gets
nerd-sniped again as I did today.
For the record: 62135596800 is the difference in seconds between 0001-01-01 00:00:00 (Unix time zero point) and 1971-01-01 00:00:00 (Go time zero point) in the Gregorian calendar. If "Prometheus time" were in seconds (not milliseconds), that difference would be relevant to prevent over-/underflow when converting from "Prometheus time" to "Go time".
Signed-off-by: beorn7 <beorn@grafana.com>
---------
Signed-off-by: beorn7 <beorn@grafana.com>
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>
Sidecar containers are a newish feature in k8s. They're implemented
similar to init containers but actually stay running and allow you to
delay startup of your application pod until the sidecar started (like
init containers always do).
This adds the ports of the sidecar container to the list of discovered
endpoint(slice), allowing you to target those containers as well.
The implementation is a copy of that of Pod discovery
fixes: #14927
Signed-off-by: bas smit <bsmit@bol.com>
Without this, the page that is shown first renders once with an empty path
prefix value, since the settings update takes a render cycle to complete.
However, we only fetch certain data from the API exactly once for a given
page, and not for every re-render with changed path prefix value (and we
also wouldn't want to fetch it from the wrong location initially).
This duplicates the served endpoint list once more, but exporting them from
App.tsx would also have been dirty (hot reload only works when a file only
exports one component and nothing else, thus there'd be a linter warning).
Signed-off-by: Julius Volz <julius.volz@gmail.com>
This went under the radar because the utils are never called directly.
We usually marshall/unmarshal Configs as embeded in a struct using UnmarshalYAMLWithInlineConfigs/MarshalYAMLWithInlineConfigs
which bypasses Configs' custom UnmarshalYAML/MarshalYAML
Signed-off-by: machine424 <ayoubmrini424@gmail.com>
This switches from the prehistoric EventSource API to the more modern
fetch-event-source package. That packages gives us full control over the
retries.
It also gives us the opportunity to close the event source when the
browser tab is hidden, saving resources.
Signed-off-by: Julien <roidelapluie@o11y.eu>
This commit introduces a new `/api/v1/notifications/live` endpoint that
utilizes Server-Sent Events (SSE) to stream notifications to the web UI.
This is used to display alerts such as when a configuration reload
has failed.
I opted for SSE over WebSockets because SSE is simpler to implement and
more robust for our use case. Since we only need one-way communication
from the server to the client, SSE fits perfectly without the overhead
of establishing and maintaining a two-way WebSocket connection.
When the SSE connection fails, we go back to a classic
/api/v1/notifications API endpoint.
This commit also contains the required UI changes for the new Mantine UI.
Signed-off-by: Julien <roidelapluie@o11y.eu>
These functions operate on whole series, not on samples, so they do not
fit into the table of functions that return a Vector. Remove the stub
entries that were left to help downstream users of the code identify
what changed.
We cannot remove the entries from the `FunctionCalls` map without
breaking `TestFunctionList`, so put some nils in to keep it happy.
Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
The pattern of `import _ "net/http/pprof"` adds handlers to the default
http handler, but Prometheus does not use that. There are explicit
handlers in `web/web.go`.
So, we can remove this line with no impact to behaviour.
Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
* scrape/scrape_test.go: reduce the time it takes to reload the manager
TestNativeHistogramMaxSchemaSet took over 3x5s to complete because
there's a minimum reload interval.
I've made the testcases run in parallel and reduced the reload interval
to 10ms. Now the test runs in around 0.1-0.2 seconds.
Ran test 10000 times to check if it's flaky.
Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
---------
Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
* [ENHANCEMENT] Alerts: remove metrics for removed Alertmanagers
So they don't continue to report stale values.
Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
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>
We are still seeing lock contention on MemPostings.mtx, and MemPostings.Delete() is by far the most expensive operation on that mutex.
This adds parallelism to that method, trying to reduce the amount of time we spend with the mutex held.
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
dependabot[bot]