amtool 真的太棒了吧？

嘿！普罗米修斯圣诞日历2018的第23天，我是sugitak！

虽然Prometheus有很多优点，但其中很大一部分也是Alertmanager的优秀之处。Alertmanager正如其名，能够实现对警报的抑制、内容整合、静默和路由等细致的控制，满足开发和运维中所需的警报控制。

这个Alertmanager好像并没有讨论使用方法的热情…真是浪费。
有了附带的amtool工具，就可以随心所欲地调整Alertmanager的内容，不仅可以进行测试和调试，甚至可以单独使用Alertmanager而无需依赖Prometheus。

因此，在本篇文章中，将介绍用于充分利用Alertmanager功能的工具amtool的使用方法。也可以称其为我的反弹簧。

准备

准备Alertmanager和amtool工具。
Alertmanager可以方便地通过apt或docker进行使用。

安装Alertmanager

$ sudo apt install prometheus-alertmanager

由于 apt 的依赖中没有 prometheus，所以可以单独安装 Alertmanager。这样做感觉很“明白”，我喜欢这样。
如果在 Docker 中有 prom/alertmanager 镜像，就可以运行起来，如果你熟悉使用它的话，那可能更加稳定。

因此，只安装Alertmanager并不能安装Amtool，因此我们可以使用go get进行安装。

$ go get github.com/prometheus/alertmanager/cmd/amtool
$ amtool
usage: amtool [<flags>] <command> [<args> ...]

View and modify the current Alertmanager state.

Config File: The alertmanager tool will read a config file in YAML format from one of two default config locations:
$HOME/.config/amtool/config.yml or /etc/amtool/config.yml

All flags can be given in the config file, but the following are the suited for static configuration:

  alertmanager.url
    Set a default alertmanager url for each request
...

amtool 的使用方法

amtool 是一个用 Go 语言编写的简单 CLI 软件。
需要将要访问的 Alertmanager 地址作为选项传递。

$ amtool --alertmanager.url http://localhost:9093 alert
Alertname  Starts At  Summary

因为不能每次都写 -alertmanager.url http://localhost:9093，所以我们应该创建一个配置文件。配置可以放置在 /etc/amtool/config.yml 或者 $HOME/.config/amtool/config.yml 中，并且会生效。

$ cat /etc/amtool/config.yml
alertmanager.url: "http://localhost:9093"

创建警报

在此格式中，您可以添加警报。这样不仅可以用于Prometheus的调试目的，而且还可以从其他工具发出警报，非常方便。

$ amtool add <Alertname> [<label>=<value>]

比如添加这样的警报…

$ amtool alert add TooMuchOpenFiles Stage=staging Role=web

当我查看警报列表时，确实可以看到已经添加了警报。哇哦，我真喜欢警报！我喜欢亮亮的警报。

$ amtool alert
Alertname         Starts At                Summary
TooMuchOpenFiles  2018-12-23 15:28:12 UTC

因为只用alert的话，标签就不会显示出来，有点不方便。这种情况下可以用-o extended选项。可以更详细地查看包括标签在内的内容。太好了。

$ amtool alert -o extended
Labels                                                   Annotations  Starts At                Ends At                  Generator URL
Role="web" Stage="staging" alertname="TooMuchOpenFiles"               2018-12-23 15:28:12 UTC  0001-01-01 00:00:00 UTC

如果想将此设为默认显示，请在设置文件中添加一行 output: “extended” 来进行设置。目前还没有 verbose 选项。

$ cat /etc/amtool/config.yml
alertmanager.url: "http://localhost:9093"
output: "extended"

删除警报

已经创建的警报无法直接删除。你只能选择将其标记为“已结束”，或者将其静音，以确保不会再次触发警报。关于如何设置静音，请查看以下部分，现在我们来看看如何“删除”警报。

$ amtool alert add TooMuchOpenFiles Stage=staging Role=web --end='2018-12-23T16:02:00Z'
$ amtool alert
Labels                                                   Annotations  Starts At                Ends At                  Generator URL
Role="web" Stage="staging" alertname="TooMuchOpenFiles"               2018-12-23 16:01:00 UTC  2018-12-23 16:02:00 UTC

将之前添加的 TooMuchOpenFiles 警报进行覆盖。在此过程中，将警报的结束时间以 RFC 3339 格式通过 –end 选项传递。

在这种情况下，–end选项需要输入一个比现在时间更晚的时间。由于上述写法省略了–start选项，所以默认情况下会将当前时间作为开始时间，并且要求结束时间必须在开始时间之后。如果出现amtool: error: start time must be before end time (code: 400)错误，很可能是因为这个原因。（我遇到了这个问题）
另外，可以将–start设置为过去的时间，同时将–end设置为过去的时间。

警报的静音：警报静音

如果你想暂时让吵闹的警报停下来，amtool silence命令就派上用场了。
嗯，本来应该不要制造需要被停下来的警报的情况，这是个关于那个的讨论，但现实情况并非如此，这种场景还是会出现的。

哎呀，他没出来吗？那真是太好了。请回来这里吧。

$ amtool silence add alertname=TooMuchOpenFiles -c 'sugitak: うるさーい！'
bef9a58f-7cfc-49d9-b01c-2aea98080eb9

对于要理解的人来说，可以通过使用 amtool silence add 命令来添加静音。另外，可以使用 -c 选项来添加该静音的注释。在我的版本（alertmanager 0.16.0-alpha.0）中，注释是必需的。

$ amtool silence
ID                                    Matchers                    Starts At                Ends At                  Updated At               Created By  Comment
bef9a58f-7cfc-49d9-b01c-2aea98080eb9  alertname=TooMuchOpenFiles  2018-12-23 15:33:27 UTC  2018-12-23 16:33:27 UTC  2018-12-23 15:33:27 UTC  sugitak     sugitak: うるさーい！

保持静默，通过 amtool silence expire 来删除。

$ amtool silence expire bef9a58f-7cfc-49d9-b01c-2aea98080eb9

如果要全部删除，一个简单的Shell命令就足够了。

$ amtool silence | awk '/^[^I]/ {print $1;}' | xargs amtool silence expire

这样的感觉。真方便！

总结

因此，我已经向您介绍了使用Alertmanager非常方便的amtool的使用方法。嗯，虽然所有内容都写在github.com/prometheus/alertmanager上，但要找到它们还是很麻烦的，所以我决定以这篇文章的形式来进行学习。

由于今年的 Qiita 的 Prometheus Advent Calendar 让人感到非常冷清，让我感到惊讶。但这并不是因为没有使用 Prometheus，相反，它已经成为常规使用而无需太多花费就能使用的工具，所以可能没有太多的写作内容。

Kubernetes 和 Gitlab 已经支持 Prometheus，并在各种场景中得到应用，但今年甚至连 Nomad 也发布了以 Prometheus 格式输出的信息，可以看出势头不减。我感受到可观测性正逐渐成为开发者的一部分。

各位朋友们，祝大家度过一个快乐的普罗米修斯人生以及欢乐的年末年始。