SupportConsoleDéveloppeursCommencer un essaiContact

3.2. Configurer et déployer le traçage distribué

L'opérateur de plateforme de traçage distribuée 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 la plateforme de traçage distribuée. Vous pouvez soit installer la configuration par défaut, soit modifier le fichier pour mieux répondre aux exigences de votre entreprise.

La plateforme de traçage distribuée Red Hat OpenShift dispose de stratégies de déploiement prédéfinies. Vous spécifiez une stratégie de déploiement dans le fichier de ressources personnalisées. Lorsque vous créez une instance de plateforme de traçage distribuée, l'opérateur utilise ce fichier de configuration pour créer les objets nécessaires au déploiement.

Fichier de ressources personnalisées Jaeger indiquant la stratégie de déploiement

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: MyConfigFile
spec:
  strategy: production 1

1
L'opérateur de plateforme de traçage distribuée Red Hat OpenShift prend actuellement en charge les stratégies de déploiement suivantes :

  • allInOne (Par défaut) - Cette stratégie est destinée au développement, aux tests et aux démonstrations ; elle n'est pas destinée à une utilisation en production. Les principaux composants du backend, l'agent, le collecteur et le service de requête, sont tous regroupés dans un seul exécutable qui est configuré, par défaut, pour utiliser le stockage en mémoire.

    Note

    Le stockage en mémoire n'est pas persistant, ce qui signifie que si l'instance de la plateforme de traçage distribuée s'arrête, redémarre ou est remplacée, vos données de traçage seront perdues. De plus, le stockage en mémoire ne peut pas être mis à l'échelle, puisque chaque module possède sa propre mémoire. Pour le stockage persistant, vous devez utiliser les stratégies production ou streaming, qui utilisent Elasticsearch comme stockage par défaut.

  • production - La stratégie de production est destinée aux environnements de production, où le stockage à long terme des données de traçage est important, et où une architecture plus évolutive et hautement disponible est nécessaire. Chacun des composants du backend est donc déployé séparément. L'agent peut être injecté en tant que sidecar dans l'application instrumentée. Les services Query et Collector sont configurés avec un type de stockage pris en charge - actuellement Elasticsearch. Plusieurs instances de chacun de ces composants peuvent être provisionnées si nécessaire à des fins de performance et de résilience.

  • streaming - La stratégie de diffusion en continu est conçue pour compléter la stratégie de production en fournissant une capacité de diffusion en continu qui se situe effectivement entre le collecteur et le stockage dorsal Elasticsearch. Cela permet de réduire la pression sur le stockage dorsal dans les situations de forte charge et permet à d'autres capacités de post-traitement des traces d'exploiter les données en temps réel directement à partir de la plateforme de diffusion en continu(AMQ Streams/ Kafka).

    Note

    La stratégie de streaming nécessite un abonnement Red Hat supplémentaire pour AMQ Streams.

Note

La stratégie de déploiement en continu n'est actuellement pas prise en charge sur les systèmes IBM z.

Note

Il y a deux façons d'installer et d'utiliser le traçage distribué de Red Hat OpenShift, en tant que partie d'un maillage de services ou en tant que composant autonome. Si vous avez installé le traçage distribué dans le cadre de Red Hat OpenShift Service Mesh, vous pouvez effectuer une configuration de base dans le cadre du ServiceMeshControlPlane, mais pour un contrôle complet, vous devez configurer un Jaeger CR et ensuite référencer votre fichier de configuration de traçage distribué dans le ServiceMeshControlPlane.

3.2.1. Déployer la stratégie par défaut de traçage distribué à partir de la console web

La définition de ressource personnalisée (CRD) définit la configuration utilisée lorsque vous déployez une instance de Red Hat OpenShift distributed tracing. La CRD par défaut est nommée jaeger-all-in-one-inmemory et elle est configurée avec des ressources minimales pour s'assurer que vous pouvez l'installer avec succès sur une installation OpenShift Container Platform par défaut. Vous pouvez utiliser cette configuration par défaut pour créer une instance de plateforme de traçage distribué Red Hat OpenShift qui utilise la stratégie de déploiement AllInOne, ou vous pouvez définir votre propre fichier de ressources personnalisé.

Note

Le stockage en mémoire n'est pas persistant. Si le pod Jaeger s'arrête, redémarre ou est remplacé, vos données de traçage seront perdues. Pour un stockage persistant, vous devez utiliser les stratégies production ou streaming, qui utilisent Elasticsearch comme stockage par défaut.

Conditions préalables

  • La plateforme de traçage distribuée Red Hat OpenShift Operator a été installée.
  • Vous avez passé en revue les instructions relatives à la personnalisation du déploiement.
  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

  1. Connectez-vous à la console web de OpenShift Container Platform en tant qu'utilisateur ayant le rôle cluster-admin.

  2. Créez un nouveau projet, par exemple tracing-system.

    Note

    Si vous effectuez l'installation dans le cadre du Service Mesh, les ressources de traçage distribuées doivent être installées dans le même espace de noms que la ressource ServiceMeshControlPlane, par exemple istio-system.

    1. Naviguez jusqu'à Home Projects.
    2. Cliquez sur Create Project.
    3. Saisissez tracing-system dans le champ Name.
    4. Cliquez sur Create.
  3. Naviguez jusqu'à Operators Installed Operators.
  4. Si nécessaire, sélectionnez tracing-system dans le menu Project. Il se peut que vous deviez attendre quelques instants pour que les opérateurs soient copiés dans le nouveau projet.
  5. Cliquez sur l'opérateur de la plateforme de traçage distribuée Red Hat OpenShift. Dans l'onglet Details, sous Provided APIs, l'opérateur fournit un lien unique.
  6. Sous Jaeger, cliquez sur Create Instance.
  7. Sur la page Create Jaeger, pour installer en utilisant les valeurs par défaut, cliquez sur Create pour créer l'instance de la plate-forme de traçage distribuée.
  8. Sur la page Jaegers, cliquez sur le nom de l'instance de la plate-forme de traçage distribuée, par exemple jaeger-all-in-one-inmemory.
  9. Sur la page Jaeger Details, cliquez sur l'onglet Resources. Attendez que le pod ait un statut de "Running" avant de continuer.

3.2.1.1. Déployer la stratégie par défaut de traçage distribué à partir de l'interface CLI

Suivez cette procédure pour créer une instance de plate-forme de traçage distribuée à partir de la ligne de commande.

Conditions préalables

  • L'opérateur de la plateforme de traçage distribuée Red Hat OpenShift a été installé et vérifié.
  • Vous avez passé en revue les instructions relatives à la personnalisation du déploiement.
  • Vous avez accès à l'OpenShift CLI (oc) qui correspond à votre version d'OpenShift Container Platform.
  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

  1. Connectez-vous au CLI de OpenShift Container Platform en tant qu'utilisateur ayant le rôle cluster-admin. 

    $ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:8443

  2. Créez un nouveau projet nommé tracing-system. 

    $ oc new-project tracing-system

  3. Créez un fichier de ressources personnalisé nommé jaeger.yaml qui contient le texte suivant :

    Exemple jaeger-all-in-one.yaml

    apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: jaeger-all-in-one-inmemory

  4. Exécutez la commande suivante pour déployer la plateforme de traçage distribuée : 

    $ oc create -n tracing-system -f jaeger.yaml

  5. Exécutez la commande suivante pour observer la progression des modules pendant le processus d'installation : 

    $ oc get pods -n tracing-system -w

    Une fois le processus d'installation terminé, vous devriez obtenir un résultat similaire à l'exemple suivant : 

    NAME                                         READY   STATUS    RESTARTS   AGE
jaeger-all-in-one-inmemory-cdff7897b-qhfdx   2/2     Running   0          24s

3.2.2. Déployer la stratégie de production de traçage distribué à partir de la console web

La stratégie de déploiement production est destinée aux environnements de production qui nécessitent une architecture plus évolutive et hautement disponible, et où le stockage à long terme des données de traçage est important.

Conditions préalables

  • L'opérateur OpenShift Elasticsearch a été installé.
  • La plateforme de traçage distribuée Red Hat OpenShift Operator a été installée.
  • Vous avez passé en revue les instructions relatives à la personnalisation du déploiement.
  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

  1. Connectez-vous à la console web de OpenShift Container Platform en tant qu'utilisateur ayant le rôle cluster-admin.

  2. Créez un nouveau projet, par exemple tracing-system.

    Note

    Si vous effectuez l'installation dans le cadre du Service Mesh, les ressources de traçage distribuées doivent être installées dans le même espace de noms que la ressource ServiceMeshControlPlane, par exemple istio-system.

    1. Naviguez jusqu'à Home Projects.
    2. Cliquez sur Create Project.
    3. Saisissez tracing-system dans le champ Name.
    4. Cliquez sur Create.
  3. Naviguez jusqu'à Operators Installed Operators.
  4. Si nécessaire, sélectionnez tracing-system dans le menu Project. Il se peut que vous deviez attendre quelques instants pour que les opérateurs soient copiés dans le nouveau projet.
  5. Cliquez sur l'opérateur de la plateforme de traçage distribuée Red Hat OpenShift. Dans l'onglet Overview, sous Provided APIs, l'opérateur fournit un lien unique.
  6. Sous Jaeger, cliquez sur Create Instance.

  7. Sur la page Create Jaeger, remplacez le texte YAML par défaut de all-in-one par votre configuration YAML de production, par exemple :

    Exemple de fichier jaeger-production.yaml avec Elasticsearch

    apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: jaeger-production
  namespace:
spec:
  strategy: production
  ingress:
    security: oauth-proxy
  storage:
    type: elasticsearch
    elasticsearch:
      nodeCount: 3
      redundancyPolicy: SingleRedundancy
    esIndexCleaner:
      enabled: true
      numberOfDays: 7
      schedule: 55 23 * * *
    esRollover:
      schedule: '*/30 * * * *'

  8. Cliquez sur Create pour créer l'instance de la plate-forme de traçage distribuée.
  9. Sur la page Jaegers, cliquez sur le nom de l'instance de la plate-forme de traçage distribuée, par exemple jaeger-prod-elasticsearch.
  10. Sur la page Jaeger Details, cliquez sur l'onglet Resources. Attendez que tous les pods aient un statut de "Running" avant de continuer.

3.2.2.1. Déployer la stratégie de production de traçage distribué à partir de l'interface de ligne de commande

Suivez cette procédure pour créer une instance de plate-forme de traçage distribuée à partir de la ligne de commande.

Conditions préalables

  • L'opérateur OpenShift Elasticsearch a été installé.
  • La plateforme de traçage distribuée Red Hat OpenShift Operator a été installée.
  • Vous avez passé en revue les instructions relatives à la personnalisation du déploiement.
  • Vous avez accès à l'OpenShift CLI (oc) qui correspond à votre version d'OpenShift Container Platform.
  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

  1. Connectez-vous au CLI de OpenShift Container Platform en tant qu'utilisateur ayant le rôle cluster-admin. 

    $ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:8443

  2. Créez un nouveau projet nommé tracing-system. 

    $ oc new-project tracing-system
  3. Créez un fichier de ressources personnalisé nommé jaeger-production.yaml qui contient le texte du fichier d'exemple de la procédure précédente.

  4. Exécutez la commande suivante pour déployer la plateforme de traçage distribuée : 

    $ oc create -n tracing-system -f jaeger-production.yaml

  5. Exécutez la commande suivante pour observer la progression des modules pendant le processus d'installation : 

    $ oc get pods -n tracing-system -w

    Une fois le processus d'installation terminé, vous devriez obtenir un résultat similaire à l'exemple suivant : 

    NAME                                                              READY   STATUS    RESTARTS   AGE
elasticsearch-cdm-jaegersystemjaegerproduction-1-6676cf568gwhlw   2/2     Running   0          10m
elasticsearch-cdm-jaegersystemjaegerproduction-2-bcd4c8bf5l6g6w   2/2     Running   0          10m
elasticsearch-cdm-jaegersystemjaegerproduction-3-844d6d9694hhst   2/2     Running   0          10m
jaeger-production-collector-94cd847d-jwjlj                        1/1     Running   3          8m32s
jaeger-production-query-5cbfbd499d-tv8zf                          3/3     Running   3          8m32s

3.2.3. Déploiement de la stratégie de traçage distribué en continu à partir de la console web

La stratégie de déploiement streaming est destinée aux environnements de production qui nécessitent une architecture plus évolutive et hautement disponible, et où le stockage à long terme des données de traçage est important.

La stratégie streaming offre une capacité de diffusion en continu entre le collecteur et le stockage Elasticsearch. Cela réduit la pression sur le stockage dans les situations de charge élevée et permet à d'autres capacités de post-traitement des traces d'exploiter les données en temps réel directement à partir de la plateforme de streaming Kafka.

Note

La stratégie de streaming nécessite un abonnement Red Hat supplémentaire pour AMQ Streams. Si vous n'avez pas d'abonnement AMQ Streams, contactez votre représentant commercial pour plus d'informations.

Note

La stratégie de déploiement en continu n'est actuellement pas prise en charge sur les systèmes IBM z.

Conditions préalables

  • L'opérateur AMQ Streams a été installé. Si vous utilisez la version 1.4.0 ou une version supérieure, vous pouvez utiliser l'auto-provisionnement. Sinon, vous devez créer l'instance Kafka.
  • La plateforme de traçage distribuée Red Hat OpenShift Operator a été installée.
  • Vous avez passé en revue les instructions relatives à la personnalisation du déploiement.
  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

  1. Connectez-vous à la console web de OpenShift Container Platform en tant qu'utilisateur ayant le rôle cluster-admin.

  2. Créez un nouveau projet, par exemple tracing-system.

    Note

    Si vous effectuez l'installation dans le cadre du Service Mesh, les ressources de traçage distribuées doivent être installées dans le même espace de noms que la ressource ServiceMeshControlPlane, par exemple istio-system.

    1. Naviguez jusqu'à Home Projects.
    2. Cliquez sur Create Project.
    3. Saisissez tracing-system dans le champ Name.
    4. Cliquez sur Create.
  3. Naviguez jusqu'à Operators Installed Operators.
  4. Si nécessaire, sélectionnez tracing-system dans le menu Project. Il se peut que vous deviez attendre quelques instants pour que les opérateurs soient copiés dans le nouveau projet.
  5. Cliquez sur l'opérateur de la plateforme de traçage distribuée Red Hat OpenShift. Dans l'onglet Overview, sous Provided APIs, l'opérateur fournit un lien unique.
  6. Sous Jaeger, cliquez sur Create Instance.
  7. Sur la page Create Jaeger, remplacez le texte YAML par défaut de all-in-one par votre configuration YAML de streaming, par exemple :

Exemple de fichier jaeger-streaming.yaml

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: jaeger-streaming
spec:
  strategy: streaming
  collector:
    options:
      kafka:
        producer:
          topic: jaeger-spans
          #Note: If brokers are not defined,AMQStreams 1.4.0+ will self-provision Kafka.
          brokers: my-cluster-kafka-brokers.kafka:9092
  storage:
    type: elasticsearch
  ingester:
    options:
      kafka:
        consumer:
          topic: jaeger-spans
          brokers: my-cluster-kafka-brokers.kafka:9092

  1. Cliquez sur Create pour créer l'instance de la plate-forme de traçage distribuée.
  2. Sur la page Jaegers, cliquez sur le nom de l'instance de la plate-forme de traçage distribuée, par exemple jaeger-streaming.
  3. Sur la page Jaeger Details, cliquez sur l'onglet Resources. Attendez que tous les pods aient un statut de "Running" avant de continuer.

3.2.3.1. Déployer la stratégie de streaming de traçage distribué à partir de l'interface de ligne de commande

Suivez cette procédure pour créer une instance de plate-forme de traçage distribuée à partir de la ligne de commande.

Conditions préalables

  • L'opérateur AMQ Streams a été installé. Si vous utilisez la version 1.4.0 ou une version supérieure, vous pouvez utiliser l'auto-provisionnement. Sinon, vous devez créer l'instance Kafka.
  • La plateforme de traçage distribuée Red Hat OpenShift Operator a été installée.
  • Vous avez passé en revue les instructions relatives à la personnalisation du déploiement.
  • Vous avez accès à l'OpenShift CLI (oc) qui correspond à votre version d'OpenShift Container Platform.
  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

  1. Connectez-vous au CLI de OpenShift Container Platform en tant qu'utilisateur ayant le rôle cluster-admin. 

    $ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:8443

  2. Créez un nouveau projet nommé tracing-system. 

    $ oc new-project tracing-system
  3. Créez un fichier de ressources personnalisé nommé jaeger-streaming.yaml qui contient le texte du fichier d'exemple de la procédure précédente.

  4. Exécutez la commande suivante pour déployer Jaeger : 

    $ oc create -n tracing-system -f jaeger-streaming.yaml

  5. Exécutez la commande suivante pour observer la progression des modules pendant le processus d'installation : 

    $ oc get pods -n tracing-system -w

    Une fois le processus d'installation terminé, vous devriez obtenir un résultat similaire à l'exemple suivant : 

    NAME                                                              READY   STATUS    RESTARTS   AGE
elasticsearch-cdm-jaegersystemjaegerstreaming-1-697b66d6fcztcnn   2/2     Running   0          5m40s
elasticsearch-cdm-jaegersystemjaegerstreaming-2-5f4b95c78b9gckz   2/2     Running   0          5m37s
elasticsearch-cdm-jaegersystemjaegerstreaming-3-7b6d964576nnz97   2/2     Running   0          5m5s
jaeger-streaming-collector-6f6db7f99f-rtcfm                       1/1     Running   0          80s
jaeger-streaming-entity-operator-6b6d67cc99-4lm9q                 3/3     Running   2          2m18s
jaeger-streaming-ingester-7d479847f8-5h8kc                        1/1     Running   0          80s
jaeger-streaming-kafka-0                                          2/2     Running   0          3m1s
jaeger-streaming-query-65bf5bb854-ncnc7                           3/3     Running   0          80s
jaeger-streaming-zookeeper-0                                      2/2     Running   0          3m39s

3.2.4. Valider votre déploiement

3.2.4.1. 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.

3.2.5. Personnaliser votre déploiement

3.2.5.1. Meilleures pratiques de déploiement

  • Les noms des instances de traçage distribuées Red Hat OpenShift doivent être uniques. Si vous souhaitez avoir plusieurs instances de plateforme de traçage distribuée Red Hat OpenShift et que vous utilisez des agents injectés sidecar, les instances de plateforme de traçage distribuée Red Hat OpenShift doivent avoir des noms uniques, et l'annotation d'injection doit explicitement spécifier le nom de l'instance de plateforme de traçage distribuée Red Hat OpenShift vers laquelle les données de traçage doivent être rapportées.

  • Si vous avez une implémentation multi-locataires et que les locataires sont séparés par des espaces de noms, déployez une instance de plateforme de traçage distribuée Red Hat OpenShift dans l'espace de noms de chaque locataire.

    • L'agent en tant que daemonset n'est pas pris en charge pour les installations multitenant ou Red Hat OpenShift Dedicated. L'agent en tant que sidecar est la seule configuration supportée pour ces cas d'utilisation.
  • Si vous installez le traçage distribué dans le cadre de Red Hat OpenShift Service Mesh, les ressources de traçage distribuées doivent être installées dans le même espace de noms que la ressource ServiceMeshControlPlane.

Pour plus d'informations sur la configuration du stockage persistant, voir Comprendre le stockage persistant et la rubrique de configuration appropriée pour l'option de stockage choisie.

3.2.5.2. Options de configuration par défaut du traçage distribué

La ressource personnalisée Jaeger (CR) définit l'architecture et les paramètres à utiliser lors de la création des ressources de la plate-forme de traçage distribuée. Vous pouvez modifier ces paramètres pour adapter la mise en œuvre de votre plate-forme de traçage distribuée aux besoins de votre entreprise.

Exemple de YAML générique Jaeger

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: name
spec:
  strategy: <deployment_strategy>
  allInOne:
    options: {}
    resources: {}
  agent:
    options: {}
    resources: {}
  collector:
    options: {}
    resources: {}
  sampling:
    options: {}
  storage:
    type:
    options: {}
  query:
    options: {}
    resources: {}
  ingester:
    options: {}
    resources: {}
  options: {}

Tableau 3.1. Paramètres Jaeger
ParamètresDescriptionValeursValeur par défaut

apiVersion:

 

Version de l'API à utiliser lors de la création de l'objet.

jaegertracing.io/v1

jaegertracing.io/v1

kind:

Définit le type d'objet Kubernetes à créer.

jaeger

 

metadata:

Données permettant d'identifier l'objet de manière unique, y compris une chaîne de caractères name, UID et, en option, namespace.

 

OpenShift Container Platform génère automatiquement le UID et complète le namespace avec le nom du projet où l'objet est créé.

name:

Nom de l'objet.

Le nom de l'instance de la plate-forme de traçage distribuée.

jaeger-all-in-one-inmemory

spec:

Spécification de l'objet à créer.

Contient tous les paramètres de configuration de votre instance de plateforme de traçage distribuée. Lorsqu'une définition commune à tous les composants Jaeger est requise, elle est définie sous le nœud spec. Lorsque la définition concerne un composant individuel, elle est placée sous le nœud spec/<component>.

N/A

strategy:

Stratégie de déploiement de Jaeger

allInOne, production, ou streaming

allInOne

allInOne:

Comme l'image allInOne déploie l'agent, le collecteur, la requête, l'ingestion et l'interface utilisateur Jaeger dans un seul pod, la configuration de ce déploiement doit imbriquer la configuration des composants sous le paramètre allInOne.

 
 

agent:

Options de configuration qui définissent l'agent.

 
 

collector:

Options de configuration qui définissent le collecteur Jaeger.

 
 

sampling:

Options de configuration qui définissent les stratégies d'échantillonnage pour le traçage.

 
 

storage:

Options de configuration qui définissent le stockage. Toutes les options liées au stockage doivent être placées sous storage, plutôt que sous allInOne ou sous d'autres options de composants.

 
 

query:

Options de configuration qui définissent le service Query.

 
 

ingester:

Options de configuration qui définissent le service Ingester.

 

L'exemple YAML suivant est le minimum requis pour créer un déploiement de plateforme de traçage distribuée Red Hat OpenShift en utilisant les paramètres par défaut.

Exemple minimum requis dist-tracing-all-in-one.yaml

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: jaeger-all-in-one-inmemory

3.2.5.3. Options de configuration du collecteur Jaeger

Le collecteur Jaeger est le composant responsable de la réception des intervalles capturés par le traceur et de leur écriture dans un stockage Elasticsearch persistant lors de l'utilisation de la stratégie production, ou dans des flux AMQ lors de l'utilisation de la stratégie streaming.

Les collecteurs sont sans état et de nombreuses instances de Jaeger Collector peuvent donc être exécutées en parallèle. Les collecteurs ne nécessitent pratiquement aucune configuration, à l'exception de l'emplacement du cluster Elasticsearch.

Tableau 3.2. Paramètres utilisés par l'opérateur pour définir le collecteur Jaeger
ParamètresDescriptionValeurs
collector:
  replicas:

Spécifie le nombre de répliques du collecteur à créer.

Entier, par exemple, 5

Tableau 3.3. Paramètres de configuration transmis au collecteur
ParamètresDescriptionValeurs
spec:
 collector:
  options: {}

Options de configuration qui définissent le collecteur Jaeger.

 
options:
  collector:
    num-workers:

Le nombre de travailleurs tirés de la file d'attente.

Entier, par exemple, 50 

options:
  collector:
    queue-size:

Taille de la file d'attente du collecteur.

Entier, par exemple, 2000 

options:
  kafka:
    producer:
      topic: jaeger-spans

Le paramètre topic identifie la configuration Kafka utilisée par le collecteur pour produire les messages et par l'ingérateur pour consommer les messages.

Label pour le producteur. 

options:
  kafka:
    producer:
      brokers: my-cluster-kafka-brokers.kafka:9092

Identifie la configuration Kafka utilisée par le collecteur pour produire les messages. Si les courtiers ne sont pas spécifiés, et que vous avez installé AMQ Streams 1.4.0, l'opérateur de la plateforme de traçage distribuée Red Hat OpenShift fournira lui-même Kafka.

 
options:
  log-level:

Niveau de journalisation pour le collecteur.

Valeurs possibles : debug, info, warn, error, fatal, panic.

3.2.5.4. Options de configuration de l'échantillonnage de traçage distribué

La plateforme de traçage distribuée Red Hat OpenShift Operator peut être utilisée pour définir les stratégies d'échantillonnage qui seront fournies aux traceurs qui ont été configurés pour utiliser un échantillonneur distant.

Toutes les traces sont générées, mais seules quelques-unes sont échantillonnées. L'échantillonnage d'une trace la marque pour un traitement et un stockage ultérieurs.

Note

Ceci n'est pas pertinent si une trace a été lancée par le proxy Envoy, car la décision d'échantillonnage est prise à ce niveau. La décision d'échantillonnage de Jaeger n'est pertinente que lorsque la trace est lancée par une application utilisant le client.

Lorsqu'un service reçoit une requête qui ne contient pas de contexte de trace, le client lance une nouvelle trace, lui attribue un identifiant aléatoire et prend une décision d'échantillonnage basée sur la stratégie d'échantillonnage actuellement installée. La décision d'échantillonnage se propage à toutes les demandes ultérieures de la trace, de sorte que les autres services ne prennent pas à nouveau la décision d'échantillonnage.

les bibliothèques de la plate-forme de traçage distribué prennent en charge les échantillonneurs suivants :

  • Probabilistic - L'échantillonneur prend une décision d'échantillonnage aléatoire avec une probabilité d'échantillonnage égale à la valeur de la propriété sampling.param. Par exemple, l'utilisation de sampling.param=0.1 permet d'échantillonner environ 1 trace sur 10.
  • Rate Limiting - L'échantillonneur utilise un limiteur de taux de leaky bucket pour s'assurer que les traces sont échantillonnées à un certain taux constant. Par exemple, l'utilisation de sampling.param=2.0 permet d'échantillonner les demandes au rythme de 2 traces par seconde.
Tableau 3.4. Options d'échantillonnage Jaeger
ParamètresDescriptionValeursValeur par défaut
spec:
 sampling:
  options: {}
    default_strategy:
    service_strategy:

Options de configuration qui définissent les stratégies d'échantillonnage pour le traçage.

 

Si vous ne fournissez pas de configuration, les collecteurs renverront la politique d'échantillonnage probabiliste par défaut avec une probabilité de 0,001 (0,1 %) pour tous les services. 

default_strategy:
  type:
service_strategy:
  type:

Stratégie d'échantillonnage à utiliser. Voir les descriptions ci-dessus.

Les valeurs valables sont probabilistic, et ratelimiting.

probabilistic 

default_strategy:
  param:
service_strategy:
  param:

Paramètres de la stratégie d'échantillonnage sélectionnée.

Valeurs décimales et entières (0, .1, 1, 10)

1

Cet exemple définit une stratégie d'échantillonnage par défaut qui est probabiliste, avec une probabilité de 50 % que les instances de la trace soient échantillonnées.

Exemple d'échantillonnage probabiliste

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: with-sampling
spec:
  sampling:
    options:
      default_strategy:
        type: probabilistic
        param: 0.5
      service_strategies:
        - service: alpha
          type: probabilistic
          param: 0.8
          operation_strategies:
            - operation: op1
              type: probabilistic
              param: 0.2
            - operation: op2
              type: probabilistic
              param: 0.4
        - service: beta
          type: ratelimiting
          param: 5

Si aucune configuration n'est fournie par l'utilisateur, la plate-forme de traçage distribuée utilise les paramètres suivants :

Échantillonnage par défaut

spec:
  sampling:
    options:
      default_strategy:
        type: probabilistic
        param: 1

3.2.5.5. Options de configuration de la mémoire de traçage distribuée

Vous configurez le stockage pour les services Collector, Ingester et Query à l'adresse spec.storage. Plusieurs instances de chacun de ces composants peuvent être provisionnées si nécessaire à des fins de performance et de résilience.

Tableau 3.5. Paramètres généraux de stockage utilisés par l'opérateur de la plateforme de traçage distribuée Red Hat OpenShift pour définir le stockage du traçage distribué
ParamètresDescriptionValeursValeur par défaut
spec:
  storage:
    type:

Type de stockage à utiliser pour le déploiement.

memory elasticsearch le stockage en mémoire n'est approprié que pour les environnements de développement, de test, de démonstration et de validation de principe, car les données ne persistent pas si le module est arrêté. Pour les environnements de production, la plateforme de traçage distribuée prend en charge Elasticsearch pour le stockage persistant.

memory 

storage:
  secretname:

Nom du secret, par exemple tracing-secret.

 

N/A 

storage:
  options: {}

Options de configuration qui définissent le stockage.

  
Tableau 3.6. Paramètres du nettoyeur d'index Elasticsearch
ParamètresDescriptionValeursValeur par défaut
storage:
  esIndexCleaner:
    enabled:

Lors de l'utilisation du stockage Elasticsearch, une tâche est créée par défaut pour nettoyer les anciennes traces de l'index. Ce paramètre permet d'activer ou de désactiver la tâche de nettoyage de l'index.

true/ false

true 

storage:
  esIndexCleaner:
    numberOfDays:

Nombre de jours à attendre avant de supprimer un index.

Valeur entière

7 

storage:
  esIndexCleaner:
    schedule:

Définit la fréquence de nettoyage de l'index Elasticsearch.

Cron expression

"55 23 * * *"

3.2.5.5.1. Auto-provisionnement d'une instance Elasticsearch

Lorsque vous déployez une ressource personnalisée Jaeger, l'opérateur de la plateforme de traçage distribuée Red Hat OpenShift utilise l'opérateur OpenShift Elasticsearch pour créer un cluster Elasticsearch basé sur la configuration fournie dans la section storage du fichier de la ressource personnalisée. L'opérateur de la plateforme de traçage distribuée Red Hat OpenShift provisionnera Elasticsearch si les configurations suivantes sont définies :

  • spec.storage:type est fixé à elasticsearch
  • spec.storage.elasticsearch.doNotProvision fixé à false
  • spec.storage.options.es.server-urls n'est pas définie, c'est-à-dire qu'il n'y a pas de connexion à une instance d'Elasticsearch qui n'a pas été provisionnée par l'Opérateur Red Hat Elasticsearch.

Lors du provisionnement d'Elasticsearch, l'opérateur de la plateforme de traçage distribuée Red Hat OpenShift définit la ressource personnalisée Elasticsearch name à la valeur de spec.storage.elasticsearch.name de la ressource personnalisée Jaeger. Si vous ne spécifiez pas de valeur pour spec.storage.elasticsearch.name, l'opérateur utilise elasticsearch.

Restrictions

  • Vous ne pouvez avoir qu'une seule plateforme de traçage distribuée avec instance Elasticsearch auto-provisionnée par espace de noms. Le cluster Elasticsearch doit être dédié à une seule instance de plateforme de traçage distribuée.
  • Il ne peut y avoir qu'un seul Elasticsearch par espace de noms.
Note

Si vous avez déjà installé Elasticsearch dans le cadre d'OpenShift Logging, l'opérateur de la plateforme de traçage distribuée Red Hat OpenShift peut utiliser l'opérateur OpenShift Elasticsearch installé pour provisionner le stockage.

Les paramètres de configuration suivants concernent une instance Elasticsearch self-provisioned, c'est-à-dire une instance créée par l'opérateur de la plateforme de traçage distribuée Red Hat OpenShift à l'aide de l'opérateur OpenShift Elasticsearch. Vous spécifiez les options de configuration pour Elasticsearch auto-provisionné sous spec:storage:elasticsearch dans votre fichier de configuration.

Tableau 3.7. Paramètres de configuration des ressources Elasticsearch
ParamètresDescriptionValeursValeur par défaut
elasticsearch:
  properties:
    doNotProvision:

À utiliser pour spécifier si une instance Elasticsearch doit être provisionnée par l'opérateur de la plateforme de traçage distribuée Red Hat OpenShift.

true/false

true 

elasticsearch:
  properties:
    name:

Nom de l'instance Elasticsearch. L'opérateur de la plateforme de traçage distribuée Red Hat OpenShift utilise l'instance Elasticsearch spécifiée dans ce paramètre pour se connecter à Elasticsearch.

chaîne de caractères

elasticsearch 

elasticsearch:
  nodeCount:

Nombre de nœuds Elasticsearch. Pour la haute disponibilité, utilisez au moins 3 nœuds. Ne pas utiliser 2 nœuds car un problème de "split brain" peut se produire.

Valeur entière. Par exemple, Preuve de concept = 1, Déploiement minimum =3

3 

elasticsearch:
  resources:
    requests:
      cpu:

Nombre d'unités centrales de traitement pour les requêtes, en fonction de la configuration de votre environnement.

Spécifié en cœurs ou en millicores, par exemple 200m, 0,5, 1. Par exemple, preuve de concept = 500m, déploiement minimum =1

1 

elasticsearch:
  resources:
    requests:
      memory:

Mémoire disponible pour les requêtes, en fonction de la configuration de votre environnement.

Spécifié en octets, par exemple 200Ki, 50Mi, 5Gi. Par exemple, preuve de concept = 1Gi, déploiement minimal = 16Gi*

16Gi 

elasticsearch:
  resources:
    limits:
      cpu:

Limitation du nombre d'unités centrales de traitement, en fonction de la configuration de votre environnement.

Spécifié en cœurs ou en millicores, par exemple 200m, 0,5, 1. Par exemple, preuve de concept = 500m, déploiement minimum =1

 
elasticsearch:
  resources:
    limits:
      memory:

Limite de mémoire disponible en fonction de la configuration de votre environnement.

Spécifié en octets, par exemple 200Ki, 50Mi, 5Gi. Par exemple, preuve de concept = 1Gi, déploiement minimal = 16Gi*

 
elasticsearch:
  redundancyPolicy:

La politique de réplication des données définit comment les shards Elasticsearch sont répliqués à travers les nœuds de données dans le cluster. S'il n'est pas spécifié, l'opérateur de la plateforme de traçage distribuée Red Hat OpenShift détermine automatiquement la réplication la plus appropriée en fonction du nombre de nœuds.

ZeroRedundancy(pas de répliques), SingleRedundancy(une réplique), MultipleRedundancy(chaque index est réparti sur la moitié des nœuds de données), FullRedundancy (chaque index est entièrement répliqué sur chaque nœud de données de la grappe).

 
elasticsearch:
  useCertManagement:

À utiliser pour spécifier si la plateforme de traçage distribuée doit ou non utiliser la fonctionnalité de gestion des certificats de Red Hat Elasticsearch Operator. Cette fonctionnalité a été ajoutée au sous-système de journalisation pour Red Hat OpenShift 5.2 dans OpenShift Container Platform 4.7 et est le paramètre préféré pour les nouveaux déploiements de Jaeger.

true/false

true

*Chaque nœud Elasticsearch peut fonctionner avec un paramètre de mémoire inférieur, mais cela n'est PAS recommandé pour les déploiements en production. Pour une utilisation en production, vous ne devriez pas avoir moins de 16Gi alloués à chaque pod par défaut, mais de préférence allouez autant que possible, jusqu'à 64Gi par pod.

Exemple de stockage de production

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  storage:
    type: elasticsearch
    elasticsearch:
      nodeCount: 3
      resources:
        requests:
          cpu: 1
          memory: 16Gi
        limits:
          memory: 16Gi

Exemple de stockage avec stockage persistant :

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  storage:
    type: elasticsearch
    elasticsearch:
      nodeCount: 1
      storage: 1
        storageClassName: gp2
        size: 5Gi
      resources:
        requests:
          cpu: 200m
          memory: 4Gi
        limits:
          memory: 4Gi
      redundancyPolicy: ZeroRedundancy

1
Configuration du stockage persistant. Dans ce cas, AWS gp2 avec une taille de 5Gi. Si aucune valeur n'est spécifiée, la plateforme de traçage distribuée utilise emptyDir. L'OpenShift Elasticsearch Operator fournit PersistentVolumeClaim et PersistentVolume qui ne sont pas supprimés avec l'instance de plateforme de traçage distribuée. Vous pouvez monter les mêmes volumes si vous créez une instance de plateforme de traçage distribuée avec le même nom et le même espace de noms.
3.2.5.5.2. Connexion à une instance Elasticsearch existante

Vous pouvez utiliser un cluster Elasticsearch existant pour le stockage avec le traçage distribué. Un cluster Elasticsearch existant, également connu sous le nom d'instance Elasticsearch external, est une instance qui n'a pas été installée par l'opérateur de plateforme de traçage distribué Red Hat OpenShift ou par l'opérateur Red Hat Elasticsearch.

Lorsque vous déployez une ressource personnalisée Jaeger, l'opérateur de la plateforme de traçage distribuée Red Hat OpenShift ne provisionnera pas Elasticsearch si les configurations suivantes sont définies :

  • spec.storage.elasticsearch.doNotProvision fixé à true
  • spec.storage.options.es.server-urls a une valeur
  • spec.storage.elasticsearch.name a une valeur, ou si le nom de l'instance Elasticsearch est elasticsearch.

L'opérateur de la plateforme de traçage distribuée Red Hat OpenShift utilise l'instance Elasticsearch spécifiée dans spec.storage.elasticsearch.name pour se connecter à Elasticsearch.

Restrictions

  • Vous ne pouvez pas partager ou réutiliser une instance Elasticsearch de la plateforme OpenShift Container avec une plateforme de traçage distribuée. Le cluster Elasticsearch doit être dédié à une seule instance de plateforme de traçage distribuée.
Note

Red Hat ne fournit pas de support pour votre instance Elasticsearch externe. Vous pouvez consulter la matrice des intégrations testées sur le portail client.

Les paramètres de configuration suivants s'appliquent à une instance Elasticsearch déjà existante, également appelée instance Elasticsearch external. Dans ce cas, vous spécifiez les options de configuration pour Elasticsearch sous spec:storage:options:es dans votre fichier de ressources personnalisé.

Tableau 3.8. Paramètres généraux de configuration de l'ES
ParamètresDescriptionValeursValeur par défaut
es:
  server-urls:

URL de l'instance Elasticsearch.

Le nom de domaine complet du serveur Elasticsearch.

http://elasticsearch.<namespace>.svc:9200 

es:
  max-doc-count:

Nombre maximal de documents à renvoyer à partir d'une requête Elasticsearch. Cette valeur s'applique également aux agrégations. Si vous définissez à la fois es.max-doc-count et es.max-num-spans, Elasticsearch utilisera la plus petite valeur des deux.

 

10000 

es:
  max-num-spans:

[Deprecated - Sera supprimé dans une prochaine version, utilisez es.max-doc-count à la place] Le nombre maximum de portées à récupérer à la fois, par requête, dans Elasticsearch. Si vous définissez à la fois es.max-num-spans et es.max-doc-count, Elasticsearch utilisera la plus petite valeur des deux.

 

10000 

es:
  max-span-age:

Le délai maximal de consultation pour les périodes dans Elasticsearch.

 

72h0m0s 

es:
  sniffer:

La configuration du renifleur pour Elasticsearch. Le client utilise le processus de reniflage pour trouver automatiquement tous les nœuds. Désactivé par défaut.

true/ false

false 

es:
  sniffer-tls-enabled:

Option permettant d'activer TLS lors du sniffing d'un cluster Elasticsearch. Le client utilise le processus de reniflage pour trouver automatiquement tous les nœuds. Désactivé par défaut

true/ false

false 

es:
  timeout:

Délai d'attente utilisé pour les requêtes. S'il est fixé à zéro, il n'y a pas de délai d'attente.

 

0s 

es:
  username:

Le nom d'utilisateur requis par Elasticsearch. L'authentification de base charge également l'AC si elle est spécifiée. Voir aussi es.password.

  
es:
  password:

Le mot de passe requis par Elasticsearch. Voir aussi es.username.

  
es:
  version:

La version majeure d'Elasticsearch. Si elle n'est pas spécifiée, la valeur sera auto-détectée à partir d'Elasticsearch.

 

0

Tableau 3.9. Paramètres de réplication des données ES
ParamètresDescriptionValeursValeur par défaut
es:
  num-replicas:

Le nombre de répliques par index dans Elasticsearch.

 

1 

es:
  num-shards:

Le nombre d'unités par index dans Elasticsearch.

 

5

Tableau 3.10. Paramètres de configuration de l'index ES
ParamètresDescriptionValeursValeur par défaut
es:
  create-index-templates:

Créer automatiquement des modèles d'index au démarrage de l'application lorsque le paramètre est fixé à true. Lorsque les modèles sont installés manuellement, le paramètre est fixé à false.

true/ false

true 

es:
  index-prefix:

Préfixe facultatif pour les index de la plate-forme de traçage distribuée. Par exemple, la valeur "production" crée des index nommés "production-tracing-*".

  
Tableau 3.11. Paramètres de configuration du processeur ES bulk
ParamètresDescriptionValeursValeur par défaut
es:
  bulk:
    actions:

Nombre de demandes pouvant être ajoutées à la file d'attente avant que le processeur de masse ne décide d'enregistrer les mises à jour sur le disque.

 

1000 

es:
  bulk:
    flush-interval:

time.Duration - Intervalle après lequel les demandes groupées sont validées, quels que soient les autres seuils. Pour désactiver l'intervalle de vidange du processeur de traitement en masse, fixer cette valeur à zéro.

 

200ms 

es:
  bulk:
    size:

Nombre d'octets que les demandes groupées peuvent occuper avant que le processeur de traitement groupé ne décide d'enregistrer les mises à jour sur le disque.

 

5000000 

es:
  bulk:
    workers:

Le nombre de travailleurs capables de recevoir et d'envoyer des requêtes en masse à Elasticsearch.

 

1

Tableau 3.12. Paramètres de configuration ES TLS
ParamètresDescriptionValeursValeur par défaut
es:
  tls:
    ca:

Chemin d'accès à un fichier d'autorité de certification (CA) TLS utilisé pour vérifier les serveurs distants.

 

Utilise par défaut le truststore du système. 

es:
  tls:
    cert:

Chemin d'accès à un fichier de certificat TLS, utilisé pour identifier ce processus auprès des serveurs distants.

  
es:
  tls:
    enabled:

Activer la sécurité de la couche transport (TLS) lors de la communication avec les serveurs distants. Cette option est désactivée par défaut.

true/ false

false 

es:
  tls:
    key:

Chemin d'accès à un fichier de clé privée TLS, utilisé pour identifier ce processus auprès des serveurs distants.

  
es:
  tls:
    server-name:

Remplacer le nom du serveur TLS prévu dans le certificat des serveurs distants.

  
es:
  token-file:

Chemin d'accès au fichier contenant le jeton du porteur. Cet indicateur charge également le fichier de l'autorité de certification (CA) s'il est spécifié.

  
Tableau 3.13. Paramètres de configuration de l'archive ES
ParamètresDescriptionValeursValeur par défaut
es-archive:
  bulk:
    actions:

Nombre de demandes pouvant être ajoutées à la file d'attente avant que le processeur de masse ne décide d'enregistrer les mises à jour sur le disque.

 

0 

es-archive:
  bulk:
    flush-interval:

time.Duration - Intervalle après lequel les demandes groupées sont validées, quels que soient les autres seuils. Pour désactiver l'intervalle de vidange du processeur de traitement en masse, fixer cette valeur à zéro.

 

0s 

es-archive:
  bulk:
    size:

Nombre d'octets que les demandes groupées peuvent occuper avant que le processeur de traitement groupé ne décide d'enregistrer les mises à jour sur le disque.

 

0 

es-archive:
  bulk:
    workers:

Le nombre de travailleurs capables de recevoir et d'envoyer des requêtes en masse à Elasticsearch.

 

0 

es-archive:
  create-index-templates:

Créer automatiquement des modèles d'index au démarrage de l'application lorsque le paramètre est fixé à true. Lorsque les modèles sont installés manuellement, le paramètre est fixé à false.

true/ false

false 

es-archive:
  enabled:

Permettre un stockage supplémentaire.

true/ false

false 

es-archive:
  index-prefix:

Préfixe facultatif pour les index de la plate-forme de traçage distribuée. Par exemple, la valeur "production" crée des index nommés "production-tracing-*".

  
es-archive:
  max-doc-count:

Nombre maximal de documents à renvoyer à partir d'une requête Elasticsearch. Cette valeur s'applique également aux agrégations.

 

0 

es-archive:
  max-num-spans:

[Deprecated - Sera supprimé dans une prochaine version, utilisez es-archive.max-doc-count à la place] Le nombre maximum d'étendues à récupérer à la fois, par requête, dans Elasticsearch.

 

0 

es-archive:
  max-span-age:

Le délai maximal de consultation pour les périodes dans Elasticsearch.

 

0s 

es-archive:
  num-replicas:

Le nombre de répliques par index dans Elasticsearch.

 

0 

es-archive:
  num-shards:

Le nombre d'unités par index dans Elasticsearch.

 

0 

es-archive:
  password:

Le mot de passe requis par Elasticsearch. Voir aussi es.username.

  
es-archive:
  server-urls:

La liste des serveurs Elasticsearch, séparée par des virgules. Les serveurs doivent être spécifiés sous forme d'URL complètes, par exemple, http://localhost:9200.

  
es-archive:
  sniffer:

La configuration du renifleur pour Elasticsearch. Le client utilise le processus de reniflage pour trouver automatiquement tous les nœuds. Désactivé par défaut.

true/ false

false 

es-archive:
  sniffer-tls-enabled:

Option permettant d'activer TLS lors du sniffing d'un cluster Elasticsearch. Le client utilise le processus de reniflage pour trouver automatiquement tous les nœuds. Cette option est désactivée par défaut.

true/ false

false 

es-archive:
  timeout:

Délai d'attente utilisé pour les requêtes. S'il est fixé à zéro, il n'y a pas de délai d'attente.

 

0s 

es-archive:
  tls:
    ca:

Chemin d'accès à un fichier d'autorité de certification (CA) TLS utilisé pour vérifier les serveurs distants.

 

Utilise par défaut le truststore du système. 

es-archive:
  tls:
    cert:

Chemin d'accès à un fichier de certificat TLS, utilisé pour identifier ce processus auprès des serveurs distants.

  
es-archive:
  tls:
    enabled:

Activer la sécurité de la couche transport (TLS) lors de la communication avec les serveurs distants. Cette option est désactivée par défaut.

true/ false

false 

es-archive:
  tls:
    key:

Chemin d'accès à un fichier de clé privée TLS, utilisé pour identifier ce processus auprès des serveurs distants.

  
es-archive:
  tls:
    server-name:

Remplacer le nom du serveur TLS prévu dans le certificat des serveurs distants.

  
es-archive:
  token-file:

Chemin d'accès au fichier contenant le jeton du porteur. Cet indicateur charge également le fichier de l'autorité de certification (CA) s'il est spécifié.

  
es-archive:
  username:

Le nom d'utilisateur requis par Elasticsearch. L'authentification de base charge également l'AC si elle est spécifiée. Voir aussi es-archive.password.

  
es-archive:
  version:

La version majeure d'Elasticsearch. Si elle n'est pas spécifiée, la valeur sera auto-détectée à partir d'Elasticsearch.

 

0

Exemple de stockage avec des montages de volumes

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  storage:
    type: elasticsearch
    options:
      es:
        server-urls: https://quickstart-es-http.default.svc:9200
        index-prefix: my-prefix
        tls:
          ca: /es/certificates/ca.crt
    secretName: tracing-secret
  volumeMounts:
    - name: certificates
      mountPath: /es/certificates/
      readOnly: true
  volumes:
    - name: certificates
      secret:
        secretName: quickstart-es-http-certs-public

L'exemple suivant montre un Jaeger CR utilisant un cluster Elasticsearch externe avec un certificat TLS CA monté à partir d'un volume et un utilisateur/mot de passe stocké dans un secret.

Exemple d'Elasticsearch externe :

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  storage:
    type: elasticsearch
    options:
      es:
        server-urls: https://quickstart-es-http.default.svc:9200 1
        index-prefix: my-prefix
        tls: 2
          ca: /es/certificates/ca.crt
    secretName: tracing-secret 3
  volumeMounts: 4
    - name: certificates
      mountPath: /es/certificates/
      readOnly: true
  volumes:
    - name: certificates
      secret:
        secretName: quickstart-es-http-certs-public

1
URL du service Elasticsearch fonctionnant dans l'espace de noms par défaut.
2
Configuration TLS. Dans ce cas, il s'agit uniquement du certificat de l'autorité de certification, mais il peut également contenir es.tls.key et es.tls.cert lors de l'utilisation de TLS mutuel.
3
Secret qui définit les variables d'environnement ES_PASSWORD et ES_USERNAME. Créé par kubectl create secret generic tracing-secret --from-literal=ES_PASSWORD=changeme --from-literal=ES_USERNAME=elastic
4
Les montages de volumes et les volumes qui sont montés dans tous les composants de stockage.

3.2.5.6. Gestion des certificats avec Elasticsearch

Vous pouvez créer et gérer des certificats à l'aide de l'Opérateur Red Hat Elasticsearch. La gestion des certificats à l'aide de Red Hat Elasticsearch Operator vous permet également d'utiliser un seul cluster Elasticsearch avec plusieurs collecteurs Jaeger.

Important

La gestion des certificats avec Elasticsearch 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.

À partir de la version 2.4, l'opérateur de la plateforme de traçage distribuée Red Hat OpenShift délègue la création de certificats à l'opérateur Red Hat Elasticsearch en utilisant les annotations suivantes dans la ressource personnalisée Elasticsearch :

  • logging.openshift.io/elasticsearch-cert-management: "true"
  • logging.openshift.io/elasticsearch-cert.jaeger-<shared-es-node-name>: "user.jaeger"
  • logging.openshift.io/elasticsearch-cert.curator-<shared-es-node-name>: "system.logging.curator"

Où <shared-es-node-name> est le nom du nœud Elasticsearch. Par exemple, si vous créez un nœud Elasticsearch nommé custom-es, votre ressource personnalisée pourrait ressembler à l'exemple suivant.

Exemple de CR Elasticsearch montrant les annotations

apiVersion: logging.openshift.io/v1
kind: Elasticsearch
metadata:
  annotations:
    logging.openshift.io/elasticsearch-cert-management: "true"
    logging.openshift.io/elasticsearch-cert.jaeger-custom-es: "user.jaeger"
    logging.openshift.io/elasticsearch-cert.curator-custom-es: "system.logging.curator"
  name: custom-es
spec:
  managementState: Managed
  nodeSpec:
    resources:
      limits:
        memory: 16Gi
      requests:
        cpu: 1
        memory: 16Gi
  nodes:
    - nodeCount: 3
      proxyResources: {}
      resources: {}
      roles:
        - master
        - client
        - data
      storage: {}
  redundancyPolicy: ZeroRedundancy

Conditions préalables

  • OpenShift Container Platform 4.7
  • sous-système de journalisation pour Red Hat OpenShift 5.2
  • Le nœud Elasticsearch et les instances Jaeger doivent être déployés dans le même espace de noms. Par exemple, tracing-system.

Vous activez la gestion des certificats en définissant spec.storage.elasticsearch.useCertManagement sur true dans la ressource personnalisée Jaeger.

Exemple montrant useCertManagement

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: jaeger-prod
spec:
  strategy: production
  storage:
    type: elasticsearch
    elasticsearch:
      name: custom-es
      doNotProvision: true
      useCertManagement: true

L'opérateur de la plateforme de traçage distribuée Red Hat OpenShift définit la ressource personnalisée Elasticsearch name à la valeur de spec.storage.elasticsearch.name de la ressource personnalisée Jaeger lors du provisionnement d'Elasticsearch.

Les certificats sont fournis par l'opérateur Red Hat Elasticsearch et l'opérateur de la plateforme de traçage distribuée Red Hat OpenShift injecte les certificats.

3.2.5.7. Options de configuration des requêtes

Query est un service qui récupère les traces du stockage et héberge l'interface utilisateur pour les afficher.

Tableau 3.14. Paramètres utilisés par l'opérateur de la plateforme de traçage distribuée Red Hat OpenShift pour définir la requête
ParamètresDescriptionValeursValeur par défaut
spec:
  query:
    replicas:

Spécifie le nombre de répliques de requêtes à créer.

Entier, par exemple, 2

 
Tableau 3.15. Paramètres de configuration transmis à la requête
ParamètresDescriptionValeursValeur par défaut
spec:
  query:
    options: {}

Options de configuration qui définissent le service Query.

  
options:
  log-level:

Niveau de journalisation pour Query.

Valeurs possibles : debug, info, warn, error, fatal, panic.

 
options:
  query:
    base-path:

Le chemin de base de toutes les routes HTTP de jaeger-query peut être défini à une valeur non racine, par exemple, /jaeger fera commencer toutes les URL de l'interface utilisateur par /jaeger. Cela peut s'avérer utile lorsque jaeger-query est exécuté derrière un proxy inverse.

/<path>

 

Exemple de configuration d'une requête

apiVersion: jaegertracing.io/v1
kind: "Jaeger"
metadata:
  name: "my-jaeger"
spec:
  strategy: allInOne
  allInOne:
    options:
      log-level: debug
      query:
        base-path: /jaeger

3.2.5.8. Options de configuration de l'ingestionur

Ingester est un service qui lit à partir d'un sujet Kafka et écrit dans le backend de stockage Elasticsearch. Si vous utilisez les stratégies de déploiement allInOne ou production, vous n'avez pas besoin de configurer le service Ingester.

Tableau 3.16. Paramètres du Jaeger transmis à l'injecteur
ParamètresDescriptionValeurs
spec:
  ingester:
    options: {}

Options de configuration qui définissent le service Ingester.

 
options:
  deadlockInterval:

Spécifie l'intervalle, en secondes ou en minutes, pendant lequel l'intégrateur doit attendre un message avant de s'arrêter. L'intervalle d'impasse est désactivé par défaut (défini sur 0), afin d'éviter que l'ingester ne se termine lorsqu'aucun message n'arrive lors de l'initialisation du système.

Minutes et secondes, par exemple 1m0s. La valeur par défaut est 0. 

options:
  kafka:
    consumer:
      topic:

Le paramètre topic identifie la configuration Kafka utilisée par le collecteur pour produire les messages et par l'ingérant pour consommer les messages.

Étiquette destinée au consommateur. Par exemple, jaeger-spans. 

options:
  kafka:
    consumer:
      brokers:

Identifie la configuration Kafka utilisée par l'ingester pour consommer les messages.

Label pour le courtier, par exemple, my-cluster-kafka-brokers.kafka:9092. 

options:
  log-level:

Niveau de journalisation pour l'ingérant.

Valeurs possibles : debug, info, warn, error, fatal, dpanic, panic.

Exemple de collecteur et d'ingérateur de flux

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-streaming
spec:
  strategy: streaming
  collector:
    options:
      kafka:
        producer:
          topic: jaeger-spans
          brokers: my-cluster-kafka-brokers.kafka:9092
  ingester:
    options:
      kafka:
        consumer:
          topic: jaeger-spans
          brokers: my-cluster-kafka-brokers.kafka:9092
      ingester:
        deadlockInterval: 5
  storage:
    type: elasticsearch
    options:
      es:
        server-urls: http://elasticsearch:9200

3.2.6. Injection des side-cars

La plateforme de traçage distribuée Red Hat OpenShift s'appuie sur un sidecar de proxy dans le pod de l'application pour fournir l'agent. L'opérateur de la plateforme de traçage distribuée Red Hat OpenShift peut injecter des sidecars d'agent dans les charges de travail de déploiement. Vous pouvez activer l'injection automatique de sidecars ou la gérer manuellement.

3.2.6.1. Injection automatique de sidecars

L'opérateur de la plateforme de traçage distribuée Red Hat OpenShift peut injecter des sidecars de l'agent Jaeger dans les charges de travail de déploiement. Pour activer l'injection automatique de sidecars, ajoutez l'ensemble d'annotations sidecar.jaegertracing.io/inject à la chaîne true ou au nom de l'instance de la plate-forme de traçage distribuée qui est renvoyé par l'exécution de $ oc get jaegers. Lorsque vous spécifiez true, il ne doit y avoir qu'une seule instance de plate-forme de traçage distribuée pour le même espace de noms que le déploiement, sinon l'opérateur ne peut pas déterminer l'instance de plate-forme de traçage distribuée à utiliser. Un nom d'instance de plate-forme de traçage distribuée spécifique sur un déploiement a une priorité plus élevée que true appliqué à son espace de noms.

L'extrait suivant montre une application simple qui injectera un sidecar, l'agent pointant vers l'instance unique de plate-forme de traçage distribuée disponible dans le même espace de noms :

Exemple d'injection automatique du side-car

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  annotations:
    "sidecar.jaegertracing.io/inject": "true" 1
spec:
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: acme/myapp:myversion

1
Il s'agit soit de la chaîne true, soit du nom de l'instance Jaeger.

Lorsque le sidecar est injecté, l'agent est alors accessible à son emplacement par défaut sur localhost.

3.2.6.2. Injection manuelle des side-cars

L'opérateur de la plateforme de traçage distribuée Red Hat OpenShift peut uniquement injecter automatiquement les sidecars de l'agent Jaeger dans les charges de travail de déploiement. Pour les types de contrôleurs autres que Deployments, tels que StatefulSets`and `DaemonSets, vous pouvez définir manuellement le sidecar de l'agent Jaeger dans votre spécification.

L'extrait suivant montre la définition manuelle que vous pouvez inclure dans la section des conteneurs pour un side-car d'agent Jaeger :

Exemple de définition d'un side-car StatefulSet

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: example-statefulset
  namespace: example-ns
  labels:
    app: example-app
spec:

    spec:
      containers:
        - name: example-app
          image: acme/myapp:myversion
          ports:
            - containerPort: 8080
              protocol: TCP
        - name: jaeger-agent
          image: registry.redhat.io/distributed-tracing/jaeger-agent-rhel7:<version>
           # The agent version must match the Operator version
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 5775
              name: zk-compact-trft
              protocol: UDP
            - containerPort: 5778
              name: config-rest
              protocol: TCP
            - containerPort: 6831
              name: jg-compact-trft
              protocol: UDP
            - containerPort: 6832
              name: jg-binary-trft
              protocol: UDP
            - containerPort: 14271
              name: admin-http
              protocol: TCP
          args:
            - --reporter.grpc.host-port=dns:///jaeger-collector-headless.example-ns:14250
            - --reporter.type=grpc

L'agent est alors accessible à son emplacement par défaut sur localhost.

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.