API de Telemetría

Istio proporciona una API de Telemetría que permite una configuración flexible de métricas, registros de acceso y trazado.

Uso de la API

Alcance, Herencia y Anulaciones

Los recursos de la API de Telemetría heredan la configuración de los recursos padre en la jerarquía de configuración de Istio:

  1. namespace de configuración raíz (ejemplo: istio-system)
  2. namespace local (recurso con alcance de namespace sin selector de workload)
  3. workload (recurso con alcance de namespace con un selector de workload)

Un recurso de la API de Telemetría en el namespace de configuración raíz, típicamente istio-system, proporciona valores predeterminados para el comportamiento de toda la malla. Cualquier selector específico de workload en el namespace de configuración raíz será ignorado/rechazado. No es válido definir múltiples recursos de la API de Telemetría de toda la malla en el namespace de configuración raíz.

Las anulaciones específicas del namespace para la configuración de toda la malla se pueden lograr aplicando un nuevo recurso Telemetry en el namespace deseado (sin un selector de workload). Cualquier campo especificado en la configuración del namespace anulará completamente el campo de la configuración padre (en el namespace de configuración raíz).

Las anulaciones específicas del workload se pueden lograr aplicando un nuevo recurso Telemetry en el namespace deseado con un selector de workload.

Selección de Workload

Los workloads individuales dentro de un namespace se seleccionan a través de un selector que permite la selección de workloads basada en etiquetas.

No es válido que dos recursos Telemetry diferentes seleccionen el mismo workload usando selector. Del mismo modo, no es válido tener dos recursos Telemetry distintos en un namespace sin selector especificado.

Selección de Proveedor

La API de Telemetría utiliza el concepto de proveedores para indicar el protocolo o tipo de integración a utilizar. Los proveedores se pueden configurar en MeshConfig.

Un ejemplo de conjunto de configuración de proveedor en MeshConfig es:

data:
  mesh: |-
      extensionProviders: # El siguiente contenido define dos proveedores de trazado de ejemplo.
      - name: "localtrace"
        zipkin:
          service: "zipkin.istio-system.svc.cluster.local"
          port: 9411
          maxTagLength: 56
      - name: "cloudtrace"
        stackdriver:
          maxTagLength: 256

Para mayor comodidad, Istio viene con algunos proveedores configurados de fábrica con valores predeterminados:

Nombre del ProveedorFuncionalidad
prometheusMétricas
stackdriverMétricas, Trazado, Registro de Acceso
envoyRegistro de Acceso

Además, se puede establecer un proveedor predeterminado que se utilizará cuando los recursos Telemetry no especifiquen un proveedor.

Ejemplos

Configuración del comportamiento de toda la malla

Los recursos de la API de Telemetría heredan del namespace de configuración raíz para una malla, típicamente istio-system. Para configurar el comportamiento de toda la malla, agregue un nuevo (o edite el existente) recurso Telemetry en el namespace de configuración raíz.

Aquí hay un ejemplo de configuración que utiliza la configuración del proveedor de la sección anterior:

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

Esta configuración anula el proveedor predeterminado de MeshConfig, estableciendo el valor predeterminado de la malla en el proveedor localtrace. También establece el porcentaje de muestreo de toda la malla en 100, y configura una etiqueta para que se agregue a todos los spans de traza con un nombre de foo y un valor de bar.

Configuración del comportamiento de trazado con alcance de namespace

Para adaptar el comportamiento a namespaces individuales, agregue un recurso Telemetry al namespace deseado. Cualquier campo especificado en el recurso del namespace anulará completamente la configuración de campo heredada de la jerarquía de configuración. Por ejemplo:

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

Cuando se despliega en una malla con la configuración de ejemplo de toda la malla anterior, esto dará como resultado un comportamiento de trazado en el namespace myapp que envía spans de traza al proveedor localtrace y selecciona aleatoriamente solicitudes para el trazado a una tasa del 100%, pero que establece etiquetas personalizadas para cada span con un nombre de userId y un valor tomado de la cabecera de solicitud userId. Es importante destacar que la etiqueta foo: bar de la configuración padre no se utilizará en el namespace myapp. El comportamiento de las etiquetas personalizadas anula completamente el comportamiento configurado en el recurso mesh-default.istio-system.

Configuración del comportamiento específico del workload

Para adaptar el comportamiento a workloads individuales, agregue un recurso Telemetry al namespace deseado y use un selector. Cualquier campo especificado en el recurso específico del workload anulará completamente la configuración de campo heredada de la jerarquía de configuración.

Por ejemplo:

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

En este caso, el trazado se deshabilitará para el workload frontend en el namespace myapp. Istio seguirá reenviando las cabeceras de trazado, pero no se informarán spans al proveedor de trazado configurado.

¿Fue útil esta información?
¿Tienes alguna sugerencia para mejorar?

¡Gracias por tus comentarios!