Installation du backend « Instana »

• Le plug-in « Instana » ( kubectl ) doit être installé.
• Les magasins de données requis doivent être opérationnels. Voir la section « Configuration des magasins de données ».
• L'opérateur Enterprise d' Instana doit être installé.

Avant de créer Core et Unit, vous devez créer des espaces de nom et placer un ensemble de secrets pour les espaces de nom afin de pouvoir extraire des images Core et Unit du registre artifact-public.instana.io .

Un coeur représente les composants partagés et est responsable de la configuration de l'accès au magasin de données. Par conséquent, la plupart des configurations vont se produire ici.

Pour plus d'informations, consultez la documentation d' API.

Une ressource personnalisée Core doit avoir la version instana.io/v1beta2 et le type Core. Les configurations pour Core sont décrites dans la section spec .

Créez un fichier core.yaml. Les configurations pour Core sont décrites dans la section spec .

apiVersion: instana.io/v1beta2
kind: Core
metadata:
  namespace: instana-core
  name: instana-core
spec:
  ...
 

Assurez-vous qu'au moins un nœud du cluster n'est pas marqué et ne porte pas l'étiquette node-role.kubernetes.io/monitor: "true". Ajoutez les lignes suivantes dans le fichier core.yaml pour définir les tolérances et le sélecteur de nœuds.

 spec:
   tolerations:
     - key: node.instana.io/monitor
       operator: Equal
       effect: NoSchedule
       value: "true"
   nodeSelector:
     node-role.kubernetes.io/monitor: "true"
 

Effectuez certaines configurations de base comme suit:

apiVersion: instana.io/v1beta2
kind: Core
metadata:
  namespace: instana-core
  name: instana-core
spec:
  # The domain under which Instana is reachable
  baseDomain: <instana.example.com>

  # Depending on your cluster setup, you may need to specify an image pull secret.
  imagePullSecrets:
    - name: my-registry-secret

  # This configures an SMTP server for sending e-mails.
  # Alternatively, Amazon SES is supported. Please see API reference for details.
  emailConfig:
    smtpConfig:
      from: smtp@example.com
      host: smtp.example.com
      port: 465
      useSSL: true
 

L'opérateur utilise un ensemble de profils de ressource prédéfinis qui déterminent les ressources affectées aux pods de composant individuels. Les profils suivants sont disponibles. Par défaut, medium est utilisé si rien n'est configuré.

• small
• medium
• large

spec:
  resourceProfile: large
 

En outre, vous pouvez configurer des ressources d'UC et de mémoire personnalisées pour chaque pod de composant. Dans l'exemple suivant, le composant filler est utilisé. Remplacez filler par le composant que vous souhaitez utiliser et désignez les ressources d'UC et de mémoire avec les totaux que vous souhaitez fournir.

spec:
  componentConfigs:
    - name: filler
      resources:
        requests:
          cpu: 2.5
          memory: 5000Mi
        limits:
          cpu: 4
          memory: 20000Mi
 

La configuration suivante est obsolète. Utilisez la configuration indiquée dans la section « Configuration de la passerelle ».

L'acceptor est le point de terminaison que les agents d' Instana ation doivent atteindre pour transmettre les traces ou les métriques au backend d' Instana. L'accepteur est généralement un sous-domaine pour le baseDomain configuré précédemment dans la section Configuration de base .

spec:
  agentAcceptorConfig:
    host: ingress.<instana.example.com>
    port: 443
 

Vous pouvez configurer les hôtes et les ports pour les types de trafic entrant suivants :

• Agent Instana
• Synthétiques
• Sans serveur
• OTLP (HTTP/gRPC)
• EUM
• OpAMP

Pour configurer les hôtes et les ports des différents récepteurs d' Instana, ajoutez la configuration suivante dans le fichier CoreSpec :

spec:
  gatewayConfig:
    enabled: true # enables gateway-v2 and gateway-controller
  acceptors:
    agent:
      host: ingress.<instana.example.com>
      port: 443
    opamp:
      host: opamp-acceptor.<instana.example.com>
      port: 443
    otlp:
      http:
        host: otlp-http.<instana.example.com>
        port: 443
      grpc:
        host: otlp-grpc.<instana.example.com>
        port: 443
    eum:
      host: eum.<instana.example.com>
      port: 443
    synthetics:
      host: synthetics.<instana.example.com>
      port: 443
    serverless:
      host: serverless.<instana.example.com>
      port: 443
 

Les exemples suivants montrent comment configurer la collecte du trafic par votre acceptor en fonction de différents besoins :

1. Utilisez des sous-domaines avec un seul port (443). Cette approche vous permet de n'exposer qu'un seul port (443) tout en utilisant des sous-domaines pour différencier le trafic destiné à chaque serveur.

    spec:
      acceptors:
        agent:
          host: ingress.<instana.example.com>
          port: 443
        opamp:
          host: opamp-acceptor.<instana.example.com>
          port: 443
        otlp:
          http:
            host: otlp-http.<instana.example.com>
            port: 443
          grpc:
            host: otlp-grpc.<instana.example.com>
            port: 443
        eum:
          host: eum.<instana.example.com>
          port: 443
        synthetics:
          host: synthetics.<instana.example.com>
          port: 443
        serverless:
          host: serverless.<instana.example.com>
          port: 443
    

2. Utiliser un seul domaine avec différents ports. Cette approche vous permet d'utiliser un seul domaine tout en différenciant le trafic entrant en fonction des numéros de port. Seule la version Custom Edition d' 1.3.0, et les versions ultérieures, peut être configurée avec un seul domaine.

    spec:
      acceptors:
        agent:
          port: 1444
        otlp:
          http:
            port: 4318
          grpc:
            port: 4317
        eum:
          port: 1555
        synthetics:
          port: 1666
        serverless:
          port: 1777
    

   Dans ce cas, vous devez mettre à jour la configuration de votre équilibreur de charge au sein de votre cluster afin d'exposer les différents ports d'acceptation. Voir la section « Configuration des équilibreurs de charge » et DNS.

Votre environnement Custom Edition peut acheminer le trafic de tous les locataires via un seul domaine de base. Pour activer cette fonctionnalité, configurez la propriété suivante dans votre CoreSpec :

kind: Core
metadata:
  name: instana-core
  namespace: instana-core
spec:
  properties:
    ...
    - name: config.url.format.pathStyle
      value: "true"
    ...
 

Une fois cette fonctionnalité activée, l' URL, qui permet d'accéder à l'interface utilisateur de tous vos locataires Instana, est accessible à l'adresse <basedomain>.com/<unitname>/<tenantname> au lieu de <unitname>-<tenantname>.<basedomain>.com. Tout le trafic entrant vers Instana peut être acheminé via un seul enregistrement A dans votre fichier DNS, en l'associant à la configuration présentée dans le deuxième exemple de la section « Configuration de la passerelle ».

Votre environnement Custom Edition prend en charge la création automatique des services LoadBalancerKubernetes pour le composant gateway-v2. Vous n'avez pas besoin de créer manuellement les services d' LoadBalancer.

Pour activer cette fonctionnalité, ajoutez la configuration suivante à votre CoreSpec :

spec:
  gatewayConfig:
    enabled: true
    gateway:
      loadBalancerConfig:
        enabled: true # enables automatic loadbalancer creation
        ip: <your public IP>
        externalTrafficPolicy: Local # default
        annotations:
          your-annotation-key: your-annotation-value
 

Avant d'activer cette fonctionnalité, assurez-vous qu'un proxy frontal est déployé pour acheminer tout le trafic entrant de Instana vers le service gateway-v2. Si des ports distincts sont configurés pour chaque acceptor, assurez-vous que le proxy frontal transfère le trafic vers ces ports. Les ports sur gateway-v2 doivent correspondre exactement aux ports exposés par le proxy frontal.

Votre environnement Custom Edition permet également de désactiver la terminaison de l' TLS (c'est-à-dire d'accepter le trafic entrant sans SSL ). Cette option est utile lorsque vous déployez un proxy frontal chargé de la terminaison de l' TLS en amont de votre environnement Custom Edition.

Pour activer cette fonctionnalité, ajoutez la configuration suivante à votre fichier CoreSpec :

spec:
  gatewayConfig:
    enabled: true
    disableTLS: true # disables TLS termination for all ingress traffic
 

Vous devez utiliser l'une des trois options suivantes pour stocker les données d'intervalles brutes:

• S3 (ou compatible)
• Google Cloud Storage (GCS)
• Système de fichiers Azure
• Système de fichiers

Le noeud final S3 varie en fonction de la région.

Pour utiliser S3 (ou compatible) pour stocker des données de plages brutes, configurez Core comme illustré dans l'exemple suivant:

spec:
  storageConfigs:
    rawSpans:
      s3Config:
        # Endpoint address of the object storage.
        # S3 Endpoint Ref: https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_region
        endpoint:
        # Region.
        region: eu-central-1
        # Bucket name.
        bucket: mybucket
        # Prefix for the storage bucket.
        prefix: myspans
        # Storage class.
        storageClass: STANDARD
        # Bucket name for long-term storage.
        bucketLongTerm: mybucket
        # Prefix for the long-term storage bucket.
        prefixLongTerm: myspans-longterm
        # Storage class for objects that are written to the long-term bucket.
        storageClassLongTerm: STANDARD

  # If using IRSA
  # Appropriate IAM Role should be provisioned including IAM policy with sufficient privileges.
  serviceAccountAnnotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-role
 

Pour utiliser GCS pour le stockage de données d'étendues brutes, configurez Core comme suit:

spec:
  storageConfigs:
    rawSpans:
      gcloudConfig:
        # Bucket name.
        bucket: mybucket
        # Prefix for the storage bucket.
        prefix: myspans
        # Storage class.
        storageClass: STANDARD
        # Bucket name for long-term storage.
        bucketLongTerm: mybucket
        # Prefix for the long-term storage bucket.
        prefixLongTerm: myspans-longterm
        # Storage class for objects that are written to the long-term bucket.
        storageClassLongTerm: STANDARD

  # If using Workload Identity
  serviceAccountAnnotations:
    iam.gke.io/gcp-service-account: rawspans@myproject.iam.gserviceaccount.com
 

Pour utiliser le système de fichiers Azure pour stocker des données de plages brutes, procédez comme suit:

1. Créez un secret avec le nom de compte de stockage et le volume:

   kubectl create secret generic storage-account --from-literal=azurestorageaccountname={storage_account_name} --from-literal=azurestorageaccountkey={storage_account_key} -n instana-core
    

2. Créez un volume persistant en créant pv.yaml:

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: my-nfs-volume
   spec:
     capacity:
       storage: 100Gi
     accessModes:
       - ReadWriteMany
     azureFile:
       secretName: storage-account
       shareName: <storage_account_name>
       readOnly: false
     persistentVolumeReclaimPolicy: Retain
    

3. Configurez Core comme illustré dans l'exemple suivant:

   spec:
     storageConfigs:
       rawSpans:
         pvcConfig:
           accessModes:
             - ReadWriteMany
           resources:
             requests:
               storage: 100Gi
           volumeName: my-nfs-volume
    

Pour utiliser le système de fichiers pour stocker les données de plages brutes, configurez Core comme suit:

spec:
  storageConfigs:
    rawSpans:
      pvcConfig:
        accessModes:
          - ReadWriteMany
        resources:
          requests:
            storage: 100Gi
        volumeName: my-nfs-volume
        storageClassName: ""
 

Vous devez configurer les magasins de données suivants dans la section spec de Core:

• cassandra
• postgres
• clickhouse
• elasticsearch
• kafka

Remarques :

• Au minimum, les adresses doivent être configurées pour chaque magasin de données. Voir l'exemple suivant :

  spec:
    datastoreConfigs:
      cassandraConfigs:
        - hosts:
            - <IP address or hostname>
      clickhouseConfigs:
        - hosts:
            - <IP address or hostname>
      postgresConfigs:
        - hosts:
            - <IP address or hostname>
      elasticsearchConfig:
        hosts:
          - <IP address or hostname>
      kafkaConfig:
        hosts:
          - <IP address or hostname>
   

  Remplacez < adresse IP ou nom d'hôte > par l'adresse IP ou le nom d'hôte du magasin de données.

• Si des magasins de données sont installés dans le même cluster à l'aide d'opérateurs tiers, vous pouvez configurer datastoreConfigs la connexion à ces magasins en utilisant les noms d'hôte de l' DNS e interne au cluster, comme le montre l'exemple de configuration suivant :

  spec:
    datastoreConfigs:
      cassandraConfigs:
        - authEnabled: true
          datacenter: cassandra
          hosts:
            - <IP address or hostname>
      clickhouseConfigs:
        - authEnabled: true
          clusterName: local
          hosts:
            - <IP address or hostname>
            - <IP address or hostname>
      elasticsearchConfig:
        authEnabled: true
        clusterName: instana
        hosts:
          - <IP address or hostname>
      kafkaConfig:
        saslMechanism: SCRAM-SHA-512
        authEnabled: true
        hosts:
          - <IP address or hostname>
      postgresConfigs:
        - authEnabled: true
          hosts:
            - <IP address or hostname>
   

• Vérifiez que le nom exact du centre de données Cassandra (par défaut: cassandra) est configuré dans la section cassandraConfigs de la spécification Core via l'attribut datacenter .

• Pour l'architecture Power: vérifiez que le nom exact du centre de données Cassandra (par défaut: datacenter1) est configuré dans la section cassandraConfigs de la spécification Core via l'attribut datacenter .

• ClickHouse (par défaut: local) et Elasticsearch (par défaut: onprem_onprem) acceptent un nom de cluster via l'attribut clusterName .

  Les magasins de données permettent de configurer un port tcp . De plus, un port http peut également être configuré pour clickhouse et elasticsearch.

  spec:
    datastoreConfigs:
      clickhouseConfigs:
        - clusterName: local
          hosts:
            - <IP address or hostname>
          ports:
            - name: tcp
              port: 9000
            - name: http
              port: 8123
   

Si aucun port n'est configuré, les valeurs par défaut suivantes s'appliquent:

Le remplacement des paramètres de conservation par défaut est facultatif et ne doit être effectué que consciemment. Ces valeurs de paramètre de conservation sont configurées en tant que propriétés dans CoreSpec.

Les propriétés de conservation suivantes s'appliquent aux tables de cumul de métriques et les valeurs répertoriées sont les valeurs par défaut en secondes. Une valeur de zéro indique au système de ne pas supprimer les cumuls de cette période. Une valeur nulle pour les rollups de petite taille peut entraîner un remplissage rapide des disques.

kind: Core
metadata:
  name: instana-core
  namespace: instana-core
spec:
  properties:
    - name: retention.metrics.rollup5
      value: "86400"
    - name: retention.metrics.rollup60
      value: "2678400"
    - name: retention.metrics.rollup300
      value: "8035200"
    - name: retention.metrics.rollup3600
      value: "34214400"
    - name: retention.metrics.rawPayload
      value: "2592000"
...
 

Les perspectives d'application et la surveillance des utilisateurs finaux (EUM) utilisent les mêmes paramètres de conservation pour les données à court terme et à long terme, respectivement. La conservation à court terme enregistre l'intégralité des données et est fixée par défaut à 7 jours. La conservation à long terme conserve un échantillon aléatoire de 1 % des données; la durée par défaut est de 13 mois. Avec les paramètres par défaut et une alimentation constante en données, les données à long terme occupent environ la moitié de l'espace disque par rapport aux données à court terme.

Vous pouvez définir une durée de conservation à court terme comprise entre 2 et 31 jours. Vous pouvez définir une durée de conservation à long terme comprise entre 31 et 396 jours. Si vous indiquez des valeurs en dehors de ces plages, les services d' Instana s échoueront au démarrage.

Outre les données complètes à court terme et les données échantillonnées à long terme, Instana conserve des indicateurs agrégés afin d'améliorer les performances des requêtes. Instana ne vous permet pas de configurer la durée de conservation des métriques agrégées et la définit par défaut sur 31 jours.

kind: Core
metadata:
  name: instana-core
  namespace: instana-core
spec:
  properties:
    - name: config.appdata.shortterm.retention.days
      value: "7"

    - name: config.appdata.longterm.retention.days
      value: "396"
...
 

Les modifications apportées aux paramètres de conservation ont des répercussions variables sur les vues de l'application et les données de surveillance des utilisateurs finaux :

• Conservation à court terme pour les applications : le système n'applique le nouveau paramètre qu'aux nouvelles données. Il supprime les données précédemment enregistrées conformément au paramètre de conservation qui était en vigueur au moment de leur enregistrement. Une fois la modification effectuée, la durée de conservation effective des données s'adapte progressivement à la nouvelle valeur.
• Conservation à court terme pour l'EUM : le système applique le nouveau paramètre aussi bien aux données existantes qu'aux nouvelles données. Il supprime toutes les données conformément au paramètre de conservation actuel.
• Conservation à long terme : le système applique les modifications à toutes les données à long terme, existantes et nouvelles, pour les perspectives applicatives et l'EUM.

Consultez l'impact suivant sur les données des perspectives d'application:

Exemples :

• config.appdata.shortterm.retention.days passe de 7 à 14 jours : le système supprime les données enregistrées avant cette modification dès qu'elles datent de plus de 7 jours. Il supprime les données enregistrées après la modification dès qu'elles datent de plus de 14 jours. Le système a besoin de 14 jours pour établir un historique complet de l' 14‑day. Cependant, Instana part immédiatement du principe que 14 jours de données complètes sont disponibles, ce qui peut entraîner des résultats temporairement inexacts pendant la période de transition.
• config.appdata.shortterm.retention.days passe de 14 à 7 jours : le système supprime les données enregistrées avant cette modification dès qu'elles datent de plus de 14 jours. Il supprime les données enregistrées après la modification dès qu'elles datent de plus de 7 jours. Le volume des données à court terme stockées diminue pour atteindre ce nouveau niveau en l'espace de 14 jours. Cependant, Instana limite immédiatement les requêtes portant sur une période supérieure aux 7 derniers jours aux données à long terme ou agrégées.
• config.appdata.longterm.retention.days passe de 396 jours à 60 jours : le système supprime les données d'échantillonnage à long terme dès qu'elles datent de plus de 60 jours. Il supprime les données actuellement stockées datant de plus de 60 jours lors du prochain cycle de nettoyage.
• config.appdata.longterm.retention.days est modifiée de 60 à 120 jours : le système ne supprime les données d'échantillonnage à long terme que lorsqu'elles datent de plus de 120 jours. Les données qui avaient déjà atteint 60 jours restent désormais disponibles pendant la période prolongée de l' 120‑day.

Consultez les conséquences suivantes sur les données de surveillance des utilisateurs finaux :

Exemples :

• config.appdata.shortterm.retention.days passe de 7 à 14 jours : les données récentes sont supprimées lorsqu'elles datent de plus de 14 jours.
• config.appdata.shortterm.retention.days passe de 14 à 7 jours : les données à court terme sont supprimées lorsqu'elles datent de plus de 7 jours.
• config.appdata.longterm.retention.days est ramenée de 396 jours à 60 jours : toutes les données d'échantillonnage à long terme sont supprimées dès lors qu'elles datent de plus de 60 jours.
• config.appdata.longterm.retention.days est portée de 60 à 120 jours : toutes les données d'échantillonnage à long terme sont supprimées lorsqu'elles datent de plus de 120 jours.

La surveillance synthétique possède une propriété de conservation des données distincte avec une valeur par défaut de 60 jours. La rétention des résultats des tests synthétiques et des détails des résultats des tests synthétiques est contrôlée par ce paramètre.

kind: Core
metadata:
  name: instana-core
  namespace: instana-core
spec:
  properties:
    - name: config.synthetics.retention.days
      value: "60"
...
 

Consultez l'impact suivant sur les données de surveillance synthétique:

Exemples :

• config.synthetics.retention.days passe de 60 jours à 90 jours: les données stockées avant le changement de configuration sont supprimées lorsqu'elles sont antérieures à 60 jours, et les données stockées après le changement de configuration sont supprimées lorsqu'elles sont antérieures à 90 jours.
• config.synthetics.retention.days passe de 60 jours à 7 jours: les données stockées avant la modification de la configuration sont supprimées lorsqu'elles datent de plus de 60 jours et les données stockées après la modification de la configuration sont supprimées lorsqu'elles datent de plus de 7 jours.

Une fois que votre fichier de configuration pour Core est prêt, appliquez-le comme suit:

kubectl apply -f path/to/core.yaml
 

Vérifiez si tous les pods sont en cours d'exécution avant de procéder comme suit:

kubectl get pods -n instana-core
 

Vérifiez l'état de la ressource « core » dans l'espace de noms « instana-core » :

kubectl get core -n instana-core
 

L'exemple suivant présente un aperçu du résultat :

NAME           VERSION   INSTANA VERSION   DB MIGRATION STATUS   COMPONENTS STATUS
instana-core   1.2.0     3.289.589-0       Ready                 Ready
 

La création d'une unité et d'un locataire est simple.

Pour créer un logement et un locataire, créez un fichier de configuration de logement ( YAML ) tel que unit.yaml celui présenté dans l'exemple suivant :

apiVersion: instana.io/v1beta2
kind: Unit
metadata:
  namespace: instana-units
  name: tenant0-unit0
spec:
  # Must refer to the namespace of the associated Core object that was created previously
  coreName: instana-core

  # Must refer to the name of the associated Core object that was created previously
  coreNamespace: instana-core

  # The name of the tenant
  # Tenant name must match the regular expression pattern `^[a-z][a-z0-9]*$`
  # Tenant name must not exceed a maximum length of 15 characters
  # Tenant name must begin with an alphabetical character
  # Tenant name can consist of alphanumeric characters
  # Characters must be in lowercase
  tenantName: tenant0

  # The name of the unit within the tenant
  unitName: unit0

  # The same rules apply as for Cores. May be ommitted. Default is 'medium'
  resourceProfile: large
 

Une fois votre configuration prête, appliquez vos paramètres comme suit:

kubectl apply -f path/to/unit.yaml
 

Vérifiez si tous les pods sont en cours d'exécution avant de procéder comme suit:

kubectl get pods -n instana-units
 

Récupérer la liste des unités dans l'espace de noms « instana-units » :

kubectl get unit -n instana-units
 

L'exemple suivant présente un aperçu du résultat :

AME           VERSION   INSTANA VERSION   DB MIGRATION STATUS   COMPONENTS STATUS
instana-unit   1.2.0     3.289.589-0       Ready                 Ready
 

Ajoutez les lignes suivantes dans le fichier unit.yaml pour définir les tolérances et le sélecteur de nœuds

 spec:
   tolerations:
     - key: node.instana.io/monitor
       operator: Equal
       effect: NoSchedule
       value: "true"
   nodeSelector:
     node-role.kubernetes.io/monitor: "true"
 

Certaines fonctions ne sont pas activées dans un système de back end auto-hébergé par défaut. Vous pouvez activer ces fonctions à l'aide d'options de configuration supplémentaires.

Pour plus d'informations sur les fonctionnalités optionnelles et la manière de les activer, consultez la section « Activation des fonctionnalités optionnelles ».