Telemetry API

Istio надає Telemetry API, яке забезпечує гнучке налаштування метрик, доступ до логів, та трейси.

Використання API

Область дії, Спадкування та Перевизначення

Ресурси Telemetry API успадковують конфігурацію від батьківських ресурсів у ієрархії конфігурації Istio:

1. кореневий простір імен (наприклад, istio-system)
2. локальний простір імен (ресурс, що обмежений простором імен без selector робочого навантаження)
3. робоче навантаження (ресурс, що обмежений простором імен з selector робочого навантаження)

Ресурс Telemetry API у кореневому просторі імен конфігурації, зазвичай istio-system, забезпечує стандартну поведінку для всієї мережі. Будь-який специфічний для робочого навантаження selector у кореневому просторі імен буде проігноровано/відхилено. Не є дійсним визначення кількох ресурсів Telemetry API для всього mesh в кореневому просторі імен.

Перевизначення, специфічні для простору імен, для конфігурації всієї мережі можна досягти шляхом застосування нового ресурсу Telemetry у бажаному просторі імен (без selector робочого навантаження). Будь-які поля, зазначені в конфігурації простору імен, повністю перевизначать поля з батьківської конфігурації (у кореневому просторі імен).

Перевизначення, специфічні для робочого навантаження, можна досягти шляхом застосування нового ресурсу Telemetry у бажаному просторі імен з селектором робочого навантаження.

Вибір робочого навантаження

Окремі робочі навантаження в просторі імен вибираються за допомогою selector, який дозволяє вибір робочих навантажень на основі міток.

Неправильно, коли два різні ресурси Telemetry вибирають одне й те саме робоче навантаження за допомогою selector. Аналогічно, не допустимо мати два різних ресурсів Telemetry у просторі імен без вказаного selector.

Вибір провайдера

Telemetry API використовує концепцію провайдерів для вказання протоколу або типу інтеграції, який слід використовувати. Провайдери можуть бути налаштовані в MeshConfig.

Приклад набору конфігурації провайдера в MeshConfig:

data:
  mesh: |-
      extensionProviders: # Наступний вміст визначає два приклади провайдерів трейсів.
      - name: "localtrace"
        zipkin:
          service: "zipkin.istio-system.svc.cluster.local"
          port: 9411
          maxTagLength: 56
      - name: "cloudtrace"
        stackdriver:
          maxTagLength: 256

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

Додатково, можна налаштувати стандартного провайдера, який буде використовуватися, коли ресурси Telemetry не вказують провайдера.

Приклади

Налаштування поведінки для всієї мережі

Ресурси Telemetry API успадковують конфігурацію з кореневого простору імен для мережі, зазвичай istio-system. Щоб налаштувати поведінку для всього mesh, додайте новий (або відредагуйте наявний) ресурс Telemetry у кореневому просторі імен.

Ось приклад конфігурації, що використовує налаштування провайдера з попереднього розділу:

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: mesh-default
  namespace: istio-system
spec:
  tracing:
  - providers:
    - name: localtrace
    customTags:
      foo:
        literal:
          value: bar
    randomSamplingPercentage: 100

Ця конфігурація перевизначає стандартного провайдера з MeshConfig, встановлюючи стандартним провайдером для mesh localtrace. Вона також встановлює відсоток вибірки для всього mesh на 100 і налаштовує теґ, який додається до всіх відрізків трейсів з імʼям foo та значенням bar.

Налаштування поведінки трасування для простору імен

Щоб адаптувати поведінку для окремих просторів імен, додайте ресурс Telemetry до бажаного простору імен. Будь-які поля, зазначені в ресурсі простору імен, повністю перевизначать успадковану конфігурацію полів з ієрархії конфігурації. Наприклад:

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: namespace-override
  namespace: myapp
spec:
  tracing:
  - customTags:
      userId:
        header:
          name: userId
          defaultValue: unknown

При розгортанні у мережі з попередньою конфігурацією для всього mesh, це призведе до поведінки трасування в просторі імен myapp, яка надсилає відрізки трейсів до провайдера localtrace і випадковим чином вибирає запити для трасування на рівні 100%, але налаштовує власні теґи для кожного відрізку з іменем userId і значенням, яке береться з заголовка запиту userId. Важливо, що теґ foo: bar з батьківської конфігурації не буде використовуватися в просторі імен myapp. Поведінка власних теґів повністю перекриває поведінку, налаштовану в ресурсі mesh-default.istio-system.

Налаштування поведінки для конкретного робочого навантаження

Щоб адаптувати поведінку для окремих робочих навантажень, додайте ресурс Telemetry до бажаного простору імен і використовуйте selector. Будь-які поля, зазначені в ресурсі для конкретного робочого навантаження, повністю перевизначають успадковану конфігурацію полів з ієрархії конфігурації.

Наприклад:

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: workload-override
  namespace: myapp
spec:
  selector:
    matchLabels:
      service.istio.io/canonical-name: frontend
  tracing:
  - disableSpanReporting: true

У цьому випадку трасування буде вимкнено для робочого навантаження frontend у просторі імен myapp. Istio все ще буде передавати заголовки трасування, але жодні відрізки трейсів не будуть надіслані до налаштованого провайдера трасування.