我在AWS EKS集群中使用Istio。我使用预装的prometheus和grafana来监控pod、Istio mesh和Istio服务工作负载。
我有三个服务在三个不同的工作区运行，
Service 1:- service1.namespace1.svc.cluster.local
Service 2 :- service2.namespace2.svc.cluster.local
Service 3:- service3.namespace3.svc.cluster.local
我可以从Grafana中的Istio Service Dashboard中找到每个服务端点的延迟。但是，它只是显示服务端点的延迟，而不是端点前缀。虽然总体服务端点延迟很好，但我想检查在服务端点中哪条路径需要时间。
假设service1.namespace1.svc.cluster.local的P50 Latency是2.91ms，但我也想检查每条路径的延迟。它有四条路径，
service1.namespace1.svc.cluster.local/login => Loging Path , P50 Latency = ?
service1.namespace1.svc.cluster.local/signup => Singup Path , P50 Latency = ?
service1.namespace1.svc.cluster.local/auth => Auth path , P50 Latency = ?
service1.namespace1.svc.cluster.local/list => List path , P50 Latency = ?
我不确定在普罗米修斯和格拉法纳的堆栈中是否可能。建议的实现方式是什么？
Istioctl version --remote
client version: 1.5.1
internal-popcraftio-ingressgateway version:
citadel version: 1.4.3
galley version: 1.4.3
ingressgateway version: 1.5.1
pilot version: 1.4.3
policy version: 1.4.3
sidecar-injector version: 1.4.3
telemetry version: 1.4.3
pilot version: 1.5.1
office-popcraftio-ingressgateway version:
data plane version: 1.4.3 (83 proxies), 1.5.1 (4 proxies)
据我所知，这不是Istio度量所能提供的。但是，您应该查看服务器框架提供的可用度量(如果有的话(。因此，这是依赖于应用程序(框架(的。例如，请参阅SpringBoot(https://docs.spring.io/spring-metrics/docs/current/public/prometheus(或垂直x(https://vertx.io/docs/vertx-micrometer-metrics/java/#_http_server(
对于基于HTTP路径的度量，需要注意的一点是，如果不小心使用，它可能会使度量基数爆炸。想象一下，你的一些路径包含无限动态值(例如/object/123465，其中123456是一个ID(，如果该路径存储为Prometheus标签，这意味着在引擎盖下，Prometheus将为每个ID创建一个度量，这可能会导致Prometheu斯的性能问题，并导致应用程序内存不足的风险。
我认为这是不让Istio提供基于路径的度量的一个很好的理由。而在另一端，框架可以具有足够的知识来提供基于路径模板而不是实际路径的度量(例如/object/$ID而不是/object/123465(，这解决了基数问题。
附言：Kiali有一些关于运行时监控的文档，可能会有所帮助：https://kiali.io/documentation/runtimes-monitoring/