助けを求めたいのですが、Istio メトリクス モニタリングを有効にしているときに、Prometheus が Out Of Memory で強制終了されないようにするにはどうすればよいですか? 私は Prometheus Operator を使用しており、Medium の Prune によるこの記事から引用した Istio の ServiceMonitors を作成するまで、メトリクスのモニタリングは正常に機能します。記事から、それらは次のとおりです。
データ プレーンの ServiceMonitor:
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: prometheus-oper-istio-dataplane
labels:
monitoring: istio-dataplane
release: prometheus
spec:
selector:
matchExpressions:
- {key: istio-prometheus-ignore, operator: DoesNotExist}
namespaceSelector:
any: true
jobLabel: envoy-stats
endpoints:
- path: /stats/prometheus
targetPort: http-envoy-prom
interval: 15s
relabelings:
- sourceLabels: [__meta_kubernetes_pod_container_port_name]
action: keep
regex: '.*-envoy-prom'
- action: labelmap
regex: "__meta_kubernetes_pod_label_(.+)"
- sourceLabels: [__meta_kubernetes_namespace]
action: replace
targetLabel: namespace
- sourceLabels: [__meta_kubernetes_pod_name]
action: replace
targetLabel: pod_name
コントロール プレーンの ServiceMonitor:
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: prometheus-oper-istio-controlplane
labels:
release: prometheus
spec:
jobLabel: istio
selector:
matchExpressions:
- {key: istio, operator: In, values: [mixer,pilot,galley,citadel,sidecar-injector]}
namespaceSelector:
any: true
endpoints:
- port: http-monitoring
interval: 15s
- port: http-policy-monitoring
interval: 15s
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 モニタリングを有効にする前は、この数値は非常に安定しています。
他に提案はありますか？