著者: Prest13 元のソース: https://tidb.net/blog/44b9b8b1
背景
tidb dr-auto 同期クラスターをデュアルセンターにデプロイ: モニタリングの高可用性を実現するために、独立した prometheus+alertmanager+grafana が物理的に分離された 2 つのデータセンターにデプロイされ、どのモニタリングにもアクセスできるようになります。
この展開アーキテクチャでは、2 セットの監視コンポーネントからのデータ収集の一貫性と、監視アラームの繰り返し送信の問題を考慮する必要があります。
実装のアイデア
- 2 セットの Prometheus コンポーネントは、クラスター監視情報を個別に収集して保存します。
<!---->
- 2 セットの Grafana がそれぞれの Prometheus をデータ ソースとして接続します。
<!---->
- AlertManager はクラスターを介して構成され、ゴシップ メカニズムに基づいており、複数のアラート マネージャーが同じアラーム イベントを受信すると、そのうちの 1 つがモニタリング アラーム情報を外部に送信します。
シミュレーションの実装
シミュレーション実施環境
TiDB v7.1.0 LTS
単一クラスター上に 2 セットの監視を導入する
# # Server configs are used to specify the configuration of Prometheus Server.
monitoring_servers:
- host: 30.0.100.40
port: 9091
deploy_dir: "/tidb/tidb-deploy/prometheus-8249"
data_dir: "/data/tidb-data/prometheus-8249"
log_dir: "/data/tidb-deploy/prometheus-8249/log"
- host: 30.0.100.42
port: 9091
deploy_dir: "/tidb/tidb-deploy/prometheus-8249"
data_dir: "/data/tidb-data/prometheus-8249"
log_dir: "/data/tidb-deploy/prometheus-8249/log"
# # Server configs are used to specify the configuration of Grafana Servers.
grafana_servers:
- host: 30.0.100.40
deploy_dir: /data/tidb-deploy/grafana-3000
- host: 30.0.100.42
deploy_dir: /data/tidb-deploy/grafana-3000
# # Server configs are used to specify the configuration of Alertmanager Servers.
alertmanager_servers:
- host: 30.0.100.40
deploy_dir: "/data/tidb-deploy/alertmanager-9093"
data_dir: "/data/tidb-data/alertmanager-9093"
log_dir: "/data/tidb-deploy/alertmanager-9093/log"
- host: 30.0.100.42
deploy_dir: "/data/tidb-deploy/alertmanager-9093"
data_dir: "/data/tidb-data/alertmanager-9093"
log_dir: "/data/tidb-deploy/alertmanager-9093/log"
モニタリングデータリンクを調整する
グラファナ調整データソース
prometheus の設定を確認し、alertmanager 情報を設定する
アラートマネージャーにログインし、複数のアラートマネージャーがクラスターを形成していることを確認します (構成はここで tidb によって自動的に完了します)。
複数の Prometheus に対して haproxy+keepalive リバース プロキシを再利用し、単一の Prometheus 障害後のダッシュボードの使用への影響を避けるためにダッシュボードの Prometheus データ ソースを変更する必要があります。
haproxy設定を少しだけ
ダッシュボードの構成は次のとおりです
Webhookの実装
- WebhookをFeishu APIに変換するgolangプログラムを書く
わずかに
- テストでは、HTTP インターフェイス テスト ツールを使用して、Feishu Webhook アプレットが関連するアラーム イベントを受信して解析することを確認します。
{
"version": "4",
"groupKey": "123333",
"status": "firing",
"receiver": "target",
"groupLabels": {"group":"group1"},
"commonLabels": {"server":"test"},
"commonAnnotations": {"server":"test"},
"externalURL": "http://30.0.100.40:3000",
"alerts": [
{
"labels": {"server":"test"},
"annotations": {"server":"test"},
"startsAt": "2023-08-12T07:20:50.52Z",
"endsAt": "2023-08-12T09:20:50.52Z"
}
]
}
2023/08/20 10:40:20 172.31.0.4 - {"version":"4","groupKey":"123333","status":"firing","Receiver":"target","GroupLabels":{"group":"group1"},"CommonLabels":{"server":"test"},"CommonAnnotations":{"server":"test"},"ExternalURL":"http://30.0.100.40:3000","Alerts":[{"labels":{"server":"test"},"annotations":{"server":"test"},"startsAt":"2023-08-12T07:20:50.52Z","endsAt":"2023-08-12T09:20:50.52Z"}]}
[GIN] 2023/08/20 - 10:40:20 | 200 | 621.879µs | 172.31.0.4 | POST "/alert-feishu"
アラートマネージャー Webhook を構成する
- alertmanager 構成ファイルのテンプレートを作成し、レシーバーと Webhook の定義を追加して、それらを tiup 中央制御コンピューターのパスに保存します。
routes:
- match:
receiver: webhook-feishu-adapter
continue: true
receivers:
- name: 'webhook-feishu-adapter'
webhook_configs:
- send_resolved: true
url: 'http://30.0.100.42:9999/alert-feishu'
- tiup edit-config を使用して、alertmanager_server の下に config_file を追加します。このパスは、前の手順で作成したalertmanager 構成ファイルを指します。
alertmanager_servers:
- host: 30.0.100.40
ssh_port: 22
web_port: 9093
cluster_port: 9094
deploy_dir: /data/tidb-deploy/alertmanager-9093
data_dir: /data/tidb-data/alertmanager-9093
log_dir: /data/tidb-deploy/alertmanager-9093/log
arch: arm64
os: linux
config_file: /home/tidb/monitor-template/alert_config_40.yaml
- host: 30.0.100.42
ssh_port: 22
web_port: 9093
cluster_port: 9094
deploy_dir: /data/tidb-deploy/alertmanager-9093
data_dir: /data/tidb-data/alertmanager-9093
log_dir: /data/tidb-deploy/alertmanager-9093/log
arch: arm64
os: linux
config_file: /home/tidb/monitor-template/alert_config_42.yaml
- アラームをトリガーしてみて、複数のアラームが生成されていないことを確認します。
- いずれかのセンターの監視機器を停止し、警報が正常に発せられるか確認してください。
- 前のステップで停止した tidb コンポーネントを開始し、アラームの回復をトリガーできることを確認します。
(ここには Webhook コードのバグがあり、復旧時間は引用されていません)
結論は
マルチセンター環境では、クラスター自体の高可用性機能を考慮することに加えて、その監視コンポーネントも高可用性機能を備えている必要があります。この記事では、マルチセンター監視の使用法とアラーム統合の観点から、複数センターでのクラスター監視のための高可用性展開および実装ソリューションの構築を試みます。
ご質問がございましたら、ご相談ください。
参考:
https://www.prometheus.wang/ha/alertmanager-high-availability.html
https://prometheus.io/docs/alerting/latest/overview/
オープンソース フレームワーク NanUI の作者がスチールの販売に切り替えたため、プロジェクトは中断されました。Apple App Store の無料リストのナンバー 1 はポルノ ソフトウェア TypeScript です。人気が出てきたばかりなのに、なぜ大手はそれを放棄し始めるのでしょうか。 ? TIOBE 10月リスト:Javaが最大の下落、C#はJavaに迫る Rust 1.73.0リリース AIガールフレンドにイギリス女王暗殺を勧められた男性に懲役9年の実刑判決 Qt 6.6正式リリース ロイター:RISC-Vテクノロジーが中米テクノロジー戦争の鍵となる 新たな戦場 RISC-V: 単一の企業や国に支配されない レノボ、Android PC の発売を計画