vivoコンテナクラスタ監視システムを最適化する方法

1. 背景

vivo のビジネスがコンテナ プラットフォームに移行するにつれて、vivo のクラウド ネイティブ監視システムは、指標の急増によってもたらされる一連の課題に直面しています。この記事では、コンテナ化プロジェクトにおけるコンテナ監視で遭遇する問題と、その解決策および最適化方法について説明します。

2. 監視アーキテクチャ

まず、vivo コンテナ監視アーキテクチャについて簡単に紹介します。

• [高可用性アーキテクチャ]: クラスター ディメンション内のデュアル コピー Prometheus は、基盤となるエクスポーター データを収集し、アダプター マルチインスタンスはマスターを自動的に選択して災害復旧を実現します。
• [データの永続性]: remoteWrite を使用して、バックエンドの VictoriaMetrics にデータを永続的ストレージとして保存します。 Grafana は、表示とアラームのデータ ソースとして VictoriaMetrics を使用します。
• [統合監視]: データは kafka-adapter によって remoteWrite 経由で Kafka に転送され、同社の基本監視サービスが Kafka 内のデータを消費して表示し、アラームを発行します。

ネイティブ Prometheus は標準的な高可用性ソリューションを提供しません。独自に開発したアダプタ「グループ選出」方式により重複排除を実装します。つまり、各 Prometheus レプリカはアダプタのグループに対応します。 2 つのアダプタ グループがリーダーを選出し、リーダー グループ内のアダプタのみがデータを転送します。このようにして重複排除が実現され、Prometheus デュアルレプリカの高可用性も実現されます。

3. 問題現象

過去数年間で、vivo のコンテナ化されたサービスは急速に成長し、監視トラフィックは数倍に増加しました。主に、監視コンポーネントの負荷の急増、コンテナ監視データのブレークポイント、データストレージコンポーネントの負荷の急増という 3 つの問題が発生しました。

3.1 監視コンポーネント負荷の急激な増加

コンテナ化では、デプロイされるたびに IP アドレスが変更されるという特性があるため、コンテナの監視指標は物理マシンや仮想マシンの監視指標よりも桁違いに高くなります。同時に、クラスターサイズの継続的な増加とビジネスの急速な成長により、Prometheus と VictoriaMetrics の監視負荷が急速に増加し、コンテナ監視に大きな課題をもたらしました。総監視時系列は、ポッドの数、ポッドインジケーターの数、インジケーターラベルディメンションの数に線形に関連する次の式に簡略化できます。

合計シリーズ = PodNum * PerPodMetrics * PerLabelCount

クラスターのサイズとコンテナの数が増え続けると、監視シーケンスが急速に増加し、監視コンポーネントの負荷が急速に増加し、コンテナ監視システムの安定性に影響を与えます。

3.2 モニタリングポイント損失現象

vivoコンテナレベル（業務）の監視データは自社開発のアダプタを通じてKafkaに転送され、社内の基本監視に格納され業務監視の表示やアラーム設定に利用されます。同時に、より多くの次元での統計レポート用にコピーが Druid にも保存されます。監視データをプッシュする際に、Pod 次元インジケーターの送信頻度を保証することが難しいことがわかりました。つまり、インジケーターの収集頻度は 10 秒に設定されていましたが、プッシュされたデータ内の頻度は 10 秒に到達できず、変動していました。次の図は、収集頻度が 10 秒に設定され、1 分間のインジケーター データが照会されることを示しています。

1 分以内のコンテナのcontainer_cpu_user_seconds_total メトリックの値:

期待される 6 つの値と矛盾する 4 つの値しか得られず、つまり「ポイントドロップ」が発生していることがわかります。指定された頻度でデータを表示すると、監視パネルに 0 が頻繁に表示されます。

3.3 データストレージコンポーネントの負荷が劇的に増加する

vivo コンテナ モニタリングでは、モニタリング データを永続的に保存するために、バックエンドの時系列データベースとして VictoriaMetrics v1.59.1-cluster を使用します。使用中に、VictoriaMetrics の負荷が不規則に増加し、バックエンド データベースの遅延により監視クエリ アラーム機能が異常になり、ユーザー エクスペリエンスに影響を与えることが判明しました。

4. 解決策

4.1 監視コンポーネント負荷の急激な増加

Prometheus を管理するには Prometheus-Operator を使用します。最適化プランには Prometheus-Operator に関連する用語があるため、次のことを理解するために、まず Prometheus-Operator を紹介します。

(画像出典: 公式アーキテクチャ図)

上図は Prometheus-Operator の公式アーキテクチャ図です。下の図のコンポーネントを次に示します。

1. オペレータ：オペレータはコア部分です。コントローラーとして、Prometheus および ServiceMonitor リソース オブジェクトを作成し、これらのリソース オブジェクトのステータスを監視および維持します。
2. Prometheus : このリソース オブジェクトは Prometheus サーバーとして存在します。 Operator は、カスタム リソース Prometheus タイプで定義されたコンテンツに基づいて Prometheus サーバーをデプロイします。 Prometheus は、labelSelector を通じて複数の ServiceMonitor を一致させることもできます。
3. ServiceMonitor : ServiceMonitor はエクスポーターの抽象化です。エクスポータは、メトリック データ インターフェイスを具体的に提供するサービスを提供するために使用されます。 Prometheus は、ServiceMonitor によって提供されるメトリック データ インターフェースを通じてデータを取得します。このリソースは、ラベルを通じて対応するサービス エンドポイントを選択し、Prometheus サーバーが選択されたサービスを通じてメトリック情報を取得できるようにします。 ServiceMonitor は、labelSelector を使用してサービスのタイプを一致させることができます。
4. サービス: サービスは Kubernetes の組み込みリソースであり、同じ機能を持つ Pod のグループをカプセル化し、この Pod グループのサービスを公開するための統一されたエントリを提供します。これにより、クライアント アクセス用の安定したアクセス アドレスが提供され、基盤となる Pod の変更や障害が保護されます。サービスを Kubernetes 内の他のコンポーネントと組み合わせて、負荷分散、サービス検出、クラスター内の内部通信などの機能を実現できます。

ServiceMonitor に焦点を当てる理由は、ServiceMonitor が、収集頻度、ターゲット内のインジケーターのフィルタリング、インジケーターのラベル名の変更、その他の操作など、ターゲット収集を指定するための構成を提供するためです。

監視コンポーネントの負荷が急増するという問題を解決するために、私たちは主にインジケーターの管理とパフォーマンスの最適化という 2 つの側面に焦点を当てています。

写真

4.1.1 指標ガバナンス

1. 未使用の指標をフィルタリングする

最初のタスクは、役に立たない指標をフィルタリングすることです。 Prometheus は Target からインジケーター データを取得します。各ターゲットの下に複数のエンドポイントが存在します。各エンドポイントは数十または数百のインジケーターを提供し、各インジケーターのデータ量も非常に大きくなります。ただし、実稼働環境では、数十個のインジケーターしか使用できない場合があります。 Prometheus によって収集された使用されない指標はリソースを浪費し、監視システムの安定性を低下させます。したがって、リソース使用量を削減するには、Prometheus によって収集されたインジケーターをある程度フィルタリングする必要があります。

プロメテウス

scrape_samples_scraped インジケーターは、収集されたターゲットを分析して、収集されたサンプルが多いターゲットを見つけます。

当社のインジケーター フィルタリングは、主に大量のデータを持つターゲットに焦点を当てています。インジケーターをフィルタリングする前に、Prometheus によって収集されたすべてのインジケーター データと、現在の監視アラーム パネルおよび関連する依存サービスによって使用されるインジケーターを収集する必要があります。次に、収集したインジケーターと現在使用されているインジケーターに基づいて正規表現を記述します。最後に、正規表現が対応するターゲットの ServiceMonitor に書き込まれます。 Prometheus は不要なインジケーターを除外します。以下は、cAdvisor ターゲットの container_threads で始まるインジケーターをフィルタリングする例です。

 # 过滤container_threads 开头的指标- action: drop regex: container_threads(.*) sourceLabels: - __name__

指標が合理化された後、1回の監視セッションで収集されるサンプルの数は1,000万から250万に削減されました。 Prometheus の CPU 使用量は 70% 削減され、メモリ使用量は 55% 削減されました。

2. 優先度の低いポッド関連の指標をフィルタリングする

合理化された指標を分析した結果、Pod ディメンションの監視指標が 70% を占め、かなりの割合の Pod がクラスター コンポーネントの Daemonset の Pod であることがわかりました。クラスターのサイズが大きくなるにつれて、Daemonset Pod の数も増加します。

ほとんどのクラスター コンポーネント Daemonset では、リソース制限が設定されているため、リソースの消費に注意を払う必要はありません。彼らが生き残り、正常にサービスを提供できるかどうかにのみ注意を払う必要があります。したがって、これらの Pod のインジケーターは簡略化され、これらの Pod のメモリや CPU などのコンテナ監視インジケーターは収集されません。

Daemonset によって提供される Pod には、同じ名前空間と同じ Pod 名プレフィックスがあります。

 # 名称为cadvisor的daemonset 提供的pod cadvisor-xxxx1 1/1 Running cadvisor-xxxx2 1/1 Running

cAdvisorによって提供されるインジケーターには、名前空間とポッド ラベルが含まれます。

 container_memory_cache{cnotallow="POD", namespace="monitoring", pod="kube-state-metrics-xxxx-xxxx", service="cadvisor"}

したがって、ServiceMonitor 上のインジケーターのポッドと名前空間を組み合わせ、指定されたルールと照合して、不要なデーモンセット ポッドのシーケンスを破棄します。

 # 过滤掉monitoring namespace 下面telegraf 这个daemosnet提供的pod 的相关指标- action: drop regex: monitoring@telegraf(.*) separator: '@' sourceLabels: - namespace - pod

クラスター内の一部の ds Pod のメトリックをフィルタリングした後。

1 回のトランザクションでcAdvisorに収集されるデータの量が 70% 減少しました。効果は非常に明白です。

4.1.2 パフォーマンスの最適化

1. Prometheusの負荷分散

vivo のコンテナ監視アーキテクチャのコアコンポーネントは Prometheus ですが、Prometheus はデータを収集するだけでなく、remote_write を通じて VictoriaMetrics と Kafka にデータをプッシュする必要があるため、日常的に最も問題が発生するコンポーネントでもあります。

写真

監視対象は Prometheus の異なるグループによって分類および収集され、各タイプの Prometheus はデュアルコピー モードになっています。クラスターのサイズが大きくなるにつれて、現在のモデルが不合理であることがわかります。 Pod次元の監視データ量が非常に多いため、コンテナ型Prometheusの負荷は他の種類のPrometheusに比べて非常に高くなります。高負荷状態では、再起動や remote_write 例外が発生する可能性があります。

当社の Prometheus コンポーネント アーキテクチャは、タイプ別に監視インジケーターを収集します。コンテナ タイプ Prometheus によって収集されるインジケーターの数は、コンポーネント、ホスト、およびリソース タイプよりもはるかに多くなります。そのため、クラスター内の Prometheus の負荷を手動で分散し、クラスターのコンテナー タイプ Prometheus 上の kubelet と kube-state-metrics を resource-Prometheus に転送して、container-Prometheus の負荷を軽減する必要があります。 (同時に、resource-Prometheus も kafka-adapter に送信されます)。また、監視ジャンプパネルが使用する監視指標（コア指標）は、データ損失を極力防ぐため、低負荷のPrometheus上で繰り返し収集されます。コンテナPrometheusの負荷が40%削減され、Prometheusの異常発生が大幅に減少しました。

2. Prometheusがデータを保存する時間を短縮する

2 番目の変更点は、Prometheus のデータ保存時間です。 Prometheus のデフォルトの保存期間は 2 週間です。その後のテストで、Prometheus の保存時間がメモリに大きな影響を与えることが判明し、現在では監視データの永続的なストレージは VictoriaMetrics に配置されています。 Prometheus に保存されるデータは主にトラブルシューティングに使用され、永続的なストレージのタスクを実行する必要はありません。そのため、Prometheus によって収集されたデータのローカル保存期間を 7 日から 2 日に変更しました。 Prometheus のメモリ消費量が 40% 削減されました。

4.2 モニタリングポイント損失現象

4.2.1 問題の場所

当初、Prometheus は remote_write プロセス中にデータを失ったと考えました。しかし、コミュニティに問い合わせて、Prometheus のリモート書き込みに関連する監視インジケーターを構成すると、Prometheus はリモート書き込み中にデータを破棄しないことがわかりました。さらに、データ プッシュ プロセス中に「ポイントが失われた」のは、kubelet の組み込みcAdvisorによって提供されたデータのみであることがわかりました。そこで、インジケーター プロバイダー コンポーネントcAdvisor を調査し始めたところ、 cAdvisor の「ポイントが欠落する」問題の原因は、 cAdvisorコンポーネントに独自の更新レートとタイムスタンプがあることであることがわかりました。 cAdvisor はcgroup からデータを読み取り、外部で使用するためにメモリに保存します。 Kubelet のcAdvisorのデータ更新頻度は 10 秒未満であり、更新時間に応じてインジケーターに反映されます。 Prometheus が 10 秒間隔でデータを収集する場合、基盤となるcAdvisor がデータを更新していないと、以前のデータがメモリ内に残ります。 cAdvisor はバージョン 0.31 以降でタイムスタンプのサポートを追加しました。つまり、cadvisor によって提供されるデータには独自のタイムスタンプが付きます。 Prometheus が cadviosr データを収集する際、 cAdvisorによって提供されるタイムスタンプを基準として使用します。したがって、Prometheus が ServiceMonitor によって設定された 10 秒の収集頻度に従って cAdvisor から提供されたデータを収集する場合、この期間中に cAdvisor がデータを更新しないと、Prometheus は最後の収集と同じタイムスタンプと値を収集し、Prometheus は 1 つのデータのみを記録します。これがcAdvisorの「失点」の本質です。 cAdvisorの更新頻度は、ハウスキーピング関連のパラメータとディザリング メカニズムによって決まります。

kubelet の組み込みcAdvisorによって設定されるパラメータ:

 // Kubelet 内置cadvisor 默认参数// cadvisor housekeeping 的间隔，刷新数据的间隔const defaultHousekeepingInterval = 10 * time.Second // cadvisor 是否开启动态housekeeping const allowDynamicHousekeeping = true /* cadvisor housekeeping 的最大间隔，allow_dynamic_housekeeping=true的时候, 会判断容器活跃程度动态的调整HousekeepingInterval， 当发现一段时间为容器状态为发生改变会将housekeeping 的间隔设置为maxHousekeepingInterval 。 */ const maxHousekeepingInterval = 15 * time.Second

4.2.2 解決策

上記の分析によると、インジケーターの頻度を保証できない根本的な原因は、 cAdvisorのデフォルトの起動パラメータにあります。ただし、現在収集しているcAdvisor はkubelet に組み込まれています。パラメータを変更する場合は、kubelet を変更する必要があります。そこで、クラスターの安定性やメンテナンスコストなどを考慮して、デーモンセットの形でcAdvisorのセットを展開し、 cAdvisor のデータ更新頻度を確保するために必要に応じてハウスキーピング関連のパラメータを設定し、 cAdvisorデータを収集する際には Prometheus がcAdvisor自身のタイムスタンプを無視するように設定しました。つまり、別途デプロイされたcAdvisorを使用して Pod 監視データを提供して、監視データの頻度を確保します。

私たちの仕事は主に、 cAdvisor の導入と対応する ServiceMonitor の変更に重点を置いています。

1. cAdvisorを展開する: 主にcAdvisor の起動パラメータを決定します。主な操作は、dynamic_housekeeping を無効にし、housekeeping_interval を 1 秒に設定して、 cAdvisor がデータを取得する頻度を確保することです。

 containers:// 参数设置- -allow_dynamic_housekeeping=false - -housekeeping_interval=1s

2. 対応する ServiceMonitor を作成し、 cAdvisor がPrometheus に cadviosr のタイムスタンプを無視するように指示します。 （cadviosr自体のジッター機構のため、周波数を固定することはできません）

cAdvisorのジッターメカニズム:

 // return jitter(cd.housekeepingInterval, 1.0) func jitter(duration time.Duration, maxFactor float64) time.Duration { if maxFactor <= 0.0 { maxFactor = 1.0 } wait := duration + time.Duration(rand.Float64()*maxFactor*float64(duration)) return wait }

cAdvisorの ServiceMonitor を設定して、インジケーターのタイムスタンプを無視します。

cAdvisorを別途デプロイし、Prometheus でcAdvisor自体のタイムスタンプを無視することで、コンテナ監視ブレークポイントの問題を解決し、監視頻度を確保することができました。

 spec: endpoints: - honorLabels: true // 忽略时间戳honorTimestamps: false interval: 10s

1 分以内に収集されたコンテナ関連の監視データは、6 つのデータ ポイントと非常に標準的なものであることがわかります。この時点で、監視の「ドロップポイント」問題は解決されました。

監視パネルには中断することなくデータが継続的に表示されます。

4.3 バックエンドデータベースの負荷急増

4.3.1 問題の場所

監視アーキテクチャ図からわかるように、監視バックエンドの時系列データベースとして VictoriaMetrics のコミュニティ v1.59.1 クラスター バージョンを使用し、Prometheus によって収集されたデータを、永続ストレージ用の remote_write を介して時系列データベース VictoriaMetrics に書き込みます。 Grafana は VictoriaMetrics からデータを読み取り、対応するダッシュボードに表示します。実際の使用では、Prometheus のリモート書き込み VictoriaMetrics に不規則な遅延スパイクがあることがわかりました。

Prometheus が VictoriaMetrics に書き込むのが遅れる

データベースの書き込み待ち時間の急増は、監視パネルの表示の遅延や誤った監視アラームなどの一連の問題を引き起こす可能性があります。

VictoriaMetrics の詳細な指標を分析します。 vmstorage コンポーネントが最下層で indexdb マージ操作を実行すると、CPU、メモリ、およびその他のリソースの使用量が急増することがわかりました。つまり、indexdb マージ操作は大量のリソースを消費します。

4.3.2 解決策

VictoriaMetricsなどのリソースが急増したために負荷が高くなりすぎて、Prometheusのremote_writeデータに正常に応答できない状態になっているのが原因と考えられます。私たちが期待しているのは、indexdb のマージ中にリソース使用量が増加しても、通常のデータ挿入やクエリには影響がないことです。関連リソースを照会した結果、VictoriaMetrics がバージョン 1.73.0 で indexdb のマージを最適化し、全体的なパフォーマンスが向上したことがわかりました。そのため、この問題を最適化するために VictoriaMetrics をアップグレードしました。バージョンアップグレード後、VictoriaMetrics の indexdb マージ中にリソースの急増は見られませんでした。

V. 結論

現在ではKubernetesが大規模に利用されるようになり、クラウドネイティブ監視の分野ではPrometheusを中核とした監視システムが事実上の標準となっています。ネイティブ Prometheus は、高可用性と永続ストレージのための標準ソリューションを提供しません。 Vivo は独自に開発したアダプターを使用して Prometheus デュアルレプリカの高可用性を実現し、データを永続的に保存するために VictoriaMetrics にデータを書き込みます。ビジネス規模の拡大に伴い、監視データの量も急速に増加し、監視収集および保存コンポーネントに大きな負担がかかっています。現在、データプロバイダー側​​のインジケーターの数を減らし、収集コンポーネントのパラメータを最適化し、オープンソースのストレージコンポーネントのバージョンをアップグレードすることで、監視システムのパフォーマンスが向上しました。

ビジネス規模の拡大に合わせて、アーキテクチャは継続的に進化し、改善されます。今後は、実際のビジネス規模に応じて監視アーキテクチャを最適化し、コンテナ監視全体のパフォーマンスを向上させていきます。今後は、監視収集、監視クエリ、監視データ提供の 3 つの領域でシステムパフォーマンスを継続的に向上させる予定です。

• [監視と収集]: データ収集アーキテクチャを改善し、自動シャーディングを適用して、収集側の負担を軽減します。
• [監視クエリ]: PrometheusRule を適用して、一般的なクエリの時間消費を削減し、監視クエリのエクスペリエンスを向上させます。
• 提供されるデータを監視: より安定したデータを提供するために、輸出側の量を減らします。