我建议不要共享现有的istio prometheus，它部署在istio-system命名空间是有原因的。它由istio部署并配置。

如果您真的想创建一个中央共享的prometheus服务，请使用prometheus-运算符并为istio创建一个prometheus运算符。要将您的istio安装重新集成到这个新的prometheus实例中，这仍然需要大量的配置工作，并且只有在您计划扩展运行此设置的集群数量时才可能值得。2或4个Prometheis是一个可以管理的差距。20或40不是那么多。

Istio附带Prometheus和Grafana的预配置版本，包括Prometheus数据源和Istio仪表板。您应该能够通过运行以下命令来确认Prom和Grafana已经在该命名空间中运行：

$kubectl-n istio-system获取svc prometheus

$kubectl-n istio-system获取svcgrafana

(https://istio.io/docs/tasks/telemetry/metrics/using-istio-dashboard/)

它们应该是这两种服务的全功能版本，但是为了为您的自定义作业配置Prometheus，您需要找到并更新作为Istio一部分部署的ConfigMap，其中包括prometheus. yaml。如果您停止运行Istio，或者有人出于Istio原因将confiMap更新回旧版本，您可能会失去这些配置选项。Istio的Grafana的默认映像也是较旧的，根据文档，版本为5.2.3，因此运行自己的映像意味着您可以更新到最新版本。

运行Prometheus两次不应该是一个大问题，尤其是如果这两个版本专注于不同的目标（尽管可能在不同的节点上运行），所以例如，如果您的Prom专注于Node导出器和应用程序指标，而Istio Prom只查看Istio资源。这将使其保持干净，您可以在专用的监控命名空间中部署自己的Prometheus和其他工具。这是我写的关于Prometheus部署的博客和视频，其中涵盖了命名空间和基本的Prometheus/Node导出器部署。

另一种选择是使用Prometheus远程存储选项和远程托管版本的Grafana。Metricfire（我为其工作）提供远程存储，并允许您直接通过Grafana中的数据源查询该存储，而不是针对您的本地Prometheus。您可以将远程存储详细信息添加到任何Prometheus配置，包括Istio Prom（如果您愿意），并将其发送到Metricfire以托管和创建仪表板（这是我写的一篇关于在哪里可以找到不同部署方法的prometheus. yaml的博客文章，如果有帮助的话）。这将允许您在同一个仪表板中并排查看两个Proms的指标。

您还可以在那里安装Istio仪表板——您可以在Grafana站点中找到它们：（https://grafana.com/grafana/dashboards?search=istio）。将您的指标和Istio指标放在同一个位置意味着您也可以并排查看它们，如果您需要分析任何性能趋势，可以将它们保留更长时间。

我建议最好使用Azure日志分析，而不是在集群中安装Prometheus。

第1步：在azure中创建日志分析第2步：在kubernetes集群中安装OMS代理，并在集群和日志分析之间安装管道第3步：日志将开始从集群移动到日志分析第4步：从Azure监控创建日志警报，该警报将监控集群运行状况第5步：在grafana数据源中添加日志分析并创建几个仪表板

按照下面的链接连接日志分析与Grafanahttps://www.ciraltos.com/connect-grafana-to-azure-log-analytics/

点击链接创建日志分析：https://learn.microsoft.com/en-us/azure/container-service/kubernetes/container-service-kubernetes-oms