Grafana 中的 Kubernetes Istio 延迟路径明智答案

【问题标题】：Kubernetes Istio latency path wise in GrafanaGrafana 中的 Kubernetes Istio 延迟路径明智
【发布时间】：2020-08-04 19:16:49
【问题描述】：

我在 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

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

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

我不确定在 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)

【问题讨论】：

嗨，你有没有考虑尝试 istio tracing？
Istio 默认捕获所有请求的跟踪。我可以在哪个仪表板中看到它们
据我所知，不在 Grafana 中。 Jaeger 是默认的跟踪工具，它有自己的仪表板。 Kiali 还可以通过 jaeger 显示痕迹。

标签： amazon-web-services kubernetes kubectl istio amazon-eks

【解决方案1】：

据我所知，这不是 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/

【讨论】：