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 :

  1. 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.sh
     

    Pour 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.sh
     

    Pour 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.sh
    Remarque : 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.

  2. 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 est true. Définissez ce paramètre sur false pour désactiver le service de supervision.
    Important : les paramètres INSTANA_OTEL_ENDPOINT_GRPC INSTANA_KEY et sont obligatoires pour lancer le programme d'installation. Vous pouvez modifier ces paramètres ultérieurement dans le config.env fichier 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.
Le script d'installation installe le collecteur IDOT et lance le service de collecte Instana (ainsi que le service de supervision, si vous le souhaitez) sur votre système en utilisant les paramètres spécifiés.
  • 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 install
     
  • Désinstaller le service :

    ./instana_collector_service.sh uninstall
     
  • Démarrez le service :

    ./instana_collector_service.sh start
     

    Ou

    service instana-collector start
     
  • Arrêtez le service :

    ./instana_collector_service.sh stop
     

    Ou

    service instana-collector stop
     
  • Redémarrer le service :

    ./instana_collector_service.sh restart
     

    Ou

    service instana-collector restart
     
  • Affiche l'état du service :

    ./instana_collector_service.sh status
     

    Ou

    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é

Important : ce récepteur exécute les commandes shell arbitraires configurées par l'utilisateur. Utilisez-le uniquement dans des environnements fiables où la configuration ne peut pas être modifiée par des tiers non autorisés. Des commandes malveillantes pourraient compromettre le système.

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 INFO le 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 value qu'attribut.

Analyse syntaxique basée sur les expressions régulières (personnalisée)

Lorsque 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 champ
  • metric_names: Noms des champs renseignés
  • field_types: Indique si chaque champ est un Attribute (identifiant sous forme de chaîne) ou un Gauge (mesure numérique)
  • descriptions: Descriptions facultatives pour chaque champ
Ce mode offre la souplesse nécessaire pour gérer des formats de sortie variables et irréguliers, déterminer quels champs sont des attributs ou des métriques, et définir explicitement les types de champs.

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.

Tout le trafic OTLP doit passer par la passerelle sur le port 443 en utilisant les sous-domaines suivants :
  • otlp-grpc.<base_domain> → OTLP/gRPC
  • otlp-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

Lorsque vous installez IDOT pour envoyer des données via l'agent local Instana, utilisez 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
Important : Utilisez 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.
Remarque : lorsque vous activez le service de supervision (-u true), vous devez le spécifier -o en définissant INSTANA_OPAMP_ENDPOINT dans la ligne de commande.

Configuration post-installation

Une fois l'installation terminée, vérifiez et mettez à jour le /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
Important : utilisez 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
Remarque : le paramètre 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

Configurez l'exportateur « OTLP » dans votre 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.

Autres ressources d' OpenTelemetry

Pour découvrir des exemples d' OpenTelemetry, des bonnes pratiques et des modèles d'intégration proposés par la communauté, consultez le dépôt « OpenTelemetry » sur Instana. Cette ressource fournit les informations suivantes :
  • Exemples concrets de configuration.
  • Guides de dépannage.
  • Modèles d'intégration pour diverses technologies.
  • Solutions proposées par la communauté.