Метрики та логи, ЧаПи

Ви можете збирати дані телеметрії Istio, використовуючи Prometheus. А потім використовувати HTTP API Prometheus для запитів до цих даних.

Телеметрія у проксі (відомою як v2) знижує використання ресурсів і покращує продуктивність проксі в порівнянні з телеметрією на основі Mixer (відомою як v1) і є переважним механізмом для телеметрії в Istio. Однак є кілька відмінностей у телеметрії між v1 і v2, які наведені нижче:

• Відсутні мітки для трафіку поза мережею Телеметрія у проксі покладається на обмін метаданими між проксі Envoy для збору інформації, такої як імʼя робочого навантаження, простір імен і мітки. У телеметрії на основі Mixer ця функціональність виконувалася Mixer як частина комбінування атрибутів запитів з даними платформи. Цей обмін метаданими виконується проксі Envoy, додаючи конкретний HTTP заголовок для протоколу HTTP або доповнюючи протокол ALPN для протоколу TCP, як описано тут. Такий підхід вимагає, щоб проксі Envoy були впроваджені як у клієнтських, так і в серверних робочих навантаженнях, що передбачає, що телеметрія, що збирається, коли один з партнерів не знаходиться в мережі, буде без атрибутів партнера, таких як імʼя робочого навантаження, простір імен і мітки. Однак, якщо обидва партнери мають впроваджені проксі, всі мітки, згадані тут, доступні в згенерованих метриках. Коли серверне робоче навантаження знаходиться поза мережею, метадані робочого навантаження сервера все ще передаються клієнтському sidecar, що призводить до того, що клієнтські метрики мають заповнені мітки метаданих робочого навантаження сервера.

• Обмін метаданими TCP вимагає mTLS Обмін метаданими TCP покладається на протокол ALPN Istio, який вимагає, щоб mutual TLS (mTLS) був увімкнений для успішного обміну метаданими між проксі Envoy. Це означає, що якщо mTLS не увімкнено у вашому кластері, телеметрія для протоколу TCP не включатиме інформацію про партнера, таку як імʼя робочого навантаження, простір імен і мітки.

• Відсутність механізму для конфігурації власних кошиків для гістограмних метрик Телеметрія на основі Mixer підтримувала налаштування кошиків для метрик типу гістограми, таких як тривалість запиту та розміри байтів TCP. Телеметрія у проксі не має такого механізму. Крім того, кошики для метрик затримки в телеметрії у проксі вимірюються в мілісекундах, в порівнянні з секундами в телеметрії на основі Mixer. Однак, в телеметрії у проксі доступно стандартно більше кошиків для метрик затримки на нижчих рівнях затримки.

• Відсутність термінації метрик для метрик з коротким часом існування Телеметрія на основі Mixer підтримувала термінацію метрик, за якої метрики, що не були згенеровані протягом встановленого часу, були видалені з колекції Prometheus. Це корисно в сценаріях, таких як одноразові завдання, які генерують метрики з коротким часом існування. Видалення метрик запобігає звітуванню про метрики, які більше не змінюватимуться в майбутньому, тим самим зменшуючи мережевий трафік і зберігання в Prometheus. Цей механізм термінації не доступний у телеметрії у проксі. Робоче рішення для цього можна знайти тут.

Метрики з коротким терміном життя можуть впливати на продуктивність Prometheus, оскільки вони часто є великою джерелом кардинальності міток. Кардинальність — це міра кількості унікальних значень для міток. Щоб управляти впливом ваших метрик з коротким терміном життя в Prometheus, спочатку потрібно визначити метрики та мітки з високою кардинальністю. Prometheus надає інформацію про кардинальність на своїй сторінці /status. Додаткову інформацію можна отримати через PromQL. Є кілька способів зменшити кардинальність метрик Istio:

• Вимкніть резервне використання заголовка хосту. Мітка destination_service є одним з потенційних джерел високої кардинальності. Значення для destination_service стандартно використовують заголовок хосту, якщо проксі Istio не може визначити службу призначення з інших метаданих запиту. Якщо клієнти використовують різні заголовки хостів, це може призвести до великої кількості значень для destination_service. В цьому випадку слідуйте керівництву з налаштування метрик, щоб вимкнути резервне використання заголовка хосту на рівні мережі. Щоб вимкнути резервне використання заголовка хосту для конкретного робочого навантаження або простору імен, потрібно скопіювати конфігурацію EnvoyFilter статистики, оновити її, щоб вимкнути резервне використання заголовка хосту, і застосувати її з більш специфічним селектором. Цей тікет має більше деталей про те, як цього досягти.
• Викиньте непотрібні мітки зі збору. Якщо мітка з високою кардинальністю не потрібна, ви можете викинути її зі збору метрик через налаштування метрик за допомогою tags_to_remove.
• Нормалізуйте значення міток, через федерацію або класифікацію. Якщо інформація, надана міткою, потрібна, ви можете використовувати федерацію Prometheus або класифікацію запитів для нормалізації мітки.

Mixer був видалений у випуску Istio 1.8. Міграція необхідна, якщо ви все ще покладаєтеся на вбудовані адаптери Mixer або будь-які зовнішні адаптери для розширення мережі.

Для вбудованих адаптерів надано кілька альтернатив:

• Інтеграції Prometheus і Stackdriver реалізовані як розширення проксі. Налаштування телеметрії, створеної цими двома розширеннями, може бути досягнута через класифікацію запитів та налаштування метрик Prometheus.
• Функціональність глобального та локального обмеження швидкості (memquota і redisquota адаптери) надається через розвʼязання на основі Envoy для обмеження швидкості.
• Адаптер OPA замінений на розвʼязання на основі Envoy ext-authz, яке підтримує інтеграцію з агентом політики OPA.

Для власних зовнішніх адаптерів рекомендується міграція до розширень на основі Wasm. Будь ласка, ознайомтеся з посібниками по розробці модуля Wasm та розповсюдженню розширень. Як тимчасове рішення, ви можете увімкнути підтримку Envoy ext-authz та gRPC доступу до API логів у Mixer, що дозволяє вам оновити Istio до версій після 1.7, одночасно використовуючи 1.7 Mixer з зовнішніми адаптерами. Це дасть вам більше часу для міграції на розширення на основі Wasm. Зверніть увагу, що це тимчасове рішення не протестовано в бойових умовах і навряд чи отримає виправлення помилок, оскільки воно доступне тільки у гілці Istio 1.7, яка вийшла з терміну підтримки після лютого 2021 року.

Ви можете використовувати docker-compose для встановлення Prometheus.

Ви можете включити трейсинг, щоб визначити маршрут запиту в Istio.

Додатково, ви можете використовувати такі команди, щоб дізнатися більше про стан мережі:

• istioctl proxy-config: Отримати інформацію про конфігурацію проксі, коли ви працюєте в Kubernetes:

  # Отримати інформацію про конфігурацію bootstrap для екземпляра Envoy у вказаному podʼі.
  $ istioctl proxy-config bootstrap productpage-v1-bb8d5cbc7-k7qbm
  
  # Отримати інформацію про конфігурацію кластера для екземпляра Envoy у вказаному podʼі.
  $ istioctl proxy-config cluster productpage-v1-bb8d5cbc7-k7qbm
  
  # Отримати інформацію про конфігурацію прослуховувача для екземпляра Envoy у вказаному podʼі.
  $ istioctl proxy-config listener productpage-v1-bb8d5cbc7-k7qbm
  
  # Отримати інформацію про конфігурацію маршрутизації для екземпляра Envoy у вказаному podʼі.
  $ istioctl proxy-config route productpage-v1-bb8d5cbc7-k7qbm
  
  # Отримати інформацію про конфігурацію точок доступу для екземпляра Envoy у вказаному podʼі.
  $ istioctl proxy-config endpoints productpage-v1-bb8d5cbc7-k7qbm
  
  # Спробуйте наступне, щоб дізнатися більше про команди proxy-config
  $ istioctl proxy-config --help

• kubectl get: Отримує інформацію про різні ресурси в мережі разом з конфігурацією маршрутизації:

  # Показати всі віртуальні сервіси
  $ kubectl get virtualservices

Так. Prometheus — це система моніторингу з відкритим кодом та база даних часових рядів. Ви можете використовувати Prometheus з Istio для запису метрик, які відстежують справність Istio та застосунків у сервісній мережі. Ви можете візуалізувати метрики за допомогою інструментів, таких як Grafana та Kiali. Перегляньте Конфігурацію для Prometheus, щоб зрозуміти, як увімкнути збір метрик.

Кілька приміток:

• Якщо pod Prometheus запустився до того, як pod istiod встиг створити необхідні сертифікати та надіслати їх до Prometheus, pod Prometheus потрібно перезапустити, щоб зібрати дані з цілей, захищених взаємним TLS.
• Якщо ваш застосунок надає метрики Prometheus на окремому порту, цей порт слід додати до специфікацій сервісу та розгортання.