Prometheus

Changelog

1. 0.6.2

   Prometheus 0.6.2: listing every metric means leaving match out, and the plugin says so

   After 0.6.1 read "{}" as no match, an agent asked for everything with {job=~".*"} instead, and Prometheus refused that too: a selector that would match every series is not one it takes, and its own message does not say what to do instead. The description now says to leave match out to list every metric, and names that kind of selector as one that is refused; when one is passed anyway, the error says the same.

   A server answering 200 with something that is not Prometheus's API - a login page, a web app that serves itself at every path - used to read as an empty list, which looks exactly like a Prometheus with nothing in it. It is now an error naming the connection's url, which is where the mistake usually is.

2. 0.6.1

   Prometheus 0.6.1: "now" and "{}" mean what an agent meant by them

   Asked to query the present, an agent passed time "now", and asked for every metric it passed match "{}". Prometheus refuses both - it parses neither as a timestamp nor as a selector, since a selector needs at least one matcher - so the call failed with a 400 for doing what it was asked.

   Both are now read as what they mean: "now" (any case) is the same as leaving time out, and "{}" is the same as no match at all. match may also be left out now, rather than having to be passed empty, and both descriptions say to leave the argument out instead of describing a value to write.

3. 0.6.0

   Prometheus 0.6.0: every call says which Prometheus it asks

   0.5 made the server a Prometheus connection, but the plugin still took one of them, in a setting - so a workspace with production, staging and a Thanos in front of both could only ever ask one.

   listMetrics and query now take the connection as their first argument, prometheus: picked from a list in a workflow, passed by id from an agent. Add a Prometheus connection per server and each call names the one it means. There is nothing left to configure on the plugin's own page.

   Coming from 0.5: the plugin's prometheus parameter is gone. A workflow calling listMetrics or query needs the new first argument set to the connection the parameter used to name. This needs a server that resolves a connection argument; on an older one the call says the connection never reached it rather than asking nowhere.

4. 0.5.0

   Prometheus 0.5.0: the server to ask is a Prometheus connection

   Prometheus used to be configured on the plugin's own page: a url, a username and a token. That meant one Prometheus per workspace, and its token typed into a plugin setting rather than kept where a workspace keeps hosts.

   The plugin now brings a connection kind of its own, Prometheus. Add one per server with its root as the URL - no auth for a bare Prometheus, Bearer for one behind a token, Basic with instanceId:token as the secret for Grafana Cloud - and point the plugin's prometheus parameter at it. The address and credential stay on the connection, encrypted, and the picker offers only Prometheus connections.

   Coming from 0.4: the url, username and token parameters are gone. Make a Prometheus connection from them and point prometheus at it. This needs a server that hands a plugin's own kind of connection over with its address; on an older one the plugin says so rather than calling nowhere.

   The library mirrors connectionTypes() end to end - the contract, the ambient globals, inspect, validate, definePlugin and the check report - and a connection parameter may name the plugin's own kind by its bare name, as the upload allows. A handle now says what such a connection carries: url, authType, secret and headers.

5. 0.4.1

   Every plugin takes a patch version

   Thirteen patches, because what changed is a manifest field: category became tags in the last commit and no code moved with it. Patch is the honest size of that.

   Worth knowing what a version bump does here, since the last two releases deliberately avoided one. The schema says publishing a key again with a new version replaces the file and moves the listing back to the top of "newest first" - so this puts all thirteen there at once, which makes that ordering say nothing for this batch. And a server compares the version against what it recorded at install to decide whether to offer an update, so every installation of every plugin will now say one is available, for tags.

   That is the cost of asking the catalogue to carry a number that moved. The alternative - republishing the same versions, which is what the schema means by fixing a description - was what the previous two releases did.