Prometheus has issues parsing RFC3339Nano timestamps if the year has more than 4 digits, in addition it is the second-pass parse attempt. Since this is a client library and the interface is a `time.Time` it makes sense that we pick the clearest simplest format-- so I propose we use the `model.Time` representation of time in our communications to prometheus. This (1) removes the issues with timezones in those queries going downstream and (2) completely works around this #614 issue as the parsing mechanism in prometheus can handle those times in this format.
Related to #614
Signed-off-by: Thomas Jackson <jacksontj.89@gmail.com>
This allows us to simplify a bunch of code while still supporting the
last four Go minor versions.
We have also run into minor annoyances a couple of times by now to
keep supporting 1.7 and 1.8.
It's time to pull the plug!
Signed-off-by: Bjoern Rabenstein <bjoern@rabenste.in>
This PR adds support for fetching [rules](https://prometheus.io/docs/prometheus/latest/querying/api/#rules) via the `/api/v1/rules` endpoint using the API client. Currently, the API client exposes no way to do this and it would be nice to have for external systems that wish to retrieve this information.
400 and 422 are documented error codes from Prometheus, so we should
attempt to parse the error returned for both of them.
Needed to change a test that was requiring the old behaviour - made it
use 500 instead of 400.
Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
This commit creates a new package to hold the prometheus
v1 API interface. This interface will contain all the funcionality
exposed by Prometheus v1 HTTP API.
The underlying http client is kept on the api package since it
may be reused across diferent API versions and also by the Alertmanager
api package (to come.)
Thomas Jackson