AlertManager監視アラームアーティファクト（9）

Prometheus + AlertManagerは監視とアラームを実現します

1.AlertManagerの概要

Prometheus自体にはアラーム機能がないため、監視インジケータアラームを実現するには、サードパーティのアラームプログラムと組み合わせる必要があります。

AlertManagerは優れたアラートプログラムです。まず、prometheusがアラートルールを設定します。アラートルールがトリガーされると、アラート情報がaltermanagerにプッシュされます。AlertManagerがアラートを受信すると、設定されたルートに基づいてさまざまなアラームに送信し、さまざまなアラートレベル。受信（受信者）、AlertManagerは、電子メール、企業のWeChat、およびその他のアラームを実装できます。

2.AlertManagerと構成ファイルのデプロイメントの概要

2.1.AlertManagerをデプロイします

[root@prometheus-server ~]# tar xf AlertManager-0.21.0.linux-amd64.tar.gz 
[root@prometheus-server ~]# mv AlertManager-0.21.0.linux-amd64 /data/AlertManager

2.2。構成ファイルの概要

グローバル：

resolve_timeout //解決タイムアウト時間。つまり、アラームリカバリはすぐには送信されませんが、リカバリアラームは、アラームが時間範囲内にトリガーされない場合にのみ送信できます。デフォルトは5分です。

smtp_from //受信者のメールアドレス

smtp_smarthost //メールボックスプロバイダーのSMTPアドレス

smtp_auth_username //受信者のメールアカウント

smtp_auth_password //メール認証コード

smtp_require_tls // tlsプロトコルが必要かどうかにかかわらず、デフォルトはtrueです

wechart_api_url // WeChatAPIアドレス

wbchart_api_secret //パスワード

wechat_api_corp_id //ロボットアプリケーションのID

ルート：

group_by //グループ化の基礎として使用されるラベル

group_wait //グループの待機時間。アラームは、アラームを受信した直後には送信されませんが、一定期間待機して他のアラームがあるかどうかを確認し、一緒に送信します。

group_interval //アラーム間隔

repeat_interval //アラーム間隔を繰り返します。これにより、アラームの送信頻度を減らすことができます。

レシーバー//レシーバーは誰ですか

レシーバー：

name //ルート内の受信者に対応する受信者の名前

email_configs

-to //受信者のメールアドレス

2.3.AlertManagerメールボックスアラームを構成する

1.修改主配置文件
[root@prometheus-server ~]# cd /data/AlertManager/
[root@prometheus-server /data/AlertManager]# vim /data/AlertManager/AlertManager.yml 
global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.qq.com:465'        
  smtp_from: '[email protected]'       
  smtp_auth_username: '[email protected]'  
  smtp_auth_password: 'yzjqxhsranbpdijd'     
  smtp_require_tls: false
  
route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 10m
  receiver: 'mail'
receivers:
- name: 'mail'
  email_configs:
  - to: '[email protected]'
  
2.检测语法
[root@prometheus-server /data/AlertManager]# ./amtool check-config AlertManager.yml 
Checking 'AlertManager.yml'  SUCCESS
Found:
 - global config
 - route
 - 0 inhibit rules
 - 1 receivers
 - 0 templates

3.启动AlertManager
[root@prometheus-server /data/AlertManager]# nohup ./AlertManager --config.file="/data/AlertManager/AlertManager.yml" &

4.查看端口
[root@prometheus-server /data/AlertManager]# netstat -lnpt | grep alert
tcp6       0      0 :::9093                 :::*                    LISTEN      31401/./alertmanage 
tcp6       0      0 :::9094                 :::*                    LISTEN      31401/./alertmanage 
  

2.4.AlertManagerを統合するようにprometheusを構成します

1.修改配置文件
[root@prometheus-server ~]# vim /data/prometheus/prometheus.yml 
alerting:
  AlertManagers:											
  - static_configs:
    - targets:
      - 192.168.81.210:9093											#AlertManager地址

rule_files:											#告警规则路径
  - "rules/*.yml"

2.创建rules告警规则目录
[root@prometheus-server ~]# mkdir /data/prometheus/rules

3.加载配置
[root@prometheus-server ~]# curl -XPOST 192.168.81.210:9090/-/reload

構成が更新され、AlertManagerをアラームに使用できるようになりました

3.警告ルール

3.1。アラームルールの構文

groups:									//定义一个告警规则组
- name: general.rules			//组名，可以将同一类型的报警放到一个分组中
  rules:						//定义告警规则，可以有多个
  - alert: 主机宕机					//告警名称，也就是告警信息的标题，一个alert代表一个告警规则
    expr: up == 0				//表达式，根据表达式的值进行匹配
    for: 1m						//报警收到后多长时间后发送报警信息
    labels:										//定义标签
      serverity: error				//告警级别，有warning、error等
    annotations:					//定义告警内容
      summary: "主机 {
    
    { $labels.instance }} 停止工作"				//消息内容，$labels.instance就是监控项中的标签变量
      description: "{
    
    { $labels.instance }} job {
    
    { $labels.job }} 已经宕机5分钟以上!"			//详细描述

3.2。アラームルールのステータス

アラームルールには3つのタイプがあります

• 非アクティブ：アラームなし、すべてが正常

  • 緑

• 保留中：しきい値はトリガーされましたが、アラーム期間が満たされていません。つまり、アラームルールに記述されている期間は、指定された時間内にトリガーされたときにAlertManagerに送信されず、AlertManagerにすぐに送信されます。期間が経過した後

  • 黄

• 発火：しきい値がトリガーされ、アラーム期間が満たされ、アラームが受信機に送信されます

  • 赤

4.ホストのダウンタイムを検出するためのアラームを作成します

各監視インスタンスにはアップ監視項目があります。この監視項目の値が0の場合、ホストはダウンしており、1は正常な生存を示します。

4.1。ホストダウンアラームルールを書き留めます

1.编写规则
[root@prometheus-server /data/prometheus]# vim rules/hostdown.yml
groups:
- name: general.rules
  rules:
  - alert: 主机宕机
    expr: up == 0
    for: 1m
    labels:
      serverity: error
    annotations:
      summary: "主机 {
   
   { $labels.instance }} 停止工作"
      description: "{
   
   { $labels.instance }} job {
   
   { $labels.job }} 已经宕机5分钟以上!"

2.检查语法
[root@prometheus-server /data/prometheus]# promtool check config /data/prometheus/prometheus.yml 
Checking /data/prometheus/prometheus.yml
  SUCCESS: 1 rule files found

Checking /data/prometheus/rules/hostdown.yml
  SUCCESS: 1 rules found

3.加载配置
[root@prometheus-server /data/prometheus]# curl -XPOST 192.168.81.210:9090/-/reload

ページのステータスルールの下に作成したアラームルールを確認できます

アラートでは、アラームルールがトリガーされているかどうかも確認できます。トリガーされていない場合は、緑色で表示されます。

4.2。トリガーアラームルール

192.168.81.220のmysql_exporterを停止して、アラームがトリガーされるかどうかを確認します

[root@192_168_81_220 ~]# ps aux | grep mysql
[root@192_168_81_220 ~]# kill -9 40268

4.3.AlertManagerがアラーム情報を受信したかどうかを確認します

ターゲットページが表示されています

赤い発火は、アラームが送信されたことを意味します

AlertManagerページは、ホストからプッシュダウンされたアラーム情報も受信しました

4.4。電子メールアラームコンテンツを受信したかどうかを確認します

受け取った、これまでのところ私たちのプロセスは実行されています

4.5。同様のアラームルールのトリガー

同様のアラームは次のとおりです。Prometheusのアラームルールはすべての監視インスタンスに有効です。つまり、同じタイプのアラームがトリガーされると、一緒に表示され、電子メールが送信されます。

Dockerサービスを停止した後、この時点で2つの同様のアラームが生成されます

これらは2つのサービスですが、1つのタイプのアラームルールに属しているため、まとめられます。

電子メールも一緒に送信されます。これは、構成ファイルで構成されたgroup_waitのパラメーターでもあります。同じグループで複数のアラームルールが同時にトリガーされると、それらは同時に1つの電子メールとして送信されます。