Rechercher

3.3. Configuration et déploiement de la collecte de données de traçage distribuées

download PDF

L'opérateur de collecte de données de traçage distribué Red Hat OpenShift utilise un fichier de définition de ressource personnalisée (CRD) qui définit l'architecture et les paramètres de configuration à utiliser lors de la création et du déploiement des ressources de collecte de données de traçage distribué Red Hat OpenShift. Vous pouvez soit installer la configuration par défaut, soit modifier le fichier pour mieux répondre aux exigences de votre entreprise.

3.3.1. Options de configuration du collecteur OpenTelemetry

Important

L'opérateur de collecte de données de traçage distribué de Red Hat OpenShift est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

Le collecteur OpenTelemetry est constitué de trois composants qui accèdent aux données télémétriques :

  • Receivers - Un récepteur, qui peut être de type "push" ou "pull", est la façon dont les données entrent dans le collecteur. En général, un récepteur accepte des données dans un format spécifique, les traduit dans le format interne et les transmet aux processeurs et aux exportateurs définis dans les pipelines applicables. Par défaut, aucun récepteur n'est configuré. Un ou plusieurs récepteurs doivent être configurés. Les récepteurs peuvent prendre en charge une ou plusieurs sources de données.
  • Processors - (Facultatif) Les processeurs sont exécutés sur les données entre leur réception et leur exportation. Par défaut, aucun processeur n'est activé. Les processeurs doivent être activés pour chaque source de données. Tous les processeurs ne prennent pas en charge toutes les sources de données. Selon la source de données, il peut être recommandé d'activer plusieurs processeurs. En outre, il est important de noter que l'ordre des processeurs est important.
  • Exporters - Un exportateur, qui peut être de type "push" ou "pull", permet d'envoyer des données à un ou plusieurs backends/destinations. Par défaut, aucun exportateur n'est configuré. Un ou plusieurs exportateurs doivent être configurés. Les exportateurs peuvent prendre en charge une ou plusieurs sources de données. Les exportateurs peuvent être livrés avec des paramètres par défaut, mais beaucoup nécessitent une configuration pour spécifier au moins la destination et les paramètres de sécurité.

Vous pouvez définir plusieurs instances de composants dans un fichier YAML de ressources personnalisées. Une fois configurés, ces composants doivent être activés au moyen de pipelines définis dans la section spec.config.service du fichier YAML. La meilleure pratique consiste à n'activer que les composants dont vous avez besoin.

exemple de fichier de ressources personnalisées du collecteur OpenTelemetry

apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: cluster-collector
  namespace: tracing-system
spec:
  mode: deployment
  config: |
    receivers:
      otlp:
        protocols:
          grpc:
          http:
    processors:
    exporters:
      jaeger:
        endpoint: jaeger-production-collector-headless.tracing-system.svc:14250
        tls:
          ca_file: "/var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt"
    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: []
          exporters: [jaeger]

Note

Si un composant est configuré, mais n'est pas défini dans la section service, il n'est pas activé.

Tableau 3.17. Paramètres utilisés par l'opérateur pour définir le collecteur OpenTelemetry
ParamètresDescriptionValeursDéfaut
récepteurs :

Un récepteur permet aux données d'entrer dans le collecteur. Par défaut, aucun récepteur n'est configuré. Il doit y avoir au moins un récepteur activé pour qu'une configuration soit considérée comme valide. Les récepteurs sont activés lorsqu'ils sont ajoutés à un pipeline.

otlp, jaeger

Aucun

receivers:
  otlp:

Les récepteurs oltp et jaeger sont livrés avec des paramètres par défaut, il suffit de spécifier le nom du récepteur pour le configurer.

  
des transformateurs :

Les processeurs traitent les données entre leur réception et leur exportation. Par défaut, aucun processeur n'est activé.

 

Aucun

exportateurs :

Un exportateur envoie des données à un ou plusieurs backends/destinations. Par défaut, aucun exportateur n'est configuré. Il doit y avoir au moins un exportateur activé pour qu'une configuration soit considérée comme valide. Les exportateurs sont activés lorsqu'ils sont ajoutés à un pipeline. Les exportateurs peuvent être livrés avec des paramètres par défaut, mais beaucoup nécessitent une configuration pour spécifier au moins la destination et les paramètres de sécurité.

logging, jaeger

Aucun

exporters:
 jaeger:
  endpoint:

Le point de terminaison de l'exportateur jaeger doit être de la forme <name>-collector-headless.<namespace>.svc, avec le nom et l'espace de noms du déploiement Jaeger, pour qu'une connexion sécurisée puisse être établie.

  
exporters:
 jaeger:
  tls:
   ca_file:

Chemin d'accès au certificat de l'autorité de certification. Pour un client, cela permet de vérifier le certificat du serveur. Pour un serveur, cela permet de vérifier les certificats des clients. Si empty utilise l'autorité de certification racine du système.

  
service:
  pipelines:

Les composants sont activés en les ajoutant à un pipeline sous services.pipeline.

  
service:
  pipelines:
    traces:
      receivers:

Vous activez les récepteurs pour le traçage en les ajoutant sous service.pipelines.traces.

 

Aucun

service:
  pipelines:
    traces:
      processors:

Vous activez les processeurs pour le traçage en les ajoutant sous service.pipelines.traces.

 

Aucun

service:
  pipelines:
    traces:
      exporters:

Vous activez les exportateurs pour le traçage en les ajoutant sous service.pipelines.traces.

 

Aucun

3.3.2. Valider votre déploiement

3.3.3. Accéder à la console Jaeger

Pour accéder à la console Jaeger, vous devez avoir soit Red Hat OpenShift Service Mesh, soit Red Hat OpenShift distributed tracing installé, et Red Hat OpenShift distributed tracing platform installé, configuré et déployé.

Le processus d'installation crée une route pour accéder à la console Jaeger.

Si vous connaissez l'URL de la console Jaeger, vous pouvez y accéder directement. Si vous ne connaissez pas l'URL, suivez les instructions suivantes.

Procédure à partir de la console OpenShift

  1. Connectez-vous à la console web de OpenShift Container Platform en tant qu'utilisateur disposant des droits cluster-admin. Si vous utilisez Red Hat OpenShift Dedicated, vous devez avoir un compte avec le rôle dedicated-admin.
  2. Naviguez jusqu'à Networking Routes.
  3. Sur la page Routes, sélectionnez le projet de plan de contrôle, par exemple tracing-system, dans le menu Namespace.

    La colonne Location affiche l'adresse liée à chaque itinéraire.

  4. Si nécessaire, utilisez le filtre pour trouver la route jaeger. Cliquez sur la route Location pour lancer la console.
  5. Cliquez sur Log In With OpenShift.

Procédure à partir du CLI

  1. Connectez-vous au CLI de OpenShift Container Platform en tant qu'utilisateur ayant le rôle cluster-admin. Si vous utilisez Red Hat OpenShift Dedicated, vous devez avoir un compte avec le rôle dedicated-admin.

    $ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
  2. Pour demander des détails sur l'itinéraire à l'aide de la ligne de commande, entrez la commande suivante. Dans cet exemple, tracing-system est l'espace de noms du plan de contrôle.

    $ export JAEGER_URL=$(oc get route -n tracing-system jaeger -o jsonpath='{.spec.host}')
  3. Lancez un navigateur et accédez à https://<JAEGER_URL>, où <JAEGER_URL> est l'itinéraire que vous avez découvert à l'étape précédente.
  4. Connectez-vous en utilisant le même nom d'utilisateur et le même mot de passe que ceux utilisés pour accéder à la console OpenShift Container Platform.
  5. Si vous avez ajouté des services au maillage de services et généré des traces, vous pouvez utiliser les filtres et le bouton Find Traces pour rechercher vos données de traces.

    Si vous validez l'installation de la console, il n'y a pas de données de trace à afficher.

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.