1

我想向您寻求帮助 - 在启用 Istio 指标监控时，如何防止 Prometheus 因内存不足而被杀死？我使用 Prometheus Operator 并且对指标的监控工作正常，直到我为 Istio 创建 ServiceMonitors，取自Prune on Medium 的这篇文章。从文章来看，它们如下：

数据平面的 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

创建 Istio 数据平面的 ServiceMonitor 后，内存使用量在一分钟内从大约 10GB 增加到 30GB，并且 Prometheus 副本被 Kubernetes 杀死。CPU使用率正常。怎样才能防止资源使用量出现如此巨大的增长？重新标记有什么问题吗？它应该从大约 500 个端点抓取指标。

[编辑]

从调查看来，这对资源使用有很大影响的是重新标记。例如，如果我将 targetLabel 更改为 pod 而不是 pod_name，则资源使用量会立即增加。

无论如何，我没有找到解决这个问题的方法。我在 GithHub 上使用了 Istio 提供的半官方ServiceMonitor 和 PodMonitor，但它只是让 Prometheus 在 Out Of Memory Exception 之前运行得更久。现在，从 ~10GB 到 32GB 的内存使用大约需要一个小时。

我可以看到的是，启用 Istio 指标后，时间序列的数量增长得非常快并且永不停止，在我看来这看起来像是内存泄漏。在启用 Istio 监控之前，这个数字相当稳定。

你有什么其他的建议？

4

0 回答 0