IDOT et le projet « OpenTelemetry »
La distribution « Instana » du collecteur OpenTelemetry ( IDOT ) s'appuie sur le projet open source en amont « OpenTelemetry Collector ». Si les fonctionnalités de base proviennent du projet en amont, IDOT propose plusieurs améliorations spécifiques à l' Instana :
- Composants préconfigurés optimisés pour l'envoi de données de télémétrie vers les backends d' Instana
- Processus d'installation et de configuration simplifié
De plus, IDOT propose une sélection rigoureuse de composants issus de la version communautaire, en mettant l'accent sur la stabilité et la sécurité pour les environnements d'entreprise.
- IBM gère les correctifs de sécurité et les mises à jour pour IDOT
- Une assistance de niveau entreprise via les canaux d'assistance d' IBM
- Audits de sécurité réguliers et gestion des vulnérabilités
- Tests de compatibilité avec les services d'arrière-plan d' Instana
IDOT reste compatible avec la norme « OpenTelemetry Protocol » ( OTLP ) et offre une expérience simplifiée aux utilisateurs d' Instana. La distribution est régulièrement mise à jour afin d'intégrer les améliorations apportées par le projet en amont et contribue à garantir une intégration fiable avec la plateforme d'observabilité d' Instana.
Avant de commencer, vérifiez la configuration système requise afin de garantir une installation sans encombre.
Instana Distribution du collecteur « OpenTelemetry » ( IDOT )
Pour qu' Instana puisse recevoir les données de télémétrie envoyées par le collecteur OpenTelemetry (indépendant du fournisseur), vous devez configurer correctement les points de OTLP terminaison HTTP ou gRPC et OTLP ou. L'outil « IDOT » automatise le processus de configuration du collecteur et garantit que Instana reçoive les données de télémétrie par défaut.
L' IDOT e prend en charge les systèmes d'exploitation, plateformes et architectures suivants :
| Système d'exploitation ou plateformes | Architectures | Valable dans un environnement isolé physiquement |
|---|---|---|
| Linux | x86-64 (amd64), s390x (IBM Z) | Oui |
| AIX | ppc64 | Oui |
| Windows | amd64 | Oui |
| Kubernetes | amd64 | Oui |
| OpenShift | amd64 | Oui |
Installation de l' IDOT
Pour installer l' IDOT e dans votre environnement cible, procédez comme suit :
Téléchargez le programme d'installation adapté à votre architecture :
Pour les systèmes d' x86-64 s ou amd64 :
curl -Lo instana_otelcol_setup.sh https://github.com/instana/instana-otel-collector/releases/latest/download/instana-otel-collector-installer-latest-linux-amd64.sh chmod +x instana_otelcol_setup.shPour les systèmes d' s390x s ou zLinux :
curl -Lo instana_otelcol_setup.sh https://github.com/instana/instana-otel-collector/releases/latest/download/instana-otel-collector-installer-latest-linux-s390x.sh chmod +x instana_otelcol_setup.shPour les systèmes d' AIX :
curl -Lo instana_otelcol_setup.sh https://github.com/instana/instana-otel-collector/releases/latest/download/instana-otel-collector-installer-latest-aix-ppc64.sh chmod +x instana_otelcol_setup.shRemarque : l'interface utilisateur d' Instana fournit un script d'installation simplifié (instana-collector-installer-latest.sh) qui détecte automatiquement l'architecture de votre système. Le script de l'interface utilisateur et les scripts spécifiques à l'architecture installent tous deux le même collecteur.Pour Windows (téléchargement et installation en une seule ligne)
powershell -Command "Invoke-WebRequest -Uri 'https://github.com/instana/instana-otel-collector/releases/download/<latest-version>/instana-otel-collector-installer-latest-windows-amd64.zip' -OutFile '$env:TEMP\instana-collector.zip'; Expand-Archive -Path '$env:TEMP\instana-collector.zip' -DestinationPath 'C:\Program Files\Instana\' -Force; Set-Location 'C:\Program Files\Instana\instana-collector\bin'; .\setenv.bat -a <INSTANA_KEY> -e <INSTANA_OTEL_ENDPOINT_GRPC> -H <INSTANA_OTEL_ENDPOINT_HTTP>; .\start.bat"Pour « Windows » (installation MSI)
Utilisez le programme d'installation MSI comme méthode d'installation recommandée pour les environnements d' Windows. Le programme d'installation MSI prend en charge l'installation interactive via une interface graphique, enregistre automatiquement un service d' Windows, et s'intègre aux outils de déploiement d'entreprise tels que Group Policy et SCCM.
Pour plus d'informations, consultez la section « Installation d' IDOT sur Windows à l'aide du programme d'installation MSI ».
Pour consulter le graphique « Kubernetes » Helm
helm install instana-otel-collector \ --repo https://instana.github.io/instana-otel-collector instana-otel-collector-chart \ --namespace instana-otel-collector \ --create-namespace \ --set clusterName=<CLUSTER_NAME> \ --set instanaEndpoint=<INSTANA_OTEL_ENDPOINT> \ --set instanaKey=<INSTANA_KEY>Pour plus d'informations sur les instructions d'installation d' Kubernetes, y compris la prise en charge des systèmes d'exploitation pour l'opérateur et l' OpenShift, consultez la page « Installation de la distribution Instana d' OpenTelemetry Collector » sur Kubernetes.
Exécutez le script d'installation à l'aide de la commande suivante :
sudo ./instana_otelcol_setup.sh -e <INSTANA_OTEL_ENDPOINT_GRPC> -a <INSTANA_KEY> [-H <INSTANA_OTEL_ENDPOINT_HTTP>] [-u USE_SUPERVISOR_SERVICE] [<install_path>]Utilisez les paramètres suivants avec le script d'installation :<INSTANA_OTEL_ENDPOINT_GRPC>: Indique le point de terminaison requis de l' gRPC pour Instana. Utilisez le<ip_address>:<port>format.<INSTANA_KEY>: Indique la clé de l'agent d' Instana s requise pour l'authentification.<INSTANA_OTEL_ENDPOINT_HTTP>: Spécifie le point de terminaison facultatif HTTP pour Instana. Utilisez le<ip_address>:<port>format.<USE_SUPERVISOR_SERVICE>: Indique si le service de supervision d' Instana est activé. La valeur par défaut esttrue. Définissez ce paramètre surfalsepour désactiver le service de supervision.
Important : les paramètresINSTANA_OTEL_ENDPOINT_GRPCINSTANA_KEYet sont obligatoires pour lancer le programme d'installation. Vous pouvez modifier ces paramètres ultérieurement dans leconfig.envfichier qui se trouve dans le répertoire install_path/collector/config/config.env. Le chemin par défaut est /opt/instana/collector/config/config.env. De plus, l'installation nécessite des droits d'administrateur, car le collecteur doit généralement écrire dans les répertoires système et configurer des services au niveau du système.
- Service de supervision : gère le cycle de vie du processus de collecte, permettant ainsi la gestion à distance et les redémarrages automatiques. Le service de supervision est activé par défaut lors de l'installation.
- Service Collector : processus principal de Collector d' OpenTelemetry s chargé de recevoir, de traiter et d'exporter les données de télémétrie.
Pour plus d'informations sur la terminologie d' OpenTelemetry, notamment les services « Supervisor » et « Collector », consultez la documentation relative à la gestion des collecteurs d' OpenTelemetry.
Gestion du service de collecte d' Instana s
Le script d'installation d' IDOT Collector installe et démarre le service par défaut. Vous pouvez également gérer le service de collecte d' Instana s en exécutant les commandes suivantes dans le bin répertoire :
Installer le service :
./instana_collector_service.sh installDésinstaller le service :
./instana_collector_service.sh uninstallDémarrez le service :
./instana_collector_service.sh startOu
service instana-collector startArrêtez le service :
./instana_collector_service.sh stopOu
service instana-collector stopRedémarrer le service :
./instana_collector_service.sh restartOu
service instana-collector restartAffiche l'état du service :
./instana_collector_service.sh statusOu
service instana-collector status
Gestion du service « Supervisor » d' Instana
Tout comme le service de collecte d' Instana s, le service de supervision d' Instana est installé et initialisé au cours du processus d'installation d' IDOT. La gestion du service « Supervisor » s'effectue de la même manière (comme indiqué dans la section précédente) que celle du service du collecteur, en utilisant ./instana_supervisor_service.sh au lieu de ./instana_collector_service.sh.
Configuration du collecteur OpenTelemetry
Vous pouvez configurer le collecteur en fonction de vos besoins en modifiant le fichier /opt/instana/collector/config/config.yaml . Vous pouvez également définir et modifier les pipelines pour les données télémétriques en fonction des besoins. L'exemple de configuration suivant permet de prendre en charge le flux de données pour tous les types de données télémétriques :
receivers:
# Configure OTLP/gRPC endpoint
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:24317
# Specifies a file log receiver to include logs from a given path
filelog:
include: ["path/to/logs/*.log"]
processors:
# Set a limit for batch size
batch:
send_batch_size: 5000
send_batch_max_size: 10000
timeout: 180s
# Specify a transform processor to add a processed attribute for logs
transform:
log_statements:
- set(log.body, log.attributes["processed"])
exporters:
# Configure OTLP exporter for telemetry data to be sent to
otlp:
endpoint: INSTANA_OTEL_ENDPOINT_GRPC
headers:
x-instana-key: INSTANA_KEY
x-instana-host: INSTANA_HOST
tls:
insecure: true
# Assemble the data pipeline from the configured components
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlp]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [otlp]
logs:
receivers: [filelog]
processors: [transform]
exporters: [otlp]
Facultatif : Configuration du récepteur shell OTEL
Le récepteur Shell est un composant de Collector d' OpenTelemetry s qui exécute des commandes Shell et recueille leurs résultats sous forme de métriques ou de journaux. Ce récepteur est utile pour intégrer des outils en ligne de commande et des scripts dans votre pipeline d'observabilité.
Avertissement de sécurité
Options de configuration
Le récepteur shell prend en charge les options de configuration suivantes :
receivers:
shell:
collection_interval: 60s # How often to execute commands (default: 60s)
commands:
- name: disk_usage # Required: Unique identifier for this command
command: df -h / # Required: Shell command to execute
shell: /bin/sh # Optional: Shell to use (default: /bin/sh)
args: [] # Optional: Additional arguments to pass to the shell
timeout: 5s # Optional: Maximum time the command can run
metric_name: disk.usage # Required for metrics: Name for the metric
log_name: disk_check # Optional: Name for log records (defaults to metric_name)
description: "Check disk usage" # Optional: Human-readable description
labels: # Optional: Additional key-value pairs as attributes
filesystem: "root"
output_type: both # Optional: How to process output (metric, log, or both; default: metric)
Paramètres de configuration de la commande
Chaque commande de la commands liste prend en charge les options suivantes :
| Zone | Type | Obligatoire | Par défaut | Description |
|---|---|---|---|---|
name |
string |
Oui | Identifiant unique de cette commande | |
command |
string |
Oui | Commande Shell à exécuter | |
shell |
string |
Non | /bin/sh |
Shell à utiliser pour l'exécution |
args |
[]string |
Non | [] | Arguments supplémentaires à transmettre au shell |
timeout |
duration |
Non | Durée maximale d'exécution de la commande | |
metric_name |
string |
Obligatoire lorsqueoutput_type « ismetric » ouboth |
Nom de l'indicateur. Pour les sorties simples, il s'agit du nom complet de la métrique. Dans les tableaux, il sert de préfixe métrique associé aux noms de colonnes (par exemple,prefix.column_name). |
|
log_name |
string |
Obligatoire lorsqueoutput_type estlog etmetric_name n'est pas défini |
metric_name |
Nom des entrées du journal |
description |
string |
Non | Description en langage clair de la fonction de la commande | |
labels |
map[string]string |
Non | {} |
Autres paires clé-valeur à ajouter en tant qu'attributs |
output_type |
chaîne | Non | metric |
Détermine comment traiter la sortie de la commande :metric,log, ouboth |
row_regex |
string |
Non | Expression régulière permettant de faire correspondre et d'analyser chaque ligne de sortie (permet une analyse personnalisée) | |
metric_names |
[]string |
Non (obligatoire sirow_regex l'option est activée) |
Noms attribués à chaque champ capturé à partir derow_regex |
|
descriptions |
[]string |
Obligatoire sirow_regex cette option est activée |
Descriptions lisibles par l'utilisateur pour chaque champ (facultatif, la longueur doit correspondremetric_names ) |
|
field_types |
[]string |
Non | Comment chaque champ doit être traité :Attribute ouGauge |
Modes de traitement de sortie
Le récepteur prend en charge les modes d'analyse suivants :
Analyse syntaxique automatique (par défaut)
Si row_regex n'est pas spécifié, le récepteur détecte automatiquement le format de sortie :
Pour les métriques (lorsque output_type est metric ou both) :
- Si la sortie peut être interprétée comme un nombre, cela crée une métrique de jauge avec cette valeur.
- Si le résultat se présente sous forme de tableau (plusieurs colonnes), le système crée des indicateurs distincts pour chaque colonne numérique.
- Si la sortie ne peut pas être interprétée comme un nombre, une métrique de somme est créée avec la valeur 1 et la sortie est incluse en tant qu'attribut.
Pour les logarithmes (lorsque output_type est log ou both) :
- Crée une entrée de journal dont le corps correspond à la sortie de la commande.
- Définit
INFOle niveau de gravité par défaut. - Comprend le nom de la commande, la description et les libellés en tant qu'attributs.
- Si la sortie peut être interprétée comme un nombre, elle est ajoutée en tant
valuequ'attribut.
Analyse syntaxique basée sur les expressions régulières (personnalisée)
row_regex est spécifié, le récepteur utilise des expressions régulières pour analyser la sortie, ce qui lui permet de contrôler entièrement les types de champs :row_regex: Expression régulière avec des groupes de capture pour chaque champmetric_names: Noms des champs renseignésfield_types: Indique si chaque champ est unAttribute(identifiant sous forme de chaîne) ou unGauge(mesure numérique)descriptions: Descriptions facultatives pour chaque champ
Exemples de configuration
Les exemples suivants illustrent les différentes options de configuration :
Utilisation de base
receivers:
shell:
collection_interval: 30s
commands:
- name: cpu_temperature
command: cat /sys/class/thermal/thermal_zone0/temp
metric_name: system.cpu.temperature
description: "CPU temperature in millidegrees Celsius"
Plusieurs commandes avec différents types de sortie
receivers:
shell:
collection_interval: 60s
commands:
- name: memory_free
command: free -m | grep Mem | awk '{print $4}'
metric_name: system.memory.free
description: "Free memory in MB"
labels:
unit: "MB"
output_type: metric
- name: disk_usage
command: df -h / | grep / | awk '{print $5}' | sed 's/%//'
metric_name: system.disk.usage
description: "Root filesystem usage percentage"
labels:
filesystem: "root"
unit: "percent"
output_type: both
- name: last_logins
command: last -n 5
log_name: system.logins
description: "Last 5 system logins"
output_type: log
Analyse syntaxique automatique avec sortie sous forme de tableaux multiples
receivers:
shell:
collection_interval: 60s
commands:
- name: system_metrics_auto
command: hyptop -b -n 1 | awk 'BEGIN {printf "%-12s %-10s %-8s %-12s\n","system","cpucount","cpu%","memoryinGB"}$2 ~ /^[0-9]+$/ {printf "%-12s %-10s %-8s %-12s\n",$1,$2,$3,$5}'
metric_name: system.metrics.shell.hypervisor
description: "System CPU and Memory metrics"
output_type: metric
Analyse syntaxique basée sur les expressions régulières pour un contrôle personnalisé
receivers:
shell:
collection_interval: 60s
commands:
- name: system_metrics_regex
command: hyptop -b -n 1 | awk 'BEGIN {printf "%-12s %-10s %-8s %-12s\n","system","cpucount","cpu%","memoryinGB"}$2 ~ /^[0-9]+$/ {printf "%-12s %-10s %-8s %-12s\n",$1,$2,$3,$5}'
metric_name: system.metrics.shell.hypervisor
description: "System CPU and Memory metrics"
output_type: metric
row_regex: '^\s*(\S+)\s+(\d+)\s+([\d.]+)\s+([\d.]+)\s*$'
metric_names:
- system
- cpucount
- cpu
- memoryinGB
descriptions:
- System Name
- CPU Count
- CPU Usage Percentage
- Memory Usage in GB
field_types:
- Attribute # system is an identifier, not a metric
- Gauge # cpucount is a numeric metric
- Gauge # cpu is a numeric metric
- Gauge # memoryinGB is a numeric metric
labels:
source: "hyptop"
- name: process_stats
command: ps aux | grep myapp | awk '{print $2, $3, $4}'
metric_name: process.metrics
description: "Process CPU and Memory usage"
output_type: metric
row_regex: '^\s*(\d+)\s+([\d.]+)\s+([\d.]+)\s*$'
metric_names:
- pid
- cpu_percent
- mem_percent
descriptions:
- Process ID
- CPU Usage Percentage
- Memory Usage Percentage
field_types:
- Attribute # PID is an identifier, not a gauge
- Gauge # CPU percentage is a metric
- Gauge # Memory percentage is a metric
labels:
app: "myapp"
Sélection d'un mode d'analyse
Utilisez l'analyse automatique dans les cas suivants :
- Vous disposez de résultats numériques simples ou de données tabulaires standard.
- Vous souhaitez une installation rapide sans avoir à configurer d'expressions régulières.
- Tous les champs numériques doivent être considérés comme des indicateurs.
Utilisez l'analyse syntaxique basée sur les expressions régulières dans les cas suivants :
- Il faut faire la distinction entre les identifiants (tels que les PID ou les noms de système) et les métriques proprement dites
- Vos formats de sortie sont irréguliers ou variables.
- Vous souhaitez pouvoir contrôler explicitement les types et les noms des champs.
- Vous avez besoin de descriptions de champs personnalisées.
Connexion d' IDOT à différents environnements d' Instana
Environnements auto-hébergés
Pour utiliser l' IDOT, vous devez configurer l'exportateur OTLP afin qu'il envoie les données au backend Instana, qui est l'option par défaut.
otlp-grpc.<base_domain>→ OTLP/gRPCotlp-http.<base_domain>→ OTLP/HTTP
Par défaut, le backend Instana utilise un certificat auto-signé. Si vous ne configurez pas le collecteur avec le fichier CA, vous devez désactiver la vérification. Sinon, la négociation de la connexion « TLS » échoue.
Exemple de configuration sans vérification du certificat :
exporters:
otlp:
endpoint: https://otlp-grpc.<base_domain>:443
tls:
insecure: false
insecure_skip_verify: true
headers:
x-instana-key: <your_instana_key>
x-instana-host: <your_instana_host>
Vérifiez la configuration du superviseur. Assurez-vous qu'il cible le bon terminal et qu'il gère correctement le certificat auto-signé.
Connexion d' IDOT. à l'agent local
Vous pouvez également transmettre les données via l'agent local d' Instana s sur le même hôte. Cette option nécessite une configuration spécifique lors de l'installation et dans les fichiers de configuration.
Commande d'installation de l'agent local
127.0.0.1 (localhost) pour les paramètres du point de terminaison :sudo ./instana_otelcol_setup.sh -e 127.0.0.1:4317 -a <INSTANA_KEY> -H http://127.0.0.1:4318 -o <INSTANA_OPAMP_ENDPOINT> -u true
127.0.0.1 à la place de l'adresse IP du serveur. L'agent « Instana » écoute sur les ports 4317 et 4318 uniquement sur localhost.-u true), vous devez le spécifier -o en définissant INSTANA_OPAMP_ENDPOINT dans la ligne de commande.Configuration post-installation
/opt/instana/collector/config/config.env fichier afin d'utiliser le protocole HTTP pour les connexions à localhost :INSTANA_OTEL_ENDPOINT_GRPC=http://127.0.0.1:4317
INSTANA_OTEL_ENDPOINT_HTTP=http://127.0.0.1:4318
http:// à la place de https:// pour les connexions à localhost. L'agent local d' Instana s n'utilise pas le cryptage TLS pour les connexions à localhost. L'utilisation de ` HTTPS ` entraîne des erreurs de connexion avec ` SSL `.INSTANA_OPAMP_ENDPOINT=wss://<opamp-endpoint-url>:443/v1/opamp
INSTANA_OPAMP_ENDPOINT est obligatoire lorsque le service de supervision est activé afin de permettre la gestion à distance du collecteur.YAML configuration de l'agent local
config.yaml application pour qu'il cible localhost :exporters:
otlphttp:
endpoint: http://127.0.0.1:4318
tls:
insecure: true
Installation de la distribution « Instana » du collecteur « OpenTelemetry » sur Kubernetes
Dans les environnements d' Kubernetes, IDOT peut être déployé en tant que collecteur centralisé à l'aide des charts disponibles sur Helm ou des manifestes disponibles sur YAML. Ce modèle de déploiement vous permet d'effectuer les tâches suivantes :
- Collectez les données de télémétrie provenant de plusieurs applications au sein de votre cluster
- Configurer la haute disponibilité avec plusieurs instances de collecteur
- Gérer la configuration du collecteur à l'aide des outils natifs d' Kubernetes
Pour obtenir des instructions détaillées sur l'installation et la configuration d' IDOT, rendez-vous sur Kubernetes et consultez la page « Installation de la distribution Instana d' OpenTelemetry Collector » sur Kubernetes.
Pour le déploiement et la gestion d' IDOT via l'opérateur sur Kubernetes, consultez la section « Installation d' IDOT via l'opérateur ».
Désinstallation du collecteur OpenTelemetry
Par défaut, le script d'installation ajoute également un script de désinstallation sous collector/bin dans le répertoire install_path.
./uninstall.sh
L'exécution de ce script arrête le service de collecte d' Instana s et supprime tous les fichiers de collecte du système.
Traitement des incidents
Pour connaître les problèmes courants et leurs solutions, consultez la section « Dépannage de la distribution d' Instana du collecteur d' OpenTelemetry ». Cette rubrique traite des problèmes d'installation, des difficultés de connexion et des procédures de dépannage spécifiques à chaque plateforme.
Notes sur l'édition
Pour connaître les dernières mises à jour, fonctionnalités et corrections de bogues, consultez les notes de mise à jour d' IDOT.
Support
Pour toute question relative à l'assistance, consultez la stratégie d'assistance pour IDOT.
Autres ressources d' OpenTelemetry
- Exemples concrets de configuration.
- Guides de dépannage.
- Modèles d'intégration pour diverses technologies.
- Solutions proposées par la communauté.