どうやって警告した?
5463 ワード
文章の出所:愛可生雲データベースの作者:張沈波
アウトライン
第1節:モニタリング採集、計算とアラーム第2節:アラームパケット、抑制、サイレントアラームパケットアラーム抑制アラームサイレント収束小結第3節:アラーム遅延遅延の3つのパラメータ遅延小結まとめ
Prometheus+Grafanaは、皆さんがよく知っているPMMのように、警報ソリューションの後始末を監視するショーです.先日、羅先生は3306 piの公衆番号に完全な使用チュートリアル「クールなMySQL監視プラットフォームを構築する」を書いたことがあるので、ここでは具体的な構築方法を説明しません.
今日はPrometheusのいくつかの興味深い特性についてお話しします.これらの特性は、Prometheusの警告がどのようにトリガーされたのかをより深く理解するのに役立ちます.本文の概要は以下の通りである.
モニタリング採集、計算とアラームグループ化、抑制と静かなアラーム遅延
第1節採集、計算と警告・Prometheusを監視してscrape_interval(デフォルトは1 m)ルールサイクルで、モニタリングターゲットから情報を収集します.ここでscrape_intervalは、グローバルまたは単一metric定義に基づいてもよい.その後、監視情報はローカルストレージに永続的に格納されます.
Prometheusはevaluation_でinterval(デフォルトは1 m)別の独立したルールサイクルで、アラートルールを定期的に計算します.ここでevaluation_intervalはグローバル値のみです.そしてアラーム状態を更新します.
3つの警告ステータスが含まれています.
・inactive:トリガしきい値なし・pending:トリガしきい値がアラーム持続時間を満たしていない・firing:トリガしきい値がアラーム持続時間を満たしている
例を挙げると、しきい値アラートの構成は次のとおりです.
・収集したmysql_uptime>=30、アラーム状態はinactive・収集したmysql_uptime<30、持続時間が10 s未満、アラーム状態がpending・収集mysql_uptime<30、持続時間が10 sより大きく、アラーム状態がfiring
⚠ 注意:構成中のfor構文は、アラームの持続時間を設定するために使用されます.構成でforを設定しないか0に設定しないとpending状態は直接スキップされます.
では、アラームしきい値の持続時間をどのように計算するかは、上記のscrape_に戻る必要があります.intervalとevaluation_interval、scrape_と仮定intervalは5 sで1回の情報を収集する.evaluation_intervalは10 sです.mysql_uptimeアラームしきい値は10 sの持続時間を満たす必要があります.
上の図に示すように、Prometheusは5 s(scrape_interval)の採集周期で採集状態である.次に、収集された状態に基づいて10 s(evaluation_interval)の計算周期に従って式を計算する.式が真で、アラーム状態がpendingに切り替わります.次の計算サイクルでは、式は真であり、forが10 s継続していることに合致し、アラーム状態はactiveに変更され、PrometheusからAltermangerにアラームを送信します.次の計算サイクルでは、式は真であり、forが10 s継続し、Altermangerに警告し続けます.計算サイクルが偽になるまで、アラートステータスがinactiveに変更され、Altermangerにresolveが送信され、このアラートが解決されたことを示します.
第二節警報グループ、抑制、黙秘
第1節mysqlを成功させましたuptimeのアラームはAltermangerに送信されました.しかし、AltermangerはPrometheusから受信したアラームを簡単に直接送信するわけではありません.直接送信すると警報情報が多すぎて、運営者が警報に水没します.だからAltermangerは警報を合理的に収束させる必要がある.
上記の図のように、青色の枠標柱は、それぞれアラームの受信端と送信端である.このAltermangerのアーキテクチャ図には、複雑で重要な流れが続き、mysql_を待っていることがはっきりと見えます.uptimeアラーム.
次はAltermangerの非常に重要なアラーム収束手段について説明します.
・パケット:group・抑制:inhibitor・サイレント:silencer
1.アラームグループ
アラームグループの役割・同類のアラームの集約による運用・メンテナンスの問題のトラブルシューティング・アラームメールの統合によるアラーム数の削減
例えば、mysqlのインスタンスidに従ってアラートグループをグループ化します.次の図に示すように、アラーム情報は2つのグループに分割されます.
·mysql-A
·mysql-B
インスタンスAパケットの下のアラームは、1つのアラームメールに統合されて送信される.インスタンスBパケットの下のアラームは、1つのアラームメールに統合されて送信される.
グループ化された統合により、運用次元のアラート数を削減し、アラート情報を効率的に集約し、問題の分析を支援できます.
2.アラーム抑制
アラーム抑制の役割
・冗長アラームの排除
例えば、同一のサーバ−Aのアラームは、次の2つのアラームがある場合に抑制ルールが構成される.
·mysql_uptime·server_uptime
最後にserverが1つしか受け取れませんuptimeのアラーム.
A機械が切れたので、Aサーバーのmysqlも切れたに違いない.抑制ルールが構成されている場合、サーバdownによってこのサーバ上の他のアラームを抑制する.これにより、冗長なアラートを排除し、運用維持が最も核心的なアラート情報を最初に把握するのに役立ちます.
3.アラームサイレント
サイレントアラームの役割
予期されるアラートの送信を阻止
例えば、夜間にバッチ時間を走ると、バッチタスクはインスタンスAの圧力を上昇させる.インスタンスAに対するサイレントルールを構成した.
·mysql-A
·mysql-B
最後に、インスタンスBのアラームは1つしか受信されません.
A圧力が高いことは予想され、周期的な警報は運行維持判断に影響を与える.このようなシナリオでは、運転次元は、インスタンスBの問題に焦点を当てる必要がある.
収束小結この節、私たちmysql_uptimeさんはPrometheusから出発された後、Altermangerの内部プロセスに入り、予想通りに警察に通報されなかった.それは先にグループ化され、抑制され、静かにされます.なぜこのようにするのか、私达の运维の学友がとても忙しくて忙しくて、精力はとても限られているためです;mysqlだけuptimeさんは自分が非常に重要であることを証明して、私たちはそれを運維さんと会うように手配しました.
第三節警報遅延
第2節では、パケットの概念について言及し、パケットは必ず遅延をもたらす.合理的な配置が遅延してこそ、警報がタイムリーではない問題を避けることができ、同時に警報爆撃の問題を避けることができる.
まず、アラーム遅延のいくつかの重要なパラメータを見てみましょう.
group_by:パケットパラメータ、第2節で説明したように[mysql-id]パケットgroup_wait:パケット待ち時間、例えば:5 sgroup_interval:パケットがアラームを再送信しようとする間隔、例えば:5 mRepeat_interval:パケット内で同じアラームを送信する間隔、例えば:60 m
遅延パラメータは主にAltermangerのDedup段階に作用する.
1.遅延の3つのパラメータ
たとえば、次のように仮定します.
・遅延パラメータが構成されている:
repeat_interval:60 m・同グループの警報集Aがあり、以下の通りである.
・同グループのアラームセットBがあり、以下の通りである.
シーン1:
1.a 1はアラームシステムに先に到着し、group_wait:5 sの作用の下で、a 1はすぐに告発することはできなくて、a 1は5 sを待って、次の瞬間a 2は5 s内でもトリガーして、a 1、a 2は5 sの後で1つのグループに合併して、1つの警報メッセージを通じて出します;2.a 1,a 2は未解決のままであり、repeat_interval:60 mの役割で、1時間おきにアラームメッセージを送信します.
シーン2:
1.a 1,a 2は未解決が続き、その間に新しい同グループのアラームa 3が現れ、group_interval:5 mの作用の下で、同グループの状態が変化するため、a 1,a 2,a 3は5 minの中で迅速に運維を知らせて、60 min(repeat_interval)の時間を収束されません;2.a 1,a 2,a 3が変化し続けるとrepeat_interval:60 mの作用で、再び1時間おきにアラームメッセージを送信します.
シーン3:
1.a 1,a 2が発生する過程で、b 1のアラームが発生し、b 1パケット規則は集合Aにないため、b 1は集合Bのタイムラインに従う.2.b 1の発生後、b 2,b 1,b 2は、類似の集合Aの遅延規則に従って収束するが、時間線は独立している.
ちえんせつごう
3つの遅延パラメータにより、アラームはパケット待機のマージ送信(group_wait)を実現し、アラームの重複アラーム(repeat_interval)を解決せず、パケットが変化した後に迅速にアラーム(group_interval)を通知する.
まとめ
本文は監視情報の周期的な採集、警報公式の周期的な計算、同類の警報のグループを合併すること、冗長警報の抑制を減らすこと、予想できる警報の静黙を下げること、同時に3つの遅延パラメータを協力することを通じて、Prometheusの1本の警報がどのようにトリガーされたかを説明した.もちろんPrometheusには、実践できる特性がたくさんあります.興味があれば、私たちに連絡してください.私たちは爱しています.
PS:雲樹Umonは、大クラスタ監視警報に対して大量の使いやすさの改造を行った.ワンタッチでグラフィック配置インストール、グラフィック配置Prometheus、恥ずかしいyaml配置に別れを告げ、同時に完璧なアラーム統計分析ビューなどの特性を提供し、皆さんの体験を歓迎します.
MySQLミドルウェア性能テストIMySQL性能診断実践のシステム観測ツールPrometheus 1本のアラームがどのようにトリガーされたのか、ライブラリから半同期でコピーして動作しないBUG分析大規模クラスタのアラームシステム実践安全考慮、binlog_row_imageはできるだけFULLを使用してライブラリの時半同期から動作しないBUG分析MySQLボトルネック分析と最適化VS Codeを使用してMySQLをデバッグすることを提案する
アウトライン
第1節:モニタリング採集、計算とアラーム第2節:アラームパケット、抑制、サイレントアラームパケットアラーム抑制アラームサイレント収束小結第3節:アラーム遅延遅延の3つのパラメータ遅延小結まとめ
Prometheus+Grafanaは、皆さんがよく知っているPMMのように、警報ソリューションの後始末を監視するショーです.先日、羅先生は3306 piの公衆番号に完全な使用チュートリアル「クールなMySQL監視プラットフォームを構築する」を書いたことがあるので、ここでは具体的な構築方法を説明しません.
今日はPrometheusのいくつかの興味深い特性についてお話しします.これらの特性は、Prometheusの警告がどのようにトリガーされたのかをより深く理解するのに役立ちます.本文の概要は以下の通りである.
モニタリング採集、計算とアラームグループ化、抑制と静かなアラーム遅延
第1節採集、計算と警告・Prometheusを監視してscrape_interval(デフォルトは1 m)ルールサイクルで、モニタリングターゲットから情報を収集します.ここでscrape_intervalは、グローバルまたは単一metric定義に基づいてもよい.その後、監視情報はローカルストレージに永続的に格納されます.
Prometheusはevaluation_でinterval(デフォルトは1 m)別の独立したルールサイクルで、アラートルールを定期的に計算します.ここでevaluation_intervalはグローバル値のみです.そしてアラーム状態を更新します.
3つの警告ステータスが含まれています.
・inactive:トリガしきい値なし・pending:トリガしきい値がアラーム持続時間を満たしていない・firing:トリガしきい値がアラーム持続時間を満たしている
例を挙げると、しきい値アラートの構成は次のとおりです.
・収集したmysql_uptime>=30、アラーム状態はinactive・収集したmysql_uptime<30、持続時間が10 s未満、アラーム状態がpending・収集mysql_uptime<30、持続時間が10 sより大きく、アラーム状態がfiring
⚠ 注意:構成中のfor構文は、アラームの持続時間を設定するために使用されます.構成でforを設定しないか0に設定しないとpending状態は直接スキップされます.
では、アラームしきい値の持続時間をどのように計算するかは、上記のscrape_に戻る必要があります.intervalとevaluation_interval、scrape_と仮定intervalは5 sで1回の情報を収集する.evaluation_intervalは10 sです.mysql_uptimeアラームしきい値は10 sの持続時間を満たす必要があります.
上の図に示すように、Prometheusは5 s(scrape_interval)の採集周期で採集状態である.次に、収集された状態に基づいて10 s(evaluation_interval)の計算周期に従って式を計算する.式が真で、アラーム状態がpendingに切り替わります.次の計算サイクルでは、式は真であり、forが10 s継続していることに合致し、アラーム状態はactiveに変更され、PrometheusからAltermangerにアラームを送信します.次の計算サイクルでは、式は真であり、forが10 s継続し、Altermangerに警告し続けます.計算サイクルが偽になるまで、アラートステータスがinactiveに変更され、Altermangerにresolveが送信され、このアラートが解決されたことを示します.
第二節警報グループ、抑制、黙秘
第1節mysqlを成功させましたuptimeのアラームはAltermangerに送信されました.しかし、AltermangerはPrometheusから受信したアラームを簡単に直接送信するわけではありません.直接送信すると警報情報が多すぎて、運営者が警報に水没します.だからAltermangerは警報を合理的に収束させる必要がある.
上記の図のように、青色の枠標柱は、それぞれアラームの受信端と送信端である.このAltermangerのアーキテクチャ図には、複雑で重要な流れが続き、mysql_を待っていることがはっきりと見えます.uptimeアラーム.
次はAltermangerの非常に重要なアラーム収束手段について説明します.
・パケット:group・抑制:inhibitor・サイレント:silencer
1.アラームグループ
アラームグループの役割・同類のアラームの集約による運用・メンテナンスの問題のトラブルシューティング・アラームメールの統合によるアラーム数の削減
例えば、mysqlのインスタンスidに従ってアラートグループをグループ化します.次の図に示すように、アラーム情報は2つのグループに分割されます.
·mysql-A
mysql_cpu_high
·mysql-B
mysql_uptime
mysql_slave_sql_thread_down
mysql_slave_io_thread_down
インスタンスAパケットの下のアラームは、1つのアラームメールに統合されて送信される.インスタンスBパケットの下のアラームは、1つのアラームメールに統合されて送信される.
グループ化された統合により、運用次元のアラート数を削減し、アラート情報を効率的に集約し、問題の分析を支援できます.
2.アラーム抑制
アラーム抑制の役割
・冗長アラームの排除
例えば、同一のサーバ−Aのアラームは、次の2つのアラームがある場合に抑制ルールが構成される.
·mysql_uptime·server_uptime
最後にserverが1つしか受け取れませんuptimeのアラーム.
A機械が切れたので、Aサーバーのmysqlも切れたに違いない.抑制ルールが構成されている場合、サーバdownによってこのサーバ上の他のアラームを抑制する.これにより、冗長なアラートを排除し、運用維持が最も核心的なアラート情報を最初に把握するのに役立ちます.
3.アラームサイレント
サイレントアラームの役割
予期されるアラートの送信を阻止
例えば、夜間にバッチ時間を走ると、バッチタスクはインスタンスAの圧力を上昇させる.インスタンスAに対するサイレントルールを構成した.
·mysql-A
qps_more_than_3000
tps_more_than_2000
thread_running_over_200
·mysql-B
thread_running_over_200
最後に、インスタンスBのアラームは1つしか受信されません.
A圧力が高いことは予想され、周期的な警報は運行維持判断に影響を与える.このようなシナリオでは、運転次元は、インスタンスBの問題に焦点を当てる必要がある.
収束小結この節、私たちmysql_uptimeさんはPrometheusから出発された後、Altermangerの内部プロセスに入り、予想通りに警察に通報されなかった.それは先にグループ化され、抑制され、静かにされます.なぜこのようにするのか、私达の运维の学友がとても忙しくて忙しくて、精力はとても限られているためです;mysqlだけuptimeさんは自分が非常に重要であることを証明して、私たちはそれを運維さんと会うように手配しました.
第三節警報遅延
第2節では、パケットの概念について言及し、パケットは必ず遅延をもたらす.合理的な配置が遅延してこそ、警報がタイムリーではない問題を避けることができ、同時に警報爆撃の問題を避けることができる.
まず、アラーム遅延のいくつかの重要なパラメータを見てみましょう.
group_by:パケットパラメータ、第2節で説明したように[mysql-id]パケットgroup_wait:パケット待ち時間、例えば:5 sgroup_interval:パケットがアラームを再送信しようとする間隔、例えば:5 mRepeat_interval:パケット内で同じアラームを送信する間隔、例えば:60 m
遅延パラメータは主にAltermangerのDedup段階に作用する.
1.遅延の3つのパラメータ
たとえば、次のように仮定します.
・遅延パラメータが構成されている:
group_wait:5s
group_interval:5mrepeat_interval:60 m・同グループの警報集Aがあり、以下の通りである.
a1
a2
a3・同グループのアラームセットBがあり、以下の通りである.
b1
b2
シーン1:
1.a 1はアラームシステムに先に到着し、group_wait:5 sの作用の下で、a 1はすぐに告発することはできなくて、a 1は5 sを待って、次の瞬間a 2は5 s内でもトリガーして、a 1、a 2は5 sの後で1つのグループに合併して、1つの警報メッセージを通じて出します;2.a 1,a 2は未解決のままであり、repeat_interval:60 mの役割で、1時間おきにアラームメッセージを送信します.
シーン2:
1.a 1,a 2は未解決が続き、その間に新しい同グループのアラームa 3が現れ、group_interval:5 mの作用の下で、同グループの状態が変化するため、a 1,a 2,a 3は5 minの中で迅速に運維を知らせて、60 min(repeat_interval)の時間を収束されません;2.a 1,a 2,a 3が変化し続けるとrepeat_interval:60 mの作用で、再び1時間おきにアラームメッセージを送信します.
シーン3:
1.a 1,a 2が発生する過程で、b 1のアラームが発生し、b 1パケット規則は集合Aにないため、b 1は集合Bのタイムラインに従う.2.b 1の発生後、b 2,b 1,b 2は、類似の集合Aの遅延規則に従って収束するが、時間線は独立している.
ちえんせつごう
3つの遅延パラメータにより、アラームはパケット待機のマージ送信(group_wait)を実現し、アラームの重複アラーム(repeat_interval)を解決せず、パケットが変化した後に迅速にアラーム(group_interval)を通知する.
まとめ
本文は監視情報の周期的な採集、警報公式の周期的な計算、同類の警報のグループを合併すること、冗長警報の抑制を減らすこと、予想できる警報の静黙を下げること、同時に3つの遅延パラメータを協力することを通じて、Prometheusの1本の警報がどのようにトリガーされたかを説明した.もちろんPrometheusには、実践できる特性がたくさんあります.興味があれば、私たちに連絡してください.私たちは爱しています.
PS:雲樹Umonは、大クラスタ監視警報に対して大量の使いやすさの改造を行った.ワンタッチでグラフィック配置インストール、グラフィック配置Prometheus、恥ずかしいyaml配置に別れを告げ、同時に完璧なアラーム統計分析ビューなどの特性を提供し、皆さんの体験を歓迎します.
MySQLミドルウェア性能テストIMySQL性能診断実践のシステム観測ツールPrometheus 1本のアラームがどのようにトリガーされたのか、ライブラリから半同期でコピーして動作しないBUG分析大規模クラスタのアラームシステム実践安全考慮、binlog_row_imageはできるだけFULLを使用してライブラリの時半同期から動作しないBUG分析MySQLボトルネック分析と最適化VS Codeを使用してMySQLをデバッグすることを提案する