• EnglishEspañol日本語한국어Português
  • Inicia sesiónComenzar ahora

Te ofrecemos esta traducción automática para facilitar la lectura.

En caso de que haya discrepancias entre la versión en inglés y la versión traducida, se entiende que prevalece la versión en inglés. Visita esta página para obtener más información.

Crea una propuesta

Vincular la aplicación OpenTelemetry-instrumentada a Kubernetes

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

Luego 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 permite ver el panorama completo de sus telemetry data y colaborar entre equipos para lograr un tiempo medio de resolución (MTTR) más rápido para problemas en su entorno Kubernetes .

Cómo correlacionamos los datos

Este documento lo guía para habilitar su aplicación para inyectar metadatos específicos de 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 comenzar:

Antes de que empieces

Para completar con éxito los pasos siguientes, ya debe estar familiarizado con OpenTelemetry y Kubernetes y hacer lo siguiente:

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 2 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: Anexe 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 emplean 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:

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]

Siga estos pasos para configurar y desplegar el recolector OpenTelemetry como agente:

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

Configurar el procesador por lotes

El procesador por lotes acepta tramos, métricas o troncos y los coloca en lotes. Esto facilita la compresión de datos y reduce las solicitudes salientes del recolector.

processors:
batch:

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]

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

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 licencias get, watch y list para los recursos de pod y espacio de nombres incluidos en los filtros configurados. Este ejemplo muestra cómo configurar el control de acceso basado en roles (RBAC) para que ClusterRole otorgue a ServiceAccount las licencias necesarias para todos los pods y espacios de nombres en el clúster.

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 emplea 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 del agente recolector OpenTelemetry . Para ver un ejemplo, consulte GitHub. 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

Debería poder verificar que su configuración esté funcionando una vez que vinculó exitosamente sus datos OpenTelemetry con sus datos Kubernetes .

  1. Vaya a one.newrelic.com > All capabilities > APM & Services y seleccione su aplicación dentro de Services - OpenTelemetry.
  2. En la sección Monitor , haga clic en Service map.
  3. Vea la conexión entre su servicio OpenTelemetry y su clúster. A la derecha, verá el atributo Kubernetes como k8s.cluster.name, k8s.namespace.name y k8s.deployment.name como etiqueta.

Elige tu próximo paso

See our best practices guide

Aprenda cómo mejorar su uso de OpenTelemetry y New Relic.

Check out this blog post

Correlacionar OpenTelemetry traza, métrica y log con datos de rendimiento Kubernetes

Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.