3.3. Configuration et déploiement de la collecte de données de traçage distribuées
L'opérateur de collecte de données de traçage distribué Red Hat OpenShift utilise un fichier de définition de ressource personnalisée (CRD) qui définit l'architecture et les paramètres de configuration à utiliser lors de la création et du déploiement des ressources de collecte de données de traçage distribué Red Hat OpenShift. Vous pouvez soit installer la configuration par défaut, soit modifier le fichier pour mieux répondre aux exigences de votre entreprise.
3.3.1. Options de configuration du collecteur OpenTelemetry
L'opérateur de collecte de données de traçage distribué de Red Hat OpenShift est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.
Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.
Le collecteur OpenTelemetry est constitué de trois composants qui accèdent aux données télémétriques :
- Receivers - Un récepteur, qui peut être de type "push" ou "pull", est la façon dont les données entrent dans le collecteur. En général, un récepteur accepte des données dans un format spécifique, les traduit dans le format interne et les transmet aux processeurs et aux exportateurs définis dans les pipelines applicables. Par défaut, aucun récepteur n'est configuré. Un ou plusieurs récepteurs doivent être configurés. Les récepteurs peuvent prendre en charge une ou plusieurs sources de données.
- Processors - (Facultatif) Les processeurs sont exécutés sur les données entre leur réception et leur exportation. Par défaut, aucun processeur n'est activé. Les processeurs doivent être activés pour chaque source de données. Tous les processeurs ne prennent pas en charge toutes les sources de données. Selon la source de données, il peut être recommandé d'activer plusieurs processeurs. En outre, il est important de noter que l'ordre des processeurs est important.
- Exporters - Un exportateur, qui peut être de type "push" ou "pull", permet d'envoyer des données à un ou plusieurs backends/destinations. Par défaut, aucun exportateur n'est configuré. Un ou plusieurs exportateurs doivent être configurés. Les exportateurs peuvent prendre en charge une ou plusieurs sources de données. Les exportateurs peuvent être livrés avec des paramètres par défaut, mais beaucoup nécessitent une configuration pour spécifier au moins la destination et les paramètres de sécurité.
Vous pouvez définir plusieurs instances de composants dans un fichier YAML de ressources personnalisées. Une fois configurés, ces composants doivent être activés au moyen de pipelines définis dans la section spec.config.service du fichier YAML. La meilleure pratique consiste à n'activer que les composants dont vous avez besoin.
exemple de fichier de ressources personnalisées du collecteur OpenTelemetry
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
name: cluster-collector
namespace: tracing-system
spec:
mode: deployment
config: |
receivers:
otlp:
protocols:
grpc:
http:
processors:
exporters:
jaeger:
endpoint: jaeger-production-collector-headless.tracing-system.svc:14250
tls:
ca_file: "/var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt"
service:
pipelines:
traces:
receivers: [otlp]
processors: []
exporters: [jaeger]
Si un composant est configuré, mais n'est pas défini dans la section service, il n'est pas activé.
| Paramètres | Description | Valeurs | Défaut |
|---|---|---|---|
récepteurs : | Un récepteur permet aux données d'entrer dans le collecteur. Par défaut, aucun récepteur n'est configuré. Il doit y avoir au moins un récepteur activé pour qu'une configuration soit considérée comme valide. Les récepteurs sont activés lorsqu'ils sont ajoutés à un pipeline. |
| Aucun |
receivers: otlp: |
Les récepteurs | ||
des transformateurs : | Les processeurs traitent les données entre leur réception et leur exportation. Par défaut, aucun processeur n'est activé. | Aucun | |
exportateurs : | Un exportateur envoie des données à un ou plusieurs backends/destinations. Par défaut, aucun exportateur n'est configuré. Il doit y avoir au moins un exportateur activé pour qu'une configuration soit considérée comme valide. Les exportateurs sont activés lorsqu'ils sont ajoutés à un pipeline. Les exportateurs peuvent être livrés avec des paramètres par défaut, mais beaucoup nécessitent une configuration pour spécifier au moins la destination et les paramètres de sécurité. |
| Aucun |
exporters: jaeger: endpoint: |
Le point de terminaison de l'exportateur | ||
exporters: jaeger: tls: ca_file: | Chemin d'accès au certificat de l'autorité de certification. Pour un client, cela permet de vérifier le certificat du serveur. Pour un serveur, cela permet de vérifier les certificats des clients. Si empty utilise l'autorité de certification racine du système. | ||
service: pipelines: |
Les composants sont activés en les ajoutant à un pipeline sous | ||
service:
pipelines:
traces:
receivers:
|
Vous activez les récepteurs pour le traçage en les ajoutant sous | Aucun | |
service:
pipelines:
traces:
processors:
|
Vous activez les processeurs pour le traçage en les ajoutant sous | Aucun | |
service:
pipelines:
traces:
exporters:
|
Vous activez les exportateurs pour le traçage en les ajoutant sous | Aucun |
3.3.2. Valider votre déploiement
3.3.3. Accéder à la console Jaeger
Pour accéder à la console Jaeger, vous devez avoir soit Red Hat OpenShift Service Mesh, soit Red Hat OpenShift distributed tracing installé, et Red Hat OpenShift distributed tracing platform installé, configuré et déployé.
Le processus d'installation crée une route pour accéder à la console Jaeger.
Si vous connaissez l'URL de la console Jaeger, vous pouvez y accéder directement. Si vous ne connaissez pas l'URL, suivez les instructions suivantes.
Procédure à partir de la console OpenShift
-
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. -
Naviguez jusqu'à Networking
Routes. 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.
-
Si nécessaire, utilisez le filtre pour trouver la route
jaeger. Cliquez sur la route Location pour lancer la console. - Cliquez sur Log In With OpenShift.
Procédure à partir du CLI
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ôlededicated-admin.$ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
Pour demander des détails sur l'itinéraire à l'aide de la ligne de commande, entrez la commande suivante. Dans cet exemple,
tracing-systemest l'espace de noms du plan de contrôle.$ export JAEGER_URL=$(oc get route -n tracing-system jaeger -o jsonpath='{.spec.host}')-
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. - 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.
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.
