海に入るクジラのように、森に入る鳥のように
1.Prometheus電子メールアラームPrometheusのアーキテクチャは2つの部分に分かれています。アラームルールとアラームはPrometheusServerで定義されています。Alertmanagerコンポーネントは、Prometheusによって生成されたこれらのアラームを処理するために使用されます。Alertmanagerは、Prometheusシステムのアラートの統合処理センターです。Alertmanagerは、さまざまな組み込みのサードパーティアラート通知方法を提供し、Webhook通知のサポートも提供します。Webhookを介して、ユーザーはアラートに対してよりパーソナライズされた拡張機能を完了することができます。
Prometheusアラームの概要
アラーム機能は、Prometheusアーキテクチャの2つの独立した部分に分かれています。以下に示すように、PrometheusでAlertRuleを定義することにより、Prometheusは定期的にアラートルールを計算し、アラートトリガー条件が満たされると、アラート情報をAlertmanagerに送信します。
Prometheusのアラートルールは、主に次の部分で構成されています。
1.アラーム名：ユーザーはアラームルールに名前を付ける必要があります。もちろん、名前を付けるには、アラームの主な内容を直接表現できる必要があります
。2。アラームルール：アラームルールは実際には主にPromQLによって定義され、実際の意味は式としてです。 （PromQL）アラームがトリガーされるまでのクエリ結果の持続時間（中）
Prometheusでは、関連するアラームのグループをグループ（アラームグループ）で一律に定義することもできます。もちろん、これらの定義はYAMLファイルを通じて一律に管理されます。
Alertmanagerは、独立したコンポーネントとして、Prometheus Server（または他のクライアントプログラム）からのアラーム情報の受信と処理を担当します。Alertmanagerは、これらのアラームをさらに処理できます。たとえば、重複するアラームを多数受信した場合、重複するアラームを排除すると同時に、アラームをグループ化して正しい通知パーティにルーティングできます。Prometheusには、メール、Slackなどが組み込まれています。通知方法がサポートされており、よりカスタマイズされたシナリオをサポートするためにWebhookとの統合もサポートされています。たとえば、現在AlertmanagerはDingdingをサポートしていないため、ユーザーはWebhookを介してDingdingロボットと統合し、Dingdingを介してアラート情報を受信できます。同時に、AlertManagerは、アラート通知の動作を最適化するためのサイレントおよびアラーム抑制メカニズムも提供します。
Alertmanagerの機能基本的なアラート通知機能に加えて、Alertmanagerは主に、グループ化、抑制、無音などのアラート機能も提供します。
グループ化
**グループ化メカニズムは、詳細なアラーム情報を1つの通知に組み合わせることができます。**システムのダウンタイムなどにより、同時に多数のアラームがトリガーされる場合があります。この場合、グループ化メカニズムにより、これらのトリガーされたアラームを1つのアラーム通知に結合して、一度に多数のアラーム通知を受信しないようにすることができます。問題をすばやく特定することはできません。
たとえば、クラスター内に数百の実行中のサービスインスタンスがあり、インスタンスごとにアラームルールが設定されている場合です。この時点でネットワーク障害が発生すると、多数のサービスインスタンスがデータベースに接続できなくなる可能性があり、その結果、何百ものアラームがAlertmanagerに送信されます。
ユーザーとして、1つの通知で影響を受けるサービスインスタンスのみを確認したい場合があります。このとき、アラームはサービスクラスタまたはアラーム名に従ってグループ化でき、これらのアラームをグループ化して通知を形成できます。
アラームのグループ化、アラーム時間、およびアラームの受信方法は、Alertmanagerの構成ファイルを介して構成できます。
抑制
抑制とは、特定のアラームが送信された後、このアラームによって引き起こされた他のアラームの送信を繰り返し停止できるメカニズムを指します。
たとえば、クラスターにアクセスできない場合にアラームがトリガーされ、Alertmanagerを構成することで、クラスターに関連する他のすべてのアラームを無視できます。これにより、実際の問題に関係のない多数のアラーム通知を受信することを回避できます。
抑制メカニズムは、Alertmanagerの構成ファイルでも設定されます。
Silent
Silenceは、タグに基づいてアラームをすばやく消音するためのシンプルなメカニズムを提供します。受信したアラームがサイレント構成と一致する場合、Alertmanagerはアラーム通知を送信しません。
サイレント設定は、AlertmanagerのWerbページで設定する必要があります。
2. PrometheusアラームルールのカスタマイズPrometheusのアラームルール
を使用すると、PromQL式に基づいてアラームトリガー条件を定義できます。Prometheusバックエンドは、これらのトリガールールに対して定期的な計算を実行し、トリガー条件が満たされると、アラーム通知がトリガーされます。デフォルトでは、ユーザーはPrometheusWebインターフェイスを介してこれらのアラームルールとアラームトリガーステータスを表示できます。PromthuesがAlertmanagerに関連付けられた後、アラートをAlertmanagerなどの外部サービスに送信でき、これらのアラートはAlertmanagerを介してさらに処理できます。
アラームルール
の定義一般的なアラームルールは次のとおりです。
groups:
- name: example
rules:
- alert: HighErrorRate
expr: job:request_latency_seconds:mean5m{
job="myjob"} > 0.5
for: 10m
labels:
severity: page
annotations:
summary: High request latency
description: description info
アラームルールファイルでは、グループの下に関連するルール設定のグループを定義できます。各グループで、複数のアラームルール（ルール）を定義できます。アラームルールは、主に次の部分で構成されています。
alert：アラートルールの名前。expr：PromQL式のアラームトリガー条件に基づいて、条件を満たす時系列があるかどうかを計算するために使用されます。
for：評価待機時間、オプションのパラメーター。これは、トリガー条件が一定期間続く場合にのみアラームが送信されることを示すために使用されます。待機期間中に新しく生成されたアラームの状態は保留中です。
ラベル：カスタムラベル。ユーザーは、アラームに添付する追加のラベルのセットを指定できます。
注釈：アラートの詳細情報を説明するために使用されるテキストなど、一連の追加情報を指定するために使用されます。注釈の内容は、アラートが生成されるときにパラメーターとしてAlertmanagerに送信されます。
Prometheusで定義されたアラームルールを有効にするには、Prometheusグローバル構成ファイルのrule_filesを介して一連のアラームルールファイルのアクセスパスを指定する必要があります。Prometheusが起動すると、これらのパスの下のルールファイルで定義されたコンテンツが自動的にスキャンされ、これらのルールに従います。外部に通知を送信するかどうかを計算します。
rule_files:
[ - <filepath_glob> ... ]
デフォルトでは、Prometheusはこれらのアラームルールを毎分計算します。ユーザーが独自のアラーム計算期間を定義する場合は、evaluation_intervalを使用してデフォルトの計算期間を上書きできます。
global:
[ evaluation_interval: <duration> | default = 1m ]
テンプレート化
アラームルールファイルの注釈で、summaryを使用してアラームの要約情報を記述し、descriptionを使用してアラームの詳細情報を記述します。同時に、AlertmanagerのUIには、これら2つのタグ値に基づいたアラート情報も表示されます。アラーム情報を読みやすくするために、Prometheusはテンプレート化されたラベルとラベル値の注釈をサポートしています。
現在のアラームインスタンスで指定されたラベルの値には、$ labels。変数を介してアクセスできます。$ valueは、現在のPromQL式によって計算されたサンプル値を取得できます。
# To insert a firing element's label values:
{
{
$labels.<labelname> }}
# To insert the numeric expression value of the firing element:
{
{
$value }}
たとえば、要約と説明の内容の読みやすさは、テンプレートを使用して最適化できます。
groups:
- name: example
rules:
# Alert for any instance that is unreachable for >5 minutes.
- alert: InstanceDown
expr: up == 0
for: 5m
labels:
severity: page
annotations:
summary: "Instance {
{ $labels.instance }} down"
description: "{
{ $labels.instance }} of job {
{ $labels.job }} has been down for more than 5 minutes."
# Alert for any instance that has a median request latency >1s.
- alert: APIHighRequestLatency
expr: api_http_request_latencies_second{
quantile="0.5"} > 1
for: 10m
annotations:
summary: "High request latency on {
{ $labels.instance }}"
description: "{
{ $labels.instance }} has a median request latency above 1s (current value: {
{ $value }}s)"
アラームステータスの
表示以下に示すように、ユーザーは、Prometheus WEBインターフェイスの[アラート]メニューから、現在のPrometheusおよび現在のアクティブ状態のすべてのアラームルールを表示できます。
同時に、保留中または発火中のアラームの場合、Prometheusはそれらを時系列ALERTS {}に保存します。
次の式を使用して、アラームインスタンスをクエリできます。
ALERTS{
alertname="<alert name>", alertstate="pending|firing", <additional alert labels>}
サンプル値1は、現在のアラームがアクティブ（保留中または発生中）であることを示します。アラームがアクティブ状態から非アクティブ状態に移行するとき、サンプル値は0です。
例：ホスト監視アラームを定義する
Prometheus構成ファイルprometheus.ymlを変更し、次の構成を追加します。
rule_files:
- /usr/local/prometheus/*.rules
次の内容のアラートファイルalert.rulesをディレクトリ/ usr / local / prometheus /に作成します。
groups:
- name: hostStatsAlert
rules:
- alert: hostCpuUsageAlert
expr: sum(avg without (cpu)(irate(node_cpu_seconds_total{
mode!='idle'}[1m]))) by (instance) > 0.5
for: 1m
labels:
severity: page
annotations:
summary: "Instance {
{ $labels.instance }} CPU usgae high"
description: "{
{ $labels.instance }} CPU usage above 50% (current value: {
{ $value }})"
- alert: hostMemUsageAlert
expr: (node_memory_MemTotal - node_memory_MemAvailable)/node_memory_MemTotal > 0.7
for: 1m
labels:
severity: page
annotations:
summary: "Instance {
{ $labels.instance }} MEM usgae high"
description: "{
{ $labels.instance }} MEM usage above 50% (current value: {
{ $value }})"
Prometheusを再起動した後、Prometheus UI http://127.0.0.1:9090/rulesにアクセスして、現在ロードされているルールファイルを表示します。ここではしきい値を下げましたが、構成ファイルの変更を忘れてもかまいません。
[アラート]タブhttp://127.0.0.1:9090/alertsに切り替えて、現在のアラートのアクティブなステータスを表示します。
この時点で、システムのCPU使用率を手動で増やし、Prometheusアラームプロセスを確認して、ホストで次のコマンドを実行できます。
cat /dev/zero>/dev/null
コマンドを実行した後、次の図に示すように、CPU使用率を確認します
。Prometheusがトリガー条件が初めて満たされたことを検出した後、hostCpuUsageAlertはアラームがアクティブであることを示します。アラームルールで待機時間が1mに設定されているため、現在のアラーム状態はPENDINGです。1分経過してもアラーム状態が続くと、実際にアラームが発生し、次の図のようにアラーム状態がFIRINGになります。
3. AlertManagerのデプロイAlertmanager
とPrometheusServerはGolangに実装されており、サードパーティの依存関係はありません。一般的に、Alertmanagerは、バイナリパッケージ、コンテナ、およびソースのインストールの方法で展開できます。
AlertManagerで一般的に使用されるコマンドパラメータ：
-h，--help显示上下文相关的帮助（也可以尝试--help-long和--help-man）。
--config.file =“ alertmanager.yml”
Alertmanager配置文件名。
--storage.path =“ data /”数据存储的基本路径。
--data.retention = 120h保留数据的时间。
--alerts.gc-interval = 30m警报GC之间的间隔。
--web.external-url = WEB.EXTERNAL-URL
从外部可访问Alertmanager的URL（例如，如果Alertmanager是通过反向提供的
代理）。用于生成返回到Alertmanager本身的相对和绝对链接。如果该网址包含路径部分，
它将用于为Alertmanager服务的所有HTTP端点添加前缀。如果省略，则相关的URL组件将为
自动派生。
--web.route-prefix = WEB.ROUTE-PREFIX
Web端点内部路由的前缀。默认为--web.external-url的路径。
--web.listen-address =“：9093”
侦听Web界面和API的地址。
--web.get-concurrency = 0并发处理的最大GET请求数。如果为负数或零，则限制为GOMAXPROC或8，以两者中的最大值为准
更大。
--web.timeout = 0 HTTP请求超时。如果为负或零，则不设置超时。
--cluster.listen-address =“ 0.0.0.0:9094”
集群的监听地址。设置为空字符串以禁用高可用性模式。
--cluster.advertise-address = CLUSTER.ADVERTISE-ADDRESS
在群集中进行广播的显式地址。
--cluster.peer = CLUSTER.PEER ...
最初的同伴（可以重复）。
--cluster.peer-timeout = 15秒
等待对等方之间发送通知的时间。
--cluster.gossip-interval = 200ms
发送八卦消息之间的间隔。通过降低此值（更频繁），可以传播八卦消息
以增加带宽为代价更快地跨集群运行。
--cluster.pushpull-interval = 1m0s
八卦状态同步的间隔。将此间隔设置得越低（越频繁），将加快整个过程的收敛速度
较大的群集，但以增加带宽使用为代价。
--cluster.tcp-timeout = 10s与远程节点建立流连接以进行完整状态同步以及流读写的超时
操作。
--cluster.probe-timeout = 500ms
在假定它不正常之前，等待被探测节点发出的确认超时。应将其设置为99％
网络上的RTT（往返时间）。
--cluster.probe-interval = 1s
随机节点探测之间的间隔。将此值设置得较低（更频繁）将导致群集检测到故障
节点更快地增加带宽使用率。
--cluster.settle-timeout = 1m0s
在评估通知之前，等待集群连接建立的最长时间。
--cluster.reconnect-interval = 10秒
尝试重新连接到丢失的对等方之间的间隔。
--cluster.reconnect-timeout = 6h0m0s
尝试重新连接到丢失的对等设备的时间长度。
--log.level = info仅记录具有给定严重性或更高严重性的消息。下列之一：[调试，信息，警告，错误]
--log.format = logfmt日志消息的输出格式。下列之一：[logfmt，json]
--version显示应用程序版本。
tar xf alertmanager-0.21.0.linux-amd64.tar.gz -C /usr/local/ && cd /usr/local/
ln -s /usr/local/alertmanager-0.21.0.linux-amd64/ alertmanager
mkdir -p /usr/local/alertmanager/data/
vim /etc/systemd/system/alertmanager.service
添加如下内容：
[Unit]
Description=alertmanager
After=network.target
[Service]
Type=simple
User=prometheus
ExecStart=/usr/local/alertmanager-0.21.0.linux-amd64/alertmanager --config.file=/usr/local/alertmanager/alert-test.yml --storage.path=/usr/local/alertmanager/data/
Restart=on-failure
[Install]
WantedBy=multi-user.target
–config.fileは、alertmanager構成ファイルのパスを指定するために使用されます
–storage.pathは、データストレージパスを指定するために使用されます。
alertmanager構成ファイルの作成
解凍後、Alertmanagerには、次の内容のデフォルトのalertmanager.yml構成ファイルが含まれます。
cd /usr/local/alertmanager
cp alertmanager.yml alert-test.yml
vim alert-test.yml
内容如下：
global:
resolve_timeout: 5m
route:
group_by: ['alertname']
group_wait: 10s
group_interval: 10s
repeat_interval: 1h
receiver: 'web.hook'
receivers:
- name: 'web.hook'
webhook_configs:
- url: 'http://127.0.0.1:5001/'
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'dev', 'instance']
Alertmanagerの構成は、主にルートとレシーバーの2つの部分で構成されます。すべてのアラーム情報は、構成の最上位ルートからルーティングツリーに入り、アラーム情報は、ルーティングルールに従って対応する受信者に送信されます。
Alertmanagerで一連の受信者を定義できます。たとえば、複数の受信者を役割（システムの運用と保守、データベース管理者など）に応じて分割できます。受信者は、メール、Slack、およびその他の方法でアラーム情報を受信できます。
デフォルトのレシーバーdefault-receiverは、現在の構成ファイルで定義されています。ここには受信方法がないため、現在、プレースホルダーと同等です。
トップレベルのルートは、構成ファイルのルートを使用して定義されます。ルートは、ラベルマッチングルールに基づくツリー構造です。すべてのアラーム情報は、最上位ルートから始まり、ラベル照合ルールに従ってさまざまなサブルートに入り、サブルートによって設定された受信者に従ってアラームを送信します。現在、構成ファイルには1つの最上位ルートのみが設定されており、定義されているレシーバーはdefault-receiverです。したがって、すべてのアラームはデフォルトのレシーバーに送信されます。
Alermanagerはデータをローカルに保存します。デフォルトのストレージパスはdata /です。したがって、Alertmanagerを起動する前に、対応するディレクトリを作成する必要があります
Alertmanagerを起動します
chown -R prometheus:prometheus /usr/local/alertmanager-0.21.0.linux-amd64/
systemctl status alertmanager.service
Alertmanagerの起動後、ポート9093、http
：
//192.168.0.10 ：9093のデフォルトのリスニングポート：9093クラスターリスニングポート9094を介してアクセスできます。Alertmanagerが受信したアラートコンテンツは、[アラート]メニューで表示できます。[サイレンス]メニューでは、UIからサイレントルールを作成できます。
PrometheusとAlertmanagerの関連付け
は、Prometheusアーキテクチャでは2つの別々の部分に分かれています。Prometheusはアラームの生成を担当し、Alertmanagerはアラームが生成された後のフォローアップ処理を担当します。したがって、Alertmanagerの展開が完了したら、PrometheusでAlertmanager関連の情報を設定する必要があります。
Prometheus構成ファイルprometheus.ymlを編集し、次のコンテンツを追加します。
alerting:
alertmanagers:
- static_configs:
- targets: ['localhost:9093']
Prometheusサービスを再起動します。成功したら、http：//192.168.0.10：9090 / configからアラート構成が有効になっているかどうかを確認できます。
この時点で、システムのCPU使用率を手動で増やしてみてください。
cat /dev/zero>/dev/null
Prometheusアラームがトリガーされるのを待ち
ます。AlertmanagerUIを確認すると、Alertmanagerが受信したアラーム情報を確認できます。
