Traitement des incidents

Informations sur la manière de résoudre un problème avec Custom Edition.

Recueillir des informations de diagnostic pour le dépannage

Utilisez la commande kubectl instana diagnostics pour recueillir un ensemble complet de diagnostics concernant l' Kubernetes, la plate-forme, les nœuds et les banques de données, afin de dépanner un déploiement auto-hébergé d' Instana (édition personnalisée) fonctionnant sur Kubernetes ou OpenShift.

Utilisez la syntaxe suivante pour exécuter la commande :

kubectl instana diagnostics [flags]
kubectl instana debug [flags]

kubectl instana debug est un alias de kubectl instana diagnostics et se comporte exactement de la même manière.

Remarque :
Cette commande ne permet ni de gérer ni de provisionner un cluster. Il se connecte à un cluster Kubernetes déjà en cours d'exécution en utilisant le contexte kubeconfig actif.

Options de commande

Tableau 1. Options de commande
Indicateur Court Type Par défaut Description
--download-key - Chaîne Obligatoire Instana Téléchargez la clé utilisée comme mot de passe du registre de conteneurs (nom d'utilisateur : _) pour récupérer l'image node-collector. Vous devez spécifier cet indicateur pour exécuter la commande.
--output-dir -o Répertoire Répertoire de travail en cours Le répertoire dans lequel la commande crée le dossier de diagnostics horodaté et l'archive.
--deep-debug - Booléen false Exécute une série supplémentaire de scripts de débogage approfondi une fois la collecte des diagnostics standard terminée.
--max-log-lines -l Entier 20000 Nombre maximal de lignes de journal à collecter par conteneur. Réglez sur 0 pour collecter toutes les lignes de journal disponibles.
--log-collection-days - Entier 7 Nombre de jours de journaux historiques à collecter.
--node-collector-image - Chaîne Image par défaut fournie avec la version Image de conteneur utilisée par le « node-collector » temporaire DaemonSet. Remplacez ce paramètre pour les déploiements de registre en mode « air-gapped » ou privés.
--node-collector-namespace - Chaîne default Espace de noms dans lequel la commande crée le collecteur de nœuds temporaire DaemonSet.
--external-script - Extrait de chaîne Aucun Un ou plusieurs scripts shell fournis par l'utilisateur à exécuter pendant la collecte des données de diagnostic. Indiquez plusieurs valeurs sous forme de liste séparée par des virgules ou en répétant l'indicateur.
--env-file - Fichier Aucun Charge les variables d'environnement à partir d'un .env fichier afin de remplacer la configuration des diagnostics (espaces de noms, identifiants, sélecteurs de pods et autres paramètres similaires).

Une fois la collecte des données de diagnostic terminée, la commande affiche l'emplacement du paquet généré.

Done!
Diagnostics package ->
<output-dir>/diagnostics_<YYYYMMDDHHmmss>

La commande crée le répertoire horodaté à l'intérieur du répertoire que vous indiquez avec --output-dir.

Ce que le moteur collecte

Le moteur de diagnostic exécute les collecteurs suivants.

  • Ressources « Kubernetes » au niveau du cluster

    Le moteur collecte les ressources d' Kubernetes s au niveau du cluster, notamment :

    • Noeuds
    • Espaces de nom
    • ClusterRoles
    • ClusterRoleBindings
    • StorageClasses
    • PersistentVolumes
    • CustomResourceDefinitions (CRD)
    • Autres ressources au niveau du cluster
  • Informations relatives au réseau de l'hôte

    Le moteur recueille des informations relatives au réseau de l'hôte, notamment :

    • Tables de routage
    • Interfaces réseau
    • règles iptables
    • Paramètres réseau sysctl
    • Informations sur la connectivité
  • Envoy diagnostics

    Le moteur recueille des données de diagnostic d' Envoy s provenant des pods de répartition de charge « Instana Core », notamment :

    • Statistiques sur les grappes
    • Configuration de l'écouteur
    • Routes
    • Informations sur la santé
  • Ressources « Kubernetes » avec espace de noms

    Le moteur rassemble les ressources Kubernetes associées à des espaces de noms dans tous les espaces de noms Instana, notamment :

    • Pods
    • Déploiements
    • StatefulSets
    • services
    • ConfigMaps
    • Secrets (valeurs masquées)
    • Evénements
    • ReplicaSets
    • DaemonSets
    • PersistentVolumeClaims
    • HorizontalPodAutoscalers
    • Ressources personnalisées
  • Informations au niveau des nœuds

    Le moteur utilise une « DaemonSet » temporaire pour collecter des informations au niveau des nœuds, notamment :

    • UC
    • Mémoire
    • Topologie des disques
    • Version du noyau et du système d'exploitation
    • Points de montage
    • Utilisation du disque
    • Configuration de sysctl
    • Sortie de la commande `dmesg`

    Le collecteur de nœuds temporaire DaemonSet applique une tolérance aux caractères génériques. Cela permet au moteur de collecter des données de diagnostic provenant de chaque nœud du cluster, y compris ceux du plan de contrôle, de l'infrastructure, des banques de données dédiées, des GPU et de tout nœud personnalisé marqué. Ce comportement est automatique; vous n'avez pas besoin d'utiliser d'options supplémentaires.

  • Instana diagnostics du backend

    Le moteur recueille les données de diagnostic du backend d' Instana, notamment :

    • Réponses relatives aux critères d'évaluation en matière de santé
    • Indicateurs internes
    • Utilisation des ressources des pods
  • Kafka diagnostics

    Le moteur recueille des données de diagnostic « Kafka », notamment :

    • Liste des thèmes
    • Décalage dans le groupe de consommateurs
    • courtier, configuration
    • Kafka Statut de la ressource personnalisée
  • Cassandra diagnostics

    Le moteur recueille des données de diagnostic « Cassandra », notamment :

    • Résultats de la commande « nodetool status »
    • Sortie de la commande « nodetool info »
    • Statistiques des tables
    • Résultats de la validation CQL
  • Elasticsearch diagnostics

    Le moteur recueille des données de diagnostic « Elasticsearch », notamment :

    • État de santé du cluster
    • Statistiques d'index
    • Allocation des fragments
    • Elasticsearch Statut de la ressource personnalisée
  • BeeInstana diagnostics

    Le moteur recueille des données de diagnostic « BeeInstana », notamment :

    • Journaux de l'agrégateur
    • Journaux d'Ingestor
    • Journaux Monconfig
    • BeeInstana Statut de la ressource personnalisée
    • Indicateurs internes
  • Kubernetes journaux de service au niveau des nœuds

    Le moteur collecte les journaux de service au niveau des nœuds pour les distributions standard d’ Kubernetes, y compris les plateformes cloud gérées. En voici quelques exemples :

    • kubelet
    • containerd
    • Docker durée d'exécution (le cas échéant)
  • OpenShift-specific journaux de service de la plateforme

    Le moteur collecte les journaux de service de la plateforme OpenShift-specific ainsi que les journaux de service au niveau des nœuds Kubernetes. En voici quelques exemples :

    • CRI-O
    • Serveur d'API OpenShift
    • Démon de configuration de la machine
    • Autres composants de la plateforme
    Remarque :
    Sur les clusters « non-OpenShift », ce collecteur se ferme sans générer de sortie.
  • Scripts de débogage approfondi (nécessite l' --deep-debug))

    --deep-debugLorsque vous activez cette option, le moteur exécute une série supplémentaire de scripts de débogage approfondi une fois la collecte standard terminée. En voici quelques exemples :

    • Diagnostics avancés du réseau
    • Inspection approfondie du magasin de données

Espaces de noms par défaut

Le moteur de diagnostic utilise les espaces de noms par défaut suivants.

Tableau 2. Espaces de noms par défaut
Composant Espace de nom par défaut
ClickHouse instana-clickhouse
PostgreSQL instana-postgres
BeeInstana instana-beeinstana
Elasticsearch instana-elasticsearch
Cassandra instana-cassandra
Kafka instana-kafka
Agent Instana instana-agent

Le moteur détecte automatiquement les espaces de noms « Core » et « Unit » au sein du cluster.

Référence de variable d'environnement

Vous pouvez fournir la configuration soit directement via des variables d'environnement, soit en transmettant un .env fichier à l'aide de --env-file l'option. Lorsque la valeur par défaut est indiquée comme « Détectée automatiquement », le moteur récupère la valeur à partir des secrets d' Kubernetes s dans l'espace de noms correspondant.

ClickHouse

Tableau 3. ClickHouse variables d'environnement
Variables Par défaut Description
CLICKHOUSE_NAMESPACE instana-clickhouse ClickHouse espace de noms
CLICKHOUSE_POD_NAME chi-clickhouse-local-0-0-0 Cible : le podcast « ClickHouse »
CLICKHOUSE_CLUSTER local Nom du cluster
CLICKHOUSE_HORAIRES_DE_OUVERTURE 24 Nombre d'heures de données diagnostiques à collecter
CLICKHOUSE_ADMIN_USER Détecté automatiquement Nom de l'administrateur
CLICKHOUSE_ADMIN_PASSWORD Détecté automatiquement Mot de passe administrateur
CLICKHOUSE_USER Détecté automatiquement Nom d'utilisateur de l'application
CLICKHOUSE_MOT_DE_PASSE Détecté automatiquement Mot de passe de l'application

PostgreSQL

Tableau 4. PostgreSQL variables d'environnement
Variables Par défaut Description
POSTGRES_NAMESPACE instana-postgres PostgreSQL espace de noms
POSTGRES_ADMIN_USER Détecté automatiquement Nom de l'administrateur
POSTGRES_ADMIN_PASSWORD Détecté automatiquement Mot de passe administrateur
POSTGRES_USER Détecté automatiquement Nom d'utilisateur de l'application
POSTGRES_PASSWORD Détecté automatiquement Mot de passe de l'application

BeeInstana

Tableau 5. BeeInstana variables d'environnement
Variables Par défaut Description
BEEINSTANA_NAMESPACE instana-beeinstana BeeInstana espace de noms
BEEINSTANA_USER Détecté automatiquement Nom d'utilisateur de l'application
BEEINSTANA_MOT_DE_PASSE Détecté automatiquement Mot de passe de l'application
BEEINSTANA_POD_SELECTOR app.kubernetes.io/name=beeinstana Sélecteur de pods pour les pods « BeeInstana »

Elasticsearch

Tableau 6. Elasticsearch variables d'environnement
Variables Par défaut Description
ELASTICSEARCH_NAMESPACE instana-elasticsearch Elasticsearch espace de noms
ELASTICSEARCH_ADMIN_USER Détecté automatiquement Nom de l'administrateur
ELASTICSEARCH_ADMIN_PASSWORD Détecté automatiquement Mot de passe administrateur
ELASTICSEARCH_USER Détecté automatiquement Nom d'utilisateur de l'application
ELASTICSEARCH_PASSWORD Détecté automatiquement Mot de passe de l'application
ELASTICSEARCH_POD_SELECTOR common.k8s.elastic.co/type=elasticsearch Sélecteur de pods pour les pods « Elasticsearch »

Cassandra

Tableau 7. Cassandra variables d'environnement
Variables Par défaut Description
CASSANDRA_NAMESPACE instana-cassandra Cassandra espace de noms
CASSANDRA_ADMIN_USER Détecté automatiquement Nom de l'administrateur
CASSANDRA_ADMIN_PASSWORD Détecté automatiquement Mot de passe administrateur
CASSANDRA_USER Détecté automatiquement Nom d'utilisateur de l'application
CASSANDRA_PASSWORD Détecté automatiquement Mot de passe de l'application
CASSANDRA_POD_SELECTOR app.kubernetes.io/name=cassandra Sélecteur de pods pour les pods « Cassandra »

Kafka

Tableau 8. Kafka variables d'environnement
Variables Par défaut Description
KAFKA_NAMESPACE instana-kafka Kafka espace de noms
KAFKA_ADMIN_USER Détecté automatiquement Nom de l'administrateur
KAFKA_ADMIN_PASSWORD Détecté automatiquement Mot de passe administrateur
KAFKA_CONSUMER_USER Détecté automatiquement Nom d'utilisateur du consommateur
KAFKA_MOT_DE_PASSE_UTILISATEUR Détecté automatiquement Mot de passe de l'utilisateur
KAFKA_PRODUCER_USER Détecté automatiquement Nom d'utilisateur du producteur
KAFKA_PRODUCER_PASSWORD Détecté automatiquement Mot de passe du producteur
KAFKA_SASL_MECHANISM SCRAM-SHA-512 Mécanisme SASL
KAFKA_SASL_TEXTE_EN_CLAR SASL_PLAINTEXT Protocole de transport SASL
KAFKA_POD_SELECTOR app.kubernetes.io/name=kafka Sélecteur de pods pour les pods « Kafka »

Noyau et agent

Tableau 9. Variables d'environnement du noyau et de l'agent
Variables Par défaut Description
CORE_NAMESPACE Détecté automatiquement Espace de noms du composant principal « Instana »
CORE_NAME Détecté automatiquement Nom de l'instance principale d' Instana
INSTANA_AGENT_NAMESPACE instana-agent Instana Espace de noms de l'agent

Identifiants d' API s du backend

Tableau 10. Identifiants API du backend
Variables Description
ADMIN_API_USER Nom d'utilisateur de l'administrateur API (détecté automatiquement)
ADMIN_API_PASSWORD Mot de passe d' API, administrateur (détecté automatiquement)
SERVICE_API_USER Nom d'utilisateur du service « API » (détecté automatiquement)
SERVICE_API_PASSWORD Mot de passe du service « API » (détecté automatiquement)

registre Docker

Tableau 11. Docker variables d'environnement du registre
Variables Par défaut Description
DOCKER_REGISTRY_USER _ Nom d'utilisateur du registre
DOCKER_REGISTRY_PASSWORD Valeur de --download-key Mot de passe du registre

Exemple de fichier.env

Créez un .env fichier pour remplacer les valeurs de configuration par défaut.

CLICKHOUSE_NAMESPACE=my-clickhouse
KAFKA_NAMESPACE=my-kafka

CLICKHOUSE_ADMIN_USER=clickhouse_operator_user
CLICKHOUSE_ADMIN_PASSWORD=s3cr3t

CLICKHOUSE_WINDOW_HOURS=48

CASSANDRA_POD_SELECTOR=app=instana-cassandra,tier=database

Exécutez la commande avec votre fichier de paramètres personnalisés :

kubectl instana diagnostics \
  --download-key <download-key> \
  --env-file ./my-overrides.env

Réglage du niveau de journalisation pour les composants d' Instana

Pour régler le niveau des composants d' Instana, procédez comme suit :

  1. Configurez le niveau de journalisation d'un composant dans l' CoreSpec. Dans l'exemple suivant, vous modifiez le niveau de journalisation de DEBUG pour le composant butler :

    apiVersion: instana.io/v1beta2
kind: Core
metadata:
  name: instana-core
  namespace: core
spec:
  ...
  componentConfigs:
    - name: butler
      env:
        - name: COMPONENT_LOGLEVEL
          # Possible values are DEBUG, INFO, WARN, ERROR (not case-sensitive)
          value: DEBUG

  2. Affichez les journaux en exécutant la commande suivante:

    kubectl logs <component name> -n instana-core

    <nom du composant> est le nom du composant pour lequel vous souhaitez effectuer un dépannage.

Utilisation d'une commande spécifique à l' kubectl pour le débogage et le diagnostic

La commande « cluster-info dump » d' kubectl est un outil utile pour le débogage et le diagnostic des clusters d' Kubernetes. Il fournit un rapport détaillé sur l'état actuel du cluster Kubernetes, comprenant diverses informations sur les ressources.

Configurez l'espace de nom cible et le répertoire pour générer des informations de débogage. Dans l'exemple suivant, l'espace de nom est instana-units et le répertoire est temp. Lorsque vous exécutez cette commande, ` kubectl ` génère des fichiers ` YAML ` pour chaque ressource de l'espace instana-units de noms et enregistre ces fichiers ` YAML ` dans le temp répertoire.

kubectl cluster-info dump --namespace instana-units --output-directory temp --output yaml

L'extrait suivant présente une partie du contenu du répertoire temp . Dans le sous-répertoire instana-units , vous trouverez des détails sur les objets daemonsets, les déploiements, les événements, les pods et d'autres ressources dans les fichiers .yaml . Les journaux de tous les pods se trouvent dans chaque sous-répertoire instana-units\pod name .

├── instana-units
│   ├── daemonsets.yaml
│   ├── deployments.yaml
│   ├── events.yaml
│   ├── pods.yaml
│   ├── replicasets.yaml
│   ├── replication-controllers.yaml
│   ├── services.yaml
│   ├── tu-instana-prod-appdata-legacy-converter-755bb474c7-xn4vg
│   │   └── logs.txt
│   ├── tu-instana-prod-appdata-processor-6b8f448584-nmvgl
│   │   └── logs.txt
│   ├── tu-instana-prod-filler-9485b85d-wj7pv
│   │   └── logs.txt
│   ├── tu-instana-prod-issue-tracker-bbd5f5d5f-98zxx
│   │   └── logs.txt
│   ├── tu-instana-prod-processor-fc956c46c-fxs5z
│   │   └── logs.txt
│   └── tu-instana-prod-ui-backend-89bccd9c5-8lp76
│       └── logs.txt
...
└── nodes.yaml
Remarque :
  • Vous pouvez choisir un autre espace de nom, tel que instana-core.
  • Si n'est kubectl pas installé sur votre cluster, vous pouvez utiliser la commande oc cluster-info dump, qui offre les mêmes fonctionnalités que la commande kubectl cluster-info dump .

Pour plus de commandes de dépannage, consultez la section « Dépannage des clusters » sur kubectl ainsi que le guide de référence des commandes CLI pour développeurs sur Red Hat OpenShift.

Utilisation de l' API du backend interne

Vous pouvez utiliser certains points de terminaison de l' API des composants internes pour vous aider à administrer un backend Instana auto-hébergé. Vous pouvez envoyer ces appels ` API ` depuis le cluster vers les pods correspondants à l'aide de ` curl `. Etant donné que les ressources requièrent une authentification, vous devez d'abord obtenir des données d'identification valides. Vous trouverez les identifiants « API » dans le secret « internal-instana » de l'espace de noms « core ». Les points de terminaison de l' API, AdminAPIUser et ServiceAPIUser, contiennent deux types de données. Pour obtenir les identifiants valides pour une installation d' Instana, exécutez les commandes suivantes :

kubectl get secret instana-internal -n instana-core --template='{{ index .data.serviceAPIUser  | base64decode }}'

kubectl get secret instana-internal -n instana-core --template='{{ index .data.serviceAPIPassword  | base64decode }}'

Pour obtenir les données d'identification de l'administrateur, interrogez .data.adminAPIUser et .data.adminAPIPassword.

Vous pouvez utiliser ces identifiants pour les procédures suivantes.

Réinitialisation du mot de passe d'un utilisateur d' Instana

Pour réinitialiser le mot de passe d'un compte utilisateur Instana, exécutez la commande suivante :

kubectl exec -it -n instana-core deploy/butler -- curl -X PUT http://localhost:8601/admin/authentication/{tenant}/reset/user -u {adminAPIUser}:{adminAPIPassword} -H 'Content-Type: application/json' -d '{"email":"{user}","pass":"{newPassword}"}'

Désactivation des configurations des fournisseurs SSO ( LDAP / SAML / OIDC)

Si vous utilisez un fournisseur d'identité pour l'authentification d' Instana, désactivez ce fournisseur à l'aide de la commande suivante. Par la suite, vous pourrez utiliser les comptes utilisateurs internes d' Instana pour l'authentification.

kubectl exec -it -n instana-core deploy/butler -- curl -X PUT http://localhost:8601/admin/authentication/{tenant}/idp -u {adminAPIUser}:{adminAPIPassword}

Désactiver la fonction « 2FA » sur un compte utilisateur

Pour désactiver l'authentification à deux facteurs ( 2FA ) pour un compte utilisateur Instana, exécutez la commande suivante :

kubectl exec -it -n instana-core deploy/butler -- curl -X DELETE http://localhost:8601/admin/2fa/users/{email} -u {adminAPIUser}:{adminAPIPassword}

Vérification des licences

Pour vérifier toutes les licences enregistrées, exécutez la commande suivante :

kubectl exec -it -n instana-core deploy/groundskeeper -- curl -X GET http://localhost:8600/license/list/{tenant}/{unit} -u {serviceAPIUser}:{serviceAPIPassword}

Certaines métriques n'apparaissent pas sur les tableaux de bord

Si certains indicateurs n'apparaissent pas dans les tableaux de bord, c'est probablement que vous avez atteint la limite du nombre d'indicateurs. La limite est fixée à 3 000 par défaut.

Astuce: Vous pouvez voir la limite actuelle sous maxMetrics dans le fichier filler/config.yaml . La limite est là pour empêcher certaines entités d'envoyer un trop grand nombre de métriques, ce qui augmenterait le stockage et l'unité centrale utilisés par l'agent de remplissage, et augmenterait la bande passante pour envoyer des métriques à l'interface utilisateur.

Pour augmenter la limite, ajoutez le bloc avec config.max.metrics dans la ressource personnalisée pour l'unité comme suit:

kind: unit
...
spec:
...
  properties:
    - name: config.max.metrics
      value: "6000"
...

Instana Le backend cesse de fonctionner lorsque le disque de données de l' Elasticsearch ation dépasse 85 % de son espace disponible

Elasticsearch passe automatiquement son magasin de données en mode lecture seule lorsque l'espace utilisé sur le disque dépasse 85 %. Cela entraîne l'arrêt du fonctionnement du backend Instana. Libérez de l'espace sur le disque de données de l' Elasticsearch, ou augmentez sa capacité afin de rétablir un fonctionnement normal. Remarque : les autres disques « Instana » ne passent pas en mode lecture seule à des taux d'utilisation similaires (même supérieurs à 95 %), ce qui peut rendre ce problème difficile à comprendre.

Pour résoudre ce problème, procédez de l'une des manières suivantes :
  • Espace libre sur le disque de données de l' Elasticsearch
  • Augmenter l'espace disque alloué à Elasticsearch
Lorsque l'espace disponible est suffisant, Elasticsearch reprend ses opérations d'écriture normales et le backend redevient opérationnel.
Remarque :
Les autres disques « Instana » ne passent pas en mode lecture seule à des niveaux d'utilisation similaires (même supérieurs à 95 %), ce qui peut prêter à confusion lors du dépannage.

La licence n'est pas valide ou est manquante

Si la licence n'est pas valide ou est manquante, le serveur empêche les agents de se connecter.

Lorsque cela se produit

  • La licence importée n'est pas valide.
  • L'opérateur « Instana » ne peut pas appliquer la licence au backend de Groundskeeper.

Comment résoudre les problèmes

  1. Vérifiez que la clé de vente figurant dans le secret principal correspond aux chaînes de licence contenues dans le secret de l'unité. Si elles ne correspondent pas, téléchargez à nouveau la licence en utilisant la clé de vente appropriée.
  2. Vérifiez les journaux de l'opérateur « Instana » pour détecter d'éventuelles erreurs d'importation de licence :
    kubectl logs -n instana-operator deployment/instana-operator --tail=100
  3. Vérifiez le composant backend de Groundskeeper, l'état du pod et les journaux :
    kubectl get pods -n instana-core | grep groundskeeper
  4. Si la licence apparaît toujours comme non valide, contactez le service d'assistance d' IBM.