海に入るクジラのように、森に入る鳥のように
Alertmanagerでは、アラームの処理方法はルーティング（ルート）によって定義されます。ルーティングは、ラベルマッチングに基づくツリーマッチング構造です。アラームを受信したタグに応じて、対応する処理方法を一致させてください。
Alertmanagerは、主にPrometheusによって生成されたアラートの統合処理を担当します。したがって、Alertmanagerの構成には、通常、次の主要部分が含まれます。
グローバル構成（グローバル）：グローバルSMTP構成、Slack構成など、いくつかのグローバルパブリックパラメーター
を定義するために使用されます。テンプレート：HTMLテンプレート、電子メールテンプレートなど、アラート通知用のテンプレートを定義するために使用されます。
アラートルーティング（ルート）：ラベルの照合に従って現在のアラームを処理する方法を決定します。
レシーバー：レシーバーは抽象的な概念であり、メールボックス、WeChat、Slack、Webhookなどです。受信者は通常、アラームルーティングに協力します。使用;
禁止ルール（inhibit_rules）：禁止ルールを適切に設定すると、スパムアラームの生成を減らすことができます
完全な構成形式は次のとおりです。
global:
[ resolve_timeout: <duration> | default = 5m ]
[ smtp_from: <tmpl_string> ]
[ smtp_smarthost: <string> ]
[ smtp_hello: <string> | default = "localhost" ]
[ smtp_auth_username: <string> ]
[ smtp_auth_password: <secret> ]
[ smtp_auth_identity: <string> ]
[ smtp_auth_secret: <secret> ]
[ smtp_require_tls: <bool> | default = true ]
[ slack_api_url: <secret> ]
[ victorops_api_key: <secret> ]
[ victorops_api_url: <string> | default = "https://alert.victorops.com/integrations/generic/20131114/alert/" ]
[ pagerduty_url: <string> | default = "https://events.pagerduty.com/v2/enqueue" ]
[ opsgenie_api_key: <secret> ]
[ opsgenie_api_url: <string> | default = "https://api.opsgenie.com/" ]
[ hipchat_api_url: <string> | default = "https://api.hipchat.com/" ]
[ hipchat_auth_token: <secret> ]
[ wechat_api_url: <string> | default = "https://qyapi.weixin.qq.com/cgi-bin/" ]
[ wechat_api_secret: <secret> ]
[ wechat_api_corp_id: <string> ]
[ http_config: <http_config> ]
templates:
[ - <filepath> ... ]
route: <route>
receivers:
- <receiver> ...
inhibit_rules:
[ - <inhibit_rule> ... ]
グローバル構成のresolve_timeoutに注意してください。このパラメーターは、アラートステータスを解決済み（解決済み）としてマークする前に、Alertmanagerがアラートを受信しなかった期間を定義します。このパラメータの定義は、アラーム回復通知の受信時間に影響を与える可能性があります。ユーザーは実際のシナリオに従って定義できます。デフォルト値は5分です。
タグベースのアラート処理ルーティング
Alertmanagerの構成では、タグマッチングルールに基づくアラートルーティングツリーが定義され、Alertmanagerがアラートを受信した後にどのように処理する必要があるかを決定します。
route: <route>
その中で、routeは主に、アラームのルーティング一致ルールと、一致したアラームを送信する必要のあるレシーバーAlertmanagerを定義します。最も単純なルート定義は次のとおりです。
route:
group_by: ['alertname']
receiver: 'web.hook'
receivers:
- name: 'web.hook'
webhook_configs:
- url: 'http://127.0.0.1:5001/'
上記のように：Alertmanager構成ファイルでは、ルートを1つだけ定義します。つまり、Prometheusによって生成されたすべてのアラートは、Alertmanagerに送信された後、web.hookという名前のレシーバーを介して受信されます。ここで、web.hookはwebhookアドレスとして定義されています。もちろん、実際のシナリオでは、アラーム処理はそれほど単純な問題ではありません。アラームのレベルが異なれば、処理方法もまったく異なる可能性があります。したがって、ルートでは、さらに多くのサブルートを定義することもできます。これらのルートは通過します。ラベルマッチングアラームの処理方法、ルートの完全な定義は次のとおりです。
[ receiver: <string> ]
[ group_by: '[' <labelname>, ... ']' ]
[ continue: <boolean> | default = false ]
match:
[ <labelname>: <labelvalue>, ... ]
match_re:
[ <labelname>: <regex>, ... ]
[ group_wait: <duration> | default = 30s ]
[ group_interval: <duration> | default = 5m ]
[ repeat_interval: <duration> | default = 4h ]
routes:
[ - <route> ... ]
ルートマッチング
各アラームは、構成ファイルの最上位ルートからルーティングツリーに入ります。最上位ルートはすべてのアラームと一致する必要があり（つまり、一致する設定のmatchとmatch_reはありません）、各ルートは独自の受け入れを定義できることに注意してください。人とマッチングルール。デフォルトでは、アラームが最上位ルートに入った後、最も一致するルートが見つかるまですべての子ノードをトラバースし、ルートで定義されたレシーバーにアラームが送信されます。ただし、ルートでcontinueの値がfalseに設定されている場合、最初の子ノードが一致した直後にアラームが停止します。継続が真の場合、アラームは後続の子ノードと一致し続けます。現在のアラームがどの子ノードとも一致しない場合、アラームは現在のルーティングノードのレシーバー構成に基づいて処理されます。
アラームの一致を選択する方法は2つあります。1つ
目は文字列の検証に基づいており、一致ルールを設定して、ラベルlabelnameが現在のアラームに存在し、その値がlabelvalueと等しいかどうかを判断します。
2番目の方法は通常の式に基づいており、match_reを設定することにより、現在のアラームタグの値が通常の式の内容を満たしているかどうかを確認します。
アラームが正常に送信された場合、アラーム通知を送信するまでの待機時間を設定する場合は、repeat_intervalパラメーターを使用して設定できます。
アラームのグループ化
Alertmanagerは、アラーム通知をグループ化し、複数のアラームを1つの通知に組み合わせることができます。ここでは、group_byを使用してグループ化ルールを定義できます。アラームに含まれるタグに基づいて、group_byで定義されたタグ名が満たされると、これらのアラームは1つの通知にまとめられ、受信者に送信されます。
より関連性の高い情報を一度に収集して送信するために、group_waitパラメーターを使用して待機時間を設定できる場合があります。現在のグループが待機時間内に新しいアラームを受信すると、これらのアラームは1つの通知にまとめられ、受信者に送信されます。
group_interval構成は、同じグループ間でアラーム通知を送信するための時間間隔を定義するために使用されます。
たとえば、Prometheusを使用して複数のクラスターと、クラスターにデプロイされたアプリケーションおよびデータベースサービスを監視し、次のアラーム処理ルーティングルールを定義して、クラスターに例外を通知する場合です。
route:
receiver: 'default-receiver'
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
group_by: [cluster, alertname]
routes:
- receiver: 'database-pager'
group_wait: 10s
match_re:
service: mysql|cassandra
- receiver: 'frontend-pager'
group_by: [product, environment]
match:
team: frontend
デフォルトでは、すべてのアラームはクラスター管理者のdefault-receiverに送信されます。したがって、Alertmanager構成ファイルのルートルートでは、アラーム情報はクラスターとアラームの名前に従ってグループ化されます。
アラームがMySQLやCassandraなどのデータベースサービスから発生した場合は、この時点で対応するデータベース管理者（database-pager）にアラームを送信する必要があります。ここで別のサブルートを定義します。アラームにサービスタグが含まれ、サービスがMySQLまたはCassandraの場合、アラーム通知がデータベースページャーに送信されます。ここで定義されたgroup_byなどの属性がないため、これらの属性の構成情報は上位ルーターから継承されます。データベースページャーは、クラスターとアラート名でグループ化されたアラート通知を受信します。
一部のアラームルールのソースは開発チームの定義に由来する場合があり、これらのアラームの作成者は、これらのアラームにタグチームを追加することによってマークされます。Alertmanager構成ファイルのアラートルートの下で、このタイプのアラート通知を処理するための別のサブルートを定義します。アラートにタグチームが含まれ、チームの値がフロントエンドの場合、Alertmanagerはタグの製品と環境に従ってアラートに応答します。グループ化。この時点でアプリケーションが異常である場合、開発者はどの環境のどのアプリケーションに問題があるかを明確に知ることができ、アプリケーション内の問題をすばやく見つけることができます。
電子メールアラームサンプルファイル：
$ cd /usr/local/alertmanager
$ vim alert-test.yml
global:
smtp_smarthost: 'smtp.163.com:25'
smtp_from: '[email protected]'
smtp_auth_username: '[email protected]'
smtp_auth_password: 'xxxxxx' # 邮箱的授权密码
smtp_require_tls: false
templates:
- '/alertmanager/template/*.tmpl'
route:
group_by: ['alertname', 'cluster', 'service']
group_wait: 30s
group_interval: 5m
repeat_interval: 10m
receiver: default-receiver
receivers:
- name: 'default-receiver'
email_configs:
- to: '[email protected]'
html: '{ alert.html }'
headers: {
Subject: "Prometheus[WARN] Test报警邮件" }
ヘルプドキュメント：https：//yunlzheng.gitbook.io/prometheus-book/