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:
- En cada contenedor de aplicación, defina una variable de entorno para enviar telemetry data al recolector.
- Implementar el recolector OpenTelemetry como
DaemonSet
en modo agente con procesadoresresourcedetection
,resource
,batch
yk8sattributes
para inyectar metadatos relevantes (nombres de clúster, despliegue y namespace ).
Antes de que empieces
Para completar con éxito los pasos siguientes, ya debe estar familiarizado con OpenTelemetry y Kubernetes y hacer lo siguiente:
Creó estas variables de entorno:
OTEL_EXPORTER_OTLP_ENDPOINT
: Consulte el extremoNew Relic OTLP para obtener más información.NEW_RELIC_API_KEY
: Consulte New Relic clave de API para obtener más información.
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 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 entornoOTEL_RESOURCE_ATTRIBUTES
. Esta variable de entorno la emplean los procesadoresresourcedetection
yk8sattributes
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.yamlapiVersion: apps/v1kind: 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]
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 .
- Vaya a one.newrelic.com > All capabilities > APM & Services y seleccione su aplicación dentro de Services - OpenTelemetry.
- En la sección Monitor , haga clic en Service map.
- 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
yk8s.deployment.name
como etiqueta.