时间戳

首页 > 解决方案 > Grafana 中的 Kubernetes Istio 延迟路径明智

amazon-web-services - Grafana 中的 Kubernetes Istio 延迟路径明智

问题描述

我在 AWS EKS 集群中使用 Istio。我正在使用预装的 prometheus 和 grafana 来监控 pod、Istio 网格、Istio 服务工作负载。

我在三个不同的工作区中运行了三个服务，

Service 1:- service1.namespace1.svc.cluster.local
Service 2 :- service2.namespace2.svc.cluster.local
Service 3:- service3.namespace3.svc.cluster.local

Istio Service Dashboard我可以从Grafana中找到每个服务端点的延迟。但是，它只显示服务端点的延迟，而不是端点前缀。虽然整体服务端点延迟很好，但我想检查哪个路径在服务端点中花费时间。

假设 P50 Latency是service1.namespace1.svc.cluster.local2.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 = ?

我不确定在 Prometheus 和 Grafana 堆栈中是否可行。实现它的推荐方法是什么？

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)

标签： amazon-web-serviceskuberneteskubectlistioamazon-eks

解决方案

据我所知，这不是 Istio 指标所能提供的。但是，您应该查看您的服务器框架提供的可用指标（如果有）。因此，这是依赖于应用程序（框架）的。例如参见 SpringBoot ( https://docs.spring.io/spring-metrics/docs/current/public/prometheus ) 或 Vert.x ( https://vertx.io/docs/vertx-micrometer-metrics/java /#_http_server )

对于基于 HTTP 路径的指标，需要注意的一件事是，如果不小心使用，它可能会使指标基数爆炸。想象一下，您的一些路径包含无限的动态值（例如/object/123465，123456作为 ID），如果该路径存储为 Prometheus 标签，这意味着 Prometheus 将为每个 ID 创建一个指标，这可能会导致性能问题在 Prometheus 上，并冒着应用程序内存不足的风险。

这是我认为不让 Istio 提供基于路径的指标的一个很好的理由。而另一方面，框架可以有足够的知识来提供基于路径模板而不是实际路径（例如/object/$ID代替/object/123465）的度量，这解决了基数问题。

PS： Kiali 有一些关于运行时监控的文档，这可能会有所帮助：https ://kiali.io/documentation/runtimes-monitoring/

推荐阅读