Lier les applications instrumentées OpenTelemetryà Kubernetes

Si vous êtes un développeur exécutant des applications dans Kubernetes, vous pouvez utiliser New Relic pour comprendre comment l'Kubernetes infrastructure affecte vos OpenTelemetry applications instrumentées .

Après avoir effectué les étapes ci-dessous, vous pouvez utiliser l’interface utilisateur de New Relic pour corréler les métriques au niveau de l’application d’ OpenTelemetry avec les Kubernetes infrastructure métriques . Cela vous permet de voir l'ensemble de vos données télémétriques et de collaborer entre les équipes pour obtenir un délai moyen de résolution (MTTR) (MTTR) plus rapide pour les problèmes dans votre environnement Kubernetes .

Comment nous corrélons les données

Ce document vous guide dans la procédure permettant à votre application d'injecter des métadonnées spécifiques à infrastructuredans les données télémétriques. Le résultat est que l’interface utilisateur de New Relic est remplie d’informations exploitables. Voici les étapes à suivre pour commencer :

• Dans chaque conteneur d'application, définissez une variable d'environnement pour envoyer des données télémétriques au Collector.

• Déployez l' OpenTelemetry Collector en tant que DaemonSet en mode agent avec resourcedetection, resource, batch et k8sattributes Processeur pour injecter des métadonnées pertinentes (noms cluster, déploiement et espace de nommage).

Avant de commencer

Pour réussir les étapes ci-dessous, vous devez déjà être familiarisé avec OpenTelemetry et Kubernetes et avoir effectué les opérations suivantes :

• J'ai créé ces variables d'environnement :

  • OTEL_EXPORTER_OTLP_ENDPOINT:Consultez le point de terminaison New Relic OTLP pour plus d'informations.
  • NEW_RELIC_API_KEY:Voir l'API clé New Relic pour plus d'informations.

• Installez votre cluster Kubernetes avec OpenTelemetry.

• Instrumenté vos applications avec OpenTelemetry et envoyé avec succès des données à New Relic via le protocole OpenTelemetry (OTLP).

Si vous avez des questions générales sur l'utilisation de Collecter avec New Relic, consultez notre Introduction à OpenTelemetry Collector avec New Relic.

Configurez votre application pour envoyer des données télémétriques à OpenTelemetry Collector

Pour configurer cela, vous devez ajouter un snippet personnalisé à la section env de votre fichier YAML Kubernetes . L'exemple ci-dessous montre le snippet d'un exemple de microservices front-end (Frontend.yaml). Le snippet comprend 2 sections qui effectuent les tâches suivantes :

• Section 1: Assurez-vous que les données télémétriques sont transmises au Collector. Cela définit la variable d'environnement OTEL_EXPORTER_OTLP_ENDPOINT avec l'IP de l'hôte. Cela se fait en appelant l’API descendante pour extraire l’IP de l’hôte.

• Section 2: Joindre des métadonnées spécifiques à l’infrastructure. Pour ce faire, nous capturons metadata.uid à l’aide de l’API descendante et l’ajoutons à la variable d’environnement OTEL_RESOURCE_ATTRIBUTES . Cette variable d'environnement est utilisée par les processeurs OpenTelemetry Collector resourcedetection et du k8sattributes pour ajouter infrastructureun contexte supplémentaire spécifique à aux données télémétriques.

Pour chaque microservice instrumenté avec OpenTelemetry, ajoutez les lignes en surbrillance ci-dessous à la section env de votre manifeste :

# 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)"

Configurer et déployer le OpenTelemetry Collector

Nous vous recommandons d'utiliser le Collector en tant qu'agent sur chaque nœud d'un cluster Kubernetes. L'agent peut recevoir des données télémétriques, et enrichir les données télémétriques avec des métadonnées. Par exemple, le Collector peut ajouter des attributs personnalisés ou des informations infrastructure via le processeur, ainsi que gérer le traitement par lots, la nouvelle tentative, la compression et des fonctionnalités avancées supplémentaires qui sont gérées moins efficacement au niveau de instrumentation client.

Vous pouvez choisir l'une de ces options pour monitorer votre cluster:

• (Recommandé) Installez votre cluster Kubernetes en utilisant OpenTelemetry: Cette option déploie automatiquement le Collector en tant qu'agent. Tout fonctionnera immédiatement, vous aurez les métadonnées Kubernetes dans la télémétrie APM et les interfaces utilisateur Kubernetes.

• Configuration et déploiement manuels: Si vous préférez le configurer manuellement, suivez ces étapes :

  Configurer l'exportateur OTLP

  Ajoutez un exportateur OTLP à votre fichier YAML de configuration OpenTelemetry Collector avec votre New Relic clé de licencecomme en-tête.

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

  Copier

  Configurer le processeur par lots

  Le processeur par lots accepte les étendues, les métriques ou les logs et les place dans des lots. Cela facilite la compression des données et réduit requests sortantes du Collector.

  processors:
    batch:

  Copier

  Configurer le processeur de détection de ressources

  Le processeur resourcedetection obtient des informations spécifiques à l'hôte pour ajouter un contexte supplémentaire aux données télémétriques traitées via le Collector. Dans cet exemple, nous utilisons Google Kubernetes Engine (GKE) et Google Compute Engine (GCE) pour obtenir des métadonnées spécifiques Google Cloud , notamment :

  • 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]

    Copier

  Configurer l'attribut Kubernetes Processeur (général)

  Lorsque nous k8sattributes exécutons le processeur dans le cadre du OpenTelemetry Collector exécuté en tant qu'agent, il détecte les adresses IP des pods envoyant des données télémétriques à OpenTelemetry Collector l'agent , les utilisant pour extraire les pod métadonnées . Vous trouverez ci-dessous un exemple de manifeste Kubernetes de base avec uniquement une section Processeur. Pour déployer OpenTelemetry Collector en tant que DaemonSet, lisez cet exemple de manifeste complet.

  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

  Copier

  Configurer le processeur d'attribut Kubernetes (RBAC)

  Vous devez ajouter une configuration pour le contrôle d’accès basé sur les rôles (RBAC). Le processeur k8sattributes a besoin des autorisations get, watch et list pour les ressources pod et espace de nommage incluses dans les filtres configurés. Cet exemple montre comment configurer le contrôle d'accès basé sur les rôles (RBAC) pour ClusterRole afin de donner à ServiceAccount les autorisations nécessaires pour tous les pods et espaces de nommage du cluster.

  Configurer l'attribut Kubernetes Processeur (filtre de découverte)

  Lorsque vous exécutez le Collector en tant qu'agent, vous devez appliquer un filtre de découverte afin que le processeur ne découvre que les pods du même hôte sur lequel il s'exécute. Si vous n'utilisez pas de filtre, l'utilisation des ressources peut être inutilement élevée, en particulier sur un très grand cluster. Une fois le filtre appliqué, chaque processeur interrogera uniquement l'API Kubernetes pour les pods exécutés sur son propre nœud.

  Pour définir le filtre, utilisez l’API descendante pour injecter le nom du nœud en tant que variable d’environnement dans la section pod env du fichier YAML de configuration de l’agent OpenTelemetry Collector. Pour un exemple, voir le fichier otel-collector-config.yml sur GitHub. Cela injectera une nouvelle variable d’environnement dans le conteneur de l’agent OpenTelemetry Collector. La valeur sera le nom du nœud sur lequel le pod était prévu pour s'exécuter.

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

  Copier

  Ensuite, vous pouvez filtrer par le nœud avec le k8sattributes:

  k8sattributes:
    filter:
      node_from_env_var: KUBE_NODE_NAME

  Copier

Validez que vos configurations fonctionnent

Vous devriez être en mesure de vérifier que votre configuration fonctionne une fois que vous avez lié avec succès vos données OpenTelemetry à vos données Kubernetes .

1. Allez dans one.newrelic.com > All capabilities > APM & Services et sélectionnez votre application dans Services - OpenTelemetry.

2. Cliquez sur Kubernetes dans le volet de navigation de gauche.

Choisissez votre prochaine étape