Vincular la aplicación OpenTelemetry-instrumentada a Kubernetes

Si es un desarrollador que ejecuta aplicaciones en Kubernetes, puede usar New Relic para comprender cómo la infraestructura Kubernetes afecta su aplicación instrumentada OpenTelemetry .

Después de completar los pasos a continuación, puede usar la New Relic UI para correlacionar la métrica a nivel de OpenTelemetry aplicación de con Kubernetes la infraestructura métrica . Esto le ayudará a ver el panorama completo de sus telemetry data y trabajar en equipos para obtener un tiempo medio de resolución (MTTR) más rápido para problemas en su entorno Kubernetes .

Descripción general: cómo correlacionamos los datos

Los pasos de esta guía permiten que su aplicación inyecte metadatos específicos de la infraestructura en los telemetry data. El resultado es que la New Relic UI está llena de información procesable. Estos son los pasos que deberá seguir para que esto funcione:

En cada contenedor de aplicación, defina una variable de entorno para enviar telemetry data al recolector.
desplegar el recolector OpenTelemetry como DaemonSet en modo agente con procesadores resourcedetection, resource, batch y k8sattributes para inyectar metadatos relevantes (clúster, despliegue y nombres de namespace )

Requisitos previos

Para tener éxito con los pasos a continuación, ya debe estar familiarizado con OpenTelemetry y Kubernetes y haber hecho lo siguiente:

Creó las siguientes variables de entorno:
- OTEL_EXPORTER_OTLP_ENDPOINT (New Relic extremo para su región o propósito)
- NEW_RELIC_API_KEY (
  )
Instaló la integración de New Relic Kubernetes en su clúster
instrumentó su aplicación con OpenTelemetry y envió datos exitosamente a New Relic a través del Protocolo OpenTelemetry (OTLP)

Si tiene preguntas generales sobre el uso del recolector con New Relic, consulte nuestra Introducción al recolector OpenTelemetry con New Relic.

Configure su aplicación para enviar telemetry data al recolector OpenTelemetry

Para configurar esto, debe agregar un fragmento personalizado a la sección env de su archivo YAML de Kubernetes. El siguiente ejemplo muestra el fragmento de un microservicio de interfaz de muestra (Frontend.yaml). El fragmento incluye dos secciones que hacen lo siguiente:

Section 1:
Asegúrese de que los telemetry data se envíen al recolector. Esto establece la variable de entorno OTEL_EXPORTER_OTLP_ENDPOINT con la IP del host. Para ello, llama a la API descendente para extraer la IP del host.
Section 2:
Adjunte metadatos específicos de la infraestructura. Para hacer esto, capturamos metadata.uid usando la API descendente y lo agregamos a la variable de entorno OTEL_RESOURCE_ATTRIBUTES . Esta variable de entorno la utilizan los procesadores resourcedetection y k8sattributes del recolector OpenTelemetry para agregar contexto adicional específico de la infraestructura a telemetry data.

Para cada microservicio instrumentado con OpenTelemetry, agregue las líneas resaltadas a continuación a la sección env de su manifiesto:

# Frontend.yaml
apiVersion: apps/v1
kind: Deployment
...
spec:
  containers:
  - name: yourfrontendservice
    image: yourfrontendservice-beta
  env:
  # Section 1: Ensure that telemetry data is sent to the collector
  - name: HOST_IP
        valueFrom:
          fieldRef:
            fieldPath: status.hostIP
      # This is picked up by the opentelemetry sdks
      - name: OTEL_EXPORTER_OTLP_ENDPOINT
        value: "http://$(HOST_IP):55680"
  # Section 2: Attach infrastructure-specific metadata
     # Get pod ip so that k8sattributes can tag resources
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_UID
valueFrom:
fieldRef:
fieldPath: metadata.uid
      # This is picked up by the resource detector
    - name: OTEL_RESOURCE_ATTRIBUTES
      value: service.instance.id=$(POD_NAME),k8s.pod.uid=$(POD_UID)”

Configurar y desplegar el recolector OpenTelemetry como agente

Le recomendamos implementar el recolector como agente en cada nodo dentro de un clúster de Kubernetes. El agente puede recibir telemetry data y enriquecer telemetry data con metadatos. Por ejemplo, el recolector puede agregar información de atributos personalizados o de infraestructura a través de procesadores, así como manejar procesamiento por lotes, reintentos, compresión y características avanzadas adicionales que se manejan de manera menos eficiente en el nivel de instrumentación del cliente.

Para obtener ayuda para configurar el recolector, consulte el archivo de configuración del recolector de muestra a continuación, junto con las secciones sobre cómo configurar estas opciones:

Exportador OTLP
procesador por lotes
procesador de resourcedetection
Procesador k8sattributes: general
Procesador de atributos k8: RBAC
Procesador k8sattributes: filtros

receivers:
  otlp:
    protocols:
      grpc:

processors:
  batch:
  resource:
    attributes:
      - key: host.id
        from_attribute: host.name
        action: upsert
  resourcedetection:
    detectors: [ gke, gce ]
  k8sattributes:
    auth_type: "serviceAccount"
    passthrough: false
    filter:
      node_from_env_var: KUBE_NODE_NAME
    extract:
      metadata:
        - k8s.pod.name
        - k8s.pod.uid
        - k8s.deployment.name
        - k8s.cluster.name
        - k8s.namespace.name
        - k8s.node.name
        - k8s.pod.start_time
    pod_association:
      - from: resource_attribute
        name: k8s.pod.uid

exporters:
  otlp:
    endpoint: $OTEL_EXPORTER_OTLP_ENDPOINT
    headers:
      api-key: $NEW_RELIC_API_KEY
  logging:
    logLevel: DEBUG

service:
  pipelines:
    metrics:
      receivers: [ otlp ]
      processors: [ resourcedetection, k8sattributes, resource, cumulativetodelta, batch ]
      exporters: [ otlp ]
    traces:
      receivers: [ otlp ]
      processors: [ resourcedetection, k8sattributes, resource, batch ]
      exporters: [ otlp ]
    logs:
      receivers: [ otlp ]
      processors: [ resourcedetection, k8sattributes, resource, batch ]
      exporters: [ otlp ]

Paso 1: configurar el exportador OTLP

Primero, agregue un exportador OTLP a su archivo YAML de configuración del recolectorOpenTelemetry junto con su New Relic como encabezado.

exporters:
  otlp:
    endpoint: $OTEL_EXPORTER_OTLP_ENDPOINT
  headers: api-key: $NEW_RELIC_API_KEY

Paso 2: configurar el procesador por lotes

El procesador por lotes acepta tramos, métricas o registros y los coloca en lotes para facilitar la compresión de los datos y reducir la cantidad de solicitudes salientes del recolector.

processors:
  batch:

Paso 3: configurar el procesador de detección de recursos

El procesador resourcedetection obtiene información específica del host para agregar contexto adicional a los telemetry data que se procesan a través del recolector. En este ejemplo, utilizamos Google Kubernetes Engine (GKE) y Google Calcula Engine (GCE) para obtener metadatos específicos Google Cloud , que incluyen:

cloud.provider ("gcp")
cloud.platform ("gcp_compute_engine")
cloud.account.id
cloud.region
cloud.availability_zone
host.id
host.image.id
host.type

processors:
  resourcedetection:
Detectors: [ gke, gce ]

Paso 4: Configurar el procesador de atributos Kubernetes (general)

Cuando ejecutamos el procesador k8sattributes como parte del recolector OpenTelemetry ejecutándose como agente, detecta las direcciones IP del pod que envía telemetry data al agente recolector OpenTelemetry , usándolas para extraer metadatos pod . A continuación se muestra un ejemplo de manifiesto básico de Kubernetes con solo una sección de procesadores. Para implementar el recolector OpenTelemetry como DaemonSet, lea este ejemplo de manifiesto completo.

processors:
  k8sattributes:
    auth_type: "serviceAccount"
    passthrough: false
    filter:
      node_from_env_var: KUBE_NODE_NAME
    extract:
      metadata:
        - k8s.pod.name
        - k8s.pod.uid
        - k8s.deployment.name
        - k8s.cluster.name
        - k8s.namespace.name
        - k8s.node.name
        - k8s.pod.start_time
    pod_association:
      - from: resource_attribute
        name: k8s.pod.uid

Paso 5: Configurar el procesador de atributos Kubernetes (RBAC)

Debe agregar una configuración para el control de acceso basado en roles (RBAC). El procesador k8sattributes necesita permisos get, watch y list para los recursos de pod y espacio de nombres incluidos en los filtros configurados. Vea este ejemplo de cómo configurar el control de acceso basado en roles (RBAC) para que ClusterRole otorgue a ServiceAccount los permisos necesarios para todos los pods y espacios de nombres en el clúster.

Paso 6: Configurar el procesador de atributos Kubernetes (filtro de descubrimiento)

Al ejecutar el recolector como agente, debe aplicar un filtro de descubrimiento para que el procesador solo descubra el pod del mismo host en el que se está ejecutando. Si no utiliza un filtro, el uso de recursos puede ser innecesariamente alto, especialmente en clústeres muy grandes. Una vez aplicado el filtro, cada procesador solo consultará la Kubernetes API para el pod que se ejecuta en su propio nodo.

Para configurar el filtro, use la API descendente para inyectar el nombre del nodo como una variable de entorno en la sección pod env del archivo YAML de configuración del agente recolector OpenTelemetry (consulte GitHub para ver un ejemplo). Esto inyectará una nueva variable de entorno al contenedor del agente recolector OpenTelemetry . El valor será el nombre del nodo en el que se programó la ejecución del pod.

spec:
  containers:
  - env:
    - name: KUBE_NODE_NAME
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: spec.nodeName

Luego, puedes filtrar por el nodo con k8sattributes:

k8sattributes:
    filter:
      node_from_env_var: KUBE_NODE_NAME

Valida que tu configuración esté funcionando

Si ha vinculado correctamente sus datos OpenTelemetry con sus datos Kubernetes , debería poder ver atributos Kubernetes como k8s.cluster.name y k8s.deployment.name en sus intervalos dentro de la UI de rastreo distribuida.

Haga clic para ampliar la imagen:

¿Que sigue?

Ahora que ha conectado sus aplicaciones instrumentadas OpenTelemetrycon Kubernetes, consulte nuestra guía de mejores prácticas para obtener sugerencias para mejorar su uso de OpenTelemetry y New Relic.

También puede consultar esta publicación de blog, Correlacionar OpenTelemetry traza, métrica y registrar con datos de rendimiento Kubernetes para obtener más información sobre los pasos proporcionados anteriormente.