SupportConsoleDéveloppeursCommencer un essaiContact

1.26. Référence de la configuration Jaeger

Lorsque l'opérateur Service Mesh déploie la ressource ServiceMeshControlPlane, il peut également créer des ressources pour le traçage distribué. Service Mesh utilise Jaeger pour le traçage distribué.

1.26.1. Activation et désactivation du traçage

Vous activez le traçage distribué en spécifiant un type de traçage et un taux d'échantillonnage dans la ressource ServiceMeshControlPlane.

Paramètres par défaut de all-in-one Jaeger

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  version: v2.3
  tracing:
    sampling: 100
    type: Jaeger

Actuellement, le seul type de traçage pris en charge est Jaeger.

Jaeger est activé par défaut. Pour désactiver le traçage, définissez type sur None.

Le taux d'échantillonnage détermine la fréquence à laquelle le proxy Envoy génère une trace. Vous pouvez utiliser l'option de taux d'échantillonnage pour contrôler le pourcentage de requêtes qui sont rapportées à votre système de traçage. Vous pouvez configurer ce paramètre en fonction de votre trafic dans le maillage et de la quantité de données de traçage que vous souhaitez collecter. Vous configurez sampling sous la forme d'un nombre entier échelonné représentant des incréments de 0,01 %. Par exemple, la valeur 10 échantillonne 0,1 % des traces, la valeur 500 échantillonne 5 % des traces et la valeur 10000 échantillonne 100 % des traces.

Note

L'option de configuration de l'échantillonnage SMCP contrôle le taux d'échantillonnage Envoy. Vous configurez le taux d'échantillonnage de la trace Jaeger dans la ressource personnalisée Jaeger.

1.26.2. Spécification de la configuration de Jaeger dans le SMCP

Vous configurez Jaeger dans la section addons de la ressource ServiceMeshControlPlane. Cependant, il existe certaines limites à ce que vous pouvez configurer dans le SMCP.

Lorsque le SMCP transmet des informations de configuration à l'opérateur de la plateforme de traçage distribuée Red Hat OpenShift, il déclenche l'une des trois stratégies de déploiement : allInOne, production, ou streaming.

1.26.3. Déployer la plateforme de traçage distribuée

La plate-forme de traçage distribué 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 (CR) Jaeger. Lorsque vous créez une instance de la plate-forme de traçage distribuée, l'opérateur de plate-forme de traçage distribuée Red Hat OpenShift utilise ce fichier de configuration pour créer les objets nécessaires au déploiement.

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 et ne doit pas être utilisée en production. Les principaux composants du back-end, 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. Vous pouvez configurer cette stratégie de déploiement dans le SMCP.

    Note

    Le stockage en mémoire n'est pas persistant, ce qui signifie que si l'instance Jaeger 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. Chaque composant back-end 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, qui est actuellement Elasticsearch. Plusieurs instances de chacun de ces composants peuvent être provisionnées si nécessaire à des fins de performance et de résilience. Vous pouvez configurer cette stratégie de déploiement dans le SMCP, mais pour qu'elle soit entièrement personnalisée, vous devez spécifier votre configuration dans le Jaeger CR et la relier au SMCP.
  • 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 entre le collecteur et le stockage dorsal Elasticsearch. Cela permet de réduire la pression sur le stockage dorsal 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 diffusion en continu(AMQ Streams/Kafka). Vous ne pouvez pas configurer cette stratégie de déploiement dans le SMCP ; vous devez configurer un Jaeger CR et le relier au SMCP.
Note

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

1.26.3.1. Déploiement par défaut de la plate-forme de traçage distribuée

Si vous ne spécifiez pas d'options de configuration Jaeger, la ressource ServiceMeshControlPlane utilisera par défaut la stratégie de déploiement Jaeger allInOne. Lorsque vous utilisez la stratégie de déploiement par défaut allInOne, définissez spec.addons.jaeger.install.storage.type sur Memory. Vous pouvez accepter les valeurs par défaut ou spécifier des options de configuration supplémentaires sous install.

Paramètres Jaeger par défaut du plan de contrôle (mémoire)

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  version: v2.3
  tracing:
    sampling: 10000
    type: Jaeger
  addons:
    jaeger:
      name: jaeger
      install:
        storage:
          type: Memory

1.26.3.2. Déploiement d'une plate-forme de traçage distribuée en production (minimale)

Pour utiliser les paramètres par défaut de la stratégie de déploiement production, définissez spec.addons.jaeger.install.storage.type sur Elasticsearch et spécifiez des options de configuration supplémentaires sous install. Notez que le SMCP ne prend en charge que la configuration des ressources Elasticsearch et du nom de l'image.

Paramètres Jaeger par défaut du plan de contrôle (Elasticsearch)

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  version: v2.3
  tracing:
    sampling: 10000
    type: Jaeger
  addons:
    jaeger:
      name: jaeger  #name of Jaeger CR
      install:
        storage:
          type: Elasticsearch
        ingress:
          enabled: true
  runtime:
    components:
      tracing.jaeger.elasticsearch: # only supports resources and image name
        container:
          resources: {}

1.26.3.3. Déploiement d'une plateforme de traçage distribuée en production (entièrement personnalisée)

Le SMCP ne prend en charge que des paramètres Elasticsearch minimaux. Pour personnaliser entièrement votre environnement de production et accéder à tous les paramètres de configuration d'Elasticsearch, utilisez la ressource personnalisée (CR) Jaeger pour configurer Jaeger.

Créez et configurez votre instance Jaeger et donnez à spec.addons.jaeger.name le nom de l'instance Jaeger, dans cet exemple : MyJaegerInstance.

Plan de contrôle avec production Jaeger CR liée

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  version: v2.3
  tracing:
    sampling: 1000
    type: Jaeger
  addons:
    jaeger:
      name: MyJaegerInstance #name of Jaeger CR
      install:
        storage:
          type: Elasticsearch
        ingress:
          enabled: true

1.26.3.4. Déploiement de Jaeger en streaming

Pour utiliser la stratégie de déploiement streaming, vous devez d'abord créer et configurer votre instance Jaeger, puis attribuer à spec.addons.jaeger.name le nom de l'instance Jaeger, dans cet exemple : MyJaegerInstance.

Plan de contrôle avec flux Jaeger CR lié

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  version: v2.3
  tracing:
    sampling: 1000
    type: Jaeger
  addons:
    jaeger:
      name: MyJaegerInstance  #name of Jaeger CR

1.26.4. Spécifier la configuration de Jaeger dans une ressource personnalisée Jaeger

Vous pouvez personnaliser entièrement votre déploiement Jaeger en configurant Jaeger dans la ressource personnalisée Jaeger (CR) plutôt que dans la ressource ServiceMeshControlPlane (SMCP). Cette configuration est parfois appelée "Jaeger externe", car la configuration est spécifiée en dehors du SMCP.

Note

Vous devez déployer le SMCP et Jaeger CR dans le même espace de noms. Par exemple, istio-system.

Vous pouvez configurer et déployer une instance Jaeger autonome, puis spécifier le site name de la ressource Jaeger comme valeur de spec.addons.jaeger.name dans la ressource SMCP. S'il existe une CR Jaeger correspondant à la valeur de name, le plan de contrôle Service Mesh utilisera l'installation existante. Cette approche vous permet de personnaliser entièrement votre configuration Jaeger.

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

1.26.4.2. Configuration de la sécurité du traçage distribué pour le maillage de services

La plateforme de traçage distribuée utilise OAuth pour l'authentification par défaut. Cependant, Red Hat OpenShift Service Mesh utilise un secret appelé htpasswd pour faciliter la communication entre les services dépendants tels que Grafana, Kiali et la plateforme de traçage distribuée. Lorsque vous configurez votre plateforme de traçage distribuée dans le site ServiceMeshControlPlane, le Service Mesh configure automatiquement les paramètres de sécurité pour utiliser htpasswd.

Si vous spécifiez la configuration de votre plateforme de traçage distribuée dans une ressource personnalisée Jaeger, vous devez configurer manuellement les paramètres htpasswd et vous assurer que le secret htpasswd est monté dans votre instance Jaeger afin que Kiali puisse communiquer avec elle.

1.26.4.2.1. Configurer la sécurité du traçage distribué pour le maillage de services à partir de la console OpenShift

Vous pouvez modifier la ressource Jaeger pour configurer la sécurité de la plateforme de traçage distribuée pour une utilisation avec Service Mesh dans la console OpenShift.

Conditions préalables

  • Vous avez accès au cluster en tant qu'utilisateur avec le rôle cluster-admin. Si vous utilisez Red Hat OpenShift Dedicated, vous devez avoir un compte avec le rôle dedicated-admin.
  • L'opérateur Red Hat OpenShift Service Mesh doit être installé.
  • Le site ServiceMeshControlPlane déployé dans le cluster.
  • Vous avez accès à la console web de OpenShift Container Platform.

Procédure

  1. Connectez-vous à la console web de OpenShift Container Platform en tant qu'utilisateur ayant le rôle cluster-admin.
  2. Naviguez vers Opérateurs Opérateurs installés.
  3. Cliquez sur le menu Project et sélectionnez dans la liste le projet dans lequel votre ressource ServiceMeshControlPlane est déployée, par exemple istio-system.
  4. Cliquez sur le site Red Hat OpenShift distributed tracing platform Operator.
  5. Sur la page Operator Details, cliquez sur l'onglet Jaeger.
  6. Cliquez sur le nom de votre instance Jaeger.
  7. Sur la page de détails de Jaeger, cliquez sur l'onglet YAML pour modifier votre configuration.

  8. Modifiez le fichier de ressources personnalisées Jaeger pour ajouter la configuration htpasswd, comme indiqué dans l'exemple suivant.

    • spec.ingress.openshift.htpasswdFile
    • spec.volumes

    • spec.volumeMounts

      Exemple de ressource Jaeger montrant la configuration de htpasswd 

      apiVersion: jaegertracing.io/v1
kind: Jaeger
spec:
  ingress:
    enabled: true
    openshift:
      htpasswdFile: /etc/proxy/htpasswd/auth
      sar: '{"namespace": "istio-system", "resource": "pods", "verb": "get"}'
    options: {}
    resources: {}
    security: oauth-proxy
  volumes:
    - name: secret-htpasswd
      secret:
        secretName: htpasswd
    - configMap:
        defaultMode: 420
        items:
          - key: ca-bundle.crt
            path: tls-ca-bundle.pem
        name: trusted-ca-bundle
        optional: true
      name: trusted-ca-bundle
  volumeMounts:
    - mountPath: /etc/proxy/htpasswd
      name: secret-htpasswd
    - mountPath: /etc/pki/ca-trust/extracted/pem/
      name: trusted-ca-bundle
      readOnly: true

  9. Cliquez sur Save.
1.26.4.2.2. Configuration de la sécurité du traçage distribué pour le maillage de services à partir de la ligne de commande

Vous pouvez modifier la ressource Jaeger pour configurer la sécurité de la plate-forme de traçage distribuée à utiliser avec Service Mesh depuis la ligne de commande à l'aide de l'utilitaire oc.

Conditions préalables

  • Vous avez accès au cluster en tant qu'utilisateur avec le rôle cluster-admin. Si vous utilisez Red Hat OpenShift Dedicated, vous devez avoir un compte avec le rôle dedicated-admin.
  • L'opérateur Red Hat OpenShift Service Mesh doit être installé.
  • Le site ServiceMeshControlPlane déployé dans le cluster.
  • Vous avez accès à la CLI d'OpenShift (oc) qui correspond à votre version d'OpenShift Container Platform.

Procédure

  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 https://<HOSTNAME>:6443

  2. Passez au projet dans lequel vous avez installé le plan de contrôle, par exemple istio-system, en entrant la commande suivante : 

    $ oc project istio-system

  3. Exécutez la commande suivante pour modifier le fichier de ressources personnalisées Jaeger, où jaeger.yaml est le nom de votre ressource personnalisée Jaeger. 

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

  4. Modifiez le fichier de ressources personnalisées Jaeger pour ajouter la configuration htpasswd, comme indiqué dans l'exemple suivant.

    • spec.ingress.openshift.htpasswdFile
    • spec.volumes

    • spec.volumeMounts

      Exemple de ressource Jaeger montrant la configuration de htpasswd 

      apiVersion: jaegertracing.io/v1
kind: Jaeger
spec:
  ingress:
    enabled: true
    openshift:
      htpasswdFile: /etc/proxy/htpasswd/auth
      sar: '{"namespace": "istio-system", "resource": "pods", "verb": "get"}'
    options: {}
    resources: {}
    security: oauth-proxy
  volumes:
    - name: secret-htpasswd
      secret:
        secretName: htpasswd
    - configMap:
        defaultMode: 420
        items:
          - key: ca-bundle.crt
            path: tls-ca-bundle.pem
        name: trusted-ca-bundle
        optional: true
      name: trusted-ca-bundle
  volumeMounts:
    - mountPath: /etc/proxy/htpasswd
      name: secret-htpasswd
    - mountPath: /etc/pki/ca-trust/extracted/pem/
      name: trusted-ca-bundle
      readOnly: true

  5. Exécutez la commande suivante pour appliquer vos modifications, où <jaeger.yaml> est le nom de votre ressource personnalisée Jaeger. 

    $ oc apply -n tracing-system -f <jaeger.yaml>

  6. Exécutez la commande suivante pour suivre la progression du déploiement du pod : 

    $ oc get pods -n tracing-system -w

1.26.4.3. 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 1.39. 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

1.26.4.4. 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 1.40. 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 1.41. 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.

1.26.4.5. 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 1.42. 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

1.26.4.6. 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 1.43. 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 1.44. 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 * * *"

1.26.4.6.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 1.45. 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.
1.26.4.6.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 1.46. 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 1.47. 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 1.48. 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 1.49. 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 1.50. 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 1.51. 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.

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

Pour plus d'informations sur la configuration d'Elasticsearch avec OpenShift Container Platform, voir Configuration du magasin de logs ou Configuration et déploiement du traçage distribué.

1.26.4.8. 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 1.52. 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 1.53. 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

1.26.4.9. 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 1.54. 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

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.