問題タブ [istio-prometheus]

最近、Google Cloud の Kubernetes クラスター (GKE) に Istio 1.7.3 をインストールし、Grafana Prometheus ダッシュボードなどの他のさまざまなアドオンをインストールしました。Istio サービスとその他のパラメーターを使用してダッシュボードを構成しました。クラスター サイズを0 (ゼロ) に変更し、数回後に 2 にサイズ変更します (または必要に応じて)。構成済みの Grafana および Prometheus ダッシュボードは、クラスターのサイズ変更プロセス後に、構成済みのすべてのダッシュボードを失っていることがわかりました。すべてのダッシュボードが利用できず、作成したユーザーも利用できません。Prometheus、Grafana、およびその他のダッシュボードで ISTIO をインストールして管理するための良い方法は何ですか?

すべてのアドオンは正常に動作していますが、Network LoadBalancer URL 経由でアクセスできないだけです

YAML ファイルを保存したソース コードは以下のとおりです。

Pod は正常に実行されているため、以下のようにサービスに問題はありません。

今、私はそれらにアクセスできません...

追伸; 以下のスクリーンショットを確認してください。

それでは、各 YAML ファイルの NLM 文字列を a77* で learningservicemesh.com に更新する必要がありますか?

手伝ってください。

あなたが提案したとおりにしましたが、魅力はありません...

助けを求めたいのですが、Istio メトリクス モニタリングを有効にしているときに、Prometheus が Out Of Memory で強制終了されないようにするにはどうすればよいですか? 私は Prometheus Operator を使用しており、Medium の Prune によるこの記事から引用した Istio の ServiceMonitors を作成するまで、メトリクスのモニタリングは正常に機能します。記事から、それらは次のとおりです。

データ プレーンの ServiceMonitor:

コントロール プレーンの ServiceMonitor:

ServiceMonitor for Istio Data Plane が作成されると、メモリの使用量がわずか 1 分で約 10GB から最大 30GB になり、Prometheus レプリカは Kubernetes によって強制終了されます。CPU 使用率は正常です。このようなリソース使用量の大幅な増加を防ぐにはどうすればよいでしょうか? 再ラベル付けに何か問題がありますか? 約 500 のエンドポイントからメトリックをスクレイピングすることになっています。

[編集]

調査の結果、リソースの使用に大きな影響を与えているのは、ラベルの変更であると思われます。たとえば、targetLabel を pod_name ではなく pod に変更すると、リソースの使用量がすぐに増加します。

とにかく、私はこの問題の解決策を見つけられませんでした。GithHub で Istio が提供する半公式の ServiceMonitor と PodMonitor を使用しましたが、メモリ不足例外が発生する前に Prometheus の実行時間が長くなりました。現在、メモリ使用量が 10GB から 32GB になるまでに約 1 時間かかります。

これは、Istio メトリクスを有効にした後、時系列の数が非常に速く増加し、決して止まらないことを示しています。私の意見では、メモリ リークのように見えます。Istio モニタリングを有効にする前は、この数値は非常に安定しています。

他に提案はありますか？