同じ都市内にある TiDB デュアルセンター監視コンポーネントの高可用性ソリューション

著者: Prest13 元のソース: https://tidb.net/blog/44b9b8b1

背景

tidb dr-auto 同期クラスターをデュアルセンターにデプロイ: モニタリングの高可用性を実現するために、独立した prometheus+alertmanager+grafana が物理的に分離された 2 つのデータセンターにデプロイされ、どのモニタリングにもアクセスできるようになります。

この展開アーキテクチャでは、2 セットの監視コンポーネントからのデータ収集の一貫性と、監視アラームの繰り返し送信の問題を考慮する必要があります。

Alt なし

実装のアイデア

  • 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"

モニタリングデータリンクを調整する

グラファナ調整データソース

Alt なし

Alt なし

prometheus の設定を確認し、alertmanager 情報を設定する

Alt なし

アラートマネージャーにログインし、複数のアラートマネージャーがクラスターを形成していることを確認します (構成はここで tidb によって自動的に完了します)。

Alt なし複数の Prometheus に対して haproxy+keepalive リバース プロキシを再利用し、単一の Prometheus 障害後のダッシュボードの使用への影響を避けるためにダッシュボードの Prometheus データ ソースを変更する必要があります。

haproxy設定を少しだけ

ダッシュボードの構成は次のとおりですAlt なし

Webhookの実装

  1. WebhookをFeishu APIに変換するgolangプログラムを書く

わずかに

  1. テストでは、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 を構成する

  1. 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'
  1. 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
  1. アラームをトリガーしてみて、複数のアラームが生成されていないことを確認します。

Alt なし

Alt なし

Alt なし

  1. いずれかのセンターの監視機器を停止し、警報が正常に発せられるか確認してください。

Alt なし

  1. 前のステップで停止した tidb コンポーネントを開始し、アラームの回復をトリガーできることを確認します。

Alt なし

Alt なし

(ここには 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 の発売を計画
{{名前}}
{{名前}}

おすすめ

転載: my.oschina.net/u/5674736/blog/10106852