* 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
* Update Architecture diagram
Update diagram from sketch to vector.
Add draw.io XML source file.
Update README.md to display master doc/arch.jpg
Signed-off-by: Silvio Gissi <silvio@gissilabs.com>
* Updated README.md with relative link to architecture doc.
* Updated Architecture document from JPG to SVG
Signed-off-by: Silvio Gissi <silvio@gissilabs.com>
* Small fix in graph.
* Updated font to align with Prometheus architecture.
Signed-off-by: Silvio Gissi <silvio@gissilabs.com>
* Embedded images at arch.svg
* Removed images from SVG, update source XML
The cluster configuration uses DefaultLANConfig which seems
to be quite sensitive to WAN conditions. Allowing the tuning of these 3
parameters (TCP Timeout, Probe Interval and Probe Timeout) makes
clustering more robust across WAN connections.
Signed-off-by: Rhys Meaclem <rhysmeaclem@gmail.com>
* Provide README information for amtool
Amtool has been bundled with alertmanager for a while now. It's probably
far past the acceptable time to add information to the readme
* Fixups based on recommendations
* replace `,` with `.` in first sentance
* Add silence query example with filtering
* Add silence add example with multiple matchers and a regex
* Add silence expire all example that shows query -q
* Add configfile example
* Anchor silence regex rules
When user creates a new silence with regex match it's left to the user to anchor it, which is not consistent with Prometheus regex handling (promql/functions.go#L818).
* Serialize AlertStatus as 'status'
AlertStatus doesn't have json tag with the field name, so it's serialized into 'Status', and it's the only uppercase field in the alert object. Tag it with 'status' name for consistency
* Fix lock usage in the types package
Locking is a bit tricky there since some state-modifying methods will call to other methods that also modify marker state, simple defer won't work.
* Throw error when continue in route root of Alertmanager config
* Fix alert status handling in UI
* Fixes#746
Found that we are only defining MarshalJSON for the Regexp type for
references not for the direct object
Also took the time to simplify the json.Unmarshal usage in cli/config.go
* Added unit test for continue in root route error (#768)
* Added unit test for continue in root route error
* replaced %v with %q
* Fix broken link to silence from alert
* Fix broken link to silence from alert
* *: cut v0.6.2 (#777)
* Show startsAt time for pending silences (#778)
* docs: Add note to not load balance Alert trafic
* Find MAC address if mesh.hardware-addr not given
Defaulting to the machine's MAC address fails
sometimes fails and causes a panic. Allow the user
to specify custom address to skip this so they can
run AlertManager.
* -mesh.hardware-address -> -mesh.peer-id
* Fix command-line invocation
The continue examples were not aligned with the current semantics and
are mostly important for advanced use cases. Those are not in the scope
of this basic example.
Since our default templates are now compiled into the binary, this is only
relevant to advanced users and will cause trouble when running a derivative
of the example config within the repository directory.
