Allows connecting to alertmanager instances behind a TLS endpoint that
requires mutual TLS. Conveniently also allows specifying a CA
certificate file for alertmanagers that use trusted roots not in the
system root trust store.
Fixes: https://github.com/prometheus/alertmanager/issues/2652
Signed-off-by: Joe Groocock <me@frebib.net>
This commit adds a `--created-by` argument to the `amtool silence
query` command so that silences can be filtered by the author they
were created with in `amtool silence add --author=<name>`.
Signed-off-by: nre <nre@ableton.com>
* amtool: Detect version drift and warn users
This change detects the alertmanager version when initiating the client.
It ignores most errors since I expect amtool to fail later.
If amtool is not compiled with proper version, we do not do anything
either.
We use MajorMinor for now as we have not reach 1.0, but we still allow
the bugfix version number (Z in x.y.Z) to differ.
Signed-off-by: Julien Pivotto <roidelapluie@inuits.eu>
* Add version check
Signed-off-by: Julien Pivotto <roidelapluie@inuits.eu>
* cli: add new template render command
Add a new template rendering command that allows users to test out their
templates. This is especially needed because small bugs in templates do
not surface until alertmanager actually tries to render them.
* cli: permit passing alert data via a file
Add a new parameter `--templatefile` for `amtool` so that it would be
possible to pass custom alert data. Use an example `template.Data` if
none has been passed to permit simple use-cases.
Signed-off-by: Giedrius Statkevičius <giedrius.statkevicius@vinted.com>
Check the error type when there is a non-existent silence
instead of comparing the text of the error message.
Signed-off-by: Paul Gier <pgier@redhat.com>
* simplified setting first assumed alertname in cli/silence_query.go
* added assumed first label to alertname when adding silences
Signed-off-by: Hrishikesh Barman <hrishikeshbman@gmail.com>
The documentation stated that the `alertname=`
part of a matcher could be dropped and it would be
assumed that the first value was the alertname.
This behavior was only honored if there was a
single matcher, but failed if there were multiple.
Any time we have one or more matchers, check to
see if the first matcher fails parsing. If so,
assume it's intended to be used as the alertname,
and append that value to the matcher.
Signed-off-by: Stuart Nelson <stuartnelson3@gmail.com>
* Add support for adding alerts using amtool
Signed-off-by: Bob Shannon <bshannon@palantir.com>
* comment: Simplify return in addAlert
Signed-off-by: Bob Shannon <bshannon@palantir.com>
* amtool: add support for stdin to check-config
Signed-off-by: Simon Pasquier <spasquie@redhat.com>
* Address Stuart's comment
Signed-off-by: Simon Pasquier <spasquie@redhat.com>
* Amtool: Implement filter by receiver
* Adds receiver flag to amtool alert query
* Adds receiver argument to alert http client
* Updates http client tests for added argument
Also works: scpecifying `receiver: "receiver-123"` in config file
automaticly filters all alerts shown
* Include receiver in amtool config docs
Now that I've implemented the receiver in amtool I should add the new
feature to the documentation.
* #937 Add mention of supporting regex syntax to receiver flag
