Задержка пути Kubernetes Istio целесообразна в Графане - PullRequest
Новая
       32

Задержка пути Kubernetes Istio целесообразна в Графане

0 голосов
/ 22 апреля 2020

Я использую Istio в AWS EKS кластере. Я использую предварительно установленные prometheus и grafana для мониторинга модулей, Istio me sh, рабочие нагрузки службы 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.local составляет 2,91 мс, но я также хочу проверить задержка каждого пути. У него четыре пути: 

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)

1 Ответ

1 голос
/ 22 апреля 2020

Насколько мне известно, это не то, что метрики 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 является то, что это может привести к взрыву кардинальной метрики, если не использовать с осторожностью. Представьте, что некоторые из ваших путей содержат неограниченные значения динамических c (например, /object/123465, с 123456 в качестве идентификатора), если этот путь хранится как метка Прометея, это будет означать, что Прометей создаст один метри c на идентификатор, что может вызвать проблемы с производительностью Prometheus и привести к нехватке памяти в вашем приложении.

Я думаю, что это хорошая причина НЕ использовать Istio для предоставления метрик на основе пути. В то время как на другом конце платформы могут обладать достаточными знаниями для предоставления метрик на основе шаблона пути вместо фактического пути (например, /object/$ID вместо /object/123465), что решает проблему количества элементов.

PS: Kiali имеется некоторая документация по мониторингу времени выполнения, которая может помочь: https://kiali.io/documentation/runtimes-monitoring/

...