Since 1.16 is out, we still support the last four minor releases.
The bump was required by the prometheus/procfs package using the new
`%w` printf directives. However, it also allows us to remove some
special casing about build info.
Signed-off-by: beorn7 <beorn@grafana.com>
This commit adds a security policy to this repository. SECURITY.md files
are threated in a special way by GitHub, helping users to know how to
best submit security issues for the projects.
In this case, we simply point to our existing documentation on
prometheus.io.
The content of this file will be synced automatically with the
prometheus/prometheus repository, as our security policy covers all the
repositories. This sync is automated with prombot, like other files
(LICENSE, Makefile.common).
https://docs.github.com/en/free-pro-team@latest/github/managing-security-vulnerabilities/adding-a-security-policy-to-your-repository
Signed-off-by: Julien Pivotto <roidelapluie@inuits.eu>
Without this fix, the `InstrumentHandler...` middlewares get locked in
an endless loop in case of an invalid Collector, eating all the memory.
Signed-off-by: beorn7 <beorn@grafana.com>
* Added example api code showing how to add auth tokens and user agents to prom client.
Signed-off-by: Bartlomiej Plotka <bwplotka@gmail.com>
* Ran go mod tidy.
Signed-off-by: Bartlomiej Plotka <bwplotka@gmail.com>
MetricVec was already exported in early versions of this library, but
nobody really used it to implement vectors of custom Metric
implementations. Now #796 has shown up with a fairly special use case
for which I'd prefer a custom implementation of a special
"auto-sampling histogram" outside of this library. Therefore, I'd like
to reinstate support for creating vectors of custom Metric
implementations.
I played around for quite some while with the option of a separate
package providing the tools one would need to create vectors of custom
Metric implementations. However, with the current structure of the
prometheus/client_golang/prometheus package, this leads to a lot of
complications with circular dependencies. (The new package would need
the primitives from the prometheus package, while the existing metric
vectors like GaugeVec need to import the new vector package to not
duplicate the implementation. Separating vector types from the main
prometheus package is out of the question at this point because that
would be a breaking change.)
Signed-off-by: beorn7 <beorn@grafana.com>
When discussing #801, I remembered #794. While dealing with the
latter, I read the HTTP RFC, stumbling upon the following:
When a request method is received
that is unrecognized or not implemented by an origin server, the
origin server SHOULD respond with the 501 (Not Implemented) status
code. When a request method is received that is known by an origin
server but not allowed for the target resource, the origin server
SHOULD respond with the 405 (Method Not Allowed) status code.
Concluding from that, it is possible that a server desiring a fallback
to GET will send a status code of 501. It is even preferred if that
server does not offer any resource to be used with the POST method.
Therefore, I think we should fallback to GET on a 501, too.
Signed-off-by: beorn7 <beorn@grafana.com>
Björn Rabenstein